TypeScript 및 타입 시스템

정적 타입 시스템은 코드가 실행되기 전, 즉 컴파일 시점에 변수나 표현식의 타입을 검사하는 방식이다. TypeScript나 Java, C++ 같은 언어가 이에 해당한다. 컴파일러는 소스 코드를 분석하여 타입 불일치나 잘못된 연산을 미리 발견하고 오류를 보고한다. 이로 인해 프로그램의 런타임 중 발생할 수 있는 많은 종류의 오류를 사전에 방지할 수 있다. 또한, IDE의 자동 완성, 정확한 리팩토링, 코드 탐색 등의 개발 도구 지원을 강력하게 받을 수 있다는 장점이 있다.

반면, 동적 타입 시스템은 코드 실행 중, 즉 런타임에 타입을 결정하고 검사한다. JavaScript, Python, Ruby가 대표적인 예이다. 변수에 어떤 타입의 값이든 자유롭게 할당할 수 있으며, 타입 검사는 실제 연산이 일어나는 순간에 수행된다. 이는 빠른 프로토타이핑과 유연한 코드 작성이 가능하게 하지만, 실행 전까지 타입 관련 오류를 발견하기 어렵고, 개발 도구의 지원이 제한될 수 있다.

두 시스템의 주요 차이점은 다음과 같이 요약할 수 있다.

TypeScript는 정적 타입 시스템을 채택한 언어이지만, 그 기반이 되는 JavaScript는 동적 타입 언어이다. 따라서 TypeScript는 개발 중에 정적 타입 검사의 이점을 제공하면서도, 최종적으로는 순수 JavaScript로 컴파일되어 동적 타입의 환경에서 실행된다. 이는 두 세계의 장점을 결합한 접근법으로 볼 수 있다.

TypeScript의 타입 시스템은 명목적 타입 시스템이 아닌 구조적 타입 시스템을 채택한다. 이는 타입의 호환성을 판단할 때 타입의 이름(명목)보다는 타입이 실제로 가지고 있는 프로퍼티와 메서드의 구조를 기준으로 삼는다는 의미이다. 다시 말해, 두 타입이 동일한 구조를 가지면 서로 호환되는 타입으로 간주한다.

이러한 접근 방식은 덕 타이핑과 유사한 개념으로, "오리처럼 걷고 오리처럼 꽥꽥거리면 그것은 오리이다"라는 철학을 반영한다. 예를 들어, Person이라는 인터페이스가 name: string 프로퍼티를 가지고 있고, 별도로 정의된 User 객체가 동일한 name: string 프로퍼티를 가진다면, TypeScript는 User 객체를 Person 타입이 필요한 곳에 사용하는 것을 허용한다. 타입의 이름이 다르더라도 구조가 일치하기 때문이다.

구조적 타입 시스템의 장점은 코드의 유연성을 크게 높인다는 점이다. 명시적인 상속 관계나 인터페이스 구현 선언 없이도 객체 리터럴이나 클래스 인스턴스가 특정 형태를 만족하기만 하면 해당 타입으로 사용될 수 있다. 이는 특히 자바스크립트의 동적이고 유연한 특성과 잘 어울리며, 기존 자바스크립트 코드에 타입 안전성을 점진적으로 도입하는 TypeScript의 설계 목표와 부합한다.

반면, 구조적 타입 시스템은 때로는 의도하지 않은 타입 호환을 허용할 수 있다는 점에서 비판을 받기도 한다. 예를 들어, 서로 다른 도메인의 객체가 실수로 동일한 구조를 가질 경우, 컴파일 타임에는 오류 없이 통과하지만 논리적으로는 잘못된 코드가 될 수 있다. 개발자는 이러한 특성을 이해하고, 필요한 경우 더 엄격한 타입 제약을 위해 브랜드 타입 같은 패턴을 활용하기도 한다[1].

타입 추론은 TypeScript 컴파일러가 명시적인 타입 표기가 없어도 코드의 문맥을 분석하여 값의 타입을 자동으로 결정하는 기능이다. 이 기능은 개발자가 모든 변수나 함수에 타입을 일일이 명시하지 않아도 되게 하여 코드 작성의 편의성을 크게 높인다. 컴파일러는 변수의 초기값, 함수의 반환문, 매개변수의 기본값 등 다양한 단서를 사용하여 가장 적절한 타입을 유추한다.

타입 추론은 주로 다음과 같은 상황에서 발생한다.

* 변수 선언과 초기화: 변수를 선언하면서 동시에 값을 할당하면, 해당 값의 타입이 변수의 타입으로 추론된다. 예를 들어, let count = 5; 라고 선언하면 count 변수의 타입은 number로 추론된다.

* 함수 반환 타입: 함수 본문의 return 문을 분석하여 반환값의 타입을 추론한다. 명시적인 반환 타입 표기가 없어도 함수의 타입을 결정할 수 있다.

* 기본값이 설정된 매개변수: 함수 매개변수에 기본값이 설정되어 있으면, 해당 기본값의 타입을 바탕으로 매개변수의 타입이 추론된다.

그러나 타입 추론에는 한계가 있다. 변수를 선언만 하고 초기화하지 않으면 타입을 추론할 수 없어 any 타입으로 간주된다. 또한, 복잡한 로직이나 여러 가능한 반환 경로가 있는 함수에서는 개발자가 의도한 타입과 다른 타입이 추론될 수 있다. 이러한 경우 명시적인 타입 표기를 추가하는 것이 타입 안전성을 보장하는 데 도움이 된다. 타입 추론은 개발자의 수고를 덜어주는 편리한 기능이지만, 타입 시스템의 정확성을 완전히 대체하는 것은 아니다.

TypeScript의 타입은 크게 원시 타입과 객체 타입으로 구분된다. 이 구분은 값의 종류와 메모리에서의 표현 방식, 그리고 동작에 근간을 둔다.

원시 타입은 단일한 값을 나타내는 불변(immutable) 타입이다. TypeScript는 JavaScript의 원시 타입을 그대로 지원하며, 주요 예시는 다음과 같다.

이들 원시 타입의 값은 변경할 수 없으며, 변수에 할당되거나 함수에 전달될 때 '값에 의한 전달(pass-by-value)' 방식으로 동작한다.

반면 객체 타입은 원시 타입이 아닌 모든 타입을 지칭한다. 이는 속성(property)의 집합으로 구성되며, 배열, 함수, 클래스 인스턴스, 사용자 정의 객체 등이 포함된다. 객체 타입의 값은 변경 가능(mutable)한 경우가 많으며, 변수에 할당되거나 전달될 때는 '참조에 의한 전달(pass-by-reference)' 방식으로 동작한다. 객체 타입을 정의하는 주요 수단으로는 인터페이스와 타입 별칭이 있다. 예를 들어, { name: string; age: number; }와 같은 형태로 객체의 구조를 명시할 수 있다. 배열은 number[] 또는 Array<string>과 같이, 함수는 (x: number, y: number) => number와 같이 타입을 정의한다.

유니온 타입은 두 개 이상의 타입 중 하나를 가질 수 있는 값을 표현한다. | 기호를 사용하여 정의하며, 주어진 타입들 중 하나에 해당하는 값을 허용한다. 예를 들어, string | number 타입은 문자열이나 숫자 값을 가질 수 있다. 이는 함수의 매개변수가 여러 타입을 받아야 하거나, API 응답이 다양한 형태를 가질 때 유용하게 사용된다. 유니온 타입의 변수를 사용할 때는 타입 가드를 통해 특정 타입으로 좁혀야 해당 타입의 고유 메서드나 속성에 안전하게 접근할 수 있다.

반면, 인터섹션 타입은 여러 타입의 모든 속성을 동시에 만족하는 타입을 생성한다. & 기호를 사용하여 정의하며, 객체 타입을 결합할 때 흔히 사용된다. 예를 들어, Person & Serializable이라는 타입은 Person 타입이 가진 모든 속성과 Serializable 타입이 가진 모든 속성을 모두 갖는 객체만을 의미한다. 이는 믹스인 패턴이나 객체 구성(composition)을 타입 수준에서 표현하는 데 적합하다.

두 타입의 주요 차이점은 결합의 논리적 의미에 있다. 유니온 타입은 "A 또는 B"의 논리합(OR) 개념이라면, 인터섹션 타입은 "A 그리고 B"의 논리곱(AND) 개념이다. 다음 표는 간단한 예시를 통해 이를 비교한다.

실제 개발에서는 두 타입을 조합하여 복잡한 타입 관계를 모델링한다. 예를 들어, string | null은 선택적 값을, T & {id: number}는 기존 타입 T에 id 속성을 추가하는 확장을 표현할 수 있다.

제네릭은 TypeScript의 타입 시스템에서 재사용 가능한 컴포넌트를 만들기 위한 핵심 도구이다. 함수, 인터페이스, 클래스를 정의할 때, 구체적인 타입이 아닌 타입 매개변수를 사용하여 다양한 타입에 대해 동작하는 일반화된 코드를 작성할 수 있게 한다. 이는 자바나 C#과 같은 정적 타입 언어의 제네릭 개념과 유사하다. 제네릭을 사용하면 any 타입을 사용할 때 발생할 수 있는 타입 안전성 손실 없이, 코드의 재사용성과 유연성을 크게 향상시킬 수 있다.

제네릭의 가장 일반적인 사용 예는 함수와 배열이다. 예를 들어, identity라는 함수가 어떤 타입의 값을 받아 그대로 반환한다고 할 때, 제네릭 타입 매개변수 T를 사용해 function identity<T>(arg: T): T { return arg; }와 같이 정의할 수 있다. 이 함수를 호출할 때는 identity<string>("hello")처럼 명시적으로 타입을 지정하거나, identity("hello")처럼 타입 추론에 맡길 수 있다. 마찬가지로, Array<T>는 TypeScript 내장 제네릭 타입의 대표적인 예로, 배열이 담을 요소의 타입을 매개변수로 받는다.

제네릭은 인터페이스와 클래스 정의에서도 광범위하게 활용된다. interface Box<T> { contents: T; }와 같이 인터페이스를 정의하면, string, number 등 어떤 타입이든 contents로 가질 수 있는 박스를 만들 수 있다. 클래스에서는 class GenericNumber<T> { zeroValue: T; add: (x: T, y: T) => T; }와 같이 멤버 변수나 메서드의 타입을 일반화할 수 있다. 또한, 제네릭 타입 매개변수에 제약 조건을 걸어 특정 요구사항을 만족하는 타입만 사용하도록 제한할 수 있다. extends 키워드를 사용해 interface Lengthwise { length: number; }를 상속받도록 T를 제한하면(function loggingIdentity<T extends Lengthwise>(arg: T): T), length 프로퍼티가 있는 타입만 인자로 전달받을 수 있다.

제네릭을 활용한 일반적인 패턴은 다음과 같다.

이러한 제네릭의 특성은 라이브러리나 프레임워크를 설계할 때 특히 유용하다. 사용자는 자신의 구체적인 타입을 제네릭 타입 매개변수로 제공함으로써, 타입 안전성을 보장받으면서도 미리 정의된 일반적인 로직을 활용할 수 있다.

인터페이스는 TypeScript에서 객체의 형태를 정의하는 주요 방법 중 하나이다. 구체적인 구현 없이 객체가 가져야 할 프로퍼티와 메서드의 구조를 명시하는 타입 계약이다. 클래스가 이를 구현하거나, 객체 리터럴이 이 형태를 따르도록 강제하는 데 사용된다.

인터페이스는 interface 키워드로 선언하며, 선택적 프로퍼티(?), 읽기 전용 프로퍼티(readonly), 함수 타입, 인덱스 시그니처 등을 정의할 수 있다. 또한, 하나의 인터페이스는 extends 키워드를 사용해 다른 인터페이스를 상속받아 프로퍼티를 확장할 수 있다. 이는 코드의 재사용성을 높이고 계층적인 타입 구조를 만드는 데 유용하다.

인터페이스는 주로 객체의 구조적 타입 시스템을 정의하는 데 사용되며, 타입 별칭과 유사한 역할을 한다. 그러나 인터페이스는 선언 병합이 가능하고, extends를 통한 상속에 더 적합한 반면, 타입 별칭은 유니온이나 인터섹션 타입을 생성하는 등 더 복잡한 타입 표현에 주로 사용된다는 차이점이 있다.

타입 별칭은 TypeScript에서 새로운 타입의 이름을 생성하는 방법이다. type 키워드를 사용하여 복잡한 타입 정의에 간결한 이름을 부여한다. 이는 코드의 가독성을 높이고, 동일한 타입 구조를 반복해서 작성하는 것을 방지한다.

타입 별칭은 인터페이스와 유사한 역할을 하지만, 몇 가지 차이점이 있다. 인터페이스는 주로 객체의 형태를 정의하는 데 사용되며, 선언 병합이 가능하다. 반면 타입 별칭은 유니온 타입, 인터섹션 타입, 튜플, 원시 타입 등 더 넓은 범위의 타입에 이름을 붙일 수 있다. 다음은 간단한 사용 예시이다.

```typescript

type UserID = string | number;

type Point = {

x: number;

y: number;

};

type Coordinates = [number, number, number?];

```

타입 별칭은 재할당이 불가능하다는 점에서 상수와 유사하다. 한 번 정의된 타입 별칭은 변경할 수 없다. 이는 타입 안정성을 유지하는 데 도움을 준다. 또한, 제네릭과 함께 사용하여 재사용 가능한 타입 템플릿을 만들 수 있다. 예를 들어, type ApiResponse<T> = { success: boolean; data: T }와 같이 정의하면 다양한 데이터 타입에 대해 일관된 응답 형식을 표현할 수 있다.

클래스는 TypeScript에서 객체 지향 프로그래밍의 핵심 요소이자 강력한 타입 정의 수단으로 사용된다. 클래스는 인스턴스의 구조와 동작을 정의하며, 동시에 해당 클래스 이름 자체가 하나의 타입으로 작용한다. 클래스로 생성된 타입은 주로 해당 클래스의 인스턴스를 가리킨다.

클래스는 implements 키워드를 사용하여 인터페이스를 구현할 수 있다. 이는 클래스가 특정 계약(인터페이스)을 충족하도록 강제하는 메커니즘이다. 또한, extends 키워드를 통해 다른 클래스를 상속받을 수 있으며, 이때 자식 클래스는 부모 클래스의 타입을 포함하는 하위 타입이 된다. TypeScript의 구조적 타입 시스템 덕분에 명시적인 상속 관계가 없더라도 구조가 호환되는 클래스 인스턴스는 서로 할당될 수 있다.

클래스의 구성 요소는 다음과 같은 타입 의미를 가진다.

추상 클래스(abstract class)는 직접 인스턴스화할 수 없지만, 다른 클래스가 상속받을 기반 타입을 제공한다. 추상 메서드는 구현 없이 시그니처만 선언하여, 파생 클래스에서 반드시 구체적인 구현을 강제한다.

타입 가드는 TypeScript 컴파일러가 특정 범위 내에서 변수의 타입을 더 좁혀서 추론할 수 있도록 하는 코드 패턴이다. 주로 유니온 타입으로 선언된 변수를 다룰 때, 런타임 검사를 통해 구체적인 타입을 확인하고 해당 범위에서 타입을 좁히는 데 사용된다. 이를 통해 개발자는 타입 안전성을 유지하면서도 유연한 코드를 작성할 수 있다.

타입 가드는 주로 typeof, instanceof, in 연산자나 사용자 정의 타입 술어 함수를 통해 구현된다. typeof는 문자열, 숫자, 불리언 등의 원시 타입을 구분하는 데 사용되고, instanceof는 클래스의 인스턴스를 확인하는 데 사용된다. in 연산자는 객체가 특정 프로퍼티를 가지고 있는지 검사하여 타입을 좁힌다.

사용자 정의 타입 가드 함수는 반환 타입이 변수명 is 타입 형식인 함수를 말한다. 이 함수는 런타임에 논리적 검사를 수행하고, true를 반환하면 TypeScript 컴파일러는 해당 인자의 타입을 지정된 타입으로 좁힌다. 예를 들어, function isFish(pet: Fish | Bird): pet is Fish와 같은 함수는 매개변수 pet이 Fish 타입인지를 검사한다.

타입 가드를 효과적으로 사용하면 불필요한 타입 단언을 줄이고, 코드의 가독성과 유지보수성을 높일 수 있다. 또한, 복잡한 객체 구조를 가진 유니온 타입을 안전하게 처리할 때 필수적인 기법으로 활용된다.

타입 단언은 컴파일러에게 "이 값의 타입은 내가 지정한 타입이다"라고 명시적으로 알려주는 방법이다. TypeScript의 타입 시스템은 일반적으로 정적 타입 검사를 수행하지만, 개발자가 컴파일러보다 값의 타입을 더 정확히 알고 있는 경우가 있다. 이때 as 키워드나 앵글 브래킷(<>) 구문을 사용하여 타입 단언을 수행한다.

타입 단언은 두 가지 주요 형태로 사용된다. 가장 일반적인 형태는 값 as 타입 구문이다. 예를 들어, document.getElementById는 HTMLElement | null을 반환하지만, 특정 id를 가진 요소가 반드시 존재한다고 확신할 때 document.getElementById('myCanvas') as HTMLCanvasElement와 같이 단언하여 더 구체적인 타입을 지정할 수 있다. 앵글 브래킷을 사용한 타입값 구문도 가능하지만, JSX와의 혼동 가능성 때문에 as 구문을 권장한다.

타입 단언은 타입 변환이나 런타임 동작을 변경하지 않는다. 순전히 컴파일 타임에만 영향을 미치는 작업이다. 따라서 실제 값의 구조가 단언한 타입과 호환되지 않으면 런타임 오류가 발생할 수 있다. 이를 남용하면 타입 안전성을 훼손할 수 있으므로, any 타입으로의 단언이나 상속 관계가 없는 타입 간의 단언(이중 단언)은 필요한 경우에만 신중하게 사용해야 한다. 대안으로는 타입 가드를 활용하는 방법이 있다.

TypeScript의 타입 시스템은 주로 컴파일 타임에 작동하므로, 런타임 환경에서는 타입 정보가 대부분 제거된다. 따라서 JavaScript로 변환된 후 실행 중에 변수의 타입을 확인하려면 추가적인 검사 로직이 필요하다. 이를 런타임 타입 검사라고 한다.

가장 일반적인 방법은 typeof와 instanceof 연산자를 사용하는 것이다. typeof 연산자는 문자열, 숫자, 불리언, undefined 등 기본 원시 타입을 구분하는 데 유용하다. instanceof 연산자는 사용자 정의 클래스나 배열, Date 같은 내장 객체의 인스턴스인지를 확인할 때 사용한다. 그러나 이 방법들은 TypeScript의 정교한 인터페이스나 유니온 타입 같은 복잡한 타입을 완벽하게 검사할 수 없다는 한계가 있다.

더 강력한 런타임 검사를 위해, 개발자는 종종 사용자 정의 타입 가드 함수를 작성하거나 외부 라이브러리를 도입한다. 예를 들어, zod나 io-ts 같은 라이브러리는 스키마를 정의하고, 해당 스키마에 대해 데이터의 유효성을 런타임에 검증하는 기능을 제공한다. 이는 주로 외부 API 응답이나 사용자 입력처럼 컴파일 타임에 타입을 보장할 수 없는 데이터를 안전하게 처리할 때 필수적이다.

결론적으로, TypeScript 프로젝트에서 완전한 타입 안전성을 달성하려면 컴파일 타임 타입 검사와 런타임 타입 검사를 조화롭게 사용하는 전략이 필요하다. 특히 시스템의 경계 부분에서는 런타임 검사가 데이터 무결성을 보장하는 핵심 수단이 된다.

조건부 타입은 입력되는 제네릭 타입에 따라 결과 타입이 결정되는 타입 시스템의 고급 기능이다. T extends U ? X : Y 형태의 삼항 연산자 구문을 사용하여 타입 수준에서의 조건부 논리를 표현한다. 여기서 T가 U에 할당 가능하면 결과 타입은 X가 되고, 그렇지 않으면 Y가 된다. 이는 런타임이 아닌 컴파일 타임에 평가되는 타입 수준의 연산이다.

조건부 타입은 주로 제네릭 타입을 정제하거나 오버로드를 모델링하는 데 활용된다. 예를 들어, Array<T> 타입에서 요소 타입 T를 추출하는 TypeName<T> 같은 유틸리티 타입을 구성할 수 있다. 또한, 함수 오버로딩의 복잡한 시그니처를 단일 제네릭 함수 타입으로 표현할 때 유용하게 사용된다. 분산 조건부 타입이라는 특성 덕분에 유니온 타입이 입력되면 각 구성 요소에 대해 조건이 개별적으로 평가되어 결과가 다시 유니온 타입으로 결합된다[3].

조건부 타입을 활용한 몇 가지 일반적인 패턴은 다음과 같다.

infer 키워드는 조건부 타입의 extends 절에서 새로운 제네릭 타입 변수를 선언하는 데 사용된다. 이를 통해 기존 타입의 내부 구조를 탐색하고 부분 타입을 추출할 수 있다. 조건부 타입은 템플릿 리터럴 타입이나 매핑된 타입과 결합되어 더욱 강력하고 유연한 타입 변환을 가능하게 한다.

매핑된 타입은 기존 타입을 기반으로 각 속성을 변환하여 새로운 타입을 생성하는 타입스크립트의 고급 기능이다. 이는 반복문과 유사한 방식으로 타입의 속성을 순회하며 새로운 타입 정의를 만드는 것을 가능하게 한다. 주로 keyof 연산자와 함께 사용되어, 기존 타입의 모든 키를 순회하고 각 키에 대한 타입을 수정한다. 예를 들어, 모든 속성을 선택적(optional)으로 만들거나 읽기 전용(readonly)으로 변환하는 등의 작업을 수행할 수 있다.

매핑된 타입의 기본 구문은 { [K in Keys]: Type } 형태를 따른다. 여기서 Keys는 유니온 타입 형태의 키 집합(예: keyof T)이며, K는 각 키를 순회하는 변수이다. Type은 각 키 K에 대해 계산될 새로운 타입을 지정한다. 내장된 유틸리티 타입인 Partial<T>, Readonly<T>, Pick<T, K> 등은 모두 매핑된 타입을 기반으로 구현되어 있다. 사용자는 이러한 패턴을 활용하여 도메인에 특화된 유연한 타입 변환기를 직접 정의할 수 있다.

매핑된 타입은 as 절을 사용한 키 리매핑을 통해 더욱 강력해졌다. 이를 통해 순회 중인 키의 이름을 조건에 따라 변경할 수 있다. 예를 들어, 모든 속성 이름에 접두사를 추가하거나 특정 패턴을 가진 키만 필터링하여 새로운 키 집합을 생성하는 타입을 정의할 수 있다. 이 기능은 템플릿 리터럴 타입과 결합되어 동적인 문자열 조작을 타입 수준에서 가능하게 한다. 매핑된 타입은 제네릭과 함께 사용될 때 가장 빛을 발하며, 재사용 가능하고 타입 안전성을 높이는 추상화된 타입 계층을 구축하는 데 핵심적인 역할을 한다.

템플릿 리터럴 타입은 문자열 리터럴 타입을 기반으로 하여, 문자열의 특정 패턴을 타입으로 정의할 수 있게 해주는 기능이다. TypeScript 4.1 버전에서 도입되었으며, 템플릿 리터럴 문법을 타입 수준에서 사용할 수 있게 한다. 이를 통해 특정 형식을 갖춘 문자열(예: 이메일 주소, 파일 경로, CSS 단위 등)의 타입을 보다 정교하게 표현할 수 있다.

기본적인 사용법은 유니온 타입과 결합하여 문자열의 특정 부분을 변수화하는 것이다. 예를 들어, VerticalAlign 타입을 'top' | 'middle' | 'bottom'으로 정의하고, HorizontalAlign 타입을 'left' | 'center' | 'right'로 정의했을 때, 이 둘을 조합한 새로운 타입을 만들 수 있다.

```typescript

type VerticalAlign = 'top' | 'middle' | 'bottom';

type HorizontalAlign = 'left' | 'center' | 'right';

// "top-left", "middle-center", "bottom-right" 등의 타입을 자동 생성

type Alignment = ${VerticalAlign}-${HorizontalAlign};

```

이 패턴은 매핑된 타입과 함께 사용될 때 더욱 강력해진다. 객체의 키나 값의 타입을 문자열 패턴에 따라 변환하는 것이 가능하다. 또한 조건부 타입 내에서 infer 키워드와 함께 사용되어 문자열을 파싱하거나 특정 부분을 추출하는 타입 유틸리티를 만드는 데 활용된다. 예를 들어, 경로 문자열에서 파일 확장자를 추출하는 타입을 정의할 수 있다.

```typescript

type ExtractFileExtension<T extends string> = T extends ${string}.${infer Ext} ? Ext : never;

type CssExt = ExtractFileExtension<'style.css'>; // 타입은 "css"

type JsExt = ExtractFileExtension<'index.ts'>; // 타입은 "ts"

```

템플릿 리터럴 타입은 유니온 타입으로 생성된 모든 가능한 문자열 조합의 교집합을 계산하여 타입을 만든다. 이는 조합 가능한 경우의 수가 매우 많아질 경우 컴파일러 성능에 영향을 줄 수 있으므로 주의가 필요하다. 주로 API 엔드포인트 경로, CSS 클래스명, 국제화(i18n) 키, 식별자 생성 규칙 등 문자열 패턴이 중요한 도메인에서 타입 안전성을 높이는 데 유용하게 적용된다.

TypeScript 컴파일러(tsc)는 다양한 옵션을 제공하여 타입 검사와 JavaScript 변환 과정을 세밀하게 제어할 수 있다. 이러한 옵션은 tsconfig.json 파일에 설정하거나 명령줄 인수로 전달할 수 있다. 주요 옵션은 타입 검사의 엄격성, 출력 대상, 모듈 시스템, 소스 맵 생성 등 프로젝트의 요구사항에 맞게 컴파일 동작을 조정하는 데 사용된다.

타입 검사와 관련된 핵심 옵션으로는 strict 플래그가 있다. 이 플래그를 true로 설정하면 noImplicitAny, strictNullChecks, strictFunctionTypes 등 일련의 엄격한 타입 검사 옵션들을 한꺼번에 활성화한다. 예를 들어, strictNullChecks가 활성화되면 null과 undefined가 모든 타입에 자동으로 포함되지 않아 널 안전성을 강화할 수 있다. 반면, 기존 JavaScript 코드를 점진적으로 마이그레이션하는 경우에는 strict를 false로 설정하거나 개별 엄격 옵션을 조정하여 타입 검사의 강도를 완화할 수 있다.

출력과 모듈 관련 설정도 중요하다. target 옵션은 컴파일 결과물이 어떤 ECMAScript 버전(예: ES5, ES2015, ES2020)을 대상으로 하는지 지정한다. module 옵션은 모듈 코드 생성 방식을 결정하며(commonjs, es2015, esnext 등), 이는 사용하는 번들러나 런타임 환경에 따라 달라진다. outDir은 컴파일된 파일이 저장될 디렉토리를, rootDir은 입력 소스 파일의 루트 디렉토리를 지정한다.

이 외에도 allowJs 옵션을 통해 .js 파일을 프로젝트에 포함하고 checkJs를 통해 이들 파일에 대한 타입 검사를 수행할 수 있다. skipLibCheck는 선언 파일(.d.ts)의 타입 검사를 생략하여 컴파일 성능을 향상시킬 수 있지만, 일부 타입 불일치가 발생할 위험이 있다. 적절한 컴파일러 옵션의 조합은 개발 생산성, 코드 품질, 그리고 빌드 성능 사이의 균형을 찾는 데 핵심적인 역할을 한다.

타입 정의 파일은 TypeScript에서 JavaScript 라이브러리나 모듈의 타입 정보를 제공하는 데 사용되는 특수한 파일이다. 확장자는 .d.ts를 가지며, 이 파일들은 순수한 타입 선언만을 포함하고 실행 가능한 코드는 포함하지 않는다. 주로 타입이 없는 기존 JavaScript 코드에 타입 안전성을 부여하거나, 다른 TypeScript 프로젝트에서 사용할 수 있는 라이브러리의 공개 API를 정의하는 목적으로 작성된다.

.d.ts 파일의 주요 내용은 인터페이스, 타입 별칭, 함수 시그니처, 클래스 선언, 제네릭 정의, 모듈 및 네임스페이스 선언 등이다. 예를 들어, declare 키워드를 사용해 "이런 형태의 함수나 변수가 존재한다"고 선언한다. 다음은 간단한 예시이다.

```typescript

// myLib.d.ts

declare function greet(name: string): void;

declare const version: string;

```

이 파일은 greet 함수와 version 상수가 존재하며 그 타입을 정의하지만, 실제 구현은 포함하지 않는다.

.d.ts 파일은 크게 두 가지 방식으로 관리된다. 첫째, 널리 사용되는 JavaScript 라이브러리의 타입 정의는 대부분 DefinitelyTyped 저장소에서 @types/ 스코프의 npm 패키지로 제공된다[5]. 둘째, 라이브러리 자체가 TypeScript로 작성되었다면, 패키지의 package.json 파일에 "types" 필드를 설정하여 자체적인 .d.ts 파일을 번들링해 제공할 수 있다. 이는 최선의 방식으로 간주된다.

.d.ts 파일을 사용할 때 주의할 점은 앰비언트 선언의 범위이다. 전역으로 타입을 노출시키는 선언은 의도치 않은 이름 충돌을 일으킬 수 있으므로, 모듈(export 사용) 또는 네임스페이스 내에 선언하여 범위를 제한하는 것이 바람직하다. 또한, 타입 정의 파일의 정확성은 라이브러리의 실제 구현과 일치해야 하며, 그렇지 않으면 타입 체크의 신뢰성이 떨어지게 된다.

타입스크립트 컴파일러(tsc)는 기본적인 타입 검사를 수행하는 핵심 도구이다. 컴파일러는 소스 코드를 분석하여 타입 오류를 식별하고, 설정된 컴파일러 옵션에 따라 자바스크립트 코드로 변환하거나 검사만 수행한다. tsc --noEmit 명령어는 코드 생성을 하지 않고 타입 검사만 실행할 때 유용하다.

타입 검사의 정확성과 범위는 tsconfig.json 파일의 설정에 크게 의존한다. 주요 옵션은 다음과 같다.

타입스크립트 생태계에는 컴파일러 외에도 다양한 보조 도구가 존재한다. ESLint와 같은 린터는 @typescript-eslint 플러그인을 통해 코드 스타일과 잠재적 문제를 함께 검사할 수 있다. Prettier는 코드 포맷터로, 타입스크립트 문법을 지원하여 일관된 코드 스타일을 유지하는 데 도움을 준다.

대규모 프로젝트나 모노레포 환경에서는 타입 검사 성능이 중요해진다. 이 경우, 증분 컴파일을 지원하는 도구나 타입 검사만을 빠르게 실행하는 전용 도구를 고려할 수 있다. 또한, CI/CD 파이프라인에 타입 검사 단계를 통합하여 메인 브랜치에 타입 오류가 병합되는 것을 방지하는 것이 일반적인 관행이다.

TypeScript 컴파일러는 소스 코드를 JavaScript로 변환하는 과정에서 타입 검사를 수행한다. 이 타입 검사 과정은 추가적인 계산 리소스를 소모하며, 이로 인해 발생하는 컴파일 시간의 증가가 주요 오버헤드로 여겨진다. 특히 대규모 프로젝트나 복잡한 제네릭과 조건부 타입을 광범위하게 사용하는 코드베이스에서는 컴파일 시간이 눈에 띄게 길어질 수 있다. 그러나 이 오버헤드는 개발 단계에서의 비용이며, 최종 산출물인 자바스크립트 코드의 런타임 성능에는 전혀 영향을 미치지 않는다. 컴파일된 자바스크립트 코드에는 모든 타입 정보가 제거되기 때문이다.

타입 시스템 오버헤드를 관리하기 위한 일반적인 접근법은 점진적 타입 검사를 도입하는 것이다. 대부분의 프로젝트에서는 핵심 모듈이나 자주 변경되는 부분에 대해서만 실시간 타입 검사를 적용하고, 비교적 안정된 라이브러리 코드나 타사 모듈에 대해서는 검사 강도를 낮추는 전략을 사용한다. 또한, 컴파일러의 --incremental 플래그를 사용하여 이전 컴파일 결과를 재사용하거나, 프로젝트 참조를 활용해 큰 프로젝트를 작은 단위로 분리하여 컴파일하는 방법이 효과적이다.

다음은 타입 시스템 오버헤드에 영향을 미치는 주요 요소와 완화 전략을 정리한 표이다.

결론적으로, 타입 시스템의 오버헤드는 컴파일 시간에 국한된 트레이드오프이다. 이 오버헤드는 적절한 도구 설정과 프로젝트 구조 최적화를 통해 관리 가능한 수준으로 줄일 수 있으며, 그 대가로 얻는 타입 안전성과 개발자 경험 향상의 이점은 일반적으로 더 크다고 평가된다.

TypeScript의 타입 시스템은 개발 과정에서 높은 안전성을 제공하지만, 대규모 프로젝트나 복잡한 타입 정의에서는 컴파일 시간 증가와 같은 오버헤드를 유발할 수 있다. 이를 완화하기 위해 여러 최적화 기법이 활용된다.

주요 최적화 기법으로는 불필요한 복잡성을 줄이는 것이 핵심이다. 인터페이스와 타입 별칭을 과도하게 중첩하거나, 깊은 수준의 조건부 타입과 매핑된 타입을 남용하면 타입 추론에 부담을 준다. 가능하면 간결한 타입 구조를 설계하고, 제네릭의 타입 매개변수에 기본값을 제공하여 타입 추론을 돕는 것이 좋다. 또한, type 대신 interface를 사용하면 인터섹션 타입을 통한 확장 시 성능상 이점이 있을 수 있다[7].

타입 검사 범위를 제한하는 설정도 효과적이다. tsconfig.json의 skipLibCheck 옵션을 활성화하면 라이브러리의 타입 정의 파일 검사를 건너뛰어 컴파일 속도를 높일 수 있다. 특정 모듈에 대해서만 엄격한 검사를 적용하려면 // @ts-expect-error나 // @ts-ignore 주석을 신중하게 사용하거나, 점진적으로 타입을 적용하는 전략을 채택한다. 프로젝트 참조(Project References) 기능을 이용해 코드베이스를 작은 단위로 분리하고 증분 컴파일을 활용하는 것도 빌드 시간을 단축하는 방법이다.