tsrs의 빠른 타입 검사, CI와 편집기의 교체 조건은 다르다

타입 검사 시간이 줄었다는 이유로 CI 명령을 바꿨는데, 편집기에서는 같은 파일을 제대로 이해하지 못할 수 있다. TypeScript 컴파일러의 Rust 포트인 tsrs를 살펴보며 내가 먼저 확인한 것도 속도보다 교체 범위다. 한 번의 검사, 편집 중 피드백, 브라우저 안의 실행은 같은 컴파일러를 사용해도 요구 조건이 다르다.

Cloudflare와 VoidZero는 Owner.com의 Max Schwenk와 함께 tsrs를 개발한다고 2026년 10월 20일 발표했다. GeekNews에는 10월 21일 오전 2시 37분, 한국 시각으로 등록됐다. 아래는 10월 21일 확인한 최신 릴리스 0.18.0과 main 브랜치 문서를 읽은 분석이다. 설치하거나 벤치마크를 실행한 결과는 아니다.

새 언어보다 기존 동작을 따라가는 구현

tsrs는 TypeScript의 문법과 설계를 따로 발전시키려는 프로젝트가 아니다. 발표는 언어의 방향을 TypeScript 팀에 맡기고, 원래 구현을 충실하게 따라가겠다고 설명한다. Rust와 Wasm의 결합으로 메모리 사용을 줄여 개발 도구를 더 다양한 환경에서 실행하려는 목적도 밝힌다. WebAssembly, 줄여서 Wasm은 브라우저 등 여러 실행 환경에서 사용할 수 있는 바이너리 형식이다. 프로젝트의 목표

하지만 충실하게 따른다는 목표와 현재 모든 기능이 같다는 사실은 구분해야 한다. 호환성 문서의 기준은 TypeScript 7.1 개발 버전의 특정 Go 구현 커밋이다. 오류 메시지뿐 아니라 순서와 종료 코드의 차이도 버그로 취급한다. 우리가 쓰던 TypeScript와 tsrs의 기준 버전이 다르면, 진단 차이가 이식 오류인지 원래 언어 버전의 변화인지부터 나눠 봐야 한다.

0.18.0의 릴리스 노트는 기준 커밋과 바이너리가 보고하는 개발 버전을 함께 기록한다. 라이선스는 Apache-2.0이다. 나는 시험할 때 패키지 버전과 기준 TypeScript 버전을 한 쌍으로 기록하겠다. 프로젝트 이름만 고정하면 이후 비교에서 어느 쪽이 바뀌었는지 설명하기 어렵다.

속도 비교에는 워커 수와 측정 범위가 붙는다

발표는 같은 수의 타입 검사 워커를 쓸 때 TypeScript 7.0보다 최대 8배 빠르고 메모리를 약 70% 적게 쓴다고 제시한다. 동시에 TypeScript 7.1 베타 자체도 7.0보다 빨라졌으며, tsrs의 일부 최적화가 반영됐다고 설명한다. 이는 발표자가 제시한 초기 결과다. 모든 코드베이스의 개선율이나 Rust라는 언어만의 효과로 읽을 수 없다. 성능 발표

기본 설정끼리 실행하는 비교도 의미는 있다. 다만 tsrs는 머신에 맞춰 워커 수를 조정하므로, 같은 자원으로 얻는 효율과 기본값으로 얻는 완료 시간을 따로 기록해야 한다. 사용 안내도 검사 스레드를 늘리면 속도와 메모리 사이의 교환이 생긴다고 설명한다.

측정 옵션도 결과에 끼어든다. 벤치마크 문서는 시간을 재는 실행에 --extendedDiagnostics나 --diagnostics를 넣지 않도록 한다. Go 구현은 통계 출력 과정에서 가비지 컬렉션과 줄 정보 계산을 수행해 두 구현에 더해지는 비용이 다르기 때문이다. 내부 통계가 필요하면 별도 실행에서 수집하는 편이 비교 목적에 맞다.

나는 같은 소스와 의존성, 설정, CPU·메모리 제한을 고정하고, 캐시가 없는 최초 검사와 증분 검사를 나눠 보겠다. 검사 프로세스가 빨라져도 CI 대부분이 패키지 설치나 번들 생성에 쓰인다면 전체 대기 시간의 개선은 작을 수 있다. 최대 메모리와 실제 작업 종료 시간도 함께 봐야 한다.

CLI 통과가 편집기 호환성을 보장하지 않는다

호환성 표는 타입 검사와 JavaScript·선언 파일 출력, 증분 빌드, 프로젝트 참조를 지원한다고 명시한다. 반면 --init과 --showConfig는 지원하지 않는다. 기존 자동화가 설정을 출력해 분석하거나 초기 파일을 만드는 명령까지 감싸고 있다면 단순한 실행 파일 교체로 끝나지 않는다.

운영체제도 확인할 항목이다. 확인 시점의 문서는 0.18.0까지 macOS arm64와 Linux x64·arm64용 바이너리를 제공하며, Windows x64 패키지는 다음 릴리스를 위해 구성됐다고 구분한다. Intel Mac용 바이너리도 없다. main 브랜치에 Windows 관련 변경이 보인다는 이유로 현재 배포 패키지까지 지원한다고 판단하면 안 된다. 배포 범위

편집기에서는 언어 서버가 별도 경계다. 언어 서버는 진단, 자동 완성, 정의로 이동 같은 기능을 편집기에 제공한다. tsrs는 이를 구현했지만, 언어 서버 문서에는 콘텐츠 매퍼를 아직 불러오지 않는다는 제약이 있다. 콘텐츠 매퍼는 Vue·Svelte·Astro 같은 파일을 TypeScript가 검사할 수 있게 연결하는 기능이다. CLI 검사와 빌드는 이를 지원하므로 같은 프로젝트라도 두 경로의 결과를 따로 확인해야 한다.

따라서 CI 검사만 병행 도입하고 편집기의 기존 언어 서버를 유지하는 선택도 가능하다. 편집기까지 바꾸려면 실제 서버 실행 경로, 자동 완성, 이름 변경, 파일 저장 뒤 진단 갱신을 확인하겠다. 명령 한 번의 성공으로 이 흐름까지 검증됐다고 보지는 않는다.

Wasm에서는 작업을 맡기는 호스트가 중요하다

@tsrs/wasm은 브라우저와 Node.js 22 이상에서 사용할 수 있으며 단일 스레드로 실행된다. 브라우저에서는 프로젝트 파일과 의존성의 타입 선언을 메모리 파일로 전달해야 한다. 표준 라이브러리는 포함되지만 패키지 전체를 자동으로 가져오는 환경은 아니다. Wasm 패키지 안내

특히 브라우저 호스트는 Web Worker를 자동 생성하지 않는다. 모듈을 준비한 뒤 컴파일은 동기적으로 진행하므로 개발자가 만든 Worker에서 실행하도록 안내한다. 화면을 멈추지 않는 실행 구조와 파일을 준비하는 비용까지 호스트의 역할로 남는다.

이 패키지는 --watch, 언어 서버, API 서버를 지원하지 않는다. 인스턴스의 선형 메모리는 wasm32 기준 최대 4GiB이며 런타임 제한은 더 작을 수 있다. 깊은 재귀에서는 브라우저별 스택 한계도 문제가 된다. 따라서 네이티브 실행의 병렬 성능 수치를 브라우저 편집기의 예상 성능으로 가져올 수 없다. 현재 실행 제약

교체할 부분 하나를 정하고 차이를 남긴다

타입 검사에 시간이 많이 들거나 CI 메모리가 부족한 팀, 브라우저에서 코드를 검사하는 도구를 만드는 개발자라면 시험할 이유가 있다. 다만 출발점은 요구에 따라 달라진다.

필요한 변화	먼저 확인할 경계
CI 타입 검사 시간을 줄인다	같은 기준 버전의 진단·종료 코드와 시간·최대 메모리
편집기 반응을 개선한다	언어 서버 연결, 파일 형식 지원과 편집 동작
브라우저 안에서 검사한다	Worker, 메모리 파일 공급과 스택·메모리 한계

나는 기존 필수 검사를 유지한 채 대표 프로젝트 하나를 추가 검사하겠다. 진단의 파일·위치·코드, 종료 코드와 결과물을 먼저 대조하고, 그다음 시간과 메모리를 비교한다. 버전 차이와 알려진 제약으로 설명되지 않는 차이는 최소 재현 사례로 남긴다.

속도 이득이 작거나 편집기 기능의 빈틈이 크다면 기존 TypeScript를 유지하는 편이 합리적이다. tsrs는 타입 검사를 실행할 장소와 자원 배분의 선택지를 늘린다. 우리 도구에서 그 선택이 필요한 부분부터 확인하겠다.

참고 자료

• Introducing tsrs: A port of TypeScript to Rust — Cloudflare
• tsrs 공식 저장소와 라이선스 안내
• tsrs 0.18.0 릴리스
• TypeScript compatibility
• Using tsrs
• Benchmarks: tsrs vs tsgo
• The language server
• @tsrs/wasm