TypeScript type과 interface 차이

interface의 선언 병합

interface는 같은 이름으로 다시 선언하면 각 선언의 멤버가 합쳐진다.
이 동작을 선언 병합이라고 한다.

interface AppConfig {
  apiUrl: string
}

interface AppConfig {
  timeout: number
}

const config: AppConfig = {
  apiUrl: 'https://api.example.com',
  timeout: 3000,
}

최종 AppConfig에는 apiUrl과 timeout이 모두 필요하다.
같은 이름의 속성을 여러 선언에 넣는다면 타입도 서로 호환되어야 한다.

interface AppConfig {
  apiUrl: string
}

interface AppConfig {
  apiUrl: number
  // 오류: 같은 이름의 속성은 같은 타입이어야 한다.
}

type은 같은 스코프에서 같은 이름으로 다시 선언할 수 없다.

type AppConfig = {
  apiUrl: string
}

type AppConfig = {
  timeout: number
}
// 오류: Duplicate identifier 'AppConfig'

선언 병합은 기존 라이브러리 타입에 속성을 보태는 모듈 확장이나 전역 타입 확장에서 특히 유용하다.
반대로 애플리케이션 내부의 닫힌 데이터 모델에서는 의도하지 않은 병합이 생길 여지도 있다.
확장 가능성이 요구사항인지부터 확인하고 interface의 열린 특성을 사용하는 편이 안전하다.

extends와 교차 타입

기존 객체 타입을 확장하는 방법도 둘 다 제공한다.
interface는 extends를 사용하고, type은 주로 & 교차 타입을 사용한다.

interface User {
  id: number
  name: string
}

interface Admin extends User {
  permissions: string[]
}

type User = {
  id: number
  name: string
}

type Admin = User & {
  permissions: string[]
}

두 Admin 예시는 모두 User의 속성과 permissions를 가진 객체를 표현한다.
겉으로 보이는 결과가 같아도 속성 이름이 충돌하면 처리 방식이 달라진다.

속성 충돌 처리의 차이

interface의 확장 관계에서 같은 속성이 서로 다른 타입을 요구하면 선언 지점에서 오류가 난다.

interface StringId {
  id: string
}

interface NumberId {
  id: number
}

interface InvalidAccount extends StringId, NumberId {}
// 오류: id 속성의 타입이 서로 같지 않다.

어떤 속성이 충돌했는지 타입을 합치는 순간 확인할 수 있다는 장점이 있다.

교차 타입은 두 조건을 그대로 동시에 만족하라고 요구한다.
그래서 서로 다른 속성 타입을 교차해도 타입 별칭 선언 자체는 만들어질 수 있다.

interface StringId {
  id: string
}

interface NumberId {
  id: number
}

type ImpossibleAccount = StringId & NumberId

declare const account: ImpossibleAccount

account.id
// id의 타입은 never

id가 string이면서 동시에 number여야 하므로 실제로 가능한 값이 없고 결과는 never가 된다.
오류가 타입을 합치는 줄이 아니라 나중에 값을 만들거나 사용할 때 드러날 수 있다는 뜻이다.

교차 타입을 여러 겹 조합할 때는 같은 이름의 속성이 서로 모순되지 않는지 확인해야 한다.
객체 계층을 확장하면서 충돌을 일찍 발견하고 싶다면 interface extends가 읽기 편한 경우가 많다.

클래스와의 관계

클래스가 따라야 할 인스턴스 구조는 interface와 객체 형태의 type 모두로 검사할 수 있다.

interface Printable {
  print(): void
}

type Serializable = {
  serialize(): string
}

class Report implements Printable, Serializable {
  print() {
    console.log('report')
  }

  serialize() {
    return JSON.stringify({ type: 'report' })
  }
}

implements를 쓴다는 이유만으로 반드시 interface를 선택할 필요는 없다.
다만 클래스 중심 설계에서 extends로 객체 계약의 계층을 드러내려면 interface가 자연스럽게 읽힐 수 있다.

실무 선택 기준

유니온, 리터럴, 튜플, 함수 타입처럼 객체 하나의 구조를 넘어서는 타입에는 type을 쓴다.
기존 타입을 조합해 새로운 타입을 만드는 작업이 많을 때도 type이 편하다.

외부에서 보강할 수 있는 공개 객체 계약이나 선언 병합이 필요한 라이브러리 타입에는 interface를 고려한다.
객체 계약의 상속 관계를 extends로 분명하게 보여주고 싶을 때도 interface가 잘 맞는다.

일반적인 내부 객체 모델은 둘 다 가능하다.
React props나 API 응답 객체라고 해서 반드시 한쪽만 정답인 것은 아니다.
이미 프로젝트가 한 가지 방식으로 일관되게 작성되어 있다면 그 규칙을 유지하는 편이 코드를 읽기 쉽다.

충돌 가능성도 선택 기준에 넣는다.
확장 과정의 속성 충돌을 선언 시점에 분명하게 확인하고 싶다면 interface extends가 유리하다.
교차 타입을 사용할 때는 충돌한 속성이 never로 좁혀질 수 있다는 점을 기억해야 한다.

정리하면 객체 모양만 필요할 때는 둘 중 익숙한 방식을 써도 된다.
객체 밖의 타입을 표현해야 하면 type, 선언을 다시 열어 확장해야 하면 interface를 고르면 된다.
둘을 합치는 과정에서는 문법보다 충돌 처리 방식까지 보고 결정하는 것이 중요하다.

참고 자료

• TypeScript Handbook: Everyday Types
• TypeScript Handbook: Object Types
• TypeScript Handbook: Declaration Merging
• TypeScript Handbook: Type Compatibility