타입스크립트 7, 빌드가 10배 빨라진 진짜 이유

백엔드 코드를 타입스크립트로 짠 지 몇 년째인데, 매번 걸리는 게 있다. 코드 몇 줄 고치고 저장한 다음, 에디터 구석에 뜨는 빨간 줄이 사라지길 기다리는 시간. 파일 몇 개 안 되는 사이드 프로젝트에서도 저장할 때마다 3~4초씩 멈칫하는데, 실무에서 다루는 큰 코드베이스는 그보다 몇 배는 더 걸린다. 그 몇 초가 하루에 몇십 번씩 쌓이면 퇴근할 때쯤 은근히 큰 덩어리가 된다. 그래서 2026년 7월 8일에 마이크로소프트가 타입스크립트 7.0을 정식 발표하면서 내건 "10배 빠르다"는 문구를 그냥 지나칠 수가 없었다.

핵심은 컴파일러 자체를 갈아엎었다는 거다. 기존 컴파일러는 자바스크립트로 짜여 있었는데, 7.0부터는 이걸 통째로 Go로 새로 썼다. 마이크로소프트 타입스크립트팀 공식 개발자 블로그에 실린 숫자를 보면 체감이 확 온다. VS Code 코드베이스 전체를 타입 검사하는 데 6.0에서는 125.7초가 걸렸는데, 7.0에서는 10.6초로 줄었다. 11.9배다. Sentry는 139.8초에서 15.7초로, Playwright는 12.8초에서 1.47초로, Bluesky는 24.3초에서 2.8초로 줄었다. 프로젝트마다 편차는 있지만 대체로 8~12배 구간에 몰려 있다. 메모리 사용량도 6~26퍼센트 줄었다고 한다.

이게 왜 가능했는지는 타입스크립트 설계자 아네르스 하일스베르가 작년에 네이티브 포팅 계획을 처음 공개하면서 설명한 적이 있다. 자바스크립트 런타임을 벗어나 네이티브 바이너리로 도는 몫이 절반쯤, 나머지는 Go의 고루틴으로 파싱·타입체크·코드생성을 여러 코어에 나눠 돌리는 병렬화 몫이라는 것이다. 그래서 코어가 많은 CI 서버에서 특히 이득이 크다. 병렬화 정도는 직접 조절할 수도 있다. 타입 검사 워커 수를 정하는 `--checkers` 플래그는 기본값이 4이고, 모노레포라면 `--builders`로 프로젝트 단위 빌드까지 동시에 돌릴 수 있다. 반대로 디버깅할 때처럼 순서가 중요하면 `--singleThreaded`로 전부 끌 수 있게 해뒀다.

실사용 사례가 재밌다. 슬랙은 머지 큐 대기시간이 40퍼센트 줄었고 CI 타입체크는 7.5분에서 1.25분으로 짧아졌다고 밝혔다. 캔바는 에디터에서 코드를 고쳤을 때 첫 에러가 뜨는 데 걸리던 58초가 4.8초로 줄었다. 마이크로소프트 뉴스팀은 한 달에 400시간어치 CI 대기 시간을 아꼈다고 적었다. VS Code 자체 편집기도 에러 표시까지 17.5초 걸리던 게 1.3초로 줄었다니, 이 정도면 팀 단위로 하루 일과가 달라질 만한 숫자다.

그럼 지금 당장 회사 프로젝트에도 갖다 붙여야 하나. 여기서는 선을 긋고 싶다. 공식 문서에도 못 박혀 있는데, 7.0은 6.0과 호환은 되지만 6.0에서 도입된 새 기본값(`strict: true`, `module: esnext`)을 그대로 물려받고 `es5`, `amd`, `node10` 같은 구식 타깃 설정을 아예 없앴다. `rootDir`나 `types` 설정을 손봐야 하는 프로젝트도 있다고 명시돼 있다. 즉 숫자만 보고 버전만 올리면 어딘가에서 설정 에러가 튄다는 뜻이다. 설정 말고 생태계 쪽 제약도 있다. 7.0은 에디터 연동을 기존 tsserver 방식에서 표준 LSP 기반으로 갈아탔는데, 옛 API에 기대던 Vue·Svelte·Astro·Angular 같은 프레임워크 도구들은 당장은 7을 못 쓴다고 공식 문서에 적혀 있다. 이런 스택을 쓰는 팀이라면 속도 숫자보다 자기 프레임워크 툴링의 대응 일정을 먼저 확인하는 게 순서다. 배포 파이프라인이 걸린 실무 코드는 몇 달 더 지켜볼 생각이다. 대신 혼자 만지는 사이드 프로젝트 tsconfig부터 먼저 바꿔서 저장할 때 멈칫하는 그 3~4초가 진짜 줄어드는지 확인해볼 참이다. 빌드를 기다리는 시간이 개발자 경험에서 차지하는 비중은 생각보다 크고, 슬랙이나 캔바 같은 곳들이 이미 실제로 재본 숫자라면 결국 대부분의 팀이 뒤따라갈 거다.

읽어주셔서 감사합니다. 얏호