MVP 범위 정하는 법: 첫 개발을 정말 중요한 것만으로 줄이기

앱 아이디어를 들고 저희를 찾는 거의 모든 사람은 이미 머릿속에서 그 완성판을 다 만들어 두었습니다. 대시보드, 설정 페이지, 추천 프로그램, 다크 모드까지 설명할 수 있습니다. 하지만 그 그림의 어느 한 부분이 작동하면 전체를 할 가치가 생기는지는 대개 말하지 못합니다. MVP 범위를 정한다는 것은 바로 그 한 부분을 찾아내고, 나머지를 나중으로 미룰 용기를 내는, 화려하지 않고 약간 고통스러운 작업입니다.

저는 많은 첫 제품이 만들어지는 것을 지켜봤는데, 고전하는 제품이 팀의 게으름 때문에 실패하는 일은 거의 없습니다. 실패하는 이유는 첫 주부터 범위가 잘못됐기 때문입니다. 버전 1에 너무 많이 담았고, 누구도 무엇 하나 배우기 전에 예산이 바닥났으며, 출시 무렵 팀은 출발선에 서는 데만 모든 것을 써버립니다. 실제 사용자가 무엇을 했는지에 반응할 돈은 남아 있지 않습니다.

그래서 이것은 코드 한 줄을 쓰기 전에 제가 사람들에게 건네는 가이드입니다. 애자일 의식이나 화려한 프레임워크 이야기가 아닙니다. 단 하나의 정직한 질문——이 아이디어가 진짜인지 알려줄, 우리가 만들 수 있는 가장 작은 것은 무엇인가?——과, '딱 하나만 더 기능을'이라는 유혹이 다시 스며들 때마다 그 질문에 계속 답하는 규율에 관한 이야기입니다. 그 유혹은 언제나 다시 스며들기 때문입니다.

MVP란 실제로 무엇인가 (그리고 무엇이 아닌가)

이 표현은 남용되어 닳아버렸으니 정확히 합시다. 최소 기능 제품(MVP)이란, 실제 사용자에게 진짜 가치를 전달하고 슬라이드 자료로는 배울 수 없던 것을 가르쳐 주는, 아이디어의 가장 작은 버전입니다. 사람들이 잊는 핵심 단어는 기능하는(viable)입니다. 단 하나의 일만 하더라도, 누군가에게 처음부터 끝까지 실제로 작동해야 합니다.

MVP가 아닌 것은 이렇습니다. 곳곳이 망가진 완성품의 절반짜리 버전이 아닙니다. 버리려고 만드는 프로토타입도 아닙니다. 그리고 분명히 '저렴한 버전'도 아닙니다——저렴함은 좋은 범위 설정의 부산물이지 목표가 아닙니다. 목표는 배우는 것입니다. 가장 비싼 질문에 답하기 위해 가능한 한 적은 돈을 쓰는 것입니다. 즉, 누군가 이것을 쓸 것인가, 그리고 내가 생각하는 방식으로 쓸 것인가?

이 구분은 들리는 것보다 중요합니다. '첫 20%' 사고방식은 모든 방향으로 망가지고 어디에도 쓸모없는 것을 낳습니다. '한 가지를, 제대로'는 사람이 집어 들고 진짜로 쓰며 의견을 가질 수 있는 것을 낳습니다. 의견이 전부입니다. 침묵 위에서는 반복할 수 없습니다.

너무 많이 만드는 함정, 그리고 왜 이렇게 빠지기 쉬운가

누구도 범위를 일부러 부풀리려 하지 않습니다. 그것은 합리적인 결정 하나하나가 쌓이며 일어납니다. 당연히 계정이 필요하니 로그인을 더합니다. 계정에는 비밀번호 재설정 흐름, 이메일 인증, 설정 페이지가 따라옵니다. 설정은 프로필을 뜻하고, 이는 이미지 업로드를, 이는 저장 공간을 뜻합니다. 각 단계는 그 자체로는 타당합니다. 쌓이고 보면, 아이디어를 특별하게 하는 부분은 시작도 안 했는데 두 달과 예산의 상당 부분을 써버린 것입니다.

함정의 나머지 절반은 감정적입니다. 기능을 잘라내는 것은 아이디어가 작다고 인정하는 것처럼 느껴집니다. 그렇지 않습니다——어떤 기능이 중요한지 아직 모른다고 인정하는 것이고, 그것은 그저 사실입니다. 사용자가 생기기 전에 만드는 모든 기능은 눈을 가리고 건 베팅입니다. 그 베팅 중 일부는 틀릴 것이고, MVP에서 잘라낸 것들은 애초에 걸지 않았기에 틀려도 가장 값싼 베팅입니다.

MVP가 반드시 해야 할 단 하나의 일을 찾기

어떤 제품이든 결국 얼마나 커지든, 핵심 루프——사용자가 반복하며 가치를 만들어 내는 단일한 연속 동작——를 가집니다. 예약 앱이라면 빈 시간을 찾고, 예약하고, 알림을 받는 것입니다. 마켓플레이스라면 물건을 올리고, 누군가 그것을 찾고, 돈이 오가는 것입니다. 내부 도구라면 데이터를 한 번 입력하고, 어디서나 쓰는 것입니다. 제품의 다른 모든 것은 이 루프를 지탱하고, 꾸미고, 확장하기 위해 존재합니다. 당신의 MVP는 그 루프입니다. 루프뿐입니다.

당신의 것을 찾으려면 이 문장을 소리 내어 완성하십시오. “사용자는 ______ 하려고 내 제품에 오고, ______ 라면 만족한다.” 첫 번째 빈칸이 그 일입니다. 두 번째는 그것이 성공했는지 어떻게 알 것인가입니다. 두 빈칸을 한 호흡에 채우지 못한다면 아직 핵심을 찾지 못한 것입니다——범위를 정할 준비도, 하물며 만들 준비도 안 된 것입니다.

핵심 루프와, 필수처럼 느껴지지만 실은 아닌 것들의 차이에 가차 없으십시오. 로그인은 필수처럼 느껴집니다. 버전 1에서는 대개 아닙니다——수많은 MVP가 공유 링크 하나, 수동 초대, 혹은 계정 없이 출시해 인증 장치를 만들기 전에 필요한 모든 것을 배웁니다. 분석 대시보드도 필수처럼 느껴집니다. 아닙니다. 사용자가 열한 명일 때는 데이터베이스를 손으로 읽으면 됩니다. 루프까지 깎아내면 얼마나 많은 것이 떨어져 나가는지 놀랄 것입니다.

모든 기능을 필수·있으면 좋음·지금은 안 함으로 분류하기

핵심 루프에 이름을 붙였다면, 큰 기능 목록을 가져와 각 항목을 세 바구니로 분류하십시오. 바구니는 일부러 무딥니다. 무딤이야말로 끝없는 '그래도 혹시' 대화를 멈추기 때문입니다.

• 필수: 이것 없이는 핵심 루프가 말 그대로 작동하지 않는다. 제거하면 제품이 없다. 이 목록은 충격적일 만큼 짧게 유지하라——보통 세 개에서 여섯 개.
• 있으면 좋음: 제품을 더 낫게 하지만, 그것 없이도 루프는 작동한다. 여기 있는 모든 것은 버전 2를 기다린다. 첫 개발에서는 예외 없다.
• 지금은 안 함: 지금은 만들지 않기로 의식적으로 선택한 기능. 적어 두는 것이 중요하다——아이디어가 버려진 게 아니라 순서가 매겨졌을 뿐임을, 자신과 팀에게 안심시키는 방법이다.

이것을 작동하게 하는 비결은 세 번째 바구니입니다. 대부분은 필수냐 있으면 좋음이냐만 두고 다투는데, 그것은 진을 빼고 결코 끝나지 않습니다. '지금은 안 함' 목록이야말로 안도가 깃드는 곳입니다——그 멋진 아이디어는 안전하고 예정되어 있으며, 다만 지금이 아닐 뿐이라는, 미래의 자신에게 하는 약속입니다. 아무것도 버려지지 않는다고 사람들이 믿게 되면, 모든 것을 버전 1에 남기려고 싸우기를 멈춥니다.

기능 목록이 아니라 시간과 돈으로 범위를 정하라

모든 것을 바꾸는 조용한 전환이 있습니다. '우리가 무엇을 원하는가'로 범위를 정하기를 멈추고, '예산과 마감에 무엇이 들어맞는가'로 정하기 시작하는 것입니다. 먼저 핵심 질문에 답하기 위해 얼마의 돈과 몇 주를 쓸 의향이 있는지 정합니다. 그런 다음 기능 목록을 그 상자 안에 맞춥니다. 거꾸로 들리지만, 이것은 당신이 스스로에게 줄 수 있는 가장 유용한 제약입니다. 그렇지 않으면 피했을 우선순위 정하기를 강제하기 때문입니다.

고정된 상자는 심리적인 일도 합니다. 예산이 열려 있으면 모든 기능이 논쟁거리이고 목록은 늘어나기만 합니다. 상자가 고정되면——이를테면 8주와 정해진 금액——대화가 뒤집힙니다. '이걸 더할까?'가 아니라 '이게 들어가면 무엇이 나가는가?'가 됩니다. 좋은 MVP를 만드는 것은 바로 두 번째 질문입니다. 절충이 숨지 않고 보이며, 팀은 의도적으로 그것을 합니다.

실제 사례: 작업 관리 아이디어를 줄이기

저희가 작업한 사례로 구체화하겠습니다——익명 처리했지만 이런 일이 흘러가는 방식에 충실합니다. 작은 난방·배관 회사가 현장 팀을 위한 앱을 원하며 찾아왔습니다. 종이 위 개요는 거대했습니다. 실시간 작업 일정, 차량 GPS 추적, 고객 포털, 자동 청구, 차량별 부품 재고, 견적 빌더, 사진 문서화, 그리고 사장을 위한 보고서 모음. 결국에는 정말 유용한 제품입니다. 첫 개발로는 무엇 하나 배우기 전에 1년 예산을 다 쓰는 확실한 방법이었습니다.

그래서 저희는 그 연습을 했습니다. 사장에게 그 문장을 물었습니다. '사용자는 이것에 와서 ______ 하고, ______ 라면 만족한다.' 몇 차례 오간 끝에 진짜 답이 떠올랐습니다. 기술자들의 가장 큰 일상의 고통은 일정도 청구도 아니라——서류 왕복이었습니다. 작업을 마치고 시간과 부품을 종이에 휘갈겨 적고, 차를 몰아 돌아오고, 사무실의 누군가가 그것을 모두, 흔히 며칠 뒤에, 흔히 오류와 함께, 회계 시스템에 다시 입력했습니다. 핵심 루프는 단순했습니다. 현장에서 일어난 일을, 한 번, 그 자리에서 기록해 아무도 다시 입력하지 않게 한다.

선택된 것——그리고 선택되지 않은 것

모든 것이 분류됐습니다. 필수 바구니는 네 가지로 좁혀졌습니다. 각 기술자를 위한 오늘의 작업 목록, 작업별로 시간과 사용 부품을 기록하는 간단한 양식, 사진 첨부, 그리고 제출되는 순간 사무실이 그 데이터를 볼 수 있는 방법. 그것이 MVP의 전부였습니다. GPS도, 고객 포털도, 견적 빌더도, 화려한 보고서도 없이——모두 명시적으로 '지금은 안 함' 목록에, 곧 온다는 메모와 함께 세워 두었습니다.

저희는 그 핵심을 1년의 대부분이 아니라 몇 주 만에 만들었습니다. 그리고 전체 접근을 정당화하는 부분이 여기 있습니다. 출시되자 팀의 진짜 우선순위는 개요와 다른 것으로 드러났습니다. 사장은 GPS 추적이 다음일 거라 가정했지만, 기술자들은 그것을 거의 언급하지 않았습니다. 그들이 큰 목소리로 원한 것은, 앱 안에서 고객에게 도착 시간대를 문자로 보내는 것이었습니다——원래 목록에 있지도 않던 기능입니다. MVP가 작고 저렴했기에, 몇 달 전 추측한 것이 아니라 그들이 정말로 원한 것을 만들 예산이 남아 있었습니다.

MVP 범위를 조용히 망치는 실수들

'작게 유지하라'를 받아들인 팀조차 대개 같은 몇 가지에 걸려 넘어집니다. 어느 것도 극적이지 않습니다. 당신이 보지 않는 사이 범위를 다시 부풀리는 느린 누수입니다. 그러다 어느 날 '최소' 제품이 다시 서른 개의 화면과 6개월 일정을 갖게 됩니다.

• 가장자리에 도금하기: 핵심 루프가 아직 거친데, 오직 당신만 볼 관리자 패널을 완벽하게 하는 데 며칠을 쓴다. 사용자가 만지는 것을 다듬고, 백오피스는 못생겨도 작동하게 둬라.
• 없는 규모를 위해 만들기: 첫 열 명이 돌아올지 증명해야 할 때 백만 사용자를 위해 설계한다. 규모 문제는 규모라는 행복한 문제를 가졌을 때 풀어라.
• '필수'와 '업계 표준'을 혼동하기: 모든 경쟁사가 기능 X를 가졌다고 해서 당신의 MVP가 핵심 아이디어를 검증하는 데 그것이 필요한 건 아니다. 당신은 완성품을 출시하는 게 아니라 실험을 하는 것이다.
• 모든 예외 경우를 미리 설계하기: 누군가 흔하고 정상적인 경로를 쓰는지 알기도 전에 드물고 이상한 입력을 처리한다. 어떤 예외 경우가 애초에 진짜인지는 실제 사용이 알려주게 하라.
• 완료의 정의가 없음: '끝났다'가 어떤 모습인지 적은 한 줄이 없으면 개발은 결코 끝나지 않는다. 범위 확장은 결승선 없는 프로젝트를 사랑한다.

이 가운데 하나만 막는다면 마지막 것으로 하십시오. 명확하게 적은 완료의 정의——'기술자가 작업의 시간과 부품을 휴대폰에 기록할 수 있고, 사무실이 그것을 즉시 본다'——는 범위를 정직하게 유지하는 가장 강력한 단일 도구입니다. 제안되는 모든 추가는 그 문장에 비춰집니다. 그 문장에 기여하지 않으면, 아무리 좋아도 버전 2 아이디어입니다.

MVP 범위를 정하는 간단한 절차

정리하면, 첫 개발을 시작하기 전에 제가 누구와도 함께 밟을 순서는 이렇습니다. 일부러 로테크입니다——대부분은 방에 개발자가 필요하기 한참 전에, 문서 하나와 정직한 대화로 할 수 있습니다.

1. 1
   핵심 루프에 이름을 붙여라

   문장을 완성하라. '사용자는 ___ 하러 와서, ___ 라면 만족한다.' 못 한다면 아직 범위를 정할 준비가 안 된 것이다——진짜 일이 떠오를 때까지 계속 이야기하라.
2. 2
   모든 기능을 쏟아낸 뒤 분류하라

   머릿속 희망 목록 전부를 종이로 꺼내라. 각 항목을 필수·있으면 좋음·지금은 안 함으로 나눠라. '필수' 목록은 무자비하게 짧게 유지하라.
3. 3
   상자를 고정하라

   기능 목록을 확정하기 전에 예산과 마감을 정하라. 목록을 상자에 맞춰라. 그 반대가 아니다.
4. 4
   완료의 정의를 써라

   작동하는 핵심 루프를 묘사하는 구체적인 한 문장. 이것이 프로젝트 내내 범위 확장에 맞서는 당신의 방패다.
5. 5
   만들고, 출시하고, 지켜보고, 그다음 결정하라

   핵심을 실제 사용자에게 전달하라. 그들이 실제로 무엇을 하는지 지켜보라. 이전의 추측이 아니라 그들의 행동이, '있으면 좋음' 목록에서 다음에 무엇이 내려올지 고르게 하라.

마지막 단계가 당신을 처음으로 되돌린다는 점에 주목하십시오. 좋은 MVP는 일회성 사건이 아니라 바퀴의 첫 회전입니다. 작게 범위를 정하고, 출시하고, 배우며, 배운 것이 다음 개발의 범위를 다시 정합니다. 이기는 팀은 완벽한 제품을 미리 계획한 팀이 아닙니다——아무도 그러지 못합니다. 현실이 아직 그들의 방향을 잡아줄 수 있을 만큼 빨리, 진짜 무언가를 사용자 앞에 내놓은 팀입니다.

자주 묻는 질문