5일 짧게 만드는 법, 압축의 기술

두 번째 MVP는 같은 일을 30% 빠르게 하는 게 아니라, 다른 일을 안 하는 것이다.

14일이 9일이 된 이유

박서연 씨는 1년 전 첫 MVP를 만들 때 14일이 걸렸어요. 마케팅 칼럼 분류 SaaS였지만, 막상 시작하니 먼저 고객 심층 인터뷰 5건을 했고, 대시보드 UI를 3번 다시 만들었으며, 성능 최적화에 3일을 썼습니다. 그러던 중 이준호 씨가 물었어요. "두 번째는 몇 일에 만들 거야?"

박서연 씨가 생각해보니, 첫 번째에서 했던 일 중 실제로 필요했던 것은 70% 정도였어요. 인터뷰 중 절반은 이미 알고 있던 문제였고, 세 번째 대시보드 디자인은 첫 번째와 거의 같았으며, 성능 최적화는 출시 후 두 달이 지나도 아무도 언급하지 않았습니다.

그래서 두 번째 MVP는 9일이 걸렸어요. 더 빠르게 개발한 게 아니라, 하지 않아도 되는 것을 안 했을 뿐입니다.

빠르게 하기 vs 안 하기, 겉보기 같지만 다른 전략

두 번째 MVP를 빠르게 만드는 방법은 크게 두 가지예요.

• 속도 개선: 같은 일을 더 빠르게 (5건 인터뷰를 더 효율적으로, 대시보드를 더 빨리 디자인). "최적화"
• 일 제거: 처음부터 그 일을 안 함 (인터뷰 2건만, UI 재검토 1회만, 성능 최적화 출시 후로). "선택"

표면적으로 두 결과는 비슷해 보여요. 14일 → 10일이든, 14일 → 9일이든. 하지만 내부적으론 완전히 달라요. 1인 메이커의 시간은 한정되어 있는데, 속도 개선은 선택지가 많지만 일 제거는 훨씬 큰 효과를 냅니다.

한국의 한 스타트업 사례를 보면, 초기 개발팀은 완벽한 제품을 만들려고 6개월을 계획했는데, 스프린트 방식으로 전환하면서 불필요한 기능을 과감하게 빼자 2개월 만에 첫 버전 출시가 가능했어요. 속도를 2배로 높인 게 아니라, 할 일의 60%를 애초에 하지 않은 것.

10번 할 일을 9번으로 줄이는 것이 9번 할 일을 8번으로 하는 것보다 심리적 수확이 큽니다. 전자는 "선택"의 경험이고, 후자는 "가속"의 경험이기 때문이에요.

첫 번에 한 일의 70% 분류법

어떤 일이 제거 대상일까요? 첫 MVP 이후 한 달간의 기록을 펼쳐놓고 다음 질문을 던집니다.

1. 이 일이 없었으면 출시가 불가능했을까?
2. 이 일을 하지 않았으면 사용자가 눈치챘을까?
3. 이 일을 2주 뒤로 미뤘으면 문제가 되었을까?

이 질문에 "아니오"가 2개 이상이면, 그 일은 70%(제거 대상)에 포함됩니다.

필수 일 (30%)

• 핵심 기능 구현
• 최소한의 사용자 테스트
• 배포와 모니터링
• 치명적 버그 수정

선택 일 (70%)

• 세 번 이상의 디자인 재검토
• 완벽한 문서화
• 모든 엣지 케이스 처리
• 출시 전 완전한 성능 최적화
• 모든 사용자 피드백에 대한 대응
• 마케팅 자료 준비

이준호 씨의 경우, 첫 번째 AI 프롬프트 관리 도구를 만들 때 완벽한 온보딩 튜토리얼에 2일을 썼어요. 분석해보니 사용자의 80%가 도움말을 읽지 않고 바로 시작했습니다. 두 번째 제품에서는 튜토리얼 대신 인라인 힌트 3줄로 대체, 구현 시간 2시간.

"이미 한 번 했으니까 이번엔 더 완벽하게"라는 생각이 오는 순간을 조심하세요. 그 생각은 완벽주의의 시작입니다.

시간 도둑 3가지

1. 결정 미루기

박서연 씨가 두 번째 MVP를 기획할 때, "이번엔 기술 스택을 바꿔볼까?" 이 결정 하나가 3일의 회의와 테스트로 이어졌어요. 결국 유지했지만 시간 낭비. 매일의 작은 결정들이 쌓이면 "결정 피로"가 됩니다.

2. 과도한 회의와 보고

1인 메이커에게 회의는 자기와의 만남이지만, 팀이 있다면 회의는 시간 낭비의 지점. 또 "현황 보고"의 유혹도 있어요. "진행률이 얼마나 될까?"를 매일 체크하고 정리하는 행위 자체가 시간 낭비가 됩니다.

3. 작은 완벽주의

"5건 인터뷰는 너무 적을까?" → 7건으로 늘림 → 분석이 복잡 → 1일 추가. 가장 위험한 순간은 "출시 일주일 전"이에요. 작은 버그를 "빨리 고칠 수 있다"고 생각하고 손대는 순간, 예상치 못한 다른 문제가 터집니다.

의사결정 자동화, 패턴에서 규칙으로

"빼야 할 일"을 아는 것과 "실제로 빼는 것"은 달라요. 그 사이의 간격을 메우는 방법은 의사결정을 자동화하는 것입니다.

이준호 씨의 규칙:

• 규칙 1: 첫 버전에는 가장 많이 쓰는 기능 3개만. 나머지는 v1.1에서
• 규칙 2: 버그는 심각도 기준으로 분류. 중간 이하는 출시 후로 미룸
• 규칙 3: 의사결정은 24시간 고민 이상 금지. 그 이상이면 기본값으로

이 규칙들은 처음 만들 때 약간의 용기가 필요해요. "정말 이 기능 없이도 괜찮을까?" 하는 의심. 하지만 규칙이 정해지는 순간, 매번 고민할 필요가 없어집니다.

의사결정 자동화는 보이기에 "경직된 선택"처럼 보이지만, 실제로는 반복되는 작은 고민에서 자유로워지는 경험이에요.

시간 절약 매트릭스: 9일 vs 14일

의사결정 규칙 카드 만드는 5단계

1. 첫 MVP에서 "이게 정말 필요했나?" 순간 5개 적기
2. 각 순간마다 "다음엔 어떻게 할 것인가" 규칙 정하기
3. 규칙을 문장 하나씩 카드에 적기
4. 개발 시작 전날 카드를 다시 읽기
5. 결정 순간에 "규칙을 따를까, 새로 판단할까" 기준 세우기

마무리

"5일 짧게 만드는 법"의 핵심은 속도가 아니라 선택입니다. 빠르게 하려고 노력하는 사람은 많지만, 아예 하지 않기로 결정하는 사람은 드물어요. 그리고 그 차이가 14일과 9일을 만듭니다.

하지만 한 번 MVP를 만들기 빨라진다고 끝이 아니에요. 문제는 이 속도로 계속 만들 수 있는가입니다. 다음 편에서는 한 사람이 여러 MVP를 운영하는 시리즈 빌더의 운영법을 다룹니다.

이전 편: 같은 실수 안 하는 법, 패턴 인식의 기술
다음 편: 시리즈 빌더의 운영법, 한 사람이 여러 MVP

이 글에 등장하는 인물(박서연, 이준호)에 대한 안내
본 시리즈에 등장하는 인물은 페일스쿨이 만든 가상의 페르소나입니다.

김민철, 프리아이브 CEO, 페일스쿨