오늘은 PM이라면 반드시 알아야 할, 아니, 잘해야 할 ‘우선순위 결정 프레임워크’에 대해 이야기해볼게. PM 일이라는 게 참 그렇거든? 할 일은 산더미처럼 쌓여있고, 팀원들의 시간과 자원은 한정되어 있고, 또 각자 중요하다고 생각하는 게 다 다르잖아. 이럴 때 뭘 먼저 해야 할지 명확하게 정하지 못하면 프로젝트는 표류하고, 팀원들은 지쳐버리고, 결국 결과물도 좋지 않게 되더라. 내가 PM 10년차인데, 정말 이 우선순위 결정만큼 중요한 게 없다고 느껴. 수많은 이해관계자들의 요구사항과 한정된 자원 속에서 ‘무엇이 가장 중요한가’를 판단하고 설득하는 것이 PM의 핵심 역량이거든. 단순히 "이거 중요해요!"라고 외치는 게 아니라, 객관적인 기준과 논리를 가지고 팀과 이해관계자들을 설득해야 해. 그래서 오늘은 실무에서 정말 유용하게 쓰이는 우선순위 결정 프레임워크 몇 가지를 소개해줄게.

data analytics dashboard

1. MoSCoW 프레임워크: 기본 중의 기본, 명확한 분류로 팀 합의 이끌어내기

MoSCoW는 Must-have, Should-have, Could-have, Won't-have의 약자인데, 각각의 의미는 다음과 같아.

  • Must-have (반드시 있어야 할 기능): 제품이 출시되거나 특정 목표를 달성하기 위해 절대적으로 필요한 기능이야. 이게 없으면 제품 자체가 의미가 없거나, 치명적인 문제가 발생할 수 있지. 예를 들어, 온라인 쇼핑몰이라면 '결제 기능' 같은 게 Must-have겠지?
  • Should-have (있으면 좋지만 없어도 되는 기능): 제품의 가치를 크게 높여주지만, 없어도 제품이 동작하는 데는 문제가 없는 기능이야. 출시 시점에 포함되면 좋지만, 시간이나 자원이 부족하면 다음 단계로 미룰 수 있어. 예를 들어, '상품 추천 기능' 같은 게 될 수 있겠네.
  • Could-have (있으면 더 좋은 기능): 있으면 사용자 경험을 소소하게 개선해주지만, 중요도가 낮아서 쉽게 포기할 수 있는 기능이야. '댓글 이모티콘 추가' 같은 사소한 기능들이 여기에 해당될 수 있어.
  • Won't-have (이번에는 하지 않을 기능): 이번 스프린트나 릴리즈에서는 아예 고려하지 않을 기능이야. 보통 미래 계획으로 넘기거나, 자원이 너무 많이 들어서 포기하는 기능들이지. 실무 팁: MoSCoW 프레임워크는 특히 MVP(Minimum Viable Product)를 만들 때 정말 유용해. 팀원들과 함께 각 기능을 이 4가지 카테고리에 분류해보는 시간을 가져봐. "이게 정말 Must-have인가?"라고 서로 질문하면서 논의하다 보면, 생각보다 많은 기능들이 Should-have나 Could-have로 내려오는 경우가 많거든. 이 과정에서 팀 전체가 제품의 핵심 가치에 집중할 수 있게 돼.

2. RICE 스코어링: 데이터와 직관을 결합한 객관적인 평가

RICE는 Reach, Impact, Confidence, Effort의 약자로, 각 요소를 점수화해서 우선순위를 정하는 방법이야. 주관적인 판단을 최소화하고 객관적인 지표로 우선순위를 매기는 데 도움을 주지.

  • Reach (얼마나 많은 사용자에게 영향을 미칠까?): 해당 기능이 얼마나 많은 사용자에게 도달할지, 혹은 얼마나 자주 사용될지 추정하는 거야. 예를 들어, '월간 활성 사용자 10만 명 중 20%가 사용할 기능'이라면 Reach는 2만 명이 되겠지.
  • Impact (사용자에게 얼마나 큰 영향을 줄까?): 이 기능이 사용자 경험이나 비즈니스 목표에 얼마나 긍정적인 영향을 미칠지 평가하는 거야. 보통 1(낮음)부터 5(매우 높음)까지의 척도를 사용하는데, 이건 팀마다 기준을 정하기 나름이야.
  • Confidence (이 평가에 얼마나 확신이 있을까?): Reach와 Impact 추정치에 대해 얼마나 확신하는지 나타내는 지표야. '데이터가 명확해서 100% 확신', '어느 정도 추정이라 80% 확신', '그냥 감이라 50% 확신' 등으로 비율을 매길 수 있어.
  • Effort (얼마나 많은 노력이 필요할까?): 개발, 디자인, QA 등 해당 기능을 구현하는 데 필요한 총 노력을 추정하는 거야. 보통 '인월(Person-months)'이나 '스토리 포인트'로 계산하지. 계산 방법: (Reach x Impact x Confidence) / Effort 실무 팁: RICE 스코어링은 특히 여러 기능 후보가 있을 때, 어떤 것을 먼저 개발할지 결정하는 데 아주 효과적이야. Impact와 Confidence는 PM의 직관과 시장 조사를 기반으로, Reach는 데이터 분석 팀과 협의해서, Effort는 개발 팀과 상세히 논의해서 점수를 매겨야 해. 이 점수가 높을수록 우선순위가 높은 기능이 되는 거지. 단, 너무 숫자에만 매몰되지 말고, 점수 외적인 전략적 중요도도 함께 고려하는 유연함이 필요하다는 점 잊지 마.

team collaboration

3. 가치/노력 매트릭스 (Value/Effort Matrix): 시각적으로 한눈에 파악하기

이 프레임워크는 X축을 '노력(Effort)', Y축을 '가치(Value)'로 놓고 각 기능을 4분면에 배치해서 우선순위를 시각적으로 파악하는 방법이야. 팀원들과 화이트보드에 포스트잇을 붙여가며 논의하기 정말 좋지.

  • Quick Wins (고가치, 저노력): 가장 먼저 해야 할 기능들이야. 적은 노력으로 큰 가치를 만들어낼 수 있기 때문에, 팀의 사기를 높이고 빠르게 성과를 보여줄 수 있지. 예를 들어, 치명적인 버그 수정이나 사용자 경험을 크게 개선하는 작은 기능 같은 것들이 여기에 해당돼.
  • Big Bets (고가치, 고노력): 장기적으로 큰 가치를 가져올 수 있지만, 많은 시간과 노력이 필요한 기능들이야. 전략적으로 중요하기 때문에 충분한 계획과 자원 투입이 필요해. 대규모 기능 개발이나 플랫폼 리팩토링 같은 것들이지.
  • Fill-ins (저가치, 저노력): 당장 급하지는 않지만, 여유가 있을 때 해두면 좋은 기능들이야. Quick Wins와 Big Bets를 처리하고 남은 시간에 고려할 수 있어.
  • Thankless Tasks (저가치, 고노력): 가장 피해야 할 기능들이야. 시간과 노력은 많이 드는데, 가져오는 가치는 적어서 팀의 에너지만 소모시키거든. 이런 기능들은 과감하게 포기하거나, 아예 하지 않는 게 답이야. 실무 팁: 이 매트릭스는 팀원들이 각 기능의 상대적인 가치와 노력을 직관적으로 이해하고 합의하는 데 큰 도움을 줘. 특히 'Quick Wins'에 집중해서 빠르게 성과를 내는 경험을 하는 것이 중요해. 그리고 'Thankless Tasks'는 왜 하지 말아야 하는지 팀원들과 명확히 소통하고 공감대를 형성하는 게 중요하더라. 결국 우선순위 결정 프레임워크는 도구일 뿐이야. 중요한 건 이 도구를 활용해서 '왜' 이 기능을 먼저 해야 하는지 논리적으로 설명하고 팀과 이해관계자들을 설득하는 능력이지. 모든 이해관계자를 100% 만족시킬 수는 없다는 현실을 인정하고, 때로는 과감하게 'No'라고 말할 줄도 알아야 해. 데이터와 직관을 적절히 활용하고, 무엇보다 팀원들과 끊임없이 소통하면서 우리 제품의 진짜 핵심 가치가 무엇인지 함께 찾아나가야 한다고 생각해. 이 프레임워크들을 꾸준히 적용해보고, 우리 팀과 제품에 가장 잘 맞는 방식으로 자신만의 노하우를 쌓아가 봐. 결국 PM의 일은 '가장 중요한 것을 가장 먼저 하는 것'이거든.