RICE 1위가 MoSCoW 에서는 Won't 가 될 수 있다

결론부터

RICE 와 MoSCoW 는 둘 다 우선순위 기법으로 묶이지만 답하는 질문이 다르다.

RICE — 후보들 중 무엇이 일한 시간 대비 효과가 큰가. 후보를 한 줄로 세운다
MoSCoW — 정해진 기간 안에 무엇을 반드시 내고 무엇을 이번에 빼나. 이번 범위를 자른다

그래서 RICE 점수 1위가 이번 타임박스(기간을 고정해 둔 작업 구간)에서는 Won’t 로 빠질 수 있다. 점수가 높아도 기간에 들어가지 않으면 이번에는 빼고, 뺐다는 사실을 기록한다.

두 기법 모두 흔한 오용이 있다. RICE 는 점수를 객관적 진실로 읽는 것, MoSCoW 는 전부 Must 가 되는 것이다. 원문은 둘 다 이를 막는 장치를 이미 넣어두었다. RICE 에는 Confidence 가, DSDM 문서에는 Must 비율 상한과 “전부 Won’t 에서 시작하라”는 지침이 있다.

1편 서비스 기획 용어 17개는 쓰이는 단계로 나누면 안 헷갈린다에서 둘을 해법 설계 단계에 놓았다. 이 글은 그 한 칸을 깊게 판다.

RICE 는 펫 아이디어를 막으려고 만들었다

RICE 는 Intercom 의 Sean McBride 가 2018년 1월 5일 글에서 소개했다. 글은 우선순위가 어려운 이유를 세 가지로 든다.

자기가 쓸 펫 아이디어(pet ideas)에 끌린다 — “넓게 닿는 프로젝트 대신 내가 쓸 아이디어를 하는 게 만족스럽다”
영리한 아이디어에 끌린다 — 목표에 직접 영향을 주는 프로젝트 대신
추가로 드는 노력을 과소평가한다

기존 기법은 많지만 “서로 다른 아이디어를 일관되게 비교하게 해주는 것”을 찾기 어려워서, 팀이 원리부터 직접 만들었다고 쓴다. 세 가지 문제가 그대로 네 요소로 바뀐다. 펫 아이디어는 Reach 로, 영리한 아이디어는 Impact 와 Confidence 로, 노력 과소평가는 Effort 로 견제한다. 이 대응은 내 해석이다. 원문이 이렇게 짝지어 말하지는 않는다.

네 요소와 척도

요소	원문의 정의	척도
Reach	기간당 영향받는 사람 수. 예: 분기당 고객 수	가능하면 실제 지표를 쓴다
Impact	한 사람에게 주는 영향	3 massive / 2 high / 1 medium / 0.5 low / 0.25 minimal
Confidence	추정치를 얼마나 믿을 수 있나	100% high / 80% medium / 50% low. 50% 아래는 “total moonshot”
Effort	팀 전체가 쓰는 시간	인월(person-month). 정수, 한 달에 한참 못 미치면 0.5

결합 방식은 이렇다.

RICE = (Reach × Impact × Confidence) / Effort

원문에서 이 공식은 이미지로 실려 있다. 본문 텍스트가 직접 말하는 것은 두 가지다. Impact 는 최종 점수에 곱해져 크기를 키우거나 줄이고, Effort 는 다른 요소와 달리 클수록 나쁘므로 총 영향을 나눈다. 그 결과를 원문은 “일한 시간당 총 영향(total impact per time worked)”이라고 부른다.

Impact 에는 기준점이 하나 붙는다. 원문은 한 사람에 대한 영향을 목표에 대해서 추정하라고 한다. 예시 목표는 전환율 증가이고, 팀에 따라 “도입 늘리기” 같은 다른 목표로 바꿔도 된다고 쓴다. 목표가 바뀌면 같은 기능의 Impact 도 바뀐다.

원문은 스프레드시트 템플릿도 함께 공유했다. 요소를 추정할 때마다 점수가 자동으로 계산되게 만든 시트다.

배달앱 예시로 보면 Confidence 한 칸에 순위가 뒤집힌다

1편의 배달앱 쿠폰 소재를 이어 쓴다. 아래 서비스와 숫자는 계산을 보이려고 지어낸 예시이고 측정값이 아니다. 목표는 주문 전환 높이기로 둔다.

후보	Reach (분기당 사용자)	Impact	Confidence	Effort (인월)	점수
A. 결제 화면 쿠폰 자동 적용	4000	1	80%	2	1600
B. 주문 취소 시 쿠폰 반환	500	2	100%	1	1000
C. AI 메뉴 추천	6000	2	50%	4	1500
D. 쿠폰 만료 임박 알림	1500	0.5	80%	0.5	1200

순위는 A, C, D, B 다. 여기서 C 를 제안한 사람이 “추천은 효과가 분명하다”며 Confidence 를 80% 로 한 칸 올렸다고 하자.

C (Confidence 50%)  6000 × 2 × 0.5 / 4 = 1500   → 2위
C (Confidence 80%)  6000 × 2 × 0.8 / 4 = 2400   → 1위

데이터는 하나도 바뀌지 않았다. 바뀐 것은 추정치를 얼마나 믿느냐는 판단 하나다. 그런데 순위표 맨 위가 바뀌었다.

RICE 점수는 측정값이 아니라 추정치 네 개를 곱하고 나눈 값이다. 이것이 RICE 의 결함은 아니다. 원문은 Confidence 를 정확히 이 상황 때문에 넣었다고 쓴다. “흥미롭지만 정의가 덜 된 아이디어에 대한 열기를 누르려고(To curb enthusiasm for exciting but ill-defined ideas)” Confidence 를 넣고, 큰 영향이 예상되는데 뒷받침할 데이터가 없으면 Confidence 로 그걸 조절하라는 것이다. 원문은 “추정치에 실제로 얼마나 근거가 있는지 자신에게 정직하라”고도 쓴다.

즉 Confidence 는 점수를 객관적으로 만드는 장치가 아니다. 추정이 부풀려지는 걸 점수 안에서 드러내는 장치다. 그 장치도 사람이 채우므로, 위처럼 한 칸 올리면 효과가 사라진다.

Confidence 를 낮게 줘도 순위가 높을 수 있다는 점도 원문 예시에서 볼 수 있다. 원문은 프로젝트 셋의 입력값만 적고 최종 점수는 적지 않았다. 아래는 원문 입력값으로 내가 계산한 값이다.

원문 예시	Reach	Impact	Confidence	Effort	내가 계산한 점수
프로젝트 1	450	3	100%	2	675
프로젝트 2	2000	1	80%	4	400
프로젝트 3	800	2	50%	1	800

Confidence 가 가장 낮은 프로젝트 3 이 점수는 가장 높다. Effort 가 1 인월로 작아서다. Confidence 는 점수를 깎을 뿐 다른 요소를 이기지는 않는다.

원문도 RICE 점수를 규칙으로 쓰지 말라고 한다

같은 글은 “RICE 점수를 엄격한 규칙으로 쓰면 안 된다(shouldn’t be used as a hard and fast rule)”고 직접 적는다. 점수가 낮아도 먼저 할 이유로 두 가지를 든다.

의존성 — 다른 프로젝트가 이 프로젝트에 기대고 있어서 먼저 해야 한다
테이블 스테이크(table stakes) — 특정 고객에게 팔려면 기본으로 갖춰야 하는 기능이다

순서를 바꾸는 것 자체는 괜찮다고 본다. 대신 그 트레이드오프가 보이게 하라고 한다. 점수를 낸 뒤에는 “점수가 너무 높거나 낮아 보이는 프로젝트가 있나”를 다시 보라고도 쓴다.

원문이 말하는 RICE 의 쓸모는 정답 산출이 아니다. 무엇을 먼저 할지 더 잘 판단하고, 그 판단을 다른 사람에게 방어하는 것(defend those decisions to others)이다. 점수는 판단의 근거를 펼쳐 보이는 형식이라고 나는 읽었다.

MoSCoW 는 고정된 기간 안에서만 뜻이 생긴다

MoSCoW 의 1차 자료로 Agile Business Consortium 의 DSDM 문서를 봤다. DSDM(Dynamic Systems Development Method)은 이 단체가 관리하는 애자일 프로젝트 프레임워크다. 문서에 작성 연도는 적혀 있지 않다.

창안자는 흔히 Oracle 의 Dai Clegg 로 알려져 있지만 1차 자료로 확인하지 못했다. DSDM 문서도 글자가 네 분류를 뜻한다고만 할 뿐 이름의 유래나 창안자는 말하지 않는다.

네 분류

Must Have — “프로젝트가 인도를 보장하는 최소 사용 가능 부분집합(Minimum Usable SubseT)”이다. MUST 라는 글자 자체가 이 말의 머리글자다. 근거로 드는 문장은 이런 것이다. 이것 없이 목표일에 내봐야 의미가 없다, 이것 없이는 법에 어긋난다, 안전하지 않다, 실행 가능한 해법이 안 된다.
Should Have — 중요하지만 필수는 아니다(Important but not vital). 빼면 아플 수 있지만 해법은 성립한다. 임시 우회책이 필요할 수 있다.
Could Have — 바라지만 덜 중요하다. 빠졌을 때 영향이 Should 보다 작다.
Won’t Have this time — 프로젝트 팀이 이번 기간에는 인도하지 않기로 합의한 요구사항이다.

Must 를 가르는 시험 질문도 문서에 있다. “이 요구사항이 충족되지 않으면 무슨 일이 생기나?” 수동이고 고통스럽더라도 우회책이 있으면 Must 가 아니라 Should 나 Could 다.

타임박스와 묶인 개념이다

MoSCoW 의 네 칸은 중요도 4단계 척도가 아니다. DSDM 은 시간·비용·품질을 고정하고 기능을 협상한다(fixing time, cost and quality and negotiating features). 기한이 움직이지 않으니, 문제가 생기면 덜 중요한 것을 빼서 기한을 지킨다. 그 “뺄 것”이 미리 정해져 있어야 하므로 칸이 필요하다.

그래서 문서는 Could 를 “주요 예비분(the main pool of contingency)”이라고 부른다. 기한이 위험해지면 Could 중 하나 이상이 가장 먼저 빠진다.

우선순위도 한 층이 아니다. 문서는 같은 요구사항이 프로젝트, 증분(Project Increment), 타임박스 세 층에서 각각 MoSCoW 를 가질 수 있다고 쓴다. 타임박스를 시작할 때는 대부분의 요구사항이 “이번 타임박스에는 Won’t” 다. 타임박스용 목록은 프로젝트 목록의 부분집합으로 따로 만들고, 프로젝트 목록의 우선순위는 그대로 두라고 권한다.

Won’t 는 왜 칸이 따로 있나

빼기로 한 것을 굳이 적는 이유를 문서는 두 가지로 든다.

범위를 분명히 해서 그 요구사항이 나중에 비공식적으로 다시 들어오는 것(informally reintroduced)을 막는다
이번에 배포될 해법에 무엇이 없는지 기대치를 관리하고, 더 높은 우선순위에 집중하게 한다

목록에서 지우기만 하면 “그것도 살짝 넣죠”가 회의마다 다시 나온다. Won’t 에 적어두면 이미 합의한 결정으로 남는다. 그리고 이름이 “this time” 이라서, 영원히 안 한다는 뜻이 아니라는 것도 같이 적힌다.

둘을 같이 쓰면 RICE 로 줄 세우고 MoSCoW 로 자른다

DSDM 문서도 Intercom 글도 둘을 함께 쓰는 법은 말하지 않는다. 아래 순서는 내 해석이다. 질문이 다르니 순서대로 이어 붙일 수 있다는 것이다.

후보를 RICE 로 점수 내고 줄 세운다 — 무엇이 시간 대비 효과가 큰가
이번 타임박스의 목표와 용량을 정한다
MoSCoW 로 이번 범위를 합의한다 — 시험 질문으로 Must 를 가르고, 남은 것을 Should·Could·Won’t 로 나눈다

앞 예시를 이어 간다. 이번 분기 목표는 “쿠폰 자동 적용 출시”, 용량은 4 인월로 둔다. 역시 지어낸 숫자이고 측정값이 아니다. C 의 Confidence 는 80% 로 올라가 RICE 1위인 상태다.

후보	RICE 순위	Effort	MoSCoW	판단 근거
A. 쿠폰 자동 적용	2위	2	Must	이것 없이 내면 이번 분기 출시가 의미 없다
B. 취소 시 쿠폰 반환	4위	1	Should	없으면 고객센터가 수동으로 재발급해야 한다. 아프지만 우회책이 있다
D. 만료 임박 알림	3위	0.5	Could	있으면 좋지만 빠져도 영향이 작다. 기한이 밀리면 먼저 뺀다
C. AI 메뉴 추천	1위	4	Won’t this time	혼자 4 인월이라 용량에 들어가지 않는다. 다음 분기 후보로 기록한다

RICE 1위가 Won’t 가 되고, RICE 꼴찌인 B 가 D 보다 위 칸에 들어간다. 모순이 아니다. RICE 는 비용 대비 효과를, MoSCoW 는 이번 기간에 빠졌을 때의 결과를 묻는다. B 는 효과가 작아도 빠지면 사람이 손으로 메워야 하고, D 는 빠져도 아무도 메울 필요가 없다.

이 배치는 DSDM 의 노력 배분 지침에도 맞는다. Must 인 A 는 용량 4 인월 중 2 인월로 절반이다. 합계 3.5 인월이라 0.5 인월이 남는다.

Intercom 이 점수가 낮아도 먼저 할 이유로 든 의존성과 테이블 스테이크는 MoSCoW 의 Must 시험 질문과 닮았다. 둘 다 “점수와 상관없이 빠지면 성립하지 않는 것”을 가려낸다. 이 연결도 내 해석이다.

그럼 RICE 점수가 있으면 MoSCoW 회의는 안 해도 되나

그렇지 않다. RICE 는 범위를 정하지 않는다. 순위표는 있지만 어디서 자를지, 자른 아래쪽을 어떻게 기록할지는 RICE 의 질문이 아니다. 점수 순서대로 용량이 찰 때까지 담는 방법도 있지만, 그러면 위 예시의 B 처럼 점수는 낮아도 빠지면 아픈 항목을 놓친다.

반대도 같다. MoSCoW 는 후보끼리 효과를 비교하는 척도를 주지 않는다. DSDM 문서는 Should 와 Could 를 충족되지 않았을 때의 고통으로 가르고, 그 고통을 업무 가치나 영향받는 사람 수로 따질 수 있다고 쓴다. 그 경계는 요구사항을 모으기 전에 합의해 두라고 한다. 영향받는 사람 수는 RICE 의 Reach 와 같은 축이다. 칸을 나누는 근거로 점수를 쓸 수 있다는 뜻으로 나는 읽었다.

둘 다 혼자 쓸 수 있다. 다만 혼자 쓰면 각자의 질문에만 답한다.

전부 Must 가 되는 문제에는 DSDM 지침이 있다

MoSCoW 를 실제로 쓰면 가장 먼저 무너지는 곳이 Must 다. 다들 자기 요구사항이 빠지면 안 된다고 말한다. DSDM 문서는 이 문제를 직접 다룬다.

진단 — “모든 것이 Must 라고 믿는 것은 대개 요구사항을 충분히 쪼개지 않았다는 증상이다(often symptomatic of insufficient decomposition of requirements).” 큰 요구사항 하나 안에 Must 인 부분과 아닌 부분이 섞여 있다는 뜻이다
시작점 — “모든 요구사항을 Won’t 로 두고 시작해서, 왜 더 높은 우선순위가 필요한지 정당화하라”
상한 — 노력 기준으로 Must 는 보통 60% 를 넘지 않게, Could 는 보통 20% 안팎으로 둔다. 60% 를 넘기려면 추정이 정확하고, 방식이 잘 알려져 있고, 팀이 제 성과를 내고, 환경 위험이 낮아야 한다고 쓴다
이유 — 모든 요구사항이 정말 Must 라면 덜 중요한 것을 빼는 유연성이 사라진다. 시간을 고정하고 기능을 조정한다는 DSDM 의 전제와 충돌한다
책임 — 어떤 요구사항이 왜 Must 인지 설명하는 것은 Business Visionary 또는 그가 권한을 준 Business Ambassador 의 몫이다. 이견이 생겼을 때 올라갈 경로도 미리 정해 두라고 한다

60% 와 20% 는 문서가 제시한 지침 값이다. 이 글의 다른 숫자와 달리 내가 지어낸 예시가 아니다. 다만 근거가 된 측정 자료는 문서에 없다.

문서는 압박에 대해서도 한 줄을 남긴다. Must, Should, Could 를 전부 인도하라고 팀을 압박하는 것은 역효과라고 쓴다. 그러면 추정치가 부풀려지고 성공했다는 착각만 남는다는 것이다. Could 를 예비분으로 둔 이유가 여기서 무너진다.

원전을 찾지 못한 것과 확인하지 못한 것

MoSCoW 창안자는 1차 자료로 확인하지 못했다. 흔히 Dai Clegg 로 알려져 있다는 정도로만 적었다
DSDM 문서는 작성 연도가 없다. 문서가 개정됐다면 지침 값이 바뀌었을 수 있다
RICE 공식은 원문에 이미지로 실려 있어 텍스트로는 Impact 의 곱셈과 Effort 의 나눗셈만 확인했다. 공식 자체는 1편과 같은 형태로 적었다
ICE 같은 다른 점수 기법은 1차 출처를 확인하지 못해 비교하지 않았다. Intercom 글도 다른 기법을 이름으로 언급하지 않는다
Business Visionary, Business Ambassador 는 DSDM 이 정한 역할 이름이다. DSDM 을 쓰지 않는 조직에서는 그 결정을 누가 하는지를 따로 정해야 한다
배달앱 예시와 그 숫자는 전부 지어낸 것이다. 실제 서비스에 적용해 보지 않았다

정리

	RICE	MoSCoW
출처	Intercom, Sean McBride, 2018	Agile Business Consortium 의 DSDM 문서
답하는 질문	무엇이 일한 시간 대비 효과가 큰가	이번 기간에 무엇을 반드시 내고 무엇을 빼나
산출물	점수와 순위	네 칸으로 나뉜 이번 범위
흔한 오용	점수를 객관적 진실로 읽는다	전부 Must 로 둔다
원문의 장치	Confidence, “엄격한 규칙으로 쓰지 말라”	Must 시험 질문, Must 60% 상한, 전부 Won’t 에서 시작

RICE 는 줄을 세우고, MoSCoW 는 이번 범위를 자른다. 그래서 RICE 1위가 이번 타임박스의 Won’t 가 되는 것은 어느 한쪽이 틀린 게 아니다. 점수는 판단을 펼쳐 보이는 형식이고, Won’t 는 그 판단을 다음 기간까지 남겨 두는 기록이다.