클라우드플레어·보이드제로, 타입스크립트 러스트 포팅 tsrs 공개 — TS 7.0보다 최대 8배 빠르고 메모리 70% 덜 쓴다

무슨 일이Go 포팅이 끝나자마자 러스트 포팅이 나왔다

타입스크립트 컴파일러는 원래 타입스크립트로 쓰여 있었다. 마이크로소프트는 이를 Go로 옮기는 작업을 해 왔고, 2026년 7월 8일 TypeScript 7.0으로 정식 출시했다. 공식 발표에 따르면 전체 빌드가 보통 8~12배 빨라졌다. 7.0은 아직 프로그래밍용 API가 없고, 7.1에서 새 API를 넣을 계획이다.

그로부터 석 달 남짓 지난 10월 20일, 클라우드플레어 블로그에 "Introducing tsrs: A port of TypeScript to Rust"라는 글이 올라왔다. 작성자는 보시 천(Boshen Chen), 디미트리 미트로풀로스(Dimitri Mitropoulos), 크리스토프 나카자와(Christoph Nakazawa)다. 블로그는 클라우드플레어와 보이드제로가 오너닷컴의 맥스 슈웽크와 함께 tsrs를 만들고 있으며, 타입스크립트 팀과 긴밀히 협력하고 있다고 적었다. 프로젝트는 Oxc 자바스크립트 컴파일러 툴체인의 일부로 인큐베이팅된다. 보이드제로는 Vite, Rolldown, Oxlint를 만든 곳이고, 블로그는 이 도구들을 "클라우드플레어가 이미 품고 있는" 러스트 도구로 소개했다.

저장소는 github.com/oxc-project/tsrs다. 소개 문구는 "TypeScript 7 타입 검사기의 러스트 포팅"이고, README는 "TypeScript 7 컴파일러와 언어 서버의 드롭인 대체품"을 목표로 내건다. 저장소 생성일은 10월 1일, 공개 사흘째인 10월 23일 기준 GitHub 별은 2천 개 가까이 모였다.

어떻게 만들어졌나

출발점은 오너닷컴이다. 오너닷컴 엔지니어링 블로그에 10월 19일 올라온 글에서 슈웽크는 9월 30일 이 작업을 시작했고, 코드는 직접 한 줄도 쓰지 않고 에이전트(Claude Opus 5.5)와 20개가 넘는 서브에이전트를 병렬로 돌려 만들었다고 밝혔다. 업스트림 Go 컴파일러의 특정 커밋에 고정해 놓고 충실하게 번역하는 방식이었다. 회사의 대형 모노레포(약 3만 7천 개 파일) 타입 검사가 단일 스레드 TS 7.0 기준 80초에서 CI의 tsrs 기준 약 7초로 줄었다는 것이 그 글의 제목이다.

클라우드플레어도 블로그에서 이 배경을 숨기지 않는다. "최신 AI 모델은 이제 대규모 포팅을 며칠 만에 거의 독립적으로 해낸다"고 쓰고, 그 결과 러스트나 C++로 된 "슬롭포크(slopfork)", 충실한 포팅, 완전히 재설계한 버전이 쏟아졌다고 했다. 블로그 표현대로라면 지금까지 타입스크립트를 다른 언어로 옮기려는 시도는 많았지만 성공한 건 타입스크립트 팀의 Go 포팅 하나뿐이었다.

성능"최대 8배"는 어떤 조건의 숫자인가

클라우드플레어가 내건 숫자는 "같은 수의 타입 검사 워커를 쓸 때 TS 7.0 대비 최대 8배 빠르고 메모리 약 70% 절감"이다. 블로그는 다른 포팅들이 더 큰 머신과 기본값이 아닌 옵션으로 성능을 부풀려 왔다고 지적하면서, 자신들은 타입스크립트 팀과 함께 같은 설정을 비교하도록 확인했다고 밝혔다. tsrs의 기본값은 머신에 맞춰 검사 스레드를 늘리는 적응형 설정이라, 메모리는 더 쓰지만 더 빠르다.

저장소의 bench/RESULTS.md에는 실제 측정표가 있다. 16 vCPU 리눅스 머신에서 TypeScript 7.0.2(tsgo), tsrs, 그리고 bun check를 17개 프로젝트에 돌린 "과거 스냅숏"이다. 이 중 6개는 타입스크립트 팀이 tsgo를 측정하는 microsoft/typescript-benchmarking에서 가져왔다. 같은 조건(검사 스레드 4개, tsgo 기본값)으로 맞춘 표에서 tsrs는 4.37배(Compiler)에서 11.81배(mui-docs) 빨랐고, 피크 메모리는 2.19배에서 7.24배 적었다.

같은 파일에는 "기본 설정" 표도 있는데, 여기서는 tsgo가 4스레드, tsrs가 16스레드로 돈다. 이 조건에서는 tsrs가 4.20배~16.87배 빠르게 나온다. 스레드 수가 달라 공정한 비교는 아니고, 블로그가 "같은 워커 수"를 강조한 이유도 여기 있다. 기사나 SNS에서 "16배"라는 숫자를 보면 이 표에서 나온 것인지 확인하는 게 좋다.

비교 대상도 따져 봐야 한다. 블로그 스스로 TS 7.1 베타가 7.0보다 최대 2.5배 빨라졌다고 했으니, 7.1과 견주면 격차는 줄어든다. 오너닷컴 글의 자체 모노레포 측정에서도 4스레드 기준 tsrs 0.14.0은 7.1 나이틀리(9월 29일)보다 5.0배 빠르고 메모리는 4.7배 적었다. 7.0.2와 비교한 수치(61.4초 대 8.75초)보다는 작은 차이다.

호환성목표는 100% 일치, 지금은 실험판

tsrs의 원칙은 단순하다. 저장소 호환성 문서는 "Go 코드가 곧 명세"이며 진단 메시지, 그 순서, 메시지 문구, 종료 코드 중 하나라도 다르면 tsrs의 버그로 본다고 적었다. 출력이 더 보기 좋아도 마찬가지다. 같은 문서는 업스트림 순서대로 돌렸을 때 오류 기준선 13,700개, .types·.symbols 기준선 각 12,998개, JS·선언 파일 기준선 13,626개가 모두 일치한다고 밝힌다. 인기 타입스크립트 저장소 1,000개에 대해 고정된 tsgo와 진단 결과를 비교하는 검사도 돌린다.

벤치마크 표의 오류 개수를 보면 tsgo 7.0.2와 tsrs가 17개 중 9개 프로젝트에서 같은 오류를 냈다. 나머지 8개는 tsrs가 7.1 개발 커밋을 옮겨 왔기 때문이며, 그 커밋으로 빌드한 TypeScript 7.1 dev 버전은 tsrs와 똑같은 오류를 낸다고 저장소는 설명한다. 오너닷컴은 자사 모노레포를 빌드마다 tsgo와 tsrs로 함께 검사해 왔고 수만 번 돌리는 동안 불일치가 없었다고 했다.

써 보려면

블로그는 npm 설치를, README는 pnpm 예시를 든다. 기존 tsc --noEmit 자리에 넣어 보는 게 가장 간단하다. 브라우저 플레이그라운드(tsrs-playground.void.app)도 있다.

# 블로그 안내
npm install tsrs
npx tsrs

# README 예시: 개발 의존성으로 넣고 타입 검사만
pnpm add -D tsrs
pnpm exec tsrs --noEmit

왜 중요한가속도보다 "어디서 돌릴 수 있나"의 문제

"Go 포팅으로 이미 10배 빨라졌는데 왜 또?"라는 질문에 클라우드플레어는 WebAssembly로 답한다. Go 프로그램을 Wasm으로 컴파일하면 가비지 컬렉터까지 같이 들어가야 하지만, 러스트는 메모리 관리 모델 덕분에 Wasm 게스트와 호스트 사이 메모리를 직접 주고받기 쉽다는 것이다. 클라우드플레어 워커스는 몇 주 전 wasm-bindgen의 Emscripten 대상을 통해 네이티브 러스트 지원을 발표했다. 메모리를 적게 쓰는 타입 검사기가 있으면 빌드·배포 시스템 전체를 워커스 같은 샌드박스, 브라우저, 임베디드 기기에서 돌릴 수 있다는 그림이다.

결국 클라우드플레어의 관심은 에이전트다. 블로그는 에이전트와 결합하면 개발 툴체인을 처음부터 끝까지 완전히 격리된 환경에서 돌릴 수 있다고 썼다. 에이전트가 코드를 고칠 때마다 타입 검사를 돌리는 구조라면, 검사 한 번에 드는 시간과 메모리가 곧 비용이다. 오너닷컴이 "샌드박스와 CI 자원에서 연간 수십만 달러를 아낄 것"이라고 한 것도 같은 맥락이다.

유지보수 방식도 눈여겨볼 만하다. 클라우드플레어는 Next.js를 Vite 위에서 다시 구현한 Vinext를 업스트림과 맞추던 방식을 그대로 쓰겠다고 했다. 매일 아침 에이전트가 업스트림 변경을 훑어 추적 이슈를 열고, 매일 밤 업스트림 테스트를 돌려 호환성 표를 갱신하는 식이다. 또 테오 브라운(Theo Browne)과 함께 별도 러스트 포팅인 tsc-rs(pingdotgg/ts-rust)를 tsrs와 하나로 합쳐 LSP까지 지원하는 단일 패키지로 만들 계획이다. 성능 개선은 타입스크립트 Go 코드베이스에도 되돌려 보내겠다고 했다.

앞으로TS 7.1 정식판과 함께 안정판을 노린다

README에 따르면 tsrs는 TypeScript 7.1을 대상으로 100% 일치하는 안정판을 내는 것이 목표다. 블로그는 그때까지 진단 출력 순서 같은 차이를 최소로 줄이겠다고 했다. Oxc 팀은 이미 속도·메모리·유지보수성을 위해 코드베이스를 리팩터링하기 시작했고, Oxlint에 타입 인식 린트 규칙을 넣는 식의 통합도 실험할 계획이다.

자주 묻는 질문

tsrs란?

tsrs는 TypeScript 7 컴파일러와 언어 서버를 러스트로 옮긴 오픈소스 포팅판이다. 클라우드플레어와 보이드제로가 오너닷컴의 맥스 슈웽크와 함께 Oxc 프로젝트 아래에서 개발하며, 2026년 10월 20일 실험 버전이 공개됐다. 라이선스는 Apache-2.0이다.

tsrs는 TypeScript 7(tsgo)보다 얼마나 빠른가?

클라우드플레어는 같은 워커 수 기준 TS 7.0보다 최대 8배 빠르고 메모리를 약 70% 덜 쓴다고 밝혔다. 저장소 벤치마크에서 4스레드 기준 속도 향상은 프로젝트별로 4.37~11.81배였다. TS 7.1 베타가 7.0보다 최대 2.5배 빨라졌기 때문에 7.1과 비교하면 격차는 더 작다.

tsrs는 타입스크립트 포크인가?

아니다. 클라우드플레어는 포크가 아니며 언어 설계와 방향은 타입스크립트 팀이 계속 결정해야 한다고 밝혔다. tsrs는 업스트림 Go 구현을 명세로 삼아 그대로 따라가고, 동작이 다르면 tsrs의 버그로 취급한다.

tsrs를 설치해서 써 보려면?

npm install tsrs 후 npx tsrs로 실행하면 된다. pnpm이라면 pnpm add -D tsrs, pnpm exec tsrs --noEmit로 타입 검사만 돌릴 수 있다. 아직 실험판이라 기존 tsc와 결과를 나란히 비교하며 쓰는 편이 안전하다.

왜 Go가 아니라 러스트로 다시 포팅했나?

클라우드플레어가 든 가장 큰 이유는 WebAssembly다. Go는 Wasm으로 컴파일할 때 가비지 컬렉터를 함께 넣어야 하지만, 러스트는 메모리를 적게 쓰고 Wasm 호스트와 메모리를 직접 주고받기 쉽다. 이를 이용해 브라우저나 워커스 같은 샌드박스에서 개발 툴체인 전체를 돌리려는 것이다.

출처

• Cloudflare Blog — Introducing tsrs: A port of TypeScript to Rust
• GitHub — oxc-project/tsrs (README·라이선스)
• GitHub — tsrs 벤치마크 결과(bench/RESULTS.md)
• GitHub — tsrs 호환성 문서(docs/COMPATIBILITY.md)
• Building @Owner — tsrs (Max Schwenk)
• Microsoft TypeScript Blog — Announcing TypeScript 7.0
• GitHub — pingdotgg/ts-rust (tsc-rs)