AI로 11일 만에 끝낸 Bun의 Zig→Rust 재작성에서 배울 점 — 개발자가 알아야 할 핵심 정리

535,496줄의 Zig 코드와 64개 AI 에이전트. Bun의 사례는 대규모 언어 전환이 더 이상 몇 년짜리 프로젝트로만 남지 않을 수 있다는 점을 보여줍니다. 다만 핵심은 에이전트 숫자가 아니라, 사람이 설계한 제약과 검증 루프입니다.

원문 요약: 메모리 안전성이 없는 Zig에서 누수와 충돌이 계속되자, Bun은 535,496줄의 코드를 64개 AI 에이전트로 Rust에 옮겨 1~2년 걸릴 작업을 11일로 단축함 성공의 출발점은 600줄짜리 PORTING.md였으며, 파일별 병렬 변환과 두 차례 적대적 검토, 컴파일 오류 수정…

Bun이 Rust 재작성을 선택한 이유

Bun은 JavaScript와 TypeScript 변환, 번들링, 축소, 테스트 러너, npm 호환 패키지 관리자, 모듈 해석과 WebSocket 기능을 함께 제공하는 복잡한 프로덕션 프로젝트입니다. 월간 다운로드가 2,200만 건에 이르고 Claude Code와 OpenCode가 의존하는 기반이어서, 메모리 오류를 조금씩 고치는 방식만으로는 장기 비용을 줄이기 어려웠습니다.

Zig는 빠르고 낮은 수준의 제어가 가능하지만 메모리 안전을 언어 차원에서 보장하지 않습니다. Bun 팀은 컴파일러 패치와 종단 간 누수 테스트를 도입했지만, 가비지 컬렉션 값과 수동 관리 값의 수명을 함께 다루는 과정에서 누수와 간헐적 충돌이 남았습니다. Rust에서는 use-after-free와 double-free 같은 문제가 컴파일 오류로 드러나고, Drop 기반 자동 정리가 오류 경로의 누락을 줄여 줍니다.

재작성 프로젝트가 오래 걸리는 진짜 이유

일반적인 재작성은 원래 코드베이스에 기능이 계속 추가되면서 목표가 움직입니다. 9개월로 잡은 작업이 9개월 뒤에도 6개월 남고, 기능 동결을 하더라도 사용자에게 보이는 개선 없이 긴 시간을 보내야 합니다. Bun의 선택은 이 지연 구조를 먼저 깨는 것이었습니다.

처음부터 전체를 무작정 번역하지 않고, 먼저 Zig 패턴을 Rust에 대응시키는 600줄짜리 PORTING.md를 만들었습니다. 이 문서는 에이전트가 편리해 보인다는 이유로 아키텍처를 바꾸지 못하도록 경계를 정했습니다.

속도의 출발점은 600줄짜리 설계 문서

• tokio, rayon, hyper, async-trait, futures 같은 새 의존성을 임의로 도입하지 않기
• std::fs, std::net, std::process처럼 I/O를 직접 다루는 모듈을 금지하기
• Bun이 소유한 이벤트 루프와 시스템 호출 구조를 유지하고, async fn 대신 기존 콜백과 상태 머신을 따르기
• 빌림 검사기와 충돌하면 원시 포인터로 우회하지 않고 구조를 바꾼 위치에 이식 메모를 남기기
• 작은 샘플을 먼저 변환하고, 변경 세션과 분리된 세션에서 적대적 검토를 수행하기

이런 문서는 단순한 사용 설명서가 아닙니다. 여러 에이전트가 동시에 작업해도 결과가 한 방향으로 수렴하도록 만드는 실행 계약입니다.

64개 에이전트 병렬화에서 얻는 교훈

파일을 서로 독립적으로 처리할 수 있도록 나누고 64개 에이전트를 병렬로 실행했지만, 초기에는 같은 저장소 상태를 만지면서 충돌이 발생했습니다. 한 에이전트의 git stash가 다른 에이전트의 작업을 흔들 수 있었고, 별도 worktree를 많이 만들면 저장 공간이 문제가 됐습니다.

최종 워크플로는 4개 worktree에 작업을 분할하고, 각 worktree에서 16개의 Claude가 파일을 커밋하고 푸시하도록 바뀌었습니다. 동시에 git stash, git reset 같은 위험한 명령과 장시간 명령을 금지했습니다. 병렬화의 본질은 작업자 수가 아니라 충돌 표면을 줄이는 운영 설계입니다.

컴파일 오류를 검증 루프로 바꾸기

최초 변환이 끝났을 때 코드는 바로 컴파일되지 않았습니다. 이후에는 crate 단위로 cargo check를 실행하고 오류를 파일별로 묶어 담당 에이전트에 배분했습니다. 수정 담당 에이전트가 오류를 고치면 두 명의 적대적 검토자가 확인하고, 다시 수정 담당자가 검토 결과를 반영하는 순서였습니다.

컴파일 성공은 끝이 아니라 다음 검증의 시작이었습니다. 대규모 테스트 스위트를 로컬에서 실행하고 실패한 테스트를 고친 뒤 CI를 통과시켰습니다. 계획부터 병합까지 총 11일이 걸렸지만, 그 기간의 대부분은 번역 자체보다 컴파일·테스트·검토 루프에 쓰였습니다.

설계 문서 → 작은 변환 → 적대적 검토 → 병렬 이식 → crate별 컴파일 → 테스트 → CI → 병합

비용은 16만 5,000달러, 하지만 비교 기준이 중요하다

Fable API 가격 기준으로 전체 재작성에는 약 16만 5,000달러가 들었습니다. 비캐시 입력 59억 토큰, 출력 6억 9,000만 토큰, 캐시 입력 읽기 720억 토큰이 사용됐습니다. 숫자만 보면 큰 비용이지만, 비교 대상은 단순한 번역 도구가 아니라 코드베이스를 깊이 아는 엔지니어 3명이 약 1년 동안 제품 개선과 버그·보안 수정 대신 재작성에 매달리는 비용입니다.

그렇다고 모든 팀이 같은 방식을 따라야 한다는 뜻은 아닙니다. 작은 프로젝트는 비용이 낮고, 계획·검토에는 강한 모델을 쓰되 반복 코딩에는 더 저렴한 모델을 배치할 수 있습니다. 중요한 것은 비용 상한을 정하고, 실패했을 때 중단할 기준을 미리 정하는 일입니다.

다른 프로젝트에 적용하기 위한 체크리스트

1. 코드베이스를 아는 사람을 먼저 배치합니다. 에이전트가 모르는 구조를 자동으로 추측하게 두지 말고, 금지사항과 보존해야 할 설계를 문서화합니다.
2. 테스트 스위트를 투자로 봅니다. 테스트가 약하면 병렬 에이전트가 만든 그럴듯한 오류를 빠르게 걸러낼 수 없습니다.
3. 작업 단위를 충돌 없이 나눕니다. 파일·crate·모듈 경계를 정하고 공유 상태를 최소화합니다.
4. 검토를 별도 세션으로 분리합니다. 생성한 에이전트가 자기 결과를 승인하는 구조를 피하고 적대적 검토자를 둡니다.
5. 비용과 권한을 제한합니다. 위험한 Git 명령, 외부 시스템 변경, 장시간 실행을 기본 금지하고 필요한 경우에만 허용합니다.

결론: AI가 줄인 것은 코딩 시간이 아니라 실행 가능한 선택지다

Bun 사례의 가장 큰 의미는 11일이라는 기록 자체가 아닙니다. 이전에는 비용과 기간 때문에 검토조차 하지 못했던 메모리 안전 전환을, 강한 설계 문서와 테스트가 있다면 실제 선택지로 만들었다는 점입니다. AI 에이전트는 재작성의 책임을 대신 지지 않습니다. 대신 사람이 검증 가능한 경계를 설계했을 때, 반복 작업의 속도를 크게 높입니다.

핵심 요약: 좋은 문서가 방향을 고정하고, 병렬화가 속도를 만들며, 컴파일·테스트·적대적 검토가 신뢰를 만듭니다. 셋 중 하나라도 빠지면 64개 에이전트는 생산성 도구가 아니라 64배로 커진 디버깅 비용이 될 수 있습니다.

---

📰 원본 출처 · https://news.hada.io/topic?id=31890 (#N=31890)

이 글은 GeekNews(긱뉴스)에 게시된 글을 기반으로 작성되었습니다. 원문의 라이선스와 저작권은 원작자에게 있습니다.