LANGUAGE DOSSIER
TypeScript는 제품 팀이 커질수록 프런트엔드와 API 계약을 단단하게 붙잡아 준다
복잡한 웹 앱, BFF 서버, 설계가 자주 바뀌는 제품. 빠른 실험 속도는 유지하되 계약 오류를 줄이고 싶을 때 효율이 크다.
대형 프런트엔드 팀BFF/API 계약 팀디자인 시스템 팀
JavaScript의 민첩함을 유지하면서도 팀이 커질수록 생기는 “말 안 맞음”을 줄여 주는 언어가 TypeScript다.
Why It Works
이럴 때 특히 힘을 발합니다
계약 오류를 미리 본다
화면과 API 사이에서 필드 누락, 상태 이름 불일치 같은 문제를 배포 전에 잡을 수 있다.
도메인 용어를 코드에 남긴다
타입 이름이 곧 제품 언어가 되어 팀 회의와 개발이 더 가깝게 붙는다.
팀 확장에 유리하다
새로 합류한 개발자도 타입 선언을 따라가며 화면 흐름과 데이터 계약을 빠르게 이해할 수 있다.
Business Scenes
사업 현장에서 자주 보이는 장면
대시보드 제품
테이블, 필터, 상태 배지, 권한 분기처럼 복잡한 화면에서 데이터 계약을 안정적으로 유지할 수 있다.
BFF 서버
프런트엔드가 원하는 모양으로 응답을 조립하는 레이어에서 계약과 변환 책임을 분명히 하기에 좋다.
디자인 시스템
컴포넌트의 상태와 props 규칙을 타입으로 문서화해 팀 간 오해를 줄인다.
Workflow
팀이 움직이는 방식
- 컴포넌트보다 도메인 타입 이름을 먼저 정한다.
- API 변경은 화면 수정 전에 타입 차이부터 살핀다.
- 런타임 검증이 필요한 경계와 컴파일 타임 보장으로 충분한 경계를 구분한다.
- 타입이 너무 복잡해지면 설계가 아니라 제품 규칙이 꼬인 건 아닌지 먼저 본다.
계약이 드러나는 타입 예시
type OrderSummary = {
id: string;
total: number;
status: 'draft' | 'paid' | 'refunded';
};
function toLabel(order: OrderSummary) {
return order.status === 'paid' ? '결제 완료' : '후속 확인 필요';
}타입 이름 하나가 API 문서와 회의 언어를 동시에 정리해 줄 때가 많다.
리뷰 노트
TypeScript로 프런트와 BFF 계약을 다시 맞춘 날
제품팀이 커질수록 생기는 문제는 속도보다 용어 불일치였다. 팀은 타입 리뷰를 설계 리뷰처럼 다뤘다.