TypeScript 7.0 Project Corsa: Go로 재작성한 컴파일러가 빌드 속도를 10배 끌어올리는 이유
TypeScript를 쓰면서 tsc --noEmit 결과를 기다리며 커피 한 잔 마시고 온 경험이 있으신가요? 대형 모노레포에서 타입 체크 한 번 돌리는 데 1분이 넘어가면, 솔직히 "그냥 any 쓸까" 하는 유혹이 들기도 하죠. 그 답답함을 Microsoft가 꽤 근본적인 방법으로 해결했습니다. TypeScript 컴파일러 전체를 JavaScript에서 Go 언어로 완전히 재작성한 것입니다.
2025년 3월, TypeScript 창시자 Anders Hejlsberg가 직접 발표한 이 프로젝트의 내부 코드명은 "Corsa"입니다. 두 버전이 병렬로 개발되다 보니 타임라인이 조금 독특한데, 2026년 1월에 TypeScript 7.0 베타가 출시되었고, 같은 해 3월에는 기존 JS 기반 컴파일러의 마지막 버전인 TypeScript 6.0이 정식 배포되었습니다. 핵심은 단 하나인데, TypeScript 언어 문법은 단 한 줄도 바뀌지 않으면서 컴파일러 내부 구현만 교체해 빌드 속도를 약 10배 끌어올렸다는 점입니다.
이 글에서는 Project Corsa가 정확히 무엇을 바꾼 것인지, 지금 당장 써볼 수 있는지, 그리고 실무 도입 전에 알아둬야 할 함정은 무엇인지를 실제 벤치마크 데이터와 함께 살펴봅니다.
핵심 개념
컴파일러 전체를 갈아엎었는데 문법은 그대로?
처음 소식을 들었을 때 저도 "그럼 Go 코드를 써야 하나?"라고 잠깐 헷갈렸는데, 전혀 그렇지 않습니다. 바뀐 것은 .ts 파일을 처리하는 도구 쪽이고, 개발자가 작성하는 TypeScript 코드 자체는 100% 동일합니다.
구체적으로 Go로 교체된 부분은 이렇습니다.
| 컴포넌트 | 역할 | 변경 여부 |
|---|---|---|
| Parser | 소스 코드 → AST 변환 | Go로 재작성 |
| Binder | 심벌 테이블 구성 | Go로 재작성 |
| Type Checker | 타입 오류 검사 | Go로 재작성 |
| Emitter | JS 코드 출력 | Go로 재작성 (부분 진행 중) |
| Language Service | IDE 자동완성·에러 표시 | Go로 재작성 |
.ts / .tsx 문법 |
개발자가 쓰는 언어 | 변경 없음 |
tsconfig.json |
컴파일러 설정 | 일부 기본값만 변경 |
| 제네릭, 유틸리티 타입 | TypeScript 언어 기능 | 변경 없음 |
"왜 Go인가?" Microsoft는 Rust, C# 등 여러 언어를 검토했습니다. 최종적으로 Go를 선택한 이유는 경량 goroutine 기반의 동시성 모델, GC 지원(메모리 관리 부담 감소), 그리고 기존 JS 코드베이스를 포팅하기 용이한 언어 특성 때문이었습니다. 자세한 논의는 Why Go? — microsoft/typescript-go Discussion #411에서 확인할 수 있습니다.
10배라는 숫자는 어디서 나왔나
공식 발표에서는 약 10배 향상을 핵심 수치로 내세웁니다. 언어 전환 자체에서 오는 네이티브 실행 속도 향상에, Go의 goroutine 기반 병렬 처리가 더해진 결과입니다.
여기서 goroutine이 생소하게 느껴지실 수 있는데, 간단히 설명하면 이렇습니다. JavaScript는 단일 스레드 기반이라 타입 체크를 파일 단위로 순차 처리해야 하는 반면, Go는 goroutine이라는 경량 동시성 단위를 수천 개 띄워 여러 파일을 동시에 병렬 분석할 수 있습니다. 현대 멀티코어 CPU를 온전히 활용할 수 있게 된 셈입니다.
측정 기준을 나눠서 보면 더 구체적입니다. VS Code 소스코드(약 150만 줄) 기준으로, 언어 서버(Language Server) 초기 로딩 시간은 9.6초 → 1.2초로, 전체 타입 체크 시간은 약 77초 → 약 7.5초로 줄었다고 공식 발표에서 밝혔습니다. 전자는 에디터에서 프로젝트를 열 때 느끼는 반응 속도이고, 후자는 CI나 커맨드라인에서 전체 체크를 실행할 때의 시간입니다. 두 수치가 달라 보이는 건 측정 대상이 다르기 때문입니다.
메모리 사용량도 3~4배 감소했는데, 이는 CI 비용과 직결됩니다. 타입 체크 때문에 메모리가 큰 인스턴스를 써야 했다면 의미 있는 절약이 될 수 있습니다.
버전 전략: 6.x는 '브리지 릴리스'
버전 번호가 헷갈릴 수 있어서 정리해드립니다. 두 버전이 동시에 개발되다 보니 타임라인이 조금 독특합니다.
- TypeScript 7.0 베타: 2026년 1월 출시 — Go 기반 컴파일러의 첫 공개 버전
- TypeScript 6.0 정식: 2026년 3월 출시 — 기존 JS 기반 컴파일러의 마지막 버전
6.0은 7.0으로의 마이그레이션을 돕는 브리지 역할입니다. deprecated 옵션들을 정리하고 breaking change를 미리 소화시켜, 7.0으로 안전하게 넘어갈 수 있는 중간 발판을 제공합니다. 7.0으로 마이그레이션하려면 6.0을 먼저 거치는 것을 권장하는 이유가 여기에 있습니다.
6.0에서 바뀌는 주요 기본값도 미리 확인해두시면 좋습니다.
// TypeScript 6.0 기준 tsconfig.json 주요 기본값 변경
{
"compilerOptions": {
"strict": true, // 이제 기본값 true (기존엔 false)
"module": "esnext", // 기본값 변경
"target": "es2025", // 기본값 변경
"types": [] // 기본값 빈 배열로 변경
}
}strict: true가 기본값이 된다는 건 새 프로젝트에서는 반갑지만, 기존 프로젝트를 마이그레이션할 때 예상치 못한 타입 오류가 쏟아질 수 있으니 미리 준비해두시면 좋습니다.
실전 적용
예시 1: 프리뷰 설치하고 속도 직접 확인해보기
지금 당장 기존 프로젝트에서 속도 차이를 체감해볼 수 있습니다. @typescript/native-preview 패키지를 사이드 바이 사이드로 설치하는 방식으로, 기존 tsc를 건드리지 않고 실험해볼 수 있습니다.
# 프리뷰 패키지 설치 (pnpm/yarn 사용 시 동일하게 대체 가능합니다)
npm install --save-dev @typescript/native-preview
# 버전 확인
npx tsgo --version
# 타입 체크 실행 (emit 없이)
npx tsgo --noEmit실제로 저도 중간 규모 프로젝트(약 3만 줄)에서 돌려봤는데, 체감상 3~4배 정도 빨라지는 느낌이었습니다. 공식 벤치마크 수치들을 보면 대형 프로젝트일수록 효과가 더 커집니다.
아래는 공식 발표 자료(A 10x Faster TypeScript)에 포함된 주요 프로젝트 벤치마크입니다.
| 프로젝트 | 기존 tsc | tsgo | 속도 향상 |
|---|---|---|---|
| VS Code (150만 줄) | ~77초 | ~7.5초 | ~10x |
| tRPC | — | — | 9.1x |
| TypeORM | — | — | 13.5x |
| 9,292 파일 JSX 코드베이스 | ~72초 | ~7초 | ~10x |
예시 2: CI/CD 파이프라인에 병행 전략 적용하기
프리뷰 단계에서 권장하는 방식은 tsgo와 기존 typescript를 함께 유지하는 것입니다. 아직 기능 완전성이 100%가 아니기 때문에, tsgo에서 놓친 오류를 기존 tsc가 잡아줄 수 있습니다.
// package.json
{
"scripts": {
"typecheck": "tsgo --noEmit", // 새 네이티브 컴파일러 (빠름)
"typecheck:legacy": "tsc --noEmit", // 폴백용 기존 컴파일러
"typecheck:ci": "tsgo --noEmit && tsc --noEmit" // CI에서 둘 다 돌리기 (첫 번째 실패 시 즉시 중단)
},
"devDependencies": {
"typescript": "^6.0.0",
"@typescript/native-preview": "latest"
}
}CI에서는 두 체크를 별도 step으로 분리해 각각의 결과를 독립적으로 확인할 수 있습니다.
# GitHub Actions 예시 — step을 분리하면 두 결과를 각각 리포트로 확인할 수 있습니다
- name: Type check (native)
run: npx tsgo --noEmit
- name: Type check (legacy fallback)
run: npx tsc --noEmit로컬 개발에서는 tsgo로 빠른 피드백을 받고, CI에서는 두 가지를 모두 돌려서 안전망을 유지하는 방식입니다. package.json의 typecheck:ci는 &&로 연결되어 첫 번째 커맨드 실패 시 즉시 중단되는 반면, GitHub Actions의 별도 step 방식은 두 결과를 각각 확인할 수 있다는 차이가 있습니다. 운영 방식에 맞게 선택하시면 됩니다. 기능이 안정화된 이후에는 typecheck:legacy를 제거하면 됩니다.
예시 3: IDE 연동 설정
VS Code를 쓴다면 마켓플레이스에서 "TypeScript (Native Preview)" 확장을 설치하면 됩니다. 확장이 설치되면 자동으로 네이티브 언어 서버가 활성화되어 별도 설정 없이 바로 체감할 수 있습니다. JetBrains WebStorm은 2025.2 버전부터 tsgo 언어 서버를 공식 지원합니다.
언어 서버(Language Server) 란 IDE에 자동완성, 타입 오류 표시, 코드 탐색 기능을 제공하는 백그라운드 프로세스입니다.
tsgo는 타입 체크뿐 아니라 이 언어 서버 역할도 Go로 재구현했기 때문에, 에디터에서의 자동완성 응답 속도도 눈에 띄게 빨라집니다.
장단점 분석
제가 실제로 가장 걱정한 건 Compiler API 호환성이었는데, 결국 기존 tsc와 병행하는 방법으로 당장은 해결했습니다. 하지만 ESLint 플러그인이나 ts-morph 같은 도구를 쓰고 계신다면, 안정화까지 시간이 더 걸릴 수 있다는 점도 미리 알아두시면 좋을 것 같습니다.
장점
| 항목 | 내용 | 활용 방안 |
|---|---|---|
| 압도적 빌드 속도 | 대형 코드베이스에서 최대 10배 빠름. 빌드 대기 시간이 분 → 초 단위로 단축 | CI에서 tsgo --noEmit을 주 체크로 전환 |
| 메모리 절약 | 3~4배 메모리 감소로 CI 인스턴스 비용 절감, 에디터 응답성 개선 | 메모리 큰 CI 인스턴스를 다운사이징하는 기회로 활용 |
| 언어 문법 100% 호환 | .ts, tsconfig.json 기존 코드 수정 없이 적용 가능 |
기존 코드베이스에 즉시 사이드 바이 사이드로 실험 |
| 멀티코어 활용 | Go의 goroutine 기반 병렬 타입 체크로 현대 CPU를 최대한 활용 | 코어 수가 많은 빌드 머신에서 효과가 배가됨 |
| IDE 응답성 개선 | 언어 서버도 Go로 재작성되어 자동완성·오류 표시가 빠르게 동작 | VS Code 확장 설치만으로 즉시 체감 가능 |
단점 및 주의사항
솔직히 단점도 꽤 있습니다. 특히 레거시 타겟을 쓰는 프로젝트는 마이그레이션 비용이 예상보다 클 수 있습니다.
| 항목 | 내용 | 대응 방안 |
|---|---|---|
| 플러그인 API 미지원 | 기존 Compiler API 의존 린터·포매터·IDE 확장 호환 안 됨 | Corsa API 안정화까지 기존 tsc 병행 유지 |
| 레거시 타겟 제거 | target: es5, AMD·UMD 모듈, baseUrl 옵션 완전 제거 |
ts5to6 마이그레이션 도구로 자동 처리 |
| JS 특화 패턴 일부 제거 | @enum, @constructor JSDoc 태그 등 지원 중단 |
해당 패턴 사용 여부 사전 검토 필요 |
| 데코레이터 다운레벨 미지원 | es2021 이전 타겟으로의 데코레이터 컴파일 미지원 |
target: es2022 이상으로 올리거나 Babel 병행 사용 |
| emit 완전 지원 아직 진행 중 | 일부 emit 시나리오 미지원 | --noEmit 용도로만 사용하고 emit은 esbuild/Babel 활용 |
Compiler API(Strada API) 란 TypeScript가 외부 도구에 노출하는 프로그래밍 인터페이스입니다. ESLint의 TypeScript 플러그인, ts-morph 같은 코드 변환 도구, 많은 IDE 확장이 이 API를 통해 TypeScript 내부 정보에 접근합니다. Corsa는 새로운 API를 설계 중이며, 안정화 전까지 기존 Compiler API와 호환되지 않습니다.
실무에서 가장 흔한 실수
tsgo가 emit까지 대체한다고 가정하기 — 현재 프리뷰 단계에서tsgo는 타입 체크(--noEmit) 용도로 먼저 사용하는 것을 권장합니다. 번들러나 트랜스파일러는 기존 파이프라인을 유지하는 쪽이 안전합니다.- 6.0 마이그레이션 없이 7.0으로 바로 점프하려 하기 — TypeScript 7.0으로 가려면 6.0이 선행되어야 합니다.
ts5to6도구를 먼저 실행해서baseUrl제거,rootDir조정 등을 처리해두는 과정이 필요합니다. - CI에서
tsgo만 믿고 기존tsc를 바로 제거하기 — 플러그인 API 의존 도구들이 아직 완전히 호환되지 않으므로, 기능 안정성이 확인될 때까지는 두 가지를 병행하는 방식이 더 안전합니다.
마치며
TypeScript 7.0 / Project Corsa는 언어를 바꾸지 않고 도구를 바꿔서 개발 경험을 근본적으로 개선한 사례입니다. 코드 한 줄 고치지 않아도 빌드 속도가 10배 빨라질 수 있다는 건, 특히 대형 코드베이스를 운영하는 팀에게는 꽤 의미 있는 변화입니다.
지금 바로 시작해볼 수 있는 단계들을 정리해봤습니다.
- 프리뷰 패키지를 사이드 바이 사이드로 설치해 속도를 직접 체감해볼 수 있습니다.
npm install --save-dev @typescript/native-preview후npx tsgo --noEmit을 기존 프로젝트에서 실행해 비교해보시면 됩니다. package.json에"typecheck": "tsgo --noEmit"스크립트를 추가하고, 기존tsc --noEmit은typecheck:legacy로 병행 유지하는 것을 권장합니다. 이렇게 하면 안전망을 유지하면서 실험해볼 수 있습니다.- VS Code를 사용 중이라면 "TypeScript (Native Preview)" 확장을 설치해볼 수 있습니다. 에디터 내 자동완성과 오류 표시 응답 속도가 함께 개선되는 것을 체감할 수 있습니다.
- 팀 도입을 검토 중인 시니어나 테크 리드라면, 실제 코드베이스 기준으로 벤치마크를 돌려 리포트를 만들어보는 것도 좋은 방법입니다.
tsgo --noEmit과tsc --noEmit의 실행 시간을 비교해 팀 공유 자료로 활용할 수 있습니다.
참고 자료
- A 10x Faster TypeScript | Microsoft TypeScript Blog
- Announcing TypeScript Native Previews | Microsoft TypeScript Blog
- Progress on TypeScript 7 - December 2025 | Microsoft TypeScript Blog
- Announcing TypeScript 7.0 Beta | Microsoft TypeScript Blog
- Announcing TypeScript 6.0 | Microsoft TypeScript Blog
- microsoft/typescript-go | GitHub
- TypeScript (Native Preview) VS Code 확장 | VS Code Marketplace
- Why Go? — microsoft/typescript-go Discussion #411 | GitHub
- TypeScript Migrates to Go: What's Really Behind That 10x Performance Claim? | Architecture Weekly
- tsgo Released! TypeScript 7's New Compiler Installation Guide | DEV Community
- TypeScript 7.0 will be 10x faster with Go | Appwrite Blog
