MVP에 넣을 기능은 어떻게 고를까

MUST — 이게 없으면 가설을 확인할 수 없다

검증하려는 가설 하나를 문장으로 적고, 그 문장을 확인하는 데 반드시 필요한 기능만 넣습니다. 예를 들어 "사람들이 이 조건으로 예약을 잡는가"가 가설이라면 조건 입력과 예약 확정까지가 MUST이고, 예약 취소 정책 화면은 아닙니다. 판단 기준은 "없으면 불편한가"가 아니라 "없으면 확인이 불가능한가"입니다.

• 가설을 확인하는 데 직접 쓰이는 화면
• 그 화면이 동작하려면 반드시 있어야 하는 데이터 입력·저장
• 결과를 운영자가 확인할 최소 수단(목록 조회 정도)

SHOULD — 초기 운영에는 유용하지만 첫 출시에는 없어도 된다

서비스가 돌아가기 시작하면 곧 필요해지지만, 없다고 해서 가설 검증이 막히지는 않는 기능입니다. 초기에는 사람이 손으로 처리하고, 반복이 확인되면 그때 만듭니다. 이 칸의 기능을 MUST로 올리는 순간 범위가 두 배가 되는 경우가 많습니다.

• 관리자에서의 수정·삭제·상태 변경(초기에는 직접 데이터 수정으로 대체 가능)
• 통계·리포트 화면
• 알림 자동화(초기에는 수동 발송으로 대체 가능)
• 검색·필터 고도화

LATER — 사용자 반응을 본 뒤 정한다

지금 만들면 대부분 다시 만들게 되는 기능입니다. 실제 사용 패턴을 보기 전에는 어떤 형태여야 하는지 알 수 없기 때문입니다. LATER는 "안 만든다"가 아니라 "지금 결정하지 않는다"는 뜻입니다.

• 추천·개인화
• 포인트·등급 같은 리텐션 장치
• 다국어
• 외부 시스템과의 양방향 연동
• 역할 세분화(권한을 잘게 쪼개는 작업)

자주 잘못 분류되는 기능들

세 가지가 습관적으로 MUST에 들어갑니다. 로그인은 "누가 썼는지 알아야 한다"는 이유로 들어가지만, 가설이 "이 흐름을 사람들이 끝까지 진행하는가"라면 익명으로도 확인됩니다. 결제는 "돈을 받아야 진짜 검증"이라는 이유로 들어가지만, 결제 의사는 사전 신청이나 계좌 안내로도 확인할 수 있습니다. 관리자 화면은 "운영해야 하니까"인데, 데이터가 하루 몇 건이면 초기에는 직접 처리하는 편이 빠릅니다. 반대로 운영자가 매일 손대야 하는 데이터가 있다면 관리자 화면은 그때부터 MUST입니다.

분류가 범위에 실제로 미치는 영향

기능 하나를 MUST에서 SHOULD로 내리는 것보다, 사용자 역할 하나를 줄이거나 외부 연동 하나를 미루는 쪽이 범위를 더 크게 줄입니다. 역할이 늘면 화면이 한 벌 더 생기고 권한 규칙과 테스트 경우의 수가 함께 늘어나기 때문입니다. 우선순위를 조정할 때는 기능 목록보다 역할 수와 연동 수를 먼저 보세요.

MVP 이후에 정하는 것

출시 후에는 LATER 목록을 그대로 꺼내는 것이 아니라, 실제 사용 데이터를 기준으로 다시 매깁니다. 예상과 다른 지점에서 사람들이 이탈하면 그 구간을 고치는 일이 새 기능보다 우선입니다. MVP의 목적은 기능을 적게 만드는 것이 아니라 이 판단 근거를 빨리 얻는 것입니다.

름랩에서는 이 분류를 어떻게 쓰나

상담에서 기능 목록을 받으면 먼저 위 세 칸으로 나누고, MUST만으로 1차 범위를 잡습니다. 사이트에 공개된 정액 패키지 기준으로는 핵심 화면 3~5개의 Flutter MVP(앱 라이트)가 VAT 포함 580만 원·약 14일, 회원·결제·관리자를 포함한 앱 스탠다드가 980만 원·약 21일입니다. SHOULD 이하를 1차에 넣을수록 이 범위를 넘어가므로, 무엇을 미룰 수 있는지부터 함께 정리합니다.