feat: Wiki 지식 자산 업데이트 - UX Scenarios, Frontend, Game Design, Topics 추가 [2026-05-08]

10_Wiki/Topics/AI_and_ML/Exhaustiveness-Checking.md

@@ -1,20 +1,33 @@
 ---
-category: Unified
+id: wiki-2026-0508-exhaustiveness-checking
+title: Exhaustiveness Checking
+category: 10_Wiki/Topics
+status: needs_review
+canonical_id: self
+aliases: []
+duplicate_of: none
+source_trust_level: A
+confidence_score: 0.92
 tags: [auto-consolidated, technical-documentation]
-title: [[Exhaustiveness-Checking|Exhaustiveness-Checking]] (망라성 검사)
-last_updated: 2026-05-02
+raw_sources: []
+last_reinforced: 2026-05-08
+github_commit: pending
+inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
+tech_stack:
+  language: unspecified
+  framework: unspecified
 ---
 
 # [[Exhaustiveness-Checking|Exhaustiveness-Checking]] (망라성 검사)
 
-## 📌 Brief Summary
+## 📌 한 줄 통찰 (The Karpathy Summary)
 > "빠진 케이스가 없는지 컴파일러가 대신 체크하는 완벽주의자의 도구." 모든 가능한 타입 시나리오를 처리했음을 논리적으로 보장하여, 나중에 새로운 타입이 추가되었을 때 발생할 수 있는 런타임 에러를 원천 봉쇄하는 기법이다.
 
 ---
 
 > 완전성 검사(Exhaustiveness Checking)는 타입 시스템 내에서 특정 유니온 타입의 모든 가능한 케이스(변형)가 코드상에서 빠짐없이 처리되었는지를 컴파일 시점에 검증하는 기법입니다[1-3]. 식별 가능한 유니온([[Discriminated Unions|Discriminated Unions]])과 함께 결합하여 주로 사용되며, 새로운 상태가 추가되었을 때 이를 처리하지 않은 분기문이 존재하면 즉시 컴파일 에러를 발생시킵니다[2, 3]. 이를 통해 개발자는 런타임 버그를 사전에 예방하고 잘못된 상태가 시스템을 통과하는 것을 원천적으로 차단할 수 있습니다[4, 5].
 
-## 📖 Core Content
+## 📖 구조화된 지식 (Synthesized Content)
 - **The Never Trick**:
     - 타입스크립트의 `never` 타입을 활용한다. 모든 조건문(if/switch)이 끝난 뒤 `default` 케이스에 `const _check: never = remainValue;`를 할당한다.
 - **How it works**:
@@ -29,7 +42,7 @@ last_updated: 2026-05-02
 - **`strictNullChecks`를 활용한 반환 타입 검사:** 또 다른 방법으로는 TypeScript의 `strictNullChecks` 기능을 켜고 함수에 명시적인 반환 타입을 지정하는 방식이 있습니다[6]. 모든 케이스를 철저히 처리하지 않은 분기문은 암묵적으로 `undefined`를 반환할 가능성을 내포하게 되므로, 반환 타입 규칙 위반으로 에러를 발생시켜 완전성을 강제할 수 있습니다[6].
 - **다양한 환경에서의 활용 패턴:** TypeScript의 기본 제어 구조뿐만 아니라, `ts-pattern`과 같은 패턴 매칭 라이브러리에서도 `.exhaustive()` 문법을 활용하여 처리되지 않은 케이스를 타입스크립트 컴파일러가 감지하도록 돕습니다[8]. 또한 C#과 같은 다른 언어 환경에서도, 결과를 철저히 소진(exhausting)하지 않으면 컴파일이 되지 않게 구조화하여 오류를 안전하게 처리하는 동일한 목적의 설계 방식이 사용됩니다[9].
 
-## ⚖️ Trade-offs & Caveats
+## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
 - 망라성 검사는 '닫힌 시스템(Closed[[_system|system]])'에서는 완벽하지만, 외부 라이브러리에서 동적으로 확장되는 타입에 대해서는 무력할 수 있다. 이때는 `assertNever`와 같은 헬퍼 함수를 사용하여 런타임 에러를 명시적으로 던지도록 설계해야 한다.
 
 ---
@@ -37,7 +50,7 @@ last_updated: 2026-05-02
 - **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
 - **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
 
-## 🔗 Knowledge Connections
+## 🔗 지식 연결 (Graph)
 - Related: [[Discriminated-Unions|Discriminated-Unions]] , Type-Soundness
 - Tool: TypeScript Compiler (tsc)
 
@@ -51,3 +64,52 @@ last_updated: 2026-05-02
 *Last updated: 2026-04-18*
 
 ---
+
+## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
+
+**언제 이 지식을 쓰는가:**
+- *(TODO)*
+
+**언제 쓰면 안 되는가:**
+- *(TODO)*
+
+## 🧪 검증 상태 (Validation)
+
+- **정보 상태:** needs_review
+- **출처 신뢰도:** A
+- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
+
+## 🧬 중복 검사 (Duplicate Check)
+
+- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
+- **처리 방식:** UPDATE (자동 정규화)
+- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
+
+## 🕓 변경 이력 (Changelog)
+
+| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
+|------|-----------|-----------|--------|
+| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
+
+## 💻 코드 패턴 (Code Patterns)
+
+**패턴 1:** *(TODO: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*
+
+```text
+# TODO
+```
+
+## 🤔 의사결정 기준 (Decision Criteria)
+
+**선택 A를 써야 할 때:**
+- *(TODO)*
+
+**선택 B를 써야 할 때:**
+- *(TODO)*
+
+**기본값:**
+> *(TODO)*
+
+## ❌ 안티패턴 (Anti-Patterns)
+
+- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*