RICE·ICE 우선순위 정하는 법

우선순위 결정 · 실전 가이드 · 게시 2026. 07. 06 · 작성 rohan · 수정 2026. 09. 25

할 일 목록을 앞에 두면 늘 같은 문제에 부딪힙니다. "이것도 중요하고 저것도 중요한데, 대체 무엇부터 해야 하지?" 시간과 인력은 한정돼 있는데 "다 중요하다"고 느끼는 순간, 우선순위는 결국 목소리 큰 사람이나 직급 높은 사람의 의견으로 정해지기 쉽습니다. 이 글에서는 기능과 아이디어의 우선순위를 RICE와 ICE라는 두 점수 공식으로 객관적으로 정하는 법을 정리합니다. 이 글은 무엇을 할지 고르는 단계를 다루고, 고른 항목을 작업으로 쪼개 일정에 올리는 다음 단계는 WBS 작성법과 프로젝트 일정 관리 방법에서 이어집니다.

왜 우선순위를 "점수"로 매길까

우선순위를 감으로 정하면 두 가지가 반복됩니다. 하나는 "다 중요하다"는 함정입니다. 모든 항목을 똑같이 중요하게 두면 사실상 우선순위가 없는 것과 같아, 정작 급할 때 무엇을 미룰지 판단하지 못합니다. 다른 하나는 감정·직급 싸움입니다. 근거 없이 "이게 더 중요해 보인다"가 부딪히면 토론은 설득전이 되고, 결국 힘 있는 쪽이 이깁니다.

점수화의 힘은 여기서 나옵니다. 각 항목을 몇 가지 기준으로 나눠 숫자로 환산하면, 팀이 같은 기준으로 항목을 비교하게 됩니다. 논쟁의 초점이 "누구 말이 맞느냐"에서 "이 항목의 Reach를 얼마로 볼 것이냐"로 옮겨가고, 그러면 합의가 훨씬 빨라집니다. 대표적인 두 공식이 RICE와 ICE입니다.

RICE 점수 — 데이터가 있을 때

RICE는 네 가지 요소의 앞글자를 딴 이름으로, 공식은 다음과 같습니다.

RICE 점수 = (Reach × Impact × Confidence) ÷ Effort

점수가 높을수록 우선순위가 높습니다. 각 요소를 하나씩 보겠습니다.

• Reach(도달 범위) — 정해진 기간 동안 이 항목이 영향을 주는 사용자 수나 건수입니다. 예를 들어 "한 분기 동안 2,000명이 이 기능을 쓴다"처럼 잡습니다. 반드시 측정 기간을 정해 세는 것이 핵심입니다.
• Impact(영향) — 영향을 받은 한 명당 효과의 크기입니다. 숫자로 딱 떨어지지 않으니 보통 척도를 씁니다. 3=매우 큼, 2=큼, 1=보통, 0.5=약함, 0.25=매우 약함이 흔한 예입니다.
• Confidence(확신도) — 위 추정치들을 얼마나 믿을 수 있는지를 100% / 80% / 50%처럼 비율로 표현합니다. 근거 없는 낙관을 눌러 주는 장치로, 데이터가 부실할수록 값을 낮게 잡아 점수를 깎습니다.
• Effort(공수) — 이 항목을 하는 데 드는 노력으로, 보통 person-month(인·월) 같은 단위로 잡습니다. 나누는 값이라서 공수가 클수록 점수가 내려갑니다.

계산 예시

어떤 기능이 분기당 2,000명에게 도달하고(Reach=2000), 한 명당 영향이 큰 편이며(Impact=2), 추정에 대한 확신이 80%이고(Confidence=0.8), 공수가 4인·월(Effort=4)이라고 해 봅시다. 그러면 RICE 점수는 (2000 × 2 × 0.8) ÷ 4 = 800이 됩니다. 다른 후보 기능들도 같은 방식으로 점수를 내면, 800이라는 절대값 자체보다 후보들 사이의 상대 순위를 보고 무엇을 먼저 할지 정할 수 있습니다.

ICE 점수 — 빠르게 골라낼 때

ICE는 더 가볍습니다. 공식은 다음과 같습니다.

ICE 점수 = Impact × Confidence × Ease

세 요소를 각각 1~10점으로 매겨 곱합니다. Impact는 효과의 크기, Confidence는 그 판단에 대한 확신, Ease는 얼마나 쉽게(빠르게) 할 수 있는지입니다. RICE의 Effort가 "나누는 공수"라면, ICE의 Ease는 "곱하는 쉬움"이라 방향이 반대라는 점만 기억하면 됩니다. 계산이 단순해 빠르지만, 세 값 모두 주관적인 1~10점이라 RICE보다 사람에 따라 편차가 큽니다.

언제 RICE, 언제 ICE?

• RICE — 사용자 수 같은 데이터가 어느 정도 있고, 분기 로드맵처럼 정식으로 우선순위를 확정해야 할 때 적합합니다. 근거가 있는 만큼 설득력도 큽니다.
• ICE — 아이디어가 쏟아지는 브레인스토밍이나 초기 아이디어 선별처럼, 정밀함보다 속도가 중요할 때 좋습니다. 수십 개 후보를 빠르게 추려 상위 몇 개만 남길 때 유용합니다.

실전에서 지키면 좋은 것

1. 척도를 먼저 합의하세요. Impact의 3점이 어느 정도인지, Ease의 10점이 무엇인지를 팀이 미리 맞춰 두지 않으면 같은 항목에 서로 다른 점수를 매기게 됩니다.
2. Reach의 측정 기간을 통일하세요. 한 항목은 월 기준, 다른 항목은 분기 기준으로 세면 점수를 비교할 수 없습니다. 모두 같은 기간(예: 분기)으로 맞춥니다.
3. Confidence로 과대추정을 견제하세요. 근거가 약한 항목은 확신도를 낮게 잡아 자동으로 점수가 깎이게 두면, 희망 섞인 추정이 순위를 왜곡하는 것을 막을 수 있습니다.
4. 절대 점수보다 상대 순위로 쓰세요. "800점"이라는 숫자 자체는 큰 의미가 없습니다. 항목들 사이의 순서를 보는 도구로 활용하는 것이 맞습니다.

흔한 실수 3가지

• Effort를 과소평가한다 — "금방 하죠"가 실제로는 몇 주가 되는 일이 흔합니다. 공수를 낮게 잡으면 애매한 항목이 부당하게 위로 올라옵니다.
• Impact를 감으로만 매긴다 — 척도(3·2·1·0.5·0.25)를 정해 두고도 근거 없이 "이건 3점 느낌"이라고 찍으면, 점수화의 의미가 사라집니다.
• 점수를 결론으로 맹신한다 — 점수는 토론을 돕는 도구지 정답이 아닙니다. 계산 결과가 직관과 크게 다르면, 순위를 무작정 따르기보다 어떤 값이 틀렸는지 다시 짚어 보는 계기로 삼으세요.

실제 백로그 8개를 RICE로 채점해 보기

공식만 보면 간단해 보이지만, 실제 백로그를 앞에 두면 "이 항목의 Reach를 얼마로 볼 것인가"에서 막힙니다. 일정 관리 SaaS를 운영하는 팀의 분기 백로그 8개를 예로 들어 끝까지 채점해 보겠습니다. 기간은 한 분기, Impact는 3·2·1·0.5·0.25 척도, Confidence는 100%·80%·50%, Effort는 인·월(person-month) 단위입니다.

#	항목	Reach	Impact	Conf.	Effort	RICE	순위
1	소셜 로그인 추가	3,000	1	0.8	1	2,400	4
2	온보딩 튜토리얼 개선	4,000	2	0.8	2	3,200	2
3	모바일 앱 출시	5,000	3	0.5	12	625	7
4	엑셀 내보내기	1,500	2	1.0	0.5	6,000	1
5	다크 모드	6,000	0.5	1.0	1	3,000	3
6	결제 오류 수정	400	3	1.0	0.5	2,400	4
7	팀 협업(멤버 초대)	2,000	3	0.5	6	500	8
8	알림 이메일	2,500	1	0.8	1.5	1,333	6

결과를 어떻게 읽을까

• 1위 엑셀 내보내기(6,000) — Reach는 중간이지만 고객 요청이 많아 Confidence 100%, 공수가 0.5인·월로 작아 압도적 1위입니다. RICE가 "가성비 좋은 일"을 위로 올리는 전형적인 모습입니다.
• 4위 동점: 소셜 로그인과 결제 오류 수정(2,400) — Reach는 7.5배(3,000 대 400) 차이지만 Impact(1 대 3)와 Confidence(0.8 대 1.0), Effort(1 대 0.5)가 이를 정확히 상쇄했습니다. 동점이면 매출에 직결되는 결제 오류를 먼저 하는 식으로, 점수 밖의 기준(분기 목표·리스크)으로 순서를 정합니다.
• 7·8위 모바일 앱과 팀 협업 — Impact 3점짜리 큰 기능인데도 꼴찌입니다. Effort가 크고 Confidence가 낮기 때문입니다. 이것이 RICE의 한계이자 장점입니다. 전략적으로 반드시 해야 하는 항목이라면 점수와 별개로 "전략 슬롯"에 배정하되, 이번 분기에는 기술 조사(스파이크) 같은 작은 선행 작업으로 쪼개 Effort 1인·월짜리 항목으로 다시 채점하는 것이 현실적입니다.
• 3위 다크 모드(3,000) — Reach가 가장 크지만 Impact 0.5로 낮아 중위권입니다. "요청이 많다"와 "영향이 크다"는 다르다는 점을 점수가 보여 줍니다.

이 표를 우선순위 계산기에 옮길 때는 두 가지를 알아 두세요. 첫째, 계산기의 Confidence 칸에는 0.8이 아니라 80처럼 퍼센트 숫자로 넣습니다. 0.8을 넣으면 점수가 100분의 1로 작아집니다. 둘째, 동점 항목은 공동 순위로 표시되지 않고 표에 먼저 입력된 행이 앞 순위(여기서는 4위와 5위)를 받습니다. 동점을 어떻게 가를지는 위처럼 점수 밖의 기준으로 정한 뒤 행 순서를 맞춰 두면 됩니다.

점수 척도 합의하기 — 캘리브레이션

같은 항목을 두고 A는 Impact 3, B는 Impact 1을 매기면 점수표는 의미가 없습니다. 첫 채점 전에 30분만 들여 척도를 팀 언어로 번역해 두면 이후 채점이 빨라지고 다툼이 줄어듭니다.

1. 기준 항목(앵커)을 정합니다. 이미 출시한 기능 중 "이게 Impact 3", "이게 Impact 1"이라고 모두가 동의하는 예를 하나씩 고릅니다. 이후 새 항목은 앵커와 비교해 매깁니다.
2. Confidence 규칙을 문장으로 씁니다. 예: 100% = 실측 데이터와 사용자 검증이 모두 있음, 80% = 데이터는 있으나 추정이 섞임, 50% = 가설 수준. 규칙이 문장으로 있으면 "느낌상 80%"가 사라집니다.
3. 세 항목을 각자 채점한 뒤 비교합니다. 값이 두 단계 이상 벌어진 항목만 토론합니다. 대개 "Reach를 월로 셌다 vs 분기로 셌다"처럼 기준 차이가 원인이고, 이를 바로잡으면 나머지도 맞춰집니다.
4. 척도 문서를 백로그 옆에 둡니다. 새 팀원이 와도 같은 잣대로 채점할 수 있어야 점수의 일관성이 유지됩니다.

Reach 추정, 데이터는 어디서 가져올까

Reach는 네 값 중 유일하게 실제 숫자를 넣을 수 있는 자리입니다. 어디서 숫자를 가져왔는지에 따라 Confidence도 함께 정해집니다.

출처	어떤 항목에 쓰나	예시	Confidence 경향
제품 이벤트 로그·분석 도구	기존 화면·기능을 개선하는 항목	"내보내기 버튼을 분기당 1,500명이 누름"	높음(80~100%)
가입·활성 사용자 수 × 비율	모든 사용자에게 노출되는 항목	"활성 6,000명 중 설정 화면 진입 70%"	중간(80%)
고객 문의·CS 티켓 수	불편·오류 관련 항목	"결제 실패 문의 분기 120건 → 실제 영향은 3~4배"	중간(50~80%)
설문·인터뷰	아직 없는 기능	"응답자 200명 중 35%가 원함 → 활성 사용자에 비율 적용"	낮음(50%)
영업 파이프라인	B2B 요구 기능	"협업 기능이 없어 보류된 거래 8건, 예상 좌석 2,000"	낮음~중간(50~80%)

중요한 것은 출처를 점수표에 함께 적는 것입니다. "Reach 3,000 (로그, 8~9월 실측)"처럼 적어 두면 나중에 값이 의심될 때 바로 검증할 수 있고, 새 데이터가 들어오면 어느 항목을 갱신할지도 분명해집니다.

Effort 산정 요령

Effort는 나누는 값이라 조금만 잘못 잡아도 순위가 크게 흔들립니다. 0.5를 1로 바꾸면 점수가 절반이 됩니다. 다음 원칙으로 잡으면 과소평가를 줄일 수 있습니다.

• 개발만이 아니라 전체 공수를 셉니다. 기획·디자인·개발·테스트·배포·문서·고객 안내까지 포함합니다. "개발 2주"가 실제로는 1.5인·월이 되는 이유가 대부분 여기에 있습니다.
• 세 점 추정을 씁니다. 낙관·보통·비관 세 값을 적고 (낙관 + 4×보통 + 비관) ÷ 6으로 계산하면 "금방 하죠"가 눌립니다. 예: 0.5·1·3인·월 → (0.5 + 4 + 3) ÷ 6 ≈ 1.25인·월.
• 과거 유사 작업과 비교합니다. "지난 분기 알림 기능이 1.5인·월 걸렸으니 이번 이메일 알림도 그쯤"처럼 실적 기반으로 잡으면 근거가 생깁니다.
• 큰 항목은 쪼개서 잡습니다. 6인·월이 넘는 항목은 산출물 단위로 나눠 각각 채점합니다. 나누는 원칙은 WBS 작성법의 100% 규칙과 8/80 규칙을 그대로 쓰면 됩니다.
• Effort가 불확실하면 Confidence도 낮춥니다. "몇 달 걸릴지 모르겠다"는 항목은 Effort를 비관값으로 잡고 Confidence를 50%로 두어 이중으로 견제합니다.
• 최소 단위는 0.25인·월 정도로 둡니다. 그보다 잘게 나누면 정밀한 척 하지만 실제로는 추정 오차가 더 큽니다.

분기 로드맵에 반영하는 법

점수표는 순위표일 뿐, 로드맵은 아닙니다. 순위를 팀의 가용 공수(capacity)에 맞춰 잘라 넣어야 분기 계획이 됩니다.

1. 가용 공수를 계산합니다. 개발자 4명 × 3개월 = 12인·월이지만, 회의·운영·휴가·긴급 대응을 빼면 실제 가용률은 60~70% 정도입니다. 이 팀은 약 8인·월로 잡습니다.
2. 전략 슬롯과 유지보수 슬롯을 먼저 뗍니다. 예를 들어 20%(약 1.5인·월)는 점수와 무관하게 회사 방향에 필요한 항목에, 10%는 자잘한 버그·요청에 예약합니다. 남는 약 5.5인·월을 점수순으로 채웁니다.
3. 순위대로 누적 Effort가 가용 공수에 닿을 때까지 넣습니다. 위 표라면 엑셀 내보내기(0.5) + 온보딩(2) + 다크 모드(1) + 결제 오류(0.5) + 소셜 로그인(1) = 5인·월. 알림 이메일(1.5)은 다음 분기 첫 항목이 됩니다.
4. 전략 슬롯에는 큰 항목의 선행 작업을 넣습니다. 모바일 앱 출시 전체(12인·월) 대신 "기술 검토와 화면 설계"(1.5인·월)만 이번 분기에 넣어 다음 분기 채점 때 Confidence를 올릴 근거를 만듭니다.
5. 의존관계를 확인합니다. 소셜 로그인이 온보딩 개선의 전제라면 점수와 무관하게 먼저 배치합니다. 이런 선후 관계를 실제 일정으로 옮기는 방법은 프로젝트 일정 관리 방법과 크리티컬 패스 계산법에 있습니다.
6. 확정된 항목만 WBS·간트차트로 옮깁니다. 우선순위 계산기에서 CSV로 내려받은 순위표를 기준으로, 선정된 항목을 WBS·간트차트에 작업으로 등록해 영업일 기준 일정과 진행율을 추적하면 계획과 실행이 이어집니다.

이해관계자를 설득하는 문장 예시

점수표가 있어도 "왜 내 요청이 뒤로 밀렸느냐"는 질문은 옵니다. 이때 점수를 들이밀기보다 어떤 값 때문에 그 순위가 나왔는지를 설명하면 대화가 부드럽습니다.

• 큰 기능이 밀렸을 때 — "모바일 앱은 영향(Impact 3)은 가장 크지만 공수 12인·월에 확신도 50%입니다. 이번 분기에 점수순으로 쓸 수 있는 공수가 약 5.5인·월이라, 모바일 앱 하나만으로도 그 두 배가 넘습니다. 대신 이번 분기에 기술 검토 1.5인·월을 넣어 다음 분기 확신도를 80%로 올리는 안을 제안드립니다."
• 요청이 많은 항목이 중위권일 때 — "다크 모드는 요청 수(Reach 6,000)는 가장 많지만 한 명당 효과가 작아(Impact 0.5) 3위입니다. 상위 두 항목(엑셀 내보내기 0.5인·월, 온보딩 개선 2인·월)을 먼저 끝내고 바로 착수하겠습니다. 다크 모드 자체는 1인·월이라 이번 분기 안에 들어갑니다."
• 경영진의 직관과 다를 때 — "점수는 결론이 아니라 가정의 목록입니다. 이 항목의 Reach를 5,000이 아니라 15,000으로 보신다면 근거를 반영해 다시 계산하겠습니다. 그 근거가 있으면 순위는 바뀝니다."
• 영업팀 요청을 조정할 때 — "보류된 거래 8건은 파이프라인 기준으로 Reach 2,000에 반영돼 있습니다. 계약 확정 조건으로 붙는다면 확신도를 100%로 올려 점수가 두 배가 되고, 그 시점에 순위를 다시 보겠습니다."
• 분기 중 새 요청이 들어올 때 — "새 항목을 같은 척도로 채점해 보니 현재 3위와 4위 사이입니다. 넣으려면 소셜 로그인을 다음 분기로 넘겨야 하는데, 그 교환에 동의하시면 반영하겠습니다."

공통점은 "안 됩니다" 대신 "이 값이 이렇게 바뀌면 순위가 바뀝니다"로 말한다는 것입니다. 점수 공식이 대화의 공통 언어가 되면, 우선순위 조정이 감정 싸움이 아니라 가정을 고치는 작업이 됩니다.

자주 묻는 질문

Reach를 추정할 데이터가 전혀 없으면 어떻게 하나요?

비슷한 기능의 사용량이나 전체 활성 사용자 수에 예상 비율을 곱해 추정하고, 대신 Confidence를 50%로 낮게 잡습니다. 점수표에 추정 근거를 한 줄 적어 두고, 출시 후 실제 수치가 나오면 갱신하면 됩니다.

RICE 점수가 비슷하거나 같으면 무엇을 먼저 하나요?

Effort가 작은 쪽, 분기 목표와 더 직접 연결된 쪽, 다른 항목의 선행 조건이 되는 쪽 순서로 고릅니다. 점수 차이가 10~20% 안이면 사실상 동점으로 보고, 이런 기준으로 판단하는 편이 소수점 싸움보다 낫습니다.

버그 수정이나 기술 부채도 RICE로 채점하나요?

가능합니다. Reach는 영향을 받는 사용자 수, Impact는 결제 실패처럼 치명적이면 3점을 줍니다. 다만 서비스 장애나 보안 문제처럼 즉시 처리해야 하는 항목은 점수를 매기지 않고 바로 처리하는 것이 맞습니다.

점수는 얼마나 자주 다시 매겨야 하나요?

분기 로드맵을 짤 때 한 번, 그리고 Reach나 Effort의 근거가 크게 바뀌었을 때(사용자 급증, 기술 조사 결과 등) 해당 항목만 다시 매깁니다. 매주 전체를 다시 채점하면 팀이 지치고 점수의 신뢰도 떨어집니다.

정리

우선순위를 점수로 매기는 이유는 "정답을 기계에 맡기려는 것"이 아니라, 팀이 같은 기준으로 대화하게 만들기 위해서입니다. 데이터가 있으면 RICE로 근거 있게, 빠르게 추려야 하면 ICE로 가볍게 — 상황에 맞게 골라 쓰고, 척도를 먼저 합의한 뒤 상대 순위로 활용하면 감정·직급 싸움을 크게 줄일 수 있습니다.

→ 프로젝트 일정 관리 방법 · → WBS 작성법 · → 프로젝트 진행율 계산법 · → 사용 가이드