AI로 11일 만에 끝낸 Bun의 Zig→Rust 재작성에서 배울 점
요약
Bun 팀이 53만 줄의 Zig 코드를 64개의 AI 에이전트를 활용해 11일 만에 Rust로 재작성한 사례를 분석합니다. 철저한 사전 설계와 테스트 스위트를 통해 수년이 걸릴 작업을 단축한 방법론을 다룹니다.
핵심 포인트
- 600줄의 상세한 PORTING.md 가이드가 성공의 핵심
- 파일별 병렬 변환과 두 차례의 적대적 검토 프로세스 적용
- AI 에이전트를 통한 대규모 코드베이스의 초고속 이식 가능성 증명
- 성공을 위한 필수 조건: 코드 이해도, 강력한 테스트, 토큰 비용 감수
- 메모리 안전성이 없는 Zig에서 누수와 충돌이 계속되자, Bun은
535,496줄의 코드를 64개 AI 에이전트로 Rust에 옮겨 1~2년 걸릴 작업을 11일로 단축함 - 성공의 출발점은 600줄짜리
PORTING.md
였으며, 파일별 병렬 변환과 두 차례 적대적 검토, 컴파일 오류 수정, 로컬 테스트, CI 통과를 순서대로 진행함
- 6,500개 커밋을 만드는 데 API 가격 기준
16만 5,000달러와 비캐시 입력 59억·출력 6억 9,000만·캐시 입력 읽기 720억 토큰이 사용됨 - 수작업이었다면 코드베이스를 잘 아는 엔지니어 3명이 약 1년간 제품 개선, 버그·보안 수정, 신규 기능 개발을 멈춰야 해 재작성 자체가 어려웠을 것으로 판단함
- 같은 방식을 반복하려면 코드베이스를 깊이 이해하는 엔지니어, 결과를 신뢰할 수 있는
강력한 테스트 스위트, 성공이 불확실해도 토큰 비용을 감수할 의지가 필요함
Bun이 Rust 재작성을 선택한 이유
-
Bun은 JavaScript 런타임을 넘어 여러 기능을 제공하는
복잡한 프로덕션 프로젝트임 -
JavaScript·TypeScript·CSS 변환, 번들링, 축소
-
테스트 러너와 npm 호환 패키지 관리자
-
모듈 해석, WebSocket 클라이언트, Node.js 구현과 여러 모듈
-
월간 다운로드는
2,200만 건이며 Claude Code와 OpenCode가 의존하고, Vercel·Railway·DigitalOcean이 직접 지원함 -
Zig는 메모리 안전 언어가 아니어서 최신 Bun에서도 메모리 누수, 메모리 문제로 인한 충돌, 힙 범위 밖 쓰기 등이 계속 발생함
-
Bun 팀은 Zig 컴파일러를 패치하고 종단 간 메모리 누수 테스트를 도입했지만 문제를 제거하지 못함
-
가비지 컬렉션 값과 수동 관리 값의 수명을 함께 처리하는 과정에서 작은 누수와 간헐적 충돌이 생김
-
모든 메모리 할당마다 해제 위치와 중복 해제 여부, JavaScript 예외 처리, 보수적 스택 스캐너의 포인터 가시성 등을 검토해야 했음
안전한 Rust에서는 use-after-free와 double-free가 컴파일 오류가 되며, 오류 경로에서 해제를 빠뜨리는 문제는 Drop
기반 자동 정리로 처리할 수 있음
- Rust식 스마트 포인터를 Bun 코드에 자체 도입하는 방법도 검토했지만, Rust보다 사용성이 나쁘면서 같은 보장을 제공하지 못했음
기존 재작성 프로젝트가 오래 걸리는 이유
-
재작성 중에도 원래 코드베이스에 기능이 계속 추가되므로 완료 시점이 반복해서 밀리는 경향이 있음
-
9개월로 예상한 작업은 9개월 뒤에도 약 6개월이 더 필요할 수 있음
-
15개월이 지나도 새 기능을 따라잡느라 수개월의 작업이 남을 수 있음
-
운이 좋아도 2개월간 기능을 동결한 뒤 약 18개월 만에 끝나며, 최초 9개월 예상이 2년 이상으로 늘어날 수 있음
-
주석을 제외한 Bun의 Zig 코드는
535,496줄이어서 소규모 엔지니어 팀이 다른 언어로 옮기려면 약 1년이 필요할 것으로 예상함 -
사용자에게 보이는 개선 없이 1년을 보내는 선택지는 현실적이지 않아, Fable로 일주일 안에 Rust 이식 가능성을 검증할 수 있는지 시험하기로 함
이식을 위한 사전 설계와 검증
- 첫 단계에서 Claude와 약
3시간 동안 Zig 패턴을 Rust에 가깝게 대응시키는 방법을 논의하고, 이를 600줄 분량의PORTING.md
로 정리함
- 이식 지침에는 Bun의 기존 실행 구조를 보존하기 위한 구체적인 제한을 담음
tokio
, rayon
, hyper
, async-trait
, futures
를 사용하지 않음
std::fs
, std::net
, std::process
처럼 I/O에 접근하는 모듈을 금지함
- Bun이 자체 이벤트 루프와 시스템 호출을 소유하므로
async fn
대신 기존 Zig처럼 콜백과 상태 머신을 사용함
-
빌림 검사기 충돌이 생기면 필요한 스칼라 값을 지역 변수에 저장하고 빌림을 끝낸 뒤 다시 빌림
-
빌림 검사기를 피하기 위한 원시 포인터 사용은 금지하고, 구조를 바꾼 위치에는 이식 메모를 남김
-
전체 1,448개 파일 중
3개 파일을 먼저 재작성한 뒤, 변경 작업과 분리된 세션에서 Claude가 두 차례 적대적으로 검토함
64개 AI 에이전트의 병렬 작업
- 파일을 서로 독립적으로 처리할 수 있도록 작업을 나누고
64개 AI 에이전트를 병렬로 실행함 - 초기에는 여러 에이전트가 같은 저장소 상태를 건드리면서 충돌이 발생함
- 한 에이전트가
git stash
를 실행한 뒤 다른 에이전트가 git stash pop
과 git reset HEAD --hard
를 실행함
-
에이전트마다 별도 worktree를 할당하면 Bun 저장소 크기 때문에 디스크 공간이 부족해지고, 변경 사항을 결국 함께 컴파일해야 하는 제약도 있었음
-
워크플로를 고쳐 특정 파일을 즉시 커밋하는 명령 외에는
git stash
, git reset
등의 Git 명령을 금지하고, cargo
와 실행 시간이 긴 명령도 사용하지 못하게 함
- 최종적으로
4개 worktree에 작업을 분할하고, 각각 16개의 Claude가 파일을 커밋하고 푸시하도록 구성함 - 에이전트들은 이틀 동안 535,496줄의 Zig 코드를 옮겼고, 각 커밋은 반영 전에 두 차례 적대적 검토를 거침
컴파일 오류와 테스트 수정
- 최초 변환은 끝났지만 코드가 컴파일되지 않아, Rust의 최상위 컴파일 단위인
crate별로 Claude가 오류를 수정함 - 단계 제목에는 약 1,600개의 컴파일 오류가 적혀 있지만, 인용문에서는 순환 의존성을 해결하는 과정에서 약
16,000개 오류가 드러난 것으로 나옴 - 오류 수정 과정도 병렬화함
- 각 crate에서
cargo check
를 실행함
-
출력을 파일별로 묶어 오류 파일을 저장함
-
해당 crate의 컴파일 오류를 모두 수정함
-
두 명의 적대적 검토자가 변경 사항을 확인함
-
한 명의 수정 담당 에이전트가 검토 결과를 반영함
-
에이전트들은 자정부터 오전 11시 30분까지 사람의 개입 없이 컴파일 오류를 수정함
-
이후 약 이틀 동안 대규모 테스트 스위트를 로컬에서 컴파일 오류 없이 실행할 수 있게 만들고, 실패하는 테스트를 고쳐
CI를 통과시키는 데 추가로 수일을 투입함 -
모든 테스트 통과와 동작 확인 후 변경 사항을 병합했으며, 계획부터 완료까지 총 11일이 걸림
-
약 55만 줄의 코드 이식
-
6,500개 커밋
-
64개 에이전트 사용
비용과 수작업 대비 결과
-
Fable API 가격 기준 전체 재작성 비용은
16만 5,000달러임 -
비캐시 입력 토큰 59억 개
-
출력 토큰 6억 9,000만 개
-
캐시 입력 토큰 읽기 720억 개
-
Anthropic은 API 토큰에 마진을 붙여 판매하므로 실제 내부 비용은 이보다 낮음
-
API 비용은 미국 중간급 기업 소프트웨어 엔지니어의 연간 기본급과 비슷하지만, 같은 급여의 엔지니어 한 명이 11일 안에 같은 성과를 내기는 불가능하다고 평가함
-
Fable은 명확한 보상 함수가 있는
어렵고 집중된 작업에서 특히 뛰어나다는 Mitchell Hashimoto의 평가와도 일치함 -
수작업이라면 코드베이스를 완전히 아는 엔지니어 3명이 약 1년간 필요했을 것으로 예상함
-
그동안 Node.js 호환성 개선, 버그와 보안 문제 수정, 신규 기능 구현을 진행하기 어려움
-
현실적인 대안은 재작성하지 않고 기존 메모리 버그를 계속 수정하는 것이었음
다른 프로젝트에 적용하기 위한 조건
-
AI가 1년 걸릴 재작성이나 마이그레이션을 일주일 수준으로 단축한다면, 이전에는 검토하기 어려웠던 프로젝트도 실행 가능해짐
-
Bun의 작업 흐름을 재사용하려면 세 가지 조건이 필요함
-
코드베이스를 매우 잘 알고 작업 의지가 강한
엔지니어 -
테스트 통과를 실제 동작의 근거로 신뢰할 수 있을 만큼 강력한
테스트 스위트 -
성공 여부를 미리 알 수 없는 상태에서도 상당한 토큰 비용을 투자할 의지
-
코드 마이그레이션 같은 반복 작업은 LLM이 비교적 잘 처리하므로, 좋은 테스트와 문제를 정리할 엔지니어가 있다면 성공 가능성이 높음
-
모든 프로젝트에 16만 5,000달러가 필요한 것은 아님
-
더 단순한 프로젝트라면 비용이 낮아질 수 있음
-
고수준 계획에는 가장 비싼 모델을 쓰고, 코딩과 검토에는 더 저렴한 모델을 배치할 수 있음
-
AI 기반 마이그레이션은 빨라지고 있지만, Bun처럼
잘 엔지니어링된 프로젝트에서만 이러한 속도를 실현할 수 있음
댓글과 토론
AI 자동 생성 콘텐츠
본 콘텐츠는 GeekNews의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기