타입스크립트 타입 호환성

출처 : https://toss.tech/article/typescript-type-compatibility

안녕하세요! 오늘은 타입스크립트를 사용하면서 늘 마주치지만, 막상 설명하려면 헷갈리는 '타입 호환성(Type Compatibility)'에 대해 깊이 파고들어 보려고 합니다. 마침 토스 기술 블로그에 올라온 타입스크립트의 타입 호환성, 제대로 알고 계신가요?라는 글을 읽고 큰 도움을 받아서, 제가 공부하고 이해한 내용을 바탕으로 블로그에 정리해 보기로 했습니다.

---

🤔 타입 호환성이란? 왜 중요할까?

타입스크립트에서 타입 호환성이란,  '특정 타입의 값이 다른 타입의 값으로 취급될 수 있는가?'를 판단하는 규칙입니다. 간단히 말해 A라는 타입의 변수에 B라는 타입의 값을 할당할 수 있는지 결정하는 것이죠.

let name: string = "앨리스";
let age: number = 30;

// name = age; // Error! Type 'number' is not assignable to type 'string'.

위 예제처럼 string 타입에 number를 할당할 수 없는 것은 너무나 당연해 보입니다. 하지만 타입이 객체나 함수처럼 복잡해지기 시작하면, 타입스크립트가 어떤 기준으로 호환성을 판단하는지 명확히 아는 것이 중요해집니다. 이 원리를 제대로 이해해야 예측 불가능한 타입 에러를 줄이고, 타입스크립트의 강력한 타입 추론 기능을 100% 활용할 수 있습니다.

---

🦆 핵심 원칙: 구조적 타이핑 (Structural Typing)

타입스크립트 타입 시스템의 가장 큰 특징은 구조적 타이핑을 따른다는 점입니다. 이름이 중요한 것이 아니라, 가지고 있는 속성(구조)이 중요하다는 의미입니다.

이는 흔히 '덕 타이핑(Duck Typing)'으로 비유됩니다. "오리처럼 걷고, 오리처럼 꽥꽥거린다면, 그것은 오리일 것이다."라는 말처럼요.

interface Person {
  name: string;
}

interface Developer {
  name: string;
  skill: string;
}

let person: Person;
let developer: Developer = { name: "밥", skill: "TypeScript" };

// 가능! Developer는 Person이 요구하는 'name' 속성을 가지고 있으므로.
person = developer;

// 불가능! Person은 Developer가 요구하는 'skill' 속성이 없으므로.
// developer = person; // Error! Property 'skill' is missing in type 'Person'...

위 코드에서 Developer는 Person 인터페이스를 implements 하지 않았습니다. 하지만 Developer는 Person이 필요로 하는 모든 속성(name)을 가지고 있고, 심지어 skill이라는 속성을 추가로 더 가지고 있습니다. 따라서 타입스크립트는 Developer를 Person 타입에 할당할 수 있다고 판단합니다. 더 많은 속성을 가진 타입을 더 적은 속성을 가진 타입에 할당하는 것은 안전하기 때문이죠.

✨ 잠깐! 그런데 이건 왜 에러가 날까? - 초과 속성 검사

구조적 타이핑 원칙만 생각하면 아래 코드도 문제가 없어 보입니다.

interface Person {
  name: string;
}

function greet(person: Person) {
  console.log(`Hello, ${person.name}`);
}

// 에러 발생!
// Argument of type '{ name: string; age: number; }' is not assignable to parameter of type 'Person'.
// Object literal may only specify known properties, and 'age' does not exist in type 'Person'.
greet({ name: "찰리", age: 40 });

분명 age라는 초과 속성이 있긴 하지만, Person이 요구하는 name 속성을 만족하는데 왜 에러가 날까요?

이는 타입스크립트가 객체 리터럴 에 대해 초과 속성 검사(Excess Property Checks)라는 특별한 검사를 수행하기 때문입니다. 타입스크립트는 개발자가 아마도 age 속성을 추가하려던 게 아니라, 속성 이름을 name 대신 naem처럼 오타를 냈을 가능성이 높다고 판단하고 이를 에러로 알려주는 것입니다. 일종의 안전장치인 셈이죠.

이 검사를 피하고 싶다면, 객체 리터럴을 변수에 먼저 할당하면 됩니다.

const charlie = { name: "찰리", age: 40 };
greet(charlie); // OK!

charlie 변수에 할당되는 순간 '신선한(fresh)' 객체 리터럴이 아니게 되므로, 초과 속성 검사를 건너뛰고 구조적 타이핑 규칙만으로 타입을 검사하게 됩니다.

---

🤯 가장 헷갈리는 부분: 함수의 타입 호환성

함수의 타입 호환성은 객체보다 조금 더 복잡합니다. 매개변수와 반환 타입, 두 가지를 모두 고려해야 하기 때문이죠.

1. 반환 타입 (Return Type) - 공변성 (Covariance)

반환 타입의 호환성은 객체와 비슷해서 직관적입니다. 할당하려는 함수의 반환 타입이 할당될 함수의 반환 타입보다 더 구체적인(작은) 타입이어야 합니다.

interface Person {
  name: string;
}

interface Developer extends Person {
  skill: string;
}

let personFactory: () => Person;
let developerFactory: () => Developer;

// 가능! Developer는 Person의 서브타입이므로.
personFactory = developerFactory;

// 불가능! Person은 Developer의 모든 속성을 만족하지 못하므로.
// developerFactory = personFactory;

personFactory는 Person을 반환하는 함수를 담을 변수입니다. 여기에 Developer를 반환하는 developerFactory를 할당하는 것은 안전합니다. Developer는 Person의 모든 속성을 포함하기 때문에, personFactory를 호출한 쪽에서는 기대했던 name 속성을 문제없이 사용할 수 있습니다.

이를 공변성(Covariance)이라고 합니다. 타입의 상속 관계 방향과 할당 가능성의 방향이 같다는 의미입니다.

2. 매개변수 (Parameters) - 반공변성 (Contravariance)

매개변수는 반환 타입과 정반대입니다. 할당하려는 함수의 매개변수 타입이 할당될 함수의 매개변수 타입보다 더 추상적인(큰) 타입이어야 합니다.

interface Person {
  name: string;
}

interface Developer extends Person {
  skill: string;
}

let greetPerson: (person: Person) => void;
let greetDeveloper: (dev: Developer) => void;

// 불가능!
// greetPerson = greetDeveloper;

// 가능!
greetDeveloper = greetPerson;

greetDeveloper는 Developer 타입을 인자로 받는 함수입니다. 여기에 Person 타입을 인자로 받는 greetPerson을 할당하는 것이 왜 가능할까요?

greetDeveloper 변수에 greetPerson 함수를 할당했다고 가정해 봅시다. 이제 greetDeveloper를 호출하면 실제로는 greetPerson이 실행됩니다.

// greetDeveloper 변수에는 greetPerson 함수가 담겨있다.
greetDeveloper({ name: "데이브", skill: "React" });

greetDeveloper를 호출하는 쪽에서는 약속대로 Developer 객체를 인자로 넘길 것입니다. 이 객체는 실제 실행될 greetPerson 함수로 전달됩니다. greetPerson 함수는 Person 타입의 인자를 기대하는데, Developer는 Person이 요구하는 name 속성을 가지고 있으므로 아무 문제가 없습니다.

반대의 경우를 생각해보면 왜 안되는지 명확해집니다. 만약 greetPerson 변수에 greetDeveloper 함수를 할당한다면?

// greetPerson 변수에 greetDeveloper 함수가 담겨있다고 가정 (실제로는 에러)
greetPerson({ name: "이브" });

greetPerson을 호출하는 쪽에서는 Person 객체를 넘길 것입니다. 이 객체는 실제 실행될 greetDeveloper 함수로 전달됩니다. 하지만 greetDeveloper는 skill 속성을 가진 Developer 객체를 기대했는데, Person 객체에는 skill 속성이 없으므로 런타임 에러가 발생할 수 있습니다.

이처럼 매개변수의 타입 호환성은 상속 관계의 방향과 반대이기 때문에 반공변성(Contravariance)이라고 합니다.

💡 잠깐! 이변성(Bivariance)도 있어요 tsconfig.json에서 "strictFunctionTypes": false 옵션을 사용하면 매개변수에서 공변성과 반공변성을 모두 허용하게 되는데, 이를 이변성(Bivariance)이라고 합니다. 타입 안정성을 위해 true로 설정하는 것이 강력하게 권장됩니다.

---

⛓️ 타입 호환성 제어하기: Branded Type

때로는 구조가 같더라도 의도적으로 타입을 구분하고 싶을 때가 있습니다. 예를 들어, UserId와 PostId는 둘 다 number 타입이지만, 서로 절대 섞여서는 안 되는 값입니다. 이때 Branded Type (또는 Nominal Type) 기법을 사용할 수 있습니다.

type UserId = number & { readonly __brand: "UserId" };
type PostId = number & { readonly __brand: "PostId" };

function getUserId(id: number): UserId {
  return id as UserId;
}

function getPostId(id: number): PostId {
  return id as PostId;
}

function getUser(id: UserId) {
  // ...
}

const userId = getUserId(1);
const postId = getPostId(1);

getUser(userId); // OK
// getUser(postId); // Error! Type 'PostId' is not assignable to type 'UserId'.

실제로는 존재하지 않는 __brand 속성을 타입에 추가함으로써, 같은 number 타입이라도 구조적으로 다르게 만들어 타입스크립트가 두 타입을 구분하도록 만드는 트릭입니다.

---

글을 마치며

타입스크립트의 타입 호환성, 특히 함수의 공변성과 반공변성은 처음에는 머릿속에서 그림이 잘 그려지지 않는 어려운 개념일 수 있습니다. 하지만 이 원리를 이해하고 나면 왜 타입스크립트가 특정 상황에서 에러를 발생시키는지, 그리고 어떻게 타입을 더 안전하게 설계할 수 있는지에 대한 깊은 통찰을 얻게 됩니다.

유연함과 안정성 사이에서 절묘한 균형을 잡고 있는 타입스크립트의 세계, 정말 매력적이지 않나요? 저도 이번 기회에 타입 시스템에 대해 더 깊이 공부할 수 있었습니다. 이 글이 여러분의 타입스크립트 여정에 작은 도움이 되었으면 좋겠습니다.