AI를 이용해 TypeScript를 Rust로 포팅하고 코드를 한 줄도 읽지 않은 경험

Theo Browne은 TypeScript 컴파일러의 Rust 재작성 버전을 공개하며, README에 자신이 이 코드의 한 줄도 읽어본 적이 없다고 인정했습니다. 그의 말 그대로입니다: 'I've never read a line of this code.'

그 문장만으로도 많은 것을 이야기하고 있습니다. 어떤 사람들은 그것을 재미있어 했고, 어떤 사람들은 무섭다고 느꼈습니다.

대부분의 사람들은 둘 다라고 생각했습니다.

옆에 붙은 숫자로도 마찬가지였습니다. 이 포팅 작업에는 API 토큰 비용으로 42만 달러가 넘게 들었습니다. 그런데 그는 이것을 아마 2만 달러 정도로 할 수 있었을 것이라고 말합니다.

이 간극이야말로 전체 이야기입니다.

ts-rust가 실제로 무엇인지

사람들이 항상 던지는 질문이 있습니다: 또 다른 TypeScript 컴파일러인가요?

정확히는 아닙니다. ts-rust (tsc-rs)는 Microsoft의 TypeScript 컴파일러, 타입 체커 및 언어 서버 전체를 Rust로 포팅한 것입니다.

이는 동일한 커맨드 라인, 동일한 LSP, 동일한 API를 유지합니다. npm install -D tsc-rs로 설치하고 tsc처럼 실행할 수 있습니다.

여기서 흥미로운 점은 누가 만들었느냐입니다. Microsoft가 아닙니다. Theo가 재미 삼아 시작했다가 멈추지 않은 것입니다.

그리고 결과는 실제적입니다. VS Code에서 tsc 6의 54.56초 걸리던 전체 타입 체크가 4.20초 만에 완료되었습니다. 이는 13배 향상된 속도입니다.

181,711개의 포팅된 Go 테스트 케이스 모두 통과했습니다. 60개 프로젝트에 걸친 타입 체크 시간이 Go 컴파일러 시간의 절반 수준으로 줄었습니다.

몇 달간 실패한 끝에 단 10시간 만에 작동하는 v0를 만들었다.

이것이야말로 아무도 예상하지 못한 부분입니다.

40만 달러짜리 실수

실제 대규모 포팅 작업에 에이전트(agents)들을 투입했을 때 발생하는 일은 데모에서 보여주는 것과는 다릅니다.

Theo는 OpenAI 모델을 사용하여 5개월 동안 약 40만 달러의 토큰 비용을 사용하며, /goal 루프를 돌렸습니다. 그들은 130만 줄이 넘는 Rust 코드를 작성했지만, 겨우 84% 호환성까지만 도달했습니다.

그러다 Opus를 시도했습니다. 이 모델은 단 10시간 만에 작동하는 v0를 만들었습니다.

그는 이 모델이 이전 코드를 재사용했다고 가정했습니다. 하지만 그렇지 않았습니다. 새로운 모델은 이전 에이전트들이 작성한 130만 줄의 코드들을 살펴보고, 그것들은 복구 불가능하다고 판단하여 10시간 만에 완전히 새로운 크레이트(crate)를 처음부터 작성했고, 죽은 코드는 리포지토리에 그대로 방치했습니다.

한 모델이 6개월 동안 한 작업이 다른 모델에게는 쓰레기였습니다.

최종 지출액은 2주 동안 약 $24,000이었습니다. 그는 이전 작업을 README에서 "슬롭 라인(slop line)"이라고 부르며, 그 아래의 모든 것은 자신이 아닌 LLM들이 작성한 것이라고 표시했습니다.

저는 그 부분을 계속 읽게 됩니다. 그는 그것을 출시하고, 벤치마킹했으며, 그리고 자신의 저작권에 선을 그었습니다.

비용 계산이 또 다른 문제입니다. 컴파일러가 84% 완성된 데 $400,000이 들었다는 것입니다.

작동하는 버전에 $24,000입니다. 에이전트 경제학을 모델링한 누구도, 비싼 시도가 실패하고 저렴한 것이 성공하는 이러한 형태를 예측하지 못했습니다.

bun check가 등장하다

대부분의 튜토리얼은 ts-rust와 tsc를 비교하라고 말합니다. 하지만 진짜 싸움은 옆에서 나타났습니다.

프로젝트가 막 출시되자마자, Bun 팀은 런타임에 내장된 네이티브 TypeScript 타입 체커인 bun check를 발표했는데, 이것 역시 Rust로 작성되었습니다.

그것은 빠릅니다. T3 Code에서 Effect 진단(diagnostics) 없이 bun check는 tsc-rs의 7.25초 대비 4.07초 만에 완료됩니다.

하지만 흥미로운 숫자는 다른 곳에 있습니다. VS Code에서 bun check는 전체 검사를 1.62초 만에 실행합니다.

이는 375만 줄 코드베이스에서 tsc 6보다 33.7배 빠릅니다. 기준점은 "tsc보다 빠른 것"이 아닙니다. 기준점은 이제 "방금 $24k를 들여 구축한 Rust 재작성본보다 수 배 빠른 것"입니다.

Theo는 이에 맞서지 않았습니다. 그는 bun check가 대부분의 앱에 더 나은 선택일 가능성이 높다고 말했고, tsc-rs는 무거운 함수형 타입, 즉 Effect 스타일 코드에서 이기도록 조정되었다고 언급했습니다. 그러더니 그가 ts-rust를 포기해야 한다며 농담을 했습니다.

그 정직함은 드물고, 읽기에 여전히 씁쓸합니다.

저는 비교를 숨기자고 주장했을 것입니다. 그는 경쟁자가 자신보다 잘하는 숫자를 공개하고 모두에게 경쟁자를 사용하라고 말했습니다. 제 본능은 그의 판단보다 더 나빴을 것입니다.

깊이 생각해 볼 만한 작은 세부 사항이 있습니다. Effect 진단이 같은 패스에서 실행될 때 tsc-rs가 이깁니다. 왜냐하면 bun check는 이를 포함하지 않기 때문입니다.

따라서 정직한 프레이밍은 일반적인 것이 아니라 한 종류의 코드베이스에 대한 좁은 승리라는 것입니다. 그도 그 부분을 소리 내어 말했습니다.

왜 Rust가 아니고, 왜 Go가 아닌가

이것은 대부분의 흥미로운 의견들이 건너뛰는 배경입니다. 2년 전, 모두가 마이크로소프트가 왜 TypeScript를 Rust로 포팅하지 않았는지 물었습니다.

대신 마이크로소프트는 TypeScript 7에서 Go로 포팅했습니다. 리드 개발자는 이를 명확하게 설명했습니다. Go의 메모리 모델이 원래의 TypeScript 코드베이스에 깔끔하게 매핑되기 때문입니다. Rust로 포팅하려면 단순한 포팅이 아니라 처음부터 다시 설계해야 했을 것입니다.

따라서 현재 세 가지 버전이 존재합니다. tsc 6, 느린 오리지널 버전. 마이크로소프트가 배포한 tsc 7 (Go 버전).

그리고 LLM(대규모 언어 모델)이 2주 만에 작성한 tsc-rs (Rust 버전)입니다.

검토의 문제 (the reviewing problem)

저는 예전에 에이전트가 작성한 코드는 도구(tooling) 이야기라고 생각했습니다. 하지만 그것은 신뢰(trust)에 관한 이야기입니다.

반응의 큰 부분은 속도에 대한 것이 아니었습니다. 아무나 이것을 검토할 수 있느냐에 대한 문제였습니다.

Bun 프로젝트는 Zig의 창시자가 그 Rust 리라이트를 '검토되지 않은 쓰레기(unreviewed slop)'라고 부르자 같은 싸움을 벌였습니다. 비판은 같았지만, 시기는 달랐습니다.

Theo의 대답은 README 상단에 경고문을 넣는 것이었습니다. '이것은 완전한 대체품이 아니라 초기 릴리스이며, 제가 코드를 읽어보지 않았습니다.' 이는 대부분의 팀들이 관리하는 것보다 더 정직합니다.

이는 또한 당신에게 부담을 지웁니다. 만약 당신이 자신의 레포지토리에 tsc-rs를 실행한다면, 이제 당신이 검토자(reviewer)가 되는 것입니다.

솔직한 부분 (the honest part)

대부분의 프로젝트는 오늘 당장 전환해서는 안 됩니다.

만약 타입 체크 속도가 느려서 단지 빠르게 만들고 싶다면, bun check나 tsc 7을 사용하세요. 이들은 지원되며 빠르고, 아무도 생면부지의 읽어보지 않은 Rust 코드를 신뢰할 필요가 없습니다.

tsc-rs는 Effect 기반의 코드베이스를 운영하거나, WASM(웹어셈블리) 기능을 갖춘 체커를 원하거나, 단순히 이 실험이 흥미롭다고 느끼는 경우에 지켜볼 가치가 있습니다. 아직 배포 단계 옆 CI(지속적 통합)에 넣을 만큼은 아닙니다.

가장 큰 오해는 이것이 언어 논쟁이라는 것입니다. 그렇지 않습니다. Go 대 Rust의 선택은 어떤 언어가 더 좋은지에 의해서 결정된 것이 아니라, 코드베이스를 어떻게 포팅할 수 있는지에 의해 결정되었습니다.

그리고 더 조용한 것은 이렇습니다. 에이전트가 컴파일러를 작성한다고 해서 그 컴파일러가 틀렸다는 의미는 아닙니다. 그것은 여러분이 그 정확성을 느낌(vibes)으로 받아들일 수 없다는 뜻입니다. 테스트는 통과했고, 이것이 바로 주의사항이 속도가 아니라 검토에 관한 것인 이유입니다.

제가 계속 돌아오는 주제

거의 아무것도 만들어내지 못한 42만 달러와 모든 것을 만들어낸 24,000달러가 있습니다.

만약 제가 에이전트들이 84%까지 도달했다가 포기하는 과정을 6개월 동안 지켜봤다면, LLM으로는 이것을 할 수 없다고 결론지었을 것입니다.

Theo는 또 다른 모델을 시도했고, 그것은 성공했습니다. 여기서 얻을 교훈은 에이전트가 마법이라는 것이 아닙니다. 같은 작업이라도 무엇에 초점을 맞추느냐에 따라 불가능할 수도 있고 사소하게(trivial) 처리될 수도 있다는 것입니다.

저 역시 코드를 읽어보지 않았습니다. 아무도 읽었는지 확실하지 않습니다.

어쩌면 그것이 미래일지도 모릅니다. 누군가 명세(spec)를 작성하고, 에이전트가 컴파일러를 작성하며, 나머지 우리들은 테스트 통과만으로 충분한지 결정하는 것이죠.