5P by GN⁺ | ★ favorite | 댓글과 토론
  • 메모리 안전성이 없는 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 popgit 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처럼 잘 엔지니어링된 프로젝트에서만 이러한 속도를 실현할 수 있음

댓글과 토론