MVP가 뭐야 — 최소 기능 제품(Minimum Viable Product) 정의·6가지 유형·Dropbox·Airbnb·Zappos 사례·만드는 5단계 완전 정리
스타트업 기사를 읽다 보면 "MVP로 출시했다", "MVP에서 시작해 PMF를 찾았다" 같은 표현이 반복된다. 그런데 "MVP가 정확히 무엇이냐"고 물으면 명확히 답하기 어렵다. 미완성 베타 버전 같은 거냐, 그냥 기능 적은 시제품이냐, 아니면 다른 개념이냐 하는 식의 혼란이 흔하다.
MVP는 Minimum Viable Product의 약어, 한국어로는 "최소 기능 제품"이다. 한 줄로 정의하면 "핵심 가설 1개를 검증하기 위한 최소한의 제품"이다. "쓰레기 같은 미완성품"이 아니라 작동은 안정적이지만 기능은 최소화한 제품이며, 사용자 학습(validated learning)을 얻기 위한 도구다. 이 글은 MVP의 정의와 유래, Build-Measure-Learn 루프, 6가지 유형, Dropbox·Airbnb·Zappos 같은 유명 사례, 만드는 5단계, 그리고 MMP·MLP 같은 인접 개념까지 정리한다.
이 글의 구성
01 정의와 유래
| 항목 | 내용 |
|---|---|
| 약어 | Minimum Viable Product |
| 한국어 | 최소 기능 제품 또는 최소 존속 제품 |
| 한 줄 정의 | 핵심 가설 1개를 검증하기 위한 최소한의 제품 |
| 용어 등장 | Frank Robinson (2001) — SyncDev 창업자가 처음 사용 |
| 대중화 | Eric Ries — 저서 『The Lean Startup』 (2011) |
| 핵심 사상 | 가장 작은 노력으로 가장 많은 검증 학습(validated learning)을 얻는다 |
Eric Ries는 『The Lean Startup』에서 MVP를 "제품 개발팀이 최소한의 노력으로 최대한의 검증 학습을 얻을 수 있게 해 주는 제품 버전"으로 정의했다. 핵심은 두 가지다 ━ "최소(minimum)"는 만드는 비용·시간을 줄이라는 의미이고, "검증 가능(viable)"은 사용자가 실제로 써 보고 의미 있는 피드백을 줄 수 있는 수준이어야 한다는 의미다. 둘 중 하나만 충족하면 MVP가 아니다.
💡 핵심 관찰 — MVP는 "쓰레기"가 아니다
MVP를 "급하게 대충 만든 미완성품"으로 오해하면 사용자에게 외면당해 가설 검증 자체가 불가능해진다. MVP는 기능 범위가 좁을 뿐 작동·디자인·신뢰도는 안정적이어야 한다. "최소"는 기능 수의 최소이지 품질의 최소가 아니다.
02 Build-Measure-Learn 루프와 핵심 원칙
린 스타트업의 핵심 루프는 다음과 같다.
Build · Measure · Learn 루프
이 루프의 핵심은 "한 사이클의 시간을 가능한 짧게"다. 한 번 도는 데 6개월이 걸린다면 1년에 두 번만 학습할 수 있다. 일주일에 한 번 돌 수 있다면 1년에 50번 학습한다. 이 학습 속도 차이가 곧 스타트업의 생존을 결정한다.
핵심 원칙 3가지
- 가설 우선 ━ "만들고 싶은 것"이 아니라 "검증해야 할 가설"을 먼저 정한다
- 지표 우선 ━ "그럴듯해 보인다"는 느낌이 아니라 측정 가능한 KPI로 판단한다
- 학습 우선 ━ 출시 자체가 목표가 아니라 "다음 행동을 바꿀 학습"이 목표다
03 MVP 6가지 유형과 사례
| 유형 | 설명 | 대표 사례 |
|---|---|---|
| Landing Page | 제품 없이 페이지만 만들고 가입 측정 | Buffer — 가격표만 있는 페이지 |
| Concierge | 초기 사용자에게 1:1 수동 서비스 제공 | 초기 Airbnb — 창업자 직접 응대 |
| Wizard of Oz | 자동화된 척, 뒤에서 사람이 수동 처리 | 초기 Zappos — 동네 신발가게에서 사진 찍어 배송 |
| Single Feature | 핵심 기능 1개만 만들어 출시 | 초기 Instagram — 필터 + 공유만 |
| Smoke Test | 광고만 띄워 클릭률·관심 측정 | Facebook Ads 기반 신제품 가설 검증 |
| Prototype / Video | 영상·목업으로 시연하고 대기자 모집 | 초기 Dropbox — 데모 동영상 한 편 |
여섯 가지 유형의 공통점은 "진짜 풀스택 제품을 만들기 전에 가설부터 검증한다"는 점이다. Landing Page는 수요를, Concierge·Wizard of Oz는 서비스 가치를, Single Feature는 핵심 기능 채택률을, Smoke Test는 시장 관심을, Prototype은 컨셉 자체를 검증한다. 어떤 유형을 선택할지는 검증하려는 가설의 성격에 달려 있다.
📌 유형 선택 기준
"이걸 원하는 사람이 있을까?"가 가설이면 Landing Page·Smoke Test. "내가 줄 가치를 사람들이 진짜 좋아할까?"면 Concierge·Wizard of Oz. "이 기능 1개만으로 시장이 형성될까?"면 Single Feature. 가설이 명확해야 유형 선택도 명확해진다.
04 유명 MVP 5개 스토리
사례 1 — Dropbox
2007년 창업자 Drew Houston은 클라우드 동기화 제품을 완성하기 전에 3분짜리 데모 영상을 제작해 Hacker News에 올렸다. 대기 가입자가 하룻밤 사이 1.5만 명에서 7.5만 명으로 폭증했고, 이 수치 자체가 투자 유치의 핵심 근거가 됐다. 제품 코드 한 줄 없이 "수요"부터 검증한 Prototype MVP의 교과서 사례.
사례 2 — Airbnb
2007년 창업자 Brian Chesky·Joe Gebbia는 샌프란시스코 디자인 컨퍼런스 기간 호텔이 부족하다는 점에 착안해 자기 집 거실에 매트리스 3개를 깔고 예약을 받았다. 사이트도 워드프레스 기반의 단순 페이지였다. 이 작은 실험이 "낯선 사람 집에 묵을 수 있느냐"는 가설을 검증해 글로벌 숙박 플랫폼의 출발점이 됐다.
사례 3 — Zappos
1999년 창업자 Nick Swinmurn은 "온라인으로 신발을 살까"라는 가설을 검증하기 위해 창고도 재고도 없이 동네 신발가게에서 사진을 찍어 웹사이트에 올렸다. 주문이 들어오면 가게에서 사다가 발송했다. 수익은 0에 가까웠지만 "온라인 신발 수요가 존재한다"는 사실을 입증했고, 결국 Amazon에 12억 달러에 인수됐다.
사례 4 — Buffer
2010년 창업자 Joel Gascoigne는 SNS 게시물 예약 도구를 만들기 전에 가격표만 있는 랜딩 페이지를 만들었다. "Plans & Pricing" 버튼을 누르면 "아직 준비 중입니다, 이메일을 남겨 주세요" 페이지가 떴다. 가입자가 충분히 모이는 것을 본 뒤에야 실제 제품 개발에 착수했고, 이후 글로벌 SaaS로 성장했다.
사례 5 — Groupon
2008년 시카고에서 시작된 Groupon의 초기 형태는 워드프레스 블로그 + PDF 쿠폰 수동 발송이었다. 매일 한 가지 딜을 블로그에 올리고, 구매자에게 일일이 이메일로 PDF 쿠폰을 보냈다. 결제도 PayPal로 수동 처리했다. "공동구매가 작동하는가"라는 가설을 가장 적은 코드로 검증한 Concierge MVP다.
05 MVP 만들기 5단계와 인접 개념
단계별 가이드
MVP 만드는 5단계
인접 개념 비교
| 약어 | 의미 | MVP와의 차이 |
|---|---|---|
| MVP | Minimum Viable Product | "검증 가능한" 최소 — 학습 도구 |
| MMP | Minimum Marketable Product | "팔 수 있는" 최소 — 상업화 단계 |
| MLP | Minimum Lovable Product | "사용자가 좋아할" 최소 — 감성 가치 포함 |
| PMF | Product-Market Fit | MVP 검증의 목표 지점 |
| Pivot | 방향 전환 | MVP 결과가 부정적일 때 다음 행동 |
2026년 트렌드 — AI · No-code · 바이브코딩 결합
최근 MVP 출시 시간은 주 단위에서 일 단위로 단축되고 있다. 세 가지 변화가 동시에 일어났다.
- No-code 도구 — Bubble·Webflow·Glide·Softr로 코드 없이 풀스택 프로토타입 제작
- 바이브코딩 — Cursor·Claude Code 같은 AI 코딩 도구로 며칠 만에 작동 SaaS 제작
- AI 래퍼 MVP — LLM API + 간단한 UI 조합의 MVP가 폭증, Y Combinator W25 배치에서 다수 등장
이런 흐름은 MVP의 "최소" 임계점을 더 낮춰 가설 검증 속도를 올린다. 다만 검증 가설 자체가 부실하면 빠르게 만든 만큼 빠르게 실패하므로, 속도가 빨라질수록 가설 정의 단계가 더 중요해진다.
MVP의 목적은 "출시"가 아니라 "다음 행동을 바꿀 학습"이다. 같은 가설이 옳다는 확신이 깊어지면 Persevere, 의심이 깊어지면 Pivot한다.
━ Build · Measure · Learn — 사이클 시간이 곧 학습 속도
06 자주 묻는 질문 5가지
Q1MVP와 베타 버전은 같은 건가
다르다. 베타 버전은 "거의 완성된 제품을 일부 사용자에게 미리 푸는 단계"로, 기능 대부분이 이미 구현된 상태다. MVP는 "검증 가능한 최소"로, 기능 대부분이 의도적으로 빠진 상태다. 베타는 출시 직전 품질 검증이 목적이고, MVP는 시장 가설 검증이 목적이다. 비유하면 베타는 "이미 만든 자동차의 시승"이고, MVP는 "자동차를 만들기 전 자전거로 수요 확인"이다.
Q2MVP는 어디까지 작아도 되나
"가설 1개를 검증할 수 있는 최소"가 기준이다. 가설이 "이 기능을 원하는 사람이 있는가"면 Landing Page만으로 충분하다. 가설이 "사용자가 매일 쓸 만큼 가치 있는가"면 적어도 일주일치 사용이 가능한 수준이어야 한다. 너무 작아서 가설 검증이 불가능하면 MVP가 아니라 그냥 데모다.
Q3MVP가 너무 작아서 사용자가 외면하지 않을까
이 우려에서 나온 개념이 MLP(Minimum Lovable Product)다. 기능은 최소지만 "사용자가 좋아할 만한 감성·디자인·완성도"를 갖춰야 한다는 입장이다. 실제로 너무 거친 MVP는 가설 검증 자체를 어렵게 만들 수 있어서, 핵심 기능에 한해서는 디자인·UX 완성도를 양보하지 않는 게 권장된다.
Q4대기업에서도 MVP를 쓰나
쓴다. 신규 사업·신규 기능·신시장 진입 시 내부 MVP 형태로 검증한다. 다만 대기업 환경에서는 "최소"의 정의가 스타트업보다 훨씬 크다. 브랜드 신뢰도가 걸려 있어 부실 출시가 어렵기 때문이다. Google·Amazon 같은 곳도 신규 서비스를 내부 dogfooding(직원 사용)이나 한정 지역 베타로 MVP 검증한다.
Q5MVP 검증에 실패하면 어떻게 하나
실패라기보다 "학습 1회 완료"로 보는 게 린 스타트업의 관점이다. 가설이 틀렸다는 것을 알았다면 다음 행동을 결정한다. 두 가지 선택지가 있다 ━ Pivot(가설·고객·제품을 바꿔 다시 시도) 또는 중단(시장 자체가 없다고 판단되면 깔끔히 접기). 같은 가설을 계속 우기는 것이 가장 비싼 선택이다.
07 결론
MVP는 "완성된 제품의 축소판"이 아니라 "가설 검증을 위한 학습 도구"다. 핵심 사상은 가장 작은 노력으로 가장 많은 검증 학습을 얻는 것이며, Build-Measure-Learn 루프의 사이클 시간이 곧 스타트업의 학습 속도가 된다.
실무 원칙은 다음과 같다.
첫째, MVP는 "쓰레기 같은 미완성품"이 아니라 "기능 범위가 좁은 안정적 제품"이다. 작동·디자인·신뢰도는 양보하지 않는다.
둘째, 가설을 먼저 정의하고 그에 맞는 MVP 유형을 선택한다. 가설 없이 만든 MVP는 그냥 작은 제품일 뿐이다.
셋째, 측정 가능한 KPI를 사전에 정한다. "그럴듯해 보인다"는 감으로 판단하지 않는다.
넷째, Build-Measure-Learn 사이클 시간을 가능한 짧게 유지한다. 한 번 도는 데 6개월이면 학습 속도가 너무 느리다.
다섯째, 가설이 틀렸다면 빠르게 Pivot한다. 같은 가설을 계속 우기는 것이 가장 큰 비용이다.
✅ MVP 실무 체크리스트
본 글은 MVP(Minimum Viable Product) 개념·유형·사례·만드는 단계를 정리한 자료다. 실제 적용은 제품 도메인·시장 상황·팀 역량에 따라 달라지며, 본 글의 사례는 일반적으로 알려진 정보를 정리한 것으로 세부 수치·시점은 출처별로 차이가 있을 수 있다.
#MVP #최소기능제품 #MinimumViableProduct #린스타트업 #LeanStartup #EricRies #BuildMeasureLearn #PMF #제품마켓핏 #Dropbox #Airbnb #Zappos #Buffer #Groupon #Pivot
댓글