MVP 설계: 3주 안에 만들 수 없다면, 그건 MVP가 아닙니다

6개월 동안 제품을 만들었습니다. 로그인, 대시보드, 알림, 설정, 다크 모드, 다국어 지원까지. 출시했습니다. 사용자 3명. 그중 2명은 친구입니다.

문제는 제품의 완성도가 아니었습니다. 아무도 원하지 않는 것을 완벽하게 만든 것이 문제였습니다.

MVP(Minimum Viable Product, 최소 기능 제품)는 "미완성 제품"이 아닙니다. 하나의 핵심 가설을 검증하기 위해 설계된 가장 작은 실험입니다. 그리고 그 실험은 3주 안에 끝나야 합니다.

MVP의 M은 Minimum입니다: 기능이 아니라 학습이 목표입니다

대부분의 인디 파운더가 하는 실수는 MVP를 "기능이 적은 제품"으로 이해하는 것입니다. 틀렸습니다. MVP는 "가설을 검증하는 가장 작은 방법"입니다.

차이를 비교합시다.

• 나쁜 MVP 정의 — "기능 10개 중 3개만 넣어서 출시하자"
• 좋은 MVP 정의 — "사람들이 이 문제에 돈을 낼 의향이 있는지 확인하자"

두 번째 정의에서는 제품이 필요 없을 수도 있습니다. 구글 폼 하나, 카카오톡 오픈채팅 하나, 노션 페이지 하나가 MVP가 될 수 있습니다.

MVP를 만드는 데 3주 이상 걸린다면, 당신은 MVP가 아니라 제품을 만들고 있는 것입니다. 멈추고 다시 깎으세요.

하나의 질문으로 시작하세요: "이것이 맞는지 어떻게 알 수 있습니까?"

MVP를 설계하기 전에 반드시 답해야 할 질문이 있습니다.

"내가 지금 가장 불확실한 것은 무엇인가?"

보통 세 가지 중 하나입니다.

• 문제 가설 — 이 문제가 진짜 존재하는가? 사람들이 충분히 불편해하는가?
• 솔루션 가설 — 내 해결 방법이 이 문제를 실제로 풀어주는가?
• 비즈니스 가설 — 사람들이 이 해결책에 돈을 낼 의향이 있는가?

각 가설에 따라 MVP의 형태가 완전히 달라집니다. 문제 가설이 불확실하면 인터뷰와 설문이 MVP입니다. 솔루션 가설이 불확실하면 프로토타입이 MVP입니다. 비즈니스 가설이 불확실하면 사전 판매 페이지가 MVP입니다.

코드 한 줄 없는 MVP: 인디 파운더의 비밀 무기

가장 강력한 MVP는 코드 없이 만드는 MVP입니다. 왜냐하면 가장 빠르기 때문입니다.

• 랜딩 페이지 + 결제 버튼 — 카드(Carrd)나 프레이머(Framer)로 1일 만에 완성. "구매하기" 버튼을 누르면 토스 결제 또는 "출시 알림 받기" 폼으로 연결. 클릭률이 곧 수요의 증거.
• 수동 MVP (Wizard of Oz) — 자동화된 것처럼 보이지만 실제로는 당신이 수동으로 처리. 예: AI 추천 서비스라고 홍보하지만, 초기에는 당신이 직접 추천을 작성.
• 카카오톡 오픈채팅 MVP — 한국에서 가장 빠른 커뮤니티 MVP. 오픈채팅방을 만들고 "매주 월요일 스타트업 인사이트를 공유합니다"라고 하면, 24시간 안에 수요를 확인할 수 있습니다.
• 구글 시트 MVP — 대시보드 SaaS를 만들려면? 먼저 구글 시트로 핵심 기능을 구현. 사람들이 시트를 쓰면, 그것을 제품으로 만드세요.
• 노션 템플릿 MVP — 노션 템플릿을 만들어서 유료로 판매. 클래스101이나 탈잉에서 5,000원짜리 템플릿이 팔리면, 그것을 SaaS로 확장할 근거가 됩니다.

핵심은 "만드는 시간을 최소화하고, 배우는 시간을 최대화하는 것"입니다.

기능 하나만 남기세요: "되면 좋겠다"는 전부 버립니다

코드로 MVP를 만들기로 했다면, 기능 목록을 가장 먼저 깎아야 합니다.

방법은 간단합니다. 기능 목록을 세 칸으로 나누세요.

• Must-have — 이것 없으면 핵심 가치를 전달할 수 없는 기능. 딱 1~2개.
• Nice-to-have — 있으면 좋지만 없어도 가설 검증은 가능한 기능. 전부 삭제.
• Delighter — 사용자를 감동시킬 기능. 나중에 추가. 지금은 삭제.

로그인이 필요합니까? 이메일 + 매직 링크면 충분합니다. 소셜 로그인, 비밀번호 찾기, 2FA는 MVP에 필요 없습니다. 대시보드가 필요합니까? 핵심 지표 하나만 보여주세요. 차트 4개, 필터 기능, CSV 내보내기는 나중입니다.

MVP에서 기능을 하나 더 넣을 때마다, 출시가 1주일 늦어지고, 학습의 기회가 1주일 줄어듭니다. 기능 하나의 대가는 시간입니다.

3주 스프린트: MVP 설계부터 출시까지

인디 파운더의 MVP 타임라인은 3주입니다. 이렇게 나눕니다.

• 1주차: 설계와 검증 — 핵심 가설 정의. 경쟁사 분석(30분이면 충분). 종이 위에 화면 3~5개 스케치. 잠재 고객 5명에게 스케치를 보여주고 피드백.
• 2주차: 구축 — 코어 기능만 개발. 디자인은 최소한으로. 프레임워크 고민에 시간 쓰지 말기. 가장 익숙한 기술 스택 사용.
• 3주차: 출시와 학습 — 부끄러운 상태로 출시. 첫 10명의 사용자에게 직접 연락. 사용 행동 관찰. 피드백 수집.

3주가 지났는데 출시하지 못했다면? 범위를 줄이세요. 기간을 늘리지 마세요. "2주만 더"는 영원히 반복됩니다.

"부끄럽지 않은 MVP는 너무 늦게 출시한 것입니다"

링크드인 창업자 리드 호프만의 유명한 말입니다. 그리고 이것은 진실입니다.

출시 전에 드는 생각들이 있습니다. "디자인이 좀 더 예뻐야 하지 않을까." "이 버그를 고치고 출시해야 하지 않을까." "경쟁사에 비해 기능이 너무 적지 않을까."

이 모든 것은 출시를 미루기 위한 변명입니다.

MVP의 목적은 감동을 주는 것이 아닙니다. 가설이 맞는지 틀린지 확인하는 것입니다. 예쁜 UI로는 가설을 검증할 수 없습니다. 사용자의 행동만이 답을 줍니다.

한국 시장에서 특히 주의할 점이 있습니다. 네이버 카페나 커뮤니티에 올렸을 때 "디자인이 별로다"는 댓글이 달릴 수 있습니다. 무시하세요. 비판하는 사람과 돈을 내는 사람은 다릅니다. 디자인을 비판한 100명보다, 기꺼이 결제한 3명의 목소리가 더 중요합니다.

MVP 이후가 진짜 시작입니다: 측정하고, 배우고, 반복하세요

MVP를 출시했다고 끝이 아닙니다. 오히려 여기서부터가 진짜입니다.

출시 후 2주 동안 집중해야 할 것은 세 가지입니다.

• 사용자가 가입 후 무엇을 하는가? — 핵심 기능을 쓰는가, 아니면 한 번 보고 떠나는가. 가입 후 30분 내 행동이 모든 것을 말해줍니다.
• 사용자가 돌아오는가? — 1주일 뒤 다시 접속하는 사용자가 있다면, 뭔가가 작동하고 있는 것입니다.
• 사용자가 돈을 내는가? — 무료 사용자 1,000명보다 유료 사용자 10명이 더 강력한 신호입니다.

이 세 가지 중 하나라도 긍정적인 신호가 나오면, 그 방향을 강화하세요. 전부 부정적이면, 가설을 수정하고 다시 3주 스프린트를 돌리세요. 이것이 만들기-측정-학습(Build-Measure-Learn) 순환입니다.