2주 안에 나오는 MVP는 무엇을 빼서 만드는가
기능을 스무 개 적어놓고 “최소한만 하자”고 말하면 대개 열여덟 개가 남습니다. 범위는 개수를 줄여서가 아니라 어떤 종류를 통째로 빼는가로 정해집니다.
일정을 미는 건 기능 개수가 아니다
화면 열 개짜리가 2주에 끝나고, 화면 세 개짜리가 두 달 걸리는 일이 실제로 생깁니다. 개수가 아니라 아래 세 종류가 들어 있는지가 갈랐습니다.
- 되돌리기 취소, 환불, 반려, 수정 이력. 무언가를 무를 수 있게 만드는 순간, 중간에 끊겨도 데이터가 어긋나지 않게 하는 처리가 전부 따라옵니다. 만드는 것보다 되돌리는 것이 항상 더 오래 걸립니다.
- 권한 사람마다 다른 걸 볼 수 있게 하는 일. 사용자·운영자·관리자 세 등급만 생겨도 모든 화면이 세 번씩 검토 대상이 됩니다. 화면이 늘어나는 게 아니라 화면마다 경우의 수가 늘어납니다.
- 정산 돈이 오가고 나뉘는 계산. 결제 자체보다 “누구에게 얼마가 언제”를 어긋남 없이 맞추는 쪽이 작업의 대부분입니다. MVP 단계에서 이걸 넣으면 검증할 시점이 한참 뒤로 밀립니다.
1~2주에 되는 것과 안 되는 것
| 항목 | 2주 안 | 메모 |
|---|---|---|
| 핵심 흐름 한 줄이 끝까지 도는 것 | 된다 | 입력 → 처리 → 결과 → 저장 |
| 이메일·소셜 로그인 | 된다 | 소셜은 심사 기간을 일정에 따로 잡습니다 |
| 데이터 저장과 목록·검색 | 된다 | MVP에서는 대개 필요합니다 |
| 외부 AI API 연동 | 된다 | 실패·지연 처리를 함께 넣습니다 |
| 운영자용 간단한 조회 화면 | 된다 | 고치는 기능까지는 뺍니다 |
| 결제와 정산 | 어렵다 | 취소·부분환불까지 넣으면 별건입니다 |
| 세 등급 이상의 권한 체계 | 어렵다 | 두 등급까지가 현실적입니다 |
| 알림(푸시·문자·카톡) | 어렵다 | 발송 채널 심사와 템플릿 승인이 붙습니다 |
| 앱스토어 심사가 필요한 네이티브 앱 | 어렵다 | 심사 대기가 개발보다 깁니다 |
심사용 MVP에 실제로 필요한 최소치
지원사업이나 투자 심사에 쓰려고 만드는 경우, 심사에서 실제로 확인하는 건 셋입니다.
- 링크가 열린다 — 캡처가 아니라 주소를 눌러 들어갈 수 있어야 합니다.
- 핵심 흐름 한 줄이 끝까지 돈다 — 넣고, 처리되고, 결과가 나오는 것까지. 이 한 줄이 막히면 나머지가 아무리 많아도 소용이 없습니다.
- 데이터가 남는다 — 새로고침해도 방금 한 것이 그대로 있어야 “돌아가는 것”으로 읽힙니다.
그 이상은 대체로 보지 않습니다. 화면 수를 늘리는 데 쓴 시간은 심사에서 회수되지 않습니다.
나중에 붙여도 되는 것 / 처음에 안 넣으면 비싸지는 것
“일단 빼자”가 항상 옳은 건 아닙니다. 나중에 붙이는 비용이 종류마다 다릅니다.
| 나중에 붙여도 싼 것 | 처음에 안 넣으면 비싸지는 것 |
|---|---|
| 화면 디자인 다듬기 | 데이터 구조 — 나중에 바꾸면 쌓인 데이터를 전부 옮겨야 합니다 |
| 기능 추가(새 화면) | 사용자 구분 — 처음에 “누구의 것인가”가 없으면 나중에 전부 다시 붙입니다 |
| 알림·통계 | 이력 남기기 — 안 남긴 과거는 되살릴 수 없습니다 |
| 관리자 편집 기능 | 배포 구조 — 로컬에서만 돌던 걸 나중에 올리는 게 더 오래 걸립니다 |
규칙 하나로 줄이면 이렇습니다. 보이는 것은 나중에 붙여도 되고, 데이터에 관한 것은 처음에 정해야 합니다.
범위를 정하는 세 문장
1. 이걸 누가 언제 씁니까. 한 사람의 하루 중 어느 순간인지까지.
2. 그 사람이 지금은 이걸 어떻게 하고 있습니까. 엑셀이든 카톡이든 종이든, 지금 방식이 대체 대상입니다.
3. 무엇이 되면 ‘됐다’고 말할 수 있습니까. 이 문장이 곧 완료 기준이 됩니다.
세 번째 문장을 적기 어렵다면 범위가 아직 정해지지 않은 것입니다. 그 상태로 착수하면 만드는 쪽도 받는 쪽도 언제 끝났는지 모르게 됩니다.