헤드라인은 빠르다고 말하지만, 세부 내용이 중요합니다
Rust 기반의 독립적인 TypeScript 포트는 테스트 실행을 약 0.2–0.5초에 완료했습니다. 이는 Go의 0.6–2.2초, JavaScript의 6.6–13초보다 크게 개선된 수치입니다. Go와 비교하면 평균 2.5배에서 3배 빠르며, 오류가 연쇄적으로 발생하는 시나리오에서는 최대 4.4배 빠릅니다.
중요한 점은 이 성능 향상이 Microsoft의 공식 컴파일러 작업이 아니라 독립적인 Rust 포트에서 나왔다는 것입니다. 지난 7월 Microsoft는 TypeScript 컴파일러를 Go로 포팅하여 원래 JavaScript 버전 대비 약 10배의 속도 향상을 달성했습니다. 주로 AI 에이전트를 활용한 Rust 포트는 Microsoft의 대체 제품이 아니라 Go 버전 위에 구축된 커뮤니티 주도 프로젝트입니다.
이 구분은 매우 중요합니다. Rust 컴파일러는 인상적이지만 비공식적인 개발 결과물입니다. 이는 주로 AI의 도움을 받아 성능에 초점을 맞춰 코드베이스를 다시 설계했을 때 무엇이 가능한지를 보여줍니다.
TypeScript 프로젝트 자체처럼 대규모이긴 하지만 단일 저장소에서 나타난 눈에 띄는 속도 향상은 강력한 신호입니다. 그러나 모든 TypeScript 프로젝트가 자동으로 동일한 극적인 개선을 얻는다는 확실한 증거는 아닙니다. 핵심적인 쟁점은 이러한 초기 벤치마크가 다양한 유형과 복잡도의 프로젝트에도 일반화되는지 여부입니다.
네 가지 테스트, 두드러진 성능 격차
성능 테스트에는 GitHub의 공식 TypeScript 저장소를 사용했으며, 793개 파일과 약 380,000줄의 코드로 구성되어 있습니다. 이 견고한 테스트 환경을 통해 네 가지 시나리오를 종합적으로 비교할 수 있었습니다: - 모든 타입이 유효한 경우 - 단일 단순 타입 오류 - 오류가 연쇄적으로 발생하는 핵심 타입 손상 - 깊은 재귀 타입
결과는 뚜렷했습니다. 유효한 타입의 경우 JavaScript는 약 7초, Go는 0.7초가 걸렸고, Rust는 단 0.3초 만에 작업을 완료했습니다. 핵심 타입이 손상되어 오류가 연쇄적으로 발생한 경우 JavaScript는 13초, Go는 2.2초를 기록했으며, Rust는 불과 0.5초 만에 끝냈습니다. 이 수치들은 일관되고 상당한 성능 격차를 보여줍니다.
전반적으로 영상은 Go가 JavaScript보다 대략 9–10배 빠르다고 보고했습니다. Rust는 JavaScript의 약 24배, Go의 거의 3배에 달하는 속도를 보였습니다. 반올림된 측정값과 단일 코드베이스라는 한계로 절대적인 정밀도에는 제약이 있지만, 성능 순위는 분명합니다.
Microsoft가 7월에 진행한 TypeScript의 Go 포팅은 상당한 성과를 가져왔습니다. 그러나 이후의 Rust 구현은 특히 복잡한 오류 처리 시나리오에서 더 큰 도약을 보여줍니다. 데이터는 새로운 성능 기준을 분명하게 보여줍니다.
Rust 결과를 자세히 살펴볼 필요가 있는 이유
컴파일러 워크로드는 Go나 Rust 같은 언어에도 까다로운 테스트입니다. 타입 검사에는 복잡한 재귀적 관계, 대규모 의존성 그래프 구성, 핵심 타입이 손상되었을 때 기하급수적으로 늘어날 수 있는 진단 메시지 생성이 포함됩니다. 이러한 복잡성 때문에 "핵심 타입 손상" 시나리오에서 JavaScript 컴파일러가 최대 13초가 걸렸습니다.
Rust가 Go보다 평균 2.5배에서 3배 빠른 성능 우위를 보인 것은 메모리 관리와 런타임 오버헤드의 근본적인 차이에서 비롯된 것으로 보입니다. Rust의 제로 비용 추상화, 명시적인 메모리 레이아웃, 가비지 컬렉터 부재는 할당 동작을 최소화하고 캐시 미스를 줄일 수 있어, 컴파일과 같은 CPU 중심 작업에서 실질적인 이점을 제공합니다.
AI 지원 개발에 힘입어 TypeScript의 Rust 포트가 등장한 것은 중요한 추세를 보여줍니다. GitHub의 TypeScript 저장소처럼 방대한 테스트 스위트를 갖춘 대규모 기존 코드베이스는 코딩 에이전트가 반복적으로 변환하기에 이상적인 대상입니다. 이 방식은 tsrs와 같은 프로젝트에서 보듯이 동작하는 포트를 빠르게 만들어 낼 수 있습니다. 자세한 내용은 Introducing tsrs: a Port of TypeScript to Rust에서 확인하세요.
그러나 기존 테스트를 통과했다고 해서 완전한 호환성이 자동으로 보장되거나 미묘한 동작 차이가 드러나는 것은 아닙니다. AI 기반 포팅은 강력하지만, 기능 동등성을 확보하고 원래 구현의 무결성을 유지하려면 사람이 주도하는 엄격한 검증이 여전히 중요합니다. 속도는 부인할 수 없지만, 장기적인 안정성은 신중한 검토가 필요합니다.
이 글이 마음에 드셨나요? 매일 아침 이런 글을 메일로 받아보세요.
하루 한 통 · 두 번의 클릭으로 구독 취소 · 제3자 추적 없음
벤치마크 우위가 곧 바로 대체할 수 있다는 의미는 아닙니다
벤치마크 우위가 곧 바로 대체할 수 있다는 의미는 아닙니다. Rust 포트를 도입하기 전에 개발자는 몇 가지 핵심 요소를 확인해야 합니다. 특히 공식 TypeScript 구현과의 언어 및 컴파일러 API 동등성을 평가하여, 기존 에디터 도구, 빌드 시스템, 진단 출력과 매끄럽게 통합되는지 확인해야 합니다. 자체 프로젝트에서의 동작이 궁극적인 시험대입니다.
공식 버전과 Rust 버전 모두에 동일한 컴파일러 옵션을 적용하여 공정한 로컬 테스트를 진행하세요. 클린 컴파일과 증분 컴파일을 모두 포함하고, 메모리 사용량을 모니터링하며, 몇 번의 시간 측정에 그치지 않고 대표적인 CI 워크로드에서 성능을 평가하세요. 이러한 포괄적인 접근 방식을 통해 실제 프로덕션 준비 상태를 확인할 수 있습니다.
이 Rust 포트의 인상적인 결과, 특히 Go 대비 3배 속도 향상은 컴파일러 성능의 기준을 높입니다. 이러한 대안 구현은 더 넓은 생태계가 혁신하도록 압박하며, 최적화된 네이티브 코드가 개발자 경험을 크게 개선할 수 있음을 보여줍니다. 수치는 설득력이 있지만, 프로덕션 준비 상태는 신뢰와 완전한 호환성에 달려 있습니다.
즉각적인 안정성과 공식 Microsoft TypeScript 컴파일러와의 완전한 기능 동등성이 가장 중요하다면 이 Rust 포트는 무시하셔도 됩니다. 포괄적인 통합과 생태계 지원이 성숙해지기 전까지, 벤치마크에서 우위를 보인 Rust 버전은 설득력 있는 개념 증명일 뿐 대부분의 프로덕션 환경을 위한 바로 대체 가능한 솔루션은 아닙니다.
자주 묻는 질문
Microsoft의 TypeScript 컴파일러는 이제 Rust로 작성되었나요?
아니요. 이 영상은 독립적으로 개발된 Rust 포트를 기존 JavaScript 컴파일러 및 Microsoft의 Go 구현과 비교합니다.
영상의 테스트에서 Rust 포트는 얼마나 더 빨랐나요?
테스트된 TypeScript 저장소에서 Rust 포트는 평균적으로 Go보다 약 3배, JavaScript보다 약 24배 빨랐습니다.
벤치마크에서는 무엇을 테스트했나요?
TypeScript 저장소에서 유효한 타입, 단순한 타입 오류, 핵심 타입 오류의 연쇄 발생, 깊은 재귀 타입이라는 네 가지 경우를 측정했습니다.
팀은 TypeScript 컴파일러를 Rust 포트로 교체해야 하나요?
이 결과만으로는 그렇지 않습니다. 전환하기 전에 팀별로 자체 프로젝트에서 호환성, 도구 지원, 성능을 확인해야 합니다.