Rust를 한 줄도 써본 적 없는 개발자가 10만 줄짜리 TypeScript 코드베이스를 Rust로 포팅한다면? 전 Facebook 엔지니어 Christopher Chedeau(Vjeux)가 Claude Code와 함께 한 달간 진행한 실험은 AI 코딩 도구의 가능성과 한계를 동시에 보여줍니다. 3.5배 빨라진 실행 속도와 99.96%의 정확도를 달성했지만, 그 과정은 순탄치 않았습니다.

이 글은 전 Facebook 프론트엔드 엔지니어 Christopher Chedeau가 Pokemon Showdown 배틀 엔진(10만 줄 TypeScript)을 Rust로 포팅한 경험을 다룹니다. AI 학습용 고속 오라클(정답을 알려주는 참조 시스템)을 만들기 위해 시작한 프로젝트에서 그는 Claude Code의 실전 활용법과 함께 예상치 못한 도전 과제들을 발견했습니다.

출처: Porting 100k lines from TypeScript to Rust using Claude Code in a month – vjeux.com

왜 Rust로 포팅했나요?

Chedeau의 목표는 Pokemon 배틀 AI를 학습시키는 것이었습니다. 하지만 기존 TypeScript 구현은 너무 느려서 AI 학습에 필요한 수백만 번의 배틀 시뮬레이션이 비현실적이었습니다. 더 빠른 속도가 필요했고, Rust가 답이었죠. 문제는 단 하나, 그는 Rust를 전혀 몰랐습니다.

여기서 Claude Code가 등장합니다. 그는 Rust 문법을 배우는 대신 AI에게 포팅을 맡기기로 결정했습니다. 한 달간의 실험 끝에 3.5배 빠른 Rust 버전이 완성됐고, 이제 AI가 “이 상황에서 어떻게 하면 이기는가”를 빠르게 학습할 수 있는 오라클(정답 참조 시스템)을 갖게 됐습니다. 하지만 그 여정은 AI 코딩 도구의 현실을 적나라하게 보여줬습니다.

성공의 핵심: 차분 테스트

프로젝트의 가장 똑똑한 선택은 검증 전략이었습니다. Chedeau는 원본 TypeScript 구현과 새로운 Rust 구현을 동시에 실행하며 결과를 비교하는 ‘차분 테스트(differential testing)’를 구축했습니다. 무려 200만 개의 랜덤 배틀을 돌려 두 구현의 결과가 일치하는지 확인했죠.

이 접근법이 결정적이었던 이유는 명확합니다. Rust를 읽을 수 없는 상태에서도 코드가 올바르게 작동하는지 확인할 수 있었기 때문입니다. 버그가 발생하면 Claude에게 불일치하는 배틀 로그를 보여주고 수정을 요청했습니다. 최종적으로 99.96%의 일치율을 달성했는데, 나머지 0.04%는 원본 TypeScript 코드의 버그일 가능성이 높다고 합니다.

Claude가 마주한 현실적인 문제들

AI 코딩이 완벽하게 작동했다면 이 글은 여기서 끝났을 겁니다. 하지만 실제로는 여러 도전 과제가 있었습니다.

통합 문제가 가장 빈번했습니다. Claude는 개별 파일을 완벽하게 포팅했지만, 파일들을 함께 작동시키는 데는 어려움을 겪었습니다. 예를 들어, ‘이동(move)’이라는 개념을 두 개의 다른 파일에서 서로 다른 구조체로 정의해 컴파일은 되지만 통합되지 않는 코드를 만들었습니다.

맥락 손실도 심각한 문제였습니다. Claude는 작업 중간에 자주 멈춰서 지금까지 한 일을 요약하려 했습니다. 이는 컨텍스트 윈도우가 가득 차면서 이전 내용을 압축하는 과정이었는데, 이 과정에서 중요한 세부사항이 사라지는 경우가 많았습니다.

“개선”하려는 욕구가 문제를 만들었습니다. Chedeau가 명시적으로 “라인 바이 라인으로 포팅하라”고 지시했지만, Claude는 종종 코드를 “더 좋게” 만들려고 했습니다. 리팩토링을 시도하다가 버그를 만들어내는 일이 반복됐죠. Hacker News의 한 사용자도 비슷한 경험을 공유했습니다. Claude에게 Android 게임을 WASM으로 포팅하라고 했더니 코드를 “단순화”하려다 3개의 버그를 만들었다고 합니다.

실용적인 워크플로우 해킹

Chedeau는 Claude Code를 24시간 자율 실행시키기 위해 기발한 방법을 사용했습니다. Claude는 작업 중 사용자 승인을 계속 요구하는데, 그는 AppleScript를 작성해 몇 초마다 Enter 키를 자동으로 누르게 만들었습니다. 말하자면 AI가 묻는 모든 질문에 “예”라고 자동 응답하게 한 거죠.

물론 이는 위험한 접근입니다. 악의적인 코드가 실행될 수도 있으니까요. 하지만 Chedeau의 목적에는 충분했습니다. 그는 코드가 완벽하게 유지보수 가능할 필요가 없었습니다. 단지 작동하고 빠르게 실행되는 오라클이 필요했을 뿐이죠.

최적화는 실패했습니다

3.5배의 속도 향상은 인상적이지만, Chedeau는 더 나은 성능을 원했습니다. Claude에게 Rust 코드를 최적화하라고 요청했고, AI는 그럴듯해 보이는 계획을 만들었습니다. 하루 종일 여러 최적화를 구현했지만 결과는 실망스러웠습니다. 어떤 것도 실제로 성능을 개선하지 못했고, 일부는 오히려 더 느려졌습니다.

이는 AI 코딩의 현재 한계를 보여줍니다. 기계적인 변환 작업에는 탁월하지만, 성능 분석이나 아키텍처 수준의 최적화 같은 고차원적 작업에는 아직 부족합니다. 숙련된 Rust 개발자라면 병목지점을 찾아 의미 있는 개선을 할 수 있었겠지만, AI는 그렇지 못했습니다.

AI 코딩의 현주소

Hacker News에서는 이 프로젝트를 두고 열띤 논쟁이 벌어졌습니다. 회의론자들은 “읽을 수도 없는 언어로 작성된 10만 줄의 코드베이스를 어떻게 유지보수하느냐”고 물었습니다. 일부는 이것이 단지 “컴파일되고 테스트를 통과하지만 실제로는 작동하지 않는” 코드일 뿐이라고 주장했습니다.

하지만 옹호론자들은 차분 테스트의 힘을 강조했습니다. 200만 번의 배틀 시뮬레이션으로 검증된 코드는 충분히 신뢰할 만하다는 거죠. 더 중요한 건, 이런 종류의 작업을 사람이 했다면 몇 달은 걸렸을 거라는 점입니다.

Hacker News 토론에서 흥미로운 통찰이 나왔습니다. 한 사용자는 Claude에게 왜 실수했는지 물으면 상세한 분석을 내놓지만, 이는 실제 “이해”가 아니라 그럴듯한 설명을 생성하는 것일 뿐이라고 지적했습니다. 이 설명을 프롬프트에 추가해도 같은 실수가 반복되는 이유죠. AI는 자신이 왜 그렇게 행동했는지 실제로 알지 못합니다.

실무 적용을 위한 교훈

이 프로젝트는 AI 코딩 도구를 효과적으로 사용하는 방법에 대한 몇 가지 교훈을 줍니다.

첫째, 철저한 테스트 체계가 필수입니다. Chedeau의 차분 테스트가 없었다면 이 프로젝트는 실패했을 겁니다. AI가 생성한 코드를 신뢰하려면 자동화된 검증이 반드시 필요합니다.

둘째, 명확하고 제한적인 작업이 가장 잘 작동합니다. “라인 바이 라인으로 포팅”은 명확한 목표였습니다. AI에게 “개선”이나 “최적화” 같은 모호한 작업을 맡기면 문제가 생깁니다.

셋째, AI는 도구이지 마법이 아닙니다. Chedeau는 여전히 프로젝트를 이해하고, 문제를 진단하고, 올바른 질문을 던져야 했습니다. AI는 타이핑을 대신했을 뿐, 생각을 대신하지는 않았습니다.

이 실험이 보여주는 건 AI 코딩 도구가 이미 실용적이라는 것입니다. 완벽하지는 않지만, 올바른 접근법과 함께 사용하면 혼자서는 불가능했을 작업을 해낼 수 있습니다. Rust를 전혀 모르는 사람이 한 달 만에 10만 줄을 포팅했다는 사실 자체가 그 증거입니다.

참고자료:

• Hacker News 토론