TypeScript 시니어 프레임워크 심화 면접
새 면접Q. TypeScript의 Variance(공변성, 반공변성, 이변성, 불변성) 개념을 설명하고, 함수 매개변수가 반공변적(contravariant)인 이유를 설명해주세요. 또한 strictFunctionTypes 옵션이 비활성화되었을 때 메서드 시그니처가 이변적(bivariant)으로 동작하여 발생할 수 있는 타입 안정성 문제와, 실무에서 이를 방지하기 위한 전략을 포함해주세요.
Variance는 타입 간의 상속 관계가 제네릭 타입에 어떻게 전파되는지를 나타냅니다. 공변성(covariance)은 A가 B의 서브타입이면 T<A>도 T<B>의 서브타입이 되는 것이고, 반공변성(contravariance)은 그 반대입니다. 함수 매개변수는 반공변적인데, 이는 타입 안정성을 위해 더 넓은 타입을 받는 함수가 더 좁은 타입을 받는 함수의 서브타입이 되어야 하기 때문입니다. strictFunctionTypes가 false일 때 메서드는 이변적으로 동작하여 양방향 할당이 가능해지는데, 이는 런타임 에러를 유발할 수 있습니다. 실무에서는 strictFunctionTypes를 활성화하고, 메서드 대신 프로퍼티로 함수를 정의하여 올바른 타입 체킹을 보장해야 합니다.
- • 공변성은 타입 관계가 그대로 유지되고, 반공변성은 역전되며, 이변성은 양방향 모두 허용
- • 함수 매개변수는 반공변적이어야 타입 안정성 보장 (Liskov Substitution Principle)
- • strictFunctionTypes 옵션으로 메서드의 이변성을 제어하여 타입 안정성 향상
- • 실무에서는 화살표 함수 프로퍼티를 사용하여 올바른 variance 적용
TypeScript에서 readonly 배열이나 튜플의 variance는 어떻게 동작하며, 이것이 불변 데이터 구조 설계에 어떤 영향을 미치나요?
Q. TypeScript의 Template Literal Types와 Intrinsic String Manipulation Types(Uppercase, Lowercase, Capitalize, Uncapitalize)를 조합하여 REST API 라우트를 타입 안전하게 관리하는 시스템을 설계하는 방법을 설명해주세요. 특히 동적 경로 파라미터 추출, HTTP 메서드별 타입 분기, 쿼리 파라미터 타입 추론을 포함한 엔드투엔드 타입 안정성 구현 전략을 포함해주세요.
Template Literal Types를 사용하여 라우트 패턴을 문자열 리터럴 타입으로 정의하고, 재귀적 Conditional Types로 경로에서 파라미터를 추출할 수 있습니다. 예를 들어 '/users/:userId/posts/:postId'에서 {userId: string, postId: string} 타입을 자동 추론합니다. HTTP 메서드는 Mapped Types로 각 메서드별 핸들러 타입을 분기하고, Intrinsic Types로 메서드명을 정규화합니다. 쿼리 파라미터는 별도의 제네릭 타입으로 정의하여 라우트 정의와 핸들러 구현 간 타입 일관성을 보장합니다. 이를 통해 컴파일 타임에 잘못된 파라미터 접근이나 타입 불일치를 감지할 수 있습니다.
- • Template Literal Types로 라우트 패턴을 타입으로 표현하고 파라미터 자동 추출
- • 재귀적 Conditional Types와 infer로 동적 경로 세그먼트 파싱
- • Mapped Types로 HTTP 메서드별 핸들러 타입 분기 및 Intrinsic Types로 정규화
- • 제네릭 타입 매개변수로 요청/응답 body, 쿼리, 파라미터 타입 연결하여 엔드투엔드 타입 안정성 확보
이러한 타입 시스템이 런타임 성능에 미치는 영향은 무엇이며, 타입 추론이 너무 복잡해져서 컴파일 시간이 길어지는 문제를 어떻게 해결하시겠습니까?
Q. TypeScript 컴파일러의 타입 체킹 성능을 저하시키는 주요 원인들(과도한 Union Types, 깊은 타입 중첩, 복잡한 Conditional Types 등)을 설명하고, 대규모 모노레포 환경에서 컴파일 시간을 최적화하기 위한 전략을 설명해주세요. 특히 Incremental Compilation, Composite Projects, skipLibCheck, skipDefaultLibCheck 옵션의 활용과 트레이드오프를 포함해주세요.
과도한 Union Types는 타입 체커가 각 경우의 수를 모두 검사해야 하므로 지수적으로 시간이 증가하며, 깊은 타입 중첩은 재귀 깊이 제한에 도달할 수 있습니다. 복잡한 Conditional Types는 타입 추론 과정에서 많은 연산을 요구합니다. Incremental Compilation은 .tsbuildinfo 파일로 이전 컴파일 결과를 캐싱하여 변경된 파일만 재컴파일합니다. Composite Projects는 프로젝트를 여러 단위로 분리하여 병렬 빌드와 선택적 재빌드를 가능하게 합니다. skipLibCheck는 node_modules의 타입 정의 파일 검사를 생략하여 속도를 높이지만, 서드파티 라이브러리의 타입 오류를 놓칠 수 있습니다. 실무에서는 타입 복잡도를 줄이고, Project References로 의존성 그래프를 최적화하며, CI에서는 캐시를 활용하는 전략이 필요합니다.
- • Union Types 개수 제한, 타입 중첩 깊이 감소, Conditional Types 단순화로 타입 체킹 복잡도 관리
- • Incremental Compilation으로 변경된 파일만 재컴파일하여 빌드 시간 단축
- • Project References와 Composite 옵션으로 모노레포를 논리적 단위로 분리하여 병렬 빌드
- • skipLibCheck로 서드파티 타입 검사 생략하되, 타입 안정성과 속도 간 트레이드오프 고려
TypeScript 5.0+에서 도입된 성능 개선 사항들과, 타입 체킹 성능을 모니터링하고 병목 지점을 식별하는 방법은 무엇인가요?
Q. TypeScript의 Decorator와 Reflect Metadata API를 활용하여 런타임 타입 검증, 로깅, 트랜잭션 관리 등의 횡단 관심사(cross-cutting concerns)를 구현하는 방법을 설명해주세요. 특히 Decorator의 실행 순서(클래스, 메서드, 프로퍼티, 파라미터 데코레이터), experimentalDecorators와 emitDecoratorMetadata 옵션의 역할, 그리고 TC39 Stage 3 Decorator 제안과의 차이점을 포함해주세요.
Decorator는 클래스, 메서드, 프로퍼티, 파라미터에 메타데이터를 추가하거나 동작을 변경하는 메타프로그래밍 패턴입니다. 실행 순서는 파라미터 → 메서드 → 접근자 → 프로퍼티 → 클래스 순이며, 같은 레벨에서는 아래에서 위로 적용됩니다. experimentalDecorators는 현재 TypeScript의 레거시 데코레이터를 활성화하고, emitDecoratorMetadata는 타입 정보를 Reflect.metadata로 저장하여 런타임에 접근 가능하게 합니다. 이를 활용하면 DI 컨테이너, 유효성 검증, AOP 패턴을 구현할 수 있습니다. TC39 Stage 3 제안은 static 블록, auto-accessor 등 새로운 기능을 제공하며, 메타데이터 API가 별도로 분리되어 reflect-metadata 폴리필이 필요합니다.
- • Decorator 실행 순서는 하위 요소부터 상위로, 같은 레벨은 아래에서 위로 적용
- • emitDecoratorMetadata로 타입 정보를 런타임에 보존하여 DI, 검증 등에 활용
- • Reflect Metadata API로 커스텀 메타데이터 저장/조회하여 횡단 관심사 구현
- • TC39 Stage 3 제안은 표준화된 문법이지만 메타데이터 API는 별도 제안으로 분리
Decorator를 사용할 때 발생할 수 있는 성능 오버헤드와, 프로덕션 환경에서 Decorator 기반 아키텍처의 디버깅 및 유지보수 전략은 무엇인가요?
Q. TypeScript의 Control Flow Analysis가 타입 좁히기(Type Narrowing)를 수행하는 메커니즘을 설명하고, typeof, instanceof, in 연산자, 사용자 정의 타입 가드(type predicate)가 각각 어떤 상황에서 효과적인지 설명해주세요. 또한 Discriminated Union 패턴에서 exhaustiveness checking을 구현하여 모든 케이스를 처리했는지 컴파일 타임에 보장하는 방법과, never 타입의 역할을 포함해주세요.
Control Flow Analysis는 코드의 실행 흐름을 분석하여 각 지점에서 변수의 가능한 타입을 좁혀나가는 컴파일러 기능입니다. typeof는 원시 타입 구분에, instanceof는 클래스 인스턴스 체크에, in 연산자는 객체의 프로퍼티 존재 여부로 타입을 좁힐 때 사용합니다. 사용자 정의 타입 가드는 복잡한 조건이나 외부 라이브러리 타입 체크에 유용합니다. Discriminated Union에서는 공통 리터럴 타입 프로퍼티(태그)로 각 케이스를 구분하고, switch문에서 모든 케이스를 처리하지 않으면 default에서 never 타입이 남아 컴파일 에러를 발생시켜 exhaustiveness를 보장합니다. 이를 통해 새로운 타입 추가 시 처리 누락을 방지할 수 있습니다.
- • Control Flow Analysis로 조건문, 반환문 등을 분석하여 각 코드 경로의 타입 자동 추론
- • typeof는 원시 타입, instanceof는 클래스, in은 프로퍼티, 타입 가드는 복잡한 조건에 활용
- • Discriminated Union의 태그 프로퍼티로 타입 분기하고 switch문으로 모든 케이스 처리
- • never 타입을 활용한 exhaustiveness checking으로 미처리 케이스를 컴파일 타임에 감지
타입 가드 함수에서 asserts 키워드를 사용하는 assertion function과 일반 type predicate의 차이점과 각각의 사용 사례는 무엇인가요?
아직 댓글이 없습니다. 첫 번째 댓글을 남겨보세요!