2nd/10_Wiki/Topics/Thinking & Reasoning/바닷물 끓이기 금지.md

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

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
바닷물-끓이기-금지	바닷물 끓이기 금지	10_Wiki/Topics	draft	conceptual		Don't boil the ocean		B	0.85	2026-05-24	2026-05-24			research 맥킨지식문제해결 프로세스	NotebookLM Synthesis

바닷물 끓이기 금지

🎯 한 줄 통찰 (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.