Bun이 Zig 기반 구현을 Rust로 옮겼다. 표면적으로는 Claude를 대규모로 동원해 짧은 기간에 코드를 옮긴 사건처럼 보인다. 실제로 Jarred Sumner는 Claude Fable 5의 사전 출시 버전을 사용했고, 약 64개의 Claude 인스턴스가 11일 동안 병렬로 실행됐으며, API 비용은 약 16만5천 달러에 달했다.2
하지만 이 이야기의 핵심은 “AI가 얼마나 많은 코드를 썼는가”가 아니다. 더 중요한 질문은 이것이다. Bun은 왜 이미 빠르게 성장한 런타임의 내부 구현 언어를 바꿔야 했을까?
재작성의 출발점은 메모리 버그였다
Bun이 Rust로 이동한 핵심 이유는 성능보다 메모리 안정성이었다. 문제가 된 버그 유형에는 use-after-free, double-free, 오류 경로에서 free를 빠뜨리는 문제가 포함됐다.1
use-after-free는 이미 해제한 메모리를 다시 사용하는 버그다. double-free는 같은 메모리를 두 번 해제하는 문제다. 이런 버그는 재현이 어렵고, 원인 추적도 까다롭다. 특히 런타임처럼 복잡한 시스템에서는 한 번의 실수가 크래시나 보안 문제로 이어질 수 있다.
이것이 Zig가 나쁜 언어라는 뜻은 아니다. Bun의 조건이 특히 까다로웠다는 쪽에 가깝다. Bun은 JavaScriptCore 같은 GC 기반 엔진과 수동 메모리 관리를 함께 다룬다. 이 환경에서는 “누가 이 메모리를 소유하는가”, “언제 해제해야 하는가”, “오류가 난 경로에서도 정리가 되는가”를 개발자가 계속 맞춰야 한다.
Rust는 이 부담의 일부를 컴파일러 쪽으로 옮긴다. safe Rust 영역에서는 use-after-free와 double-free가 컴파일 오류로 처리될 수 있고, Drop은 RAII와 유사하게 값의 수명이 끝날 때 정리 로직을 실행한다.1 즉 Rust 전환의 의미는 런타임에서 발견되던 일부 문제를 빌드 단계에서 더 일찍 발견하도록 만든 데 있다.
대규모 재작성의 조건은 “테스트 가능한 경계”다
대규모 재작성은 일반적으로 위험한 선택이다. 기존 동작을 다시 구현하는 과정에서 예전 버그를 반복할 수도 있고, 전혀 새로운 버그를 만들 수도 있다. 그래서 “언어를 바꾸면 좋아진다”는 판단만으로는 부족하다.
Bun이 이 위험을 낮출 수 있었던 중요한 조건은 테스트 스위트가 TypeScript로 작성되어 있었다는 점이다.1 테스트가 구현 언어에 묶여 있지 않으면, 내부가 Zig든 Rust든 같은 외부 동작을 요구할 수 있다. 이 테스트 스위트는 언어 독립적인 적합성 테스트 역할을 했고, 초기 Zig-to-Rust 포팅 자동화에도 사용됐다.1
여기서 AI의 역할도 더 정확히 볼 수 있다. AI가 코드를 많이 생성했다는 사실만으로 재작성의 성공을 설명할 수는 없다. 중요한 것은 생성된 코드를 검증할 기준이 있었다는 점이다. 테스트가 실패를 알려주고, 사람이 리뷰하며, 다시 수정하는 반복 루프가 있었기 때문에 대량의 포팅 작업을 다룰 수 있었다.
AI는 재작성의 속도를 높인 도구였지만, 재작성의 안전망은 테스트와 검증 구조였다.
Rust 선택은 취향보다 운영 비용의 문제다
Bun v1.4.0은 Rust 기반 첫 버전으로 canary 채널에 제공되고, v1.3.14는 마지막 Zig 버전으로 정리된다.3 이 전환이 “Rust가 항상 정답”이라는 뜻은 아니다. 더 정확한 결론은 프로젝트의 규모와 위험 유형에 따라 언어 기능이 운영 비용을 크게 바꿀 수 있다는 것이다.
작은 프로젝트에서는 명확한 스타일 가이드, 코드 리뷰, 제한된 범위의 수동 메모리 관리만으로도 충분할 수 있다. 하지만 Bun처럼 네이티브 메모리, GC, 비동기 I/O, 외부 C/C++ 라이브러리가 얽힌 런타임에서는 실수의 비용이 커진다. 이때 Rust의 소유권 모델과 Drop 같은 메커니즘은 단순한 생산성 기능이 아니라 안정성 인프라에 가까워진다.
이번 사례에서 얻을 수 있는 실용적인 기준은 분명하다.
반복되는 버그가 언어의 약한 지점에서 나오고 있는가?
그 버그를 리뷰나 규칙만으로 충분히 줄일 수 있는가?
구현 언어와 분리된 테스트 스위트가 있는가?
대규모 변경을 자동으로 검증할 수 있는가?
AI를 쓰더라도 결과물을 판정할 명확한 기준이 있는가?
Bun의 Rust 재작성은 “AI가 런타임을 다시 썼다”는 이야기로 소비되기 쉽다. 그러나 더 중요한 교훈은 검증 가능한 경계가 있을 때 대규모 변경이 현실적인 선택지가 된다는 점이다. 언어 선택은 취향의 문제가 아니라, 어떤 종류의 실수를 얼마나 일찍, 얼마나 싸게 잡을 수 있는지에 대한 운영상의 결정이다.
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.