2026. 3. 29. 16:43ㆍ개발/FE
0. Intro
인턴 시절 SaaS 어드민에 새로운 기능을 추가해야 했는데, 필요한 라이브러리를 설치하는 과정에서 문제가 생겼다. 당시 프로젝트에서 사용하던 TypeScript 버전이 오래되어, 최신 라이브러리와의 호환성이 좋지 않았기 때문이다. 결국 TypeScript를 3.x에서 5.x대로 마이그레이션하게 되었다.
마이그레이션 이후 master 브랜치에 머지하고 CodePipeline에서 빌드를 확인했을 때, 속도가 눈에 띄게 빨라진 것을 체감했다. 그런데 실제로 코드에서 크게 바꾼 부분은 많지 않았다. any 타입을 좀 더 구체적인 타입으로 바꾼 정도였다.
그래서 궁금해졌다. 빌드가 빨라진 이유가 any 타입을 줄였기 때문인지, 아니면 TypeScript 컴파일러 자체의 성능이 개선된 결과인지 확인해보고 싶었다.
이 글에서는 동일한 워크로드에서 반복 측정을 수행하고, --extendedDiagnostics를 통해 내부 구간별 시간을 분해해 그 차이를 확인한다.
결론부터 말하면,
- 클린 빌드 중앙값 6.7% 단축
- 증분 빌드 중앙값 14.1% 단축
이라는 결과가 나왔다.
1. 왜 ‘성능’은 체감이 아니라 측정이 필요한가
TypeScript를 업그레이드하면 “빌드가 빨라진 것 같다”는 느낌은 쉽게 든다. 문제는 이 체감이 꽤 불안정하다는 점이다.
같은 명령을 두 번 실행해도 결과가 달라질 수 있다. tsbuildinfo 캐시, Node 모듈 로딩, OS 파일 시스템 캐시가 개입하면 실행 조건 자체가 달라지기 때문이다. 여기에 브라우저, IDE 인덱싱, 파일 동기화 같은 백그라운드 작업까지 더해지면 빌드 시간은 쉽게 흔들린다.
또 하나 중요한 점은, 우리가 말하는 “빌드 시간”이 단일 단계의 성능이 아니라는 것이다.
빌드 시간에는 다음 과정이 모두 포함된다.
- 파일 로딩
- 프로그램 생성
- 타입 체크(Check)
- 변환
- 출력(emit/print)
- 증분 캐시 판단
즉, 전체 시간이 줄었다고 해서 타입체커만 빨라졌다고 단정할 수 없다. 이번 글에서는 이 합성 지표를 분해해, 실제로 어떤 단계에서 시간이 줄었는지 확인한다.
2. 실험 환경과 워크로드
목표는 단순하다.
동일한 워크로드에서 TypeScript 버전만 바꿨을 때 어떤 차이가 발생하는지 확인한다.
그래서 코드와 설정은 그대로 유지하고, TypeScript 버전만 교체하는 방식으로 실험을 구성했다.
2.1 데모 프로젝트 구조
https://github.com/choihooo/ts-compiler
데모는 모노레포 + Project References 구조로 구성했다.
- packages/core
- 공통 타입과 유틸리티
- packages/ui
- 제네릭 컴포넌트 및 복잡한 타입 정의
- packages/app
- 실제 사용처 (대량 import)
이 구조는 core → ui → app으로 타입이 전파되는 형태다. 실제 프로젝트에서 빌드 시간이 늘어나는 패턴을 축소해서 재현했다.
2.2 측정 원칙
공정한 비교를 위해 다음 원칙을 적용했다.
- 동일 코드베이스 유지
- TypeScript 버전만 변경
- 클린 / 증분 빌드 분리
- 각 케이스 5회 반복
- 중앙값(median) 기준 비교
3. 측정 방법
측정은 두 레이어로 나눴다.
- 외부 측정: 전체 실행 시간 (
time) - 내부 분석: 컴파일러 단계별 시간 (
extendedDiagnostics)
3.1 외부 측정
/usr/bin/time -p의 real 값을 사용했다.
클린 빌드
- 캐시 제거 후 전체 빌드
- 5회 반복
증분 빌드
- 초기 빌드 후 캐시 생성
- 파일 1줄 변경
- 재빌드 (5회 반복)
3.2 내부 분석
tsc -b -v --extendedDiagnostics 사용
주요 지표:
- Parse time
- Bind time
- Check time
- Emit/print time
4. 결과 1: 실제 빌드 시간
TypeScript 5.8은 클린/증분 모두에서 더 빠르게 동작했다.
특히 증분 빌드에서 차이가 더 크게 나타났다.
4.1 클린 빌드
- TS 3.9 중앙값: 2.54s
- TS 5.8 중앙값: 2.37s
→ 6.7% 단축
4.2 증분 빌드
- TS 3.9 중앙값: 1.28s
- TS 5.8 중앙값: 1.10s
→ 14.1% 단축
4.3 요약
| 구분 | TS 3.9 | TS 5.8 | 개선율 |
|---|---|---|---|
| 클린 | 2.54s | 2.37s | 6.7% ↓ |
| 증분 | 1.28s | 1.10s | 14.1% ↓ |
5. 결과 2: 어디서 빨라졌나
이번 워크로드에서 TS 5.8의 개선은 한 곳에 집중되지 않았다.
- core/ui → Emit/print 감소
- app → Check 감소
5.1 TS 3.9
- core/ui → 출력 병목
- app → 타입체크 병목
5.2 TS 5.8 변화
- ui Emit/print: 0.36s → 0.12s
- app Check: 0.32s → 0.21s
5.3 전체 관점
- Check: 0.53s → 0.47s
- Emit: 0.83s → 0.42s
→ Emit이 절반 수준으로 감소
6. 증분 빌드가 더 빨라진 이유
증분 빌드는 두 단계로 나뉜다.
- 스킵 판단 (up-to-date)
- 필요한 부분만 빌드
핵심은 tsbuildinfo 캐시다.
- 변경 없는 프로젝트 → 스킵
- 변경된 프로젝트만 재빌드
TS 5.8에서는
- 재빌드 비용 감소
- 스킵 경로 효율 증가
이 두 가지가 동시에 작동하면서 증분에서 더 큰 개선이 나타난다.
7. Outro
이번 실험의 목적은 “빨라졌다”를 체감이 아닌 수치로 확인하는 것이었다.
결론
- 클린 빌드: 6.7% 단축
- 증분 빌드: 14.1% 단축
핵심 변화
- ui → Emit/print 감소
- app → Check 감소
즉, 단일 개선이 아니라 컴파일러 전체 파이프라인에서의 개선이 합쳐진 결과다.
실무적으로 보면 더 중요한 건 증분 빌드다.
개발자는 하루에 수십 번 빌드를 반복하기 때문이다.
그래서 TypeScript 업그레이드 효과는
CI보다 개발 루프에서 더 크게 체감된다.
'개발 > FE' 카테고리의 다른 글
| 타입 스크립트 컴파일러 동작 방식 (0) | 2026.03.17 |
|---|