솔직히 말하자. RICE 스코어링 세션이 끝나고 "예상 밖의 결과"가 나온 적이 몇 번이나 있었나?

나는 5년 동안 PM을 하면서 우선순위 프레임워크를 수십 번 돌렸다. RICE, ICE, MoSCoW, Value vs Effort 매트릭스. 결과는 거의 매번 같았다. 이미 하고 싶었던 기능이 1순위로 올라왔다. 프레임워크가 결정을 도운 게 아니라, 내가 프레임워크를 도운 거다.

숫자가 객관적이라는 착각

Impact 점수를 3으로 줄까 4로 줄까 고민하는 순간, 이미 그 기능을 밀고 싶다는 뜻이다. 진짜 안 중요한 건 고민 없이 1을 준다. Confidence도 마찬가지다. 내가 확신이 있는 건 높게, 남이 제안한 건 낮게. 숫자가 객관적으로 보이지만 입력값 자체가 주관이니까 출력도 주관이다.

실제로 겪은 일이다. B2B SaaS 제품에서 대시보드 리디자인과 API 속도 개선이 동시에 올라왔다. 대시보드 리디자인의 Impact를 놓고 PM 3명이 각각 2, 4, 5를 줬다. 같은 기능, 같은 맥락인데 점수가 2.5배 차이 난다. Reach도 비슷했다. "MAU 기준으로 잡을까, DAU로 잡을까"에 따라 순위가 뒤집혔다. 측정 기준을 어떻게 잡느냐가 곧 결론을 정하는 거였다.

이건 RICE만의 문제가 아니다. ICE(Impact, Confidence, Ease) 역시 세 항목 전부 주관적 추정이고, MoSCoW는 "Must Have"와 "Should Have"의 경계를 어디에 긋느냐로 매번 싸움이 난다. Kano 모델? 설문 설계에 따라 같은 기능이 Delighter가 되기도 하고 Indifferent가 되기도 한다. 프레임워크의 종류를 바꿔봤자 근본적인 한계 — 사람의 판단이 입력된다는 점 — 는 동일하다.

그래도 버리지 못하는 이유

프레임워크의 쓸모는 의사결정이 아니라 커뮤니케이션에 있다. "RICE 점수가 높아서요"라고 답하면 대화가 끝난다. 숫자를 깔아놓고 이견 있는 항목만 논의하면 회의가 20분 만에 끝나고, 감정 싸움도 줄어든다. 문제는 이걸 진짜 분석인 것처럼 포장할 때다.

프레임워크를 제대로 쓰는 법

차라리 이렇게 하자. 프레임워크를 돌리기 전에 직감으로 순위를 매겨본다. 종이에 대충 적어도 되고, 슬랙에 "내 감으로는 A > C > B"라고 한 줄 남겨도 된다. 그 다음 RICE를 돌린다. 두 결과가 다르면 그때 비로소 진짜 토론이 시작된다. 왜 내 직감과 숫자가 다른지, 어떤 가정이 잘못됐는지. 이 간극에서 나오는 대화가 프레임워크 자체보다 훨씬 가치 있다.

실제로 이 방법을 팀에 도입했을 때, 가장 큰 변화는 "점수 조정 협상"이 줄었다는 거다. 예전에는 RICE 세션에서 "Impact를 3에서 4로 올리자"는 식의 미세 조정에 시간을 쏟았는데, 직감 순위를 먼저 깔아놓으니까 논점이 "왜 너는 이걸 2순위로 보는데 RICE는 5순위로 나오냐"로 바뀌었다. 훨씬 생산적인 질문이다.

Spotify의 DIBB 프레임워크(Data-Insight-Belief-Bet)가 비슷한 철학인데, 여기서도 핵심은 Belief — 결국 우리가 뭘 믿느냐 — 를 명시적으로 적게 만든다는 점이다. RICE에 이 단계를 하나 추가하는 것만으로도 "가짜 객관성" 문제가 상당히 해소된다. 전 직장에서 분기 회고를 할 때마다 반복되던 패턴이 있었다. 출시 후 지표가 안 나온 기능의 의사결정 과정을 되짚어보면, RICE 시트만 남아있고 왜 그 점수를 줬는지 아무도 기억 못 했다. 직감을 먼저 기록해두면 최소한 "그때 나는 이렇게 판단했고, 이 부분이 틀렸다"는 복기가 가능해진다.

우선순위 프레임워크는 나쁜 도구가 아니다. 다만 그게 뭘 해주는 도구인지 정확히 알고 써야 한다. 결정을 내려주는 게 아니라, 이미 내린 결정을 팀이 빠르게 수긍하게 만드는 장치다. 그리고 진짜 좋은 PM은 프레임워크 점수가 아니라, 그 점수가 직감과 어긋났을 때 멈춰서 생각하는 습관으로 구분된다.