2026년 10월 7일, Theo Browne이 ts-rust 저장소를 오픈소스로 공개했다. 이에 대응하는 npm 패키지 이름은 tsc-rs다. 마이크로소프트가 Go 언어로 전면 재작성한 TypeScript 7의 컴파일러, 타입 검사기, LSP(Language Server Protocol) 전체 시스템을 Rust로 이식하는 거대한 엔지니어링 프로젝트다. 이 프로젝트는 상류의 알고리즘 구조, 동작 방식, 명령줄 인터페이스, API를 그대로 계승했으며, 코드베이스는 2026년 9월 29일 자 TypeScript 7.1.0-dev(리비전 673a5f17d713) 상태로 고정되었다. 동일한 개발 목표를 두고 두 프론티어 모델 계열이 보여준 소요 시간과 비용 청구서는 한 자릿수 이상의 극명한 격차를 드러냈다.
40만 달러의 API 표면 비용과 2만 4천 달러의 실제 구독 지출
개발자의 초기 시도는 GPT-5.6 Sol과 GPT 6 Astra 모델에 의존했다. 두 모델은 수개월에 걸친 자율 /goal 루프 속에서 정가 기준 40만 달러가 넘는 API 토큰을 소비하며 130만 줄의 Rust 코드를 작성했으나, 84% 안팎의 호환성에서 완전히 멈춰 서며 한계를 드러냈다. 이후 Claude Opus 5.5로 전환하자 전체 이식 작업은 단 2주 만에 완료되었다. 개발자는 X(구 트위터)에 다음과 같이 소회를 남겼다. “Codex 토큰 약 40만 달러어치를 태우고도 아무런 성과를 내지 못했지만, Opus에 약 2만 달러를 투입하자 2주 만에 끝났다.”
여기서 40만 달러는 일반 API 정가로 환산한 액면가에 불과하며, 실제로 Opus 사용 과정에서 발생한 비용은 상위 구독 플랜의 제공량을 활용한 약 24,047달러였다. 이는 단일 사용자 기준 주당 200달러 플랜 한도의 925%~983%에 달하는 수치다. 초장기 엔지니어링 과제의 성패는 모델이 방대한 컨텍스트를 흔들림 없이 유지할 수 있는지, 그리고 기존 작업물이 쓸모없다는 것을 인지했을 때 과감히 비우고 처음부터 다시 시작할 수 있는지에 달려 있다. 동일한 작업을 API 정가로만 결제한다면 소규모 팀의 자금은 단숨에 바닥났을 것이며, 이것이 해당 프로젝트가 구독 한도를 통해서만 현실적으로 가능했던 이유다.
그림: 두 차례의 이식 시도에 따른 토큰 비용과 소요 시간 비교. 출처: @theo / X
130만 줄의 코드를 버리다: 전면 재작성을 선택한 결정적 판단
Opus 5.5가 투입되었을 때, 이 모델은 Astra가 남겨둔 130만 줄의 코드에 누더기처럼 덧대는 방식을 택하지 않았다. 기존 코드가 완전히 회생 불가능한 상태라고 판단하고, 새로운 크레이트(crate)를 만들어 밑바닥부터 다시 작성을 시작했다. 불과 10시간 만에 기초적인 동작이 가능한 v0 버전을 완성하며, 이전 모델이 수주 동안 헤매던 진척도를 단숨에 추월했다.
수십만 토큰에 이르는 컨텍스트의 압박 속에서, 결함이 있는 부산물을 과감히 비우고 새 판을 짜는 결단력이 프로젝트의 좌초 여부를 갈랐다. 장기적인 코드 생성 과제에서는 잘못된 코드 위에 패치를 덧대는 행위가 예측 불가능한 연쇄 오류를 낳기 쉽다. 망가진 코드를 수선하는 것보다 완전히 갈아엎는 편이 훨씬 빠르며, 이러한 전면 재작성은 매몰 비용에 집착하는 인간 개발자의 본능적인 직관을 뒤집어놓았다.
181,711개의 상류 테스트가 구축한 방어선
572개의 스타와 5,963회의 커밋을 기록한 이 MIT 라이선스 저장소의 README 경고 영역에는 개발자의 솔직한 문장이 적혀 있다. “나는 이 코드의 단 한 줄도 읽지 않았다.” 실제로 구분선 아래의 README 본문 전체는 Claude Code가 직접 작성했다. 한 줄도 검토하지 않은 거대한 결과물을 주저 없이 배포할 수 있었던 자신감은 Go 버전에서 이식된 181,711개의 테스트 스위트를 모두 통과했다는 검증 결과에서 나왔다.
검증 과정에서 TanStack Query core와 Hono의 타입 진단 로그는 Go 버전 컴파일러와 하나하나 완벽하게 일치했으며, 언어 서버(LSP)와 API 응답 역시 오라클 테스트 세트에서 상류 결과와 정확히 부합했다. 120개의 오픈소스 저장소를 대상으로 진행한 실측에서도 명령줄 출력 차이는 극소수의 알려진 문제를 제외하면 전무했다. 거대 LLM이 생성한 방대한 코드의 신뢰성은 오직 상류의 견고한 테스트 스위트라는 방어선에 의해 지탱된다. 인간의 인지 대역폭에 의존하는 코드 리뷰 방식은 이미 신뢰의 사슬에서 제외된 셈이다.
그림: ts-rust 저장소의 소셜 미리보기 카드. 출처: GitHub
Bun에는 못 미쳤지만 내장 Effect 진단을 확보하다
개발자는 Apple M4 Pro 칩 환경에서 hyperfine으로 5회 측정한 중앙값을 기준으로 명확한 성능 지표를 도출했다. 6개 오픈소스 프로젝트의 타입 검사에서 tsc-rs의 기하평균 속도는 tsc 7 대비 1.61배 빨랐다. 375만 줄에 달하는 VS Code 프로젝트의 경우 tsc 6은 54.56초, tsc 7은 6.84초가 걸린 반면, tsc-rs는 4.20초로 단축했다. 현재 배포된 프리뷰 패키지에는 PGO와 BOLT 프로파일 최적화가 적용되지 않았기 때문에 정식 빌드의 실제 속도는 더욱 빨라질 전망이다. 다만 Bun이 제공하는 bun check는 VS Code 검사를 1.62초 만에 완주하며 여전히 최고 속도의 자리를 지켰다.
반면 특정 생태계에 특화된 진단 작업에서는 아키텍처 통합의 강점이 빛을 발했다. T3 Code에 포함된 5개 프로젝트의 합산 테스트에서 Effect 검사를 제외했을 때 tsc-rs는 7.25초가 걸려 tsc 7의 16.10초보다 빨랐다. Effect 전용 진단(코드 377xxx)을 활성화했을 때는 tsc-rs가 11.13초를 기록하여, tsc 7에 @effect/tsgo 플러그인을 결합했을 때의 21.07초를 크게 앞질렀다. Effect 진단이 컴파일러의 기본 파이프라인에 내장되면서 보조 파싱으로 인한 오버헤드가 완전히 제거된 것이다. 개발자는 npm install -D tsc-rs 명령어 하나로 완벽한 통합 진단 환경을 확보할 수 있다.
플랫폼 한계와 연산 비용 장부를 둘러싼 논쟁
초기 실험 프로젝트인 만큼 tsc-rs에는 명확한 사용 제약이 따른다. 현재는 정적으로 링크된 Linux x64 및 macOS arm64 환경만 지원하며, Windows와 Linux arm64는 아직 지원하지 않는다. 알려진 문제로는 일부 모노레포 구조에서 TS6059 오류(파일이 rootDir 아래에 없다는 경고)가 발생하거나, tsc -b 실행 시 오래된 캐시 출력이 남는 현상이 있다. 특히 초기 등록된 5개의 이슈 중 4개는 사실 상류 TypeScript 자체의 기존 동작을 그대로 재현한 것이었다. 이식 도구가 상류의 동작을 픽셀 단위로 모사할 때, 상류의 오랜 버그와 결함마저 그대로 고유 동작으로 굳어지는 셈이다.
Hacker News 토론장에서는 기술적 구현에 대한 논의를 넘어 더 근본적인 시각차가 드러났다. 일부 사용자는 계산기를 두드리며 40만 달러면 뛰어난 컴파일러 엔지니어를 고용할 수 있는 금액인데 왜 이를 연산 클러스터에 쏟아부었느냐고 반문했다. 이에 대해 다른 사용자들은 40만 달러가 API 환산 액면가일 뿐 실제 지출은 2만 4천 달러에 불과하다고 지적했다. 또한 막대한 연산 자원을 소모한 실험 프로젝트를 개발자가 코드 한 줄 검토하지 않고 배포한 태도에 의문을 제기하거나, README 자체가 Claude Code의 노골적인 홍보물 아니냐는 회의적인 시선도 나왔다. 코딩 비용의 문턱이 월간 구독료 수준으로 낮아지면서, 소프트웨어 공학의 담론은 코드를 어떻게 짤 것인가에서 기계의 연산 비용과 인간의 노동 대가를 어떻게 맞바꿀 것인가로 빠르게 이동하고 있다.
참고 링크:
- Theo Browne의 X 발표문
- pingdotgg/ts-rust 저장소 README
- AI의 TypeScript 재작성에 관한 커뮤니티 토론
