MVP를 줄인다고 되는 게 아닙니다, 버릴 가설이 줄어들어야 합니다

많은 팀이 MVP를 이야기할 때 화면 수부터 셉니다. 회원가입은 넣을지, 대시보드는 뺄지, 관리자 기능은 나중으로 미룰지 같은 얘기요.

그런데 저는 초기에 MVP를 볼 때 기능보다 먼저 가설 목록을 봅니다. 이 팀이 지금 무엇을 믿고 있고, 그중 무엇을 이번 주에 버릴 수 있는가를 먼저 묻습니다.

보통 MVP를 ‘최소 기능 제품’이라고 부르지만, 실제 운영에서는 조금 다르게 작동합니다. MVP는 기능 집합이 아니라, 팀이 폐기 가능한 가설의 범위에 더 가깝습니다.

이 차이가 왜 크냐면요. 기능 기준으로 움직이는 팀은 자꾸 “무엇을 넣을까”를 논의하고, 가설 기준으로 움직이는 팀은 “무엇이 틀렸는지 언제 알까”를 논의하게 되거든요.

(저는 이 질문 하나만 바꿔도 회의 공기가 달라지는 걸 자주 봤습니다. 피그마 리뷰가 아니라, 믿음 검토 회의가 됩니다.)

초기 스타트업에서 더 위험한 건 기능이 적은 제품이 아닙니다. 틀린 믿음을 오래 붙잡는 팀입니다.

기능을 줄였는데도 왜 배움은 느릴까요

예를 들어 3명짜리 초기 SaaS 팀이 있다고 해보겠습니다. 대표 1명, 개발자 1명, 디자이너 1명이고, 타깃은 20인 이하 마케팅 에이전시입니다.

이 팀은 4주 동안 ‘아주 작은’ 캠페인 리포트 툴을 만들었습니다. 광고 채널 연결, 주간 리포트 자동 생성, PDF 다운로드까지만 넣었죠.

겉으로 보면 충분히 MVP 같습니다. 그런데 4주 뒤 고객 인터뷰 11건을 해보니 실제로 가장 자주 나온 말은 이거였습니다. “리포트 생성보다 고객별 지표 정의가 매번 달라서 검수하는 데 2시간씩 걸려요.”

팀은 자동 생성 기능을 줄여서 만들었지만, 정작 버려야 할 가설은 못 건드린 겁니다. 고객이 진짜 원하는 건 ‘빠른 출력’이 아니라 ‘맞는 기준으로 정리된 결과’였던 거죠.

저는 이런 경우에 제품이 너무 컸다고 보지 않습니다. 오히려 검증 단위가 너무 컸다고 봅니다. 4주 동안 확인한 게 한 번뿐이니까요.

같은 팀이 다르게 움직일 수도 있습니다. 1주차에는 랜딩페이지로 “리포트 자동화”와 “고객별 맞춤 검수 제거” 중 어떤 문구에 반응이 오는지 보고, 2주차에는 창업자가 실제 광고 계정 CSV를 받아 수동으로 정리해주고, 3주차에는 월 19만 원 가격 얘기를 꺼내는 식이죠.

이 경우엔 코드가 적어서가 아니라, 버릴 수 있는 가설이 많아서 빨라집니다. 누가 더 아픈지, 어떤 결과물을 원했는지, 돈 얘기에서 표정이 바뀌는지까지 짧게 확인할 수 있으니까요.

초기 MVP의 최소 단위는 기능이 아니라 반증 가능한 믿음 하나입니다.

제가 먼저 적어보는 가설은 보통 4가지입니다

질문은 단순합니다. 이 제품이 왜 될 거라고 믿는가. 이걸 쓰는 사람들은 대체 어디에서, 어떤 불편 때문에, 얼마를 잃고 있는가.

여기서 저는 가설을 대충 쓰지 않습니다. “고객이 불편해할 것이다”처럼 흐리게 적으면 나중에 다 맞는 말이 되어버리거든요.

예를 들면 이렇게 씁니다. “10명 이상 채용 중인 스타트업의 채용담당자는 면접 일정 조율 때문에 후보자 1명당 20분 이상을 쓴다.” 혹은 “세무 대행사를 쓰는 1인 법인 대표는 월말 증빙 정리에 최소 90분을 쓴다.” 이런 식입니다.

린 스타트업 관점에서도 가정은 검증 가능한 형태여야 의미가 있습니다. Lean Startup Method와 Validated Learning 관련 자료들이 반복해서 강조하는 것도 결국 같은 얘기입니다. 막연한 믿음이 아니라, 틀릴 수 있는 문장으로 바꾸라는 거죠.

제가 자주 나누는 가설은 대체로 네 갈래입니다.

첫째는 누가 제일 아픈가입니다. 모두가 아니라, 지금 가장 자주 문제를 겪는 한 무리를 잡아야 합니다.

둘째는 그들이 지금 어떻게 버티는가입니다. 엑셀인지, 카톡인지, 외주인지, 인턴의 손노동인지. 현재 대안이 보여야 진짜 문제 강도가 보입니다.

셋째는 왜 지금 사야 하는가입니다. “좋아 보이네요”와 “이번 달 안에 써야겠네요”는 완전히 다른 신호입니다.

넷째는 돈을 누구 예산에서 꺼내는가입니다. 팀장 개인 카드인지, 부서 운영비인지, 대표 결재인지에 따라 검증 방식이 달라집니다.

이 네 가지 중 하나라도 흐리면 MVP가 곧 기능 논의로 미끄러집니다. 그러면 제품은 점점 그럴듯해지는데, 사업은 점점 안개 속으로 들어가요.

(이때 창업자는 이상하게 더 바빠집니다. 많이 만들었는데 더 모르겠는 상태가 오거든요.)

많이 만들수록 더 많이 배우는 건 아닙니다

흔한 오해가 하나 있습니다. 기능이 많아야 고객 반응에서 더 많은 힌트를 얻을 수 있다는 생각이요.

실제로는 종종 반대입니다. 많이 만들수록 틀렸을 때 버리기 어려워집니다. 이미 5주를 썼고, 화면 18개를 그렸고, API도 붙였으니 사람 마음이 거기 매달리게 되죠.

그래서 저는 초기에 “무엇을 출시할까”보다 “무엇을 포기할 준비가 되어 있나”를 봅니다. 이게 뒤집히는 지점입니다. MVP는 완성의 출발점이 아니라, 포기의 설계도에 더 가깝습니다.

First Round의 Minimum Viable Testing 글도 비슷한 결을 갖고 있습니다. 제품처럼 보이는 무언가를 만드는 것과, 특정 가정을 정확히 찔러보는 테스트는 다르다는 얘기죠.

예를 들어 AI 회의록 서비스를 만드는 팀이 있다고 해보겠습니다. 이 팀이 처음부터 녹음, 화자 분리, 요약, 액션아이템 추출, 노션 연동까지 넣었다고 해보죠.

그런데 실제 유료 전환 미팅 8번에서 반복된 질문은 “보안 때문에 외부 업로드가 안 되는데, 사내 녹취 파일만 올려도 되나요?”였을 수 있습니다. 그러면 검증해야 할 1순위는 요약 품질이 아니라 배포 방식과 보안 제약이었던 겁니다.

이 팀이 처음 10일 동안 했어야 할 건 화려한 기능 묶음이 아니라, 보안 정책이 다른 5개 회사와 파일 반입 방식 테스트를 해보는 일이었을 겁니다.

초기 스타트업은 정답을 더하는 팀보다, 오답을 빨리 삭제하는 팀이 유리합니다.

그럼 무엇을 먼저 버려야 할까요

저는 보통 위험한 순서대로 봅니다. 원하는가, 지금도 불편한가, 돈 낼 만큼 급한가, 우리가 기술적으로 만들 수 있는가.

많은 팀은 마지막 질문부터 들어갑니다. 만들 수 있느냐는 내부에서 통제 가능하니까요. 그런데 초기에 제일 비싼 실패는 기술 실패보다 수요 실패입니다.

Michael Seibel이 여러 인터뷰에서 말하듯, MVP는 가장 위험한 가정을 검증하는 최소한의 수단이어야 합니다. 랜딩페이지든, 수동 서비스든, 스프레드시트든 상관없고요.

예를 들어 여러분이 월 49만 원짜리 재고 예측 SaaS를 판다고 해보겠습니다. 먼저 버려야 할 가설은 “예측 정확도를 5% 높이면 산다”가 아닐 수 있습니다.

실제로는 “재고팀장이 이 문제를 자기 KPI로 느끼는가”, “ERP 연동 없이는 아예 검토 대상이 아닌가”, “월 49만 원을 팀장 선에서 결재할 수 있는가”가 더 앞에 옵니다. 이 셋 중 하나가 틀리면 모델 성능을 올려도 구매는 안 일어납니다.

그래서 인터뷰 질문도 달라집니다. “이 기능 쓰실 것 같아요?”보다 “마지막으로 이 문제를 처리한 날이 언제였어요?”가 낫습니다. Mom Test가 강조하는 것도 상대의 미래 의견보다 과거 행동을 들으라는 쪽이죠.

저는 가격 질문도 초반에 피하지 않는 편입니다. “아직 가격 탐색 중인데, 지금 이 문제 때문에 쓰는 시간이나 비용이 어느 정도예요?”라고 물으면 의외로 많은 게 드러납니다.

누군가는 “한 달에 3시간 정도라 굳이 돈 낼 정도는 아니에요”라고 말하고, 누군가는 “주 2번씩 팀장 둘이 붙어서 처리해서 인건비가 더 커요”라고 답합니다. 후자 쪽이 훨씬 진한 신호죠.

초기 팀에서 자주 보이는 위험 신호

아래 항목은 체크리스트처럼 살펴보세요. 세 개 이상 해당된다면, MVP가 검증 도구가 아니라 작은 본제품처럼 굴러가고 있을 가능성이 큽니다.

• 다음 배포 일정은 정해져 있는데, 다음에 버릴 가설은 정해져 있지 않다
• 고객 인터뷰 메모보다 기능 명세서가 더 길다
• “이건 나중에 필요할 것 같아서”라는 말이 자주 나온다
• 창업자가 최근 2주 안에 고객 5명 이상과 직접 대화하지 않았다
• 수동으로 먼저 해볼 수 있는데도 자동화를 먼저 만든다
• 가격 얘기를 꺼내기 전까지 무료 반응만 긍정 지표로 본다

한 가지씩 보면 별일 아닌 것 같아도, 겹치기 시작하면 공통된 문제가 드러납니다. 팀이 제품을 만들고 있는 게 아니라, 자기 가설을 보호하고 있는 상태라는 겁니다.

GeekNews에 소개된 스타트업 사후 분석 사례들을 봐도 비슷한 패턴이 반복됩니다. 시장의 지불 의향, 전환 속도, 거래 구조 같은 더 앞단의 가정이 흔들리는데, 제품 실험은 뒤늦게 따라가는 경우가 많습니다.

제가 초기에 더 믿는 건 작은 제품이 아니라 작은 확신입니다

초기 스타트업이 할 일은 정답을 증명하는 것보다 틀린 믿음을 빠르고 싸게 버리는 데 가깝습니다.

MVP를 기능 수로 정의하면 팀은 자꾸 덜 만들려고 합니다. 하지만 가설 수로 정의하면 팀은 더 빨리 배우려고 하게 됩니다.

그 차이는 꽤 큽니다. 전자는 출시 자체가 목표가 되고, 후자는 배움과 판단이 목표가 됩니다. 전자는 제품만 남기고, 후자는 통찰을 남깁니다.

그래서 저는 MVP 문서를 볼 때 마지막 줄에 이것이 적혀 있으면 안심이 됩니다. “이번 실험이 끝나면, 우리는 어떤 믿음을 버릴 수 있어야 하는가.”

그 문장이 없으면 MVP는 대개 작아진 제품이고, 그 문장이 있으면 비로소 학습 도구가 됩니다. 초기 스타트업에 필요한 건 완성도보다, 틀린 믿음을 과감히 버릴 수 있는 판단력에 더 가깝습니다.

지금 만들고 있는 MVP가 있다면 기능 목록 옆에 가설 폐기 목록도 같이 적어보세요. 저는 그 순간부터 비로소 제품이 아니라 사업이 움직이기 시작한다고 봅니다.

참고한 문헌 링크

• Lean Startup: Unlocking Rapid, Validated Growth
• The Lean Startup Method 101: The Essential Ideas
• Testing Hypotheses Using the Validated Learning Approach — Capital Innovators
• The Minimum Viable Testing Process for Evaluating Startup Ideas
• 스타트업 사후 분석 (Postmortem) | GeekNews
• MVP 출시 과정과 실사례들 — 어들의 세상, 세상의 어들
• The Ultimate Startup Guide With Statistics (2024–2025)