34 lines
3.7 KiB
Markdown
34 lines
3.7 KiB
Markdown
---
|
|
id: P-REINFORCE-AUTO-98C2AC
|
|
category: "[[10_Wiki/💡 Topics/Programming & Language]]"
|
|
confidence_score: 0.90
|
|
tags: [auto-reinforced]
|
|
last_reinforced: 2026-04-20
|
|
github_commit: "[P-Reinforce] Continuous Worker - 완전성 검사 (Exhaustiveness Checking)"
|
|
---
|
|
|
|
# [[완전성 검사 (Exhaustiveness Checking)]]
|
|
|
|
## 📌 한 줄 통찰 (The Karpathy Summary)
|
|
> 지식 요약 정보 추출 중...
|
|
|
|
## 📖 구조화된 지식 (Synthesized Content)
|
|
- **개념 및 필요성:** 완전성 검사는 시스템이 확장되거나 타입이 변경될 때 발생하는 부작용을 원천 차단하는 방어 기제입니다 [3]. 예를 들어, 특정 유니온 타입에 새로운 형태(예: 새로운 도형 타입, 네트워크 상태, API 응답 등)가 추가되었을 때, 기존의 분기문(`switch` 등)에서 이를 다루지 않으면 컴파일 타임 에러를 발생시켜 누락 사실을 즉각적으로 알려줍니다 [1, 2, 4].
|
|
- **`never` 타입을 활용한 검증 기법:** 가장 강력하고 명시적인 완전성 검사 방법은 타입스크립트의 `never` 타입을 활용하는 것입니다. 분기문에서 유니온의 모든 가능한 케이스를 처리한 후, 남은 값을 `default` 블록이나 `assertNever`와 같은 검증 함수로 전달하여 `never` 타입에 할당하도록 작성합니다 [3, 5]. 만약 개발자가 처리하지 않은 케이스가 남아있다면, 해당 변수는 `never`가 아닌 실제 할당 가능한 타입을 가지게 되므로 "Type 'X' is not assignable to type 'never'"와 같은 컴파일 에러를 즉시 발생시킵니다 [2, 3, 5].
|
|
- **반환 타입 지정을 통한 검증:** `strictNullChecks` 옵션을 활성화하고 함수의 반환 타입을 명시적으로 지정하는 방법도 있습니다 [6]. 모든 `switch` 케이스를 처리하지 않고 빠져나오는 경로가 생긴다면, 컴파일러는 해당 함수가 `undefined`를 반환할 수 있다고 인지하여 명시된 반환 타입과의 불일치 에러를 보고합니다 [6].
|
|
- **라이브러리 및 고급 문법 활용 (`ts-pattern`, `satisfies`):** `ts-pattern`과 같은 패턴 매칭 라이브러리가 제공하는 `.exhaustive()` 메서드를 사용하면, 처리되지 않은 모든 경우를 타입스크립트 컴파일러가 감지하고 강제하도록 구현할 수 있습니다 [7, 8]. 또한, 분기문의 마지막에 `satisfies never` 키워드를 사용하여 처리되지 않은 다른 케이스가 없음을 보장할 수 있습니다 [9]. 이러한 패턴들은 '불가능한 상태'를 코드상에서 표현하지 못하게 만듭니다 [3].
|
|
|
|
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
|
- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
|
|
- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
|
|
|
|
## 🔗 지식 연결 (Graph)
|
|
- **Related Topics:** [[식별 가능한 유니온 (Discriminated Unions)]], [[never 타입]], [[ts-pattern]], [[satisfies 연산자]]
|
|
- **Projects/Contexts:** [[타입스크립트 상태 관리 및 분기 처리 설계]]
|
|
- **Contradictions/Notes:** 소스에서는 완전성 검사의 효과를 긍정적으로 평가하지만, `ts-pattern` 라이브러리의 `.exhaustive()` 등을 활용한 고도의 추상화는 기본 제어 구조(`if/else`, `switch`)보다 성능이 현저히 떨어지고 오버엔지니어링이 될 수 있음을 경계합니다. 따라서 단순한 조건의 경우, 기존 방식과 `satisfies never` 등을 조합하여 가독성을 높이고 안전하게 분기를 처리하는 것이 더 나을 수 있다고 조언합니다 [7-10].
|
|
|
|
---
|
|
*Last updated: 2026-04-18*
|
|
- Raw Source: [[00_Raw/2026-04-20/완전성 검사 (Exhaustiveness Checking).md]]
|
|
---
|