The Never Type: Shifting from Runtime Errors to Compile-Time Guarantees

소프트웨어 개발 세계에서 우리는 버그를 예방하고, 찾고, 수정하는 데 상당한 시간과 노력을 쏟습니다. 가장 위험한 버그 중 일부는 조용히 나타나는 버그입니다. 애플리케이션을 즉시 충돌시키지 않고 처리되지 않은 엣지 케이스에 숨어 특정 데이터 조각이나 사용자 작업이 잘못된 동작을 트리거하기를 기다립니다. 이러한 버그의 일반적인 원인은 간단한 간과입니다. 개발자가 선택 사항 세트에 새 옵션을 추가했지만 해당 옵션을 처리해야 하는 코드의 모든 위치를 업데이트하는 것을 잊어버리는 것입니다.

`switch` 문이 여러 유형의 사용자 알림을 처리한다고 가정해 보겠습니다. 새 알림 유형(예: 'POLL_RESULT')이 추가될 때 알림 렌더링 함수에서 해당 `case` 블록을 추가하는 것을 잊어버리면 어떻게 될까요? 많은 언어에서 코드는 단순히 실패하고 아무 것도 하지 않고 조용히 실패합니다. 사용자는 여론 조사 결과를 보지 못하고 몇 주 동안 버그를 발견하지 못할 수 있습니다.

컴파일러가 이를 방지할 수 있다면 어떻게 될까요? 우리 자신의 도구가 모든 가능성을 처리하도록 강제하여 잠재적인 런타임 논리 오류를 컴파일 타임 유형 오류로 바꿀 수 있다면 어떻게 될까요? 이것이 바로 최신 정적 타입 언어에서 발견되는 개념인 'never' 타입이 제공하는 힘입니다. 이는 모든 케이스가 처리되도록 강력한 컴파일 타임 보증을 제공하는 완전한 검사를 시행하는 메커니즘입니다. 이 기사에서는 `never` 타입을 살펴보고, 전통적인 오류 처리와의 역할을 비교하고, 이를 사용하여 보다 탄력적이고 유지 관리가 용이한 소프트웨어 시스템을 구축하는 방법을 보여줍니다.

What Exactly is the 'Never' Type?

언뜻 보기에 `never` 타입은 난해하거나 순전히 학문적으로 보일 수 있습니다. 그러나 실제적인 의미는 심오합니다. 이를 이해하려면 두 가지 주요 특성을 파악해야 합니다.

A Type for the Impossible

`never` 타입은 절대 발생할 수 없는 값을 나타냅니다. 가능한 값이 없는 타입입니다. 이것은 추상적으로 들리지만 다음과 같은 두 가지 주요 시나리오를 나타내는 데 사용됩니다.

1. 절대 반환하지 않는 함수: 이것은 아무 것도 반환하지 않는 함수(그것은 `void`입니다)를 의미하지 않습니다. 끝점에 도달하지 않는 함수를 의미합니다. 오류를 발생시키거나 무한 루프에 들어갈 수 있습니다. 중요한 것은 정상적인 실행 흐름이 영구적으로 중단된다는 것입니다.
2. 불가능한 상태의 변수: 논리적 추론(타입 좁히기라고 함)을 통해 컴파일러는 변수가 특정 코드 블록 내에서 값을 가질 수 없다고 판단할 수 있습니다. 이 상황에서 변수의 타입은 사실상 `never`입니다.

타입 이론에서 `never`는 바닥 타입(종종 ⊥로 표시됨)으로 알려져 있습니다. 바닥 타입이라는 것은 다른 모든 타입의 하위 타입임을 의미합니다. 이것은 이치에 맞습니다. `never` 타입의 값은 존재할 수 없으므로 타입 안전성을 위반하지 않고 `string`, `number` 또는 `User` 타입의 변수에 할당할 수 있습니다. 왜냐하면 해당 코드 줄은 증명 가능하게 도달할 수 없기 때문입니다.

Crucial Distinction: `never` vs. `void`

일반적인 혼란의 지점은 `never`와 `void`의 차이점입니다. 그 차이는 매우 중요합니다.

• void: 사용 가능한 반환 값이 없음을 나타냅니다. 함수는 완료될 때까지 실행되고 반환되지만 반환 값은 사용되지 않습니다. 콘솔에 기록하는 함수를 생각해 보십시오.
• never: 반환의 불가능성을 나타냅니다. 함수는 정상적으로 실행 경로를 완료하지 않음을 보장합니다.

TypeScript 예제를 살펴 보겠습니다.

            // This function returns 'void'. It completes successfully.
function logMessage(message: string): void {
  console.log(message);
  // Implicitly returns 'undefined'
}

// This function returns 'never'. It never completes.
function throwError(message: string): never {
  throw new Error(message);
}

// This function also returns 'never' due to an infinite loop.
function processTasks(): never {
  while (true) {
    // ... process a task from a queue
  }
}
            

              
                Copy
              
            
          

이 차이점을 이해하는 것이 `never`의 실제 힘을 여는 첫 번째 단계입니다.

The Core Use Case: Exhaustive Checking

`never` 타입의 가장 영향력있는 애플리케이션은 컴파일 타임에 완전한 검사를 시행하는 것입니다. 이를 통해 주어진 데이터 타입의 모든 변형을 처리했는지 확인하는 안전망을 구축 할 수 있습니다.

The Problem: The Fragile `switch` Statement

판별된 유니온을 사용하여 기하학적 도형 세트를 모델링해 보겠습니다. 이는 다루는 타입의 변형을 알려주는 공통 속성( 'discriminant', 예를 들어 `kind`)을 가진 강력한 패턴입니다.

            type Shape =
  | { kind: 'circle'; radius: number }
  | { kind: 'square'; sideLength: number };

function getArea(shape: Shape): number {
  switch (shape.kind) {
    case 'circle':
      return Math.PI * shape.radius ** 2;
    case 'square':
      return shape.sideLength ** 2;
  }
  // What happens if we get a shape we don't recognize?
  // This function would implicitly return 'undefined', a likely bug!
}
            

              
                Copy
              
            
          

이 코드는 현재 작동합니다. 하지만 애플리케이션이 진화하면 어떻게 될까요? 동료가 새로운 도형을 추가합니다.

            type Shape =
  | { kind: 'circle'; radius: number }
  | { kind: 'square'; sideLength: number }
  | { kind: 'rectangle'; width: number; height: number }; // New shape added!
            

              
                Copy
              
            
          

`getArea` 함수는 이제 불완전합니다. `rectangle`을 받으면 `switch` 문에 일치하는 케이스가 없고 함수가 완료되며 JavaScript/TypeScript에서 `undefined`가 반환됩니다. 호출 코드는 `number`를 예상했지만 `undefined`를 가져와 `NaN` 오류 또는 다른 미묘한 버그가 발생합니다. 컴파일러는 경고를 보내지 않았습니다.

The Solution: The `never` Type as a Safeguard

`switch` 문의 `default` 케이스에서 `never` 타입을 사용하여 이 문제를 해결할 수 있습니다. 이 간단한 추가는 컴파일러를 우리의 경계하는 파트너로 변환시킵니다.

            function getAreaWithExhaustiveCheck(shape: Shape): number {
  switch (shape.kind) {
    case 'circle':
      return Math.PI * shape.radius ** 2;

    case 'square':
      return shape.sideLength ** 2;

    // What about 'rectangle'? We forgot it.

    default:
      // This is where the magic happens.
      const _exhaustiveCheck: never = shape;
      // The line above will now cause a compile-time error!
      // Type 'Rectangle' is not assignable to type 'never'.
      return _exhaustiveCheck;
  }
}
            

              
                Copy
              
            
          

이것이 작동하는 이유를 분석해 보겠습니다.

1. 타입 좁히기: 각 `case` 블록 내부에서 TypeScript 컴파일러는 `shape` 변수의 타입을 좁힐만큼 똑똑합니다. `case 'circle'`에서 컴파일러는 `shape`가 `{ kind: 'circle'; radius: number }`임을 알고 있습니다.
2. `default` 블록: 코드가 `default` 블록에 도달하면 컴파일러는 `shape`가 가질 수있는 타입을 추론합니다. 원래 `Shape` 유니온에서 처리된 모든 케이스를 뺍니다.
3. 오류 시나리오: 업데이트 된 예에서 우리는 `'circle'`과 `'square'`를 처리했습니다. 따라서 `default` 블록 내부에서 컴파일러는 `shape`가 `{ kind: 'rectangle'; ... }` 여야 함을 알고 있습니다. 그런 다음 코드는 이 `rectangle` 객체를 `_exhaustiveCheck` 변수에 할당하려고 시도합니다. 이 변수는 `never` 타입을 가지고 있습니다. 이 할당은 명확한 타입 오류로 실패합니다. `Type 'Rectangle' is not assignable to type 'never'`. 코드가 실행되기 전에 버그가 잡힙니다!
4. 성공 시나리오: `'rectangle'`에 대한 `case`를 추가하면 `default` 블록에서 컴파일러는 모든 가능성을 소모합니다. `shape`의 타입은 `never`로 좁혀집니다 (원, 사각형 또는 직사각형 일 수 없으므로 불가능한 타입입니다). `never` 타입의 값을 `never` 타입의 변수에 할당하는 것은 완벽하게 유효합니다. 코드는 오류없이 컴파일됩니다.

이 패턴은 종종 "exhaustiveness trick"이라고 불리며 컴파일러가 완전성을 시행하도록 효과적으로 위임합니다. 그것은 깨지기 쉬운 런타임 규칙을 견고한 컴파일 타임 보증으로 바꿉니다.

Exhaustive Checking vs. Traditional Error Handling

완전한 검사를 오류 처리를 대체하는 것으로 생각하기 쉽지만 그것은 오해입니다. 그들은 서로 다른 종류의 문제를 해결하도록 설계된 보완적인 도구입니다. 핵심적인 차이점은 예측 가능하고 알려진 상태와 예측 불가능하고 예외적인 이벤트를 처리하도록 설계되었다는 점에 있습니다.

Defining the Concepts

• 오류 처리는 종종 프로그램의 제어 범위를 벗어나는 예외적이고 예측 불가능한 상황을 관리하기 위한 런타임 전략입니다. 실행 중에 발생할 수 있고 실제로 발생하는 실패를 처리합니다.
  • 예: 네트워크 요청 실패, 디스크에서 파일을 찾을 수 없음, 잘못된 사용자 입력, 데이터베이스 연결 시간 초과.
  • 도구: `try...catch` 블록, `Promise.reject()`, 오류 코드 또는 `null` 반환, `Result` 타입 (Rust와 같은 언어에서 볼 수 있음).
• 완전한 검사는 프로그램 로직 내에서 모든 알려진 유효한 논리적 경로 또는 데이터 상태가 명시적으로 처리되도록 보장하는 컴파일 타임 전략입니다. 코드의 완전성을 보장하는 것입니다.
  • 예: 열거형의 모든 변형 처리, 판별된 유니온의 모든 타입 처리, 유한 상태 머신의 모든 상태 관리.
  • 도구: `never` 타입, 언어가 강제하는 `switch` 또는 `match` 완전성 (Swift 및 Rust에서 볼 수 있음).

The Guiding Principle: Knowns vs. Unknowns

어떤 접근 방식을 사용할지 결정하는 간단한 방법은 문제의 본질에 대해 스스로에게 묻는 것입니다.

• 이것이 내 코드베이스 내에서 정의하고 제어하는 ​​가능성 집합입니까? 완전한 검사를 사용하십시오. 이것들은 당신의 "knowns"입니다. 당신의 `Shape` 유니온은 완벽한 예입니다. 당신은 가능한 모든 모양을 정의합니다.
• 이것이 외부 시스템, 사용자 또는 환경에서 발생하는 이벤트입니까? 여기서 실패가 가능하고 정확한 입력은 예측할 수 없습니까? 오류 처리를 사용하십시오. 이것들은 당신의 "unknowns"입니다. 네트워크가 항상 사용 가능하다고 증명하기 위해 타입 시스템을 사용할 수 없습니다.

Scenario Analysis: When to Use Which

시나리오 1: API 응답 파싱 (오류 처리)

타사 API에서 사용자 데이터를 가져오고 있다고 가정해 보겠습니다. API 설명서에는 `status` 필드가 있는 JSON 객체가 반환된다고 나와 있습니다. 컴파일 타임에 이를 신뢰할 수 없습니다. 네트워크가 다운되거나 API가 더 이상 사용되지 않아 500 오류를 반환하거나 잘못된 JSON 문자열을 반환할 수 있습니다. 이것이 오류 처리의 영역입니다.

            async function fetchUser(userId: string): Promise<User> {
  try {
    const response = await fetch(`https://api.example.com/users/${userId}`);
    if (!response.ok) {
      // Handle HTTP errors (e.g., 404, 500)
      throw new Error(`API Error: ${response.status}`);
    }
    const data = await response.json();
    // Here you would also add runtime validation of the data structure
    return data as User;
  } catch (error) {
    // Handle network errors, JSON parsing errors, etc.
    console.error("Failed to fetch user:", error);
    throw error; // Re-throw or handle gracefully
  }
}
            

              
                Copy
              
            
          

`never`를 여기에서 사용하는 것은 부적절합니다. 왜냐하면 실패 가능성은 무한하고 타입 시스템 외부에 있기 때문입니다.

시나리오 2: UI 컴포넌트 상태 렌더링 (완전한 검사)

이제 UI 컴포넌트가 여러 잘 정의된 상태 중 하나에 있을 수 있다고 가정해 보겠습니다. 이 상태를 애플리케이션 코드 내에서 완전히 제어합니다. 이것은 판별된 유니온과 완전한 검사를 위한 완벽한 후보입니다.

            type ComponentState =
  | { status: 'loading' }
  | { status: 'success'; data: string[] }
  | { status: 'error'; message: string };

function renderComponent(state: ComponentState): string { // Returns an HTML string
  switch (state.status) {
    case 'loading':
      return `<div>Loading...</div>`;
    case 'success':
      return `<ul>${state.data.map(item => `<li>${item}</li>`).join('')}</ul>`;
    case 'error':
      return `<div class="error">Error: ${state.message}</div>`;
    default:
      // If we later add a 'submitting' status, this line will protect us!
      const _exhaustiveCheck: never = state;
      throw new Error(`Unhandled state: ${_exhaustiveCheck}`);
  }
}
            

              
                Copy
              
            
          

개발자가 새로운 상태 `{ status: 'idle' }`를 추가하면 컴파일러는 즉시 `renderComponent`를 불완전하다고 표시하여 컴포넌트가 빈 공간으로 렌더링되는 UI 버그를 방지합니다.

The Synergy: Combining Both Approaches for Robust Systems

가장 탄력적인 시스템은 하나를 다른 것보다 선택하지 않습니다. 그들은 모두 함께 사용합니다. 오류 처리는 혼란스러운 외부 세계를 관리하는 반면 완전한 검사는 내부 로직이 건전하고 완전한지 확인합니다. 오류 처리 경계의 출력은 종종 완전한 검사에 의존하는 시스템의 입력이됩니다.

API 가져오기 예제를 개선해 보겠습니다. 함수는 예측할 수 없는 네트워크 오류를 처리할 수 있지만 제어된 방식으로 성공하거나 실패하면 나머지 애플리케이션이 자신감 있게 처리할 수 있는 예측 가능하고 잘 타입화된 결과를 반환합니다.

            // 1. Define a predictable, well-typed result for our internal logic.
type FetchResult<T> =
  | { status: 'success'; data: T }
  | { status: 'error'; error: Error };

// 2. The function now uses Error Handling to produce a result that can be Exhaustively Checked.
async function fetchUserData(userId: string): Promise<FetchResult<User>> {
  try {
    const response = await fetch(`https://api.example.com/users/${userId}`);
    if (!response.ok) {
      throw new Error(`API returned status ${response.status}`);
    }
    const data = await response.json();
    // Add runtime validation here (e.g., with Zod or io-ts)
    return { status: 'success', data: data as User };
  } catch (error) {
    // We catch ANY potential error and wrap it in our known structure.
    return { status: 'error', error: error instanceof Error ? error : new Error('An unknown error occurred') };
  }
}

// 3. The calling code can now use Exhaustive Checking for clean, safe logic.
async function displayUser(userId: string) {
  const result = await fetchUserData(userId);

  switch (result.status) {
    case 'success':
      console.log(`User name: ${result.data.name}`);
      break;
    case 'error':
      console.error(`Failed to display user: ${result.error.message}`);
      break;
    default:
      const _exhaustiveCheck: never = result;
      // This ensures if we add a 'loading' status to FetchResult,
      // this code block will fail to compile until we handle it.
      return _exhaustiveCheck;
  }
}
            

              
                Copy
              
            
          

이 결합된 패턴은 믿을 수 없을 정도로 강력합니다. `fetchUserData` 함수는 경계 역할을하여 예측할 수없는 네트워크 요청의 세계를 예측 가능한 판별된 유니온으로 변환합니다. 그런 다음 애플리케이션의 나머지는 컴파일 타임 완전성 검사의 완전한 안전망을 통해 이 깨끗한 데이터 구조에서 작동할 수 있습니다.

A Global Perspective: `never` in Other Languages

바닥 타입 및 컴파일 타임 완전성의 개념은 TypeScript에만 고유하지 않습니다. 그것은 많은 현대적이고 안전 중심적인 언어의 특징입니다. 다른 곳에서 구현되는 방식을 보면 소프트웨어 엔지니어링에서 근본적인 중요성이 강화됩니다.

• Rust: Rust에는 "never 타입"이라고하는 `!` 타입이 있습니다. 현재 실행 스레드를 종료하는 `panic!()` 매크로와 같이 "diverge"하는 함수의 반환 타입입니다. Rust의 강력한 `match` 표현식 (스위치 버전)은 기본적으로 완전성을 시행합니다. `enum`에서 `match`하고 모든 변형을 다루지 못하면 코드가 컴파일되지 않습니다. 언어가 기본적으로 이 안전을 제공하기 때문에 수동 `never` 트릭이 필요하지 않습니다.
• Swift: Swift에는 `Never`라는 빈 열거형이 있습니다. 오류를 발생 시키거나 종료하지 않아 함수 또는 메소드가 절대 반환하지 않음을 나타내는 데 사용됩니다. Rust와 마찬가지로 Swift의 `switch` 문은 기본적으로 완전해야하므로 열거형으로 작업할 때 컴파일 타임 안전성을 제공합니다.
• Kotlin: Kotlin에는 타입 시스템의 바닥 타입인 `Nothing` 타입이 있습니다. 오류를 항상 발생시키는 표준 라이브러리의 `TODO()` 함수와 같이 함수가 절대 반환하지 않음을 나타내는 데 사용됩니다. Kotlin의 `when` 표현식 (스위치와 동일)은 완전한 검사에도 사용할 수 있으며 컴파일러는 표현식으로 사용될 때 완전하지 않으면 경고 또는 오류를 발행합니다.
• Python (Type Hints 포함): Python의 `typing` 모듈에는 절대 반환하지 않는 함수를 주석 처리하는 데 사용할 수있는 `NoReturn`이 포함되어 있습니다. Python의 타입 시스템은 점진적이고 Rust 또는 Swift만큼 엄격하지 않지만 이러한 주석은 Mypy와 같은 정적 분석 도구에 귀중한 정보를 제공하여보다 철저한 검사를 수행 할 수 있습니다.

이러한 다양한 생태계에서 공통적 인 스레드는 타입 레벨에서 불가능한 상태를 표현할 수 없도록 만드는 것이 전체 버그 클래스를 제거하는 강력한 방법이라는 인식입니다.

Actionable Insights and Best Practices

이 강력한 개념을 일상 업무에 통합하려면 다음 방법을 고려하십시오.

1. 판별된 유니온을 수용하십시오: 여러 개의 개별 변형이 될 수 있는 타입이 있을 때마다 판별된 유니온 (태그가 지정된 유니온 또는 합 타입이라고도 함)으로 데이터를 적극적으로 모델링하십시오. 이것은 완전한 검사가 구축되는 기초입니다. API 결과, 컴포넌트 상태 및 이벤트를 이러한 방식으로 모델링하십시오.
2. 불법 상태를 표현할 수 없도록 만드십시오: 이것은 타입 기반 설계의 핵심 원칙입니다. 사용자가 관리자이자 게스트가 동시에 될 수없는 경우 타입 시스템은이를 반영해야합니다. 여러 개의 선택적 부울 플래그 (isAdmin?: boolean; isGuest?: boolean;) 대신 유니온 (A | B)을 사용하십시오. `never` 타입은 상태가 표현할 수 없음을 증명하는 궁극적인 도구입니다.
3. 재사용 가능한 도우미 함수를 만드십시오: `default` 케이스는 간단한 도우미 함수로 더 깔끔하게 만들 수 있습니다. 이는 코드가 런타임에 도달하면 (불가능해야 함) 더 설명적인 오류를 제공합니다.

               function assertNever(value: never): never {
     throw new Error(`Unhandled discriminated union member: ${JSON.stringify(value)}`);
   }
   
   // Usage:
   default:
     assertNever(shape); // Cleaner and provides a better runtime error message.
               
   
                 
                   Copy
                 
               
             

4. 컴파일러의 말을 들으십시오: 완전성 오류를 귀찮은 것으로 여기지 말고 선물로 여기십시오. 컴파일러는 프로그램에서 논리적 결함을 발견한 부지런하고 자동화된 코드 검토자 역할을 하고 있습니다. 감사하고 코드를 수정하십시오.

Conclusion: The Silent Guardian of Your Codebase

`never` 타입은 이론적 호기심 그 이상입니다. 그것은 강력하고 자기 문서화되고 유지 관리 가능한 소프트웨어를 구축하기위한 실용적이고 강력한 도구입니다. 완전한 검사를 위해 활용함으로써 우리는 근본적으로 정확성에 접근하는 방식을 바꿉니다. 우리는 논리적 완전성을 보장하는 부담을 오류가 발생하기 쉬운 인간의 기억과 런타임 테스트에서 오류가 없고 자동화된 컴파일 타임 타입 분석의 세계로 옮깁니다.

전통적인 오류 처리는 외부 시스템의 예측할 수 없는 특성을 관리하는 데 필수적이지만 완전한 검사는 애플리케이션의 내부적이고 알려진 로직에 대한 보완적 보증을 제공합니다. 함께 그들은 버그에 대한 계층화 된 방어를 형성하여 실패하기 쉬울뿐만 아니라 추론하기 쉽고 리팩터링하기에 더 안전한 시스템을 만듭니다.

다음에 `switch` 문이나 알려진 가능성 세트에 대한 긴 `if-else-if` 체인을 작성하는 자신을 발견하면 잠시 멈추고 `never` 타입이 이 코드에 대한 조용한 보호자 역할을 할 수 있는지 물어보십시오. 그렇게 함으로써 당신은 오늘날 옳을뿐만 아니라 내일의 간과에 대해서도 강화되는 코드를 작성하게 될 것입니다.