이펙티브 타입스크립트 2판 Day 10: 타입도 테스트하고 빠지는 분기는 막는다

범위: Effective TypeScript 2판 Item 55–59

오늘의 질문: “런타임 테스트가 통과했으면 타입 설계도 안전하다고 봐도 될까?”

먼저 보는 코드

type Result =
  | { kind: "success"; value: string }
  | { kind: "error"; message: string };

function render(result: Result) {
  if (result.kind === "success") {
    return result.value;
  }

  return "다시 시도해주세요";
}

지금은 괜찮아 보입니다. 그런데 나중에 loading 상태가 추가되면 어떨까요?

type Result =
  | { kind: "success"; value: string }
  | { kind: "error"; message: string }
  | { kind: "loading" };

런타임 테스트가 success/error만 보고 있었다면 loading 누락을 놓칠 수 있습니다. 타입스크립트는 이런 변경을 알려줄 수 있지만, 코드가 그 신호를 받도록 작성되어 있어야 합니다.

타입도 테스트 대상이다

런타임 테스트는 값의 동작을 확인합니다. 하지만 타입 설계의 의도는 값으로만 드러나지 않을 때가 있습니다.

예를 들어 public API 타입을 바꿀 때 이런 것을 확인하고 싶습니다.

특정 prop 조합은 허용되어야 한다. 서로 배타적인 prop 조합은 막혀야 한다. 반환 타입이 넓어지지 않아야 한다. 잘못된 호출은 계속 컴파일 에러여야 한다.

이때는 타입 테스트가 필요합니다.

type Equal<A, B> =
  (<T>() => T extends A ? 1 : 2) extends <T>() => T extends B ? 1 : 2
    ? true
    : false;

type Expect<T extends true> = T;

type _UserIdIsString = Expect<Equal<User["id"], string>>;

실무에서는 tsd, expect-type, vitest의 타입 테스트 패턴처럼 도구를 쓸 수 있습니다. 중요한 점은 도구 이름이 아니라 타입 관계가 깨졌을 때 PR에서 실패 신호가 나야 한다는 것입니다.

@ts-expect-error는 의도한 실패를 고정한다

타입 테스트는 “이 타입이 맞다”뿐 아니라 “이 호출은 실패해야 한다”도 남깁니다.

createButton({ label: "저장", href: "/save" });

// @ts-expect-error href와 onClick은 동시에 받을 수 없다.
createButton({ label: "저장", href: "/save", onClick: () => {} });

@ts-ignore와 달리 @ts-expect-error는 에러가 사라지면 오히려 실패합니다. 그래서 타입 설계가 느슨해졌을 때 알아차리기 쉽습니다.

리뷰에서는 이런 질문을 합니다.

이 타입 변경이 허용해야 할 예시와 막아야 할 예시를 둘 다 남겼나?

타입 표시가 어려우면 API도 어려울 수 있다

복잡한 조건부 타입이나 재귀 타입을 쓰면 IDE가 보여주는 타입이 길어질 수 있습니다. 타입 표시가 길다고 무조건 나쁜 것은 아니지만, 팀원이 에러 메시지를 읽고 수정 방향을 알 수 없다면 비용이 큽니다.

type DeepReadonly<T> = {
  readonly [K in keyof T]: DeepReadonly<T[K]>;
};

이런 유틸리티는 쓸모가 있지만, 깊은 객체·순환 구조·라이브러리 타입과 만나면 에러가 어려워질 수 있습니다. Item 55–59 구간의 감각은 “타입 시스템으로 어디까지 표현할까?”를 묻습니다.

타입이 구현보다 어렵다면 한 번 멈춰야 합니다.

public API에서 정말 필요한 제약인가? 더 단순한 union이나 명시적 overload로 충분하지 않은가? 타입 테스트로 의도를 설명할 수 있는가? 에러 메시지가 소비자에게 읽히는가?

never로 빠지는 분기를 막는다

discriminated union을 쓸 때는 마지막 분기가 중요합니다.

function assertNever(value: never): never {
  throw new Error(`Unexpected value: ${JSON.stringify(value)}`);
}

function render(result: Result) {
  switch (result.kind) {
    case "success":
      return result.value;
    case "error":
      return result.message;
    default:
      return assertNever(result);
  }
}

Result에 loading이 추가되면 default의 result는 더 이상 never가 아닙니다. 컴파일러가 누락된 분기를 알려줍니다.

프론트엔드에서는 상태 모델이 계속 바뀝니다. idle, loading, success, empty, error, refreshing 같은 상태가 늘어납니다. never exhaustiveness는 “새 상태를 추가했는데 화면 분기를 안 고친” 실수를 줄여 줍니다.

코드 생성은 타입의 출처를 분명하게 한다

API 스키마, GraphQL schema, OpenAPI, Prisma schema처럼 이미 권위 있는 출처가 있다면 타입을 손으로 맞추기보다 생성하는 편이 낫습니다.

OpenAPI schema → generated client types → frontend API wrapper

좋은 코드 생성 흐름은 타입을 자동으로 만든다는 점보다, 타입의 출처가 하나로 정리된다는 점이 큽니다. 서버 계약이 바뀌면 생성 결과가 바뀌고, 프론트엔드가 그 변경을 컴파일 단계에서 봅니다.

다만 코드 생성도 만능은 아닙니다.

생성물이 너무 커서 리뷰가 어려우면 생성물과 작성 코드를 분리해야 한다. schema가 느슨하면 생성 타입도 느슨하다. 런타임 검증이 필요한 외부 입력은 여전히 검증해야 한다. 생성 스크립트가 CI에서 재현되지 않으면 로컬에서만 맞는 타입이 된다.

프론트엔드 코드 리뷰 체크리스트

이번 범위의 핵심은 타입스크립트를 더 화려하게 쓰자는 말이 아닙니다. 타입 설계도 회귀할 수 있고, public API 타입도 깨질 수 있습니다. 그래서 타입은 문서이면서 테스트 대상이고, union은 상태 모델이면서 누락 분기를 막는 계약입니다.

Day 10 타입 리뷰 퀴즈