MVP 기능 우선순위, 남길 것과 버릴 것 가르기

첫 버전을 만들 때 가장 어려운 건 기능을 고르는 일이 아니라 버리는 일이다. 아이디어는 늘 기능 목록을 부풀리고 그 목록을 그대로 개발하면 출시가 한없이 밀린다. 그래서 필요한 건 우선순위를 매기는 기준이다. 몇 가지 도구를 쓰면 감정이 아니라 규칙으로 자를 수 있다.

---

단일 판단 기준: 검증을 막는가

---

가장 단순한 기준부터 보자. "이 기능을 빼면 이번에 확인하려는 핵심 가치가 성립하지 않는가." 성립이 막히면 남기고 없어도 검증은 되는데 불편할 뿐이면 미룬다. 예를 들어 예약 서비스라면 예약 확정과 중복 방지는 빠지면 서비스가 아니지만 적립 포인트는 없어도 "이 가격에 예약하는가"를 확인하는 데 지장이 없다. 전자는 남고 후자는 다음 버전이다.

---

남기는 신호와 미루는 신호

---

기준을 표로 정리하면 판단이 빨라진다. 기능을 하나씩 대보고 왼쪽에 걸리면 남기고 오른쪽이면 다음 버전으로 내린다.

| 남긴다 | 미룬다 |
|---|---|
| 없으면 핵심 검증이 막힌다 | 없어도 검증은 된다 |
| 돈·예약이 실제로 오간다 | 편의·완성도를 높인다 |
| 그 유형의 필수 축이다 | 곁가지·선택 기능이다 |

---

MoSCoW로 한 번 더 거른다

---

기능이 많을 땐 네 칸으로 나누는 방법이 쓸 만하다. 반드시 있어야 하는 것(Must), 있으면 좋은 것(Should), 없어도 되는 것(Could), 이번엔 안 하는 것(Won't). 첫 버전에는 Must만 넣는다. Should와 Could는 다음 버전 목록으로 내리고 Won't는 아예 접어둔다. 앞의 단일 기준으로 남긴 기능을 다시 이 표에 넣어보면, Must가 생각보다 적다는 걸 알게 된다.

---

유형별로 빠지면 안 되는 최소 기능

---

핵심만 남기라는 말은 유형을 만나야 구체적이 된다. 아래는 유형별로 첫 버전에서 빠지면 안 되는 축이다.

• 예약형: 시간대 선택, 예약 확정 안내, 같은 시간 중복 예약 막기.
• 커머스형: 상품 보기, 결제, 주문 내역 확인.
• 콘텐츠형: 글 발행, 목록·상세 보기, 검색이나 분류 하나.
• 커뮤니티형: 글쓰기, 남의 글 읽기, 최소한의 신고·삭제.
• 도구형: 입력, 처리, 결과.

주의할 점이 있다. 개수는 줄이되 남긴 기능은 끝까지 제대로 돌아가야 한다. 범위를 좁히는 것과 핵심을 부실하게 만드는 것은 다른 이야기다. 예약 확정을 넣기로 했다면 화면 수는 줄여도 확정과 중복 방지만큼은 실제로 작동해야, 사용자가 써보고 답을 준다.

현실에서는 Must끼리도 경쟁한다. 개발 시간이 한정되면 Must 안에서도 가장 위험한 가정을 검증하는 것부터 만든다. 예약 서비스라면 "사람들이 이 가격에 예약을 하는가"가 "결제가 매끄러운가"보다 먼저다. 어느 가정이 틀렸을 때 서비스 자체가 흔들리는지를 기준으로 순서를 잡으면, 같은 Must 안에서도 무엇을 먼저 만들지가 정해진다.

---

자르는 순서 한 가지

---

실무에서는 순서를 정해두면 손이 나간다. 먼저 이번에 확인할 가설 한 문장을 적고 기획서 기능을 종이에 모두 펼친 뒤, 기능마다 "빼면 이 가설 검증이 막히나"를 표시한다. 막히는 것만 남기고 나머지는 다음 버전 목록으로 옮긴다. 아깝다는 이유로 남발하면 목록이 다시 부푸니, 판단이 흐려질 때는 "이번 검증"이라는 말만 되뇌면 된다.

Q. MVP는 최대한 적은 기능만 넣으면 되나요?
개수가 목표가 아닙니다. 이번 검증에 필요한 기능이면 남기고 아니면 빼는 것이라, 유형에 따라 서너 개일 수도 예닐곱 개일 수도 있습니다. 숫자보다 남은 기능이 하나의 검증 목표로 묶이는지가 중요합니다.

Q. 뺀 기능은 나중에 넣기 어렵지 않나요?
처음부터 다음 버전을 염두에 두고 만들면 대개 무리 없이 붙습니다. 미룬 기능은 버린 게 아니라 목록에 적어둔 것이라, 첫 버전 반응을 보고 우선순위대로 더하면 됩니다.

원문: https://nova-lab.dev/r/t/mvp-scope-first-version

---

자주 묻는 질문

---

Q. MVP 범위는 기능을 몇 개까지 넣어야 적당한가요?

개수로 정하는 게 아니라 기준으로 정합니다.

이 기능이 없으면 이번에 확인하려는 핵심 가치가 성립하지 않는가를 물어, 그렇다는 것만 남기면 됩니다.

그러면 유형에 따라 서너 개가 될 수도, 예닐곱 개가 될 수도 있습니다.

중요한 건 숫자가 아니라 남은 기능이 하나의 검증 목표로 묶이는지입니다.

 

Q. MVP는 대충 만들어도 되나요?

범위는 좁히되 완성도는 낮추지 않는 게 맞습니다.

핵심 흐름은 사용자가 실제로 끝까지 써 봐야 배움이 나오기 때문입니다.

예를 들어 예약을 검증한다면 예약 화면 수는 줄이더라도 예약이 실제로 확정되고 중복이 막히는 것까지는 제대로 돌아가야 합니다.

곁가지 기능을 빼는 것과 핵심을 부실하게 만드는 것은 다릅니다.

 

Q. 지금 뺀 기능은 나중에 넣기 어렵지 않나요?

처음부터 다음 버전을 염두에 두고 만들면 대부분 무리 없이 붙일 수 있습니다.

미룬 기능은 버리는 게 아니라 목록에 적어 두는 것이라, 첫 버전에서 얻은 반응을 보고 우선순위대로 더하면 됩니다.

오히려 반응을 보고 넣으면 안 쓸 기능에 미리 돈을 묶지 않아도 됩니다.

글 · 노바랩 NovaLab · https://nova-lab.dev