tsgo 직접 써봤다 — TypeScript가 Go로 다시 태어난 이유와 체감 후기

올해 초부터 프론트엔드 커뮤니티에서 가장 많이 보이는 키워드가 있다면 단연 tsgo일 것이다. TypeScript 컴파일러를 Go 언어로 재작성한 프로젝트인데, Microsoft가 "10배 빨라진다"고 발표했을 때 솔직히 반신반의했다. 마케팅 수치 아닌가 싶었다. 근데 직접 써보니까 진짜였다.

이 글에서는 tsgo가 뭔지, 왜 Go로 갈아탔는지, 그리고 실제로 설치해서 돌려본 경험을 정리해본다.

tsgo가 뭔가

tsgo는 TypeScript의 공식 네이티브 컴파일러다. 기존 tsc가 TypeScript(= JavaScript)로 작성되어 있었다면, tsgo는 같은 컴파일 로직을 Go 언어로 포팅한 것이다. Microsoft 내부에서는 "Project Corsa"라는 코드네임으로 개발되어 왔고, 2025년 5월에 처음 프리뷰가 공개됐다.

핵심은 간단하다. 컴파일러 자체의 실행 속도를 극적으로 올리는 것. TypeScript의 타입 시스템이나 문법이 바뀌는 건 아니고, 그걸 처리하는 엔진이 바뀌는 것이다.

2026년 1월 15일에 TypeScript 7.0이 정식 릴리즈되면서 tsgo가 안정화 단계에 접어들었다. 지금은 npm에서 바로 설치해서 쓸 수 있다.

왜 하필 Go인가

이 부분이 처음에 제일 궁금했다. Rust도 있고, Zig도 있는데 왜 Go?

Microsoft TypeScript 팀의 설명을 종합해보면 이런 이유들이다:

기존 코드 구조와의 호환성. tsc는 내부적으로 트리 구조의 AST를 다루는 코드가 대부분인데, Go의 구조체(struct)와 인터페이스 시스템이 기존 TypeScript 코드의 패턴을 가장 자연스럽게 옮길 수 있었다고 한다. Rust의 소유권 모델은 AST 같은 트리 구조를 다룰 때 오히려 복잡성을 추가할 수 있다는 판단이었던 것 같다.

가비지 컬렉션. 컴파일러는 수많은 임시 객체를 생성하고 버리는 작업의 연속이다. GC가 있는 언어가 이런 패턴에서 개발 생산성과 성능의 균형을 잡기 좋다.

빌드 속도와 팀 온보딩. Go는 컴파일 속도가 빠르고, 언어 자체가 단순해서 팀원들이 빠르게 적응할 수 있다. 이건 장기적으로 유지보수에 큰 이점이다.

물론 "Rust였으면 더 빨랐을 텐데"라는 의견도 있다. 순수 성능만 보면 맞는 말일 수 있다. 하지만 컴파일러 개발이라는 맥락에서 Go가 꽤 합리적인 선택이라는 건 써보면서 점점 이해가 됐다.

직접 설치해보기

설치는 놀라울 정도로 간단하다.

 

 

bash

npm install -D @typescript/native-preview

설치 후 tsgo 커맨드를 사용할 수 있다.

 

 

bash

# 버전 확인
npx tsgo -v

# 프로젝트 타입 체크
npx tsgo -p .

# 상세 진단 정보와 함께 실행
npx tsgo -p . --extendedDiagnostics

기존 tsconfig.json을 그대로 읽어주기 때문에, 별도 설정 파일을 만들 필요가 없다. 이게 의외로 감동이었다. 그냥 기존 프로젝트에 설치하고 바로 돌리면 된다.

벤치마크 — 숫자로 보는 차이

Microsoft가 공개한 공식 벤치마크부터 보자.

프로젝트코드 규모tsctsgo개선율

VS Code	150만 줄	77.8초	7.5초	10.4x
Playwright	35.6만 줄	11.1초	1.1초	10.1x
TypeORM	27만 줄	17.5초	1.3초	13.5x
date-fns	10.4만 줄	6.5초	0.7초	9.5x

VS Code 같은 대규모 프로젝트에서 77초가 7초로 줄어든 건 정말 체감이 큰 차이다.

DEV Community에 올라온 한 개발자의 자체 테스트 결과도 인상적이었다:

항목tsctsgo개선율

전체 컴파일 시간	0.28초	0.026초	10.8x
타입 검사만	0.10초	0.003초	33.3x
메모리 사용량	68,645K	23,733K	2.9x 절약

타입 검사만 놓고 보면 33배 빠른 건데, 이건 솔직히 예상 못했다.

내 사이드 프로젝트에서 돌려본 결과

공식 벤치마크가 아무리 좋아도, 내 프로젝트에서 어떤지가 중요하니까 직접 돌려봤다.

사이드 프로젝트 스펙은 대략 이렇다:

• Next.js 16 + App Router
• TypeScript strict mode
• Prisma ORM (generated types 포함)
• 전체 약 2만 줄 정도

 

 

bash

# 기존 tsc
npx tsc -p . --extendedDiagnostics
# Check time: 3.42s

# tsgo
npx tsgo -p . --extendedDiagnostics
# Check time: 0.48s

약 7배 정도 빨라졌다. 공식 벤치마크의 10배에는 못 미치지만, 프로젝트 규모가 작으니 당연한 결과다. 규모가 클수록 개선 폭이 커지는 패턴이고, 소규모 프로젝트에서는 2~7배 정도가 일반적이라고 한다.

근데 체감은 숫자 이상이다. 3초든 0.5초든 별 차이 아닌 것 같지만, IDE에서 타입 에러 피드백이 실시간에 가까워지는 느낌이 확실히 다르다. 특히 Prisma가 생성하는 타입이 꽤 무거운 편인데, 이 부분에서 타입 추론 반응이 눈에 띄게 빨라졌다.

에디터 지원 — 이게 진짜 핵심

CLI에서 컴파일이 빨라지는 것도 좋지만, 사실 개발할 때 체감에 가장 큰 영향을 주는 건 에디터의 타입 체크 속도다.

tsgo는 언어 서버(Language Server)도 포함하고 있어서, VS Code에서 네이티브 타입 체크를 바로 쓸 수 있다. 설정 방법은:

 

 

json

// .vscode/settings.json
{
  "typescript.tsdk": "node_modules/@typescript/native-preview/lib"
}

이걸 적용하면 VS Code의 TypeScript 언어 서비스가 tsgo 기반으로 돌아간다. 공식 벤치마크에 따르면 에디터 로드 시간이 VS Code 프로젝트 기준 9.6초에서 1.2초로 약 8배 개선된다.

내 프로젝트에서도 "Go to Definition" 같은 네비게이션이 확실히 반응이 좋아진 느낌이었다. 물론 플라시보일 수도 있지만, 큰 파일에서의 자동완성 지연은 확실히 줄었다.

아직 주의할 점

좋은 얘기만 하면 공평하지 않으니까 주의할 점도 적는다.

100% 호환은 아니다. 대부분의 프로젝트에서 잘 동작하지만, 엣지 케이스에서 기존 tsc와 다른 결과를 내는 경우가 아직 있다. 특히 복잡한 조건부 타입(conditional types)이나 템플릿 리터럴 타입에서 간헐적으로 차이가 발생할 수 있다.

플러그인 생태계. 기존 tsc는 transformer plugin을 지원했는데, tsgo에서 이 부분이 아직 완전히 포팅되지 않았다. 플러그인에 의존하는 프로젝트라면 마이그레이션 전에 확인이 필요하다.

incremental 빌드. --incremental 옵션은 이미 지원되지만, 일부 시나리오에서 성능 퇴화가 보고된 적 있다. GitHub 이슈를 보면 활발히 수정 중이긴 하다.

프로덕션에 바로 도입하기보다는, 로컬 개발 환경에서 먼저 써보면서 호환성을 확인하는 게 안전하다고 생각한다.

TypeScript 6 vs 7 — 뭐가 다른 건지

이 부분이 좀 헷갈릴 수 있어서 정리해둔다.

• TypeScript 6.x: 기존 JavaScript 기반 컴파일러의 마지막 메이저 버전. 기존 tsc의 진화 라인.
• TypeScript 7.x: Go 기반 네이티브 컴파일러(tsgo)가 적용된 버전. 언어 기능은 6.x와 동일하되, 컴파일러 엔진만 교체.

즉, TypeScript 7은 새로운 문법을 추가하는 게 아니라 같은 언어를 훨씬 빠르게 처리하는 새 엔진인 셈이다. 이건 Python 2 → 3 같은 브레이킹 체인지가 아니라, CPython → PyPy 같은 런타임 교체에 가까운 성격이다.

프론트엔드 생태계에 미칠 영향

tsgo 하나만 놓고 보면 "컴파일이 빨라진다" 정도의 이야기인데, 이걸 더 넓은 맥락에서 보면 프론트엔드 툴링 전반의 트렌드와 맞닿아 있다.

2024~2026년 사이에 프론트엔드 툴링은 "JavaScript로 작성된 도구를 네이티브 언어로 재작성"하는 큰 흐름을 겪고 있다:

• Turbopack (Rust) — webpack 대체
• Oxlint (Rust) — ESLint 대체
• Oxfmt (Rust) — Prettier 대체
• tsgo (Go) — tsc 대체
• Biome (Rust) — ESLint + Prettier 통합 대체

전부 같은 문제의식에서 출발한다. JavaScript 기반 도구들이 대규모 프로젝트에서 병목이 되고 있고, 네이티브 언어로 재작성하면 10배 이상의 성능 향상이 가능하다는 것.

이 도구들이 안정화되면, 대규모 모노레포에서 "빌드 30분 기다리기" 같은 고통이 상당 부분 해소될 수 있다. CI/CD 비용도 줄어들 거고.

마무리

tsgo를 직접 써보면서 느낀 건, 이게 단순히 "빨라졌다"는 이야기가 아니라는 거다. 타입 체크가 빨라지면 개발 플로우 자체가 달라진다. 타입 에러를 코드 저장하는 순간 바로 확인할 수 있으니까, "일단 쓰고 나중에 고치자"가 아니라 "바로 고치고 넘어가자"가 된다.

아직 프로덕션 빌드 파이프라인에 넣기엔 좀 이른 감이 있지만, 로컬 개발 환경에서는 지금 당장 도입해볼 만하다. 특히 Prisma처럼 자동 생성 타입이 많은 프로젝트라면 체감이 상당할 거다.

다음 글에서는 tsgo + Oxlint + Turbopack을 조합한 "2026 프론트엔드 툴링 스택"을 실제로 세팅해보는 과정을 다뤄볼 생각이다. 어디까지 갈아탈 수 있는지 궁금해서.

---

참고 자료

• A 10x Faster TypeScript — Microsoft DevBlogs
• Progress on TypeScript 7 — December 2025
• tsgo Released! Installation Guide & 10x Speedup Verification — DEV Community
• TypeScript 7.0 Go Rewrite: 10x Faster Builds in 2026 — byteiota
• Fastest Frontend Tooling Stack of 2026 — UBOS