Bun의 Zig→Rust 재작성, 11일의 기적이 아니라 ‘검증 가능한 에이전트 공정’의 승리입니다

Bun의 Zig→Rust 재작성, 11일의 기적이 아니라 ‘검증 가능한 에이전트 공정’의 승리입니다

핵심 요약: Bun 팀은 약 53.5만 줄의 Zig 코드베이스를 Rust로 옮기고, 전 플랫폼에서 테스트 스위트를 통과시키는 데 11일을 썼습니다. 핵심은 모델이 코드를 대량 생성했다는 사실이 아닙니다. 언어 독립적인 100만 assertion 테스트, 작성자와 분리된 적대적 리뷰, 오류가 나면 코드가 아니라 생성 워크플로를 고치는 루프가 결합됐다는 점입니다. AI 코딩의 병목은 생성량이 아니라 신뢰를 만들어내는 검증 체계라는 사실을 이보다 선명하게 보여주는 사례는 드뭅니다.

📌 ‘전체 재작성은 하지 말라’는 상식을 다시 묻게 만든 사건

Bun의 창업자 Jarred Sumner가 공개한 기술 글에 따르면, 대상은 주석을 제외하고도 535,496줄에 이르는 코드였습니다. 목표는 새 설계로 멋지게 갈아엎는 일이 아니라, 기존 동작·아키텍처·성능을 보존한 채 Rust의 소유권과 자동 정리 모델을 얻는 것이었습니다. 즉 ‘혁신적 리팩터링’보다 행동 보존이 우선인 기계적 포팅에 가까웠습니다.

왜 Rust였을까요. Bun은 GC가 있는 JavaScript 엔진과 수동 메모리 관리 영역이 맞물리며 use-after-free, double-free, 오류 경로의 누수처럼 수명 관리가 어려운 버그를 지속적으로 마주했습니다. 안전 Rust에서는 상당수가 컴파일 오류로 드러납니다. 이는 언어 취향의 문제가 아니라, 사후 fuzzing과 리뷰에 의존하던 오류 탐지를 더 이른 단계로 끌어오는 선택입니다.

🏗️ 모델이 아니라 공정이 만든 11일

Bun 팀은 ‘Bun을 Rust로 다시 써라. 실수하지 마라’라는 한 번의 지시를 내리지 않았습니다. 약 50개의 동적 워크플로를 11일 동안 계속 돌렸습니다. 포팅 가이드와 수명 규칙을 만들고, 파일을 기계적으로 옮기고, 크레이트별 컴파일 오류를 줄이고, 하위 명령을 살리고, 전체 테스트를 통과시키고, 마지막에 정리 작업을 수행하는 식입니다.

공정 단계	에이전트에 맡긴 일	사람이 지킨 통제점
명세화	Zig 패턴·타입을 Rust 패턴으로 매핑	포팅·수명 규칙의 기준 설정
생성·수정	파일 포팅, 컴파일 오류·테스트 실패 해결	워크플로 출력 감시와 루프 조정
검증	별도 문맥에서 변경점의 실패 가능성 탐색	병합 기준·테스트·리뷰 체계 유지

여기서 중요한 단어는 ‘동적’입니다. 워크플로가 한 번 정해지고 끝난 것이 아니라, 사람이 결과를 읽다가 문제가 보이면 다음 코드 조각이 아니라 루프 자체를 수정했습니다. 이 구조는 에이전트를 만능 개발자로 취급하지 않습니다. 재현 가능한 작업 단위와 피드백 채널을 가진 생산 라인 안에 넣습니다.

🧪 100만 assertion이 ‘언어 전환’을 가능하게 한 이유

Bun의 결정적 자산은 모델이 아니라 기존 테스트였습니다. 테스트 스위트가 TypeScript로 작성돼 있어 런타임 구현 언어에 묶이지 않았고, 포팅 전후에 같은 행동을 검증하는 언어 독립적인 적합성 시험으로 작동했습니다. 컴파일이 된다는 사실과 사용자가 같은 결과를 얻는다는 사실 사이의 큰 간극을 메운 장치입니다.

Simon Willison의 분석은 이 점을 정확히 짚습니다. 대량의 LLM 생성 코드를 책임 있게 병합할 근거는 ‘모델의 자신감’이 아니라 100만 assertion, 적대적 코드 리뷰, 그리고 오류가 생기면 생성 과정을 고치는 원칙이었다는 것입니다. 테스트가 언어에 종속돼 있었다면 대규모 포팅과 테스트 재작성이라는 두 위험을 동시에 떠안았을 것입니다.

이는 일반적인 제품 개발에도 그대로 적용됩니다. 에이전트가 작성한 코드가 빠르게 늘어날수록 테스트는 개발 막바지의 품질 체크가 아니라, 에이전트가 움직일 수 있는 안전 경계가 됩니다. 경계가 없으면 속도는 곧 검토 대기열과 운영 장애로 전환됩니다. 반대로 API 계약·회귀 테스트·관찰 가능한 완료 조건이 있으면, 에이전트의 병렬성은 위험을 폭발시키지 않고 처리량을 키울 여지가 생깁니다.

🎯 적대적 리뷰: 작성자와 검토자의 목표를 분리하다

이 프로젝트에서 특히 배울 만한 부분은 리뷰의 역할 분리입니다. 구현 에이전트는 원본 Zig 코드·포팅 계획·자신의 작업 맥락을 갖습니다. 반면 리뷰 에이전트는 변경 diff만 받고, ‘이 코드가 틀린 이유를 찾아라’는 다른 목표를 부여받습니다. 구현자는 리뷰하지 않고, 리뷰어는 구현하지 않습니다.

이는 사람 코드 리뷰에서도 통하는 원칙입니다. 코드를 만든 사람은 문제를 해결했다는 서사에 이미 투자돼 있습니다. 에이전트도 마찬가지로 자신의 앞선 추론을 정당화하는 방향으로 움직일 수 있습니다. 그래서 서로 다른 문맥 창과 상반된 목표를 주는 것은 단순한 병렬화가 아니라 확증 편향을 구조적으로 줄이는 설계입니다.

검증 방식	잡아내는 것	혼자서는 부족한 이유
컴파일러	타입·소유권·문법 오류	의미·호환성·경계 사례는 통과할 수 있음
회귀 테스트	명세화된 기존 동작의 변화	명세 밖 상호작용과 누락된 사례가 남음
적대적 리뷰	그럴듯하지만 위험한 가정과 비동기 경계	재현 가능한 자동 판정 기준이 필요함

Bun은 이 조합으로 컴파일은 되지만 비동기 close 뒤에 해제된 포인터를 다시 쓰게 되는 문제, 음수 시각 변환의 잘못된 나노초 값, 게으른 평가가 필요한 곳의 즉시 평가 같은 오류를 병합 전에 발견했다고 설명합니다. 중요한 것은 에이전트 리뷰가 인간 리뷰를 ‘대체’했다는 말이 아닙니다. 리뷰 역할을 늘리고, 각 역할이 다른 실패 모드를 탐색하게 만들었다는 데 있습니다.

💰 속도와 비용을 함께 읽어야 합니다

공개된 수치는 놀랍습니다. Bun 팀은 11일 동안 59억 uncached input token, 6.9억 output token, 720억 cached input token read를 사용했고, API 정가로 환산하면 약 16만 5천 달러라고 추정했습니다. 개인 개발자의 ‘바이브 코딩’ 비용과는 완전히 다른 규모입니다.

그래서 이 글을 ‘에이전트에게 대형 리라이트를 시키면 싸고 빠르다’는 사례로 읽어서는 곤란합니다. 같은 일을 숙련된 팀이 1년간 수행할 비용, 기능 개발을 멈춘 기회비용, 안정성 문제로 인한 손실, 그리고 이미 갖춰진 대규모 테스트 자산까지 함께 비교해야 합니다. Bun에는 Anthropic 내부에서 모델을 활용할 수 있는 특수한 환경도 있었습니다.

🧐 냉정한 평가: 이 사례에서 복제해야 할 것과 복제하면 안 될 것

제 판단으로, Bun 사례에서 가장 쉽게 잘못 복제될 것은 ‘대형 재작성’이고 가장 먼저 복제해야 할 것은 ‘검증 공정’입니다. 수십만 줄 코드를 포팅했다는 결과는 화려하지만, 대부분의 팀은 그 규모·예산·테스트 자산을 갖고 있지 않습니다. 검증이 약한 상태에서 에이전트에게 거대한 diff를 맡기는 것은 속도가 아니라 부채를 빌리는 일에 가깝습니다.

반대로 작은 팀도 적용할 수 있는 원칙은 명확합니다. 변경 전에 실행 가능한 완료 조건을 만들고, 생성과 검토를 다른 문맥으로 분리하고, 실패가 반복되면 결과물을 손으로 누르기보다 프롬프트·도구·테스트·권한 경계를 포함한 워크플로를 고치는 것입니다. 이것은 특정 모델이나 언어에 종속되지 않습니다.

또 하나의 경계도 필요합니다. 테스트가 많다고 모든 위험이 사라지지는 않습니다. 성능 퇴행, 운영 환경의 예외, 보안 경계, 제품 요구사항의 변화는 여전히 별도의 관찰성과 승인 절차를 요구합니다. Bun도 Rust 전환 후 Miri, LeakSanitizer, 지속적인 fuzzing을 추가하고 unsafe 영역을 계속 줄이겠다고 밝혔습니다. ‘테스트 통과’는 끝이 아니라 다음 안전장치로 가는 입구입니다.

🔮 팀이 다음 주부터 적용할 수 있는 세 가지

• 작은 적합성 테스트부터 분리하십시오. 구현 세부사항에 묶이지 않은 API·CLI·파일 포맷·핵심 사용자 흐름 테스트가 있어야 언어·프레임워크·모델을 바꿔도 행동을 비교할 수 있습니다.
• 구현 에이전트와 반박 에이전트를 분리하십시오. 한 에이전트가 계획·구현·자기승인을 모두 하면 빠르지만 편향도 커집니다. 리뷰 역할에는 ‘통과 조건을 찾는 것’보다 ‘실패 조건을 찾는 것’을 명시하는 편이 낫습니다.
• 반복 오류를 워크플로 개선 신호로 취급하십시오. 같은 유형의 수정이 계속 나오면 모델을 탓하거나 코드만 고치지 말고, 입력 컨텍스트·도구 출력·테스트·작업 분해 중 무엇이 빠졌는지 추적해야 합니다.

7월 12일 AI 리포트가 짚은 대로, 에이전트의 진짜 병목은 생성 능력보다 검증입니다. Bun의 Rust 전환은 그 문장을 추상적인 조언이 아니라 운영 가능한 시스템 설계로 바꿔 놓았습니다. 앞으로 경쟁력은 ‘가장 똑똑한 모델을 쓴 팀’보다, 모델이 틀릴 수 있다는 사실을 전제로 더 빠르게 반증하고 더 안전하게 수정하는 팀에 쌓일 가능성이 큽니다.

 

💡 한 줄 요약: Bun의 11일 Rust 재작성은 AI가 ‘코드를 많이 쓴’ 사건이 아니라, 테스트·적대적 리뷰·워크플로 개선이 결합될 때 대규모 AI 생성 코드를 신뢰 가능한 변경으로 바꿀 수 있음을 증명한 사례입니다.