타입스크립트 7, 컴파일러를 통째로 Go로 다시 썼다 — 10배 속도 뒤의 진짜 이야기

개발자라면 한 번쯤 tsc가 프로젝트를 컴파일하는 동안 커피를 다 마신 경험이 있으실 겁니다. 큰 코드베이스에서는 타입 체크만 몇 분씩 걸리기도 하죠. 그런데 타입스크립트 팀이 이 문제를 정공법으로 해결하겠다고 나섰습니다. 컴파일러를 개선하는 게 아니라, 통째로 다시 쓰기로 한 겁니다. 그것도 자바스크립트가 아닌 Go 언어로요.

들어가기 전에 하나 짚고 넘어가겠습니다. 이 주제는 최근 30일간 커뮤니티 신규 논의가 많지 않았습니다. 그래서 이 글은 실시간 반응보다는 그동안 축적된 맥락과 쟁점을 정리하는 데 초점을 맞췄습니다. 이 점 감안하고 읽어주시면 좋겠습니다.

왜 하필 Go였을까

가장 먼저 사람들을 놀라게 한 건 언어 선택이었습니다. 타입스크립트는 마이크로소프트가 만든 언어이고, 마이크로소프트에는 러스트(Rust)도 있고 C#도 있습니다. 그런데 왜 Go일까요.

핵심은 기존 코드와의 구조적 유사성입니다. 현재 타입스크립트 컴파일러는 자바스크립트로 짜여 있는데, 함수와 클로저를 많이 쓰는 명령형 스타일입니다. 러스트처럼 소유권(ownership) 개념이 엄격한 언어로 옮기면 코드 구조를 통째로 바꿔야 합니다. 반면 Go는 가비지 컬렉션이 있고 문법이 단순해서, 기존 컴파일러 로직을 거의 1:1로 옮기기가 수월했습니다. 팀은 “새로 설계하는 게 아니라 포팅하는 것"이라고 강조했는데, 이 목표에 Go가 딱 맞았던 셈입니다.

여기에 Go는 동시성(concurrency) 처리가 언어 차원에서 강력합니다. 타입 체크처럼 병렬로 쪼갤 수 있는 작업에 유리하죠. 네이티브 코드로 컴파일되니 자바스크립트 런타임의 오버헤드도 사라집니다.

10배는 과장이 아니다

가장 화제가 된 숫자는 역시 10배입니다. 팀이 공개한 벤치마크에 따르면 VS Code처럼 거대한 코드베이스에서 전체 빌드 시간이 기존 대비 약 10분의 1로 줄었습니다.

숫자로 보면 이렇습니다. 어떤 대형 프로젝트에서 기존 컴파일러가 77초 걸리던 작업이 새 컴파일러에서는 7.5초 안팎으로 끝났습니다. 에디터에서 타입 정보를 불러오거나 자동완성이 뜨는 속도, 이른바 “에디터 반응 속도"도 크게 개선됐습니다. 코드 한 줄 고칠 때마다 기다리던 그 미세한 지연이 사라지는 거죠.

이게 왜 중요할까요. 개발 생산성은 결국 피드백 루프의 속도에 달려 있습니다. 저장하고 결과를 확인하기까지의 시간이 짧을수록 몰입이 유지됩니다. 10배라는 숫자는 단순히 빌드가 빨라지는 걸 넘어, 개발 경험 자체를 바꾸는 변화입니다.

이름부터 정리하고 갑시다

여기서 조금 헷갈리는 지점이 있습니다. 이 프로젝트는 처음에 코드네임 “Corsa"로 불렸고, 개발 저장소는 typescript-go라는 이름으로 공개됐습니다. 그리고 이 네이티브 컴파일러가 정식으로 자리 잡는 버전이 타입스크립트 7입니다.

그렇다면 지금 우리가 쓰는 자바스크립트 기반 컴파일러는 어떻게 될까요. 이건 타입스크립트 6.x 계열로 당분간 유지됩니다. 즉 한동안은 두 개의 컴파일러가 공존합니다. 기존 JS 버전은 안정성과 호환성을 담당하고, 새 Go 버전은 성능을 담당하는 과도기가 이어지는 셈입니다. 이 이원화 구조는 마이그레이션 리스크를 줄이려는 현실적인 선택입니다.

환영만 있었던 건 아니다

당연히 논쟁도 뜨거웠습니다. 가장 많이 나온 반응은 “왜 자바스크립트/타입스크립트 생태계 도구를 Go로 만드느냐"는 것이었습니다.

일부 개발자들은 아쉬움을 드러냈습니다. 타입스크립트 컴파일러가 자바스크립트로 짜여 있었기 때문에, 그동안 커뮤니티가 소스를 읽고 기여하고 실험하기가 상대적으로 쉬웠습니다. 컴파일러 내부 API를 활용해 만든 수많은 도구들, 예를 들어 린터나 번들러의 타입 관련 기능들이 있었죠. 이것들이 네이티브 바이너리로 바뀌면 접근 방식이 달라집니다.

또 다른 쟁점은 “그럴 거면 러스트가 낫지 않았냐"는 목소리였습니다. 이미 SWC나 esbuild, Biome 같은 도구들이 러스트나 Go로 자바스크립트 생태계의 속도 문제를 공략하고 있었거든요. 여기에 대해 팀은 반복해서 설명했습니다. 목표는 “완전히 새로운 컴파일러"가 아니라 “기존 동작을 그대로 보존한 포팅"이었고, 그 제약 안에서 이식 난이도가 가장 낮은 게 Go였다는 겁니다. 성능 챔피언을 뽑는 대회가 아니라, 검증된 로직을 안전하게 옮기는 이사 작업에 가까웠던 셈입니다.

생태계가 흔들리는 이유

이 변화가 단순한 속도 업그레이드로 끝나지 않는 이유가 여기 있습니다. 타입스크립트 컴파일러는 그 자체로 하나의 플랫폼이었습니다. 수많은 도구가 이 컴파일러의 내부를 들여다보며 만들어졌죠.

에디터의 언어 서버, 타입 기반 린트 규칙, 문서 생성 도구, 각종 빌드 파이프라인. 이 모든 것이 앞으로는 네이티브 컴파일러와 새로운 방식으로 대화해야 합니다. 팀은 이를 위해 별도의 API 레이어를 준비하고 있다고 밝혔지만, 기존에 JS API에 깊이 의존하던 도구들은 어느 정도 적응 기간이 필요할 겁니다.

결국 이건 성능 개선이면서 동시에 생태계 재편의 신호탄입니다. 앞으로 몇 년간 자바스크립트 툴체인 전반이 네이티브 방향으로 이동하는 흐름을 가속할 가능성이 큽니다.

마무리하며

타입스크립트 7은 단순히 “빠른 tsc"가 아닙니다. 자바스크립트로 만든 도구를 자바스크립트로 유지해야 한다는 오랜 관성을 깨고, 성능을 위해 언어의 경계를 넘은 상징적인 결정입니다. 10배라는 숫자 뒤에는 이식성, 호환성, 그리고 생태계 전체의 방향에 대한 치밀한 고민이 숨어 있습니다.

여러분의 프로젝트가 크다면, 이 변화는 곧 체감할 수 있는 생산성 향상으로 다가올 겁니다. 다만 질문 하나는 남습니다. 우리가 쓰는 도구가 점점 네이티브 바이너리로 바뀌어 갈 때, 커뮤니티가 손쉽게 들여다보고 기여하던 개방성은 어떻게 지켜낼 수 있을까요. 속도와 접근성, 여러분은 어느 쪽에 더 무게를 두시나요.