요구사항 우선순위 정하는 법 (RICE, MoSCoW)

 

백로그에 요구사항이 쌓이기 시작하면 반드시 마주치는 질문이 있습니다.
"이 중에 뭘 먼저 해야 하나요?"
저도 처음엔 이 질문에 감으로 답했다가 매번 다른 팀원들과 부딪히곤 했는데, 결국 프레임워크의 도움을 받기로 했습니다.
오늘은 저희 팀이 실제로 써본 RICE와 MoSCoW 두 가지 방법을 정리해보려고 합니다.

 

프레임워크를 쓰기 전에는 회의실에서 목소리 큰 사람 순서대로 우선순위가 정해지는 경우가 많았습니다.
대표님이 "이거 급한 것 같은데"라고 하면 그 주 스프린트 최우선 작업이 됐고, 영업팀이 강하게 요청하면 로드맵 순서가 뒤바뀌었어요.
문제는 이렇게 정해진 우선순위를 나중에 누가 물어보면 설명할 방법이 없다는 거였습니다.
"왜 이걸 먼저 했나요?"라는 질문에 "그때 급해 보여서요"라고 답하는 게 몇 번 반복되니까, 저부터도 이 방식에 자신이 없어졌습니다.

 

RICE 프레임워크

RICE는 Reach(도달), Impact(영향력), Confidence(확신도), Effort(투입 노력) 네 가지 요소로 점수를 매기는 방식입니다.
계산 공식은 (Reach × Impact × Confidence) ÷ Effort로, 숫자가 높을수록 우선순위가 높다고 봅니다.
저희 팀은 이걸 스프레드시트로 만들어서 매 분기 백로그 항목마다 점수를 매기기 시작했어요.

Reach는 "이번 분기에 이 기능이 몇 명의 사용자에게 영향을 주는가"를 숫자로 적습니다.
Impact는 1(최소)부터 3(최대)까지 척도로, 사용자 행동에 얼마나 큰 영향을 주는지를 판단해요.
Confidence는 이 예측이 얼마나 확실한지를 퍼센트로 적는데, 데이터 근거가 있으면 100%, 순수 감으로 추측한 거면 50% 이하로 낮춰서 적도록 규칙을 정했습니다.
Effort는 개발팀이 사람-주(person-week) 단위로 추정한 값을 그대로 씁니다.

처음 이 방식을 도입했을 때 흥미로웠던 건, 다들 "당연히 이게 1순위"라고 생각했던 기능이 실제 점수로는 3위, 4위로 내려간 경우가 있었다는 겁니다.
저희 팀에서 야심차게 준비했던 알림 개인화 기능이 RICE 점수로는 낮게 나왔는데, Reach가 예상보다 훨씬 작았기 때문이었어요.
실제로 이 기능을 쓸 만한 사용자 세그먼트를 다시 계산해보니 전체 사용자의 8% 정도밖에 안 됐던 거죠.
반면 다들 "그냥 소소한 개선"이라고 생각했던 검색 필터 개선이 Reach와 Confidence가 높게 나와서 순위가 확 올라갔습니다.

 

MoSCoW

RICE는 여러 프로젝트 사이의 우선순위를 정할 때 유용했는데, 하나의 프로젝트 안에서 "이번 릴리즈에 뭘 넣을지"를 정할 때는 MoSCoW가 더 잘 맞았습니다.
Must have(반드시 필요), Should have(있으면 좋음), Could have(가능하면), Won't have(이번엔 안 함) 네 가지로 요구사항을 분류하는 방식이에요.

저희는 스프린트 계획 회의 때 화이트보드에 이 네 칸을 그려놓고, 티켓마다 스티커 메모를 붙이는 방식으로 진행했습니다.
재미있는 건 Must have 칸에 스티커를 붙이려는 사람이 항상 많았다는 거예요.
개발팀 리드가 "Must have 기준이 뭔가요"라고 물었을 때, 저희는 "이게 없으면 이번 릴리즈 자체를 출시할 수 없는가"로 기준을 다시 정리했습니다.
이 기준을 명확히 하고 나서야 Must have 칸의 티켓 수가 15개에서 6개로 줄었어요.

Won't have 칸을 만든 것도 의외로 효과가 컸습니다.
"이번엔 안 함"이라고 명시적으로 적어두니까, 회의 중에 "이것도 같이 하면 좋지 않을까요"라는 이야기가 나와도 Won't have 칸에 붙이고 넘어갈 수 있었어요.
아예 논의 대상에서 빼는 게 아니라 "지금은 아니지만 기록은 남겨둔다"는 느낌이라, 아이디어를 낸 사람도 크게 서운해하지 않더라고요.

 

 

RICE와 MoSCoW를 같이 쓰면서 느낀 건, 프레임워크가 결정을 대신 내려주는 게 아니라는 점입니다.
숫자와 카테고리는 논의의 출발점일 뿐이고, 결국 최종 판단은 사람이 해야 해요.
저희도 RICE 점수가 낮게 나온 기능을 일부러 우선순위에 올린 적이 있습니다.
법적 규제 대응처럼 점수로는 안 잡히지만 반드시 해야 하는 일이었거든요.
프레임워크에 너무 매몰돼서 "숫자가 이렇게 나왔으니 무조건 이 순서"라고 밀어붙이면, 오히려 팀의 판단력을 프레임워크 뒤에 숨기는 꼴이 될 수 있다는 걸 배웠습니다.

 

이 두 프레임워크를 도입하고 나서 가장 크게 달라진 건 우선순위 논쟁에 걸리는 시간이었습니다.
예전엔 우선순위 하나 정하는 데 회의가 한 시간씩 걸렸는데, 지금은 스프레드시트에 점수가 이미 정리되어 있으니 논의는 "이 점수가 맞는지"에 집중되고, 훨씬 짧게 끝나요.
다만 이 프레임워크가 정착되기까지는 시간이 좀 걸렸습니다.
처음 두세 번은 팀원들이 "이거 또 무슨 양식 채우라는 거예요"라며 귀찮아했거든요.
그런데 몇 번 반복하고, 특히 감으로 정했던 예전 방식과 비교해서 논쟁이 얼마나 줄었는지를 눈으로 보여주고 나서야 팀 전체가 이 방식에 익숙해졌습니다.

 

프레임워크는 결국 도구입니다

 

RICE와 MoSCoW 둘 다 완벽한 답을 주는 건 아니지만, 적어도 "왜 이 순서인가"에 대한 대답을 팀 전체가 같은 언어로 할 수 있게 해줬다는 점에서 저는 확실히 도입할 만한 가치가 있었다고 생각합니다.
다음 분기에는 여기에 고객 세그먼트별 가중치를 더해서 좀 더 정교하게 다듬어볼 계획이에요.