타입스크립트의 구조적 타이핑

실무에서 타입스크립트를 1년 정도 다루며 더 깊은 이해의 필요성을 느끼던 참에 '이펙티브 타입스크립트'라는 책을 읽게 됐고 실용적인 내용이 많아 정리해두려고 합니다.

책에는 타입스크립트의 특성 중 하나인 '구조적 타이핑'이라는 개념이 자주 등장합니다.

자바스크립트가 덕 타이핑¹ (duck typing) 기반이고 타입스크립트가 이를 모델링하기 위해 구조적 타이핑을 사용함을 이해해야 합니다. 타입은 '봉인'되어 있지 않습니다.

구조적 타이핑의 가장 기본적인 특성은 값을 할당할 때 정의된 타입에 필요한 속성을 가지고 있다면 호환된다는 점입니다.

type Person = {
  name: string
};

let person: Person;

const employee = {
  name: 'Sanghyeon',
  job: 'Developer',
};

person = employee; // OK

employee는 Person 타입에 필요한 name 속성을 가지고 있기 때문에 그 외의 속성이 있더라도 person의 값으로 할당할 수 있습니다. ('잉여 속성 체크'라는 예외가 있고, 아래에서 살펴볼 예정입니다)

타입은 값의 집합

타입스크립트는 두 타입을 어떻게 비교하고 할당 가능 여부를 판단할까요?

타입을 값의 집합으로 생각하면 이해하기 편합니다(타입의 '범위').

타입을 값의 집합으로 본다면 number는 1, 2, ..., n 과 같은 무한 집합이 되고, boolean은 true, false를 값으로 갖는 유한 집합이 됩니다. 서로 다른 타입의 합은 union(|)으로 정의할 수 있습니다. 그리고 겹치는 타입은 intersection(&)으로 정의됩니다. 겹치는 타입이 없는 경우 공집합이 됩니다.

type AB = 'a' | 'b';
type BC = 'b' | 'c';
type CD = 'c' | 'd';

type ABC = AB | BC; // 'a' | 'b' | 'c'
type B = AB & BC; // 'b'
type EMPTY = AB & CD; // never

타입을 집합에 대응해보면 다음 표와 같습니다.

위의 표에 따르면 어떤 타입 T1이 T2에 할당 가능하려면 T1이 T2의 부분 집합이어야 합니다.

• 'a'라는 값은 'a' | 'b' 타입의 범위에 포함됩니다. 따라서 할당 가능합니다.
• [1, 2]라는 값은 number[] 타입의 범위에 포함됩니다. 따라서 할당 가능합니다.

여기까진 참 쉽습니다. 그런데 앞서 나온 Person 객체의 예제에 대입하면 점점 머리가 복잡해집니다.

name과 job 속성을 가진 employee는 name 속성만 가진 Person에 할당 가능합니다. 즉, employee 타입은 Person의 부분 집합이라는 의미가 됩니다. 저는 이 부분이 참 이해가 되지 않았습니다. 왜 추가 속성을 가진 객체가 부분 집합이 되는건지?

실제로 객체 타입의 연산과 추론은 아래와 같이 동작합니다.

type Person = {
  name: string;
};

type Employee = {
  job: string;
};

function union(input: Person | Employee) {
  input.name
     // ~~~~ Property 'name' does not exist on type 'Person | Employee'.
  input.job
     // ~~~~ Property 'job' does not exist on type 'Person | Employee'.
}

function intersection(input: Person & Employee) {
  input.name // string
  input.job // string
}

저는 위 문법을 접했을 때 속성을 기준으로 정반대의 결과를 예상했습니다.

타입 연산자는 인터페이스의 속성이 아닌, 값의 집합(타입의 범위)에 적용됩니다. 그리고 추가적인 속성을 가지는 값도 여전히 그 타입에 속합니다.

책에서는 위와 같이 설명되어 있어, 제 개념을 바로 잡기 위해 값의 집합으로 타입 연산하는 방법을 고민해봤습니다.

Person 타입에 할당 가능한 값의 집합:

{ name: 'Sanghyeon' }
{ name: 'Sanghyeon', extra: 'value' }
{ name: 'Sanghyeon', job: 'Developer' }
{ name: 'Sanghyeon', job: 'Developer', extra: 'value' }
그 외 `name` 필드를 가진 객체

Employee 타입에 할당 가능한 값의 집합:

{ job: 'Developer' }
{ job: 'Developer', extra: 'value' }
{ name: 'Sanghyeon', job: 'Developer' }
{ name: 'Sanghyeon', job: 'Developer', extra: 'value' }
그 외 `job` 필드를 가진 객체

Person | Employee (합집합):

유니온 연산으로 값의 집합을 모두 모아보면 항상 존재하는 필드가 없는 것을 확인할 수 있습니다.

{ name: 'Sanghyeon' }
{ name: 'Sanghyeon', extra: 'value' }
{ name: 'Sanghyeon', job: 'Developer' }
{ name: 'Sanghyeon', job: 'Developer', extra: 'value' }
{ job: 'Developer' }
{ job: 'Developer', extra: 'value' }
{ name: 'Sanghyeon', job: 'Developer' }
{ name: 'Sanghyeon', job: 'Developer', extra: 'value' }
그 외 `name` 필드를 가진 객체
그 외 `job` 필드를 가진 객체

Person & Employee (교집합):

인터섹션 연산으로 공통된 값의 집합을 추려보면 name, job 필드가 항상 존재하는 것을 확인할 수 있습니다.

{ name: 'Sanghyeon', job: 'Developer' }
{ name: 'Sanghyeon', job: 'Developer', extra: 'value' }

위와 같이 적어보니 뭔가 이해가 될듯 말듯 합니다. 수식으로도 한번 알아보겠습니다. 잊고 지내던 드모르간 법칙²을 적용해 아래와 같이 써 볼 수 있습니다.

keyof (Person | Employee) = (keyof Person) & (keyof Employee)
                          = 'name' & 'job' // never (공집합)

keyof (Person & Employee) = (keyof Person) | (keyof Employee)
                          = 'name' | 'job' // 'name' | 'job'

(책에 나온 내용이긴 하지만) 뭔가를 증명해낸 기분입니다! 이제 객체 타입 연산은 어느 정도 이해가 됐습니다.

구조적 타이핑 관점의 extends

타입스크립트에서 extends는 인터페이스의 확장 또는 제네릭의 한정자로 쓰입니다. extends 동작을 이해하기 위해 아래와 같이 인터페이스와 확장된 인터페이스 간의 관계를 살펴보겠습니다.

interface Person {
  name: string;
}

interface Employee extends Person {
  job: string;
}

const person1: Person = { name: 'Sanghyeon' };
const employee1: Employee = { name: 'Sanghyeon', job: 'Developer' };

let person2: Person;
let employee2: Employee;

person2 = employee1; // OK
employee2 = person1;
// ~~~ Property 'job' is missing in type 'Person' but required in type 'Employee'.

Person은 Employee에 할당할 수 없습니다. 반면 Employee는 Person에 할당 가능합니다. 앞서 나온 집합에 대응된 표에 따르면 Employee를 Person에 할당 가능하다는 것은 Employee가 Person의 부분 집합이 된다는 것을 뜻합니다.

이제 A extends B를 보면 A는 B의 부분 집합이다를 떠올릴 수 있습니다. 이 개념을 익히니 제네릭의 extends도 이해가 됐습니다.

interface Person {
  name: string;
}

function sort<P extends Person>(people: P[]): P[] {
  return people.sort((a, b) => a.name > b.name ? 1 : -1);
}

sort 함수의 인자는 Person 타입에 할당 가능한 타입의 배열이어야 합니다. 그래서 제네릭 선언에서의 extends는 범위를 한정하는 일종의 조건문으로 동작하게 됩니다.

잉여 속성 체크 (Excess Property Check)

구조적 타이핑 관점에서 예외 케이스가 있습니다.

타입이 명시된 변수에 객체 리터럴을 할당할 때 타입스크립트는 해당 타입의 속성이 있는지, 그리고 '그 외의 속성은 없는지' 확인합니다.

let person: Person;

person = {
  name: 'a',
  job: 'b',
// ~~~~~~~ Type '{ name: string; job: string; }' is not assignable to type 'Person'.
//         Object literal may only specify known properties, and 'job' does not exist in type 'Person'.  
};

지금까지 봤던 예제와 달리 객체 리터럴을 즉시 할당하니 속성을 엄격하게 체크하는 것을 확인할 수 있습니다. 잉여 속성 체크를 유용하게 쓸 수 있는 케이스가 몇 가지 있습니다.

선택적(optional) 속성의 오타 검증

type Person = {
  name: string;
  job?: string;
}

let person: Person;

const personWithTypo = {
  name: 'sh',
  jop: 'abc',
};

person = personWithTypo; // OK?

person = {
  name: 'sh',
  jop: 'abc',
// ~~ Object literal may only specify known properties,
//    but 'jop' does not exist in type 'Person'. Did you mean to write 'job'?
};

변수를 선언한 뒤 할당할 때는 잡지 못했던 jop이라는 선택적 속성의 오타를 잡아낼 수 있습니다. 가독성을 위해 변수로 추출해 미리 표현해두는 경우가 많은데 자주 변하는 객체인 경우 실수를 방지하기 위한 수단으로 활용해봐도 좋을 것 같습니다.

매핑된 타입을 사용해 값을 동기화하기

인터페이스에 새로운 속성을 추가할 때, 선택을 강제하도록 매핑된 타입을 고려해야 합니다.

React 컴포넌트 최적화 기법 중 props의 변화를 엄격하게 체크해 필요한 경우에만 렌더링하는 기법이 있습니다. props를 받지 않거나 원시 타입으로 구성된 경우 React.memo를 감싸는 것 만으로 대응이 가능합니다. 하지만 속성과 값이 자주 변하는 경우라면 두 번째 인자인 사용자 정의 비교 함수(custom comparison function)로 제어해야 합니다.

이 때 잉여 속성 체크 기법으로 비교 함수의 인자와 props 속성을 동기화 할 수 있습니다.

type Props = {
  x: number;
  y: number;
  radius: number;
  onClick: VoidFunction;
};

function Point(props: Props) {
  return (...);
}

const REQUIRES_UPDATE: { [k in keyof Props]: boolean } = {
  x: true,
  y: true,
  radius: true,
  onClick: false,
};

export default React.memo(Point, (prevProps, nextProps) => {
  let k: keyof Props;

  for (k in prevProps) {
    if (REQUIRES_UPDATE[k] && prevProps[k] !== nextProps[k]) {
      // 업데이트 대상 속성이고 값이 달라진 경우 다시 렌더링하기
      return false;
    }
  }

  return true;
});

REQUIRES_UPDATE 객체는 값이 변할 때 업데이트해야 하는 필드를 boolean 값으로 관리합니다. 타입 정의와 동시에 객체 리터럴로 할당하기 때문에 잉여 속성 체크 대상이 됩니다.

만약 포인트를 그릴 때 색상이 필요해졌다고 가정해보면, 아래와 같이 props 타입을 변경하게 될 것입니다.

type Props = {
  x: number;
  y: number;
  radius: number;
  color: string; // 새로운 속성 추가
  onClick: VoidFunction;
};

const REQUIRES_UPDATE: { [k in keyof Props]: boolean } = {
  //  ~~~~~~~~~~~~~~~ Property 'color' is missing in type '{ x: true; y: true; radius: true; onClick: false; }'
  //                  but required in type '{ x: boolean; y: boolean; radius: boolean; color: boolean; onClick: boolean; }'.
  x: true,
  y: true,
  radius: true,
  onClick: false, // `useCallback`이 적용된 함수라면 비교 가능
};

이 때 타입스크립트는 REQUIRES_UPDATE 객체에 새로운 속성의 업데이트 대상 여부가 설정되지 않았다고 알려줍니다. 만약 이 과정이 없었다면 color 값이 바뀌어도 UI가 업데이트되지 않는 버그가 생겼을 수도 있습니다. 잉여 속성 체크를 통해 버그를 미연에 방지할 수 있는 좋은 사례입니다.

실무에서 복잡한 컴포넌트의 렌더링 횟수를 줄이기 위해 원초적인 방법으로 속성 하나하나 체크하거나 lodash.isEqual 함수로 깊은 비교(deep equal)를 했던 적이 있었는데 위 예제와 같이 정의해두면 요구사항이 변할 때 타입 체크로 버그를 방지하고, 비교 연산 비용을 줄일 수 있습니다.

그리고 아래와 같이 제너릭 기반의 유틸 함수로 작성해 재사용 할 수 있습니다.

type Requirements<P extends object> = {
  [k in keyof Required<P>]: boolean;
};

const createMemoComparator = <P extends object>(
  requirements: Requirements<P>,
  customizer?: (prevProps: P, nextProps: P) => boolean
) => {
  return (prevProps: P, nextProps: P) => {
    let k: keyof P;

    for (k in prevProps) {
      if (requirements[k] && prevProps[k] !== nextProps[k]) {
        return false;
      }
    }
    
    if (typeof customizer === 'function') {
      return customizer(prevProps, nextProps);
    }

    return true;
  };
};

type Props = {
  x: number;
  y: number;
  radius: number;
  onClick: VoidFunction;
};

function Point(props: Props) {
  return (...);
}

export default React.memo(Point, createMemoComparator<Props>({
  x: true,
  y: true,
  radius: true,
  onClick: false,
});

마무리

타입스크립트의 구조적 타이핑에 관해 정리하며 가장 어려웠던 부분은 타입 연산을 위해 타입은 값의 집합이라는 개념을 대입시키는 과정이었습니다. 실제로 팀에 공유했을 때 이 부분의 설명이 혼동된다는 피드백이 많았습니다.

A data type provides a set of values from which an expression (i.e. variable, function, etc.) may take its values

프로그래밍 언어학에 정의된 내용임에도 동적 타입 언어인 자바스크립트에 익숙해져 있다 보니 자연스럽게 받아들이지 못하게 된 것 같습니다.

타입스크립트의 핵심 원리 중 하나인 구조적 타이핑을 다시 한번 정리해보면 아래와 같습니다.

• 자바스크립트를 모델링하기 위해 값의 형태를 기준으로 할당 여부를 결정 짓는 특성을 가짐
• 타입에 정의되지 않은 속성과 같이 포함될 수 있다는 점을 유의해야 함
• 값을 기준으로 판단하기 때문에 테스트 작성 시 mock 객체를 활용하기 쉬움
• 잉여 속성 체크는 구조적 타이핑의 예외 케이스로 객체 리터럴을 할당할 때 불필요한 속성이나 오타를 확인함