✍️ 필사 모드: 엔지니어를 위한 멘탈 모델 50선 — 시스템 사고·1차/2차 효과·Charlie Munger·Bayes·파인만·스토아·Kelly·인지 편향까지 결정의 질을 바꾸는 사고 도구 완전 가이드

"You must know the big ideas in the big disciplines and use them routinely — all of them, not just a few." — Charlie Munger

[재무 가이드]까지 오면서 우리는 엔지니어 커리어·창업·돈을 다뤘다. 하지만 이 모든 것의 근본은 하나다 — 더 나은 결정을 내리는 것.

Charlie Munger는 "latticework of mental models"를 말했다. 한 학문만 알면 "망치를 든 사람에게 모든 것이 못처럼 보인다". 여러 학문의 핵심 개념(빅 아이디어)을 내 머릿속 격자로 엮어야 복잡한 현실을 제대로 본다.

이 글은 엔지니어에게 반복적으로 유용한 50가지 멘탈 모델을 카테고리별로 정리한다. 각 모델은 정의·사례·코드/일상 적용을 짧게 담는다. 전부 외우려 하지 말고, 자기 문제에 어떤 것이 적용될지 감각을 기르는 데 쓰라.

목차

1. 사고의 프레임: First Principles·파인만·Steelmanning
2. 시스템 사고: 피드백 루프·레버리지·1차/2차 효과
3. 확률·Bayes: 베이즈 업데이트·Base rate·Black Swan
4. 경제·의사결정: Opportunity Cost·Kelly·Prospect Theory
5. Charlie Munger lattice: 20가지 핵심 모델
6. 인지 편향 20선
7. 스토아 철학: 엔지니어를 위한 실용 철학
8. Anti-fragile와 Via Negativa
9. 일상에서 멘탈 모델 루틴화
10. 체크리스트와 안티패턴

1. 사고의 프레임

1.1 First Principles (제1원리)

Elon Musk가 유명하게 만든 접근. 기본 진리까지 쪼개고 처음부터 재조합.

• 유추(Analogy): "기존 로켓이 $60M이니 우리도 비슷하겠지."
• First Principles: "로켓 구성 원소의 시장가는 얼마인가? 2% 정도? 그럼 98%는 조립·공정이다."

엔지니어 적용:

• "왜 우리는 Kubernetes를 쓰는가?" → 규모·자동화·표준.
• 그 중 진짜 필요한 것만 남기면 Nomad·ECS가 나은 경우도.

1.2 Feynman Technique

리처드 파인만의 학습법.

1. 쉬운 언어로 설명.
2. 막히면 다시 공부.
3. 더 단순화.
4. 비유와 이야기 만들기.

엔지니어 적용: 새 기술을 팀 miting에서 5분 말로 설명해보라. 막힌 곳이 진짜 이해 못 한 곳.

1.3 Steelmanning

상대방 주장의 가장 강한 버전을 만들어 반박. Strawmanning의 반대.

엔지니어 적용: PR 리뷰에서 반대 의견에 대해 "내가 그 입장이라면 무엇이 가장 강한 이유일까?"

1.4 Rubber Duck

설명을 듣는 상대(고무 오리)에게 문제를 말하면 자기 혼자 답을 찾는다. 인지 편향(익숙함)을 강제로 풀게 함.

엔지니어 적용: 디버깅 지옥에서 동료에게 설명 시작 → "아 잠깐만" → 해결.

1.5 Inversion (뒤집기)

Charlie Munger: "항상 뒤집어라 (Invert, always invert)."

"어떻게 성공할까?" 대신 "어떻게 하면 반드시 실패할까?" 물으면 피할 함정이 보인다.

엔지니어 적용: 시스템 설계에서 "어떻게 하면 반드시 장애가 날까?" 리스트가 좋은 failure mode 분석.

2. 시스템 사고

2.1 Feedback Loop

Positive (강화): 출력이 입력을 증폭. 눈덩이. Negative (균형): 출력이 입력을 약화. 항상성.

엔지니어 적용:

• 캐시 invalidation: 잘못 설정 시 Positive loop → 시스템 폭주.
• Rate limiting: Negative loop로 안정.

2.2 Leverage Point

Donella Meadows "Leverage Points" — 시스템에 개입하는 12지점. 위로 갈수록 강력.

하위: 파라미터·물리 상수. 중위: 정보 흐름·규칙. 상위: 목표·패러다임·초월.

엔지니어 적용: "코드를 최적화"보다 "왜 이걸 만드는가" 재정의가 훨씬 큰 레버리지.

2.3 1차·2차·3차 효과

• 1차: 직접 결과.
• 2차: 그로 인한 반응.
• 3차: 반응의 반응.

Case: 가격 인상.

• 1차: 매출 증가.
• 2차: 일부 고객 이탈.
• 3차: 커뮤니티 불만 → 경쟁사 이동.

엔지니어 적용: 신기능 추가 시 1차 효과(쓴다)만 보지 말고 2차(코드 복잡도)·3차(다른 팀 의존) 체크.

2.4 Chesterton's Fence

"이 울타리가 왜 있는지 모른다면, 치우지 마라."

엔지니어 적용: 오래된 legacy 코드·설정. "왜 이게 있는지 모르겠네" = 아직 제거하면 안 됨.

2.5 Hyrum's Law

"사용자 수가 충분히 많으면, 당신의 API 모든 관찰 가능한 행동이 어딘가에선 의존된다."

엔지니어 적용: 미공개 동작 변경도 breaking change 될 수 있음. 문서화 없는 것도 계약.

2.6 Conway's Law

"시스템 아키텍처는 조직 커뮤니케이션 구조를 반영한다."

역 Conway: 원하는 아키텍처가 있다면 조직을 먼저 그 모양으로.

2.7 Goodhart's Law

"지표가 목표가 되면 더 이상 좋은 지표가 아니다."

엔지니어 적용: LoC·PR 수·test coverage를 KPI로 하면 게이밍. 본질을 측정할 방법 찾아야.

2.8 Gall's Law

"복잡하게 작동하는 시스템은 항상 단순하게 작동했던 시스템에서 진화했다."

엔지니어 적용: 처음부터 거대 아키텍처 설계 금지. 작게 시작해 진화.

2.9 Tragedy of the Commons

공유 자원이 각자 최적 행동으로 고갈됨.

엔지니어 적용: 공용 코드 리팩터 아무도 안 함. 팀 소유 명확화가 해법.

2.10 Emergence

단순한 규칙의 상호작용이 복잡한 행동을 낳음.

엔지니어 적용: 마이크로서비스 시스템의 예측 불가 행동. Chaos Engineering 필요.

3. 확률과 Bayes

3.1 Bayes Rule

P(H|E) = P(E|H) × P(H) / P(E)

사전 확률을 증거로 사후 확률로 업데이트.

엔지니어 적용:

• 프로덕션 장애: "DB 장애일 확률?" = DB 장애 사전 확률 × 관찰된 증상이 DB일 확률 / 증상의 전체 확률.
• 면접: 지원자의 통과 확률을 이력서·코딩·behavioral 결과로 업데이트.

3.2 Base Rate Neglect

• 사전 확률(base rate)을 무시하고 개별 증거에만 의존.
• 의학·스팸 분류에서 결정적 오류.

3.3 Bayesian Prior vs Frequentist

• Bayesian: 믿음을 확률로.
• Frequentist: 장기 빈도로.
• A/B 테스트에서 두 관점 비교 유용.

3.4 Black Swan (Nassim Taleb)

• 예측 불가·거대 영향·사후적 설명.
• 극단 사건을 무시하면 파산.

엔지니어 적용: 평균 latency 최적화만 하면 p99 꼬리가 폭발.

3.5 Power Law

• 상위 1%가 대부분 결과.
• 스타트업 성과·블로그 독자·버그 우선순위.

엔지니어 적용: 80/20 (Pareto) 법칙의 확장. 10%가 결과의 90% 낳음.

3.6 Survivorship Bias

• 살아남은 것만 보임.
• "CEO는 새벽 5시에 일어난다" → 실패자는 안 보임.

엔지니어 적용: 성공한 스타트업 이야기만 읽지 말고 실패 post-mortem도.

3.7 Regression to the Mean

• 극단은 평균으로 회귀.
• 한 달 최고 성과 엔지니어의 다음 달은 덜 좋을 확률 높음.

엔지니어 적용: 성과 평가에서 단기 극단 과잉 보상 금물.

3.8 Law of Large Numbers vs Small Numbers

• 표본이 작을수록 극단값 많음.
• 분기별 지표·설문은 noise 많음.

3.9 Variance vs Bias

• 모델 성능 평가의 고전적 트레이드오프.
• High variance: overfitting. High bias: underfitting.

엔지니어 적용: 시스템 설계도 마찬가지. 특정 상황 과적합 vs 일반 underserve.

4. 경제·의사결정

4.1 Opportunity Cost

• 하지 않은 것의 가치.
• "공짜"는 없다. 시간·주의·자본.

엔지니어 적용: 코드 A에 1주 쓰면 코드 B에 못 쓴다. 우선순위는 기회비용 게임.

4.2 Sunk Cost

• 이미 쓴 비용은 의사결정에 무관.
• "이미 3개월 투자했으니 계속" = 오류.

엔지니어 적용: 3개월 작업한 프로젝트 취소는 괴롭다. 하지만 남은 가치만 본다.

4.3 Kelly Criterion

최적 베팅 크기:

f = (bp - q) / b

• b: odds, p: 승률, q: 1-p.

엔지니어 적용: 스타트업 주식 비중·암호화폐 투자. 절대 "all in" 하지 말기.

4.4 Expected Value

EV = Σ (확률 × 결과)

• 무한 반복하는 상황에선 EV 최대화.
• 한 번 뿐이면 variance·ruin risk 고려.

4.5 Prospect Theory (Kahneman)

• 손실은 이득의 2배 고통.
• Loss aversion.

엔지니어 적용: 새 기술 도입 시 "잃을 것"이 "얻을 것"보다 과대평가. 정직한 비교 필요.

4.6 Anchoring

• 처음 본 숫자가 이후 판단의 기준.
• 협상 시 첫 제시가가 중요.

엔지니어 적용: 밸류에이션 협상·리쿠르팅 연봉 협상.

4.7 Diminishing Returns

• 투입 대비 산출이 점점 줄어듦.
• 마지막 10%가 가장 비쌈.

엔지니어 적용: 최적화·테스트 커버리지. 80%까지는 쉬움, 99%는 지옥.

4.8 Marginal vs Average

• 의사결정은 한계로.
• "1명 추가 엔지니어의 marginal productivity"가 의미.

4.9 Network Effect

• 사용자가 늘수록 가치가 기하급수.
• Metcalfe's Law: n² 가치.

엔지니어 적용: SNS·marketplace·API 플랫폼 설계.

4.10 Zero-Sum vs Positive-Sum

• 나누어 먹기 vs 파이 키우기.
• 대부분 장기 관계는 positive-sum.

5. Charlie Munger Lattice — 20 핵심 모델

Munger는 85개+ 모델을 언급했다. 가장 자주 인용되는 20개.

5.1 Circle of Competence

• 아는 것과 모르는 것의 경계 명확히.
• 경계 밖에서 의사결정하지 말기.

5.2 Margin of Safety

• Ben Graham. 투자·설계에서 안전 마진.
• 다리 하중 + 50% 여유.

5.3 Occam's Razor

• 경제·엔지니어링에서 가장 단순한 설명 먼저.

5.4 Hanlon's Razor

• "멍청함으로 설명될 것을 악의로 설명하지 말라."

5.5 Lollapalooza Effect

• 여러 편향·요인이 동시에 한 방향으로 작용 시 극단 결과.

5.6 Pavlovian Conditioning

• 반복 반응의 힘.
• UX·notification 설계.

5.7 Social Proof

• 남이 하면 나도.
• Tech stack 선택에 강력 (and 위험).

5.8 Reciprocity

• 호의에 답하는 본능.
• 네트워크·팀 문화.

5.9 Commitment and Consistency

• 공개 약속 후 일관되게 행동.
• OKR·공약의 원리.

5.10 Authority Bias

• 권위자의 의견을 과신.
• 기술 선택에서 "구글이 쓰니까" 함정.

5.11 Availability Heuristic

• 쉽게 떠오르는 예가 진실처럼 느껴짐.
• 최근 장애 = 앞으로 장애 많을 것 착각.

5.12 Confirmation Bias

• 자기 가설 확인만 찾음.
• PR·디자인 리뷰에서 체크.

5.13 Incentive-Caused Bias

• "결제 라인이 어딘지 보면 행동이 보인다."
• Cui bono (누구에게 이득?).

5.14 Deprival Super-Reaction

• 손실·박탈에 대한 비이성적 과잉 반응.
• 연봉·지분 축소에 대한 반응.

5.15 Contrast Effect

• 절대가 아닌 비교로 판단.
• 가격 책정의 decoy 효과.

5.16 Envy

• 내 절대 이득보다 상대적 비교.
• 팀 내 연봉 공개의 부작용.

5.17 Simple Physics Analogies

• Gravity (끌어당기는 힘)·Momentum·Tipping Point.

5.18 Critical Mass

• 임계점을 넘으면 자발 성장.
• SNS·오픈소스.

5.19 Breakpoints

• 연속이 아닌 단절.
• 상전이(phase transition).

5.20 Redundancy

• 백업·예비·중복.
• 엔지니어링·생명·조직 모두.

6. 인지 편향 20선

6.1 Planning Fallacy

• 계획은 항상 너무 낙관적.
• 엔지니어 추정 × 2~3이 현실.

6.2 Dunning-Kruger

• 초보는 과신, 전문가는 겸손.
• 시니어의 "잘 모르겠다"가 오히려 신호.

6.3 Hindsight Bias

• 결과 알고 나면 "나는 예상했다".

6.4 Outcome Bias

• 결과로 과정을 판단.
• 도박 이긴 사람이 좋은 결정 내린 건 아님.

6.5 Attribution Bias

• 내 성공은 실력, 실패는 환경.
• 남은 반대.

6.6 Bandwagon Effect

• 다수가 하면 옳다고 느낌.

6.7 Status Quo Bias

• 현재 유지 편향.
• Legacy 코드 못 바꾸는 이유 중 하나.

6.8 Recency Bias

• 최근 정보 과대평가.
• 장애 직후 over-engineering.

6.9 Endowment Effect

• 내가 가진 것의 가치 과대.
• 내가 짠 코드 편향.

6.10 IKEA Effect

• 내가 만든 것 과대평가.
• NIH (Not Invented Here) 증후군.

6.11 Halo Effect

• 한 특성으로 전체 판단.
• 학력·이력서·발표 잘하는 사람.

6.12 Curse of Knowledge

• 내가 알면 남도 알 거라 착각.
• 문서·강의·온보딩 실패 원인.

6.13 Self-Serving Bias

• 자기 이미지 유리하게 해석.

6.14 Barnum Effect

• 모호한 설명을 자신에게 정확하다 착각.
• MBTI 유행의 원인.

6.15 Gambler's Fallacy

• 독립 시행 결과가 과거에 영향 받는다 착각.

6.16 Ostrich Effect

• 나쁜 소식 외면.
• 장애 대시보드·알림 꺼두기.

6.17 Framing Effect

• 같은 정보도 제시 방식이 판단 바꿈.
• 90% 성공 vs 10% 실패.

6.18 Mere Exposure

• 반복 노출된 것 선호.
• Marketing·UX 고정관념.

6.19 Zeigarnik Effect

• 미완 작업이 기억에 남음.
• To-Do 많으면 인지 부하.

6.20 Spotlight Effect

• 내 실수를 남들이 다 본다 착각.
• 발표 떨림의 원인.

7. 스토아 철학 — 엔지니어를 위한 실용 철학

7.1 핵심 원칙

• Control vs No-control: 통제 가능한 것에만 집중.
• Memento Mori: 죽음을 기억하면 우선순위 명확.
• Amor Fati: 일어난 일을 사랑하라.

7.2 주요 철학자와 핵심 책

• Marcus Aurelius 『명상록』.
• Epictetus 『엥케이리디온』.
• Seneca 『인생이 왜 짧은가』.

현대: Ryan Holiday 『The Obstacle Is the Way』, William Irvine 『A Guide to the Good Life』.

7.3 엔지니어 적용

• Code review 비판 = 통제 불가한 타인 반응. 성장 기회로만.
• 프로덕션 장애 = amor fati로 받아들이고 해결.
• 승진 누락 = 내가 통제 못 한 부분, 다음 사이클 준비.

7.4 Premeditatio Malorum (부정적 시각화)

• 최악을 상상하면 현재 감사.
• Pre-mortem과 연결.

7.5 View from Above

• 우주적 관점에서 자기 문제 보기.
• "지금 중요한 이 이슈가 10년 후도 중요할까?"

8. Anti-fragile와 Via Negativa

8.1 Anti-fragile (Nassim Taleb)

• Fragile: 스트레스에 깨짐.
• Robust: 스트레스에 견딤.
• Anti-fragile: 스트레스에 강해짐.

엔지니어 적용:

• Chaos Engineering → 시스템이 실패 학습.
• 코드 리뷰로 실패하는 코드가 개선됨.

8.2 Via Negativa

• 하지 않을 것을 정의.
• 제거로 개선.

엔지니어 적용:

• 기능 제거가 가장 큰 UX 개선.
• "할 일 목록"이 아니라 "안 할 일 목록".

8.3 Optionality

• 선택지를 열어두는 가치.
• Barbell strategy: 안전 90% + 고위험 10%.

8.4 Skin in the Game

• 결과에 대한 책임.
• 아키텍트 결정을 on-call 해야 좋은 결정.

8.5 Lindy Effect

• 오래 살아남은 것일수록 앞으로도 오래.
• Python·Unix·SQL은 앞으로도 오래갈 것.

9. 일상에서 멘탈 모델 루틴화

9.1 Decision Journal

• 중요 결정 기록.
• 가정·근거·확률 쓰기.
• 6개월 후 리뷰.

9.2 Weekly Review

• 매주 한 결정·실수 기록.
• 어떤 bias가 작용했나.

9.3 Pre-mortem

• 프로젝트 시작 전 "실패한 미래에서" 이유 상상.
• Gary Klein 기법.

9.4 Red Team

• 자기 아이디어 반박 팀.
• PR 리뷰·RFC에서.

9.5 Checklist Manifesto (Atul Gawande)

• 반복 결정을 체크리스트로.
• 장애 대응·배포·인터뷰에.

9.6 Second Brain

• 읽은 책·논문의 핵심을 Obsidian·Logseq·Notion.
• 태그·링크로 격자 구축.

10. 엔지니어링 고유 멘탈 모델 Bonus

10.1 YAGNI

"You Aren't Gonna Need It."

10.2 KISS

"Keep It Simple, Stupid."

10.3 Premature Optimization

"Premature optimization is the root of all evil." (Knuth)

10.4 DRY vs WET

"Don't Repeat Yourself" vs "Write Everything Twice" (전자만 맹신 금물).

10.5 Last Responsible Moment

결정을 미룰 수 있는 마지막 순간까지 미루기. Lean.

10.6 Two-Pizza Team

Amazon의 팀 크기 규칙 (피자 2판으로 식사).

10.7 Fallacies of Distributed Computing

• 네트워크는 안정적이다 (거짓).
• Latency는 0이다 (거짓).
• ...8가지 false assumptions.

10.8 CAP Theorem

Consistency·Availability·Partition tolerance — 3개 중 2개.

10.9 RAS (Reliability, Availability, Serviceability)

• Hardware 설계 원칙이 소프트웨어에도.

10.10 End-to-End Principle

네트워크 설계: 지능은 endpoint에. 중간은 단순.

체크리스트

자주 보는 안티패턴 10가지

1. 한 모델 과잉 적용: "모두 First principles로 풀자" → 시간 낭비.
2. 모델 수집만 하고 안 쓰기.
3. 사후 편향: 실패 후에야 "그럴 줄 알았다".
4. Overconfidence: 자기 영역 밖에서 판단.
5. Base rate 무시.
6. 감정 결정 후 합리화.
7. 최근 경험 과대평가.
8. Opportunity cost 무시: "공짜 시간"의 환상.
9. 단기 최적화로 장기 손해.
10. "멘탈 모델은 이론"이라며 실전 무시.

추천 리소스

• Charlie Munger — 『Poor Charlie's Almanack』.
• Daniel Kahneman — 『Thinking, Fast and Slow』.
• Nassim Taleb — 『Fooled by Randomness』, 『Black Swan』, 『Antifragile』, 『Skin in the Game』.
• Morgan Housel — 『돈의 심리학』, 『Same As Ever』.
• Shane Parrish — Farnam Street 블로그·『The Great Mental Models』 시리즈.
• Ray Dalio — 『Principles』.
• Donella Meadows — 『Thinking in Systems』.
• Richard Feynman — 『Surely You're Joking Mr. Feynman』.
• Marcus Aurelius — 『명상록』.

다음 글 예고 — “엔지니어를 위한 의사소통 완전 가이드: 1:1·피드백·협상·갈등 해결·프레젠테이션·Active Listening·Nonviolent Communication까지”

멘탈 모델을 가져도 사람과의 소통에서 무너지면 소용없다.

• 1:1 미팅의 과학
• 피드백을 주고받는 기술
• 협상 — Never Split the Difference·Getting to Yes
• 갈등 해결 — Crucial Conversations
• 프레젠테이션·스토리텔링
• Active Listening
• Nonviolent Communication (NVC)
• 리모트·비동기 커뮤니케이션
• 한국 문화 맥락의 커뮤니케이션

결국 모든 것은 사람의 문제다. 다음 글에서 이어진다.