TypeScript tsgo로 재편되는 타입 검사와 빌드 툴체인

TypeScript tsgo의 Go 네이티브 컴파일러 구조와 타입 검사·트랜스파일 분리, 모노레포 및 CI 빌드 전략을 정리한다.

2026-08-14 · 최초 발행 2026-08-02

Go 네이티브 컴파일러가 바꾸는 빌드 경계

2026년 6월 18일 Microsoft가 공개한 TypeScript 7.0 RC는 기존 TS/JS(Strada) 컴파일러를 Go로 옮긴 네이티브 바이너리다. 타입 체크는 6.0 대비 약 10배 빨라졌지만, 실무에서 더 큰 변화는 타입 검증과 트랜스파일을 분리하는 빌드 구성이 권장 경로로 자리 잡았다는 데 있다.

CI/CD와 모노레포에서는 tsgo --noEmit을 타입 검사에 두고 esbuild·SWC 같은 도구를 JS 방출과 번들링에 병행하는 방식이 중심이 된다.

  • Project Corsa는 기존 JS 코드베이스를 파일 단위로 Go로 이식했으며, 타입 체크 의미론은 6.0과 구조적으로 동일하게 유지한다.
  • VS Code 약 40만 라인 코드베이스에서 빌드는 약 77초에서 약 7초로 줄었다. Sentry는 133초에서 16초, Playwright는 9.3초에서 1.24초 수준 사례가 제시됐다.
  • 대형 저장소 기준 메모리는 약 2.9배 절감된 것으로 보고됐다.
  • RC는 npm install -D typescript@rc로 설치하며 CLI는 기존 tsc를 그대로 사용한다. 베타와 나이틀리에서는 @typescript/native-previewtsgo 바이너리를 제공한다.
  • LSP 기반 언어 서버는 멀티스레드로 처리하며, 실패하는 LSP 커맨드는 6.0 대비 20배 이상 줄었다.
  • GA는 RC 이후 약 한 달 내 출시될 예정이지만 확정된 일정은 아니다.

병렬 타입 체크를 구성하는 방식

기존 tsc는 단일 스레드 JS 엔진 위에서 실행돼 대형 저장소에서 CPU 코어를 충분히 활용하지 못했다. tsgo는 Go의 고루틴과 공유 메모리 모델을 사용해 이 제약을 해소한다.

--checkers는 기본 4개의 병렬 체커를 사용한다. 각 워커는 독립적인 타입 뷰를 유지해 중복을 피하면서 결정론적인 결과를 보장한다. 프로젝트 레퍼런스 단위 병렬화는 --builders가 담당하며, 모노레포에서는 패키지별 빌드를 동시에 처리할 수 있다.

--checkers 4 --builders 4를 함께 쓰면 이론상 최대 16개의 타입 체커가 동시에 동작한다. 다만 리소스 과소비가 생길 수 있으므로 코어 수에 맞춰 조정해야 한다. 디버깅이나 리소스 제약 환경에는 --singleThreaded 순차 실행 모드가 있다.

incremental: true를 설정하면 .tsbuildinfo 캐시를 활용할 수 있다. tsgo는 기존 tsc가 만든 tsbuildinfo도 재사용하므로 점진적인 전환 부담을 줄인다.

아니오아니오소스 (.ts / .tsx)파서 (병렬 파싱)프로젝트 레퍼런스?빌더 (--builders N)단일 프로젝트체커 (--checkers M)타입 체크 (Go 고루틴 / 공유메모리)--noEmit?진단 결과만 출력.d.ts / .js 방출

타입 검증과 방출을 분리하는 빌드 파이프라인

tsgo의 속도가 높아져도 타입을 제거하기만 하는 esbuild·SWC의 트랜스파일 속도와는 역할이 다르다. 타입 검사와 트랜스파일을 분리하는 이유가 여기에 있다.

  • 타입 정확성 검증과 .d.ts 생성은 tsgo --noEmit 또는 tsc --noEmit이 맡는다.
  • esbuild·SWC·Oxc는 타입을 검증하지 않고 제거(strip)한 뒤 JS를 방출한다. 검증을 하지 않는 특성이 속도의 원천이다.
  • CI에서는 타입 체크 잡과 번들 잡을 병렬로 실행할 수 있다. 모듈러 저장소에서 CI 시간이 20~40% 절감된 사례가 있다.
  • tsgo는 tsc --noEmit이 병목일 때 효과가 있다. 프레임워크 라우트 생성, lint, 테스트 기동, 번들링이 느린 경우에는 tsgo만으로 해결되지 않는다.
있음없음소스 코드tsgo --noEmit (타입 검증 +.d.ts)esbuild / SWC(트랜스파일·번들)타입 오류?JS 번들 산출물CI 실패 게이트통과배포 아티팩트

도구별로 보장하는 범위

속도만으로 도구를 나열하면 역할 차이가 사라진다. 타입 검증을 보장하는 도구는 tsgo와 tsc뿐이며, 나머지는 트랜스파일·번들·린트·포맷 영역을 맡는다.

도구 언어 역할 타입 검증 대표 속도 지표
tsgo (TS 7.0) Go 타입 체크 + 방출 보장 6.0 대비 약 10배, VS Code 77→7초
tsc (TS 6.x) JS 타입 체크 + 방출 보장 기준선(baseline)
esbuild Go 번들·트랜스파일 미검증 10k 파일 ESM 약 180ms
SWC Rust 트랜스파일 미검증 10k 파일 약 193ms
Oxc Rust 트랜스파일·린트 미검증 10k 파일 약 47ms
Biome Rust 린트·포맷(+트랜스파일 일부) 미검증 린트·포맷 통합 단일 바이너리

tsgo는 느린 타입 체크를, esbuild·SWC·Oxc는 느린 방출을 대체한다. Biome는 lint와 format을 통합한다. 역할이 겹치지 않기 때문에 조합해서 사용하는 구성이 맞는다.

모노레포에서 캐시 경계를 활용하기

대형 모노레포일수록 효과가 크다. 40만 라인 이상에서는 헤드라인의 10배 수준이 제시됐고, 소규모 저장소에서는 2~5배 수준이다.

프로젝트 레퍼런스와 tsgo -b를 함께 쓰면 레퍼런스가 캐시 경계를 만들고 tsgo가 각 단계의 속도를 높인다. 22개 패키지 저장소에서 CI가 11분에서 약 3분으로 줄어든 사례가 있다.

stableTypeOrdering을 활성화하면 6.0에서 깨끗하게 컴파일되던 코드는 7.0에서도 동일하게 컴파일된다. 타입 체크 의미론의 동일성은 호환성 검증 비용을 낮춘다.

incremental: trueskipLibCheck: true를 사용하면 변경되지 않은 프로젝트를 건너뛸 수 있으며, 30초에서 3초로 줄어든 사례가 있다. 초대형 저장소에서는 Turborepo·Nx·moon을 tsgo -b 위에 두고 크로스 머신 캐시를 공유할 수 있다.

CI에서 타입 검사 시간을 다루는 방법

타입 체크만 수행하는 tsgo --noEmit 잡을 번들·테스트 잡과 분리하면 병렬 실행이 가능하다. 프로젝트 레퍼런스와 증분 캐시를 결합하면 변경된 프로젝트만 다시 검사해 PR 단위 검사 시간을 줄일 수 있다.

--checkers--builders는 CI 러너의 코어 수에 맞춰 조정해야 한다. 과도한 곱셈은 메모리 압박으로 이어질 수 있다. .tsbuildinfo를 CI 캐시에 저장해 잡 간 재사용하는 구성도 필요하다.

22패키지 저장소에서는 개발자당 주간 약 80분의 CI 시간 절감이 추정됐다. 다만 타입 체크가 병목이 아니라면 효과는 제한적이므로, 도입 전에 빌드 단계별 프로파일링으로 느린 지점을 확인해야 한다.

Sources

TypeScripttsgo빌드 툴체인모노레포CI/CD