#MVP전략#스타트업학습#린스타트업#제품개발#창업초기

MVP를 작게 만드는 팀보다, 빨리 배우는 팀이 먼저 맞습니다

MVP는 기능 목록이 아니라, 팀이 얼마나 빨리 틀리고 바로잡는지를 결정하는 리듬에 가깝습니다.

Draftie·2026년 5월 11일

MVP를 이야기하면 보통 기능부터 셉니다. 로그인은 넣을지, 결제는 뺄지, 관리자 페이지는 나중으로 미룰지 같은 얘기요.

그런데 저는 MVP를 볼 때 기능표보다 먼저 다른 걸 봅니다. 이 팀이 한 번 배우는 데 며칠이 걸리는가입니다.

보통 MVP를 ‘최소 기능 제품’이라고 생각합니다. 저는 오히려 반대로 느낍니다. MVP는 작은 제품이라기보다, 팀의 학습 속도를 고정해버리는 운영 단위에 더 가깝습니다.

(이 차이를 한 번 체감하면 회의 방식부터 달라집니다. 기능 우선순위 회의가 아니라, 학습 주기 회의가 되거든요.)

문제는 많은 팀이 제품을 작게 만들면서도 학습은 느리게 한다는 데 있습니다. 겉으로는 MVP인데, 실제로는 6주짜리 작은 폭포수 개발인 경우가 정말 많습니다.

그래서 출시하고 나서도 남는 질문이 똑같습니다. 누가 진짜 아파하는지, 왜 지금 안 쓰는지, 이걸 돈 내고 쓸 만큼 급한지. 만들었는데도 가장 중요한 걸 모르는 거죠.

MVP가 작아도 학습이 느릴 수 있나요

네, 아주 자주 그렇습니다.

예를 들어 4명 팀이 있다고 해보겠습니다. 대표 1명, 개발자 2명, 디자이너 1명으로 구성된 초기 SaaS 팀이요. 이 팀이 5주 동안 ‘정말 최소한’의 협업 툴을 만들었습니다. 작업 생성, 담당자 지정, 댓글, 알림까지만 넣었죠.

겉으로 보면 충분히 MVP 같습니다. 그런데 막상 5주 뒤에 첫 고객 7명을 만나보니, 고객들이 가장 불편해한 건 작업 관리가 아니라 주간 보고서 취합이었습니다. 팀은 가장 큰 문제를 검증하지 못한 채, 상대적으로 덜 아픈 부분을 예쁘게 만든 셈입니다.

이럴 때 제가 묻는 건 하나입니다. 왜 5주가 걸렸냐는 게 아니라, 왜 5주 동안 배움이 1번뿐이었냐는 겁니다.

같은 기간에 다른 팀은 전혀 다르게 움직일 수 있습니다. 1주차에는 노코드 랜딩페이지로 메시지 반응을 보고, 2주차에는 창업자가 직접 슬랙으로 요청을 받아 수동으로 결과물을 전달하고, 3주차에는 돈 얘기를 꺼내고, 4주차에는 반복 요청만 제품화하는 식이죠.

MVP의 최소 단위는 기능이 아니라 학습 사이클입니다.

이 관점이 빠지면 팀은 늘 비슷한 실수를 합니다. 작게 만들었다고 안심하지만, 실제로는 큰 배치를 한 번 던지고 결과를 기다리는 식으로 움직입니다. 그건 린해 보일 뿐, 운영은 무겁습니다.

문제 검증은 출시 후가 아니라, 만들기 전부터 시작됩니다

많은 창업자가 “일단 만들어서 반응을 보자”라고 말합니다. 맞는 말 같지만, 절반만 맞습니다.

왜냐하면 문제 검증의 첫 단계는 제품 사용 반응이 아니라, 사람이 자기 시간을 내서 문제를 자세히 말하느냐이기 때문입니다. 아직 제품도 없는데 30분 통화를 잡아주고, 최근 2주 안에 겪은 불편을 화면 공유로 보여주고, 지금 쓰는 엑셀 파일이나 우회 방법까지 보여준다면 그건 꽤 강한 신호입니다.

Rob Fitzpatrick의 Mom Test가 강조하는 것도 비슷합니다. 아이디어에 대한 칭찬을 받지 말고, 상대의 실제 과거 행동을 들으라는 거죠. “이거 쓰실 것 같아요?”보다 “마지막으로 이 문제를 처리한 게 언제였어요?”가 훨씬 낫습니다.

제가 예전에 본 팀 하나는 채용 운영 툴을 만들고 싶어 했습니다. 처음엔 지원자 평가 기능을 넣으려 했는데, 인터뷰 12건을 해보니 현업 리드들이 진짜 힘들어한 건 평가가 아니라 면접 일정 조율이었습니다. 구글 캘린더, 메일, 카카오톡, 노션을 오가며 하루에 40분씩 날리고 있었거든요.

그래서 그 팀은 방향을 바꿨습니다. 첫 버전은 평가 시스템이 아니었습니다. 채용담당자가 후보자 1명 정보를 보내면, 창업자가 직접 면접관 3명의 가능 시간을 맞춰주는 반수동 서비스였죠. 10일 동안 18건을 처리했고, 그중 6개 회사가 “이거 자동화되면 월 30만 원은 낼 수 있다”고 말했습니다.

여기서 중요한 건 코드 양이 아닙니다. 가장 위험한 가정을 먼저 건드렸느냐입니다. 원하는가, 지금도 불편한가, 돈 낼 만큼 급한가. 이 순서가 흐려지면 MVP는 금방 기능 백로그로 변합니다.

학습 속도가 느린 팀은 보통 이렇게 움직입니다

흔한 오해가 하나 있습니다. 많이 만들수록 더 많이 배울 거라는 생각이요.

실제로는 반대인 경우가 많습니다. 많이 만들수록, 한 번 틀렸을 때 버려야 할 게 많아집니다. 그러면 팀은 데이터를 보기도 전에 자기 결정을 방어하게 됩니다. 이미 4주를 썼고, 디자이너가 화면 27개를 그렸고, 개발자가 API를 다 붙였으니까요. 사람 마음이 원래 그렇습니다.

(여기서부터 회의 공기가 미묘해집니다. 검증 회의가 아니라, 지난 3주를 정당화하는 회의가 되기 쉬워요.)

예를 들어 B2B 리포팅 SaaS를 만드는 3명 팀이 있다고 해보죠. 이 팀은 첫 달에 대시보드, 권한 관리, CSV 업로드, 알림 설정까지 넣었습니다. 그런데 실제 고객 미팅 9번 중 7번에서 나온 질문은 딱 하나였습니다. “그래서 우리 ERP에서 데이터 자동으로 가져와지나요?”

정작 고객의 구매 기준은 연동 가능성이었는데, 팀은 보기 좋은 화면을 먼저 만든 겁니다. 학습 속도가 느린 팀은 이런 식으로 ‘만들기 쉬운 것’과 ‘검증해야 하는 것’을 자꾸 바꿔치기합니다.

느린 팀의 공통점은 개발 속도가 아니라 질문 속도가 느리다는 데 있습니다.

질문이 느리다는 건 이런 뜻입니다. 누가 제일 아픈지 묻는 데 2주, 지금 대안을 어떻게 쓰는지 묻는 데 1주, 돈 얘기를 꺼내는 데 또 2주가 걸립니다. 제품은 계속 나오는데, 판단은 늦어집니다.

반대로 빠른 팀은 기능이 없어도 질문을 빨리 던집니다. 이번 주엔 메시지가 먹히는지, 다음 주엔 수동 전달이 반복되는지, 그다음 주엔 유료 전환 의사가 있는지. 팀 운영이 질문 중심으로 짜여 있습니다.

제가 보는 위험 신호들

초기 팀에서 아래 항목이 3개 이상 보이면, 대체로 MVP가 제품이 아니라 프로젝트로 굴러가고 있을 가능성이 높습니다.

다음 배포 날짜는 있는데, 다음 학습 질문은 없다
고객 인터뷰 메모보다 피그마 파일이 더 길다
“이 기능은 나중에 필요해질 것 같아서”가 자주 나온다
창업자가 최근 2주 안에 고객 5명 이상과 직접 대화하지 않았다
유저 반응을 보기 전에 내부 QA와 예외 처리부터 길게 붙는다
무료 사용자는 늘었는데, 누가 왜 남는지는 설명하지 못한다

이건 실행력이 부족해서가 아닙니다. 오히려 실행력이 좋아서 생기는 문제일 때가 많습니다. 만드는 힘이 세니까, 배우기 전에 먼저 만들어버리는 거죠.

운영 단위로서의 MVP는 팀 리듬을 바꿉니다

저는 MVP를 설계할 때 기능 목록보다 먼저 주기를 정합니다. 며칠마다 가설 하나가 죽거나 살아남을지, 그 리듬부터 정하는 겁니다.

예를 들어 문제 검증 단계라면 7일 안에 한 사이클이 끝나야 한다고 봅니다. 월요일에 가설을 적고, 화요일부터 목요일까지 8~10명 인터뷰를 하고, 금요일에는 메시지 수정 또는 가설 폐기를 결정하는 식이죠. 이 주기 안에서 제품은 도구일 뿐입니다.

Michael Seibel이 여러 번 말한 것도 비슷합니다. MVP는 가장 위험한 가정을 테스트하는 최소한의 것이라는 얘기요. 그 최소한은 앱일 수도 있지만, 랜딩페이지일 수도 있고, 스프레드시트일 수도 있고, 창업자의 손작업일 수도 있습니다.

Dropbox 초기에 3분짜리 데모 영상으로 반응을 본 사례가 자주 언급되는 이유도 여기 있습니다. 완성품이 있어서가 아니라, 만들기 전에 무엇을 배워야 하는지를 정확히 알았기 때문이죠.

좋은 MVP는 작은 제품이 아니라, 다음 결정을 더 빨리 하게 만드는 장치입니다.

그래서 저는 초기 팀에게 기능 수를 줄이라고만 말하지 않습니다. 그보다 먼저, 한 번의 학습 사이클이 끝날 때 팀이 반드시 답해야 하는 질문을 적어보라고 합니다. 예를 들면 이런 식입니다.

누가 이 문제를 가장 자주 겪는가
그들은 지금 무엇으로 버티는가
그 불편은 주간 단위인지, 월간 단위인지
문제가 생겼을 때 누가 제일 먼저 화를 내는가
해결되면 절약되는 시간이 몇 시간인가
그 절약분에 돈을 붙일 수 있는가

이 질문에 답이 쌓이면 로드맵이 가벼워집니다. 반대로 답이 없으면 로드맵은 늘 무거워집니다. 기능이 많아서가 아니라, 확신이 없어서 이것저것 다 넣게 되니까요.

그래서 MVP 회의에서 제가 먼저 빼는 것

“출시하면 알게 되겠지”라는 기대입니다.

이 말이 완전히 틀린 건 아닙니다. 다만 너무 자주 면죄부로 쓰입니다. 출시 후에만 알 수 있는 것도 있지만, 출시 전에 충분히 알 수 있는 것도 많습니다. 누가 가장 급한지, 지금 어떤 우회 방법을 쓰는지, 돈 얘기에서 얼굴이 굳는지 같은 것들요.

만약 여러분이 월 49만 원짜리 운영 자동화 SaaS를 준비 중이라면, 첫 목표는 예쁜 대시보드가 아닐 수 있습니다. 오히려 2주 안에 15명과 대화하고, 그중 5명이 최근 한 달 안에 같은 문제를 겪었는지 확인하고, 3명이 수동이라도 결과물을 받아보겠다고 하는지 보는 게 더 낫습니다.

그 다음에야 제품이 붙습니다. 그리고 그 제품도 처음엔 완성형일 필요가 없습니다. 고객이 매주 화요일 오전 9시에 받는 보고서를, 창업자가 밤 11시에라도 직접 만들어 보내는 게 더 좋은 MVP일 때가 있습니다. 스케일은 안 되지만, 학습은 엄청나게 빠르거든요.

Paul Graham이 말한 ‘스케일 안 되는 일을 하라’는 조언도 저는 이 맥락에서 읽습니다. 초기엔 비효율이 문제가 아니라, 무지가 문제입니다. 많이 모르는 상태에서 자동화부터 하면, 빠르게 틀린 방향으로 달릴 수 있습니다.

결국 MVP는 제품 이름이 아니라 팀 운영 방식에 가깝습니다. 무엇을 얼마나 적게 만들었는지보다, 얼마나 자주 현실과 부딪히고 판단을 바꾸는지가 더 중요합니다.

저는 그래서 MVP 문서를 볼 때 기능 정의서보다 학습 캘린더를 먼저 보고 싶습니다. 다음 14일 동안 어떤 가설을 확인하고, 누구를 만나고, 무엇을 버릴지 적혀 있다면 그 팀은 이미 절반은 맞게 가고 있는 겁니다.

혹시 지금 MVP 범위를 줄이는 데만 매달리고 있다면, 한 번만 이렇게 바꿔보세요. 이번 주에 무엇을 출시할지가 아니라, 이번 주에 무엇을 확실히 알게 될지를 먼저 적는 겁니다.

참고한 문헌 링크

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

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

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

무료로 시작하기 →

← 블로그 목록으로