MVP 범위 정하기, 첫 버전에서 뺄 것과 남길 것

MVP 범위를 정한다는 건 첫 버전에 넣을 기능을 고르는 게 아니라, 뺄 기능을 골라내는 일이다. 기준은 하나다. 이 기능이 없으면 우리가 검증하려는 핵심 가치가 성립하지 않는가. 그렇다면 남기고 없어도 핵심이 돌아가면 다음 버전으로 미룬다. MVP는 이름과 달리 제품을 최소로 깎는 것이 아니라, 가장 적은 노력으로 가장 많이 배우는 버전을 만드는 일이기 때문이다.

핵심 요약

• MVP 범위의 판단 기준은 단 하나다. 그 기능이 없으면 검증하려는 핵심 가치가 성립하지 않는가. 그렇다면 필수, 아니면 다음 버전으로 미룬다.
• MVP는 작은 제품이 아니라 가장 적은 노력으로 배움을 얻는 제품이다. 배움에 필요한 기능은 남기고 편의·완성도는 미룬다.
• 서비스 유형마다 절대 빼면 안 되는 최소 기능이 다르다. 예약형은 예약 확정과 중복 방지, 커머스형은 결제와 주문 확인이 그런 축이다.
• 기능 목록에 '핵심 검증에 필수인가'를 하나씩 달아 아니오를 걸러내면, 첫 버전 범위가 눈에 띄게 줄고 출시가 앞당겨진다.

MVP 범위란 무엇을 정하는 일인가

MVP는 'Minimum Viable Product', 최소 기능 제품이다. 이 개념을 대중화한 에릭 리스는 MVP를 "팀이 최소한의 노력으로 고객에 대한 검증된 배움을 최대로 모을 수 있게 하는 신제품의 버전"이라고 정의한다(Lean Startup, What Is an MVP?). 여기서 핵심은 검증된 배움이다. 잘 팔릴지, 사람들이 실제로 쓸지를 최소 비용으로 확인하는 게 목적이지 제품을 작게 만드는 것 자체가 목적이 아니다.

그래서 리스는 MVP가 이름과 달리 최소한의 제품을 만드는 일이 아니라고 못박는다. 범위를 정할 때 "뭘 넣을까"가 아니라 "무엇을 확인하려는가"부터 물어야 하는 이유다. 확인하려는 게 정해지면 그걸 확인하는 데 필요한 기능만 남고 나머지는 자연히 뒤로 밀린다. 기능은 하나 늘 때마다 기획·디자인·개발·테스트가 함께 붙는다. 첫 버전이 커질수록 출시는 몇 주씩 밀리고 검증도 그만큼 늦어진다. 왜 처음부터 다 만들면 안 되는지는 MVP 개발 글에서 다뤘으니 이 글은 그다음 문제인 범위를 어디서 자르나에 집중한다.

무엇을 남기고 무엇을 미루나

남길지 미룰지는 취향이 아니라 기준으로 가른다. 한 문장이면 된다. "이 기능을 빼면 핵심 가치를 검증할 수 있는가?" 검증이 막히면 남기고 검증은 되는데 불편할 뿐이면 미룬다. 아래 표는 같은 기능이라도 어느 쪽으로 가는지 예로 정리한 것이다.

구분	첫 버전에 남긴다	다음 버전으로 미룬다
판단 기준	없으면 핵심 가치 검증 불가	없어도 검증은 됨(편의·완성도)
가입·로그인	주문·예약에 꼭 필요한 최소 인증	소셜 로그인 여러 종, 프로필 꾸미기
결제	실제 돈이 오가는 한 가지 수단	여러 결제사, 포인트·쿠폰
관리	운영자가 주문·글을 확인하는 최소 화면	통계 대시보드, 권한 세분화
디자인	흐름이 이해되는 수준	애니메이션, 다크 모드

표에서 보이듯 같은 로그인도 주문에 필수인 최소 인증은 남기고 소셜 로그인 여러 종은 미룬다. 핵심은 기능 이름이 아니라 그 기능이 검증을 막느냐다. 그래서 팀이나 개발사에 물을 때도 "이 기능을 빼면 검증에 문제가 생기나요?"라고 물으면 답이 빨리 갈린다. 무엇을 검증할지부터 흐릿하면 이 판단이 안 서니 목표를 숫자로 바꾸는 법은 웹사이트 목표 설정 글이 도움이 된다.

유형별 절대 빼면 안 되는 최소 기능

핵심만 남기라는 말은 유형을 만나야 구체적이 된다. 서비스 종류마다 이게 빠지면 서비스라고 부를 수 없는 축이 있다. 자기 유형에서 아래 항목이 첫 버전에 들어가는지부터 확인하면 된다. 내 아이디어가 어느 유형인지 헷갈리면 웹서비스 종류 글로 먼저 가른다.

• 예약형(병원·미용·수업): 시간대 선택, 예약 확정 안내, 같은 시간 중복 예약 막기. 이 셋이 없으면 예약이 아니다.
• 커머스형(쇼핑몰): 상품 보기, 결제, 주문 내역 확인. 돈이 실제로 오가고 확인돼야 검증이 된다.
• 콘텐츠형(매체·블로그): 글 발행, 목록·상세 보기, 검색이나 분류 하나. 읽는 흐름이 끊기면 남는 게 없다.
• 커뮤니티형: 글쓰기, 다른 사람 글 읽기, 최소한의 신고·삭제. 사람이 모이면 관리 장치 하나는 처음부터 있어야 한다.
• 도구형(계산기·변환기 등): 입력, 처리, 결과. 곁가지를 다 빼도 이 세 단계는 남는다.

다만 이 최소 기능마저 대충 만들면 안 된다. 개수는 줄이되 남긴 기능은 끝까지 제대로 돌아가야 검증에 쓸 수 있다. 예약형에서 예약 확정 안내를 넣기로 했다면, 화면 수는 줄이더라도 확정과 중복 방지만큼은 실제로 작동해야 한다.

자주 하는 오해

범위를 좁힐 때 흔히 걸리는 오해가 있다.

• MVP를 대충 만든 시제품으로 여기지만 핵심 흐름은 실제로 돌아가야 한다. 배움을 얻으려면 사용자가 진짜로 써 봐야 하기 때문이다.
• 기능이 많을수록 반응이 좋으리라 기대하지만 기능이 늘면 출시가 밀리고 반응이 어느 기능 때문인지도 흐려진다. 검증이 오히려 어려워진다.
• 지금 빼면 영영 못 넣는다고 걱정하지만 미루는 것이지 버리는 게 아니다. 다음 버전 목록에 적어 두면 된다.

범위를 정하는 순서

말로는 쉬운데 막상 자르려면 손이 안 나간다. 다음 순서로 하면 감정이 아니라 기준으로 자를 수 있다.

1. 이번에 확인할 것 하나를 문장으로 적는다. "사람들이 이 가격에 예약까지 하는가"처럼 검증할 가설을 정한다.
2. 기획서의 기능을 목록으로 펼친다. 머릿속이 아니라 종이에 다 꺼낸다.
3. 기능마다 이걸 빼면 1번 검증이 막히는지를 예·아니오로 단다. 팀이나 개발사에 "이 기능을 빼면 검증에 문제가 생기나요?"라고 물어도 좋다.
4. 아니오는 다음 버전 목록으로 옮긴다. 예만 남은 것이 첫 버전 범위다.

이때 아깝다는 이유로 예를 남발하면 목록이 다시 부푼다. 판단이 흐려질 땐 '이번 검증'이라는 말을 되뇌면 된다. 다음에 언젠가 쓸 기능이 아니라, 이번에 확인할 것 하나에 붙는 기능인지만 본다. 그 하나에 안 붙으면 아무리 좋아 보여도 다음 버전이다.

가상 예시로, 동네 요가원이 온라인 예약을 검증하려 한다고 하자(가상 예시다). 처음 기획서에는 회원 등급, 포인트, 후기, 강사 프로필, 예약이 다 들어 있었다. '이 가격에 예약까지 하는가'를 확인하는 게 목표였으므로 예약·시간대·중복 방지·확정 안내만 예로 남고 나머지는 다음 버전으로 갔다. 범위가 줄자 개발 기간이 짧아졌다. 예약 전환율이라는 답도 몇 주 만에 나왔다. 이런 웹앱형 서비스의 구성이 궁금하면 웹앱 개발 서비스 안내를 참고하거나 기능 목록을 들고 문의로 상담해도 된다.