TypeScript type과 interface 차이: 선언 병합, 확장, 조합 기준으로 고르기

빠른 답

객체의 공개 구조를 점진적으로 확장해야 한다면 interface가 읽기 쉽습니다.
유니온, 튜플, 조건부 타입처럼 타입 표현식을 조합해야 한다면 type이 더 잘 맞습니다.
interface는 같은 이름으로 여러 번 선언하면 병합되지만, type은 같은 스코프에서 중복 선언할 수 없습니다.
둘의 차이는 런타임 값의 차이가 아니라 타입 검사 단계에서 허용되는 선언과 오류의 차이입니다.

한눈에 비교
둘 다 런타임 값이 아니라 타입 검사 규칙이다
interface가 강한 상황
type이 강한 상황
타입 검사를 엄격하게 보는 설정
extends와 intersection의 차이
흔한 오해
선택 기준

한눈에 비교

선언 병합

interface 는 같은 이름의 선언이 합쳐지고, type 은 중복 선언 시 오류가 납니다.

객체 확장

interface 는 extends 로 확장하고, type 은 인터섹션 & 으로 여러 타입을 조합합니다.

유니온 표현

type 은 "idle" | "loading" 같은 값의 집합을 직접 표현할 수 있고, interface 는 유니온 자체를 선언할 수 없습니다.

튜플과 계산 타입

type 은 튜플, 조건부 타입, 매핑된 타입, 유틸리티 타입과 함께 쓰기 좋습니다.

공개 API 보강

외부 라이브러리 타입이나 전역 객체를 보강해야 한다면 선언 병합이 가능한 interface 가 유리합니다.

의도하지 않은 확장 방지

타입 이름이 조용히 합쳐지면 곤란한 도메인 모델에는 중복 선언을 막는 type 이 더 예측 가능할 수 있습니다.

둘 다 런타임 값이 아니라 타입 검사 규칙이다

type과 interface는 모두 TypeScript의 타입 검사 단계에서 사용됩니다. JavaScript로 변환된 뒤에는 두 선언 모두 사라지고, 실행 중에는 실제 객체와 함수만 남습니다.

그래서 interface로 선언했다고 런타임 객체가 더 가볍거나, type으로 선언했다고 다른 형태의 값이 만들어지는 것은 아닙니다. 차이는 값이 생성되는 시점이 아니라 TypeScript가 코드를 검사할 때 어떤 타입 선언을 허용하는지에 있습니다.

interface UserInterface {
  id: string;
  name: string;
}

type UserType = {
  id: string;
  name: string;
};

const user1: UserInterface = { id: "u1", name: "Kim" };
const user2: UserType = { id: "u2", name: "Lee" };

console.log(user1.name);
console.log(user2.name);

위 코드에서 UserInterface와 UserType은 타입 검사에만 쓰입니다. 실행 결과에 영향을 주는 값은 user1, user2 객체입니다. 따라서 선택 기준은 “실행 성능”이 아니라 “타입의 의미를 어떻게 표현할 것인가”에 가깝습니다.

interface가 강한 상황

interface는 객체가 제공해야 하는 속성과 메서드의 형태를 표현할 때 잘 어울립니다. 특히 라이브러리 옵션, 서버 응답 DTO, 클래스가 구현해야 하는 계약처럼 외부에 드러나는 객체 구조를 설명할 때 의도가 분명하게 읽힙니다.

interface의 대표적인 특징은 선언 병합입니다. 같은 스코프에서 동일한 이름의 interface를 여러 번 선언하면 TypeScript는 이를 하나의 인터페이스로 합칩니다.

interface User {
  id: string;
  name: string;
}

interface User {
  email: string;
}

const user: User = {
  id: "u1",
  name: "Kim",
  email: "kim@example.com",
};

이 코드는 오류가 나지 않습니다. TypeScript는 User를 id, name, email을 모두 가진 객체 타입으로 해석합니다.

이 특징은 타입 보강이 필요한 경우에 유용합니다. 예를 들어 외부 라이브러리의 요청 객체에 프로젝트 고유 속성을 추가하거나, 전역 객체의 타입을 확장해야 하는 상황에서는 선언 병합이 확장 지점으로 작동합니다.

다만 모든 객체 타입을 선언 병합 가능하게 둘 필요는 없습니다. 여러 파일에서 같은 이름의 인터페이스가 병합되면 속성이 어디서 추가되었는지 추적하기 어려워질 수 있습니다. 공개 확장 지점이 아니라면 오히려 타입 구조가 흐려질 수 있습니다.

type이 강한 상황

type은 객체의 모양뿐 아니라 타입 표현식 전체에 이름을 붙일 수 있습니다. 이 차이 때문에 유니온, 튜플, 인터섹션, 조건부 타입처럼 값을 더 정밀하게 분류하는 모델링에 잘 맞습니다.

상태에 따라 값의 구조가 달라지는 API 결과를 예로 들면 type의 장점이 분명해집니다.

type RequestState = "idle" | "loading" | "success" | "error";

type ApiResult =
  | { state: "success"; data: string[] }
  | { state: "error"; message: string };

function render(result: ApiResult) {
  if (result.state === "success") {
    return result.data.join(", ");
  }

  return result.message;
}

RequestState는 객체가 아니라 가능한 문자열 값의 집합입니다. 이런 타입은 interface로 직접 표현할 수 없습니다.

ApiResult는 성공과 실패를 같은 객체 타입 하나로 뭉개지 않고, 상태별로 허용되는 속성을 분리합니다. state가 "success"이면 data를 읽을 수 있고, "error"이면 message를 읽을 수 있습니다. TypeScript는 조건문을 보고 타입을 좁히기 때문에 잘못된 속성 접근을 검사 단계에서 발견할 수 있습니다.

이런 방식은 값의 상태가 오류 가능성과 연결되는 코드에서 특히 유용합니다. 성공, 실패, 로딩, 빈 상태처럼 의미가 다른 값을 하나의 느슨한 객체로 다루기보다, 가능한 경우의 수를 타입으로 드러낼 수 있습니다.

타입 검사를 엄격하게 보는 설정

type과 interface의 차이는 실행 로그보다 타입 검사 결과에서 관찰됩니다. 예제를 확인할 때는 strict와 noEmit을 켜 두면 오류가 더 빨리 드러납니다.

{
  "compilerOptions": {
    "target": "ES2022",
    "module": "ESNext",
    "strict": true,
    "noEmit": true
  }
}

noEmit은 JavaScript 파일을 생성하지 않고 타입 검사만 수행하겠다는 설정입니다. 타입 설계 예제를 확인하거나 CI에서 정적 검사를 돌릴 때 사용할 수 있습니다.

명령은 다음처럼 실행합니다.

npx tsc --noEmit

같은 이름의 type을 두 번 선언하면 TypeScript는 실행 전에 오류를 냅니다.

type Config = {
  host: string;
};

type Config = {
  port: number;
};

// error TS2300: Duplicate identifier 'Config'.

이 오류는 JavaScript 런타임 예외가 아닙니다. TypeScript가 같은 스코프 안에서 동일한 타입 별칭 이름이 두 번 바인딩되었다고 알려주는 정적 검사 결과입니다.

extends와 intersection의 차이

객체 타입을 확장할 때 interface는 extends를 사용하고, type은 주로 인터섹션 &을 사용합니다. 둘 다 여러 속성을 합친 타입을 만들 수 있지만, 의미와 오류가 드러나는 방식에는 차이가 있습니다.

extends는 한 객체 계약이 다른 객체 계약을 확장한다는 의미를 잘 보여 줍니다.

interface BaseUser {
  id: string;
  name: string;
}

interface AdminUser extends BaseUser {
  role: "admin";
}

const admin: AdminUser = {
  id: "u1",
  name: "Kim",
  role: "admin",
};

이 코드는 AdminUser가 BaseUser의 속성을 포함하면서 추가로 role을 가진다는 뜻으로 읽힙니다. 클래스의 implements와 함께 쓰거나, 공개 API의 계층 구조를 표현할 때 이해하기 쉽습니다.

반면 type의 인터섹션은 여러 타입을 동시에 만족하는 값을 뜻합니다.

type BaseUser = {
  id: string;
  name: string;
};

type WithAudit = {
  createdAt: Date;
  updatedAt: Date;
};

type AuditedUser = BaseUser & WithAudit;

const user: AuditedUser = {
  id: "u1",
  name: "Kim",
  createdAt: new Date(),
  updatedAt: new Date(),
};

여기서 AuditedUser는 BaseUser이면서 동시에 WithAudit인 값입니다. 상속 계층이라기보다 타입 조각을 합성한 결과에 가깝습니다.

주의할 부분은 속성 충돌입니다. 예를 들어 string인 id와 number인 id를 인터섹션으로 합치면, 결과 타입은 두 조건을 동시에 만족해야 합니다. 현실적으로 그런 값은 만들 수 없기 때문에 해당 속성은 사용할 수 없는 타입에 가까워집니다.

이 차이 때문에 객체 계층의 일관성을 표현하려는 경우에는 extends가 읽기 쉽고, 여러 타입 조각을 계산해 새 타입을 만들려는 경우에는 인터섹션이 편합니다.

흔한 오해

interface는 객체 타입에 특화되어 있지만, 객체 타입을 반드시 interface로만 작성해야 하는 것은 아닙니다. 객체 타입도 type으로 선언할 수 있고, 많은 코드베이스가 객체 모델까지 type으로 통일하기도 합니다.

type Product = {
  id: string;
  name: string;
  price: number;
};

이 타입이 외부에서 선언 병합될 필요가 없고, 다른 유틸리티 타입과 자주 조합된다면 type으로 두는 편이 단순할 수 있습니다.

반대로 클래스가 구현해야 하는 계약을 표현한다면 interface가 문맥을 잘 전달합니다.

interface Repository<T> {
  findById(id: string): Promise<T | null>;
  save(value: T): Promise<void>;
}

class UserRepository implements Repository<{ id: string; name: string }> {
  async findById(id: string) {
    return { id, name: "Kim" };
  }

  async save(value: { id: string; name: string }) {
    console.log(value.id);
  }
}

implements는 객체 형태의 type에도 사용할 수 있습니다. 다만 interface라는 이름은 “이 객체가 따라야 하는 계약”이라는 의도를 더 직접적으로 드러냅니다.

또 다른 오해는 선언 병합을 항상 장점으로 보는 것입니다. 라이브러리 타입 보강처럼 확장 지점이 필요한 경우에는 장점이지만, 도메인 타입이 예측 가능하게 유지되어야 하는 코드에서는 의도하지 않은 확장의 통로가 될 수 있습니다.

선택 기준

type과 interface 중 하나만 일관되게 쓰는 규칙도 가능하지만, 타입의 의미에 따라 나누면 코드의 의도를 더 잘 남길 수 있습니다.

도메인 객체의 기본 형태는 둘 다 표현할 수 있으므로 팀 컨벤션을 따르는 편이 좋습니다. 외부 보강 가능성이 있는 공개 타입, 클래스가 구현해야 하는 계약, 라이브러리 API처럼 확장 가능한 객체 구조라면 interface가 잘 맞습니다.

가능한 값의 목록, 상태별 결과, 튜플, 함수 시그니처 조합, 조건부 타입, 매핑된 타입처럼 타입을 계산하거나 경우의 수를 표현해야 한다면 type이 더 넓은 표현력을 제공합니다.

중요한 차이는 런타임에 만들어지는 값이 아니라 타입 검사 단계에서 드러나는 의미입니다. 객체의 형태를 공개 계약으로 설명하는지, 상태와 오류 가능성을 유니온으로 나누는지, 여러 타입 표현식을 조합해 새 별칭을 만드는지에 따라 선택이 달라집니다.

원문 참고

https://www.maeil-mail.kr/question/58

Chart js와 amchart 비교

Chart js 특징은 위의 그림으로 대체 할 수 있을 듯 하다. 오픈 소스이고, 기본으로 제공하는 차트 종류가 8가지 Canv a s를 이용해서 차트를 그리고, 반응형을 지원한다. amchart amchart는 기본적으로 유료이며, 기본으로 제공하는 차트 종류가 기본적인 차트 + 주식 처럼 보이는 차트 + 지도에 관련된 차트(?) 까지 하면, 기본 제공 하는 종류가 20개 내외 이려나, 일일이 세기에는 양이 좀 많아 보인다. 렌더링은 svg를 통하여 그려지고, 당연 반응형도 지원이 된다. 그러면, 이 둘중에 어떤것이 내 프로젝트에 적합 하냐는 것이 문제이다. 일단, 주식 처럼 보이는 차트나 지도에 관련된 차트(?)가 필요하면, amchart를 선택해야 되는 것은 맞다. 그건 당연한 것이니 빼고 얘기 해보자! 여러 종류의 차트가 필요하다면, 일단은 amchart를 염두해 두는 것이 좋다. 돈 낸 만큼은 하는 듯 하다. 하지만, 기본적인 막대 그래프, 도넛 차트 등, 아주 기본적인 차트들인데, Chart js도 amchart도 그러한 차트가 없을 때가 문제가 된다. 그렇다면, 조금이라도 커스텀이 용이한 것을 찾는 것이 좋을 것이다. 일단 amchart에서 custom이라고 검색 하였을 때, 검색 결과가 61가지가 나온다. 차트의 종류도 많고, 각 차트마다 들어가는 속성이 매우 많기 때문에, 웬만한 내용들은 속성 값을 어떻게 주느냐에 따라서 변경이 가능 하게 된다. 커스텀의 예를 들면, 기본적으로 도넛 파이의 형태를 띄면서, 화살표로 목표를 표시해주는 차트가 필요하다고 생각 해보자. 이것은 amchart로 만든 그래프이고 이것은 chart js로 만든 그래프이다. 모양이 살짝 다르긴 하지만, 완벽하게 똑같이 구현 할 수도 있다. amchart로 만든 그래프의 경우, 저것은 도넛그래프가 아닌 guage 그래프이다. 원래 게이지 그래프는 이와 같...

코드 땜장이

이 블로그 검색