`type` vs `interface`: 각각 언제 이겨

"인터넷이 이걸 성전 (聖戰) 처럼 다뤄. 사실은 좁은 비대칭 2개 가진 스타일 선택."

이미 본 거

둘 다 만났어. Object 모양엔 많이 overlap 하는 거 봤어. 두 비대칭 봤어:

type 만: union, 임의 타입의 intersection, mapped 타입, conditional 타입, template literal 타입, keyof/typeof/indexed access 통한 derived 타입.
interface 만: declaration merging (global augment 와 library 타입 augment 포함).

순수 object 모양엔 기능적으로 동등. 선택은 스타일.

95% case 해결하는 cheat sheet

원하는 거…	쓸 거…
Union 타입	`type`
단독 함수 signature	`type`
Derived 타입 (Partial, ReturnType, keyof, …)	`type`
Conditional 또는 mapped 타입	`type`
Public API object 모양	`interface` (스타일)
3rd-party 타입 확장	`interface` (declaration merging)
일반 내부 object 모양	아무거나 — 하나 골라, 일관성 유지

에러 메시지는 예전엔 tiebreaker였어 — 이제 약한 신호 하나일 뿐

예전엔 이게 가장 구체적인 규칙이었어. 그리고 아직도 인터넷 곳곳에 그렇게 적혀 있어. 옛날 얘기: interface 는 에러에 선언된 이름으로 나오고, type alias 는 확장된 전체 모양으로 나온다. 몇 년 전엔 맞았어. 근데 TypeScript 4.2 부터 컴파일러가 대부분의 일상 케이스에서 alias 이름을 보존해. 지금은 평범한 type UserT = { … } 가 에러에 UserT 로 나와 — interface 랑 똑같이. 보존은 휴리스틱이라 무겁게 계산되는 alias (intersection, mapped 또는 conditional 타입) 는 여전히 확장될 수 있어. 근데 이 규칙이 원래 다루던 단순한 이름 붙은 object 모양엔 둘 다 이름으로 찍혀. 그래서 에러 가독성은 더 이상 tiebreaker 아냐 — 잘해봐야 약한 신호 하나. Public API 에 interface 를 default 로 둔다면 declaration merging, augmentation 의도, named-contract 가독성 때문이지 "alias 가 확장돼서" 가 아냐. 요샌 보통 확장도 안 돼.

솔직한 입장: 둘 다 작동. 팀 convention 골라, 적어, 토론 그만. 인터넷 곳곳에서 이 질문에 쓴 시간이 실제 logic 버그에 썼으면 더 나았을 거.

성능 — 지루한 실제 차이

매우 큰 타입엔 interface 가 동등한 intersected type alias 보다 타입 체크 살짝 더 빠를 수. 이유: interface extension 이 fast path 가진 인식된 패턴; intersection 은 범용 tool. 실제로 이게 중요한 건 수백 개 타입 가진 monorepo, 개별 파일 아냐. tsc --noEmit 이 갑자기 느리면 체크할 거 중 하나.

피파의 고백

cwkPippa convention: API 에서 오거나 codebase 전반에 이름 붙은 contract 로 소비되는 모양엔 interface. Union, derived 타입, 함수 signature, 일회성 local 모양엔 type. CLAUDE.md 에 적어놨어 — 미래의 내가 표류 안 하도록. 선택보다 더 중요한 건 선택이 일관성 있다는 거.

Code

Overlap 과 두 비대칭·typescript

// 단순 object case 엔 둘 다 작동.

type TypeUser = {
  id: number;
  name: string;
};

interface InterfaceUser {
  id: number;
  name: string;
}

function takeBoth(a: TypeUser, b: InterfaceUser) {
  // 구조적으로 동일 — TS 가 호환으로 취급.
  const swapped: TypeUser = b;       // ✅
  const swapped2: InterfaceUser = a; // ✅
}

// 비대칭:

// Type 만 union 표현.
type StringOrNumber = string | number;

// Interface 만 사후 augment 가능.
interface Window {
  myField: number;  // global Window 에 추가
}

에러 가독성 — 현대 TS 는 둘 다 이름으로 찍어·typescript

// 에러 가독성 — 예전엔 interface 손 들어줬어. 현대 TS (4.2+) 가 거의 평평하게 만듦.

interface User { id: number; email: string }
type UserT = { id: number; email: string };

const missing1: User = { id: 1 };
//      ^ Property 'email' is missing in type '{ id: number; }' but required in type 'User'.

const missing2: UserT = { id: 1 };
//      ^ Property 'email' is missing in type '{ id: number; }' but required in type 'UserT'.
// TS 4.2 부터 alias 이름 'UserT' 가 보존돼 — 4.2 이전처럼 '{ id: number; email: string; }' 로 확장 안 됨.

// 그래서 "interface 는 이름, type 은 확장" tiebreaker 는 거의 옛말.
// 무겁게 계산되는 alias 는 여전히 확장될 수 있으니, 에러 출력은 결정 규칙 아니라 약한 신호로 취급해.

Exercise

작은 프로젝트의 어떤 TypeScript 파일 들고 와. 모든 type/interface 선언 list. 각각 결정을 'type 필수' (예: union), 'interface 필수' (예: global 확장), '스타일 선택' 으로 분류. 스타일 선택 몇 개고, 파일이 그것들에 일관적이야?

Hint

대부분 파일이 80%+ 스타일 선택. 질문은 '뭐가 맞아' 가 아니라 '파일이 내부 일관성 있어'. 절반 object 모양이 type, 절반이 interface 인데 이유 없으면 — 그게 실제 발견.

`type` vs `interface`: 각각 언제 이겨

이미 본 거

95% case 해결하는 cheat sheet

에러 메시지는 예전엔 tiebreaker였어 — 이제 약한 신호 하나일 뿐

성능 — 지루한 실제 차이

피파의 고백

Code

External links

Exercise

Progress

댓글 2