PRODUCT PRACTICE
MVP 범위를 줄일 때 사용하는 다섯 가지 결정 질문
기능 목록을 줄이는 데서 멈추지 않고, 한 번의 실험으로 답할 수 있는 질문까지 MVP를 좁히는 방법입니다.
Fix Uncomfortable 작성 · 게시 2026-07-21 · 수정 2026-07-25 · 6분
작은 제품과 작은 실험은 다르다
화면 수가 적다고 MVP가 되는 것은 아닙니다. 회원가입, 검색, 결제 중 일부만 빠진 제품은 작아 보이지만 무엇을 배우려는지 불분명할 수 있습니다. 반대로 수작업이 많더라도 한 가지 중요한 가설에 답한다면 좋은 MVP가 될 수 있습니다.
범위를 줄이는 기준은 개발 공수가 아니라 의사결정입니다. 이번 실험의 결과로 어떤 선택을 바꿀 것인지 한 문장으로 말할 수 있어야 합니다.
1. 이번에 반드시 답해야 할 질문은 하나인가
“사용자가 좋아할까?”는 너무 넓습니다. “가장 빠른 일정이 보이면 전문가 선택 시간이 줄어드는가?”처럼 관찰할 행동과 비교 기준을 포함해야 합니다. 질문이 두 개라면 실험도 둘로 나누는 편이 해석하기 쉽습니다.
2. 사용자가 실제로 해야 하는 최소 행동은 무엇인가
관심을 표현하는 클릭과 문제를 해결하기 위한 행동은 다릅니다. 이메일을 남기는 것보다 현재 상황을 설명하고 시간을 예약하는 행동이 더 강한 신호일 수 있습니다. 가설과 가장 가까운 행동만 남기고 나머지는 운영자가 수동으로 처리할 수 있습니다.
3. 실패했을 때 무엇 때문인지 구분할 수 있는가
가격, 신뢰, 일정, 사용성, 문제의 중요도를 한 번에 바꾸면 결과가 좋지 않을 때 원인을 알 수 없습니다. 가장 불확실한 요소 하나를 선택하고 나머지는 고정합니다. 실험 전에 예상 실패 이유와 확인 방법을 적어두면 결과 해석이 선명해집니다.
4. 코드 대신 사람이 수행해도 되는 단계는 무엇인가
초기에는 추천, 일정 조율, 결과 정리를 수작업으로 수행할 수 있습니다. 중요한 것은 자동화된 것처럼 보이는 것이 아니라 사용자가 실제로 가치를 느끼는지 확인하는 것입니다. 반복 과정이 확인된 뒤 자동화해야 불필요한 예외 처리를 줄일 수 있습니다.
5. 실험을 중단하거나 확장할 기준이 있는가
기간만 정하면 마지막 날에 좋은 신호만 찾기 쉽습니다. 예를 들어 다섯 번의 세션 중 네 번 이상에서 합의된 다음 행동이 남고, 준비 시간이 세션 시간의 절반 이하라면 다음 단계로 이동한다고 정할 수 있습니다.
반대로 같은 설명을 반복해도 요청이 구체화되지 않거나 제공 범위 합의가 계속 실패하면 기능 추가보다 문제 정의를 다시 해야 합니다. 중단 기준은 실패를 인정하기 위한 것이 아니라 학습 비용을 통제하기 위한 장치입니다.