#MVP검증#스타트업창업#린스타트업#초기창업팀#제품검증

MVP를 6주 만에 만들고도 아무것도 검증하지 못한 팀

빠르게 만든 제품이 아니라, 가장 위험한 가정을 가장 싸게 깨보는 단위가 MVP입니다

Draftie·2026년 4월 22일

MVP를 두고 많은 초기 창업팀이 같은 착각을 합니다. ‘완성도는 낮아도 되니 일단 빨리 만들어 출시하자’는 식입니다. 그런데 실제로 막히는 지점은 개발 속도가 아니라, 무엇을 검증해야 하는지가 명확하지 않다는 데 있습니다.

가상의 시나리오로 시작해보겠습니다. 2024년 봄, 3인 팀의 한 초기 스타트업이 중소사업자용 운영 자동화 SaaS를 만들고 있었습니다. 엔지니어 2명, 비즈니스 담당 1명, 런웨이는 7개월 남은 상태였고, 이 팀은 6주 안에 MVP를 출시하기로 정합니다.

문제는 그 6주가 제품을 만드는 시간으로만 채워졌다는 데 있었습니다. 고객의 고통이 충분히 큰지, 지금도 다른 방식으로 해결하고 있는지, 돈을 낼 의사가 있는지 같은 질문은 뒤로 밀렸고, 팀은 ‘출시하면 알 수 있다’고 생각했습니다.

맥락 / 출발점

이 팀이 본 시장은 작지 않았습니다. 국내외를 막론하고 소상공인과 중소사업자를 위한 운영 툴 시장은 늘 커지고 있었고, AI 자동화라는 말도 투자자와 고객 모두에게 익숙해진 시점이었습니다. 적어도 표면적으로는 타이밍도 나쁘지 않았습니다.

당시 창업자는 전 직장에서 반복적인 운영 업무를 많이 겪은 사람이었습니다. 그래서 문제의 존재 자체는 확신했습니다. 실제로 그는 인터뷰 자리에서 “이건 분명 불편하다”는 반응을 15번 넘게 들었다고 말했습니다.

그런데 여기서 흥미로운 건, 팀이 확인한 것은 ‘불편함의 존재’였지 ‘지금 당장 해결해야 하는 고통’은 아니었다는 점입니다. 누군가는 귀찮다고 했고, 누군가는 자동화되면 좋겠다고 했지만, 그 문제 때문에 이미 시간을 쓰거나 돈을 쓰고 있는지는 제대로 묻지 않았습니다.

이 차이는 작아 보이지만 초기에 매우 큽니다. 문제 검증은 “사람들이 공감했다”에서 끝나지 않습니다. 마지막으로 언제 그 문제를 겪었는지, 지금은 무엇으로 버티는지, 그 과정에서 얼마나 손해를 보는지까지 내려가야 비로소 제품을 만들 이유가 생깁니다.

Rob Fitzpatrick의 Mom Test가 강조하는 것도 비슷합니다. 아이디어에 대한 의견을 묻지 말고, 상대의 실제 과거 행동을 물어야 한다는 겁니다. “이런 서비스 쓰실 것 같나요?”보다 “지난달에 이 문제를 어떻게 처리했나요?”가 훨씬 강한 질문인 이유입니다.

하지만 이 팀은 인터뷰에서 좋은 반응을 많이 얻은 뒤, 그걸 곧바로 제품 가설의 증거로 받아들였습니다. 3명이던 팀은 노션에 기능 목록을 27개 적었고, 그중 9개를 MVP 범위로 정했습니다. 이름은 최소 기능 제품이었지만, 실제로는 ‘처음 버전의 축소판’에 가까웠습니다.

결정 / 사건

2024년 5월, 이 팀은 6주 스프린트를 시작했습니다. 첫 주에는 화면 설계, 둘째 주에는 백엔드 구조, 셋째 주부터는 자동화 규칙 엔진을 붙였습니다. 고객에게서 가장 자주 들었다고 생각한 요청을 기능으로 옮긴 셈입니다.

팀 입장에서는 나름대로 합리적인 선택이었습니다. 고객 인터뷰를 이미 했고, 시장도 커 보였고, 경쟁사보다 더 단순한 제품을 만들면 빠르게 반응을 볼 수 있다고 믿었습니다. 게다가 엔지니어 2명이 있는 팀에서는 ‘뭔가 만드는 것’이 가장 익숙한 행동이기도 했습니다.

하지만 그들이 포착한 신호는 대부분 미약한 수준이었습니다. “좋을 것 같다”, “있으면 써볼 것 같다”, “업무가 편해질 것 같다” 같은 말은 제품 팀에게는 달콤하지만, 결제나 전환으로 이어지는 신호는 아닙니다. 특히 초기에는 호의와 수요를 자주 헷갈립니다.

이 시점에서 다시 정의해야 했던 것은 기능 범위가 아니라 검증 단위였습니다. 이 팀의 가장 위험한 가정은 ‘자동화 기능을 잘 만들 수 있는가’가 아니었습니다. 더 앞단에 있는 질문, 즉 ‘이 문제가 충분히 아픈가’, ‘누가 가장 먼저 돈을 낼 만큼 급한가’가 먼저였습니다.

YC 파트너였던 Michael Seibel이 여러 차례 말한 취지도 여기에 가깝습니다. MVP는 작은 제품이 아니라 가장 위험한 가정을 테스트하는 최소한의 도구라는 겁니다. 그래서 어떤 경우에는 코드보다 랜딩페이지가, 앱보다 수동 서비스가 더 좋은 MVP가 됩니다.

예를 들어 이 팀이 정말 먼저 봤어야 했던 건 세 가지였습니다. 첫째, 특정 업종의 운영 담당자가 이 문제를 매주 겪는가. 둘째, 이미 엑셀이나 외주, 아르바이트 인력으로 비용을 태우고 있는가. 셋째, 자동화가 되면 실제로 예산을 옮길 의사가 있는가.

그런데 팀은 이 질문을 인터뷰와 결제 실험으로 확인하는 대신, 기능 구현으로 건너뛰었습니다. 6주 동안 만든 것은 로그인, 대시보드, 규칙 설정, 알림, 리포트였고, 정작 고객 10명에게 사람이 직접 대신 처리해주며 문제의 강도를 보는 실험은 하지 않았습니다. Paul Graham이 말한 ‘스케일 안 되는 일을 해라’와는 반대 방향이었던 셈입니다.

여기서 벌어진 오해는 단순합니다. 팀은 MVP를 ‘최소 기능 제품’으로 이해했고, 그래서 기능을 줄이는 데만 집중했습니다. 하지만 실제로는 ‘최소한의 검증 도구’로 봤어야 했습니다. 제품이 아니라 질문이 먼저였고, 질문마다 필요한 형태가 달랐습니다.

문제를 검증할 때는 인터뷰 스크립트와 수동 대행이 더 적합할 수 있습니다. 지불 의향을 검증할 때는 가격 대화와 선결제 제안이 더 직접적입니다. 사용 흐름을 검증할 때는 프로토타입이나 노코드 화면이면 충분할 때가 많습니다.

결과

6주 뒤 제품은 출시됐습니다. 첫 달 동안 팀은 네트워크를 통해 38명을 데모로 모았고, 그중 19명이 가입했습니다. 숫자만 보면 나쁘지 않아 보였습니다. 내부적으로도 “초기 반응은 있다”는 분위기가 생겼습니다.

그런데 활성 사용자는 빠르게 줄었습니다. 2주 후 주간 활성 사용자는 6명 수준으로 내려갔고, 한 달 안에 반복 사용자는 3곳만 남았습니다. 더 뼈아픈 건, 남은 고객조차 자동화를 완전히 신뢰하지 않고 일부 기능만 시험적으로 썼다는 점이었습니다.

이유를 다시 물어보자 답은 선명했습니다. 어떤 고객은 “가끔 있으면 좋지만 지금은 손으로 해도 된다”고 했고, 다른 고객은 “문제는 맞는데 우리 팀은 아직 예산을 못 쓴다”고 했습니다. 또 몇 곳은 “이 기능보다 먼저 데이터 정리가 필요하다”고 말했습니다.

즉 제품이 느려서가 아니라, 검증 순서가 어긋났던 겁니다. 팀은 솔루션을 먼저 내놓고 문제 강도를 뒤늦게 확인했습니다. 그 결과 6주 동안 확인한 것은 ‘우리가 이런 제품을 만들 수 있다’는 사실뿐이었고, ‘고객이 지금 반드시 원한다’는 사실은 여전히 비어 있었습니다.

이 지점에서 많은 팀이 잘못된 해석을 합니다. “기능이 부족했나 보다”, “온보딩이 약했나 보다”, “UI를 더 다듬어야겠다”라고 생각하는 겁니다. 물론 그럴 수도 있습니다. 하지만 초기에는 제품 완성도보다 앞서, 문제의 우선순위가 고객의 머리 속에서 얼마나 높은지가 더 큰 변수인 경우가 많습니다.

그래서 두 번째 실험은 완전히 달라졌습니다. 이 팀은 기능 개발을 3주 멈추고, 특정 업종 두 곳만 좁혀서 다시 들어갔습니다. 미용실 체인 운영자 8명, 소규모 커머스 셀러 11명과 인터뷰를 했고, “마지막으로 이 업무를 처리한 날짜”, “그때 걸린 시간”, “대체 수단”, “월 예산”만 집요하게 물었습니다.

그 결과 뜻밖의 차이가 드러났습니다. 미용실 운영자는 이 문제를 불편하다고 느꼈지만 빈도는 낮았습니다. 반면 소규모 커머스 셀러는 주 3~5회 반복적으로 겪고 있었고, 이미 아르바이트나 외주, 각종 툴 구독료로 비용을 내고 있었습니다.

그제야 제품 방향이 바뀌었습니다. 팀은 범용 자동화 SaaS라는 큰 그림을 접고, 커머스 셀러의 반복 운영 업무 한 가지에만 집중했습니다. 기능도 9개에서 2개로 줄였고, 첫 5개 고객에게는 소프트웨어 대신 창업자가 직접 세팅과 운영을 도왔습니다.

결과적으로 전환율은 오히려 높아졌습니다. 데모 요청 수는 줄었지만, 상담 후 실제 사용으로 이어지는 비율은 높아졌고, 유료 전환도 그제야 생겼습니다. 처음 MVP보다 두 번째 MVP가 더 작았지만, 학습량은 훨씬 컸던 이유가 여기에 있습니다.

교훈

첫째, MVP는 제품의 축소판이 아니라 가설 검증의 최소 단위로 봐야 합니다. 무엇을 만들지보다 먼저 무엇을 틀릴 수 있는지 정해야 합니다. 가장 위험한 가정이 문제 강도라면 인터뷰와 수동 실험이 MVP이고, 사용 흐름이 의심되면 프로토타입이 MVP입니다.

둘째, 문제 검증과 솔루션 검증을 섞으면 학습이 흐려집니다. 고객이 문제를 느끼는지, 그 문제를 자주 겪는지, 이미 대가를 치르고 있는지부터 확인해야 합니다. 이 셋이 비어 있으면 좋은 제품 피드백도 쉽게 착시가 됩니다.

셋째, 초기 스타트업에서 속도는 개발 속도만 뜻하지 않습니다. 잘못된 질문으로 6주를 보내는 팀보다, 올바른 질문으로 10일 안에 가설 하나를 깨는 팀이 더 빠릅니다. Ash Maurya가 말한 ‘validation drift’도 바로 이런 상황을 가리킵니다. 리서치를 오래 하는 것만이 아니라, 학습이 안 되는 활동을 계속하는 것도 표류입니다.

넷째, 돈 이야기는 생각보다 일찍 나와야 합니다. YC 쪽 조언처럼 가격 탐색 중이라고 솔직히 밝히고, 현재 대안에 얼마를 쓰는지 물어보면 공손한 칭찬과 실제 수요를 구분하기 쉬워집니다. “좋아요”보다 “예산이 있습니다”가 훨씬 무거운 신호입니다.

다섯째, 초기 스타트업일수록 넓은 시장보다 좁은 반복 문제를 붙잡아야 합니다. 모두가 겪는 애매한 불편보다, 소수라도 매주 겪고 이미 비용을 치르는 문제 쪽이 첫 고객을 만들 가능성이 높습니다. ICP를 좁히는 일이 답답해 보여도, 실제로는 검증 속도를 가장 많이 올립니다.

이 사례의 교훈은 단순합니다. MVP를 빨리 만드는 팀이 아니라, 무엇을 검증해야 하는지 먼저 쪼개는 팀이 더 빨리 배웁니다. 초기에 필요한 것은 작은 제품이 아니라, 더 작은 질문입니다.

참고한 문헌 링크

투자/지원사업 제출 전 전략 점검

드래프티로 전략의 빈틈을 미리 확인하세요

투자자와 심사위원이 가장 먼저 질문할 가정을 제출 전에 점검할 수 있습니다.

무료로 시작하기 →

← 블로그 목록으로