목차
- TypeScript 7 베타 네이티브 컴파일러 개요
- Go 포팅이 가져온 성능 향상 원리
- CI 환경 TypeScript 7 베타 벤치마크 실측
- 성능 병목 분석 — instantiateTypeWithAlias와 GC 오버헤드
- 로컬 환경과 CI 환경 벤치마크 비교
- TypeScript 7.0 RC 마일스톤 현황
- TypeScript 7 베타 도입 전 환경별 체크리스트
- TypeScript 7 베타 벤치마크 정리와 다음 단계
TypeScript 7 베타 벤치마크 정리를 한마디로 요약하면 “10배 빠르다”가 아니라 “환경에 따라 다르다”이다. TypeScript 7이 Go로 포팅되면서 10배 성능 향상이라는 수치가 널리 퍼졌는데, 이 숫자를 그대로 CI 파이프라인에 기대하면 실망할 가능성이 높다. 322K LoC 규모 React Native 프로젝트를 GitHub Actions에서 돌렸을 때 실제 개선 폭은 28%에 그쳤다는 이슈 보고가 존재하기 때문이다. 이 글에서는 공식 발표 수치와 실측 데이터의 괴리가 왜 발생하는지, CI 환경에서 병목이 어디인지, 그리고 도입 전에 무엇을 점검해야 하는지를 분석한다.
TypeScript 7 베타 네이티브 컴파일러 개요
TypeScript 7은 기존 TypeScript 코드베이스를 Go로 포팅한 네이티브 컴파일러다. 단순히 “빨라졌다”가 아니라, 컴파일러 자체를 다른 언어로 재작성한 것이 핵심이다. npm 패키지 @typescript/native-preview로 프리뷰가 제공 중이며, VS Code 확장도 별도로 사용할 수 있다.
현재 완료된 기능과 개발 중인 기능의 경계가 명확하다. 프로그램 생성, 파싱, 타입 체크, Emit, 빌드 모드, 인크리멘탈 빌드는 완료 상태인 반면, 언어 서비스(LSP)와 Watch 모드는 아직 개발 중이다. DevOps 관점에서 이 구분이 중요한 이유는 CI 파이프라인에서 주로 쓰는 빌드·타입 체크는 이미 동작하지만, 로컬 개발 환경의 에디터 통합은 아직 불완전하다는 의미이기 때문이다.
npm install @typescript/native-preview위 패키지를 설치하면 tsgo 바이너리를 사용할 수 있게 된다. 기존 tsc 명령을 대체하는 방식이므로, CI 스크립트에서 교체 자체는 단순한 편이다. 다만 LSP가 미완성이라 에디터 자동완성이나 Sort Imports 같은 리팩터링 기능은 기대하기 어렵다.
tsgo는 Go로 컴파일된 단일 바이너리로 실행되므로 Node.js 런타임이 필요 없다. 이는 Docker 이미지 최적화 시 Node.js 레이어를 빌드 전용으로 분리할 수 있다는 의미이기도 하다.
Go 포팅이 가져온 성능 향상 원리
Go가 TypeScript 7의 구현 언어로 선택된 이유는 세 가지로 정리된다. 첫째, 기존 JS 코드베이스와 구조적 유사성이 높아 포팅 비용이 상대적으로 낮다. 둘째, 가비지 컬렉터(GC)를 언어 자체가 제공하므로 수동 메모리 관리의 부담이 없는 셈이다. 셋째, AST(Abstract Syntax Tree) 워크 같은 그래프 순회 작업에 Go의 실행 모델이 적합하기도 하다.
Anders Hejlsberg는 JS 대비 약 10배 성능 향상을 확인했으며, Go의 동시성(concurrency) 기능이 기본 컴파일 언어 이점 외에 추가적으로 약 3배 속도 향상을 기여했다고 Go 선택 배경 논의에서 밝혔다.
10배의 구성 요소 분해
이 10배 수치는 두 요인의 곱으로 구성된다.
| 요인 | 추정 기여도 | 설명 |
|---|---|---|
| 네이티브 코드 실행 | ~3.3배 | JS 인터프리터 오버헤드 제거 |
| Go 동시성 활용 | ~3배 | goroutine 기반 병렬 타입 체크 |
| 합산 효과 | ~10배 | 이상적 환경 기준 |
이 수치는 이상적인 조건에서의 측정값이라는 점을 주의해야 한다. “이상적 조건”이란 충분한 CPU 코어, 여유 있는 메모리, 낮은 GC 압력을 전제로 하는 것이다. CI 환경이 이 조건을 충족하는 경우는 드물다.
10배 성능 향상은 로컬 고성능 하드웨어에서의 측정값이다. CI 환경, 특히 공유 러너에서는 CPU·메모리 제약으로 인해 실제 개선 폭이 크게 줄어들 수 있다. 벤치마크 수치를 그대로 파이프라인 시간 추정에 적용하면 안 된다.
여기서부터가 DevOps 입장에서 중요한 부분이다. GitHub Actions CI 환경(ubuntu-latest)에서 322K LoC 규모의 React Native 프로젝트를 기준으로 측정한 결과, tsc는 79초, tsgo는 57초가 소요되었다. 개선 폭은 약 28%에 그쳤다.
이 수치는 10배와 현저한 차이가 있다. 로컬 고성능 하드웨어에서는 동일 프로젝트가 450% 빠른 결과를 보였으므로, 문제는 tsgo 자체가 아니라 CI 러너의 리소스 제약에 있다는 것이 확인되었다.
환경: GitHub Actions ubuntu-latest (공유 러너)
프로젝트: React Native, 322K LoC
tsc → 79초
tsgo → 57초
개선: 약 28% (1.39배)
비교: 로컬 고성능 하드웨어
개선: 약 450% (5.5배)GHA 러너의 리소스 제약이 병목인 이유
GitHub Actions의 ubuntu-latest 러너는 2 vCPU, 7GB RAM이 기본 사양이다. Go의 동시성이 추가 3배 속도 향상을 기여한다는 공식 설명을 감안하면, 2 vCPU 환경에서는 goroutine 병렬 처리의 이점이 거의 발현되지 않는 것이다. 동시성 기여분 3배가 사라지면 남는 것은 네이티브 코드 실행에 의한 약 3배인데, 여기에 GC 오버헤드가 겹치면서 실제로는 1.4배 수준으로 떨어지는 구조인 셈이다.
CI 파이프라인에서 tsgo 도입을 검토한다면, 러너 사양과 기대 성능의 관계를 먼저 파악해야 한다. 대형 러너(8 vCPU 이상)를 사용하는 조직이라면 개선 폭이 훨씬 클 가능성이 있지만, 기본 공유 러너로는 드라마틱한 변화를 기대하기 어렵다.
성능 병목 분석 — instantiateTypeWithAlias와 GC 오버헤드
CI 환경에서 TypeScript 7 베타 벤치마크 수치가 기대에 미치지 못한 원인은 두 가지 핵심 병목으로 좁혀진다.
instantiateTypeWithAlias — 전체 런타임의 53%
프로파일링 결과, instantiateTypeWithAlias 함수가 전체 런타임의 53.15%를 차지했다. 이 함수는 제네릭 타입 인스턴스화 과정에서 호출되는데, React Native처럼 복잡한 제네릭 체인을 가진 프로젝트에서 특히 부하가 집중된다.
이 병목은 Go 포팅 자체로는 해결되지 않는 알고리즘 수준의 문제다. 컴파일러가 아무리 빨라져도 타입 체크 로직의 복잡도가 O(n)을 초과하는 부분은 언어 전환만으로 개선되지 않기 때문이다. TypeScript 7.0 RC에서 이 부분의 최적화가 진행될지는 아직 공식 문서에 명시되어 있지 않다.
GC 오버헤드 — CPU 시간의 25.5%
Go의 GC가 CPU 시간의 25.5%를 소모한 것으로 확인되었다. Go의 GC는 low-latency를 지향하지만, 컴파일러처럼 대량의 AST 노드를 할당·해제하는 워크로드에서는 GC 빈도가 높아질 수밖에 없다.
프로파일링 결과 요약 (GHA ubuntu-latest):
instantiateTypeWithAlias 53.15% ← 타입 인스턴스화 병목
GC (가비지 컬렉션) 25.50% ← 메모리 관리 오버헤드
기타 21.35%Go 런타임은 `GOGC` 환경변수로 GC 빈도를 조절할 수 있다. 기본값은 100이며, 값을 높이면 GC 빈도가 줄어들어 처리량이 증가하는 대신 메모리 사용량이 늘어나게 된다. CI 러너의 메모리 여유가 있다면 `GOGC=200` 정도로 설정해볼 수 있으나, tsgo가 이 환경변수에 정상 반응하는지는 공식 문서에 명시되어 있지 않다.
로컬 환경과 CI 환경 벤치마크 비교
TypeScript 7 베타 벤치마크에서 가장 큰 교훈은 환경 차이에 따른 성능 편차가 극심하다는 점이다. 동일한 322K LoC 프로젝트에서 환경만 달라져도 결과가 전혀 다르게 나온다.
| 항목 | 로컬 (고성능) | CI (GHA ubuntu-latest) |
|---|---|---|
| 개선 배율 | ~450% (5.5배) | ~28% (1.39배) |
| CPU 코어 | 8+ 코어 | 2 vCPU |
| 메모리 | 16GB+ | 7GB |
| 동시성 활용 | goroutine 완전 활용 | 제한적 |
| GC 압력 | 낮음 (메모리 여유) | 높음 (메모리 제약) |
| 적합 용도 | 로컬 빌드, 개발 환경 | PR 체크, 배포 파이프라인 |
이 표에서 드러나는 패턴은 단순하다. CPU 코어 수와 메모리가 충분할수록 tsgo의 이점이 살아나고, 리소스가 제한될수록 기존 tsc와의 격차가 좁아지는 것이다.
CI 환경별 예상 시나리오
GitHub Actions 대형 러너(8 vCPU, 32GB RAM)를 사용하는 조직이라면 로컬 벤치마크에 가까운 결과를 기대할 수 있다. 반면 GitLab CI의 공유 러너나 Jenkins의 소규모 에이전트를 사용하는 환경이라면 GHA 기본 러너와 유사하게 제한적인 개선에 그칠 가능성이 높다.
자체 호스팅 러너(self-hosted runner)를 운영하는 경우, 물리 서버의 코어 수를 tsgo 벤치마크의 핵심 변수로 보아야 한다. 2코어 VM에서 8코어 VM으로 전환하는 것이 tsc에서 tsgo로 전환하는 것보다 더 큰 효과를 낼 수도 있는 셈이다.
VS Code(400K LoC), Sentry 등 대규모 프로젝트의 벤치마크 수치(89→8.74초, 메모리 2.9배 감소 등)는 Microsoft 공식 블로그에만 존재하며, 독립적으로 검증 가능한 소스에서는 확인되지 않는다. 이 수치를 인용할 때는 출처의 한계를 인지해야 한다.
TypeScript 7.0 RC 마일스톤 진행 상황을 보면, 2026-05-02 기준으로 45% 완료 상태다. Open 이슈 33개, Closed 28개로 아직 절반 이상이 남아 있다.
주요 미완성 항목은 에디터 기능과 Declaration Emit 두 영역으로 집약된다.
에디터 기능과 Declaration Emit
Sort Imports, Move to file 리팩터링 같은 에디터 기능이 아직 미구현 상태다. 이는 LSP 개발이 진행 중이라는 앞서의 설명과 일치하는 부분이다. Declaration Emit 관련 버그와 크래시 수정도 남은 과제에 포함되어 있다.
CI 파이프라인 관점에서 Declaration Emit 버그는 주의가 필요하다. 라이브러리 패키지의 .d.ts 파일 생성이 CI에서 이루어지는 경우, tsgo로 전환하면 기존 tsc와 다른 결과물이 나올 수 있기 때문이다. 릴리스 날짜가 아직 미정이므로, 프로덕션 파이프라인 마이그레이션 일정은 RC 안정화 이후로 잡는 것이 안전하다.
TypeScript 6.0에서 7.0으로 마이그레이션할 때 제거되는 deprecated 옵션 목록에 대한 공식 문서는 현재 접근이 불가능한 상태다. 이 부분은 RC가 확정된 이후 별도로 확인이 필요하다.
릴리스 타임라인 추정
공식 릴리스 날짜는 미정이지만, 마일스톤 완료율 45%와 남은 이슈의 성격(에디터 기능, 크래시 수정)을 감안하면, RC까지는 상당한 기간이 소요될 것으로 보인다. 인크리멘탈 빌드와 Watch 모드의 성능 벤치마크 데이터도 공식 문서에 아직 없으므로, 이 기능들의 안정성 검증은 별도 일정이 필요한 상황이다.
현재 tsgo는 프리뷰 단계이므로, 프로덕션 CI 파이프라인에 즉시 적용하는 것은 권장되지 않는다. RC 마일스톤이 90% 이상 완료되고, Declaration Emit 버그가 해결된 시점에서 스테이징 환경 도입을 시작하는 편이 합리적이다.
CI 파이프라인에 tsgo를 실험적으로 적용해보려는 경우, 아래 항목을 사전에 점검해야 한다.
첫째, 러너 사양 확인이다. 2 vCPU 환경에서는 28% 개선이 최선일 수 있다. 러너 코어 수를 4개 이상으로 확보할 수 있는지 먼저 파악하는 것이 우선이다. tsgo의 동시성 이점은 코어 수에 비례하여 증가하므로, 러너 업그레이드 비용과 빌드 시간 절감 효과를 비교해야 한다.
둘째, 프로젝트의 제네릭 복잡도 파악이다. instantiateTypeWithAlias가 전체 런타임의 53%를 차지한 사례는 React Native처럼 제네릭 체인이 깊은 프로젝트에서 나온 결과이다. 제네릭 사용이 적은 프로젝트라면 이 병목 비중이 낮아져 개선 폭이 더 클 수 있다.
셋째, Declaration Emit 호환성 검증이다. .d.ts 파일을 CI에서 생성하는 패키지라면, tsgo가 tsc와 동일한 결과를 내는지 diff로 비교해야 한다. RC 마일스톤에 Declaration Emit 버그가 남아 있으므로 이 부분은 특히 주의가 필요하다.
넷째, 기존 tsc 스크립트와의 호환성이다. tsconfig.json의 모든 옵션이 tsgo에서 동일하게 동작하는지 확인해야 한다. TypeScript 6.0에서 deprecated된 옵션이 7.0에서 제거될 가능성이 있으나, 공식 문서에 해당 목록이 명시되어 있지 않은 상태다.
다섯째, 마이그레이션 후 빌드 시간 모니터링 체계 수립이다. tsgo로 전환한 뒤에는 기존 tsc 기준의 알림 임계값을 그대로 유지하면 안 된다. 빌드 시간이 단축된 만큼 이상 감지 기준도 재설정해야 하며, 프로젝트 규모가 커질수록 instantiateTypeWithAlias 비중이 다시 증가할 수 있으므로 주기적인 프로파일링 점검이 필요하다.
TypeScript 공식 Playground에서 ts=7.0-beta 파라미터로 TypeScript 7.0 베타 Playground를 직접 테스트할 수 있다. 다만 이 Playground 정보의 검증 여부는 확인되지 않았으므로, 실제 동작은 로컬 설치로 확인하는 것이 정확하다.
TypeScript 7 베타 벤치마크 정리와 다음 단계
TypeScript 7 베타 벤치마크 정리의 핵심은 “환경이 성능을 결정한다”는 한 문장으로 압축된다. 10배 빠르다는 공식 수치는 고성능 로컬 환경에서의 측정값이며, CI 공유 러너에서는 28% 개선에 그칠 수 있다. 그 원인은 instantiateTypeWithAlias의 알고리즘 병목(53.15%)과 Go GC 오버헤드(25.5%)가 리소스 제약 환경에서 증폭되기 때문이다.
도입을 고려하는 시점은 RC 마일스톤이 충분히 안정화된 이후가 적절하다. 현재 45% 완료 상태에서 에디터 기능, Declaration Emit, 크래시 수정 등이 남아 있으므로, 성급한 프로덕션 전환보다는 스테이징 환경에서 벤치마크를 자체 측정하는 것이 합리적인 접근 방식이다.
이 주제의 다음 단계로는 세 가지 방향이 있다. tsgo의 인크리멘탈 빌드와 Watch 모드가 안정화되면 로컬 개발 환경에서의 벤치마크 비교가 가능해진다. TypeScript 7 마이그레이션 시 deprecated 옵션 제거 목록이 공개되면 기존 프로젝트의 호환성 영향 분석이 필요하다. 그리고 Go GC 튜닝이 tsgo 성능에 미치는 영향도 자체 러너 환경에서 실험해볼 만한 주제다. TypeScript 7 베타 벤치마크 수치는 결국 자체 환경에서 직접 측정한 데이터만이 신뢰할 수 있다.
관련 글
- Next.js 16 새 기능 변경사항 5가지 총정리 — proxy.ts·Cache·Turbopack – Next.js 16에서 middleware가 proxy.ts로 바뀌고, Dynamic API가 전부 비동기 전용이 되었다. Turbopac…