이펙티브 타입스크립트 2판 Day 3: 타입 반복을 줄이는 리뷰 감각

객체 literal을 바로 User에 넣으면 role은 excess property로 잡힙니다. 그래서 “TypeScript 객체 타입은 선언된 필드만 허용하는구나”라고 생각하기 쉽습니다.

하지만 한 번 변수에 담기면 감각이 달라집니다.

TypeScript의 타입 시스템은 structural typing입니다. payload가 User에 필요한 필드를 가지고 있으면 할당 가능합니다. 불필요한 필드를 항상 금지하는 “정확한 객체 타입”으로 동작하는 것은 아닙니다.

리뷰 포인트는 이겁니다.

excess property check는 좋은 오타 방지 장치지만, 런타임 검증이나 정확한 스키마 검사를 대신하지 않습니다.

함수식은 전체 타입으로 잡을 때 더 잘 읽힌다

콜백이나 핸들러를 작성할 때 매개변수에만 타입을 붙이는 코드를 자주 봅니다.

이 코드만 보면 onSelect가 어떤 계약을 가진 함수인지 흐릿합니다. 반환값을 쓰는지, 비동기인지, 이벤트 핸들러인지가 타입 이름에 남지 않습니다.

전체 함수 타입을 먼저 선언하면 리뷰 질문이 쉬워집니다.

이제 return id를 추가하면 계약과 어긋나는지 바로 드러납니다. 특히 React props, API mapper, command handler처럼 “이 함수가 어떤 역할인지”가 중요한 곳에서는 전체 함수 타입이 읽기 좋습니다.

리뷰에서는 매개변수 하나의 타입보다 함수 전체의 입출력 계약을 먼저 봐야 합니다.

type vs interface: 정답보다 일관성이 먼저다

type과 interface 중 무엇을 써야 하냐는 질문은 오래된 논쟁입니다. Day 3에서 잡을 기준은 단순합니다.

중요한 것은 “둘 중 하나가 항상 옳다”가 아닙니다. 한 파일 안에서 비슷한 목적의 도메인 모델은 interface, 파생 유틸 타입은 type처럼 역할이 보이면 리뷰가 쉬워집니다.

이런 구분은 읽는 사람에게 신호를 줍니다.

readonly: 불변성 구현이 아니라 수정 금지 계약

readonly를 런타임 불변성으로 오해하면 곤란합니다.

여기서 items 프로퍼티 자체를 다른 배열로 바꾸는 것은 막을 수 있습니다. 하지만 배열 내부 변경까지 항상 원하는 수준으로 막아주는 것은 아닙니다.

배열 내용까지 읽기 전용 계약으로 만들고 싶다면 readonly string[] 또는 ReadonlyArray<string> 같은 형태를 고민해야 합니다.

프론트엔드에서는 이 차이가 큽니다. props, query result, shared cache data를 함수 내부에서 수정하면 React 렌더링이나 캐시 invalidation 추적이 어려워집니다. readonly는 “이 함수는 입력을 바꾸지 않는다”는 리뷰 가능한 계약입니다.

타입 반복 제거: DRY보다 동기화 비용 줄이기

타입 반복 제거를 단순히 DRY로만 보면 과한 추상화를 만들기 쉽습니다. 더 실용적인 이유는 동기화 비용입니다.

처음에는 괜찮아 보입니다. 그런데 description이 선택값으로 바뀌면 두 타입을 모두 수정해야 합니다. 하나만 바뀌면 mapper나 UI가 오래된 계약을 믿게 됩니다.

파생 타입을 쓰면 변화가 더 잘 전파됩니다.

입력 폼처럼 일부 필드만 다르고 나머지는 원본과 연결되어야 하는 경우도 마찬가지입니다.

물론 모든 타입을 Pick과 Omit으로만 만들면 읽기 어려워집니다. 리뷰 기준은 이렇게 잡으면 됩니다.

반복 제거의 목적은 코드 줄이기가 아니라 모델 변화가 한 곳에서 새도록 만드는 것입니다.

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

1. 객체 literal에서 잡아야 할 오타가 변수로 우회됐나

retrys 같은 오타가 함수 호출 경계에서 흐려질 수 있습니다. 필요한 곳에서는 satisfies나 명시 타입으로 객체 literal 단계의 체크를 살리는 편이 낫습니다.

이 코드는 오타를 잡아야 합니다. 단, satisfies는 “타입을 맞춘다”는 힌트이지 런타임 검증이 아닙니다.

2. 함수 계약이 이름으로 남아 있나

작은 유틸이면 괜찮습니다. 하지만 API mapper나 props callback이라면 전체 함수 타입을 붙이는 것이 더 낫습니다.

3. 입력을 수정하지 않는다는 계약이 필요한가

sort는 원본 배열을 바꿉니다. 입력을 수정하지 않는 함수라면 타입부터 이렇게 두는 편이 낫습니다.

4. 같은 필드 목록이 두 번 이상 반복되는가

반복이 보이면 바로 추상화하기보다 먼저 관계를 묻습니다.

같은 모델의 투영이면 Pick, Omit, mapped type이 후보입니다. 별도 계약이면 오히려 명시적인 이름을 유지하는 편이 안전합니다.

오늘의 정리

Day 3의 핵심은 타입 선언을 더 많이 쓰는 것이 아닙니다. 체크가 실제로 강해지는 위치에 타입을 두는 것입니다.

• excess property check는 객체 literal 오타를 잡는 데 유용하지만 정확한 런타임 객체 검증은 아니다.
• 함수는 매개변수 조각보다 전체 입출력 계약으로 볼 때 리뷰가 쉬워진다.
• type과 interface는 절대 정답보다 표현력, 확장성, 팀 일관성이 중요하다.
• readonly는 입력을 수정하지 않는다는 계약을 코드에 남긴다.
• 타입 반복 제거는 줄 수 줄이기가 아니라 모델 변화의 동기화 비용을 줄이는 일이다.

참고문헌

• Dan Vanderkam, Effective TypeScript, 2nd Edition, Item 11–15
• TypeScript Handbook, Object Types / Type Manipulation / Utility Types
• SEOJing Effective TypeScript 2판 14일 읽기 계획

리뷰 퀴즈