클로드 코드 에이전트 64개로 Bun을 러스트로 이식한 방법과 API 비용 2.4억 원

핵심 메시지

• 자바스크립트 런타임 Bun의 주석 제외 약 53만 줄 지그 코드가 러스트로 옮겨졌고, 이 작업은 클로드 코드 에이전트를 최대 64개까지 동시에 돌려 11일 만에 완료됐다.
• 전략은 새로 작성이 아니라 최소한의 동작 변경만 거친 기계적 포팅이었고, 타입스크립트로 작성된 기존 테스트 스위트가 런타임 언어와 무관해 그대로 검증 기준이 됐다.
• 작업 시작 2분 만에 여러 세션이 하나의 저장소를 건드려 서로의 변경을 덮어썼고, 저장소가 커서 에이전트마다 워크트리를 줄 수 없어 샤드 4개로 나눠 각각 워크트리를 부여했다.
• 파일마다 구현자 1명과 검토자 2명 이상을 두고, 검토자는 구현 맥락 없이 디프만 보며 코드가 틀렸다는 가정으로 검토하게 해 구현자가 놓친 메모리 해제 이슈를 잡아냈다.
• 컴파일 오류 16,000개를 실패 보고서가 아니라 다음 작업의 큐로 사용했고, 같은 실패가 반복되면 코드뿐 아니라 워크플로 규칙까지 함께 고쳤다.

쉽게 이해하기

자바스크립트 런타임 Bun이 지그에서 러스트로 옮겨졌다. Bun은 2025년 12월 앤트로픽에 인수돼 현재 클로드 코드의 런타임으로 쓰이며, 주석을 제외하면 약 53만 줄에 이르는 코드베이스다. 이 대규모 포팅을 Bun 창립자 제러드 썸너가 클로드 코드 에이전트를 동시에 띄워가며 11일 만에 완료해 주목을 받았는데, 사람이 직접 했다면 코드베이스를 잘 아는 엔지니어 세 명이 1년 정도 붙어야 할 규모로 추정된다.

언어를 바꾼 이유는 메모리 관리였다. 지그에서는 사람이 메모리를 직접 관리해야 해서 실수가 자주 발생했고, 컴파일러 단계에서 그런 오류를 먼저 잡기 위해 러스트를 택했다. 방식은 완전히 새로 쓰는 것이 최악의 선택이라는 판단 아래 최소한의 동작 변경만 거친 기계적 포팅으로 정했고, 점진적 재작성은 결국 삭제될 임시 코드를 만들어 고통스럽다는 이유로 한 번에 처리하는 쪽을 선택했다. 다행히 Bun의 테스트 스위트는 타입스크립트로 작성돼 런타임 언어에 의존하지 않았기 때문에 그대로 검증 기준으로 쓸 수 있었다.

실제로 부딪힌 첫 문제는 모델 성능이 아니라 작업 공간이었다. 전체 포팅을 시작한 지 2분 만에 저장소가 꼬이기 시작했다. 여러 세션이 하나의 공유 저장소를 보면서 어떤 에이전트는 스태시하고 어떤 에이전트는 리셋하며 서로의 변경 사항을 덮어썼다. 에이전트마다 워크트리를 주면 해결되지만 Bun의 깃 저장소가 너무 커서 디스크 공간이 부족했다. 그래서 특정 파일을 한 번에 커밋하지 않는 명령은 아예 실행하지 못하도록 하네스를 손봤고, 순차 처리로 느려진 속도는 샤드 4개로 나눠 각 샤드에 워크트리를 하나씩 주는 방식으로 해결했다. 샤드마다 최대 16개의 서브 에이전트가 돌아 피크 시 64개가 24시간 작업했고, 분당 1,300줄 속도로 11일간 6,502개의 커밋이 만들어졌다.

영상은 이 사례의 핵심을 규모가 아니라 하네스와 루프 설계로 본다. 하네스는 하나의 프롬프트가 아니라 입력을 고정하고 작업 공간을 나누고 통과 여부를 판정하는 전체 구조이며, 루프는 실패의 원인을 다음 실행의 입력으로 바꾸는 경로다. 입력 고정을 위해 모든 에이전트가 따라야 할 공통 규칙집인 포팅 문서와 러스트로 옮기기 어려운 구조체 필드의 처리 방식을 적은 라이프타임 파일을 먼저 만들고, 1,448개 지그 파일을 한 번에 맡기기 전에 세 개 파일로 시험 운전을 거쳤다. 검증은 역할 분리로 설계해 파일마다 구현자 하나와 검토자 둘 이상을 두고, 검토자는 완전히 다른 세션에서 구현자의 판단 기준을 모른 채 디프만 보게 해 자기 평가 편향을 막았으며 그 결과 구현자가 놓친 메모리 해제 이슈가 실제로 잡혔다.

결과와 한계는 나눠 봐야 한다. 전체 포팅 지시 후 나온 컴파일 오류 16,000개는 실패 보고서가 아니라 다음 실행이 가져갈 작업 큐로 쓰였고, 오류가 줄지 않거나 우회 로직이 반복되면 코드가 아니라 워크플로 규칙을 고쳤다. 맥·리눅스·윈도우를 포함한 여섯 개 플랫폼에서 기존 테스트가 모두 통과했고 이 포팅은 클로드 코드 2.1.181 버전에 반영돼 이미 쓰이고 있지만, 리눅스에서 517ms가 464ms로 개선된 부분은 여러 최적화가 함께 들어갔기 때문에 언어 교체만의 효과로 보기 어렵다. 기존 테스트는 예상한 동작만 통제하므로 병합 이후에도 11차례 보안 검토와 모든 파서에 대한 24시간 커버리지 기반 퍼징이 이어졌고, 알려진 회귀 오류 19건이 모두 수정됐다. API 정가로 환산하면 약 16만 5천 달러, 원화로 2억 4천만 원 규모의 비용이 들었는데 엔지니어 세 명의 1년치 인건비와 비교하면 오히려 저렴할 수 있다는 계산도 함께 제시됐다.

주요 인사이트

• 이 사례에서 병목은 모델 성능이 아니라 쓰기 영역의 충돌이었다. 에이전트를 늘리기 전에 누가 어디에 쓰는지를 물리적으로 갈라놓지 않으면, 시작 2분 만에 서로의 작업을 덮어쓰는 상황이 발생한다.
• 긴 프롬프트를 잘 쓰는 것보다 에이전트가 다시 읽고 검증할 수 있는 공통 규칙과 예외 판단을 파일로 빼두는 것이 중요하다. 외부 메모리가 있어야 세션이 바뀌어도 판단 기준이 유지된다.
• 검토자에게 구현 맥락을 주지 않는 것이 핵심이다. 코드를 작성한 쪽은 병합하고 싶어 하기 때문에 같은 세션에서 작성과 검수를 함께 맡기면 자기 코드를 통과시키기 쉬워진다.
• 실패를 보고서가 아니라 입력으로 취급하는 순간 루프가 성립한다. 컴파일 오류 16,000개가 작업 큐가 되고 실패한 테스트가 다음 작업이 되는 구조가, 규모보다 결과를 만들어낸 요인이다.
• 테스트 전체 통과는 완료가 아니라 하나의 검증 레이어일 뿐이다. 기존 테스트는 예상한 동작만 확인하므로 보안 검토와 퍼징처럼 성격이 다른 검증을 겹쳐 쌓아야 하며, 개인 프로젝트라면 구현자 하나와 평가자 하나만으로도 같은 원리를 적용할 수 있다.

자주 묻는 질문

관련 AI 소식