MVP 범위, 무엇을 자르고 무엇을 남기나

MVP에서 무엇을 자를지, 판단은 어디서 시작하나?

범위를 자르는 판단은 기능 목록에서 시작하지 않는다. "특정 사용자가, 특정 상황에서, 특정 작업을 끝낸다"는 한 문장을 먼저 정의하고, 그 문장에 직접 기여하지 않는 것부터 컷 대상에 올린다. 기능을 몇 개 줄이느냐가 아니라, 무엇을 아직 검증하지 않기로 하느냐가 이 국면의 진짜 판단이다.

핵심 정리

• MVP 범위 자르기는 기능을 줄이는 일이 아니라 검증하지 않을 것을 정하는 일이다.
• 컷 기준은 기능 수가 아니라 핵심 여정 완주 여부와 단일 학습 지표다.
• 자동화·권한·설정 같은 저장용 기능은 초기 검증 전에는 대부분 뒤로 밀린다.
• 범위가 2~6주 안에 못 만들어진다면 이미 v1 쪽으로 넘어간 것이다.
• 잘라낸 기능은 삭제가 아니라 백로그에 남기고 재검토 시점을 적어둔다.

Must-have와 Nice-to-have, 어디서 선을 긋나?

선은 "이 기능이 없으면 핵심 과업 자체가 성립하지 않는가"에서 긋는다. 실무에서는 기능을 Must-have / Should-have / Nice-to-have 세 층으로 나누고, Must-have만 남기는 방식이 반복적으로 쓰인다. Should-have와 Nice-to-have는 제거가 아니라 보류로 처리하는 것이 핵심인데, 이 둘을 지금 없애야 할 대상이 아니라 "지금은 필요 없는 것"으로 구분해두면 이후 재논쟁을 줄일 수 있다.

이때 자주 쓰이는 질문은 "이 기능이 없어도 사용자가 성공 순간에 도달하는가", "이건 핵심 루프를 가능하게 하는가, 아니면 단지 더 좋게 만드는가"다. 두 질문에 모두 '아니오/더 좋게 만듦'으로 답이 나오면 그 기능은 이번 범위에서 빠진다. 반대로 코어 유저 여정을 완성하는 경로를 먼저 그린 뒤, 그 경로에 없는 단계는 전부 뒤로 미루는 흐름이 2026년 실무 프레임에서 계속 반복된다. 역할 관리, 관리자 도구, 추가 통합, 권한 세분화, 확장성 대비 기능은 핵심 검증 이전에는 대부분 제외 대상으로 분류된다. 경쟁사가 그 기능을 갖고 있다는 사실 자체는 포함 사유가 되지 않는다는 관점도 반복적으로 등장하는데, 복제 기능이 핵심 가설 검증과 직접 연결되지 않으면 컷하는 쪽이 일반적인 흐름이다.

자동화는 언제까지 미뤄도 되나?

자동화는 사람이 대신할 수 있는 동안은 미뤄도 되는 항목으로 다뤄진다. 초기 사용자 몇 명을 상대로는 백오피스 자동화 없이 수동 운영으로 결과만 확인하라는 제안이 2026년에도 강하게 권장된다. 예를 들어 매칭 로직, 알림 발송, 정산 처리 같은 작업을 처음 며칠은 스프레드시트와 사람 손으로 처리해도, 검증하려는 가설 자체는 훼손되지 않는 경우가 많다.

이 접근의 핵심은 "자동화를 뺐을 때 핵심 여정이 끊기는가"를 먼저 확인하는 것이다. 끊기지 않는다면 자동화는 검증 이후 문제로 넘긴다. 반대로 자동화 없이는 사용자가 핵심 흐름을 아예 완주할 수 없는 경우—예컨대 실시간 계산이 서비스 가치의 전부인 제품—라면 이 항목은 Must-have로 남는다. 즉 자동화 여부를 가르는 기준도 앞서 말한 "핵심 여정 완주 가능성"과 같은 축 위에 있다.

성공 여부는 어떤 지표로 판단하나?

판단은 대시보드가 아니라 하나의 학습 지표로 한다. 결과를 볼 수 있는 단일 지표를 미리 정하고, MVP가 작동했는지 여부는 "이 숫자가 움직였는가"로만 확인하는 구조가 실무 글에서 반복적으로 강조된다. 여러 지표를 동시에 추적하면 어떤 신호가 결정적이었는지 구분하기 어려워지고, 결국 판단이 미뤄지는 부작용이 생긴다.

지표 하나를 고르는 기준은 "그 숫자가 움직이면 핵심 가설이 참인지 거짓인지 알 수 있는가"다. 가입자 수나 방문 횟수처럼 여러 요인이 섞인 지표보다는, 완주율이나 재사용률처럼 핵심 여정과 직결된 지표가 선호된다. 이 지표를 미리 정해두지 않으면, MVP 출시 후에도 "성공했는가"를 두고 팀 내부에서 다른 기준으로 논쟁하게 되는 경우가 흔하다.

범위가 과하다는 신호는 언제 나타나나?

신호는 대개 두 가지로 나타난다. 하나는 구축 기간이다. 잘 스코프된 MVP는 보통 몇 주 안에 만들 수 있어야 하고, 완성까지 6개월이 걸린다면 그것은 MVP가 아니라 이미 v1에 가깝다고 보는 시각이 있다. 다른 하나는 기능 수다. 2026년 실무 자료 중 하나는 핵심 기능을 1~5개, 이상적으로는 1개에 가깝게 좁히라고 제시하는데, 이는 기능 수 자체를 줄이라는 뜻이 아니라 핵심 가설을 가장 적은 기능으로 검증하라는 방향이다.

범위 과잉을 확인하는 실전 질문은 "지금 범위에서 30%를 잘라도 핵심 가설을 검증할 수 있는가"다. 이 질문에 "그렇다"고 답할 수 있다면 현재 범위는 과한 것이다. 핵심 루프를 5단계 이하로 짧게 그려본 뒤, 그 루프에 직접 기여하지 않는 항목을 모두 보류·컷 처리하는 방식도 같은 맥락에서 쓰인다. 이 기준들은 서로 다른 이야기가 아니라 결국 하나—핵심 여정과 무관한 것은 남기지 않는다—로 수렴한다.

이 컷 기준은 어떤 팀에 맞고, 어떤 경우엔 다르게 가야 하나?

이 기준은 아직 핵심 가설이 검증되지 않은 초기 단계, 팀 규모가 작아 의사결정 속도가 빠른 조직에 잘 맞는다. 사용자가 누구인지, 어떤 문제를 어떻게 푸는지가 명확하지 않을 때는 기능을 최대한 줄여 빠르게 신호를 확인하는 편이 유리하다.

반대로 규제 산업, 보안·개인정보가 초기부터 필수인 도메인, 혹은 계약형 B2B 판매처럼 첫 고객이 특정 기능 없이는 아예 계약하지 않는 구조라면 접근이 달라진다. 이런 경우 "핵심 여정에 필요 없다"고 판단한 항목이 실제로는 판매 전제조건인 경우가 있어, 컷 기준을 그대로 적용하면 검증 자체가 불가능해질 수 있다. 이럴 때는 핵심 가설의 정의를 "제품이 작동하는가"에서 "이 조건에서 팔리는가"로 바꾸고, Must-have의 범위를 그에 맞게 다시 그리는 편이 낫다.

결국 무엇을 기준으로 컷을 결정하나?

기준은 세 가지로 요약된다. 첫째, 핵심 문제를 직접 푸는가. 둘째, 사용자가 핵심 여정을 처음부터 끝까지 완주할 수 있는가. 셋째, 그 결과를 하나의 지표로 측정할 수 있는가. 이 세 가지에 모두 "그렇다"고 답할 수 있는 항목만 남기고, 나머지는 제거가 아니라 보류로 문서화해두는 것이 실무적으로 안정적인 방식이다. 잘린 기능을 백로그에 남기고 언제 다시 검토할지 적어두면, 같은 논쟁이 반복되는 것을 줄일 수 있다.