MVP의 90%는 가짜다, 진짜 MVP의 정의

M(Minimum)이 아니라 V(Viable)가 책 전체의 운명을 결정한다.

6개월 매달려 출시했지만 망한 배달앱

어느 배달 플랫폼 스타트업 이야기입니다. 창업팀이 자신 있게 "MVP를 만들겠다"고 선언한 후 6개월을 일했어요. 결제 시스템, 리뷰 시스템, 쿠폰 시스템, 추천 알고리즘까지 모두 갖춘 후에야 출시했습니다. "완벽한 MVP"라고 생각했죠.

그런데 시장에 나가 보니 문제가 터졌어요. 음식점 사장님들과 고객을 연결한다는 가장 기본적인 가치조차 검증하지 못한 채로 넘어갔던 거예요. 결국 그 팀은 이미 너무 늦었습니다.

이 챕터를 읽고 나면 당신이 지금 만들려는 것이 "진짜 MVP"인지, 아니면 "MVP인 척하는 완성품"인지 정확히 진단할 수 있게 될 거예요.

"최소"의 함정, 기능이 아니라 검증이다

MVP를 처음 만들 때 사람들은 거의 항상 같은 실수를 합니다. "M(Minimum)"에만 집중하는 것이에요. "가장 적은 기능으로", "가장 빠르게", "가장 싸게"라는 목표가 먼저 생깁니다. 그래서 스프레드시트를 펼쳐 놓고 "사용자가 정말 필요한 기능은 뭘까?"가 아니라 "5개 기능으로 충분할까, 10개까지는 괜찮을까?"라는 질문을 하게 돼요.

Eric Ries는 The Lean Startup에서 MVP를 이렇게 정의했습니다.

"최소한의 노력으로 최대한의 검증 학습을 얻을 수 있는 제품의 버전."

핵심은 "기능의 개수"가 아니라 "학습"입니다. 당신이 정말 확인해야 하는 건 "사람들이 이걸 사용할까?"예요. 기능 5개든 20개든 상관없습니다. 그 기능들이 정말로 당신이 확인해야 할 가설을 검증하는가가 중요합니다.

기능이 적으면 MVP가 아니라 "불완전한 제품"이 됩니다. 기능이 많아도 핵심 가치를 검증하지 못하면 "완성도 높은 낭비"일 뿐이에요.

MVP vs 베타 vs 프로토타입, 경계를 명확히

이 셋은 자주 섞여 쓰이지만, 다른 목적, 다른 대상, 다른 시점을 가지고 있어요.

당근마켓의 초기 MVP를 보세요. 요청하기, 제안 받은 매물 확인하기, 이 두 가지 기능만으로 시작했어요. 나머지는 정말 수작업으로 이루어졌습니다. 중개사무소에 전화를 돌렸어요. 매칭 로직? 없었어요. 그냥 사람이 했어요. 예쁜 UI? 없었어요. 카카오톡으로 문의를 받고 처리했어요.

하지만 이게 진짜 MVP였던 이유는 "사람들이 본인 의도(매물 요청)를 등록하고, 매물을 받는다"는 핵심 가치를 검증할 수 있었기 때문입니다.

좋은 MVP의 4가지 조건

1. 핵심 가설이 명확하다

"사람들이 우리 서비스를 쓸까?"는 너무 커요. "서울 25~35세 직장인이 점심시간에 5분 안에 주문 가능한 간편식을 매주 2회 이상 구매할까?"처럼 구체적이어야 합니다.

토스의 초기 가설은 "기존 은행앱보다 10배 빠르게 송금할 수 있다면 사람들이 쓸까?"였어요. 그래서 송금 하나만 완벽하게 만들었습니다. 나머지는 버튼도 없었어요.

2. 사용자가 실제 문제를 해결받는다

"우리 아이디어가 답이구나"라고 느껴야 해요. 그게 무료든 유료든, 완벽하든 70% 완성도든 상관없어요. 당근마켓 사용자는 "이 앱으로 정말 매물을 찾을 수 있네?"라고 느꼈어요. 그게 MVP 성공의 신호였습니다.

3. 측정 가능하다

사용자가 정말 문제를 느꼈는지 어떻게 알죠? 숫자로요. 회원 수, 활성 사용자, 구매 횟수, 재방문율 같은 것들요. "좋은 피드백을 받았어요"는 측정이 아닙니다. 입은 거짓말을 하지만, 손가락은 거짓말을 못 합니다. 앱을 다시 켰는가, 구매했는가, 친구에게 추천했는가, 이게 증거예요.

4. 가설이 틀렸을 때 빠르게 방향을 바꿀 수 있다

6개월을 들여 만들었다면? 너무 투자가 크면 "이게 잘못됐나?"라는 의심이 들어도 방향을 못 바꿔요. 심리적으로도 금전적으로도요. 반면 2주 만에 만들었다면 "아, 이건 아니네" 하고 다음 아이디어로 넘어갈 수 있어요. 첫 번째 MVP가 성공할 확률은 매우 낮습니다.

피해야 할 잘못된 MVP 패턴 3가지

패턴 1: MVP인 척하는 완성품

위에 나온 배달 플랫폼처럼요. "사실은 완성품을 만들고 싶은데 MVP라고 부르자"는 심리입니다. 보통 "이건 실제 사용자를 받을 제품이니까 완벽해야 해"라고 정당화해요.

회복법: 지금 당신이 만드는 것에서 "꼭 필요 없는 기능 3개"를 지워보세요. 카카오톡으로 고객 지원을 한다고 해도 괜찮은가? 자동화 알고리즘 없이 수작업으로 시작해도 괜찮은가?

패턴 2: 너무 작은 MVP

반대 극단도 있어요. 프로토타입 수준으로 만들고 "이게 MVP입니다"라고 합니다. 사용자가 실제 문제를 해결받지 못하는 수준이에요. 그럼 피드백이 없거나, "더 만들어줘"라는 요청만 나옵니다. 그건 시장 신호가 아니에요.

회복법: "사용자가 이걸로 정말 내 문제를 풀 수 있을까?" 안 된다면 뭐가 더 필요한지 적어보기.

패턴 3: 측정을 하지 않는 MVP

가장 흔합니다. MVP를 만들고 출시했는데 데이터를 안 본다는 뜻이에요. 사용자 피드백 두세 명의 의견을 기준으로 다음 방향을 정합니다.

회복법: MVP 출시 전에 "어떤 지표를 볼 건가?"를 미리 정하기. Google Analytics 설정, 가입 데이터, 활성 사용자 추적, 재구매율 같은 것들요.

체크리스트, 내 아이디어가 진짜 MVP인가?

다음 10개 질문에 답해 보세요. "예"가 7개 이상이면 진짜 MVP입니다.

1. 내 핵심 가설이 한 문장으로 정의되어 있는가?
2. 이 가설을 검증하는 데 꼭 필요한 기능이 명확한가?
3. 사용자가 이 기능만으로도 실제 문제를 풀 수 있는가?
4. 개발 예상 시간이 8주 이내인가? (이상적으로는 2~4주)
5. 사용자가 처음 5분 안에 "아, 이게 내 문제를 푸는구나"라고 느낄 수 있는가?
6. 수작업, 카카오톡 고객 지원 같은 걸 써도 괜찮은가?
7. 가설이 틀렸을 때 다음 MVP로 빠르게 넘어갈 심리적 준비가 되어 있는가?
8. 출시 후 측정할 핵심 지표 3가지를 정했는가?
9. 외부인(고객)이 이걸 써봤을 때 피드백을 받았는가?
10. 지난 주에 "꼭 필요 없는 기능"을 3개 이상 지웠는가?

마무리

M(Minimum)이 덫이고, V(Viable)가 핵심이라는 걸 이제 알았어요. 그럼 다음 질문이 생깁니다. "그래서 뭘 만들어야 하는데?" 아이디어는 많은데 무엇을 선택할 건가요? 다음 편에서는 당신의 아이디어를 진단하는 5가지 질문 프레임워크를 소개합니다. "만들 수 있는가"가 아니라 "1년 매달릴 수 있는가"를 묻는 거예요. MVP의 성공은 제품이 아니라 당신의 끈기에서 나오니까요.

이전 편: 왜 지금, 당신이 MVP를 만들어야 하는가 (14일 메이커 시대)
다음 편: 무엇을 만들지 결정하는 5가지 질문 (지속 가능성 체크)

김민철, 프리아이브 CEO, 페일스쿨