9장. 우선순위: MoSCoW + RICE MVP
우선순위는 중요하다.
8장 유스케이스에 우선순위 부여하기
8장에서 정의된 유스케이스를 대상으로 우선순위를 부여하여, MVP(Minimum Viable Product - 최소 기능 제품) 범위를 확정한다.
우선순위는 MoSCoW 방법론과 RICE 스코어링을 결합하여 결정한다.
MoSCoW는 주관적 중요도를 구분하고, RICE는 정량적으로 비교 가능한 점수를 제공한다. 이 두 접근법을 결합하면, 감각적인 판단과 데이터 기반 판단을 균형 있게 유지할 수 있다.
이 과정의 목적은 제한된 인력과 시간 안에서 비즈니스 목표 달성에 가장 큰 영향을 주는 기능을 선별하는 것이다.
이번 프로젝트의 목표는 5장에서 정의한 NSM(월 거래액 3억 원)과 KPI(전환율 2.5%, 재구매율 35%, 장바구니 이탈률 60% 이하)이며, 모든 판단은 이 세 가지 지표를 기준으로 한다.
MoSCoW 방법론
MoSCoW는 네 가지 단계로 요구사항을 분류한다.
1. Must Have (필수)
서비스의 작동에 반드시 필요한 기능이다. 이 기능이 없으면 고객이 상품을 탐색하거나 구매할 수 없으며, 비즈니스 목표를 달성할 수 없다.
예를 들어, 고객이 상품을 조회하고 장바구니에 담고 결제까지 완료할 수 있도록 하는 일련의 흐름이 이에 해당한다.
2. Should Have (중요)
운영 효율과 사용자 경험 향상에 중요하지만, 임시 우회 방법이 있는 기능이다.
예를 들어, 쿠폰 적용이나 필터·정렬 같은 기능은 없더라도 수동 조작으로 대체 가능하다.
3. Could Have (보통)
서비스의 기본 작동에는 영향을 주지 않지만, 있으면 사용자 경험이나 운영 편의성을 높이는 기능이다.
재입고 알림, 상품 리뷰, 소셜 로그인, 추천 상품 등이 이에 해당한다.
4. Won’t Have (제외)
현재 범위에서는 의도적으로 제외되는 기능이다. 향후 확장 가능성이 있지만 이번 MVP에는 포함되지 않는다.
정기 구독, 멤버십 자동화, 멀티 PG 연동, 라이브커머스 등이 대표적인 예다.
이 네 가지 구분은 “이 기능이 없으면 고객이 상품을 구매할 수 있는가?”라는 질문으로 시작해, 비즈니스 영향도에 따라 Must에서 Won’t까지 단계적으로 분류된다.
RICE 스코어링
RICE는 기능을 네 가지 지표로 평가하여 (Reach × Impact × Confidence) ÷ Effort 공식을 적용하는 방법이다.
이를 통해 단순히 중요하다고 느껴지는 기능이 아니라, 실제 효율 대비 효과가 높은 기능을 우선적으로 구현할 수 있다.
RICE는 다음 네 가지 요소로 구성된다.
Reach (도달 범위)
일정 기간 동안 기능이 영향을 주는 사용자 수 또는 작업 횟수를 의미한다.
프론트오피스 기능은 월간 예상 사용자 수를 기준으로, 백오피스 기능은 월간 사용 빈도를 기준으로 산정한다.
예를 들어 상품 상세 페이지는 월 5,000명, 쿠폰 적용은 월 1,000명, CSV 등록은 월 50회로 계산할 수 있다.
Impact (영향력)
기능이 비즈니스 목표 달성에 미치는 영향을 평가한다.
전환율과 거래액에 직접적인 영향을 주는 기능은 높은 점수를, 운영 효율이나 경험 개선에 국한된 기능은 낮은 점수를 부여한다.
예를 들어 결제은 전환율에 직접 영향을 미치므로 영향력이 크고, 필터·정렬은 중간 정도로 본다.
Confidence (확신도)
해당 기능이 목표에 기여할 것이라는 확신 정도를 백분율로 표현한다.
인터뷰나 데이터로 이미 검증된 기능은 100%, 업계 표준에 근거한 기능은 80%, 아직 실험적이거나 추측에 가까운 기능은 50% 이하로 산정한다.
예를 들어 CSV 등록 기능은 운영팀 인터뷰를 통해 실효성이 검증되었으므로 100% 확신으로 평가할 수 있다.
Effort (작업량)
개발, 디자인, QA를 포함한 총 소요 리소스를 인월(Men/Month) 단위로 추정한다.
단순한 UI 변경은 0.5, 일반적인 CRUD 기능은 1, 복잡한 연동은 2, 결제나 보안 관련 기능처럼 복잡도가 높은 기능은 4 이상으로 본다.
RICE 점수 산정 및 역할 분담
RICE는 여러 담당자가 협업하여 산정해야 일관성을 유지할 수 있다.
각 항목의 책임은 다음과 같이 분담한다.
기획자 또는 PO(Product Owner)는 Impact와 Confidence를 결정한다.
데이터 분석가는 Reach를 추정한다.
개발 리더는 Effort를 산출한다.
이렇게 산정된 수치를 조합하여 RICE 스코어를 계산하고, PO가 최종 검토 후 팀 전체 회의에서 합의한다.
RICE 예시 계산
예를 들어 “결제”, “CSV 일괄 등록”, “재입고 알림” 세 가지 기능을 비교한다고 가정한다.
결제의 Reach는 3,000, Impact는 3, Confidence는 1.0, Effort는 4로 설정하면 RICE는 2,250이다.
CSV 일괄 등록의 Reach는 50, Impact는 2, Confidence는 1.0, Effort는 2로 설정하면 RICE는 50이다.
재입고 알림의 Reach는 500, Impact는 1, Confidence는 0.5, Effort는 2로 설정하면 RICE는 125이다.
이 경우 결제가 가장 높은 우선순위를 갖는다.
MoSCoW와 RICE의 결합
RICE로 계산된 점수를 그대로 사용할 수도 있지만, 팀의 전략적 중요도나 제약을 반영하기 위해 MoSCoW 분류를 우선 적용한다.
먼저 모든 유스케이스를 Must, Should, Could, Won’t로 분류한다.
Won’t 항목은 우선순위 평가에서 제외한다.
각 카테고리 내에서 RICE 점수를 계산하고 순서를 정한다.
이 순서를 기준으로 다음과 같이 P단계를 부여한다.
P0: Must Have 중 RICE가 높은 항목
P1: Should Have 중 RICE 상위 50%
P2: Should 하위 50%와 Could 상위 항목
P3: Could 하위 항목
이렇게 하면 기능의 중요도와 효율성을 모두 고려한 객관적인 우선순위를 도출할 수 있다.
MVP 범위 확정
P0와 P1 단계의 기능을 합쳐 MVP 범위로 정의한다. 이 범위가 실제 8주 개발 일정 안에서 가능한지 Effort 총합으로 검증한다.
예를 들어 P0의 Effort 합계가 12m/m, P1이 5m/m이라면 총 17m/m이 된다.
개발 인력 3명이 8주(약 2개월) 동안 일하는 경우, 가용률 80%를 고려하면 실제 가용 Effort는 약 4.8m/m 수준이다. 따라서 17m/m은 현실적으로 불가능하므로, 범위를 조정해야 한다.
조정 방법은 세 가지다.
첫째, P0 일부 기능을 간소화한다. 예를 들어 결제 기능에서 간편 결제를 제외하고 기본 PG만 연동한다.
둘째, 일정을 10주로 늘린다.
셋째, 인력을 4명으로 증원하여 분산한다.
팀 협의 결과, 핵심 기능만 포함해 8주 안에 완료하고, 나머지는 2차 릴리즈로 미루기로 결정한다.
우선순위의 시각적 관리
RICE와 MoSCoW 결과는 시각적으로 관리한다.
Impact와 Effort의 상대적 크기를 기준으로 “영향이 크고, 작업량이 적은 기능”을 상단에 배치한다.
가장 높은 위치의 기능이 MVP 핵심이다.
이 매트릭스는 노션, 피그잼, 미로(Miro) 등 협업 도구를 활용해 유지한다.
각 유스케이스 카드에는 RICE 점수와 P단계가 함께 표시된다.
리뷰 주기 및 변경 절차
우선순위는 고정된 문서가 아니다. 매주 팀 리뷰를 통해 진행 상황을 점검하고, 변경사항을 반영해야 한다.
리뷰에서는 다음 항목을 확인한다.
P0 기능 중 완료된 항목은 몇 개인가
Effort 추정치와 실제 개발 소요의 차이는 어느 정도인가
새로운 요구사항이 생겨 Must Have로 승격될 필요가 있는가
마케팅 일정, 이벤트, 외부 변수로 인해 순서 조정이 필요한가
필요시 P1 항목이 P0로 승격되거나, 일정 지연으로 P0 기능이 P1로 하향될 수 있다.
이 결정은 PO(Product Owner)가 담당하며, 모든 변경 사유와 일자는 우선순위 로그에 기록된다.
MoSCoW·RICE·MVP·P0~P3 같은 용어가 쏟아졌지만, 대부분 긴 단어의 앞글자를 따서 만든 약어다. 다른 분야도 마찬가지로, 전문용어는 함축어나 대표 단어로 소통한다.
이 방법론을 쉽게 풀면 다음과 같다. 중요하고 필요한 기능에 점수를 매기고, 실현 가능성을 따져 다시 점수를 매긴다. 합산 순위에서 개발 기간에 맞는 범위를 산정한다. - 계산식이 나왔다고 어려운게 아니다. 사칙연산만 하면 할 수 있는 작업이다. -
추상적인 아이디어만 가지고 무턱대고 진행하면 문제가 발생한다. 기능이 계속 추가되고, 중요한 것이 무엇인지 모호해지며, 개발은 산으로 가고, 결국 출시 일정을 못 맞춘다. 개발 중간에 기획이 바뀌는 프로젝트는 대부분 이런 우선순위 작업을 거치지 않고 감으로 진행한 경우다. 실제로 대부분의 프로젝트가 그렇다.
귀찮은 작업이지만, 개발이 원활히 진행되려면 우선순위 작업은 필수 과정이다. 일정에서 무엇을 만들고 무엇을 미룰지 명확히 해야, 팀이 혼선 없이 움직인다. 우선순위 문서는 범위 논쟁을 차단하는 합의의 증거이자, 프로젝트를 완료로 이끄는 지도다.
