2a2a1ad3b1
- 10_Wiki/Topics/Thinking & Reasoning/ 다수 신규 토픽 추가 (3C, 4P, 5 Whys, 7S, 80/20 법칙, 인과관계, 디자인 씽킹 변형 등) - Premium/Logic Tree/ 11개 파일 → Thinking & Reasoning 으로 흡수 - Premium/Thinking & Reasoning/ 동기화 갱신 - memory/long_term.json + .DS_Store 자동 갱신 Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
60 lines
4.7 KiB
Markdown
60 lines
4.7 KiB
Markdown
---
|
|
id: 바닷물-끓이기-금지
|
|
title: "바닷물 끓이기 금지"
|
|
category: "10_Wiki/Topics"
|
|
status: "draft"
|
|
verification_status: "conceptual"
|
|
canonical_id: ""
|
|
aliases: ["Don't boil the ocean"]
|
|
duplicate_of: ""
|
|
source_trust_level: "B"
|
|
confidence_score: 0.85
|
|
created_at: 2026-05-24
|
|
updated_at: 2026-05-24
|
|
review_reason: ""
|
|
merge_history: []
|
|
tags: ["research", "맥킨지식문제해결 프로세스"]
|
|
raw_sources: ["NotebookLM Synthesis"]
|
|
applied_in: []
|
|
github_commit: ""
|
|
---
|
|
|
|
# [[바닷물 끓이기 금지]]
|
|
|
|
## 🎯 한 줄 통찰 (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. |