---
category: Unified
tags: [auto-consolidated, technical-documentation]
title: [[Exhaustiveness-Checking|Exhaustiveness-Checking]] (망라성 검사)
last_updated: 2026-05-02
---

# [[Exhaustiveness-Checking|Exhaustiveness-Checking]] (망라성 검사)

## 📌 Brief Summary
> "빠진 케이스가 없는지 컴파일러가 대신 체크하는 완벽주의자의 도구." 모든 가능한 타입 시나리오를 처리했음을 논리적으로 보장하여, 나중에 새로운 타입이 추가되었을 때 발생할 수 있는 런타임 에러를 원천 봉쇄하는 기법이다.

---

> 완전성 검사(Exhaustiveness Checking)는 타입 시스템 내에서 특정 유니온 타입의 모든 가능한 케이스(변형)가 코드상에서 빠짐없이 처리되었는지를 컴파일 시점에 검증하는 기법입니다[1-3]. 식별 가능한 유니온([[Discriminated Unions|Discriminated Unions]])과 함께 결합하여 주로 사용되며, 새로운 상태가 추가되었을 때 이를 처리하지 않은 분기문이 존재하면 즉시 컴파일 에러를 발생시킵니다[2, 3]. 이를 통해 개발자는 런타임 버그를 사전에 예방하고 잘못된 상태가 시스템을 통과하는 것을 원천적으로 차단할 수 있습니다[4, 5].

## 📖 Core Content
- **The Never Trick**:
    - 타입스크립트의 `never` 타입을 활용한다. 모든 조건문(if/switch)이 끝난 뒤 `default` 케이스에 `const _check: never = remainValue;`를 할당한다.
- **How it works**:
    - 만약 처리하지 않은 타입이 남아 있다면, 그 값은 `never` 타입에 할당될 수 없으므로 컴파일 에러가 발생한다.
- **Value**:
    - 코드 유지보수 시 강력한 안전장치가 된다. 예를 들어 `UserRole`에 'Guest'가 새로 추가되면, 이를 처리하지 않은 모든 스위치 문에서 즉시 빨간 줄이 그어진다.

---

- **기본 작동 원리:** 완전성 검사는 데이터의 모든 가능한 형태가 `switch` 문 등의 분기 구조에서 명시적으로 다루어졌는지 확인합니다[1, 2]. 특정 유니온 타입에 새로운 형태(Shape)나 상태를 추가했지만, 이를 제어문에서 처리하는 코드를 작성하는 것을 잊었다면, 컴파일러는 누락된 부분에 대해 에러를 던집니다[2, 3]. 이는 런타임에 발생할 수 있는 잠재적 결함을 컴파일 시점의 에러로 전환해 줍니다[3-5].
- **`never` 타입을 활용한 검사 기법:** TypeScript에서 완전성 검사를 구현하는 가장 확실한 방법 중 하나는 `never` 타입을 사용하는 것입니다[3, 6, 7]. 모든 유효한 케이스를 걸러낸 후 남은 값을 `never` 타입(예: `assertNever` 함수 등)으로 할당하도록 작성합니다[7]. 만약 개발자가 실수로 특정 케이스를 누락했다면, 남은 값은 `never`가 아닌 실제 타입(누락된 타입)을 가지게 되어 컴파일 에러가 발생하며, 에러 메시지를 통해 어떤 타입이 누락되었는지 명확히 알 수 있습니다[3, 7].
- **`strictNullChecks`를 활용한 반환 타입 검사:** 또 다른 방법으로는 TypeScript의 `strictNullChecks` 기능을 켜고 함수에 명시적인 반환 타입을 지정하는 방식이 있습니다[6]. 모든 케이스를 철저히 처리하지 않은 분기문은 암묵적으로 `undefined`를 반환할 가능성을 내포하게 되므로, 반환 타입 규칙 위반으로 에러를 발생시켜 완전성을 강제할 수 있습니다[6].
- **다양한 환경에서의 활용 패턴:** TypeScript의 기본 제어 구조뿐만 아니라, `ts-pattern`과 같은 패턴 매칭 라이브러리에서도 `.exhaustive()` 문법을 활용하여 처리되지 않은 케이스를 타입스크립트 컴파일러가 감지하도록 돕습니다[8]. 또한 C#과 같은 다른 언어 환경에서도, 결과를 철저히 소진(exhausting)하지 않으면 컴파일이 되지 않게 구조화하여 오류를 안전하게 처리하는 동일한 목적의 설계 방식이 사용됩니다[9].

## ⚖️ Trade-offs & Caveats
- 망라성 검사는 '닫힌 시스템(Closed[[_system|system]])'에서는 완벽하지만, 외부 라이브러리에서 동적으로 확장되는 타입에 대해서는 무력할 수 있다. 이때는 `assertNever`와 같은 헬퍼 함수를 사용하여 런타임 에러를 명시적으로 던지도록 설계해야 한다.

---

- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.

## 🔗 Knowledge Connections
- Related: [[Discriminated-Unions|Discriminated-Unions]] , Type-Soundness
- Tool: TypeScript Compiler (tsc)

---

- **Related Topics:** 식별 가능한 유니온(Discriminated Unions), [[never 타입|never 타입]], [[타입 좁히기 (Type Narrowing)|타입 좁히기(Type Narrowing]]
- **Projects/Contexts:** TypeScript 컴파일러의 정적 타입 시스템, 패턴 매칭 라이브러리(ts-pattern 등)
- **Contradictions/Notes:** TypeScript에서 `strictNullChecks`를 활용한 반환 타입 검사 방식은 구형 코드베이스에서 항상 원활하게 작동하지 않을 수 있으며 다소 미묘한 방식인 반면, `never` 타입을 활용한 검사 방식은 오류 메시지에 누락된 타입 이름이 포함되어 더 명확하게 문제를 파악할 수 있다는 장점이 있습니다[6, 7].

---
*Last updated: 2026-04-18*

---
