MVP 핵심 기능, 제작 전에 사용자 행동 하나로 고르는 법

로그인, 채팅, 결제, 통계를 적다 보면 작은 앱도 금세 커진다. MVP 핵심 기능은 사용자 한 사람이 어떤 일을 끝내야 하는지부터 고른다. 여기서 ‘하나’는 버튼 개수가 아니다. 신청부터 저장, 담당자 확인까지 필요한 흐름은 함께 남겨야 한다.

MVP는 고객에게 가치를 전달할 수 있는 최소한의 제품을 만들어, 실제 반응으로 가정을 확인하는 접근이다. 만들기 쉬운 기능부터 고르면 화면은 완성돼도 확인하려던 질문은 남을 수 있다. 아래에서는 가상의 방문 견적 서비스를 예로, 이번에 만들 것과 미룰 것을 나눠본다.

MVP 핵심 기능보다 먼저 검증할 질문을 쓴다

첫 줄에 “어떤 기능을 만들까?” 대신 “누가 무엇을 하려다 막히는가?”를 적어보자. 대상과 문제가 정해져야 같은 신청폼도 필요한지 판단할 수 있다.

Lean Startup의 방법론은 제품을 만들 수 있는지와 만들어야 하는지를 구분한다. 문제를 정하고 만들기·측정·학습을 이어가는 방식이다. 의뢰서에는 이를 사용자와 행동, 확인할 자료로 풀어 쓰면 된다.

정할 것	가상 방문 견적 서비스의 첫 답
대상과 문제	방문 견적을 받고 싶지만 가능한 시간을 전화로 맞추기 어려운 고객
사용자 행동	희망 시간과 작업 종류를 보내고 접수 여부를 확인한다
담당자 후속	요청을 읽고 방문 가능 여부를 전달한다
확인할 질문	서비스 가능 지역에서 실제로 처리할 수 있는 신청이 생기는가

이 가정이라면 신청 접수와 담당자 확인이 먼저다. “온라인에서 돈을 낼 의사가 있는가?”가 질문이라면, 신청 건수만으로 답할 수 없다. 결제 조건을 설명하고 실제 거래가 성립하는지 별도로 확인해야 한다.

핵심 연동이 가능한지조차 모르는 상황도 있다. 이때는 화면을 늘리기 전에 해당 연동부터 시험하는 편이 맞다. GOV.UK의 alpha 안내도 가장 위험한 가정을 먼저 시험하도록 설명한다. 다만 이 문서는 정부 서비스의 비공개 시제품 단계에 관한 안내이며, 그 일정과 공개 정책을 모든 앱에 적용하는 것은 아니다.

필수 기능과 수작업, 보류 기능을 나눈다

Y Combinator의 MVP 강의는 초기 사용자의 중요한 문제에 기능을 좁히고, 만들 범위를 문서로 남기도록 권한다. 범위를 줄일 때는 기능 이름에 줄을 긋기보다 이번 질문에 왜 필요한지를 붙이는 편이 도움이 된다.

구분	방문 견적 예시	남기거나 미루는 이유
이번에 구현	신청 입력, 저장, 접수 결과, 담당자 조회	신청이 실제로 전달됐는지 확인하는 데 필요하다
사람이 처리	가능 시간 확인과 확정 안내	초기 요청을 담당자가 처리할 수 있다는 가정이다
조건부 보류	회원 등급, 채팅, 통계 대시보드	이번 질문에 필수인지 아직 확인되지 않았다

보류 조건도 적어두자. 반복 고객의 이전 신청 확인이 필요해지면 회원 기능을 검토할 수 있다. 반복 문의가 기존 연락 수단으로 처리되지 않을 때는 채팅이나 안내 개선을 비교할 수 있다. 단순히 다른 서비스에 있다는 이유로 추가하지 않는다.

접근 권한과 데이터 보호는 보류 기능과 다르다. 신청 목록을 담당자에게만 보여줘야 한다면, 권한 확인은 첫 버전의 필수 범위다. 필수값 누락이나 저장 실패를 성공처럼 안내하지 않는 것도 같은 이유로 남긴다.

사람의 후속 처리도 서비스 범위에 넣는다

신청을 담당자가 확인하는 방식으로 시작할 수는 있다. 다만 화면에는 ‘예약 확정’이 아니라 실제 상태에 맞는 ‘신청 접수’라고 안내해야 한다. 언제 어떤 방법으로 다음 안내를 받을지도 정한다.

의뢰서에는 담당자, 처리 가능한 시간대, 응답 기준, 요청을 놓쳤을 때 확인할 곳을 적어보세요. 담당자 화면에서 보기만 하면 끝인지, 고객에게 따로 연락해야 끝인지도 구분한다. 사람이 처리하는 시간이 남으면 그 시간을 운영 부담으로 기록한다.

담당자가 신청을 감당할 수 없거나 즉시 확정이 서비스의 핵심 약속이라면 답이 달라진다. 신청 대상을 좁히거나, 처리 방식을 바꾸거나, 필요한 자동화를 첫 범위에 넣어야 한다. 수작업은 모든 서비스에서 더 나은 선택이라는 뜻이 아니다.

납품 검수와 고객 반응은 따로 확인한다

앱이 약속대로 작동하는지 먼저 확인한다. 아래 표는 실제 앱에서 통과한 결과가 아니라, 제작자와 맞춰볼 검수 예시다. 고객 정보 대신 가상 데이터로 시작한다.

시험 상황	확인할 결과
정상 신청	저장된 내용과 접수 화면이 일치하고 담당자가 조회할 수 있다
필수값 누락	빠진 항목을 알려주며 완료로 안내하지 않는다
저장 실패	성공 문구를 띄우지 않고 다시 시도할 방법을 안내한다
권한 없는 조회	다른 사람의 신청 내용이 노출되지 않는다

이 검수가 끝나도 사업의 수요가 확인된 것은 아니다. 공개 후에는 안내를 본 사람, 신청한 사람, 처리 조건에 맞는 신청, 실제 주문을 나눠 기록해야 한다. 버튼 클릭을 결제나 유효 문의로 바꾸어 세지 않는다.

가령 ‘적합한 신청’은 서비스 가능 지역과 작업 종류, 필요한 연락 조건을 충족한 요청이라고 미리 정할 수 있다. 신청 수가 많아도 대부분 처리할 수 없다면, 기능 추가보다 대상과 안내를 먼저 고칠 이유가 된다.

결과를 보기 전에 다음 결정을 정한다

관찰 기간, 대상을 만나는 경로, 볼 행동, 중단할 오류를 시험 전에 적는다. 누구에게 얼마나 보여줄 수 있는지 모르면 모든 서비스에 같은 성공률을 붙이기 어렵다. 관측할 기회가 적었을 때는 수요가 없다는 결론도 미뤄야 한다.

다음은 PDF에 넣은 가상 판단 예시다. 실제 고객이나 이 블로그의 성과 수치가 아니다.

• 적합한 신청이 생겼지만 담당자 확인에서 오래 멈춘다: 새 화면을 추가하기 전에 후속 처리를 고친다.
• 기능은 작동하지만 약속한 대상에게 거의 보여주지 못했다: 수요 판단을 보류하고 관찰 경로를 확인한다.
• 신청 내용이 다른 사용자에게 보이거나 저장 누락이 생긴다: 모집 확대를 멈추고 문제를 수정한다.
• 반복 고객에게 같은 불편이 확인된다: 보류한 기능 중 그 문제를 해결하는 후보만 다시 비교한다.

같은 길이의 두 기간을 비교하더라도 방문 경로와 대상, 가격이나 안내가 달라졌다면 차이를 적는다. 전후 숫자만으로 어떤 기능이 결과를 만들었다고 단정하지 않는다.

PDF 한 장부터 작성해 의뢰 범위를 맞춘다

MVP 핵심 행동·범위·검수 기록표 PDF는 4쪽이다. 앞의 2쪽은 사용자 질문·의뢰 범위·검수 계획을 적는 빈 양식이고, 뒤의 2쪽은 가상 작성 예시와 판단 연습이다. 인쇄해서 쓰는 필기용이며 입력 가능한 PDF 양식은 아니다.

이미지는 이 글의 PDF를 렌더링한 작성 예시다. 실제 서비스 화면이나 납품 결과가 아니다. 먼저 ‘누가 어떤 결과에 도착하는가’ 한 줄을 쓴 뒤, 빠지면 그 결과에 도착하지 못하는 기능만 남겨보세요.

범위가 정리됐다면 외주 견적 비교 항목에서 포함·제외 조건을 맞출 수 있다. 직접 작은 동작부터 만들어보고 싶다면 첫 프로젝트 가이드로 이어가면 된다. 관련 실습은 바이브코딩 가이드에서 모아볼 수 있다.

검증 기준

• 마지막 업데이트일: 2026-09-08
• 확인 환경: 아래 공개 원문을 읽고 구성한 의뢰·설계 가이드. PDF의 글자·표·페이지를 렌더링해 확인했다. 가상 서비스의 앱 구현·사용자 테스트·고객 납품은 실행하지 않았다. 생성 대표 이미지는 개념 삽화다.
• 주요 근거: Lean Startup 방법론, Y Combinator의 MVP 계획 강의 원문, GOV.UK alpha 단계 안내