[TYPESCRIPT] typescript 판단 기준 요약: 주니어부터 시니어까지 흔들리지 않는 선택 가이드

 

TypeScript를 사용한 실무 경험이 쌓일수록, 기술 자체보다 더 자주 마주치는 질문이 있습니다. “이 상황에서 어디까지 타입을 써야 하는가”, “이 설계가 과한지, 부족한지 어떻게 판단해야 하는가”입니다.

 

주니어는 기준이 없어 불안하고, 시니어는 기준이 머릿속에만 있어 공유하기 어렵습니다. 결국 팀에서는 사람마다 다른 판단이 반복됩니다.

 

이번 글은 새로운 패턴이나 문법을 소개하지 않습니다. 이 시리즈 전체를 관통했던 내용을 바탕으로, TypeScript 실무에서 반복적으로 쓰이는 판단 기준을 한 번에 정리합니다. 프로젝트 초반, 코드 리뷰, 구조 리팩터링 시 바로 참고할 수 있는 기준표에 가깝습니다.

 

개념/배경 설명: TypeScript 실력은 선택의 일관성이다

TypeScript 실력이 높다는 것은 어려운 타입을 많이 아는 것이 아닙니다. 실무에서는 다음 능력이 더 중요합니다.

• 언제 타입을 강하게 써야 하는지 아는 것
• 언제 단순하게 두어야 하는지 아는 것
• 그 선택을 설명할 수 있는 것

 

그래서 이 글의 기준은 “정답”이 아니라 판단을 반복 가능하게 만드는 질문들입니다. 이 질문에 답할 수 있다면, 설계는 사람에 의존하지 않고 구조에 의존하게 됩니다.

 

이 타입은 어떤 실수를 막고 있는가

가장 먼저 던져야 할 질문은 단순합니다.

“이 타입이 없으면 어떤 실수가 발생하는가?”

 

• 실제로 한 번이라도 발생한 실수인가
• 리뷰로는 자주 놓치는 실수인가
• 운영 장애로 이어질 수 있는 실수인가

 

이 질문에 명확한 답이 없다면, 그 타입은 과설계일 가능성이 높습니다.

 

이 타입은 도메인인가, 규칙인가

타입을 설계할 때 자주 섞이는 두 개념이 있습니다.

• 도메인 타입: 비즈니스 개념
• 규칙 타입: 변환, 래핑, 흐름 제어

 

실무 기준은 명확합니다.

• 도메인 타입은 단순해야 한다
• 고급 제네릭은 규칙 타입에만 사용한다

 

도메인 타입에 제네릭이 늘어나기 시작하면, 구조를 다시 점검해야 합니다.

 

타입이 흐름을 드러내고 있는가

좋은 타입은 값을 보지 않아도 흐름이 보입니다.

 

Promise<Result<User, ServiceError>>

 

이 타입만 보고도 다음을 알 수 있습니다.

• 실패 가능성이 있다
• 실패 유형이 제한되어 있다
• 호출부에서 분기 처리가 필요하다

 

타입이 이런 정보를 주지 못한다면, 존재 이유를 다시 생각해볼 필요가 있습니다.

 

타입 변경 비용이 합리적인가

실무에서 매우 현실적인 판단 기준입니다.

 

타입 하나를 바꿨을 때,

• 수정 범위를 예측할 수 있는가
• 영향이 특정 레이어에 국한되는가
• 도메인 전체가 흔들리지 않는가

 

작은 변경에 프로젝트 전체가 흔들린다면, 그 타입은 지나치게 중심에 서 있는 것입니다.

 

팀원이 설명 없이 이해할 수 있는가

타입 설계는 개인 기술이 아니라 팀 자산입니다.

 

• 타입 이름만 보고 의도를 유추할 수 있는가
• IDE에서 따라가다 길을 잃지 않는가
• 리뷰에서 “왜 이렇게 했나요?”라는 질문이 줄어드는가

 

만약 특정 타입을 항상 설명해야 한다면, 그 타입은 구조보다 사람에게 의존하고 있습니다.

 

실무 요약 체크리스트

• 이 타입은 실제 실수를 막고 있는가
• 도메인과 규칙이 분리되어 있는가
• 성공/실패 흐름이 타입에 드러나는가
• 변경 비용이 감당 가능한 수준인가
• 팀 전체가 같은 기준으로 판단하는가

 

---

 

 

TypeScript 실무의 핵심은 더 복잡한 타입을 만드는 것이 아니라, 같은 상황에서 같은 판단을 반복하는 것입니다.

이 판단 기준들이 쌓이면, 코드는 점점 단순해지고, 리뷰는 빨라지며, 운영은 예측 가능해집니다.