깃허브의 'ts-rust'라는 프로젝트가 최근 며칠 사이 개발자들 사이에서 화제가 되고 있다. 마이크로소프트가 Go로 다시 작성한 TypeScript 컴파일러를, 타입 체커와 언어 서버(LSP)까지 통째로 Rust로 이전한 프로젝트로, 명령줄 도구 이름은 'tsc-rs'다. 유지관리자인 pingdotgg는 설명에서 솔직하게 밝혔다. 구현 코드는 전부 대형언어모델이 생성한 것이고, 자신은 단 한 줄도 읽어보지 않았다는 것이다.
이 프로젝트는 microsoft/typescript-go의 특정 상류 버전, 즉 TypeScript 7.1.0-dev에 해당하는 버전에 고정돼 있다. 설명 문서에 따르면 Go 버전에서 이전한 18만1711건의 테스트가 모두 통과했고, 작성자가 테스트한 실제 프로젝트에서는 호환률 100%를 기록했다. 저장소는 MIT 라이선스로 공개되면서도 TypeScript의 Apache-2.0 고지와 Go 표준 라이브러리의 BSD-3-Clause 고지를 그대로 유지하고 있으며, 현재 스타 수는 600개를 넘었다.
두 가지 모델 경로
작성자는 먼저 OpenAI의 GPT-5.6 Sol과 GPT-6 Astra로 한 차례 시도했다. 이때 API 비용이 40만 달러를 넘었고, 약 130만 줄의 Rust 코드를 만들어냈지만 호환률은 84%에서 멈췄다. 이후 Claude Opus 5.5로 바꿔 처음부터 다시 시작했는데, 10시간 만에 작동하는 v0를 만들었고 2주간 총비용은 약 2만4047달러에 그쳤다.
I've never read a line of this code.
성능 면에서 작성자는 자신의 T3 Code 프로젝트로 벤치마크를 진행했다. tsc-rs는 타입 체크를 끝내는 데 7.25초가 걸렸고, Go 버전인 tsc 7은 16.10초가 걸려 2.22배 빨랐다. JavaScript 버전인 tsc 6을 기준으로 하면 tsc 7은 7.1배, tsc-rs는 11.4배 빠른 셈이다. 이 수치들은 모두 작성자 본인의 테스트 결과이며, 아직 제3자가 재현한 바 없고 OpenAI와 Anthropic 모두 이 비교에 대해 공개적으로 언급하지 않았다.
비슷한 사례들 속에서 보면
대형 모델이 대규모 코드 이전을 수행한 공개 사례는 올해 들어 이미 여러 건 있었다. 깃허브는 이전에 Copilot을 이용해 자사 런타임 중 하나를 83만 줄의 Rust로 다시 작성했다고 밝혔고, 미스트랄은 에이전트를 이용해 포트란 77 코드 4만 줄을 C++로 이전했다. 이들 프로젝트의 공통점은 기존에 커버리지가 넓은 테스트 세트가 심판 역할을 한다는 점이다.
ts-rust도 같은 패턴이다. 마이크로소프트의 Go 이전 작업 자체가 파일 단위로 '그대로 베껴 쓰는' 방식의 재작성이었고, 테스트 케이스도 함께 옮겨졌다. 이는 모델에게 거의 완전히 결정적인 목표를 제공한다. 수십만 건의 테스트가 있고, 통과하면 통과한 것이라는 식이다. 목표가 분명하고 피드백이 즉각적인 이런 작업에서는 두 모델의 격차가 크게 벌어진다. 요구사항이 모호하고 테스트 안전망이 없는 업무용 코드에 적용했을 때 이 비교가 그대로 성립할지는 아직 알 수 없다.
알려진 문제점
설명 문서는 네 가지 한계를 꼽았다. 모노레포 안에서 같은 파일이 여러 경로로 접근 가능한 경우 출력 파일이 tsc보다 많아질 수 있다. tsc -b를 이용한 증분 빌드 상황에서는 오래되거나 누락된 산출물을 읽어올 수 있다. 장시간 편집 세션에서는 메모리가 서서히 늘어나는데, 편집 1000회당 약 20MB씩 증가한다. 표시되는 버전 번호는 이전 작업 당시의 7.1.0-dev 그대로이며, npm상의 버전이 아니다.
작성자는 이를 초기 버전으로 규정하고 있다. 시도해보고 싶은 팀이라면 CI에서 tsc-rs와 공식 tsc를 병행 실행해 진단 결과를 비교하는 것이 비교적 안전한 방법이라고 설명한다. 아무도 코드를 검토하지 않은 상태에서 이를 그대로 프로덕션 빌드 체인에 바꿔 넣는 것은 각 팀이 직접 리스크를 따져봐야 한다.
참고 출처: ts-rust 프로젝트 설명 문서, CocoLoop, 해커뉴스 토론; 테스트 건수, API 비용, T3 Code 벤치마크 시간과 배율은 프로젝트 설명 문서로 확인했다.