tsrs 소개: TypeScript의 Rust 포팅 버전
TMTCloudflare와 VoidZero는 이제 Owner.com의 Max Schwenk와 함께, TypeScript 컴파일러를 Rust로 포팅한 tsrs를 만들고 있습니다. 저희는 이 작업을 TypeScript 팀과 긴밀하게 협력하며 진행하고 있고, tsrs를 Oxc JavaScript 컴파일러 툴체인의 일부로 키워 나가고 있습니다.
저희 목표는 개발자가 코드 검사를 기다리는 시간은 줄이고, 무언가를 만드는 시간은 늘리도록 돕는 것입니다. TypeScript가 더 빨라지고 메모리를 덜 쓰게 되면, 브라우저 안을 포함해 더 많은 곳에서 완전한 개발 환경을 쓸 수 있게 됩니다.
분명히 말씀드리면, 저희는 TypeScript를 포크하는 것이 아닙니다. 저희는 언어의 설계와 방향을 TypeScript 팀이 온전히 결정해야 한다고 믿습니다. TypeScript 팀은 JavaScript 커뮤니티 전반에 TypeScript가 자리 잡도록 이끌면서도 장기적인 비전을 지켜 왔습니다. 저희는 그 점을 바꾸고 싶지 않습니다.
TypeScript 팀은 많은 일을 꽤 빠르게 진행하지만, 어떤 기능은 알맞은 구현을 고르기 전에 일부러 몇 년씩 여러 선택지를 탐색하고 프로토타입을 만들기도 합니다. Rust 포트는 그런 결정을 바짝 따라가야 하며, 그러지 않으면 결국 조금씩 어긋나 호환성을 잃게 됩니다. 저희는 원래 구현을 엄격한 기준으로 삼아 TypeScript 언어를 그대로 지켜야 하고, 그 언어가 어떤 모습이어야 하는지는 오직 TypeScript 팀이 결정해야 합니다.
성능과 메모리 개선
저희가 Rust로 포팅한 TypeScript의 초기 벤치마크 결과는 고무적입니다. 같은 수의 타입 검사 워커를 사용할 때, tsrs는 TypeScript 7.0보다 최대 8배 빠르고 메모리는 약 70% 덜 씁니다.
보시다시피 TypeScript의 다음 버전도 이미 많은 성능 개선을 담고 있어서, TypeScript 7.1 베타는 TypeScript 7.0보다 최대 2.5배 빠릅니다. 이런 최적화 중 일부는 tsrs에서 업스트림으로 반영된 것이며, 저희는 앞으로 더 찾아내기를 바라고 있습니다.
최근 여러 TypeScript 포트의 벤치마크가 저마다 다른 성능을 내세우는 것을 보셨을 수도 있습니다. 대개 TypeScript의 기본값과 달리 더 큰 머신 타입이나 다른 옵션을 썼기 때문입니다. 위의 벤치마크는 같은 구성끼리 비교한 결과인지 TypeScript 팀과 함께 확인했습니다.
tsrs는 기본적으로 머신 타입에 따라 달라지는 적응형 구성으로 배포됩니다. 이 구성은 메모리를 더 쓰는 대신 훨씬 더 빠릅니다.
tsrs 사용해 보기
Rust판 TypeScript는 원본 TypeScript를 충실하게 옮기는 것을 목표로 합니다. npm에서 tsrs 패키지를 설치하면 실험 버전을 써 볼 수 있습니다.
npm install tsrs
npx tsrs왜 지금일까요?
지난 몇 년 동안 TypeScript를 다른 언어로 포팅하려는 시도를 많이 봐 왔습니다. 워낙 복잡한 작업이다 보니 성공한 포트는 단 하나였습니다. 바로 TypeScript 팀이 TypeScript를 JavaScript에서 Go로 옮긴 포트입니다.
하지만 이제 프런티어 AI 모델은 대규모 포팅을 며칠 만에 거의 혼자서 해낼 수 있습니다. 실제로 Rust나 C++로 만든 TypeScript가 여럿 나왔습니다. AI로 대충 만든 포크(slopfork)도 있고, 충실한 포트도 있고, 구조를 완전히 새로 짠 버전도 있습니다. 훨씬 더 빠른 TypeScript를 원하는 수요가 분명히 있습니다.
왜 Rust일까요?
이렇게 생각하실 수도 있습니다. "TypeScript의 Go 포트는 이미 TypeScript로 작성된 이전 버전보다 TypeScript를 10배 빠르게 만들었고, 메모리 효율도 훨씬 높였다. 왜 그걸로는 부족할까?"
하지만 속도만의 문제가 아닙니다. Rust에는 몇 가지 고유한 장점이 있습니다. 바로 WebAssembly에서 실행된다는 점입니다. Rust와 Wasm은 언제나 궁합이 좋았고, 그 이유 중 하나는 Rust 언어 설계의 기본 원리에 있습니다. Go 프로그램을 Wasm으로 컴파일하면 Go의 가비지 컬렉터도 함께 컴파일해야 합니다. 반면 Rust의 메모리 관리 모델에서는 WebAssembly 게스트와 호스트가 메모리를 간단하게 주고받을 수 있습니다. Rust가 WebAssembly 용도에 훨씬 잘 맞는 핵심 이유 중 하나가 바로 이 메모리 효율입니다.
Cloudflare Workers는 오래전부터 Wasm을 지원해 왔습니다. 불과 몇 주 전에는 wasm-bindgen의 새로운 Emscripten 타깃으로 Workers에서 네이티브 Rust를 지원한다고 발표했습니다. Workers에서 소프트웨어 빌드와 배포 시스템 전체를 쉴 새 없이 반복해 돌리면, 메모리를 적게 쓰는 이점이 금방 드러납니다. 이런 워크로드를 아주 효율적으로 돌릴 수 있으니, 예전에는 실행할 수 없던 곳에서도 이제 완전히 캡슐화된 개발 시스템을 실행할 수 있습니다.
에이전트와 함께 쓰면 새로운 가능성이 열립니다. 이제 Cloudflare의 완전히 격리된 샌드박스 환경에서 개발 툴체인을 처음부터 끝까지 실행할 수 있습니다. 그뿐 아니라 Wasm을 쓰면 그런 환경을 클라이언트 쪽인 브라우저 안에서, 혹은 임베디드 기기나 IoT 애플리케이션에서도 안전하게 실행할 수 있습니다.
tsrs 포트는 어떻게 유지 관리될까요?
먼저, 저희는 Theo Browne과 함께 tsc-rs와 tsrs를 하나의 패키지로 합치고 있습니다. 이 패키지는 언어 서버 프로토콜(LSP)과 콘텐츠 매퍼(content mapper)를 포함해 TypeScript의 모든 기능을 지원합니다. 다음으로, 저희는 Vinext를 업스트림인 Next.js와 맞춰 유지하는 방식으로 큰 성과를 거뒀습니다. 그 방식은 최근 블로그 글에서 설명한 바 있습니다.
매일 아침 에이전트가 변경 사항을 검토하고, diff를 가져오고, Vinext에 영향을 줄 수 있는 것이 있으면 추적용 이슈를 엽니다. 매일 밤에는 Vinext를 대상으로 Next.js 테스트 스위트를 돌리면서 호환성 매트릭스를 다시 만듭니다. 이런 테스트나 이슈에서 빈틈이 드러나면, 이제 에이전트가 두 코드베이스에 걸쳐 해당 변경을 찾아내고, 재현 사례를 만들고, 관련 테스트를 포팅하고, 수정안을 제안할 수 있습니다.
저희는 TypeScript에도 같은 프로세스를 적용하되, 업스트림 TypeScript와 다르게 동작하는 부분이 생기지 않도록 각별히 주의하겠습니다. 성능 개선점을 찾으면 TypeScript Go 코드베이스에 다시 기여해서 모두가 이득을 보도록 노력하겠습니다.
마지막으로, 지금은 업스트림 TypeScript와 다른 점이 몇 가지 있다는 것을 알고 있습니다. 예를 들어 진단 메시지가 출력되는 순서가 다릅니다. 안정 버전을 출시할 때까지 이런 차이를 최소한으로 줄이는 것이 목표입니다.
다음 계획은 무엇일까요?
Vite, Rolldown, Oxlint, Oxfmt처럼 JavaScript 생태계를 떠받치는 무료 오픈 소스 Rust 도구 여럿이 이미 Cloudflare에 자리 잡고 있습니다. Cloudflare 위에서 개발하는 개발자가 1,000만 명이 넘는 만큼, 저희는 그 밑바탕이 되는 개발 툴체인을 더 빠르게 만들고, 이식성을 높이고, 더 많은 곳에서 쉽게 실행할 수 있게 하는 데 큰 관심을 두고 있습니다. 예를 들어 Oxlint의 타입 인식 린트 규칙처럼, tsrs를 저희 스택에 더 깊이 통합하는 실험도 기대하고 있습니다.
Vinext와 마찬가지로, 저희 목표는 TypeScript 자체를 방해하지 않으면서 tsrs를 잘 관리되는 건강한 오픈 소스 프로젝트로 운영하는 것입니다. Oxc 팀은 이미 코드베이스를 더 빠르고, 메모리를 덜 쓰고, 유지 보수하기 쉽게 만들기 위한 리팩터링을 시작했습니다. TypeScript 팀도 이 부분을 진지하게 여기고 있으며, tsc의 메모리와 성능을 개선하는 실험을 하고 있다는 것을 알고 있습니다. 저희는 TypeScript 팀, 그리고 JavaScript 커뮤니티와 협력해 가장 좋고 가장 빠른 TypeScript 구현을 함께 만들어 가기를 기대합니다.