2nd/10_Wiki/Topics/Thinking & Reasoning/Sunk Cost Fallacy.md

---
id: sunk-cost-fallacy
title: "Sunk Cost Fallacy"
category: "10_Wiki/Topics"
status: "draft"
verification_status: "conceptual"
canonical_id: ""
aliases: ["매몰 비용 오류", "Escalation of Commitment"]
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", "hypothesis-driven thinking", "cognitive-bias"]
raw_sources: ["NotebookLM Synthesis"]
applied_in: []
github_commit: ""
---

# [[Sunk Cost Fallacy]]

## 🎯 한 줄 통찰 (One-line insight)
과거에 투입한 시간, 금전, 자원이 더 이상 유용하지 않음에도 불구하고, 단지 '이미 투자했다'는 이유만으로 비합리적인 투자를 지속하려는 심리적 성향 [1].

## 🧠 핵심 개념 (Core concepts)
- **투자 지속성 (Continued Investment):** 자산의 현재 가치나 미래 수익성보다 과거의 누적 투자액에 근거하여 의사결정을 내림 [1].
- **약속의 에스컬레이션 (Escalation of Commitment):** 실패하고 있는 프로젝트임에도 불구하고 초기 결정을 정당화하기 위해 추가 자원을 투입하는 현상 [2, 3].
- **확인 편향과의 결합 (Link to Confirmation Bias):** 경영진이 상황을 객관적으로 재평가하기보다 초기 결정을 지지하는 증거만을 선택적으로 수집하며 발생함 [2].
- **중단 시점의 부재 (Lack of Exit Strategy):** "언제 멈춰야 하는가?"라는 질문에 답할 수 있는 객관적 데이터나 기준이 부족할 때 강화됨 [4].

## 🧩 추출된 패턴 (Extracted patterns)
- **사후적 합리화 (Post-hoc Rationalization):** 예상보다 낮은 성과(예: 8% 채택률)가 나왔음에도 불구하고, 특정 소수 사용자의 만족도 등을 근거로 프로젝트를 유지하려는 경향 [5, 6].
- **임계값 설정 (Threshold Setting):** 실험 시작 전 성공과 실패를 가르는 명확한 수치적 기준(Success Threshold)이 없을 때 매몰 비용 오류에 빠지기 쉬움 [3, 6, 7].
- **비합리적 정당화:** 유용성이 상실되었음에도 투자를 지속하는 것을 '책임감'이나 '의지'로 오인함 [1, 3].

## 📖 세부 내용 (Details)
- **가설 주도 사고와의 충돌:** 가설 주도 사고는 '실패를 통한 학습'과 '빠른 포기(Fail Fast)'를 강조하지만, 매몰 비용 오류는 실패를 인정하지 않고 자원을 낭비하게 함으로써 전략적 효율성을 저해함 [8, 9].
- **전략적 가드레일:** 매몰 비용 오류를 방지하기 위해 가설 수립 단계에서 반드시 "언제 이 가설을 폐기할 것인가?"와 "어떤 데이터가 충분한 정보인가?"에 대한 기준을 정의해야 함 [4].
- **실패의 가치 재인식:** 비합리적인 지속보다는 실패한 실험을 통해 얻은 '문제에 대한 이해'와 '데이터 기반의 통찰'을 가치 있는 결과물로 간주하는 문화가 필요함 [9, 10].
- **구조적 방어 기제:** 프로젝트나 실험을 실행하기 전, 예상 결과에 따른 의사결정 경로(성공 시 build, 모호할 시 iterate, 실패 시 kill)를 미리 문서화하여 감정적 개입을 차단함 [3, 11, 12].

## ⚖️ 모순 및 업데이트 (Contradictions & updates)
- 소스 데이터 내에서 매몰 비용 오류와 직접적으로 상충되는 정보는 발견되지 않았으나, **[[Evidence-First Problem Solving]]** 모델은 가설에 의한 '고착(Anchoring)' 자체를 경계하며 데이터 수집과 해석을 완전히 분리할 것을 제안함 [13]. 이는 가설 설정 자체가 매몰 비용이나 약속의 에스컬레이션을 유도할 위험이 있음을 시사함 [14].

## 🛠️ 적용 사례 (Applied in summary)
- **B2B SaaS 기능 개발 사례:** 사용자 요청에 따라 '대량 편집(Bulk Editing)' 기능을 개발했으나 실제 채택률이 8%에 그침. 팀은 사전에 해당 기능이 실제 워크플로우 문제를 해결할 것이라는 가설을 검증하지 않았으며, 결과적으로 개발 자원과 기회비용을 낭비함 [5].
- **프로덕트 가설 검증 프로세스:** Centercode 가이드에 따르면, 기능 출시 전 'Strong Success(40% 사용)', 'Moderate Success(25-39%)', 'Failure(<15%)' 등의 임계값을 미리 설정하여 매몰 비용에 의한 비합리적 유지를 방지함 [11].

## ✅ 검증 상태 및 신뢰도
- **상태:** draft
- **검증 단계:** conceptual (실제 기업의 편향 완화 전략으로 제안됨 [3])
- **출처 신뢰도:** B (학술적 리뷰 및 전문 컨설팅 방법론 기반)
- **중복 검사 결과:** 신규 생성

## 🔗 관련 문서 링크 (Related document links)

### 상위/유사 개념

#### [의사결정 저해 요인 (Cognitive Biases)]
- [[Confirmation Bias]]
  - 연결 이유: 매몰 비용을 정당화하기 위해 유리한 정보만 수집하는 심리적 기제 [2, 3].
- [[Anchoring Bias]]
  - 연결 이유: 초기 투자 결정이나 초기 정보에 지나치게 집착하게 만듦 [3].

#### [전략적 대응 방법론 (Methodologies)]
- [[Hypothesis-Driven Thinking]]
  - 연결 이유: 명확한 가설과 검증 기준을 통해 매몰 비용 오류를 사전에 차단하는 프레임워크 [3, 15].
- [[Success Thresholds]]
  - 연결 이유: 매몰 비용 오류를 극복하기 위한 가장 구체적인 실행 도구 [3, 11].

### 심층 후속 질문 (Deeper Research Questions)
- 매몰 비용 오류가 확인 편향과 결합될 때, 조직 내에서 이를 감지할 수 있는 객관적 신호(Red Flags)는 무엇인가?
- 가설 주도 모델에서 '학습된 실패'를 성과로 인정하는 보상 체계는 어떻게 설계되어야 하는가?
- '약속의 에스컬레이션'을 방지하기 위해 외부 전문가(예: Red Team)가 가설 검증 단계에 개입하는 모델의 효과는 어떠한가?
- 데이터가 부족한 'Unknown Unknowns' 영역에서 매몰 비용과 전략적 인내(Strategic Patience)를 어떻게 구분할 것인가?

### 실무 적용 맥락 (Practical Application Contexts)
- **Implementation:** 실험 로그(Hypothesis Log)에 중단 기준을 명시함 [16].
- **System Design:** 기능 플래그(Feature Flags)를 활용하여 소수 사용자에게만 노출하고, 임계값 미달 시 즉시 롤백함 [17].
- **Learning Path:** 인지 편향 교육 시 사례 연구와 게임 기반 훈련을 결합하여 체득함 [18].

### 인접 주변 주제 (Adjacent Topics)
- [[Groupthink]]
  - 확장 방향: 조직 전체가 매몰 비용 오류에 빠지는 집단적 역학 조사 [1].

## 📝 변경 이력 (Change history)
- 2026-05-24: Initial draft generated via Datacollector_MAC P-Reinforce engine.