infer, never만 보면 두려워지는 당신을 위한 타입 추론 - 고급 타입 추론 관련

TypeScript > Article(s)

---

Article(s)

• 타입 검사(type checking)
  • 타입 검사는 증명이다
• 제네릭(generic)
  • 명시적 타입 전달(explicit type argument passing)
  • 타입 인자 추론(type argument inference)
  • 조건부 타입(conditional type)
• 마치며

---

infer, never만 보면 두려워지는 당신을 위한 타입 추론 - 고급 타입 추론 | NAVER D2

infer, never만 보면 두려워지는 당신을 위한 타입 추론 - 고급 타입 추론

'infer, never만 보면 두려워지는 당신을 위한 타입 추론' 관련 영상은 링크에서 보실 수 있습니다.

TS의 궁극적인 목표는 안전한 대입과 참조를 실현하는 것입니다. 앞 글에서는 이를 위해서 타입과 그 대소 관계를 정의하고, 안전한 대입이 무엇인지 살펴보았습니다. 이 글에서는 TS가 어떻게 안전하지 않은 대입이나 참조를 잡아내는지 알아보겠습니다.

---

타입 검사(type checking)

타입 검사란, 어떤 심벌에 대한 각종 대입/참조/연산이 가능한지 확인하는 과정입니다. 어떻게 보면 자동 증명이라고 할 수 있는데요. 단순히 증명에서 그치는 것이 아니라, 구체적으로 어떤 맥락 하에 심벌이 가질 수 있는 타입은 무엇인지도 찾아냅니다(예: 타입 가드를 수행한 if문 블록, IDE 자동 완성).

학술적으로 이는 제약 충족 문제 (Constrained Satisfaction Problem, CSP)의 일종입니다. 그러나 이 문제는 NP-완전(NP-complete)하기 때문에, 현실적으로 컴파일러가 풀기엔 너무 어려운 문제입니다. 따라서 tsc는 그리디(greedy)한 알고리즘을 구현한 것으로 추정됩니다(실제로 지수 복잡도 케이스를 테스트해보면, 백트래킹을 하지 않는다는 것을 알 수 있습니다).

타입 검사는 증명이다

tsc는 개발자가 입력한 소스 코드를 기반 지식(knowledge base)으로 사용합니다. 즉, 엉터리 타입을 주거나 엉터리 대입을 하더라도 그것을 참인 명제로 간주합니다. 대신 그 소스 코드를 정적 분석하면서 모순이 발생할 경우, tsc에 내재하는 사실은 참이므로 소스 코드에 오류가 있다고 결론을 내죠.

예를 들어, 다음과 같은 간단한 상수 선언문이 있다고 생각해 봅시다.

const x: number = 'a'  

상수 식별자 x, 타입 키워드 number, 문자열 리터럴 'a'가 있네요.

1. as const가 없으니 리터럴 'a'의 타입은 string 입니다.
2. 식별자 x는 number 타입입니다.
3. rvalue의 타입은 lvalue의 서브타입이므로, number ≳ string 입니다.
4. 그런데 공리적으로 number ≄ string이므로 모순입니다.
5. tsc는 상수 선언문에서 리터럴에 그 책임을 묻고 빨간줄을 긋습니다.

---

제네릭(generic)

제네릭이란, 타입의 함수이기도 하지만, 타입 간의 관계 그 자체를 표현한 것이기도 합니다(사실 수학적으로 함수는 관계의 일종입니다). 제네릭은 일종의 1차 논리로도 볼 수 있는데요, 제네릭의 제네릭처럼 고차 논리는 사용이 불가능합니다. (예: F<T> = T<number>)

제네릭의 타입 인자에 extends 키워드를 붙여서, 허용하는 슈퍼타입을 지정할 수 있습니다.

type OnlyArray<T extends unknown[]> = ...

type X = OnlyArray<number>  
// Type 'number' does not satisfy the constraint 'unknown[]'

제네릭이 포함된 소스 코드의 타입 검사는 2가지 유형으로 나뉩니다.

명시적 타입 전달(explicit type argument passing)

명시적 타입 전달이란 제네릭 타입 인자에 명시적으로 타입을 기술하는 형태입니다. 전달한 정보를 전제(premise)로 활용합니다.

useState<{ foo?: number }>({})  

제어 흐름(control flow)상 제네릭이 선언된 심벌 다음부터는, 타입의 올바름 유무에 관계없이 해당 인자로 추론할 수 있는 모든 타입이 결정됩니다. 예를 들어 아래의 소스 코드는 잘못된 인자를 대입하고 있지만, 그것과 관계없이 반환형은 제네릭에만 의존합니다.

function processList<T>(list: T[]): T[] {  
  // ...
}

const list = processList(new Promise())  
// Argument of type 'Promise<unknown>' is not assignable to parameter of type 'unknown[]'.

list.forEach((x) => console.log(x))  
// 타입 오류가 난 것과 별개로 `list`는 `unknown[]`으로 간주하여 계속 진행

타입 인자 추론(type argument inference)

타입 인자 추론은 제네릭에 타입 인자를 생략한 경우에 수행하는 추론입니다. 라이브러리 제작자가 자주 고려해야 할 방식으로, 사용성에 지대한 영향을 미칩니다. 제네릭 외에도 타입 선언을 하지 않은 심벌이나, infer 키워드 등을 사용한 경우에도 동일한 원리가 적용됩니다.

이 방식은 tsc가 정적 분석으로 얻어낸 정보를 토대로, 최대한 인자를 추론합니다. 만약 추론에 실패한 경우 unknown으로 간주합니다. 이 알고리즘은 명시적으로 알려져 있지 않으며, 때로는 일관성이 없기도 합니다. 많은 경우 tsc는 가장 비관적이고 보수적인 관점으로 타입을 추론합니다. 또한 그리디하고 휴리스틱한 추론 알고리즘을 사용하며, tsc가 업데이트되면서 동작이 소폭 바뀌기도 하니 주의가 필요합니다.

function f<T>(value: Promise<T>): T  
function f<T>(value: T): T[]  
function f<T>(value: number): string

function f(value: any): any { ... } // 구현체

const x = f(3) // x의 타입은 number[]  

위 예시에서 f(3) 호출문을 만족하는 가장 첫 번째 시그니처는 function f<T>(value: T)입니다. number라는 구체적인 타입이 아래에 있지만, 이미 만족한 시그니처가 있으므로 무시합니다.

조건부 타입(conditional type)

조건부 타입이란 제네릭 정의문에서 특정 타입이 다른 타입의 서브타입인지 확인한 뒤 분기하는 구문입니다. infer와 밀접한 연관이 있습니다.

type IsNever<T> = [T] extends [never] ? true : false  

이때 extends ... infer 키워드로, 특정 타입 표현식을 만족하는 가장 작은 슈퍼타입을 추론할 수도 있습니다.

type GetElement<T> = T extends (infer R)[] ? R : never

type ShouldNumber = GetElement<number[]>  
// number[]의 슈퍼타입은 (number | string)[], unknown[], number[] | string 등 다양하지만
// 가장 작은 슈퍼타입은 number[]이므로, R은 number로 추론됩니다.

주의 사항

인자의 T에 대한 정보가 하나도 없는 경우, 항상 모든 분기의 결과를 합연산하지는 않는다는 것을 주의해야 합니다.

가령 아래의 코드는 얼핏 이해가 되지 않을 수 있는데요, x ≲ T이면서 x ≲ string이라고 해서 T ≲ string이라는 보장이 없기 때문입니다. 이 상황에서 T에 관해선 어떠한 전제도 할 수 없고, 결과적으로 F<T>도 결정을 못하는 상황이 됩니다. 상식적으로 생각하면 true | false나 boolean을 반환할 것 같지만, 적어도 5 버전까지의 tsc는 그냥 타입 오류를 내버립니다.

type F<T> = T extends string ? true : false  
function foo<T>(x: T): F<T> {  
    if (typeof x === 'string') {
        return true // Type 'boolean' is not assignable to type 'F<T>'
    }
    return false // Type 'boolean' is not assignable to type 'F<T>'
}

조건부 타입의 분배 법칙(distributive law)

조건부 타입에는 특수한 기능이 있습니다. 바로 extends 키워드가 합집합에 대한 분배를 수행한다는 점입니다. 다음 두 제네릭을 보면 단적으로 이해할 수 있습니다.

type F<T> = T[]  
type G<T> = T extends unknown ? T[] : never

type T1 = F<string | number> // (string | number)[]  
type T2 = G<string | number> // string[] | number[]  

unknown은 항상 모든 타입의 슈퍼타입이기 때문에, G는 묻지도 따지지도 않고 배열을 반환합니다. 그런데 F는 개별 요소가 합집합인 반면, G는 개별 요소는 분리되고 그 결과가 합집합이 됩니다. 이 사실은 고급 타입을 설계할 때 매우 중요하게 작용합니다. 경우에 따라서는 저 성질을 억제해야 할 때도 있는데요, 그럴 땐 튜플로 감싸주면 됩니다.

조건부 타입의 예시를 들 때 특정 타입이 never인지 확인하는 IsNever를 다시 보세요. 분배 법칙을 억제하고 있습니다. 왜 그럴까요?

type WrongIsNever<T> = T extends never ? true : false  
type IsItTrue = WrongIsNever<never> // never  

바로 never가 공집합의 성질을 갖기 때문입니다. 조건부 타입은 T를 대상으로 합집합에 대한 분배를 수행합니다. 즉, 내부적으로 타입 인자를 대상으로 하나씩 map을 수행하는 것과 유사한 동작을 합니다. 그런데 never는 빈 배열, 혹은 공집합과 다를 바가 없어, 해당 연산을 아예 수행하지 않습니다. 그래서 true도 false도 아닌, 빈 타입인 never가 반환된 것입니다. 그러나 튜플로 감쌀 경우, [never]는 엄연히 비어있지 않은 타입이고, [...]가 1개 있는 타입의 합집합이므로 의도한 대로 추론한 것입니다.

---

마치며

TS가 어떻게 안전하지 않은 대입이나 참조를 잡아내는지 알아보았습니다. 다음 글에서는 지금까지 다룬 내용을 토대로 응용 문제를 풀어 보겠습니다.

infer, never만 보면 두려워지는 당신을 위한 타입 추론 시리즈

infer, never만 보면 두려워지는 당신을 위한 타입 추론 - 기초 타입 이론 | NAVER D2

---

infer, never만 보면 두려워지는 당신을 위한 타입 추론 - 기초 타입 이론

infer, never만 보면 두려워지는 당신을 위한 타입 추론 - 고급 타입 추론 | NAVER D2

---

infer, never만 보면 두려워지는 당신을 위한 타입 추론 - 고급 타입 추론

infer, never만 보면 두려워지는 당신을 위한 타입 추론 - 응용 문제 | NAVER D2

---

infer, never만 보면 두려워지는 당신을 위한 타입 추론 - 응용 문제

infer, never만 보면 두려워지는 당신을 위한 타입 추론 - 고급 타입 추론

---

infer, never만 보면 두려워지는 당신을 위한 타입 추론 - 고급 타입 추론