1. 기능은 왜 이렇게 빨리 늘어날까요?
기능 목록은 대부분 “서비스라면 이것도 있어야 하지 않을까?”라는 생각에서 늘어납니다. 경쟁 서비스에 있는 기능, 미래에 필요할 기능, 운영자가 편해지는 기능까지 한 목록에 섞이기 때문입니다.
MVP 범위를 줄이려면 기능의 중요도를 논의하기 전에 첫 사용자가 반드시 완료해야 하는 하나의 핵심 행동을 먼저 정해야 합니다.
2. 20개 기능을 줄이는 5단계
1단계사용자 1명
첫 MVP의 대표 사용자를 하나로 좁힙니다.
2단계문제 1개
이번에 해결할 가장 중요한 문제를 하나로 정합니다.
3단계행동 1개
신청·구매·예약 등 완료해야 할 행동을 정합니다.
4단계흐름 연결
그 행동까지 필요한 화면과 기능만 연결합니다.
5단계나머지 분리
‘검증 후·나중에’ 또는 수작업 처리로 이동합니다.
3. 예시: 전문가 상담 서비스 20개 → 5개
“고객이 필요한 전문가를 찾고 실제 상담을 요청하는가?”를 검증한다고 가정해보겠습니다.
처음 작성한 20개 기능
→
첫 MVP의 5개 핵심 기능
| 기능 | 첫 MVP 판단 | 이유 / 대체 방법 |
|---|---|---|
| 소셜로그인 | 검증 후 | 초기 검증에 필수인지 확인. 간단한 식별 방식으로 시작 가능 |
| 추천·자동매칭 | 검증 후 | 초기에는 제한된 목록 또는 운영자 추천으로 검증 가능 |
| 결제 | 상황에 따라 지금 필요 | 지불의사 검증이 핵심 가설이면 포함 필요 |
| 채팅 | 검증 후 | 초기에는 기존 연락수단으로 운영 가능 |
| 리뷰·쿠폰·포인트 | 나중에 | 사용량과 재방문 데이터가 생긴 후 판단 |
| 고급 관리자·통계 | 나중에 | 초기 운영은 최소 관리화면 또는 수작업으로 보완 가능 |
4. ‘개발하지 않는다’와 ‘하지 않는다’는 다릅니다.
MVP에서 제외한 기능도 초기에는 사람이 대신 처리할 수 있습니다. 자동매칭 대신 운영자가 전문가를 연결하고, 자동 알림 대신 직접 메시지를 보내고, 고급 통계 대신 스프레드시트로 결과를 정리할 수 있습니다.
자동화는 나중에반복이 확인된 뒤 자동화
사용자가 거의 없는 단계에서 운영 자동화를 먼저 만드는 것보다 실제 반복 업무가 확인된 후 개발하는 편이 범위를 줄이는 데 도움이 됩니다.
검증이 먼저먼저 행동을 검증
초기에는 운영 효율보다 고객이 실제로 핵심 행동을 하는지 확인하는 것이 우선입니다.
5. 무조건 기능 수만 줄이면 안 됩니다.
| 잘못된 방법 | 문제 | 대신 이렇게 |
|---|---|---|
| 개발이 어려운 기능부터 삭제 | 핵심 가치 자체가 사라질 수 있음 | 가설 검증에 필요한지 먼저 판단 |
| 화면 수를 무조건 최소화 | 사용자 흐름이 끊길 수 있음 | 완결된 핵심 흐름 유지 |
| 결제를 무조건 나중으로 미룸 | 지불의사를 검증하지 못할 수 있음 | 핵심 가설이면 결제 포함 검토 |
| 관리기능을 전부 제거 | 실제 운영이 불가능할 수 있음 | 운영에 필요한 최소 기능만 유지 |
6. 5개로 줄인 뒤 다시 확인하세요.
첫 MVP의 핵심 사용자가 하나로 명확하다.
검증하려는 가장 중요한 가설을 한 문장으로 설명할 수 있다.
5개 기능이 하나의 사용자 흐름으로 연결된다.
각 기능이 왜 필요한지 검증 목적과 연결할 수 있다.
자동화하지 않아도 되는 업무를 수작업으로 분리했다.
제외 기능은 삭제가 아니라 검증 후 · 나중에 목록으로 관리한다.
한 줄 원칙
기능을 줄이는 가장 좋은 방법은 ‘삭제’가 아니라 ‘검증 순서’를 정하는 것입니다.
20개 기능 중 중요한 5개를 고르는 것이 아니라, 첫 번째 사용자 가설을 검증하는 하나의 흐름에 필요한 기능만 먼저 개발하세요. 나머지는 사용자 반응을 확인한 뒤 개발해도 늦지 않습니다.