출처
Bun이 Zig 약 53.5만 줄을 64개 AI 에이전트로 Rust에 옮겨,
사람이라면 1~2년 걸릴 재작성을 11일에 끝낸 사례를
Pragmatic Engineer가 "무엇을 배울 수 있는가"로 풀어쓴 글입니다.
•
동기: Zig 쪽 메모리 누수·충돌·OOB 등 안정성 피로
•
방법: PORTING.md(약 600줄) → 파일 병렬 이식 → 적대적 리뷰 2회 → 컴파일 수정 → 테스트/CI
•
규모: ~6,500 커밋 / API 기준 약 $165,000 / 막대한 토큰 사용
•
요지: "AI가 재작성을 싸게 만든다"보다, 재작성이 현실 옵션이 됐다
원인 파악을 해봅시다 :)
재작성이 역사적으로 최악인 이유:
1. 예상 9개월
2. 그동안 원본에 기능이 계속 추가됨
3. 따라잡기 게임 → 18개월~2년+
4. 그동안 사용자 체감 개선 = 0
Plain Text
복사
Bun 규모(주석 제외 Zig 535,496 LOC)면
숙련 엔지니어 소수에게 약 1년이 자연스러운 추정입니다.
그건 "제품 개선을 1년 멈추는 선택"이라 사실상 불가능에 가깝습니다.
그래서 나온 질문:
일주일 안에 Fable로 Rust 이식이 가능한지부터 검증하면?
여기서 우리가 꼭 알아가야할 핵심 개념!!: 보상 함수가 뚜렷한 마이그레이션
Mitchell Hashimoto 쪽 평가와도 맞물리는 포인트:
LLM은 어렵고 집중된 작업 + 명확한 성공 신호(컴파일·테스트)에서 특히 강하다.
Bun 플로우를 단계로 보면:
단계 | 내용 |
설계 | Claude와 ~3시간 패턴 매핑 → PORTING.md |
파일럿 | 1,448개 중 3파일 이식 + 별도 세션에서 적대적 리뷰 2회 |
병렬 | 64 에이전트, 파일 단위. git stash/reset 금지로 충돌 차단 |
컴파일 | crate별 cargo check → 오류 묶음 수정 (순환 의존 풀며 ~16k 오류도 등장) |
검증 | 로컬 테스트 실행 가능하게 → CI 그린 → 머지 (총 11일) |
PORTING.md의 제약 예시 (구조 보존이 목표):
no tokio / rayon / hyper / async-trait / futures
no std::fs·net·process (Bun이 이벤트 루프·syscall 소유)
no async fn → 콜백 + 상태머신 (Zig와 동일)
borrowck 회피용 raw pointer 금지, 필요 시 reshape + PORT NOTE
Plain Text
복사
한 줄: 에이전트에게 "알아서 Rust답게"가 아니라, 옮기는 규칙과 금지 목록을 먼저 준 것이 핵심이다.
왜 Rust인가 (Zig 비난이 아님)
Jarred의 프레임:
•
Zig 사용자 전부가 같은 버그를 겪는 것은 아님
•
Bun의 특수성: GC 값 수명 + 수동 메모리를 같이 다루는 일
•
use-after-free / double-free / 에러 경로 forgot-to-free → safe Rust에선 컴파일·Drop으로 상당수 차단
•
자체 스마트 포인터는 Rust보다 DX가 나쁘고 보장도 약함
즉 "Zig 실패담"이 아니라 문제 영역이 메모리 안전 컴파일 타임 피드백과 맞았다는 이야기입니다.
(참고: Roc은 반대로 Rust→Zig 재작성 보고서를 낸 바 있음. 방향이 달라도 "프로젝트 단위 언어 선택"은 같습니다.)
비용과 반복 가능성
API 가격 기준 대략:
항목 | 규모 |
비용 | ~$165k |
uncached input | 59억 토큰 |
output | 6.9억 토큰 |
cached input reads | 720억 토큰 |
수작업 대안: 코드베이스를 아는 엔지니어 3명 × ~1년
→ 그동안 Node 호환·보안·기능 개발 정지 → 안 했을 것
다른 팀이 따라 하려면 최소 세 조건:
1. 코드베이스를 깊게 아는 동기 부여된 엔지니어
2. 통과하면 "된다"고 믿을 수 있는 테스트 스위트
3. 성공이 불확실해도 토큰 비용을 감수할 의지
Plain Text
복사
모든 프로젝트에 $165k가 필요한 것은 아닙니다.
계획(비싼 모델) / 코딩·리뷰(저렴한 모델) 분리로 줄일 여지도 있습니다.
자주 하는 오해들입니다!
오해 1. "프롬프트 한 줄로 끝냈다"
실제로는 규칙 문서, 파일럿, 워크플로 수정(에이전트끼리 git으로 打架),
심야 자율 컴파일 픽스, 수일간의 테스트/CI 픽스가 이어집니다.
오케스트레이션이 제품입니다.
오해 2. "우리 레포도 다음 주 언어 바꾸자"
테스트가 약하거나, 도메인 문맥을 가진 사람이 없으면
빠른 이식은 빠른 잘못된 이식이 됩니다.
오해 3. "Roc 487일 vs Bun 11일 = 언어/AI 우열"
한쪽은 구조·기능까지 바꾸는 컴파일러 재작성,
한쪽은 실행 구조를 보존하는 대규모 포팅에 가깝습니다. 직접 비교하면 안 됩니다.
정리해봅시다!
1.
Bun 사례의 진짜 뉴스: 대규모 재작성이 일정·비용 면에서 선택지가 됐다.
2.
성공 공식은 모델 이름보다 규칙 문서 + 병렬 워크플로 + 적대적 리뷰 + 테스트.
3.
동기는 취향이 아니라 GC×수동 메모리가 만든 안정성 비용이었다.
4.
$165k는 비싸 보이지만, "1년 제품 정지"와 비교하면 다른 방정식이다.
5.
따라 하려면 엔지니어·테스트·토큰 감수 — 셋 중 하나라도 없으면 블루프린트가 성립하지 않는다.
