15초 요약
프레임워크는 정답을 주는 도구가 아니라 대화를 구조화하는 도구다.
RICE, MoSCoW, Kano 같은 우선순위 프레임워크들은 PM 면접 단골 질문이자 블로그 단골 주제입니다. 하지만 현업에서 "RICE 점수 높으니까 이거 먼저 해요"라고 통하는 조직은 드물죠. 프레임워크의 진짜 가치는 숫자가 아니라, "왜 이게 먼저인지"를 이해관계자와 논의할 때 공통 언어를 제공한다는 점이에요. 도구의 목적을 오해하면, 스프레드시트만 예쁘고 결국 HiPPO(Highest Paid Person's Opinion)가 결정하는 상황이 반복됩니다.
알아두면 좋은 용어
- RICE: Reach(도달 범위), Impact(영향도), Confidence(확신도), Effort(노력)를 점수화해 우선순위를 매기는 방식
- MoSCoW: Must/Should/Could/Won't Have로 기능을 분류하는 방법. MVP 정의할 때 자주 쓰임
- Kano Model: 고객 만족 관점에서 기능을 기본 기대/성능/감동 요소로 분류하는 프레임워크
- HiPPO: Highest Paid Person's Opinion. 결국 높은 사람 의견대로 가는 현상을 비꼬는 표현
Y's Insight
프레임워크, 실제로 써봤더니
솔직히 말할게요. 10년 넘게 PM의 잡부 일을 하면서, RICE 점수표 만들어서 의사결정한 적 손에 꼽습니다. 주니어 시절, 우선순위 정하는게 너무 어려워서 구글에 검색했더니 RICE 기법을 알려줘서 그대로 사용했다가 실질적으론 도움이 1도 안된 경험은 몇 번 있어요. 대부분의 조직에서 우선순위는 프레임워크가 아니라 "CEO가 어제 본 경쟁사 기능", "영업팀이 잃을 뻔한 대형 고객 요청", "분기 끝나기 전에 뭐라도 출시해야 하는 압박"으로 정해지거든요. 그래서 프레임워크가 쓸모없다? 아니에요. 쓰는 방법이 잘못된 거예요.
진짜 가치는 점수가 아니라 '과정'
프레임워크의 진짜 가치는 "점수를 매기는 과정"에 있습니다. RICE를 예로 들면, Reach를 추정하려면 "이 기능 누가 쓰지?"를 구체적으로 따져야 하고, Impact를 정하려면 "성공하면 지표가 얼마나 움직이지?"를 논의해야 해요. Confidence를 낮게 잡으면 "왜 확신이 없지? 검증이 더 필요한 거 아냐?"라는 질문이 나오고요. 이 과정에서 팀이 같은 정보를 공유하고, 가정을 명시적으로 드러내게 됩니다.
저의 팀원이었던 PM 중에 프레임워크 덕후가 있었어요. 모든 기능에 RICE 점수를 매기고, 엑셀 정렬해서 "1등이니까 이거요"라고 발표했는데 매번 묵살당했어요. 묵살했다라는 표현이 맞겠네요^^ 왜? 점수의 근거가 본인 머릿속에만 있었거든요. 반면 같은 프레임워크를 쓰더라도, "Reach를 이렇게 잡은 이유는 지난달 DAU 데이터 기준이고, Impact는 A/B 테스트 결과 유사 기능이 전환율 15% 올렸던 걸 참고했어요"라고 설명하면 그제서야 논의가 시작돼요. 동의하든 반박하든, 최소한 같은 숫자를 보면서 얘기할 수 있게 되거든요. 프레임워크는 설득의 구조를 만드는 도구지, 설득 자체가 아닙니다.
프레임워크별 실전 팁
MoSCoW — 이론적으로는 깔끔한데, 실제로 쓰면 "우리 기능 다 Must-have 아니야?"라는 논쟁이 시작됩니다. 그래서 저는 MoSCoW 쓸 때 "Must-have는 이게 없으면 출시 자체가 불가능한 것만"이라고 기준을 빡빡하게 잡아요. "있으면 좋은데 없어도 써볼 수는 있다"면 Should-have입니다. 이 기준 없이 MoSCoW 돌리면 Must-have에 20개 쌓이고, 결국 아무것도 필터링 안 된 것과 같아져요.
Kano 모델 — 고객 관점을 잡는 데 유용하지만, 설문 설계와 분석에 시간이 많이 들어요. 스타트업에서 Kano 제대로 돌릴 여유가 있는 경우는 드뭅니다. 대신 "이 기능 없으면 사용자가 화낼까(Basic), 있으면 좋아할까(Performance), 있으면 깜짝 놀랄까(Excitement)"를 팀 내부에서 빠르게 논의하는 용도로 쓰면 가성비가 높아요.
상황별 프레임워크 선택 가이드
잠깐, 먼저 짚고 갈게요. 아래 가이드는 "이 상황엔 이 프레임워크"라는 공식이 아니에요. 프레임워크의 본질은 "우리가 뭘 모르는지 드러내고, 같은 기준으로 대화하게 만드는 것"입니다. RICE든 MoSCoW든, 형식 그대로 따라하는 게 아니라 그 안에 담긴 질문을 던지는 게 핵심이에요. 참고만 하세요!
뭘 만들지도 모르겠다 — MVP/초기 스타트업 → MoSCoW로 시작하세요. 복잡한 점수 계산보다 "이거 없으면 출시 불가 vs 나중에 해도 됨"을 빠르게 나누는 게 먼저예요. 데이터도 없는데 RICE 돌리면 전부 추측 게임이 됩니다.
기능은 많은데 뭐 먼저 할지 모르겠다 — 성장기 제품 → RICE가 빛을 발하는 타이밍이에요. DAU, 전환율, CS 문의 데이터가 쌓였으니 Reach와 Impact를 숫자로 잡을 수 있어요. 단, Confidence 낮은 건 솔직하게 표기하세요.
이해관계자가 많고, 다 다른 소리 한다 — 대기업/복잡한 조직 → RICE + MoSCoW 조합 추천해요. RICE로 객관적 점수 먼저 보여주고, MoSCoW로 "그래서 이번 분기엔 이것만"을 합의하는 2단계 접근이 효과적이에요. 숫자가 있어야 HiPPO를 막을 최소한의 방패가 생깁니다.
고객이 뭘 원하는지 모르겠다 — 방향성 혼란 → Kano 라이트 버전 쓰세요. 정식 설문 돌릴 시간 없으면, 5명만 인터뷰하면서 "이 기능 없으면 어떨 것 같아요?"라고 물어보세요. Basic/Performance/Excitement 감이 잡힙니다.
다음 주까지 결정해야 한다 — 시간 없음 → Value vs. Effort 2x2 매트릭스면 충분해요. 화이트보드에 4칸 그리고 포스트잇 붙이세요. 30분이면 끝나고, Quick Win(고가치-저노력)부터 치면 됩니다.
프레임워크가 통하지 않는 상황들
솔직히, 프레임워크가 아무 소용없는 상황도 있어요. 있는 정도가 아니라 아주 많죠. 이런 케이스에서 RICE 점수표 들이밀면 오히려 역효과납니다.
대표님이 이미 결정했어요 → 위에서 내려온 결정에 프레임워크로 반박하려 들면 정치적으로만 손해예요. 이럴 땐 프레임워크 대신 "이 결정이 성공하려면 뭐가 필요한지"에 집중하세요. "대표님 의견대로 가되, 이 지표가 X 이하면 2주 후 재검토하죠"처럼 퇴로를 미리 깔아두는 게 현실적인 PM의 역할입니다.
정치 싸움 중이에요 → A팀과 B팀이 자기 기능 먼저 하자고 싸우는 상황에서 RICE 점수 들이대면, "니네가 점수 유리하게 조작한 거 아냐?"로 번져요. 이럴 땐 제3자(데이터팀, 고객 목소리, 외부 자문)를 끌어들이거나, 아예 "둘 다 작게 해보고 결과로 판단하자"는 실험 구조로 전환해보세요.
긴급 장애 / 법적 이슈 / 보안 문제 → 프레임워크 돌릴 시간 없어요. 당연히 먼저 해야 합니다. 이런 건 우선순위 논의 대상이 아니라 무조건 1순위예요. 프레임워크는 "선택지가 여러 개일 때" 쓰는 도구지, 선택지가 하나뿐인 상황에선 의미 없어요.
데이터가 아예 없어요 → Reach도 모르고 Impact도 추측인데 RICE 점수 매기면 자기만족이에요. 이럴 땐 프레임워크 대신 "가장 빠르게 검증할 수 있는 게 뭐지?"를 기준으로 삼으세요. 우선순위의 기준이 "임팩트"가 아니라 "학습 속도"가 되는 거예요. 2주 안에 배울 수 있는 것부터 하고, 데이터 쌓이면 그때 프레임워크를 꺼내도 전혀 늦지 않습니다.
결론: 프레임워크는 만능 도구가 아닙니다.
"이 상황에 프레임워크가 도움이 될까?"를 먼저 판단하고, 안 되면 과감히 다른 방법을 쓰세요. 프레임워크를 못 쓰는 게 부끄러운 게 아니라, 상황 파악 없이 프레임워크만 고집하는 게 더 문제예요.
실제 적용 사례
Intercom (RICE 창시자)
- RICE 프레임워크를 만든 팀이지만, 그들도 강조하는 건 "RICE는 토론 시작점이지 최종 결정자가 아니다"
- 점수가 높아도 전략적 방향과 안 맞으면 과감히 후순위로 미룸
- 핵심: 프레임워크 만든 사람들조차 점수에 맹목적으로 따르지 않는다
Air France-KLM 화물 리포팅 MVP
- 타이트한 일정과 예산 속에서 MoSCoW로 스코프 관리
- 연료비 수백만 달러 절감하는 항로 최적화 리포팅만 Must-have로 분류
- 다크모드, 커스텀 레이아웃 같은 UX 개선은 Could-have로 밀어냄
- 핵심: "이거 없으면 출시 의미 없다"를 기준으로 냉정하게 쳐냄
Slack 초기 (프레임워크 없이 성공한 케이스)
- 초기엔 정교한 우선순위 프레임워크 없이, 창업자가 직접 고객과 대화하며 "가장 많이 불편해하는 것"부터 해결
- 데이터가 없던 시절엔 "학습 속도"가 우선순위 기준이었음
- 핵심: 프레임워크는 도구일 뿐, 고객 목소리를 직접 듣는 게 먼저다
근데 말이죠
현실에서 "이런 프레임워크 썼어요"라는 표현은 지양해주세요. 왜냐면, 프레임워크라는 단어가 나오는 순간 "그게 뭐 우리 상황에 맞아?"라는 의심이 생기거든요. 비즈니스 상황, 리소스, 조직 문화 다 다른데 프레임워크 하나로 정답이 나올 리가 없잖아요. 그래서 유연성 없이 점수표만 들이미는 PM을 보면 좀 답답해요.
그래서 실제로 RICE 기법을 썼더라도, 발표할 땐 이렇게 말해보세요.
❌ "RICE 점수 계산해봤는데 이 기능이 42점으로 1등이에요"
✅ "이 기능을 먼저 하자고 생각한 이유는, 지난달 활성 사용자 중 약 60%가 이 플로우를 거치고 있고, 유사한 개선을 했던 B사 케이스에서 전환율이 15% 올랐어요. 다만 우리 상황에 그대로 적용될지는 확신이 좀 낮아서, 2주짜리 MVP로 먼저 검증해보면 어떨까요?"
똑같이 Reach, Impact, Confidence, Effort를 다 고려한 건데, 프레임워크 용어 대신 맥락과 근거를 풀어서 설명하는 거예요. 이렇게 하면 "RICE가 뭐예요?"라는 질문도 안 나오고, "그 점수 어떻게 나온 거야?"라는 의심도 줄어들어요. 듣는 사람 입장에서도 훨씬 납득이 쉽고요.
프레임워크는 내 머릿속을 정리하는 도구로 쓰고, 남한테 설명할 땐 그 과정에서 나온 생각을 자연스럽게 풀어내는 게 더 효과적입니다. "프레임워크 공부했다"를 티 내려고 용어 쓰는 순간, 오히려 소통이 막히니 주의하세요.