[TYPESCRIPT] 타입 단순화 전략: 과도한 타입 설계를 멈추는 판단 기준

TypeScript를 깊이 사용하기 시작하면, 어느 순간 이런 고민을 하게 됩니다. “이 타입 설계가 정말 필요한가, 아니면 내가 과하게 만든 것인가?”

 

실무에서는 다음과 같은 장면이 자주 반복됩니다.

• 타입은 정교한데, 코드를 읽는 데 시간이 오래 걸린다
• 타입을 고치면 연쇄적으로 에러가 터진다
• 새로운 요구사항보다 타입 정리가 더 힘들다
• 타입 안정성은 높아졌지만 개발 속도는 느려졌다

 

타입은 많을수록 좋은 것이 아닙니다. 이번 글에서는 “타입을 더 쓰자”가 아니라, 언제 멈추고, 언제 단순화해야 하는지를 판단하는 실무 기준을 정리합니다.

 

개념/배경 설명: 타입 과설계는 왜 생기는가

타입 과설계는 보통 나쁜 의도에서 시작되지 않습니다. 오히려 대부분은 좋은 의도에서 출발합니다.

• 실수를 미리 막고 싶다
• 확장에 대비하고 싶다
• 미래의 변경을 걱정한다

 

문제는 이 “미래”가 명확하지 않을 때 발생합니다. 존재하지 않는 요구사항을 대비하다 보면, 타입은 현실보다 앞서 나가게 됩니다.

 

실무에서 중요한 질문은 이것입니다.

• 이 타입은 실제 실패를 하나라도 막고 있는가?
• 아니면 가능성만 대비하고 있는가?

 

실패를 막지 못하는 타입은 줄인다

가장 먼저 점검해야 할 것은 “이 타입이 어떤 실수를 막아주는가”입니다.

 

// 과한 예시
type ApiResult<T, E, M> = {
  ok: boolean;
  data?: T;
  error?: E;
  meta?: M;
};

 

이 타입은 유연해 보이지만, 실제로는 아무것도 강제하지 않습니다.

• ok가 true인데 error가 존재할 수 있다
• data와 error가 동시에 없을 수 있다

 

이 경우 타입이 많아도 실수는 그대로 남습니다. 차라리 구조를 단순하게 고정하는 편이 낫습니다.

 

실무 포인트 정리

• 실패를 막지 못하는 타입은 의미가 약하다
• 제네릭 개수보다 제약 조건이 중요하다

 

“미래 확장”을 이유로 타입을 늘리지 않는다

실무에서 가장 위험한 말 중 하나는 “나중에 필요할 수도 있으니까”입니다.

 

타입은 확장을 쉽게 하지만, 확장을 무료로 만들어주지는 않습니다.

• 확장 지점이 늘어난다
• 변경 영향 범위를 예측하기 어려워진다
• 실제 변경이 왔을 때 오히려 더 고치기 힘들다

 

실무 기준은 명확합니다.

• 이미 존재하는 요구사항만 모델링한다
• 한 번이라도 쓰인 규칙만 타입으로 고정한다

 

도메인 타입은 항상 가장 단순해야 한다

타입 과설계가 가장 위험한 지점은 도메인 모델입니다.

 

// 피해야 할 패턴
type Entity<TId, TState, TMeta> = {
  id: TId;
  state: TState;
  meta: TMeta;
};

 

이 타입은 재사용성을 얻는 대신, 도메인의 의미를 잃습니다.

 

도메인 타입은 다음 기준을 지켜야 합니다.

• 제네릭 없이도 의미가 명확한가
• 비개발자에게 설명할 수 있는가
• 문서처럼 읽히는가

 

타입 변경 비용을 기준으로 판단한다

좋은 판단 기준 중 하나는 “이 타입을 바꿀 때 얼마나 많은 파일이 깨지는가”입니다.

 

타입 변경 하나로

• 수십 개 파일이 동시에 에러가 난다면
• 변경 이유보다 수정 비용이 더 커진다면

 

그 타입은 이미 경계를 넘었을 가능성이 큽니다.

 

운영/실무에서 자주 겪는 문제

• 타입 수정이 기능 수정보다 어려운 경우
• 한 타입 변경으로 광범위한 핫픽스가 필요한 경우
• 타입을 이해하지 못해 any로 우회하는 코드
• 결국 타입을 신뢰하지 않게 되는 팀 분위기

 

이 단계에 이르면, 타입은 안전망이 아니라 장애물이 됩니다.

 

실무 권장 체크리스트

• 이 타입이 막아주는 실제 실수가 있는가
• 현재 요구사항만 표현하고 있는가
• 도메인 타입이 제네릭 없이 읽히는가
• 타입 변경 비용이 합리적인 수준인가
• 팀원이 타입을 신뢰하고 사용하는가

 

---

 

좋은 타입 설계는 많은 타입을 만드는 것이 아니라, 필요한 만큼만 만드는 것입니다.

타입은 복잡성을 숨기는 도구가 아니라, 복잡성을 드러내는 도구입니다. 언제 단순화해야 하는지를 아는 것이, 고급 TypeScript 실력의 중요한 기준입니다.