---
id: wiki-2026-0508-타입-별칭-type-alias
title: 타입 별칭 (Type Alias)
category: 10_Wiki/Topics_Art
status: needs_review
canonical_id: self
aliases: [P-REINFORCE-AUTO-37A8A8]
duplicate_of: none
source_trust_level: A
confidence_score: 0.9
tags: [auto-reinforced]
raw_sources: []
last_reinforced: 2026-04-20
github_commit: "[P-Reinforce] Continuous Worker - 타입 별칭 (Type Alias)"
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
tech_stack:
  language: unspecified
  framework: unspecified
---

# [[타입 별칭 (Type Alias)]]

## 📌 한 줄 통찰 (The Karpathy Summary)
> 타입 별칭(Type Alias)은 TypeScript에서 기존 타입에 새로운 이름을 부여하여 재사용성을 높이는 기능입니다 [1]. 인터페이스(Interface)와 유사하게 객체의 형태를 정의하는 데 사용할 수 있으며, 그 외에도 원시 타입(Primitives), 유니온(Union), 튜플(Tuple) 및 기타 복잡한 타입 조합을 명명할 수 있는 폭넓은 표현력을 갖습니다 [1]. 인터페이스와 달리 선언 병합(Declaration Merging)을 허용하지 않아, 동일한 이름으로 재선언 시 에러를 발생시킴으로써 더 엄격한 타입 관리를 가능하게 합니다 [2, 3].

## 📖 구조화된 지식 (Synthesized Content)
* **유연한 타입 표현력**
  타입 별칭은 단순히 객체의 형태를 정의하는 것을 넘어 유니온 타입, 교집합(Intersection), 매핑된 타입(Mapped Types), 조건부 타입(Conditional Types) 등 복잡한 타입 구성을 표현하는 데 매우 적합합니다 [1, 4, 5]. 값이 특정 원시 타입이거나 튜플, 혹은 `Record<string, unknown>`과 같은 특수한 유틸리티 타입일 때 이를 간결하게 명명하는 역할을 수행합니다 [1, 6].

* **인터페이스(Interface)와의 구조적 차이**
  타입 별칭은 인터페이스와 목적이 겹치는 부분이 많으나 핵심적인 차이가 존재합니다. 가장 큰 차이는 **선언 병합(Declaration Merging)**의 지원 여부입니다. 인터페이스는 동일한 이름으로 여러 번 선언하면 자동으로 하나로 병합되지만, 타입 별칭은 동일한 이름을 재선언하면 컴파일 에러를 반환합니다 [2, 3]. 이 특성 때문에 외부에서 확장해야 하는 라이브러리 코드에는 인터페이스가 유리하지만, 예기치 않은 타입 확장을 막아야 하는 애플리케이션 수준의 비즈니스 로직에는 타입 별칭이 더 안전한 선택이 될 수 있습니다 [2, 3, 7].

* **컴파일 성능 및 동작 방식**
  TypeScript 컴파일러는 인터페이스를 처리할 때 해당 이름을 기준으로 평탄화된 단일 객체 타입을 만들고 타입 관계를 캐싱합니다 [8, 9]. 반면, 타입 별칭을 통한 교집합 타입(`&`)은 참조될 때마다 매번 속성을 재귀적으로 병합하고 충돌을 확인해야 하므로 대규모 프로젝트에서는 컴파일 성능 저하의 원인이 될 수 있습니다 [8, 9]. 따라서 TypeScript 성능 가이드에서는 가능하면 교집합보다는 인터페이스 상속(extends)을 사용할 것을 권장하고 있습니다 [8, 10]. 

* **실무적 사용 전략**
  이러한 특성들로 인해, 개발자들 사이에서는 어떤 것을 기본으로 사용할지에 대한 논쟁과 다양한 전략이 존재합니다 [11, 12]. 
  - **이원화 전략**: 확장 지점이 필요한 외부와의 계약(Contract)이나 다형성을 띠는 도메인 모델에는 인터페이스를 사용하고, 확장이 필요 없는 내부 비즈니스 로직이나 단순 형태 선언에는 타입 별칭을 사용하는 전략입니다 [3, 13].
  - **단일화 전략**: 팀 내 혼란("이 경우에는 어떤 걸 써야 하지?")을 방지하기 위해 더 다채로운 표현이 가능하고 선언 병합의 부작용이 없는 타입 별칭만으로 코드베이스를 통일하는 팀도 다수 존재합니다 [4, 6, 14].

## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.

## 🔗 지식 연결 (Graph)
- **Related Topics:** , [[유니온 타입 (Union Types)]], [[구조적 타이핑 (Structural Typing)]], [[선언 병합 (Declaration Merging)]]
- **Projects/Contexts:** [[대규모 TypeScript 프로젝트의 컴파일 성능 최적화]], [[견고한 도메인 모델 및 API 계약 설계]]
- **Contradictions/Notes:** TypeScript 핸드북 및 성능 가이드라인은 컴파일러의 캐싱 이점과 성능 최적화를 이유로 객체 확장 시 교집합을 사용하는 타입 별칭보다 인터페이스 상속(extends)을 사용할 것을 권장합니다 [8-10]. 하지만 실무 현장에서는 의도치 않은 선언 병합을 방지하고 유연성을 얻고자 린팅(Linting) 규칙을 통해 인터페이스 사용을 아예 금지하고 타입 별칭(Type Alias)만을 전면적으로 사용하는 개발 팀들도 많아 명확한 대립이 존재합니다 [4, 6, 15].

---
*Last updated: 2026-04-18*
- Raw Source: [[00_Raw/2026-04-20/타입 별칭 (Type Alias).md]]
---

## 🤖 LLM 활용 힌트 (How to Use This Knowledge)

**언제 이 지식을 쓰는가:**
- *(TODO)*

**언제 쓰면 안 되는가:**
- *(TODO)*

## 🧪 검증 상태 (Validation)

- **정보 상태:** needs_review
- **출처 신뢰도:** A
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*

## 🧬 중복 검사 (Duplicate Check)

- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
- **처리 방식:** UPDATE (자동 정규화)
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.

## 🕓 변경 이력 (Changelog)

| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|------|-----------|-----------|--------|
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |

## 💻 코드 패턴 (Code Patterns)

**패턴 1:** *(TODO: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*

```text
# TODO
```

## 🤔 의사결정 기준 (Decision Criteria)

**선택 A를 써야 할 때:**
- *(TODO)*

**선택 B를 써야 할 때:**
- *(TODO)*

**기본값:**
> *(TODO)*

## ❌ 안티패턴 (Anti-Patterns)

- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*