Files

T

Antigravity Agent 9148c358d0 docs(10_Wiki): 위키 전체 재구성 — Topic_* 폴더를 4개 카테고리로 통합 + 대규모 중복 제거

Topic_Agent/Topic_Blog/Topics/Topics_Biz/Topics_Meeting/Topics_Rag의 마크다운 지식 문서를
Topic_General/Topic_Programming/Topic_Graphic/Topic_Business 4개 카테고리로 재분류.

- 중복 제거: frontmatter의 status:duplicate/merged + duplicate_of/redirect_to 필드로
  자기 자신을 중복으로 선언한 리다이렉트 stub 1032개 제거, 완전 동일 내용 파일 472개 제거,
  동일 파일명·다른 내용 충돌 시 더 큰(완전한) 버전만 유지(162개 제거) — 총 1639개 중복 제거.
- 분류: 폴더 단위로 명확한 항목(AI_and_ML/Coding/Architecture 등 → Programming,
  Comfyui/Visual_Effects → Graphic, Topics_Biz/Topics_Meeting/사업 등 → Business,
  Poetic_Blog_Writing/창의성/Game_Design 등 → General)은 폴더 우선순위로,
  나머지 혼재 폴더(Topic_Agent/Topic_Blog/Topics 루트/Thinking & Reasoning/Other/UI_UX_Assets)는
  title/tags 키워드 스코어링으로 파일 단위 분류(불명확한 경우 General로 폴백).
  원본 폴더명은 "From_*" 서브폴더로 보존해 추적 가능성 유지.
- 최종 배치: Programming 2784 / General 1608 / Graphic 285 / Business 249 = 4926개 문서.
- 에이전트 운영 상태(.astra/.agent/.obsidian/sessions/memory/_company/docs/lessons/_shared/src)는
  지식 콘텐츠가 아니므로 재분류 대상에서 제외하고 원위치 유지.
- Topics/Topic_email(상위 보호 폴더 Topic_email과 파일명 100% 중복) 삭제 — 보호 폴더 자체는 미변경.
- 완전히 비게 된 Topic_Agent/Topic_Blog/Topics_Biz/Topics_Rag 폴더 제거.

2026-07-05 00:33:48 +09:00

7.4 KiB

Raw Blame History

id, title, category, status, verification_status, canonical_id, aliases, duplicate_of, source_trust_level, confidence_score, created_at, updated_at, review_reason, merge_history, tags, raw_sources, applied_in, github_commit

title

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)

상위/유사 개념

[프레임워크 및 방법론]

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.

7.4 KiB Raw Blame History