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

4.7 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

바닷물 끓이기 금지

🎯 한 줄 통찰 (One-line insight)

문제 해결 시 가용한 모든 데이터를 분석하려 하지 말고, 우선순위에 따라 핵심 요인(Key Drivers)에 집중하여 효율성을 극대화하라는 맥킨지의 핵심 작업 규범이다 [1, 2].

🧠 핵심 개념 (Core concepts)

선택과 집중 (Selection and Focus): 문제와 관련된 방대한 데이터 중 상당수를 의도적으로 무시(Ignore)하고 분석 대상을 엄격히 선별한다 [1, 3].
우선순위 설정 (Prioritization): 제한된 시간과 자원을 고려하여 가장 큰 임팩트를 낼 수 있는 영역에 집중한다 [1, 2].
Work Smarter, Not Harder: 노력의 절대량보다 방향의 정확성과 분석의 효율성을 중시한다 [1, 3].
가설 기반 접근 (Hypothesis-driven): 분석 전 가설을 수립함으로써 분석 범위를 좁히고 무분별한 데이터 수집(Boiling the ocean)을 방지한다 [4].

🧩 추출된 패턴 (Extracted patterns)

80/20 법칙의 실무 적용: 결과의 80%를 좌우하는 소수의 핵심 부분(20%)을 찾아내어 힘을 분산시키지 않고 공략한다 [2, 5].
데이터 선별 휴리스틱: 분석 가능한 모든 것을 분석하는 것이 아니라, 가설 검증에 반드시 필요한 데이터만을 취사선택한다 [1, 6].
복잡성 단순화 패턴: 문제점이 2배 복잡해지면 해결 시간은 4배로 늘어나므로, 요소를 단순화하여 핵심 드라이버를 판별한다 [1, 3].

📖 세부 내용 (Details)

개념의 유래: '바닷물 끓이기'는 바닷물을 전부 끓여서 소금을 얻으려는 것과 같이, 모든 가능성을 검토하고 방대한 데이터를 전수 조사하려는 비효율적인 방식을 경계하는 맥킨지의 격언이다 [1, 2].
효율적 분석 디자인: 맥킨지식 문제 해결에서는 충분한 팩트가 조사되지 않은 단계에서 '초기가설'을 먼저 세운다 [6, 7]. 이는 결론을 미리 상정하고 이를 증명할 팩트만을 찾아 나섬으로써 불필요한 곳에서의 시간 낭비를 막기 위함이다 [8, 9].
실행 원칙: 분석가는 세상에 널려 있는 수많은 데이터 중 대부분을 무시해야 하며, 모든 것을 다 분석하려 드는 유혹을 뿌리쳐야 한다 [1, 3].
정밀도보다 방향성: 분석 시 너무 정확한 값에 매달리기보다 대략 옳은 방향으로 가는 것이 수백 배 낫다 [10, 11]. 정밀한 숫자가 중요한 것이 아니라 어느 방향이 옳은지를 제시하는 것이 본질이다 [10, 11].
Key Driver의 판별: 조사해야 할 팩트는 무한하지만 결과에 막대한 영향을 미치는 요소는 소수이므로, 이 핵심 요소에 대한 심층적인 분석이 전체적인 문제 해결의 속도를 결정한다 [10, 11].

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

정밀성 vs 속도: 일반적으로 '완벽한 분석'이 좋은 보고서의 요건이라 생각하기 쉬우나, 맥킨지 방식은 "너무 정확하게 하려 들지 마라"고 조언하며 방향의 명확성과 속도를 더 우선시한다 [10, 11].
데이터의 함정: 숫자는 객관적 사실을 나타내지만 생성 및 해석 과정에서 왜곡될 수 있으므로, 모든 데이터를 분석하기보다 검증된 핵심 숫자만을 믿어야 한다 [12, 13].

🛠️ 적용 사례 (Applied in summary)

현재 소스 데이터 내에서 특정 프로젝트 코드, Git 커밋 해시, 또는 구체적인 decision_id가 명시되어 이 개념이 적용된 사례는 발견되지 않았습니다.
다만, 맥킨지의 모든 컨설턴트가 입사 첫날 배우는 표준 문제 해결 방법론(McKinsey Method)의 근간으로 활용되고 있습니다 [14, 15].

✅ 검증 상태 및 신뢰도

상태: draft
검증 단계: conceptual (실제 적용 사례 발견 시 applied/validated로 승격 가능)
출처 신뢰도: B (Official Documentation / Primary Source via NotebookLM)
중복 검사 결과: 신규 생성 (New discovery)

📝 변경 이력 (Change history)

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

4.7 KiB Raw Blame History