TypeScript 7 출시, Go 컴파일러로 10배 빨라졌다

타입스크립트 빌드가 느려서 저장할 때마다 기다린 적이 있다면, 2026년 7월 8일에 나온 TypeScript 7.0이 그 문제를 정면으로 겨냥한 릴리스다. 컴파일러를 Go로 다시 구현해서 전체 빌드가 8배에서 12배 빨라졌다. 다만 지금 바로 올려도 되는지는 쓰는 도구에 따라 갈린다. 이 글은 무엇이 얼마나 빨라졌는지, 그리고 누가 아직 기다려야 하는지를 정리한다.

다시 쓴 것이 아니라 옮긴 것이다

먼저 오해를 풀어야 한다. TypeScript 7.0은 언어를 바꾼 릴리스가 아니다. 타입스크립트 컴파일러와 언어 서비스를 TypeScript로 짜여 있던 것에서 Go로 포팅한 것이다. 공식 발표는 이를 "충실한 포팅"이라 표현하며 타입 검사 의미가 그대로 유지된다고 밝혔다.

이 구분이 중요한 이유는 마이그레이션 위험을 가늠하는 기준이 되기 때문이다. 언어 규칙이 바뀌었다면 코드를 고쳐야 하지만, 같은 규칙을 다른 언어로 구현한 것이라면 원칙적으로 결과가 같아야 한다. 실제로 대부분의 프로젝트는 코드 변경 없이 넘어간다.

왜 Go였나. 자바스크립트로 구현된 컴파일러는 단일 스레드에 묶이고 GC 특성상 메모리 사용이 크다. Go는 네이티브로 컴파일되고 동시성을 쉽게 쓸 수 있다. 타입 검사는 파일 단위로 병렬화할 여지가 큰 작업이라 이 선택이 맞아떨어졌다.

숫자가 꽤 구체적이다

발표에 공개된 수치는 추상적인 "몇 배 빨라짐"이 아니라 실제 프로젝트 이름과 함께 나왔다.

프로젝트	속도 향상
vscode	11.9배
sentry	8.9배
bluesky	8.7배
playwright	8.7배
tldraw	7.7배

전체 빌드 기준이고, 범위로는 8배에서 12배다. 메모리도 6%에서 26%까지 줄었다.

에디터 체감은 따로 볼 만하다. 파일을 열고 오류가 표시되기까지 걸리는 시간이 17.5초에서 1.3초로 줄었다. 13배다. 큰 모노레포에서 파일을 열 때마다 몇십 초씩 기다려 본 사람이라면 이 숫자의 의미를 안다. 언어 서버 크래시도 6.0 대비 60% 넘게 줄었다고 밝혔다.

CI 관점에서도 차이가 크다. 외부 보도에 따르면 슬랙의 CI 타입 검사가 약 7.5분에서 1.25분으로 줄었다. 타입 검사가 PR 파이프라인의 병목이던 팀이라면 이 한 줄이 전체 리드타임을 바꾼다.

공개된 수치를 그래프로 보면 편차가 한눈에 들어온다.

코드베이스가 클수록 효과가 크다는 경향이 보인다. vscode가 가장 크고, 상대적으로 작은 tldraw가 가장 낮다. 병렬화 이득은 일감이 많아야 나오기 때문으로 보인다.

바로 못 올리는 사람들이 있다

여기가 핵심이다. TypeScript 7.0은 안정적인 프로그래밍 API를 아직 제공하지 않는다. 발표는 이를 명시하고 7.1에서 제공할 예정이라고 밝혔다.

이게 왜 문제인가. 타입스크립트를 자기 컴파일러나 언어 서비스 안에 끼워 넣어 쓰는 도구들이 있다. 이들은 API가 없으면 동작할 수 없다. 발표가 직접 언급한 대상은 이렇다.

Vue, Svelte, Astro, MDX, Angular 템플릿 타입 검사, 그리고 이들이 공통으로 쓰는 Volar 기반 도구. typescript-eslint도 여기 포함된다. webpack 로더를 쓰는 프로젝트도 7.1을 기다려야 한다는 언급이 있었다.

즉 프레임워크를 쓰면 대체로 기다려야 하고, 순수 타입스크립트 프로젝트면 지금 올려도 된다. 리액트는 JSX를 타입스크립트가 직접 처리하므로 영향이 적지만, typescript-eslint를 쓰고 있다면 그쪽이 걸린다. 실제로는 린트 때문에 못 올라가는 팀이 많을 것이다.

자바스크립트 파일 취급도 달라졌다. 발표는 클로저 스타일 함수 문법과 일부 JSDoc 패턴이 더 이상 지원되지 않으며, 자바스크립트 분석이 타입스크립트 파일 분석에 더 가깝게 동작한다고 밝혔다. JSDoc으로 타입을 달아 쓰는 오래된 코드베이스라면 확인이 필요하다.

판단을 흐름도로 정리하면 이렇다.

올릴지 말지 판단하는 순서

나라면 이 순서로 확인한다.

먼저 package.json의 devDependencies를 본다. Vue, Svelte, Astro, Angular, MDX 관련 도구가 있으면 그 도구들이 7.0을 지원한다고 공지할 때까지 기다린다. 억지로 올리면 타입 검사가 아예 안 도는 상태로 CI가 통과할 수 있는데, 이게 제일 위험하다.

다음으로 typescript-eslint 사용 여부를 본다. 쓰고 있다면 역시 대기다. 린트 없이 올릴 이유는 없다.

그 둘이 없다면 브랜치를 하나 파서 올려보고 CI를 돌린다. 포팅이라 결과가 같아야 하지만, 같아야 하는 것과 같은 것은 다르다. 타입 오류 개수가 이전과 일치하는지 먼저 보고, 다르면 어떤 파일에서 갈리는지 확인한다.

마지막으로 JSDoc 기반 자바스크립트 파일이 있는지 본다. 있다면 그쪽부터 검사한다.

6.0 에서 7.0 사이에 무엇을 준비해 둘 수 있나

지금 못 올리는 팀이라도 준비는 할 수 있다. 두 가지가 효과가 크다.

하나는 타입 오류를 0으로 만들어 두는 것이다. 포팅이라 결과가 같아야 하지만, 미묘한 차이가 있다면 기존 오류에 묻혀 안 보인다. 기준선이 0이면 올렸을 때 생기는 차이가 곧바로 드러난다.

다른 하나는 tsconfig.json을 정리하는 것이다. 속도 때문에 켜둔 우회 설정이 무엇인지 목록으로 만들어 두면, 올린 뒤에 하나씩 되돌려 보며 효과를 측정할 수 있다. skipLibCheck, 프로젝트 참조 분할, incremental 캐시 같은 것들이다.

왜 Go였고, 왜 Rust나 C++이 아니었나

이 선택은 발표 당시에도 논쟁거리였다. 타입스크립트 팀이 밝힌 이유를 요약하면 세 가지다.

첫째, 기존 코드 구조를 그대로 옮기기 좋았다. 타입스크립트 컴파일러는 그래프 순회와 재귀가 많고, 가비지 컬렉션이 있는 언어를 전제로 짜여 있다. GC가 없는 언어로 옮기려면 메모리 소유권을 전부 다시 설계해야 한다. 그건 포팅이 아니라 재작성이고, 의미를 그대로 유지한다는 보장을 할 수 없게 된다.

둘째, 동시성을 쉽게 붙일 수 있었다. 타입 검사는 파일 단위 병렬화 여지가 크다. 고루틴으로 이걸 붙이는 비용이 낮았다.

셋째, 크로스 컴파일과 배포가 단순하다. 여러 플랫폼용 단일 바이너리를 만들어 npm으로 뿌려야 하는 요구에 Go가 잘 맞는다.

포팅의 충실도를 유지하는 것이 최우선이었다는 점이 핵심이다. 더 빠른 언어를 골랐다면 더 빨랐겠지만, "타입 검사 결과가 6.0과 같다"는 보장이 흔들렸을 것이다. 수백만 줄짜리 코드베이스를 가진 회사들이 올릴 수 있는 이유가 그 보장에 있다.

이 릴리스가 남기는 질문

속도가 열 배 빨라지면 개발 방식도 바뀐다. 타입 검사가 느려서 CI에서만 돌리던 팀이 저장할 때마다 돌릴 수 있게 된다. 큰 모노레포를 쪼갤 이유 중 하나였던 "빌드가 너무 느려서"가 약해진다.

그런데 나는 한 가지를 경계한다. 빠른 도구는 느슨한 설정을 감춘다. 타입 검사가 느려서 skipLibCheck를 켜두거나 프로젝트 참조를 쪼개 놓은 곳이 많은데, 빨라졌다고 그 우회를 그대로 두면 얻을 것을 못 얻는다. 올리면서 그동안 속도 때문에 포기했던 설정을 되돌려 보는 편이 낫다. strict를 못 켜고 있었다면 지금이 다시 시도할 때다.

도구가 빨라지는 것의 진짜 값어치는 기다리는 시간이 줄어드는 것이 아니라, 느려서 안 하던 일을 하게 되는 것에 있다.

참고 자료

• Announcing TypeScript 7.0 — Microsoft DevBlogs — 발표일, 프로젝트별 속도 수치, API 미제공과 영향받는 도구 목록, 자바스크립트 지원 변경
• Microsoft Releases TypeScript 7.0 with a Native Go Compiler — InfoQ — 슬랙 CI 사례 등 외부 관점의 정리