Bun의 Zig→Rust 53만 줄 이식이 11일 만에 가능했던 조건

Bun 팀은 Zig 코드를 Rust로 옮기는 데 AI 에이전트 64개를 투입했고, 계획부터 병합까지 11일이 걸렸습니다. 대상은 53만 5,496줄, 커밋 수는 약 6,500개, API 가격 기준 비용은 16만 5,000달러였습니다.

항목	값
대상 코드	53만 5,496줄 (Zig → Rust)
기간	계획부터 병합까지 11일
커밋	약 6,500개
비용	API 가격 기준 16만 5,000달러
구성	Git worktree 4개 × 에이전트 16개

겉으로 보면 사람 3명이 1년 걸릴 일을 AI가 열흘 남짓 만에 처리한 이야기처럼 보입니다. 하지만 이 사례의 핵심은 에이전트를 많이 실행했다는 데 있지 않습니다. 코드 변환 규칙을 문서로 고정하고, 저장소를 망가뜨릴 수 있는 권한을 제한하며, 컴파일 오류와 테스트 결과를 반복적으로 검증하는 구조를 만들었다는 점에 있습니다.

출발점은 코드 변환보다 600줄짜리 규칙 문서였다

Bun 팀은 곧바로 파일을 나눠 에이전트에게 배정하지 않았습니다. 먼저 Claude와 약 3시간 동안 Zig의 패턴을 Rust에서 어떻게 대응할지 논의했고, 그 결과를 600줄 분량의 PORTING.md로 정리했습니다.

이 문서에서 특히 중요한 부분은 “무엇을 구현할 것인가”보다 “무엇을 하면 안 되는가”를 구체적으로 적었다는 점입니다. 예를 들어 tokio, rayon, hyper 같은 라이브러리를 사용하지 못하게 했고, std::fs, std::net처럼 I/O를 직접 다루는 모듈도 변환 대상에서 제외했습니다. async fn으로 구조를 바꾸는 대신 기존 코드의 콜백과 상태 머신 방식을 유지하도록 했으며, 빌림 검사기를 피하기 위한 원시 포인터 사용도 금지했습니다.

금지한 것	이유
tokio·rayon·hyper	에이전트마다 다른 런타임 구조를 도입하지 않도록
std::fs·std::net 직접 사용	I/O 계층을 임의로 재설계하지 않도록
async fn으로 구조 변경	기존 콜백·상태 머신 방식을 유지
원시 포인터로 빌림 검사 우회	합칠 때 드러나는 안전성 문제를 막기 위해

이런 제약은 AI의 창의성을 떨어뜨리는 장치가 아닙니다. 대규모 병렬 작업에서 각 에이전트가 제멋대로 설계를 바꾸지 않게 만드는 인터페이스에 가깝습니다. 에이전트마다 다른 방식으로 비동기 구조를 해석하거나 파일 I/O 계층을 재설계하면, 개별 파일은 컴파일되더라도 전체 코드베이스를 합칠 때 비용이 급격히 커집니다.

64개 에이전트보다 중요한 것은 작업 경계였다

초기 운영은 순조롭지 않았습니다. 여러 에이전트가 같은 저장소를 동시에 조작하면서 한쪽이 git stash를 실행하면 다른 쪽이 stash pop이나 git reset HEAD --hard를 실행하는 식의 충돌이 발생했습니다. 병렬화 자체보다 공유 작업 공간이 더 큰 위험 요소가 된 셈입니다.

해결책은 에이전트의 권한을 줄이는 것이었습니다. 최종 구성은 Git worktree 4개에 Claude 에이전트 16개씩 배치하는 형태였습니다. 각 에이전트는 지정된 파일을 즉시 커밋하는 것 외의 Git 명령을 사용할 수 없었고, cargo나 오래 걸리는 명령도 직접 실행하지 못하도록 제한됐습니다.

이 방식의 의미는 단순히 안전성을 높였다는 데 있지 않습니다. 에이전트가 작업 범위를 넘어서 다른 사람의 변경을 되돌리거나, 저장소 상태를 임의로 정리하는 일을 막아 병렬 처리의 재현성을 높였습니다. 대규모 AI 코딩에서는 에이전트의 능력보다 파일 소유권, 커밋 단위, 실행 가능한 명령을 먼저 설계해야 한다는 사례입니다.

변환은 한 번의 생성 작업이 아니라 검증 루프였다

이식 과정은 파일을 Rust 문법으로 바꾸고 끝내는 방식이 아니었습니다. crate 단위로 cargo check를 실행하고, 발생한 오류를 파일별로 묶은 뒤, 적대적 검토자 2명이 결과를 확인하고 수정 담당 에이전트 1명이 반영하는 루프를 반복했습니다.

사람의 개입 없이 자정부터 오전 11시 30분까지 작업이 진행된 구간도 있었다고 합니다. 여기서 중요한 것은 AI가 11시간 동안 완성된 코드를 한 번에 만들었다는 뜻이 아니라, 오류를 수집하고 분류하고 수정하는 파이프라인이 자동으로 계속 돌아갔다는 점입니다.

다만 공개된 설명에는 오류 수치가 일관되지 않은 부분이 있습니다. 처음 집계된 컴파일 오류는 약 1,600개였지만, 순환 의존성을 해결하는 과정에서 약 1만 6,000개가 드러났습니다. 어느 수치가 전체 오류를 뜻하는지는 제공된 내용만으로 확정하기 어렵습니다. 따라서 이 사례를 인용할 때는 오류 개수를 정확한 성과 지표처럼 사용하기보다, 의존성 해소 과정에서 오류가 크게 늘어나고 다시 줄어드는 반복 작업이 있었다는 점에 초점을 맞추는 편이 안전합니다.

11일과 16만 5,000달러를 일반적인 기준으로 보면 안 되는 이유

API 가격 기준 비용은 16만 5,000달러였지만, 모든 프로젝트에 그대로 적용되는 고정 비용은 아닙니다. 고수준 설계와 계획에는 상대적으로 비싼 모델을 사용하고, 단순 코딩과 검토에는 저렴한 모델을 섞는 방식이 제안됐습니다. Anthropic 내부 실비는 공개된 API 가격 기준보다 낮았다는 설명도 있어, 실제 비용과 외부 사용자가 같은 조건으로 재현할 비용을 구분해야 합니다.

또한 비용에는 단순한 코드 생성 토큰만 들어가는 것이 아닙니다. 같은 파일을 여러 번 읽고, 컴파일 오류를 다시 분석하고, 리뷰 에이전트가 변경 내용을 검토하는 과정에서 입력·출력 토큰이 누적됩니다. 병렬화를 늘리면 달력상 시간은 줄어들 수 있지만, 중복 컨텍스트와 재검증 비용은 오히려 증가할 수 있습니다.

사람 3명이 1년 동안 작업한다는 기존 견적에는 신규 기능과 버그 수정의 중단 비용도 포함돼 있었습니다. 반면 AI 병렬 이식은 여러 작업을 동시에 진행할 수 있었기 때문에 일정 단축 효과가 컸습니다. 두 수치를 단순히 “1년 대 11일”로 비교하기보다, 개발 중단 비용과 검증 비용까지 포함한 프로젝트 전체 비용으로 봐야 합니다.

이 방식을 적용하려면 먼저 테스트를 의심해야 한다

이 사례를 다른 팀이 따라 하려면 세 가지 조건이 필요합니다. 코드베이스를 깊이 이해하는 엔지니어, 동작의 근거로 삼을 수 있을 만큼 강한 테스트 스위트, 그리고 결과를 미리 알 수 없는 상태에서 상당한 토큰 비용을 감수할 준비입니다.

이 가운데 가장 현실적인 분기점은 테스트입니다. 테스트가 통과했다는 사실이 실제 동작의 보증이 되지 않는다면, AI가 아무리 많은 코드를 빠르게 바꿔도 자동화된 허위 확신만 커질 수 있습니다. 특히 언어를 바꾸는 작업에서는 다음과 같은 차이가 테스트에 잘 드러나지 않을 수 있습니다.

• 메모리 수명과 소유권 처리 방식의 변화
• 오류 전파 방식과 예외적인 입력 처리
• 네트워크·파일 I/O의 타이밍과 실패 동작
• 성능 저하, 동시성 문제, 리소스 해제 누락
• 플랫폼별 동작이나 드물게 발생하는 순환 의존성

따라서 시작 전에 전체 테스트 통과 여부만 볼 것이 아니라, 테스트가 실제 사용 경로와 장애 상황을 얼마나 포함하는지 확인해야 합니다. “우리 테스트를 통과했으니 배포해도 되는가”라는 질문에 자신 있게 답할 수 없다면, 대규모 자율 이식보다 테스트 보강과 작은 범위의 파일럿이 먼저입니다.

Bun 사례에서 재사용할 수 있는 설계 원칙

Bun의 사례는 모든 코드베이스를 AI 에이전트 64개로 옮기라는 처방이 아닙니다. 월 2,200만 다운로드 규모이고 Claude Code와 OpenCode가 의존하는, 이미 잘 엔지니어링된 코드베이스였기 때문에 이런 속도를 낼 수 있었던 것으로 설명됩니다. 코드 구조가 엉켜 있거나 테스트가 약한 프로젝트라면 에이전트 수를 늘리는 것이 문제를 해결하지 못합니다.

비슷한 작업을 검토한다면 먼저 전체 이식을 약속하기보다 작은 crate나 독립 모듈로 다음을 확인하는 편이 낫습니다. 변환 규칙을 문서화할 수 있는지, 에이전트별 파일 경계를 나눌 수 있는지, 자동 검증 결과를 사람이 해석할 수 있는지, 실패했을 때 원래 구현으로 되돌릴 수 있는지를 순서대로 점검해야 합니다.

특히 금지 규칙은 초기에 정해야 합니다. 사용할 수 있는 라이브러리 목록보다 사용하면 안 되는 추상화, 변경하면 안 되는 API, 접근해서는 안 되는 I/O 계층을 명확히 적는 것이 병렬 작업에서는 더 효과적입니다. 저장소 권한 역시 최소화해야 하며, 에이전트가 임의로 리셋하거나 다른 작업자의 변경을 덮어쓸 수 있는 구조는 피해야 합니다.

이 사례의 속도는 AI의 코드 생성 능력 하나로 설명되지 않습니다. 잘 정의된 변환 규칙, 강한 테스트, 세분화된 작업 경계, 자동화된 오류 분류, 그리고 실패 비용을 감당할 예산이 함께 있었기 때문입니다. 이 조건 중 하나라도 빠진 팀이라면 53만 줄 전체를 맡기기보다, 검증 가능한 작은 단위에서 실제 비용과 오류 패턴을 먼저 측정하는 것이 현실적인 출발점입니다.