---
id: moscow-prioritization
title: "MoSCoW Prioritization"
category: "10_Wiki/Topics"
status: "draft"
verification_status: "conceptual"
canonical_id: ""
aliases: ["MoSCoW Method", "Must-Should-Could-Won't"]
duplicate_of: ""
source_trust_level: "B"
confidence_score: 0.85
created_at: 2026-06-12
updated_at: 2026-06-12
review_reason: ""
merge_history: []
tags: ["research", "Assumption Validation Loop", "Prioritization"]
raw_sources: ["NotebookLM Synthesis"]
applied_in: ["Instagram's MVP Feature Selection"]
github_commit: ""
---

# [[MoSCoW Prioritization]]

## 🎯 한 줄 통찰 (One-line insight)
[[Minimum Viable Product (MVP)]]의 범위를 결정할 때, 기능을 필수성(Must)과 선택성(Should/Could)으로 엄격히 분류하여 핵심 가설 검증에만 자원을 집중하게 하는 의사결정 프레임워크입니다 [1, 2].

## 🧠 핵심 개념 (Core concepts)
- **Must Have (필수):** MVP에 반드시 포함되어야 하는 기능으로, 이 기능이 없으면 제품이 작동하지 않거나 핵심 가설을 테스트할 수 없음 [1-3].
- **Should Have (중요):** 중요하지만 초기 릴리스에서 제외되더라도 제품의 생존에 치명적이지 않은 기능 [1, 2].
- **Could Have (선택):** 시간과 자원이 남을 경우에만 추가하는 '있으면 좋은(Nice-to-have)' 기능 [1, 2].
- **Won't Have (제외):** 이번 개발 사이클이나 MVP 단계에서는 명시적으로 구축하지 않기로 합의한 기능 [1, 2].

## 🧩 추출된 패턴 (Extracted patterns)
- **MVP 전용 필터링:** MVP에는 오직 'Must-have' 등급의 기능만 포함시키며, 나머지는 시간, 자원 또는 사용자 만족도에 따라 후순위로 미룹니다 [1].
- **고객 가치 중심 평가:** 어떤 기능이 고객 획득(Acquire)이나 유지(Retain)에 직접적으로 기여하는지 설명할 수 없다면, 해당 기능은 현재 단계에서 구축할 필요가 없습니다 [2].
- **무자비한 가지치기 (Ruthless Cutting):** 성공적인 MVP 사례(예: Instagram)는 위치 체크인, 메시징, 소셜 피드 같은 일반적인 기능들을 과감히 'Won't-have'로 분류하고 단 하나의 핵심 기능에 집중했습니다 [4].

## 📖 세부 내용 (Details)
MoSCoW 프레임워크는 기능 백로그를 관리하고 이해관계자들 간의 합의를 이끌어내는 데 매우 효과적인 도구입니다.

- **MVP 구축의 기준:** 단순히 제품을 작게 만드는 것이 아니라, 사용자에게 가치를 전달할 수 있는 '최소한의 생존 가능성(Viability)'을 확보하기 위해 'Must-have' 기능을 정의합니다 [2, 5].
- **리스크 관리와의 연결:** [[Riskiest Assumption Testing (RAT)]]과 결합할 때, 가장 위험한 가설을 검증하기 위해 필요한 기능이 'Must-have'가 됩니다 [6, 7].
- **실패 방지:** 많은 MVP가 실패하는 이유는 너무 많은 기능(Building too many features)을 동시에 출시하여 어떤 기능이 실제 참여를 유도하는지 분리하기 어렵기 때문입니다 [8]. MoSCoW는 6~8주 이상의 개발 기간이 소요되는 '오버엔지니어링'을 방지하는 가이드 역할을 합니다 [8].
- **비용 절감:** 'Must-have'에만 집중함으로써 불필요한 엔지니어링 시간을 줄이고, 검증되지 않은 아이디어에 수만 달러를 투자하기 전에 시장 수요를 먼저 확인할 수 있습니다 [2, 9].

## ⚖️ 모순 및 업데이트 (Contradictions & updates)
- **Viable의 해석 차이:** 'Minimum'에만 너무 치중하여 핵심 기능조차 제대로 작동하지 않으면(Broken core functionality) 유의미한 피드백을 얻을 수 없습니다 [8]. MoSCoW 분류 시 'Must-have'는 완벽한 폴리싱(Polish)은 아닐지라도 결함 없이 작동해야 함을 유의해야 합니다 [8].

## 🛠️ 적용 사례 (Applied in summary)
- **Instagram:** 초기 런칭 시 위치 체크인, 메시징, 소셜 피드 기능을 모두 제거하고 '필터가 적용된 사진 게시'라는 단 하나의 Must-have 기능에만 집중하여 MoSCoW 우선순위를 적용했습니다 [4].
- **Spotify:** 초기 MVP에서 소셜 공유나 재생 목록 기능을 배제하고 '클릭 시 즉시 음악이 재생되는 지연 시간(Latency) 해결'을 유일한 Must-have로 설정했습니다 [10].
- **Uber:** 초기에 요금 분할, 경유지 추가, 드라이버 평점 기능 없이 'iPhone 앱을 통한 블랙카 호출' 기능 하나만으로 시작했습니다 [11, 12].

## ✅ 검증 상태 및 신뢰도
- **상태:** draft
- **검증 단계:** conceptual (실제 다수의 성공적인 스타트업 사례에서 그 유효성이 입증됨)
- **출처 신뢰도:** B (전문적인 제품 관리 가이드 및 스타트업 사례 분석 기반)
- **중복 검사 결과:** 신규 생성 (New discovery)

## 🔗 관련 문서 링크 (Related document links)

### 상위/유사 개념

#### [프레임워크 및 방법론]
- [[Minimum Viable Product (MVP)]]
  - 연결 이유: MoSCoW는 MVP의 범위를 확정하는 직접적인 도구입니다.
  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 무엇이 '최소'이고 무엇이 '생존 가능'한지의 경계 설정 방법.
- [[Kano Model]]
  - 연결 이유: 사용자 만족도를 기준으로 기능을 분류하는 또 다른 프레임워크입니다.
  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: MoSCoW의 'Must-have'가 Kano의 'Basic Needs'와 어떻게 대응되는지 비교 가능 [13, 14].

#### [리스크 및 검증 도구]
- [[Riskiest Assumption Testing (RAT)]]
  - 연결 이유: 가장 위험한 가설을 검증하기 위한 실험 설계 시 MoSCoW가 우선순위 기준이 됩니다.
  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: '가장 위험한 것'을 '반드시 해야 하는 것'으로 전환하는 논리 [7, 15].

### 심층 후속 질문 (Deeper Research Questions)
- MoSCoW 분류 과정에서 이해관계자 간의 의견 충돌을 해결하기 위한 '데이터 기반' 의사결정 기준은 무엇인가?
- 제품이 성장함에 따라 기존의 'Should-have' 기능이 어떻게 'Must-have'로 전이되는가?
- [[Kano Model]]의 'Delighters' 기능을 MoSCoW 등급 중 어디에 배치하는 것이 전략적으로 유리한가? [13]
- 시간 제한(Time-boxing)이 MoSCoW 분류의 엄격함에 어떤 영향을 미치는가? [16]

### 실무 적용 맥락 (Practical Application Contexts)
- **Implementation:** 백로그 그루밍(Backlog Grooming) 세션에서 각 스토리나 기능에 MoSCoW 태그를 부여합니다.
- **System Design:** Must-have 기능 위주로 아키텍처를 설계하여 초기 기술 부채를 의도적으로 관리합니다 [17].
- **Operation / Maintenance:** 자원 부족 시 'Could-have'와 'Should-have' 기능을 먼저 제거하거나 연기하여 일정을 준수합니다 [1].
- **Learning Path:** [[Lean Startup Methodology]]를 학습하며 MVP 기획 단계에서 반드시 숙달해야 할 기술입니다 [18].

### 인접 주변 주제 (Adjacent Topics)
- [[Jobs-to-be-Done (JTBD)]]
  - 확장 방향: 사용자가 해결하려는 실제 '작업'이 무엇인지 파악하면 MoSCoW 분류의 정확도가 높아집니다 [19, 20].
- [[User Journey Mapping]]
  - 확장 방향: 사용자 여정 중 가장 마찰이 심한 지점을 찾아 이를 Must-have 기능으로 정의할 수 있습니다 [21, 22].

## 📝 변경 이력 (Change history)
- 2026-06-12: Initial draft generated via Datacollector_MAC P-Reinforce engine.