RICE 점수 모델(RICE Scoring)은 Reach(도달), Impact(임팩트), Confidence(확신도), Effort(노력) 네 가지 요소를 정량화해 제품 백로그의 우선순위를 결정하는 PM 프레임워크입니다. 2015년 Intercom의 제품 책임자 션 매크브라이드(Sean McBride)가 매주 반복되던 "어떤 기능부터 만들까" 논쟁을 끝내기 위해 만들었고, 이후 Intercom·Atlassian·Asana 등 글로벌 SaaS 기업의 표준 백로그 의사결정 도구로 자리잡았습니다. 단순히 직감이나 목소리 큰 사람이 이기는 결정 방식을 데이터 기반 우선순위로 바꾸는 도구입니다.
목차
- 제품 백로그 회의에서 느낀 RICE의 효용
- RICE 프레임워크가 등장한 배경
- RICE 점수 모델이란 무엇인가
- RICE 계산법: 네 가지 변수 상세 가이드
- RICE 적용 사례와 실전 활용법
- RICE의 한계와 보완 프레임워크
- FAQ
- 같이 읽으면 좋은 것들
제품 백로그 회의에서 느낀 RICE의 효용
판교 한 SaaS 스타트업의 PM으로 일하던 2023년 초가을이었습니다. 매주 화요일 오전 10시 백로그 그루밍 회의가 잡혀 있었는데, 이 회의가 매번 두 시간을 넘기는 게 일상이었습니다. 영업팀은 대형 고객 한 곳이 요청한 기능을 먼저 만들자고 했고, CS팀은 매주 들어오는 작은 불편 사항 해결이 우선이라고 했고, CEO는 신규 시장 진출에 필요한 기능을 1순위로 잡고 싶어 했습니다.
회의에서 결정된 우선순위가 다음 주 회의에서 또 뒤집히는 일이 반복됐고, 개발팀의 신뢰는 점점 사라졌습니다. 그때 부사장이 처음 꺼낸 게 RICE였습니다. 회의 첫날, 백로그 12개 항목을 다 같이 RICE로 계산해 보니까 결과가 좀 의외였습니다. 모두가 1순위라고 생각했던 "엔터프라이즈 SSO 통합"이 RICE 점수 47점으로 4위로 밀렸고, 아무도 신경 안 쓰던 "온보딩 흐름 개선"이 점수 312점으로 1위가 됐습니다.
처음에는 다들 결과에 반발했는데, Reach 변수에 신규 가입자 수를 넣어 보면 SSO는 월 12명에게만 도달하고 온보딩은 1,800명 전체에게 영향을 미친다는 게 숫자로 드러났습니다. 그날 이후 회의 시간이 30분으로 줄었고, 결정이 뒤집히는 일도 거의 사라졌습니다. RICE의 진짜 가치는 점수 자체가 아니라 "우리가 어떤 가정으로 우선순위를 정하고 있는지"를 모두가 같은 언어로 토론하게 만든다는 점이었습니다.
RICE 프레임워크가 등장한 배경
제품팀의 우선순위 결정 문제는 오래된 고민입니다. 1990년대에는 MoSCoW(Must·Should·Could·Won't)나 가중치 매트릭스가 쓰였고, 2000년대에는 Kano 모델·Value vs Effort 매트릭스가 주류였습니다. 그런데 SaaS 비즈니스가 본격화되면서 두 가지가 동시에 일어났습니다.
첫째, 제품팀이 만들 수 있는 기능 후보가 폭발적으로 늘었습니다. Intercom의 경우 2014년 한 해에 백로그에 등록된 항목이 1,200개를 넘었고, 그중 실제로 개발한 건 80여 개에 불과했습니다. 둘째, 이해관계자가 늘면서 정성적 판단이 충돌했습니다. CEO, 영업, CS, 마케팅, 엔지니어링이 각자 다른 우선순위를 들고 와서 회의가 종교 토론처럼 변하는 패턴이 반복됐습니다.
Intercom의 션 매크브라이드는 2015년 9월 자사 블로그에 RICE 프레임워크 글을 올리면서 이 문제에 대한 답을 제시했습니다. 핵심은 "우선순위를 숫자로 표현하면 토론은 점수 변수로 옮겨가고, 변수에 대한 토론은 가설 검증으로 이어진다"는 것이었습니다. 직감과 목소리 크기 대신, "왜 이 항목의 Reach를 5,000명이라고 보는가"를 묻기 시작하면 자연스럽게 데이터 기반 의사결정으로 이동한다는 발상이었습니다.
이 프레임워크가 빠르게 확산된 이유는 단순함에 있었습니다. 변수가 4개뿐이고, 계산식이 한 줄이며, 엑셀이나 노션으로 누구나 만들 수 있습니다. ProductPlan·Productboard·Aha! 같은 글로벌 PM 도구들이 RICE를 기본 점수 시스템으로 채택하면서 SaaS 업계 표준이 됐고, 한국에서도 토스·당근·쿠팡 같은 기업의 제품팀이 변형 RICE를 운영하고 있습니다.
RICE 점수 모델이란 무엇인가
RICE 점수는 네 가지 변수를 곱하고 나누어 하나의 숫자로 만듭니다.
RICE Score = (Reach × Impact × Confidence) ÷ Effort
분자에는 "이 기능이 만들 가치"가, 분모에는 "이 기능을 만드는 데 드는 비용"이 들어가는 구조입니다. 점수가 높을수록 가성비 좋은 항목이고, 낮을수록 우선순위가 뒤로 밀립니다. 변수 각각의 의미는 다음과 같습니다.
- Reach: 일정 기간 동안 이 기능에 영향을 받는 사람 수
- Impact: 영향받은 사람 1인당 발생하는 효과의 크기
- Confidence: 위 두 추정치에 대한 확신도(0~100%)
- Effort: 기능 구현에 필요한 사람-월(person-month)
다른 우선순위 프레임워크와 비교
같은 우선순위 결정 도구라도 RICE는 정량적 점수를 산출한다는 점에서 차별화됩니다.
| 프레임워크 | 변수 | 결과물 | 적합한 상황 |
|---|---|---|---|
| RICE | Reach, Impact, Confidence, Effort | 정량 점수 | 백로그 항목 비교 |
| MoSCoW | Must, Should, Could, Won't | 4단계 분류 | 릴리스 범위 결정 |
| Value vs Effort | Value, Effort | 2x2 매트릭스 | 빠른 시각 분류 |
| Kano | 기본·성능·매력 품질 | 3단계 분류 | 고객 만족도 설계 |
| ICE | Impact, Confidence, Ease | 정량 점수 | 빠른 실험 우선순위 |
RICE와 가장 닮은 것이 ICE 점수입니다. ICE는 Reach 변수가 없고 Effort 대신 Ease(쉬움 정도)를 씁니다. ICE는 빠른 실험 우선순위에 좋고, RICE는 정식 백로그 결정에 적합합니다.
RICE 계산법: 네 가지 변수 상세 가이드
Reach: 도달 인원 수
Reach는 정해진 기간(보통 분기) 동안 이 기능이 영향을 미치는 사용자 수입니다. "월간 활성 사용자 중 이 흐름을 거치는 사람", "특정 페이지 분기 방문자 수", "신규 가입자 중 첫 7일 이내 이 기능을 사용할 사람" 같은 구체적 정의가 필요합니다. 추측이 아닌 실제 데이터(Mixpanel·Amplitude·자체 로그)에서 끌어와야 합니다.
흔히 빠지는 함정이 "전체 사용자 수"를 그냥 넣는 것입니다. 결제 페이지 개선이라면 결제 페이지에 도달한 사람만 Reach에 들어가야 하고, 알림 설정 변경이라면 알림 설정을 여는 사람만 들어가야 합니다.
Impact: 1인당 효과의 크기
Impact는 영향받은 사람 1인당 어느 정도의 변화를 만드는지를 표현합니다. Intercom 원안은 5단계 척도를 씁니다.
- 3 = 대규모 (Massive impact)
- 2 = 큰 (High)
- 1 = 보통 (Medium)
- 0.5 = 작은 (Low)
- 0.25 = 미미한 (Minimal)
이 척도가 너무 거칠다고 느끼면 0.1~3 사이 자유 척도를 쓰는 팀도 있습니다. 중요한 건 "임팩트의 정의를 무엇으로 둘 것인가"입니다. 매출인지, 활성도인지, 리텐션인지, NPS인지 사전에 합의해야 같은 기준으로 비교할 수 있습니다.
Confidence: 추정의 확신도
Confidence는 위 두 추정치가 얼마나 믿을 만한지를 백분율로 표현합니다. 보통 100%·80%·50% 세 단계로 단순화합니다.
- 100% = 강력한 데이터 기반(A/B 테스트 결과·고객 인터뷰 다수)
- 80% = 합리적 근거(유사 사례·일부 정성 데이터)
- 50% = 직감 또는 가설 단계
50% 미만이 나오면 "moonshot"으로 분류하고 별도 검증 단계를 거치자는 권고가 일반적입니다. Confidence는 변수 중 가장 자주 오용됩니다. 모두가 자기 안건의 확신도를 80~100%로 부풀려 적는 경향이 있어, 점수표 옆에 "이 확신도의 근거 데이터"를 한 줄로 적게 하는 운영 규칙을 두는 팀이 많습니다.
Effort: 구현 비용
Effort는 사람-월(person-month) 단위로 적습니다. 백엔드 1명·프론트 1명·디자이너 0.5명이 1.5개월 걸린다면 Effort = 3.75입니다. 0.5 단위 미만으로 쪼개지 않는 게 좋습니다. 그 정밀도까지 추정할 수 없는 게 보통이기 때문입니다.
계산 예시: 결제 페이지 A/B 테스트 vs 신규 알림 흐름
| 항목 | Reach | Impact | Confidence | Effort | 점수 |
|---|---|---|---|---|---|
| 결제 페이지 카드 입력 UX 개선 | 12,000명/분기 | 2 (High) | 80% | 1.5 | 12,800 |
| 신규 푸시 알림 흐름 | 35,000명/분기 | 0.5 (Low) | 50% | 2 | 4,375 |
| 엔터프라이즈 SSO | 12명/분기 | 3 (Massive) | 100% | 4 | 9 |
이 표를 보면 "엔터프라이즈 SSO는 분명 큰 임팩트지만, 도달 인원이 작아 점수가 낮다"는 결론이 자연스럽게 나옵니다. 영업 압박에 시달리는 PM이 객관적 근거를 가지고 "지금은 카드 UX부터"라고 말할 수 있게 됩니다.
RICE 적용 사례와 실전 활용법
Intercom: 분기 OKR과 백로그를 연결하는 운영
Intercom은 RICE 점수를 분기마다 100개 이상 백로그 항목에 적용합니다. 점수가 높은 순으로 상위 20개를 그 분기 후보로 올리고, OKR과 매칭해 실제 우선순위 12개를 최종 결정합니다. 점수 자체가 결정이 아니라 "토론의 시작점"이 된다는 게 핵심입니다.
토스: 정성 평가와 RICE의 결합
국내 핀테크의 한 팀은 RICE에 "전략 가중치"를 추가해서 운영합니다. 분기 전략 키워드에 부합하는 항목은 가중치 1.5를 곱하고, 부합하지 않으면 그대로 두는 식입니다. 정량 점수가 압도적이어도 회사 전략과 맞지 않으면 후순위로 밀릴 수 있게 한 변형입니다.
실전 가이드: RICE 도입 4단계
- 변수 정의 합의: Reach 기간(주·월·분기), Impact 척도, Confidence 단계, Effort 단위를 팀 전원이 합의합니다.
- 백로그 시트 만들기: 노션 데이터베이스나 구글 시트에 항목·Reach·Impact·Confidence·Effort·점수 열을 추가합니다.
- 주간 그루밍 회의 운영: 매주 신규 항목을 추가하고 점수를 산정합니다. 점수 변수에 대한 토론을 의도적으로 길게 가져갑니다.
- 분기 회고: 끝난 분기의 실제 결과와 RICE 점수를 비교합니다. 어떤 변수의 추정이 빗나갔는지 정리하면 다음 분기 추정이 정교해집니다.
RICE의 한계와 보완 프레임워크
RICE가 만능은 아닙니다. 실전에서 자주 부딪히는 한계가 몇 가지 있습니다.
첫째, 전략적·정성적 가치를 반영하지 못합니다. 신규 시장 진출용 기능, 브랜드 정체성 강화, 기술 부채 청산처럼 점수가 낮게 나오지만 장기적으로 중요한 항목이 후순위로 밀릴 수 있습니다. 토스 사례처럼 전략 가중치를 보완하거나, 분기별로 일정 비율(예: 30%)을 전략 항목에 미리 할당해 두는 방식이 흔합니다.
둘째, 변수 추정의 정확도에 의존합니다. Reach를 정확히 계산하려면 사용자 행동 데이터가 잘 정리돼 있어야 하고, Impact를 추정하려면 과거 유사 변경의 결과가 축적돼 있어야 합니다. 데이터 인프라가 약한 초기 스타트업에서는 ICE 같은 더 단순한 프레임워크가 적합합니다.
셋째, 혁신적 시도를 억제하는 부작용이 있을 수 있습니다. 점수가 잘 나오는 작은 개선만 누적되고, 큰 임팩트의 베팅이 외면받는 패턴입니다. 마티 케이건(Marty Cagan)은 이를 "리스크 회피적 우선순위의 함정"이라고 비판하며, RICE 위에 별도의 "베팅 트랙"을 두라고 권합니다.
보완 프레임워크: WSJF·노스 스타 메트릭·JTBD
- WSJF (Weighted Shortest Job First): SAFe 프레임워크에서 쓰는 우선순위 도구. Cost of Delay ÷ Job Size로 계산하며, 대규모 엔터프라이즈 환경에 적합합니다.
- 노스 스타 메트릭 정렬: 회사의 단일 성장 지표에 기여하는 정도를 별도 변수로 추가하는 변형입니다.
- JTBD 기반 우선순위: 고객이 채용하려는 "일"을 기준으로 그루핑한 후 RICE를 적용해 전략적 일관성을 높입니다.
FAQ
RICE 점수가 같으면 어떤 항목을 먼저 하나요?
점수가 같거나 비슷할 때는 점수 자체가 아니라 변수 구성을 봅니다. 일반적으로 Confidence가 높은 항목을 먼저 하는 게 안전합니다. 추정이 빗나갈 리스크가 낮기 때문입니다. 또 Effort가 작은 쪽이 회수 속도가 빨라서 같은 점수라면 가벼운 항목부터 처리하라는 권고가 흔합니다.
RICE는 스타트업과 대기업 중 어디에 더 적합한가요?
둘 다 적용 가능하지만 운영 방식이 다릅니다. 초기 스타트업은 Reach 데이터가 부족하니까 ICE로 시작해 데이터가 쌓이면 RICE로 전환하는 흐름이 일반적입니다. 대기업은 RICE에 전략 가중치·WSJF 같은 추가 변수를 얹어서 정성 가치도 반영합니다. 회사 단계와 데이터 성숙도에 따라 변형해 쓰는 게 정답입니다.
RICE 회의를 효과적으로 운영하려면?
세 가지가 중요합니다. 첫째, 점수 산정 전에 각자 따로 적어 와서 회의에서 비교합니다. 회의 중에 같이 결정하면 목소리 큰 사람의 영향을 받습니다. 둘째, 변수마다 근거 데이터를 한 줄로 적게 합니다. 셋째, 끝난 분기 결과와 사전 추정을 비교하는 회고를 분기에 한 번씩 합니다. 이게 가장 큰 학습 포인트입니다.
RICE 점수가 낮은 항목은 영영 안 하나요?
그렇지 않습니다. RICE는 정렬 도구지 거부 도구가 아닙니다. 점수가 낮아도 전략적 중요성·외부 압박·기술 부채 청산 등 정성적 이유로 우선순위가 올라가는 경우가 있습니다. 분기마다 일정 비율을 전략 항목·기술 부채에 미리 할당해 두는 게 권장됩니다.
RICE 도구로 노션·시트 외에 추천할 만한 게 있나요?
PM 전용 도구로는 Productboard·Aha!·ProductPlan이 RICE를 기본 지원합니다. 노션 데이터베이스에 수식 필드로 RICE 점수를 자동 계산하게 만드는 무료 템플릿도 많이 공유되어 있습니다. 도구보다는 변수 정의의 일관성이 더 중요해서, 처음 도입할 때는 구글 시트나 노션으로 시작하는 걸 권합니다.