MoSCoW 우선순위 방법(MoSCoW Prioritization Method)

MoSCoW는 이미 쓰고 있는 우선순위 방법이다 — 단지 잘못 쓰고 있을 뿐

함께 일했던 모든 제품 팀은 이름을 부르든 안 부르든 MoSCoW를 합니다. "출시 전에 인증이 절대 필요해" — 그게 Must Have. "다크 모드가 있으면 좋겠어" — 그게 Could Have. 프레임워크는 단지 팀이 이미 직관적으로 하는 것에 이름을 줍니다. 문제는 MoSCoW의 규율 없이는 모든 게 Must Have로 이동한다는 점입니다.

Spotify 스쿼드 계획 세션에서 PM이 팀에게 30개 백로그 항목을 MoSCoW 버킷으로 독립적으로 분류해달라고 요청하는 걸 봤습니다. 30개 중 17개가 적어도 한 명에 의해 Must Have로 표시됐습니다. 그건 우선순위가 아닙니다. 멋진 라벨이 붙은 위시리스트입니다.

제약 없는 "Must Have"는 아무 의미도 없다

MoSCoW는 단단한 제약과 짝지어졌을 때만 작동합니다. 시간, 예산, 팀 용량 — "Must" 버킷을 채우는 것을 물리적으로 고통스럽게 만드는 것. Standish Group의 CHAOS Report에 따르면 소프트웨어 프로젝트의 35%만 제때 완료되며, 부실하게 정의된 우선순위에서 오는 스코프 크리프(scope creep)가 주요 원인입니다.

MoSCoW의 진짜 힘은 "Won't Have" 버킷에 있습니다. 대부분의 팀이 이걸 완전히 건너뛰지만, 여기서 프레임워크가 값을 합니다. 이 사이클에 *만들지 않을* 것을 명시적으로 적으면 공유된 명확성을 만듭니다. McKinsey의 제품 개발 연구에 따르면 명시적 "안 할 일" 리스트를 가진 팀은 그렇지 않은 팀보다 28% 빠르게 출시했고, 주로 정해진 결정을 다시 보는 시간이 적었기 때문입니다.

놓치기 쉬운 미묘함이 있습니다: "Won't Have"는 "절대"를 의미하지 않습니다. "이번에는 아님"을 의미합니다. 그 구별이 중요합니다. 이해관계자는 평면적 거절보다 "Won't Have(이번 분기)" 분류를 훨씬 잘 받아들입니다. 대치를 일정 잡는 대화로 바꿉니다.

이 프롬프트가 돕는 방식

이 프롬프트는 기능 리스트와 출시 컨텍스트를 받아, 정곡을 찌르는 질문으로 분류를 안내합니다. Must Have로 표시한 각 항목에 대해 묻습니다: "이것 없이 출시하면 무슨 일이 일어나는가?" 답이 "제품이 말 그대로 작동하지 않는다" 또는 "법적 요구사항을 위반한다"가 아니면, 아마 Should Have입니다. 그 단일 재프레이밍이 보통 30~40%의 항목을 한 단계 아래로 옮깁니다.

언제 손이 가야 하는가

• 출시나 스프린트를 계획 중이고 무엇이 들어가고 무엇이 빠지는지 팀을 정렬해야 할 때
• 이해관계자 에스컬레이션이 범위를 늘렸고 일정에 맞는 것을 재협상해야 할 때
• MVP를 만들고 있고 "출시 차단"과 "있으면 좋음" 사이에 단단한 선을 그어야 할 때
• 팀이 모든 게 우선순위라고 계속 말하고 동점을 깰 구조화된 연습이 필요할 때
• 로드맵 리뷰를 준비 중이고 리더십에 명확한 트레이드오프 추론을 보여줘야 할 때

좋은 결과의 모습

좋은 MoSCoW 출력은 대략 Must 20%, Should 30%, Could 30%, Won't 20%를 가집니다. Must 버킷이 전체 항목의 1/3 이상이라면 우선순위를 매긴 게 아닙니다 — 백로그를 다시 쓴 것뿐입니다. 모든 항목은 한 줄짜리 근거를 포함해야 하고, Won't 버킷은 명백한 일회용 항목이 아니라 진짜 후보들로 채워져야 합니다.

참고 자료

• CHAOS Report: Decision Latency Theory — Standish Group
• Delivering Value Faster with Better Product Prioritization — McKinsey