MVP 범위를 줄일 때 기능 수가 아니라 검증할 가설로 정하는 법

MVP의 범위는 기능 목록을 몇 개로 줄였는지가 아니라, 다음 결정을 내리기 위해 어떤 가설을 검증해야 하는지로 정해야 합니다. 사용자가 실제 문제를 겪는지, 제안한 해결책을 선택하는지, 운영 가능한 비용으로 제공할 수 있는지를 가설로 쪼갠 뒤 가장 위험한 하나를 가장 싼 실험으로 확인합니다.

따라서 MVP에서 빠지는 기능은 덜 중요한 기능이 아니라 아직 검증 순서가 오지 않은 기능입니다. 이 관점은 기획자에게 우선순위 근거를 주고, 개발자에게 필요한 최소 구현 경계를 알려 주며, 의뢰인에게 왜 특정 기능을 다음 단계로 미루는지 설명할 수 있게 합니다.

기능 수를 세면 범위가 줄지 않는 이유

기능 수는 개발량의 일부만 보여 줍니다. 로그인 하나도 인증 방식, 계정 복구, 권한, 개인정보 처리, 실패 화면을 포함하면 작은 일이 아닙니다. 반대로 운영자가 수동으로 처리할 수 있는 결과 화면은 코드가 거의 없어도 사용자가 핵심 가치를 판단하는 데 꼭 필요할 수 있습니다. 숫자를 줄이는 방식은 기능의 이름만 바꾸고 검증에 필요한 흐름을 놓치기 쉽습니다.

또한 기능 목록은 이미 정답을 알고 있다는 전제를 숨깁니다. ‘검색, 결제, 알림을 넣자’라고 쓰는 순간 팀은 그 기능을 만드는 일에 집중하지만, 실제로 확인해야 할 질문은 ‘고객이 이 문제를 지금 해결하기 위해 돈이나 시간을 쓸까?’일 수 있습니다. MVP는 축소된 완제품이 아니라 불확실성을 줄이는 학습 장치로 정의해야 합니다.

먼저 가설을 관찰 가능한 문장으로 바꿉니다

좋은 가설은 ‘사용자가 좋아할 것이다’처럼 취향을 묻지 않습니다. 누구에게, 어떤 상황에서, 어떤 행동이 일어나면, 무엇을 근거로 맞다고 판단할지를 한 문장에 담습니다. 예를 들어 ‘소상공인은 매주 반복되는 견적 문의를 직접 정리하기보다, 사진과 예산만 입력해 초안을 받는 흐름을 사용할 것이다’처럼 대상과 상황, 행동을 특정합니다.

Strategyzer는 사업 모델과 가치 제안이 성립하려면 무엇이 참이어야 하는지를 가설로 적고, 중요한 가설을 먼저 작은 실험으로 확인하라고 설명합니다. 이 원칙은 기능 우선순위에도 그대로 적용됩니다. 팀이 만들고 싶은 기능이 아니라 실패했을 때 사업 방향이 바뀌는 가설을 우선해야 합니다.

• 바람직성: 특정 사용자가 이 문제를 실제로 해결하려 하는가

• 실현 가능성: 제한된 기술과 운영 조건으로 약속한 결과를 낼 수 있는가

• 지속 가능성: 제공·지원·결제 비용을 감당할 수 있는가

• 신뢰와 안전: 사용자가 맡긴 데이터와 중요한 결과를 안전하게 다룰 수 있는가

위험도와 학습 가치를 함께 비교합니다

가설을 적었다면 각 항목의 불확실성과 실패 영향도를 따로 평가합니다. 불확실성은 팀이 얼마나 모르는지, 영향도는 틀렸을 때 방향·예산·신뢰가 얼마나 흔들리는지를 뜻합니다. 둘 다 높은 가설이 먼저입니다. ‘있으면 편한 다크 모드’는 불확실성이 낮고 실패 영향도도 작지만, ‘고객이 자동 산정 금액을 믿고 계약할 것’은 두 값이 모두 높을 수 있습니다.

다음으로 가설을 검증하는 데 필요한 최소 증거를 적습니다. 인터뷰 기록, 클릭 가능한 화면, 수동으로 만든 결과물, 결제 의향서, 제한된 실제 사용 로그가 각각 다른 질문에 답합니다. 증거를 먼저 정하면 기능이 아니라 실험을 예산에 넣게 되고, 자동화되지 않은 운영을 의도적으로 MVP 안에 둘 수 있습니다.

1. 가설을 한 문장으로 쓰고 대상·상황·행동·판정 기준을 붙입니다.

2. 틀렸을 때 바뀌는 의사결정과 손실을 적어 영향도를 표시합니다.

3. 가장 적은 시간과 비용으로 얻을 수 있는 증거를 고릅니다.

4. 실험을 실행하고 결과·해석·다음 질문을 한 장의 기록으로 남깁니다.

실험에서 필요한 것만 MVP에 남깁니다

실험을 기능으로 번역할 때는 ‘사용자가 가치 있는 결과를 얻는 데 반드시 필요한가’를 묻습니다. 핵심 화면이 필요하다면 화면을 만들되, 결과를 사람이 준비해도 되는지 확인합니다. 자동 추천을 검증하는 단계라면 추천 엔진 대신 운영자가 정한 결과를 보여 줄 수 있습니다. 이때 수동 처리는 부끄러운 임시방편이 아니라 어떤 자동화가 실제로 필요한지 알려 주는 측정 장치입니다.

반대로 인증, 권한, 결제, 개인정보, 되돌릴 수 없는 데이터 변경처럼 실패 비용이 큰 부분은 가설 검증을 위해서라도 대충 만들 수 없습니다. 범위를 줄인다는 말이 안전장치를 제거한다는 뜻은 아닙니다. 위험한 기능은 기능 수가 적어도 입력 검증, 오류 처리, 로그와 복구 경계를 MVP에 포함해야 합니다.

GOV.UK 서비스 매뉴얼도 해결책 전체를 만들기 전에 빠른 프로토타입으로 가설을 시험하고, 검증이 잘되지 않는 프로토타입은 버리며, 사용자의 문제를 해결하는지 확인하라고 안내합니다. 따라서 프로토타입에 생산 수준의 보안과 성능을 그대로 요구하지 않되, 실제 사용자가 판단해야 하는 상호작용은 충분히 현실적으로 보여 주는 식으로 경계를 정합니다.

예시: 견적 자동화 서비스의 첫 범위

가상 사례로 소규모 인테리어 업체를 위한 견적 자동화 서비스를 생각해 보겠습니다. 초기 기능 목록에는 사진 업로드, 자재 카탈로그, 자동 금액 계산, 고객 계정, 팀 권한, 카드 결제, PDF 발송, 알림, 통계 대시보드가 모두 들어 있습니다. 이 목록을 그대로 개발하면 제품은 커지지만, 고객이 자동 견적을 신뢰하는지는 여전히 모를 수 있습니다.

입력은 ‘업체 담당자가 문의 사진과 면적을 받으면 이틀 안에 견적 초안을 만들기 위해 평균 30분을 쓴다’는 관찰입니다. 검증할 핵심 가설은 ‘담당자는 사진·면적 입력 뒤 10분 안에 나온 초안을 수정해 고객에게 보낼 만큼 유용하다고 느낀다’로 정합니다. 자동 계산의 정확도보다 초안을 받아들이고 수정하는 행동이 먼저 확인할 위험입니다.

판단은 간단한 웹 입력 화면과 결과 화면으로 합니다. 사용자가 사진과 면적을 제출하면 백엔드 계산 대신 운영자가 미리 만든 세 가지 견적 템플릿 중 하나를 골라 10분 안에 결과를 보냅니다. 사용자가 결과를 수정해 고객에게 전송하는지, 어디서 멈추는지, 다시 쓰겠다고 말하는지를 기록합니다. 고객 계정·결제·실시간 카탈로그는 이 실험의 질문에 답하지 않으므로 첫 범위에서 제외합니다.

중간 산출물은 네 가지입니다. 첫째, 대상·행동·판정 기준이 한 줄에 있는 가설 카드입니다. 둘째, 입력과 결과만 연결한 클릭 가능한 화면입니다. 셋째, 담당자가 직접 고른 템플릿과 수정 이유를 담은 실험 기록입니다. 넷째, 다음 판단을 위해 ‘계속’, ‘가설 수정’, ‘중단’ 중 하나를 선택한 결정 로그입니다. 산출물을 남기면 다음 회의에서 느낌이 아니라 증거를 비교할 수 있습니다.

기대 결과는 자동화율이 아니라 다음 행동의 명확성입니다. 담당자가 반복해서 초안을 수정해 전송하고, 어떤 입력이 부족한지 설명하며, 다시 사용할 상황을 말한다면 계산 자동화 가설을 다음 실험으로 옮깁니다. 반대로 초안을 믿지 않거나 기존 엑셀보다 빠르지 않다면 자재 카탈로그부터 만들지 않고 문제 정의와 입력 품질을 다시 조사합니다.

실패했을 때 범위를 지키고 복구하는 방법

실험이 실패하면 팀은 두 가지 극단으로 흐르기 쉽습니다. 결과가 나쁘니 기능을 더 넣거나, 반대로 사용자가 틀렸다고 결론 내리고 실험을 끝내는 방식입니다. 먼저 실패 지점을 입력, 이해, 신뢰, 운영 응답 중 어디인지 분리합니다. 사진 형식 때문에 입력에서 막혔다면 가설이 틀렸다고 단정하기 전에 입력 안내를 고쳐 같은 가설을 재시도합니다.

복구는 결과를 숨기는 일이 아닙니다. 실험 버전, 대상 조건, 관찰된 행동, 실패한 단계, 바꿀 변수 하나, 재시도 날짜를 기록합니다. 같은 세션에서 화면·가격·대상·판정 기준을 모두 바꾸면 무엇이 영향을 줬는지 알 수 없으므로 한 번에 한 변수만 바꿉니다. 두 번 재시도해도 핵심 행동이 나오지 않으면 해당 가설을 보류하고 다른 문제를 조사하는 것이 안전한 fallback입니다.

특히 결제나 외부 발송처럼 되돌리기 어려운 작업은 실험에서 실제 실행하지 않고 테스트 계정·미리보기·승인 단계를 둡니다. 개인정보를 받는 순간에는 저장 목적과 보관 기간, 삭제 방법을 먼저 확인합니다. MVP라는 이유로 안전 요구를 뒤로 미루면 나중에 복구할 수 없는 신뢰 손실이 생기므로, 범위를 줄일 때도 실패 영향도가 큰 경계는 유지해야 합니다.

범위를 결정하는 회의용 체크리스트

회의에서는 기능 이름을 하나씩 찬반하기보다 아래 순서로 각 항목을 통과시킵니다. 모든 답이 완벽해야 한다는 뜻은 아니지만, 빈칸이 남은 항목은 ‘구현’이 아니라 ‘먼저 확인할 질문’으로 분류해야 합니다.

• 이 기능이 검증하려는 가설을 한 문장으로 말할 수 있는가

• 이 기능이 없어도 같은 가설에 답할 더 싼 실험이 있는가

• 사용자가 실제로 해야 할 행동과 관찰할 증거가 정해졌는가

• 실패하면 중단·수정·재시도 중 어떤 결정을 내릴지 적었는가

• 보안·권한·복구처럼 줄이면 안 되는 경계를 별도로 확인했는가

완료 조건은 ‘MVP 기능이 다 들어갔다’가 아닙니다. 우선순위가 가장 높은 가설, 그 가설을 검증할 실험, 입력에서 판단까지의 중간 산출물, 판정 기준, 실패 시 복구 방법이 문서에 남아 있어야 합니다. 그리고 정해진 대상이 실험을 재현할 수 있고, 결과에 따라 계속·수정·중단 중 하나를 기록했다면 해당 MVP 범위 결정은 검증 완료로 볼 수 있습니다.

작은 MVP는 기능이 적은 제품이 아니라 학습할 질문이 선명한 제품입니다. 다음 개발 항목을 추가하기 전에 이번 실험이 어떤 불확실성을 줄였는지 확인하고, 아직 답하지 못한 가장 위험한 가설을 다시 고르세요. 그렇게 하면 범위 축소가 일정 협상의 말이 아니라 다음 의사결정을 위한 증거 생산 과정이 됩니다.