요약
TypeScript 컴파일러를 Rust로 옮긴 tsrs가 TypeScript 7.0보다 최대 8배 빠르다고 클라우드플레어가 밝혔습니다.
클라우드플레어는 공식 블로그에서 보이드제로(VoidZero), 오너닷컴의 맥스 슈벵크와 함께 tsrs를 개발한다고 발표했습니다. tsrs는 Rust로 만든 자바스크립트 도구 모음인 Oxc 프로젝트 안에서 만들어지고 있으며, 아직 실험 단계입니다.
왜 중요한가
- Go와 달리 가비지 컬렉터(안 쓰는 메모리를 자동으로 치우는 장치)를 함께 넣지 않아도 돼 WebAssembly 환경에 더 잘 맞습니다.
- 그래서 브라우저, Cloudflare Workers, 임베디드 기기에서도 타입 검사를 돌릴 길이 열립니다.
- tsrs에서 찾은 최적화 일부는 7.0보다 최대 2.5배 빠른 TypeScript 7.1 베타에 이미 들어가 공식 컴파일러도 덕을 봤습니다.
핵심 내용
- 공식 Go 이식판인 TypeScript 7.0과 같은 작업자 수로 비교해 최대 8배 빠르고 메모리는 약 70% 덜 썼습니다.
- 포크가 아닌 충실한 이식이며, 언어 설계는 계속 TypeScript 팀이 정해야 한다고 강조했습니다.
- 에이전트가 매일 아침 원본의 변경을 검토하고, 원본 테스트를 밤마다 돌려 호환성 표를 만듭니다.
- 진단 메시지 출력 순서 같은 차이를 줄인 뒤 안정판을 낼 계획이며, 지금은
npx tsrs로 써 볼 수 있습니다. - 테오 브라운의 tsc-rs와 합쳐 LSP(편집기에 자동 완성과 오류 표시를 제공하는 규약)까지 지원할 예정입니다.
HN 반응
- TypeScript 팀원은 속도의 상당 부분이 언어보다 최적화에서 나온다고 했고, 단순 이식으로는 몇 % 차이뿐이라는 경험담이 뒤따랐습니다.
- Go 버전에 계속 투자할 이유를 묻는 댓글에는, 팀이 직접 읽고 고쳐 갈 코드가 필요하다는 반론이 맞섰습니다.
안녕하세요, 타입스크립트 팀 구성원입니다. tsrs 프로젝트가 만들어져 가는 과정을 지켜보는 일이 정말 흥미로웠습니다. 저희는 메인테이너들과 함께 tsrs가 어떻게 빠른지, 그리고 어떤 최적화가 안전한지 더 잘 이해하려고 노력해 왔습니다. 저희도 직접 Rust 바이브 포팅을 해 봤는데, 현재 저희가 의심하는 바는 속도 향상의 상당 부분이 단순히 언어 선택만으로 설명되지는 않는다는 것입니다. TS 7.1을 더 빠르고 가볍게 만들어 줄 요소(블로그 글의 차트를 보세요) 중 일부는 실제로 tsrs에서 발견된 최적화에서 나왔습니다.
저희는 wasm과 oxlint 통합이 클라우드플레어의 필요에 아주 잘 맞는다고 생각하고, 그래서 이번 투자도 납득이 갑니다. 동시에 저희는 공식 타입스크립트 도구 모음을 더 빠르고 효율적으로 만들기 위해 열심히 협력하며 노력할 것입니다.
tsrs 팀이 이 프로젝트를 공식화한 것을 축하합니다. 저희도 기쁘고, 앞으로도 계속 협력하기를 기대합니다!
이 시점에서 TSGO에 더 투자할 이유가 있나요?
tsrs에서 ts-go로 아무리 많은 최적화를 가져온다 해도 Rust가 더 효율적이고, WASM 활용 사례도 가능하게 해 줄 텐데요.
컴파일러를 TS에서 GO로 옮기기로 한 전제는 Go의 가비지 컬렉터 덕분에 마이그레이션이 쉽다는 것이었습니다. 이제는 그게 통하지 않잖아요? 테스트 스위트만 있으면 AI는 마이그레이션이 어렵든 쉽든 신경 쓰지 않습니다.
맞는 말이긴 한데, 그건 마이그레이션이 프로젝트에서 누군가 하는 마지막 작업일 때나 의미가 있죠. 타입스크립트 7.1이면 누구에게나 충분하다고 생각하는 게 아니라면, 타입스크립트 팀이 어떤 언어로 쓰고, 읽고, 추론하고 싶어 하는지도 중요합니다.
이게 타입스크립트 8, 8.1 이야기가 되면 좋겠네요 (:
방금 tsasm을 바이브코딩으로 만들었어요. 이제 tsrs는 구식이고, 아직도 그걸 쓰는 사람은 구제불능으로 시대에 뒤처진 겁니다. tsrs 팀은 당장 저장소를 지우고 제 프로젝트에 합류해야 해요.
한발 늦으셨네요, 저는 방금 tsvhdl을 출시했거든요. 이제 진짜 TS 컴파일러를 하드웨어로 구현한 거예요. 왜 에이전트 워크플로에서 귀중한 CPU 사이클을 훔쳐 갑니까? 트랜스파일링과 타입 검사는 전부 전용 TSC 칩에 맡기세요.
한발 늦으셨네요, 저는 방금 tsasic을 출시했어요. 앞으로 작성하실 모든 애플리케이션마다 맞춤 제작 보드를 쓰실 수 있습니다.
에이전트가 ASM으로 아주 안전한 코드를 쓸 수만 있다면 저는 괜찮습니다. Rust로 쓴 코드는 asm이나 C에 비하면 당연히 안전하다고 확신하고요. tsasm이 tsrs보다 훨씬 빠르고 안전해지기를 기다리겠습니다.
에이전트가 asm으로 짠 프로그램은 매우 위험할 뿐만 아니라 Rust, 심지어 Go나 Java와 비교해도 아주 느릴 거라고 확신합니다.
사람들은 Rust의 "안전성"을 엄청나게 과대평가합니다. 데이터 레이스를 다루는 방식이 아주 훌륭하긴 한데, 그게 다예요.
스레드 간에 상태를 공유하는 다른 모든 언어/도구와 마찬가지로, 예를 들어 레이스 컨디션은 여전히 생깁니다.
빌림 검사기는 제쳐 두더라도, 타입 시스템만으로도 C 같은 언어보다 본질적으로 더 안전하다고 생각하고 싶네요.
어떤 언어로든 나쁜 unsafe 코드는 쓸 수 있어요. Rust에는 그걸 위한 편리한 키워드가 있고, C++에는 타입이 있죠.
자신만만하게 틀린 주장이네요.
그분은 레이스 컨디션이라고 했고, 데이터 레이스는 따로 예외로 뒀습니다. Rust로도 레이스 컨디션은 얼마든지 만들 수 있어요. 논리 버그니까요.
예를 들어 함수 A와 B가 있다고 합시다. A는 어떤 이유로 B가 한 번도 실행되지 않았을 때만 제대로 동작합니다. 둘 다 값 C에 대한 참조를 받고, B는 C의 값을 어떻게든 바꾼다고 해 봅시다. Rust이니 데이터 레이스는 있을 수 없어서 C를 ArcMutex 같은 걸로 감쌉니다. 그래도 A와 B의 실행 순서에는 전혀 영향이 없습니다.
A와 B를 동시에 실행하는 스레드를 띄우면 A가 제대로 동작할지는 스케줄러 마음입니다.
비추천을 받고 계시지만 말씀이 전적으로 맞습니다. Rust가 100% 안전하다고 주장하는 사람은 한 번도 못 봤어요. Rust는 오직 메모리 안전 언어로만 내세워집니다. 그렇지 않다고 주장하는 건 터무니없고 글쓴이의 편향을 잘 보여 주네요.
제 글에서 그런 주장을 했다는 부분을 복사해서 붙여 보시죠.
그게 제가 한 말과 어떻게 다른데요?
하지도 않은 주장을 했다고 몰아가는 쪽이야말로 편향을 잘 보여 주는 겁니다.
메모리 안전성은 데이터 레이스만의 문제가 아니기 때문입니다. 사실 데이터 레이스는 Rust의 가장 혁신적이거나 중요한 기능과는 거리가 멉니다. 부수적으로 얻은 효과일 뿐이에요. 설계자들이 멋진 시스템을 만들었더니 데이터 레이스도 막을 수 있다는 걸 알았고, "그래, 안 될 거 없지" 했던 거죠.
정말로 만드셨나요? GitHub 링크는요? 그렇다면 정말 멋질 텐데요! 어떤 asm 타깃을 고르셨죠? 저는 ARM이나 x86 중에 고르기 싫어서 LLVM의 LVM을 써 볼까 했거든요. 만드는 과정에서 어떤 트레이드오프를 감수하셨나요? 잠깐, 설마 농담하면서 본인이 웃기다고 생각하시는 건 아니죠? (안 좋은 소식을 전하게 돼서 유감이지만, 안 웃겨요.)
답은 직접 쓰신 댓글 안에 있습니다. tsrs는 AI가 유지보수하고, tsgo는 사람이 유지보수하니까요.
질문을 줄이면 "사람이 왜 뭔가를 유지보수하느냐"가 되는데, 맥락에 따라 답이 여러 가지일 수 있습니다.
아니요, 이제 질문은 이겁니다. "어떤 프로젝트나 그 포크의 안팎에 사람의 정신적 관성, 자존심, 투자가 얼마나 걸려 있는가?"
저라면 의욕이 꺾일 겁니다. 바이브 코딩으로 만든 것의 절반 속도도 안 나오는 공식 컴파일러를 왜 유지보수하겠어요?
그냥 언어 명세만 공개하고 끝내면 되잖아요.
이런 포팅은 공식 구현의 아키텍처, 알고리즘, 자료구조를 상당 부분 빌려 옵니다.
명세만으로 이렇게 적은 노력과 비용으로 그런 포팅이 가능했을 것 같지는 않습니다.
훌륭한 언어 명세를 쓰려면 컴파일러를 만들고 유지보수해 본 경험이 필요합니다. tsrs 팀은 명세를 바꾸려고 하고 싶지 않다고 분명히 말했고요.
AI가 주도하는 상황에서는 사소하지 않은 프로젝트에 동기를 유지하는 게 불가능하니까요. 저라면 제일 하기 싫은 일이에요. 영혼이 빨려 나가고 코드도 형편없고요. 이 사람들은 슬롭이 아니라 진짜 노동을 몇 년씩 tsgo에 쏟아부었다는 걸 기억하세요. 슬로퍼 여러분은 이해 못 하겠지만요.
답변 감사합니다. 이 프로젝트가 바이브 코딩 이상의 의미가 있다니 힘이 나네요. 그 과정에서 흥미로운 것들이 발견된 것 같고, 저는 새로운 것을 배우는 방법으로서의 바이브 코딩에 전적으로 찬성합니다.
저는 아닙니다. 실제로 뭔가를 배우는 사람은 없으니까요. 한 명이 뭔가를 배울 때마다 나머지 99%는 더 게을러지고 더 멍청해지는데, 그게 어떻게 전개될지 생각해 보세요.
아마 지금까지 만들어진 기술 중 가장 해로울 겁니다. 얼마나 많은 사람이 자기가 더 똑똑해졌다고 스스로를 속이면서 실제로는 훨씬 멍청해지고 있는지를 생각해 보면요. 우리는 이미 끝장난 겁니다.
+1입니다. 제가 본 바로는 동등한 조건으로 Rust에 포팅해도 성능은 몇 % 정도만 달라집니다(오히려 나빠질 때도 있고요). 속도 향상은 대부분 알고리즘 개선에서 나오는데, 그건 원래 프로젝트에도 적용할 수 있습니다.
TypeScript 팀이 애초에 Rust를 선택하지 못하게 했던 문제, 즉 Rust에는 GC가 없어서 GC 언어에서 포팅할 때 데이터 구조를 다시 짜야 하는 경우가 많다는 문제를 극복하려고 독특한 메모리 모델( https://github.com/oxc-project/tsrs/blob/main/docs/PORTING.md#memory-model-the-important-part )을 쓰는 것 같습니다.
본질적으로는 수명이 긴 객체에 절대 해제하지 않는 아레나를 써서 GC를 흉내 내는 겁니다. Rust로 이런 게 된다니 흥미롭네요(건전하게 되기를 바랍니다만)!
그 문서에서 인용합니다.
이건 건전하지 않습니다. 증명을 LLM이나 사람이 하고 있잖아요. unsafe를 추상화 뒤에 숨겼을 뿐 unsafe한 성질은 없애지 못했습니다. 아레나 할당자의 수명을 썼다면 안전하고 쉬웠을 겁니다(bumpalo도 그렇게 쓰라고 권장하는 걸로 압니다).
아첨하는 LLM이 이 하중을 떠받치는 이음매를 찾아냈거나 칭찬했을 것 같네요.
절대 해제하지 않는 쪽이 오히려 건전했을 겁니다(미사일 메모리 관리: https://devblogs.microsoft.com/oldnewthing/20180228-00/?p=98125/ ).
이걸 메모리 관리의 돌파구라고 부르는 건 과소평가입니다. 튜링상 위원회에 전화하세요. 방금 정지 문제의 해법을 발견했다고요. 어떤 응용에서는 답이 단호하게 "예"라는 게 밝혀졌잖아요.