TypeScript 시니어 프레임워크 기술면접

Excess Property Checking은 객체 리터럴이 fresh object로 간주될 때만 적용되며, 이는 오타나 실수로 인한 잘못된 프로퍼티 전달을 방지하기 위한 안전장치입니다. 변수에 할당되면 객체는 더 이상 fresh하지 않아 구조적 타이핑 규칙만 적용되므로, 추가 프로퍼티가 있어도 에러가 발생하지 않습니다. Index Signature가 있는 타입의 경우 추가 프로퍼티를 허용하므로 Excess Property Checking이 적용되지 않습니다. 이러한 동작으로 인해 중간 변수를 거치면 타입 안정성이 약화될 수 있으므로, 실무에서는 타입 단언보다는 명시적 타입 정의와 직접 전달 패턴을 권장합니다. 또한 as const assertion을 활용하면 리터럴 타입을 보존하면서도 타입 안정성을 높일 수 있습니다.

Type Widening은 let으로 선언된 변수의 리터럴 타입이 일반 타입으로 확장되는 현상이고, Type Narrowing은 조건문 등을 통해 타입이 구체화되는 과정입니다. const assertion은 변수를 readonly 리터럴 타입으로 추론하며, as const는 중첩된 객체와 배열까지 깊은 readonly로 만듭니다. satisfies 연산자는 TypeScript 4.9에서 도입되어 타입 체크는 수행하되 추론된 타입은 보존하므로, 타입 안정성과 정확한 타입 추론을 동시에 달성할 수 있습니다. 실무에서 설정 객체는 as const로 불변성을 보장하고, API 응답 스키마는 satisfies로 타입 체크와 자동완성을 모두 활용하며, 상수 배열은 const assertion으로 튜플 타입을 유지하는 패턴이 효과적입니다.

TypeScript는 타입 생성자 자체를 제네릭 파라미터로 받을 수 없어 Functor나 Monad 같은 추상화를 직접 표현할 수 없습니다. 이를 우회하기 위해 타입 레벨 맵핑을 사용하는 defunctionalization 기법이 있으며, URI를 통해 타입 생성자를 식별하고 lookup 타입으로 실제 타입을 가져오는 패턴입니다. fp-ts 같은 라이브러리는 이 방식으로 HKT를 시뮬레이션하지만, 타입 정의가 복잡해지고 타입 추론이 약화되는 단점이 있습니다. 실무에서는 완전한 HKT 구현보다는 구체적인 타입에 대한 제네릭 함수를 작성하거나, 필요한 경우에만 제한적으로 HKT 패턴을 적용하는 것이 유지보수성과 가독성 측면에서 유리합니다. 타입 안정성과 코드 복잡도 사이의 균형을 고려한 실용적 접근이 중요합니다.

namespace는 TypeScript 고유의 내부 모듈 시스템으로 컴파일 시 IIFE로 변환되며, ES Module은 표준 JavaScript 모듈 시스템입니다. ES Module은 정적 분석이 가능해 트리 쉐이킹과 코드 분할을 효과적으로 지원하지만, namespace는 런타임 객체로 번들링되어 사용하지 않는 코드도 포함될 수 있습니다. 순환 참조 문제에서도 ES Module은 명시적 import로 의존성을 파악하기 쉽지만, namespace는 암묵적 참조로 인해 디버깅이 어렵습니다. 다만 전역 타입 선언이나 ambient declaration을 그룹화할 때, 또는 레거시 라이브러리와의 호환성을 위해서는 namespace가 여전히 유용합니다. 현대 프로젝트에서는 ES Module을 기본으로 사용하고, declare namespace는 타입 정의 목적으로만 제한적으로 활용하는 것이 권장됩니다.

Distributive Conditional Types는 naked type parameter가 Union 타입일 때 각 멤버에 대해 조건부 타입을 개별적으로 적용한 후 결과를 Union으로 합치는 동작입니다. 예를 들어 T extends U ? X : Y에서 T가 A | B라면 (A extends U ? X : Y) | (B extends U ? X : Y)로 분배됩니다. 분배를 방지하려면 [T] extends [U] 패턴으로 타입 파라미터를 튜플로 감싸 naked type parameter가 아니게 만들어야 합니다. Union 타입 전체를 하나의 단위로 처리해야 할 때, 예를 들어 Union을 배열로 변환하거나 Union의 길이를 계산할 때 non-distributive 패턴이 필요합니다. 실무에서는 Exclude, Extract 같은 유틸리티 타입이 분배 법칙을 활용하며, 복잡한 타입 변환 로직에서 분배 제어가 타입 정확성에 중요한 역할을 합니다.

allowSyntheticDefaultImports는 타입 체크 단계에서만 작동하여 default import를 허용하지만 실제 코드는 변환하지 않으며, esModuleInterop은 타입 체크와 함께 런타임 헬퍼 코드를 생성하여 실제 동작을 보장합니다. CommonJS 모듈은 module.exports로 내보내지만 ES Module의 default import와 구조가 달라, esModuleInterop 없이는 import React from 'react' 같은 코드가 런타임 에러를 발생시킬 수 있습니다. esModuleInterop은 __importStar와 __importDefault 헬퍼를 생성하여 이를 해결하며, allowSyntheticDefaultImports만 활성화하면 타입 체크는 통과하지만 번들러가 없는 환경에서는 런타임 에러가 발생합니다. Webpack이나 Rollup 같은 번들러를 사용하면 모듈 변환을 번들러가 처리하므로 allowSyntheticDefaultImports만으로 충분할 수 있지만, Node.js 직접 실행 환경에서는 esModuleInterop이 필수입니다.

Tuple Types는 고정 길이 배열에 각 위치별 타입을 지정할 수 있으며, Rest Elements(...T[])로 가변 길이를, Optional Elements(T?)로 선택적 요소를 표현합니다. Named Tuple Elements는 [name: string, age: number] 같은 형태로 가독성을 높이며, 함수 매개변수 시그니처를 튜플 타입으로 표현할 때 유용합니다. Variadic Tuple Types는 제네릭과 spread 연산자를 조합하여 함수 합성이나 커링을 타입 안전하게 구현할 수 있게 합니다. 예를 들어 concat 함수의 타입을 [...T, ...U]로 표현하여 두 튜플의 결합을 정확히 추론할 수 있습니다. 다만 튜플 길이 계산이나 재귀적 타입 조작은 TypeScript의 재귀 깊이 제한과 복잡도 제약을 받으므로, 실무에서는 합리적인 수준의 복잡도를 유지해야 합니다.

Abstract Class는 일부 구현을 포함할 수 있고 런타임에 존재하며 단일 상속만 가능한 반면, Interface는 순수 타입 정의만 가능하고 컴파일 후 제거되며 다중 구현이 가능합니다. Abstract Class는 공통 로직을 상위 클래스에서 구현하고 일부만 하위 클래스가 오버라이드하는 Template Method 패턴에 적합하며, private/protected 같은 접근 제어자를 사용할 수 있습니다. Interface는 계약만 정의하고 구현은 클래스에 맡기는 Strategy 패턴이나 Dependency Injection에 적합하며, 여러 인터페이스를 조합하여 유연한 타입 시스템을 구축할 수 있습니다. 실무에서는 Abstract Class로 기본 구현과 템플릿을 제공하고, Interface로 외부 계약을 정의하는 조합 패턴이 효과적이며, 이를 통해 SOLID 원칙 중 Dependency Inversion과 Interface Segregation을 달성할 수 있습니다.

Assertion Functions는 asserts 키워드를 사용하여 함수가 정상 반환되면 특정 조건이 참임을 타입 시스템에 보장하며, 조건이 거짓이면 예외를 던져야 합니다. 일반 타입 가드가 boolean을 반환하여 if문 내부에서만 타입을 좁히는 것과 달리, Assertion Functions는 함수 호출 이후 코드 전체에서 타입이 좁혀진 상태를 유지합니다. 제어 흐름 분석에서 assertion function 호출 이후 코드는 조건이 참인 경로로만 간주되어 타입 체크가 단순화됩니다. 런타임 검증 라이브러리와 통합할 때는 검증 함수에 asserts 시그니처를 추가하여 런타임 안전성과 타입 안전성을 동시에 달성할 수 있습니다. 실무에서는 API 응답 검증, 환경 변수 검증, 불변 조건 확인 등에서 assertion functions를 활용하여 방어적 프로그래밍과 타입 안정성을 결합합니다.

Recursive Type Aliases는 타입 정의 내부에서 자기 자신을 참조하여 재귀적 구조를 표현하며, TypeScript 4.1 이전에는 재귀 깊이가 매우 제한적이었지만 이후 크게 완화되었습니다. JSON 타입을 정의할 때 type Json = string | number | boolean | null | Json[] | { [key: string]: Json } 같은 재귀 구조로 모든 유효한 JSON을 표현할 수 있습니다. 트리 구조 순회나 깊은 객체 변환에서는 Conditional Types와 조합하여 각 레벨을 재귀적으로 처리하되, 종료 조건을 명확히 정의해야 무한 재귀를 방지할 수 있습니다. 실무에서는 재귀 깊이를 제한하는 카운터 타입을 사용하거나, 특정 깊이 이후 any로 대체하는 안전 장치를 두는 패턴이 효과적입니다. 또한 재귀 타입의 복잡도가 컴파일 성능에 영향을 미칠 수 있으므로, 필요한 경우에만 제한적으로 사용하고 타입 단순화를 고려해야 합니다.