🧩 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로 만들까요?" 라고 영철이가 물어봅니다. 영호 리드는 이를 어떻게 교정해 줄까요?

✅ 정답: "영철 님, 상황에 따라 형태가 아예 달라지는 '유니언(Union)' 구조는 interface가 아니라 type으로 선언하는 게 정답입니다."

💡 상세 해설:

• 원리 설명: interface는 '하나의 고정된 객체 형태'를 묘사하는 데 특화되어 있습니다. 반면 "성공 상태 객체" | "실패 상태 객체" 처럼 둘 중 하나가 되는 유니언(OR) 타입은 오직 type 키워드로만 묶을 수 있습니다.
• 오답 피드백: "이걸 굳이 interface 하나에 몰아넣고 data?: any, errorMessage?: string 처럼 전부 옵셔널로 처리하면, 성공했는데도 에러 메시지를 체크해야 하는 지옥이 펼쳐집니다."
• 📌 핵심 기억법: 고정된 뼈대는 Interface! 이것 또는 저것(Union) 조건의 결합은 Type!

🐣 영철이의 퇴근 일기

💡 "Interface는 언제든 증축 가능한 조립식 판넬 집이고, Type은 설계도가 굳어버린 주물(Casting)이다."

오늘도 영호 리드 님의 비유에 이마를 탁 쳤다. 그동안 컨벤션 논쟁 뜰 때마다 꿀먹은 벙어리였는데, 이제 누가 물어보면 '선언 병합'이라는 고급 어휘를 쓰면서 설명할 수 있겠지? (뿌듯)
백엔드 API 모델은 interface로 쫙 맞추고, 리덕스 액션이나 컴포넌트 상태 같은 유니언 타입들은 type으로 분리하는 걸로 내일 기술 블로그에 하나 써놔야겠다. 아 목마르다, 집 가는 길에 제로 콜라 하나 사서 오늘 짠 컨벤션 문서 한 번 더 정독해야지!