Files

T

Antigravity Agent c24165b8bc refactor(topics): 멀티 에이전트용 지식 재편 — _Common(공통 기본기) + Domain_* 구조

에이전트 8종(대화형/프로그래머 C·S/디자이너/설계자/기획자/QA/PD/PM)에게
[공통 기본 능력 + 롤별 Specialty] 2층으로 지식을 주입하기 위한 재분류.
문서 내용·포맷은 무수정, 폴더 이동만 (6,372개 문서 수 보존 확인).

- Topic_Programming → Domain_Programming (내부 구조 보존)
- Topic_Graphic → Domain_Design
- Topic_Business → Domain_Product
- Topic_General → Domain_General
- _Common 신설: Math(구 Topic_Math_Specialty), Reasoning(구 General/From_Thinking & Reasoning),
  Reasoning_Creativity(구 General/From_창의성), Communication(Poetic_Blog_Writing + From_writing)
- 타 도메인의 From_* 폴더는 유지 (출처 표기일 뿐, 이미 도메인에 맞게 분류된 문서)
- 빈 폴더 정리 (memory/procedures)
- 에이전트→폴더 매핑은 workspace의 .astra/agent-knowledge-map.json (9개 에이전트)

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

2026-07-11 11:05:56 +09:00

5.5 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

5Why

🎯 한 줄 통찰 (One-line insight)

표면적 현상을 넘어 문제의 본질적인 근원(Root Cause)에 도달하기 위해 '왜?'라는 질문을 반복적으로 던져 논리의 깊이를 형성하는 구조적 분석 기법 [1-3].

🧠 핵심 개념 (Core concepts)

근본 원인 규명 (Root Cause Analysis): 단순한 미봉책(현상 뒤집기)이 아닌, 문제의 시원적 본질과 기저 메커니즘을 탐색하여 재발을 방지함 [1, 3, 4].
질문의 반복성과 깊이: 통상 5회 내외의 연속적인 질문을 통해 문제 인식의 수준을 심화시키며, 질문의 깊이가 깊어질수록 해결 과제의 구체성과 실효성이 증대됨 [1, 2, 5].
인과관계의 사슬 (Causal Chain): 각 단계의 질문과 답변이 논리적으로 정합된 인과관계를 형성하여 'Why So(왜 그런가)'에 대한 명확한 근거를 제시해야 함 [6, 7].
수요 중심의 문제 정의: "어떻게 실시하는가"라는 전문가적 사고를 넘어 "어떤 문제를 왜 해결하는가"라는 전략적 사고를 통해 고객의 본질적 수요를 파악함 [8, 9].

🧩 추출된 패턴 (Extracted patterns)

현상-원인 연쇄 분해 패턴: 현상(Surface) → 직접 원인(Direct) → 중간 원인(Intermediate) → 근본 원인(Root)으로 이어지는 계단식 구조화 패턴을 보임 [1, 3].
이슈 트리(Why Tree) 정렬: 명사구 형태의 단순 분류를 넘어 가부(Yes/No) 또는 인과를 묻는 의문문 형태로 전개하여 사고의 사각지대를 제거함 [10-12].
미봉책과 근본책의 대조: 문제 인식 수준이 낮은 단계의 해결책(기름을 닦는다)과 5Why를 거친 깊은 단계의 해결책(구매 정책 변경)을 대조하여 실행 우선순위를 결정함 [1, 5].

📖 세부 내용 (Details)

정의 및 적용 시점: 5Why는 맥킨지식 문제해결 프로세스의 '문제 구조화(Structure)' 단계에서 주로 사용되며, 특히 문제의 원인을 분석하는 'Why Tree'를 구성할 때 핵심 기술로 작동한다 [6, 11, 12].
실행 원칙:
- 집요함: 단순히 5번이라는 횟수를 채우는 것이 목적이 아니라, 도출된 결과가 정말로 해당 현상을 초래한 근본적인 원인이 맞는지를 비판적으로 검토해야 한다 [13].
- 논리적 정합성: 각 단계의 원인이 하위 노드의 결과를 완벽히 설명할 수 있도록 인과관계가 분명해야 하며, 필요 시 MECE 원칙을 적용하여 원인을 분분(Breakdown)한다 [6, 14].
- 가설 기반 검증: "그 가설이 사실이려면 어떤 전제가 필요한가"를 묻는 QDT(Quick and Dirty Test)와 결합하여 원인 분석의 속도와 정확도를 높인다 [15, 16].
전략적 가치: 크게 성장한 기업일수록 과거의 성공 경험에 갇혀 본질을 놓치기 쉬운데, 5Why는 제품 중심 논리에서 수요 중심 논리로 회귀하게 하는 인지적 기틀을 제공한다 [9, 17].

⚖️ 모순 및 업데이트 (Contradictions & updates)

질문 횟수의 유연성: 일반적인 가이드라인은 '5회'를 강조하지만(5Why 습관) [1, 2], 실무 사례에 따라서는 연속 3회의 질문만으로도 진정한 목적이나 근본 원인에 도달할 수 있음이 확인된다 [8]. 핵심은 횟수가 아닌 '통찰의 도달 여부'이다 [13].
상관관계 vs 인과관계: 5Why는 인과관계를 밝히는 데 집중하지만, 현실에서는 복잡한 혼재 변수로 인해 인과관계를 분리하기 어려운 경우가 많으므로 단기적으로는 상관관계를 활용하되 장기적으로 인과관계를 추적하는 노력이 병행되어야 한다 [18].

🛠️ 적용 사례 (Applied in summary)

생산 현장 환경 개선 사례: '바닥의 기름 범벅'이라는 문제에 대해 "혼합기가 샘 → 가스켓 결함 → 품질 낮은 가스켓 구매 → 최저가 입찰 구매 정책"으로 이어지는 5단계 분석을 통해 시스템적 문제를 식별함 [1, 3].
성수대교 붕괴 원인 분석: 다리 자체의 부실(공법, 시공) 요인과 외부적 하중(신도시 건설 중장비 통행), 지정학적 물류 동선 등을 'Why' 질문으로 수평·수직 전개하여 복합 원인을 규명함 [3, 19, 20].
회의실 서비스 기획 프로젝트(M사 사례): 고객의 '못 박기' 요청에 대해 "왜 못을 박는가", "왜 의자를 만드는가" 등 연속 3회 질문을 던져 '회의실 손님 맞이 하드웨어 서비스 마련'이라는 본질적 과제를 도출함 [8].

✅ 검증 상태 및 신뢰도

상태: draft
검증 단계: conceptual (실제 적용 사례가 소스 내 구체적 에피소드로 확인됨)
출처 신뢰도: B (Official Documentation / Primary Source via NotebookLM)
중복 검사 결과: 신규 생성 (New discovery)

📝 변경 이력 (Change history)

2026-05-24: Initial draft generated via Datacollector_MAC P-Reinforce engine.

5.5 KiB Raw Blame History