MVP
한 줄 정의
이게 될까를 확인하려고, 한 흐름이 끝까지 굴러갈 만큼만 만든 첫 버전
1. 비유로 이해하기
친구들에게 떡볶이를 팔아보고 싶다고 해 보자. 방법은 두 가지다.
A. 가게를 빌리고, 간판을 달고, 메뉴판을 인쇄하고, 의자를 사고, 메뉴를 스무 개 개발한다. 석 달 걸린다. 그런데 막상 열었더니 동네 사람들이 떡볶이를 별로 안 좋아한다.
B. 집에서 한 냄비만 끓여서 친구 열 명에게 먹여 본다. 하루 걸린다. “맛있는데 좀 짜다”는 말을 듣는다. 다음 날 덜 짜게 만들어 또 먹여 본다.
B가 MVP다. 여기서 중요한 건 “대충 만든 것”이 아니라는 점이다. 떡볶이는 진짜 떡볶이여야 한다. 냄비 대신 사진을 보여주면 안 된다. 크기는 최소지만, 진짜로 먹을 수 있어야 한다.
2. 왜 필요한가
실패의 원인은 기능이 적어서가 아니다
초보 프로젝트가 실패하는 이유는 기능이 너무 많아서다. 다 만들려다 아무것도 못 끝낸다.
기준은 기능 수가 아니라 흐름의 완결성
목표가 “이동”이라면 스케이트보드는 훌륭한 MVP다. 느려도 실제로 굴러가고 나를 데려다준다. 반면 자동차 타이어 하나는 MVP가 아니다. 아무리 잘 만들어도 그걸로는 아무 데도 못 간다.
여기서 판단 기준이 나온다. 부분만 완벽하면 아직 아무 일도 끝나지 않았다. 사용자가 의미 있는 한 가지 일을 처음부터 끝까지 해낼 수 있어야 MVP다.
자를 용기
기능을 고를 때 던지는 질문은 하나다.
“이 기능 없이 출시해도, 사용자가 핵심 문제를 풀 수 있나?”
그렇다면, 또는 애매하면 자른다. 버전 2에 넣으면 된다.
기능을 네 칸으로 나누는 MoSCoW를 쓴다. 꼭(Must) / 있으면 좋음(Should) / 나중에(Could) / 지금은 안 함(Won’t). 그리고 MVP에서는 Must만 만든다.
가장 강력한 칸은 “지금은 안 함”이다. 일부러 최소 다섯 개를 적어 둔다. 적어 두면 “이것만 더 넣으면 안 될까”의 유혹을 막아 준다. 이 유혹에는 이름이 있다 — 스코프 크립. 무서운 건 이게 진보처럼 느껴진다는 점이다. 하나하나는 다 그럴듯하다. “고객이 원해서”, “경쟁사에 있어서”, “하루면 된다길래”.
에이전트는 특히 그렇다
일반 프로그램은 “버튼을 누르면 저장된다”가 예상대로 동작한다. 그런데 에이전트는 모델이 판단을 하니까, 실제로 돌려보기 전에는 알 수가 없다.
- 모델이 도구를 제대로 골라 쓸까?
- 몇 단계쯤 가면 길을 잃을까?
- 어떤 지시를 줘야 원하는 대로 움직일까?
작게 만들어 돌려보고 관찰하는 것 말고는 방법이 없다.
| 원칙 | 뜻 |
|---|---|
| 도구는 2~3개만 | 도구가 많을수록 모델이 헷갈린다 |
| 가장 어려운 부분부터 | 쉬운 걸 먼저 만들면 정작 안 되는 부분을 늦게 발견한다 |
| 화면은 나중에 | 터미널에 글자만 찍혀도 충분하다 |
| 저장은 가볍게 | 서버형 DB 대신 SQLite 파일 하나로 시작한다 |
| 하네스는 뼈대만 | 루프 + 도구 실행 + 종료 조건. 그 이상은 나중에 |
“회사 문서를 검색해서 답해 주는 에이전트”로 예를 들면 이렇게 갈린다.
✗ MVP가 아닌 계획 (3개월)
웹 UI + 로그인 + 문서 자동 수집 + 벡터DB + 대화 기록 저장
+ 관리자 페이지 + 여러 사용자 지원
✓ MVP (하루)
터미널에서 실행 + 문서 10개 수동으로 넣기 + 검색 도구 1개
+ 하네스 최소 루프
아래쪽을 하루 만에 돌려 보면 이런 걸 알게 된다.
- 검색 도구가 엉뚱한 문서를 가져온다 → 검색 방식을 고쳐야 한다
- 모델이 한 번 검색하고 바로 포기한다 → 지시문에 “여러 번 찾아봐”를 추가한다
- 5단계로는 부족하다 → 늘리거나 전략을 바꿔야 한다
이 세 가지를 석 달 뒤가 아니라 하루 만에 알게 되는 것. 그게 MVP의 전부다.
3. 어디서 만났나
8회차의 주제 자체였다. 조각(화면·백엔드·데이터베이스·에이전트)을 다 배운 뒤, 그걸 모아 내 서비스 하나로 만드는 날이었는데 수업이 먼저 말한 건 만드는 방법이 아니라 가장 흔한 실패였다.
거대한 서비스도 첫 버전은 초라했다는 이야기를 함께 들었다.
- 에어비앤비 — 거실에 에어매트리스 세 개와 웹페이지 하나. 예약 시스템도 리뷰도 결제도 없이 첫 주말 손님 세 명을 받아 “낯선 사람이 낯선 집에 돈 내고 묵을까”를 검증했다
- 드롭박스 — 제품을 안 만들고 3분짜리 시연 영상만 올려 수요를 먼저 확인했다
- 인스타그램 — 원래는 기능이 잔뜩 든 ‘Burbn’이었는데, 사용자가 사진 공유만 많이 쓰는 걸 보고 사진·필터·피드로 좁혔다
8회차 — MVP, 다 만들려 하지 말고 한 흐름이 끝까지 굴러가게
4. 헷갈리는 개념
| 이 용어 | 비슷하지만 다른 것 | 차이 |
|---|---|---|
| MVP | 프로토타입 | 프로토타입은 보여주기용이라 안이 비어 있어도 된다(떡볶이 사진). MVP는 진짜 동작한다. 작을 뿐이다(진짜 떡볶이 한 냄비) |
| MVP | PoC | PoC는 “기술적으로 가능한가?”만 확인한다. 사용자는 보지 않는다. MVP는 사용자가 써 봐야 의미가 있다 |
| MVP | 베타 | 베타는 거의 완성된 것을 미리 풀어 보는 단계다. MVP는 그보다 훨씬 앞 |
| MVP | Most Valuable Player · Model-View-Presenter | 스포츠의 최우수 선수, 화면 구조 설계 패턴. 기술 문맥에서 MVP라고 하면 거의 Minimum Viable Product다 |
5. 많이들 오해하는 지점
ㄱ. “MVP니까 대충 만들어도 된다”
MVP를 대충 만들어도 되는 핑계로 쓰는 경우가 많다. 하지만 M(Minimum, 최소)만큼 V(Viable, 쓸 만한)가 중요하다. 사용자가 실제로 써서 의미 있는 피드백을 줄 수 있어야 MVP고, 그렇지 않으면 그냥 미완성품이다.
ㄴ. “완성품의 축소판”
타이어는 자동차의 축소판이지만 MVP가 아니다. 판단 기준은 크기가 아니라 흐름이 끝까지 가느냐다. 기능을 절반으로 줄인 반쪽짜리보다, 기능 하나가 처음부터 끝까지 굴러가는 쪽이 MVP다.
ㄷ. “MVP는 목적지다”
목적지가 아니라 질문이다. 만들고 나면 답이 나오고, 그 답이 방향을 통째로 바꾸기도 한다.
슬랙은 게임 회사가 사내 소통용으로 만든 도구가 진짜 제품이 된 경우였고, 트위터는 팟캐스트 회사가 설 자리를 잃고 나온 사내 아이디어였다. 둘의 공통점이 하나였다 — 부수적으로 만든 것이 진짜 제품이었다. MVP를 만드는 이유는 계획대로 가기 위해서가 아니라, 계획이 틀렸다는 걸 싸게 알기 위해서다.