스크롤을 멈추게 할 숫자

535,496줄의 Zig. 100만 줄 이상의 Rust로 포팅되었습니다. 단 11일 만에. API 비용 $165,000를 들여서 말이죠. 병합 전까지 6개 플랫폼에서 테스트 생략이나 삭제 없이 100% 통과율을 기록했습니다.

이것이 바로 Bun입니다. Anthropic이 2025년 12월에 인수하여 현재 Claude Code를 실행하는 데 의존하고 있는 JavaScript 런타임(runtime)인 Bun이, Jarred Sumner가 주로 대시보드를 지켜보는 동안 Claude 에이전트 군단에 의해 Zig에서 Rust로 완전히 재플랫폼화되었습니다.

만약 당신의 첫 번째 반응이 "저렇게 배포하는 게 안전할 리가 없어"라면, 당신이 틀린 것은 아닙니다. 만약 당신의 두 번째 반응이 "이것이 현재 소프트웨어 엔지니어링의 모습이다"라면, 당신 또한 틀린 것이 아닙니다. 이 두 가지 생각을 모두 품어보세요.

실제로 일어난 일

Bun의 코어(core)는 첫날부터 Zig였습니다. Zig는 Sumner에게 제어권과 속도를 제공했습니다. 하지만 동시에 Bun에 고질적이고 반복적인 버그 클래스를 안겨주었습니다. use-after-free, double-free, 그리고 에러 경로에서 메모리 해제를 잊어버리는 문제들 — 이는 전형적인 수동 메모리 관리(manual-memory-management)의 대가였으며, Bun의 런타임이 JS 가비지 컬렉터(garbage collector)와 Zig의 수동 할당(manual allocation)을 혼합하여 사용하기 때문에 더욱 악화되었습니다. 두 개의 메모리 모델, 하나의 코드베이스, 그리고 지속적인 마찰이 발생했습니다.

지난 3월, 명시적으로 요청하지 않았음에도 소스맵(sourcemaps)을 생성하는 번들러(bundler) 버그로 인해 Bun의 소스 코드 512,000줄이 유출되었습니다. 그것이 경종을 울리는 계기가 되었습니다. Sumner의 진단은 다음과 같았습니다: Zig는 이 작업을 위해 만들어지지 않았으며, 앞으로도 그럴 것이라는 점입니다. Rust의 빌로우 체커(borrow checker)는 이러한 버그 클래스의 대부분을 새벽 2시의 사고가 아닌 컴파일 에러(compile errors)로 바꿔줍니다.

그래서 그들은 점진적인 마이그레이션(migration) 대신 다음과 같은 방식을 택했습니다:

• 모든 Zig 관용구(idiom)를 그에 상응하는 Rust 표현으로 매핑한 PORTING.md 작성
• 에이전트들이 빌림 검사기(borrow checker)와 무작정 싸우지 않도록 구조체 필드의 수명(lifetimes)을 미리 주석 처리한 LIFETIMES.tsv 작성
• 본격적인 작업에 착수하기 전, 접근 방식을 검증하기 위해 3개 파일로 구성된 시험 운영 실시
• 4개의 git 워크트리(worktrees)에 걸쳐 최대 64개의 Claude 에이전트가 병렬로 작동하는 50개의 동적 워크플로(dynamic workflows) 가동
• 모든 구현 사항은 버그를 찾는 것만을 유일한 임무로 하는 2개의 별도 Claude 인스턴스에 의해 적대적 검토(adversarially reviewed)를 받음
• 1,448개의 .zig 파일을 .rs로 변환하며 11일 동안 6,778개의 커밋(commits)을 생성했으며, 분당 최대 1,300줄의 코드와 시간당 695개의 커밋이라는 정점을 기록함

토큰 비용: 캐시되지 않은 입력 토큰 59억 개, 출력 토큰 6억 9천만 개, 캐시된 입력 읽기 720억 개. 그것이 바로 16만 5천 달러($165K)입니다.

결과는 진정으로 훌륭합니다

이것은 단순히 "기술적으로 컴파일은 된다"는 식의 이야기가 아닙니다:

HTTP 처리량 (Bun.serve):     169.6k → 177.7k req/s   (+4.8%)
fastify:                          91.5k → 95.9k req/s    (+4.8%)
express:                          64.5k → 66.6k req/s    (+3.2%)
...

v1.3.14에서 발견된 128개의 알려진 버그가 v1.4.0에서 재현 가능한 방식으로 모두 수정되었습니다. 포팅 과정에서 19개의 새로운 회귀(regressions)가 나타났으나, 이는 모두 언어 간의 실제 의미론적 차이(semantic gaps)에서 비롯된 것이었습니다(예: Zig의 assert는 항상 실행되지만, Rust의 debug_assert!는 릴리스 빌드에서 컴파일되어 제외되는 것과 같은 차이). 이 모든 문제는 병합(merge) 전에 포착되어 수정되었습니다.

이것은 바이브 코딩(vibe coding)이 아닙니다. 이것은 매우 비싼 컴파일러를 사용하는, 컴파일러 보조 방식의 형식적 마이그레이션(formal migration)에 더 가깝습니다.

그러자 Zig의 창시자가 이를 불태워버렸습니다

Andrew Kelley는 Rust를 공격한 것이 아닙니다. 그는 그 과정을 공격했습니다:

"우리는 Bun의 코드베이스에서 보이는 프로그래밍 관행을 보며 점점 더 경악했습니다... Zig 코드에서 버그를 잡아내는 것만으로는 충분하지 않은데, 검토되지 않은 쓰레기(unreviewed slop) 백만 줄에서 버그를 잡아내는 것이 과연 충분하단 말입니까?"

그의 요점은 감정을 걷어내도 변함없습니다: 테스트 스위트는 그것이 실제로 중요한 코드 경로를 실행한다는 당신의 확신만큼만 신뢰할 수 있습니다. 만약 그 동일한 스위트가 애초에 이 전체 재작성을 유발했던 메모리 버그를 막지 못했다면, 왜 지금 통과하는 것이 새로운 백만 줄 규모의 Rust 코드가 안전하다는 것을 증명합니까? 당신은 테스트 스위트를 재작성이 필요했던 이유와 그 재작성이 안전하다는 유일한 증거로 동시에 사용할 수 없습니다.

Zig 프로젝트는 바로 이러한 이유 때문에 컴파일러 자체에 AI가 생성한 기여를 금지하는 정책을 가지고 있습니다. Kelley가 여기에서 러다이트(Luddite)가 아니라는 뜻입니다. 그는 일관된 기준을 적용하고 있으며, Bun은 그 자신의 잣대에 따라 이 기준을 통과하지 못하고 있습니다.

Sumner의 반론 역시 공정합니다: 인간이 Zig 백만 줄을 한 줄씩 읽어본 적 있는 사람은 아무도 없습니다. 규모가 크든 AI가 작성했든 수동 검토를 완전히 할 수는 없습니다. 진정한 안전망은 항상 테스트 스위트와 프로덕션 트래픽, 그리고 시간 그 자체였습니다. Bun은 이것을 안정 버전(stable)으로 바로 출시한 것이 아니라 카나리아 배포(canary) 뒤에 배치했습니다.

누가 실제로 옳은가

둘 다입니다. 그것이 불편한 부분입니다.

Kelley가 옳습니다. '100% 테스트 통과'는 전면적인 재작성에 대한 안전 주장으로는 생각보다 훨씬 약합니다. 테스트를 통과한다는 것은 새로운 코드가 이전 테스트가 예상했던 대로 작동한다는 것을 의미할 뿐, 새로운 코드가 _정확하다_는 것을 의미하지 않으며, 게다가 검토자가 에이전트가 중간에 내린 설계 결정에 대해 승인한다는 것을 의미하지도 않습니다.

Sumner가 옳습니다. '모든 줄을 인간이 읽었는지'를 기준으로 삼는 것은 결코 현실적이지 않았고, 대규모 코드베이스가 10년 동안 검증되어 온 방식도 아닙니다. 실제 기준은 항상 더 나은 테스트 커버리지, 단계적 출시(staged rollout), 빠른 롤백(fast rollback), 그리고 프로덕션 모니터링이었습니다. Bun은 그 기준을 충족했습니다. 이것이 Claude Code 자체가 의존하는 런타임에 올바른 기준인지 여부는 합법적이고 열린 질문입니다. 이는 확정된 것이 아니며, 현재 Hacker News에서 어느 쪽의 목소리가 더 크든 상관없습니다.

직업으로 코딩을 한다면 이것이 의미하는 바

이 이야기에 대해 "AI가 엔지니어를 대체한다"는 헤드라인 버전은 무시하십시오. 그런 일은 일어나지 않았습니다. 실제로 일어난 일은, 에이전트 군단을 보유한 한 명의 엔지니어가 2년 전이었다면 여러 팀이 몇 분기 동안 매달려야 했을 6자리 수 달러 규모의 인프라 마이그레이션(infrastructure migration)을 11일 만에 해냈다는 것입니다. 희소 자원은 "타이핑 속도"에서 "출력물을 신뢰할 수 있을 만큼 충분히 좋은 검증 하네스(verification harness)를 설계할 수 있는가"로 이동했습니다.

AI의 도움을 받아 대규모 변경 작업을 수행하고 있다면, 이번 재작성 사례에서 얻을 수 있는 교훈은 구체적입니다:

1. 코드를 작성하기 전에 포팅 사양(porting spec)을 작성하십시오. PORTING.md와 LIFETIMES.tsv는 단순한 잡무가 아니었습니다. 그것들은 64개의 병렬 에이전트가 동일한 라이프타임(lifetime) 문제에 대해 64개의 서로 다른 설계 결정을 내리지 않도록 막아준 역할을 했습니다.
2. 적대적 검토(Adversarial review)가 셀프 검토(self-review)보다 낫습니다. 타인(또는 다른 무언가)의 출력물에서 버그를 찾는 것만을 유일한 임무로 하는 별도의 에이전트는 인간과 마찬가지로 단 한 번의 패스(pass)에서 놓치는 것들을 잡아냅니다.
3. 당신이 인정하든 안 하든, 테스트 스위트(test suite)가 실제 사양입니다. 만약 재작성 과정의 버그를 잡아낼 것이라고 믿지 못한다면, 그것은 AI의 문제가 아니라 이미 당신이 가지고 있던 커버리지(coverage)의 문제입니다.
4. 모든 것에 항상 카나리(Canary)를 적용하십시오. 이것이 사고 보고서가 아닌 사례 연구(case study)가 될 수 있었던 전적인 이유는, 이것이 안정(stable) 채널이 아닌 카나리 채널에 배포되었기 때문입니다.

기억해야 할 숫자는 100만 줄이나 16만 5천 달러가 아닙니다. 대부분의 팀이 6~12개월로 범위를 산정했을 마이그레이션을 단 11일 만에 끝냈다는 사실입니다. 그 격차가 앞으로 많은 인프라 작업이 계획되는 방식을 정의하게 될 것입니다.

직접 소스와 드라마를 읽어보십시오 — Bun의 자체 글에는 전체 방법론이 담겨 있으며, The Register의 보도에는 논쟁의 전말이 나와 있습니다. Simon Willison의 분석은 그 결과 Claude Code에 무엇이 배포되었는지에 대한 가장 중립적인 요약입니다.