2nd/10_Wiki/Topics/Thinking & Reasoning/Sunk Cost Fallacy.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
sunk-cost-fallacy	Sunk Cost Fallacy	10_Wiki/Topics	draft	conceptual		매몰 비용 오류 Escalation of Commitment		B	0.85	2026-05-24	2026-05-24			research hypothesis-driven thinking cognitive-bias	NotebookLM Synthesis

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.