🧩 02. Interface vs Type: 영수네 커뮤니티 데이터 설계의 딜레마

📌 이 문서를 읽기 전에

⏱️ 예상 읽기 시간: 10분(전체) / 핵심 파트만: 6분

🗺️ 이 문서의 흐름
[무엇이 같고 무엇이 다른가?] → [확장(extends) vs 교차(&)의 미묘한 차이] → [실무 가이드라인 (어떨 때 뭘 쓰지?)]

🎯 이 문서를 다 읽으면 할 수 있는 것

• interface와 type의 공통점과 핵심 차이점을 설명할 수 있다.
• 객체 지향적 확장과 함수형 교차의 차이를 프로젝트 규모에 맞게 선택할 수 있다.
• 영수네 커뮤니티처럼 백엔드 API가 수시로 변하는 환경에서 어떤 설계가 유리한지 판단할 수 있다.

🗺️ 이 문서의 배경 세계관: '영수네 커뮤니티'

• 🐣 영철 ( 타입 설계 기준을 잡는 중 ): "영호 리드 님! 팀원들마다 API 응답값 타입을 정의하는 방식이 달라요. 누구는 interface를 쓰고, 누구는 type을 쓰는데, 리뷰할 때마다 '이거 통일합시다'라고 하려니 제가 명확한 기준이 없어서 말문이 막힙니다. 둘 다 객체 만드는 거 똑같지 않나요?"
• 🦁 영호 ( 리드 ): "표면적으로는 비슷해 보이지만, 깊은 곳의 철학이 다릅니다. 하나는 '변경 가능한 뼈대'를 만드는 객체 지향의 산물이고, 다른 하나는 '변하지 않는 수학적 집합'입니다. 오늘 그 미묘한 선을 그어보죠."

🤔 왜 알아야 하는가: '설계'의 출발선

interface와 type 논쟁은 프론트엔드 팀에서 탭(Tab) vs 스페이스(Space)만큼 흔한 주제입니다.

최근의 타입스크립트는 이 둘의 격차를 많이 줄여놓아서, 사실 실무에서는 80% 이상 혼용해서 써도 당장의 버그는 나지 않습니다. 하지만, 프로젝트가 커지고 외부 라이브러리를 가져와서 내 코드로 타입 확장을 시도하는 순간, 이 둘의 설계적 차이를 모르는 개발자는 벽에 부딪힙니다.

5년 차 이상의 아키텍처 레벨로 가기 위해서는 단순한 '기능 구현'을 넘어, 동료들이 확장하기 편하고 일관된 타입 설계 기준을 세울 수 있어야 합니다.

🎭 1. 공통점: 둘 다 오리(Duck)를 만들 수 있다

앞선 1강에서 배운 **구조적 타이핑(Duck Typing)**의 관점에서 보면, 두 방식은 완벽히 동일한 객체를 만들어냅니다.

// 🐣 영철: "보세요! 둘 다 완전히 똑같이 동작하잖아요!"
 
// 1. Interface 방식
interface UserInterface {
  id: number;
  nickname: string;
}
 
// 2. Type Alias 방식
type UserType = {
  id: number;
  nickname: string;
};
 
const userA: UserInterface = { id: 1, nickname: "영호" };
const userB: UserType = { id: 2, nickname: "영수" };
 
// 구조가 같으면 호환된다!
const test: UserType = userA; // ✅ 통과

심지어 서로를 상속(확장)하는 것도 가능합니다. (Interface가 Type을 extends할 수 있고, Type이 Interface와 & 교차할 수 있습니다.)
여기까지만 보면 "아무거나 쓰면 되는 거 아냐?"라는 영철이의 말이 맞아 보입니다.

⚡ 2. 결정적 차이 1: 확장 방식 (Extends vs Intersection)

가장 빈번하게 만나는 차이점은 기존 타입을 확장(상속)하여 새로운 타입을 만들 때 나타납니다.

🦁 영호의 아키텍처 설계: Interface의 상속 (extends)

객체 지향적인 방식입니다. 기존 뼈대를 기반으로 새로운 살을 붙입니다.

interface BaseComment {
  id: string;
  content: string;
}
 
// 기존 댓글에 좋아요 기능이 추가된 새로운 인터페이스
interface LikedComment extends BaseComment {
  likeCount: number;
}

특징:

1. 컴파일러가 에러 메시지를 보여줄 때, 최종 이름인 LikedComment로 깔끔하게 보여줍니다.
2. 컴파일 속도가 (미세하지만) 더 빠릅니다. TS가 객체 구조를 캐싱하고 합치는 데 최적화되어 있기 때문입니다.
3. 속성 이름이 충돌할 때, 부모와 자식 간에 엄격한 에러를 뿜어내어 실수를 막아줍니다.

🐣 영철의 조합 방식: Type의 교차 (& Intersection)

함수형이고 수학적인 접근입니다. 두 개의 집합을 하나로 뭉쳐버립니다.

type BasePost = {
  id: string;
  title: string;
};
 
// 기존 게시글 타입과 새로운 좋아요 타입을 '교집합'으로 묶음
type LikedPost = BasePost & {
  likeCount: number;
};

특징:

1. 이름 충돌이 발생했을 때 에러를 뿜지 않고, 무리하게 never 타입(존재할 수 없는 타입)을 만들어 버려 나중에 원인을 찾기 힘든 버그를 유발할 수 있습니다.
2. 에러 툴팁에서 마우스를 올렸을 때 { id: string, title: string } & { likeCount: number } 처럼 풀어서 보여주는 경우가 많아 가독성이 떨어질 수 있습니다.

🔓 3. 결정적 차이 2: 선언 병합 (Declaration Merging)

가장 중요한 차이점입니다. 영철이가 반드시 알아야 할 타입스크립트의 선언 병합 규칙입니다.

🔓 Interface: 열려있는 문 (Open)

같은 이름의 interface를 여러 번 선언하면, 타입스크립트가 알아서 하나로 합쳐줍니다(Merge).

// 🦁 영호: "외부 라이브러리(Window 객체 등)에 내가 만든 속성을 끼워넣을 때 최고죠."
 
// 1. 첫 번째 선언
interface UserProfile {
  id: number;
}
 
// 2. 다른 파일, 혹은 나중에 두 번째 선언
interface UserProfile {
  nickname: string;
}
 
// ✅ 자동으로 두 개가 합쳐짐!
const myProfile: UserProfile = {
  id: 1,
  nickname: "멋쟁이영철",
};

🔒 Type Alias: 닫혀있는 문 (Closed)

type은 한 번 짓고 나면 절대 변경할 수 없는 식별자(Alias) 입니다.

// 🐣 영철: "타입은 왜 두 번 선언하면 화를 내죠?"
 
type UserInfo = {
  id: number;
};
 
// ❌ 에러: 식별자 'UserInfo'가 중복 선언되었습니다.
type UserInfo = {
  nickname: string;
};

🎯 4. 영수네 커뮤니티 실무 가이드라인

그렇다면 영철이는 내일 팀 회의에서 어떻게 코딩 컨벤션을 픽스해야 할까요?
타입스크립트 공식 문서와 글로벌 베스트 프랙티스를 합친 영수네 커뮤니티 룰은 다음과 같습니다.

1. 객체를 정의할 때는 기본적으로 interface를 베이스로 삼는다.
   • API 응답값, 컴포넌트의 Props, 데이터베이스 스키마 모델 등은 모두 객체이므로 interface가 깔끔하고 에러 메시지도 직관적입니다.
2. type (타입 별칭)은 아래와 같은 '특수한 경우'에만 사용한다.
   • 원시값에 이름표를 붙일 때: type UserId = string;
   • 유니언 타입을 쓸 때: type Status = "IDLE" | "LOADING" | "ERROR";
   • 교차나 튜플 같은 복잡한 연산이 필요할 때: type Response = [number, string];
3. 일관성(Consistency)이 최우선이다.
   • 이미 팀이 전부 type으로 객체를 만들고 있다면, 굳이 혼자 interface로 바꾸는 투쟁을 하지 마세요. 제일 나쁜 건 한 파일 안에서 두 개를 섞어 쓰는 것입니다.

📝 마무리 퀴즈

Q1. interface와 type을 활용해 객체를 확장할 때 사용하는 키워드/연산자는 각각 무엇인가요?

✅ 정답: interface는 extends 키워드를, type은 & (Intersection) 연산자를 사용한다.

💡 상세 해설:

• interface A extends B는 객체 지향적인 상속의 개념으로, 속성 충돌 시 컴파일러가 친절하게 에러를 잡아줍니다.
• type A = B & C는 두 타입을 수학적으로 결합하는 교차 타입으로 묶입니다.

Q2. 서드파티 라이브러리(예: 전역 window 객체)나 기존에 정의된 객체의 타입을 확장하여 새로운 프로퍼티를 끼워 넣으려고 합니다. 이때는 어떤 방식을 사용해야 할까요?

✅ 정답: interface의 선언 병합(Declaration Merging)을 사용한다.

💡 상세 해설:

• type은 한 번 선언되면 스펙이 고정되지만, interface는 동일한 이름으로 열어두면 자동으로 병합(Merge)되는 특징이 있습니다.
• 이를 활용해 interface Window { myGlobalVar: string; } 처럼 기존 전역 객체에 내 커스텀 프로퍼티를 끼워넣는 기법이 실무에서 자주 쓰입니다.

Q3. [영철이의 테스트 타임: 실무 딜레마] 영철이가 백엔드 영수 님과 상의하며 API 공통 응답 포맷을 잡고 있습니다. "성공했을 때는 data가 오고, 실패했을 때는 errorMessage가 오는 구조입니다. 이걸 interface로 만들까요?" 라고 영철이가 물어봅니다. 영호 리드는 이를 어떻게 교정해 줄까요?

✅ 정답: 성공과 실패가 서로 다른 형태라면 type 유니언으로 상태를 분리한다.

💡 상세 해설:

• interface는 하나의 객체 형태를 확장하기 좋지만, "success" 상태와 "error" 상태처럼 둘 중 하나를 표현하는 유니언은 type이 필요합니다.
• type ApiResult = { status: "success"; data: Post[] } | { status: "error"; errorMessage: string }처럼 만들면 성공 분기에서는 data, 실패 분기에서는 errorMessage만 안전하게 다룰 수 있습니다.
• 모든 필드를 data?: ..., errorMessage?: ...로 한 객체에 몰아넣으면 "성공인데 data가 없을 수도 있는" 애매한 타입이 되어 실제 요구사항을 흐립니다.

🐣 영철이의 퇴근 일기

오늘은 interface와 type을 "취향 차이"로만 넘기면 안 된다는 걸 배웠다. 객체 모델을 계속 확장해야 하는 API 응답이나 Props는 interface가 읽기 좋고, 성공/실패처럼 형태가 갈라지는 값은 type 유니언이 훨씬 정확했다.

특히 선언 병합은 기억해둘 만하다. 전역 Window나 외부 라이브러리 타입을 보강할 때는 interface가 열려 있다는 점이 장점이 된다. 반대로 상태 머신이나 API 결과처럼 "이것 또는 저것"을 말해야 할 때는 type이 더 솔직한 표현이었다.

💡 "객체의 뼈대를 확장할 때는 interface, 선택지의 조합을 표현할 때는 type. 기준은 문법 취향이 아니라 데이터가 변하는 방식이다."

내일 팀 컨벤션 문서에는 "무조건 하나만 쓰자"가 아니라 "언제 어떤 기준으로 고를지"를 적어야겠다. 영철이도 이제 리뷰에서 단순 통일보다 설계 의도를 먼저 물어볼 수 있을 것 같다.