Zig의 간판이었던 Bun, Rust 재작성 8개월 차 — 62만 줄 중 38%가 넘어갔습니다

작년 11월, Bun의 창시자 Jarred Sumner가 'Bun을 점진적으로 Rust로 재작성하겠다'고 발표했을 때 Zig 커뮤니티는 배신으로, Rust 커뮤니티는 승리 선언으로 받아들였는데요. Bun이 뭐냐면, Node.js를 대체하는 초고속 자바스크립트 런타임에 패키지 매니저와 번들러, 테스트 러너까지 올인원으로 담은 도구예요. 그리고 무엇보다 Zig 언어의 간판 프로젝트였죠. 발표로부터 8개월이 지난 지금, 이 마이그레이션을 처음부터 추적해 온 한 개발자가 관련 PR과 팀이 공개하는 마이그레이션 대시보드, 직접 빌드한 카나리 버전을 근거로 중간 점검 글을 올렸어요.

숫자로 본 진행 상황

발표 시점에 약 62만 줄이던 Zig 코드 중 약 38%가 Rust로 전환됐어요. 패키지 매니저인 bun install은 전부 Rust가 됐고, 테스트 러너와 셸, 트랜스파일러 대부분도 넘어갔고요. 반면 이벤트 루프, JavaScriptCore 바인딩, 스트림 구현 같은 런타임 코어는 아직 Zig이고, 1년은 더 Zig로 남을 수 있다고 해요. 팀이 내건 '2026년 말 Rust 전환 완료' 목표는 낙관적이긴 해도 터무니없지는 않다는 평가예요.

흥미로운 건 '어떻게' 하고 있느냐예요

팀은 zig2rs라는 자체 변환 툴을 만들어서 기계적인 번역의 70%를 자동으로 처리하고, 나머지 30%는 CI에서 도는 코딩 에이전트가 테스트 스위트를 통과할 때까지 반복 수정한 뒤, 마지막에 사람이 PR을 리뷰하는 방식으로 진행하고 있어요. 발표 당시 Jarred는 'Zig 엔지니어 채용이 Bun 성장의 가장 큰 병목'이라고 했는데, 실제로 Rust 부분의 신규 기여자 수가 Zig 시절의 4배 수준으로 늘었다고 하니 그 베팅은 통하고 있는 셈이죠.

성능은 애매한 부분이에요

Rust로 다시 쓴 bun install은 오히려 8% 느려졌어요. 아직 Zig로 남아 있는 코어와의 FFI 경계에서 데이터 복사가 늘었기 때문인데요. FFI가 뭐냐면 서로 다른 언어의 코드끼리 함수를 호출하는 통로인데, 이 경계를 넘을 때마다 데이터를 복사해야 하면 그만큼 비용이 생기거든요. 이벤트 루프까지 Rust가 되면 사라질 임시 비용이라는 게 팀의 설명이에요. 반대로 테스트 러너는 12% 빨라졌는데, 옛 Zig 구현이 이후에 나온 스케줄링 개선들을 반영하지 못한 코드라 재작성하면서 공짜로 얻은 이득이래요. 글쓴이의 정리가 인상적인데요. 이건 Rust 대 Zig의 속도 싸움이 아니라, 재작성이란 누적된 미세 최적화를 잃는 대신 누적된 우회 코드를 벗어던지는 양날의 검이라는 거예요. 메모리 안전성 쪽은 2025년에 나온 Bun의 CVE 11건 중 6건이 Zig 코드의 메모리 안전성 버그였고 Rust 부분은 아직 0건인데, Rust 코드가 가장 새것이고 가장 많이 리뷰된 코드라 아직 의미를 부여하긴 이르다고 신중하게 짚었고요.

업계 맥락

Zig 커뮤니티의 반응도 분노를 넘어 흥미로운 방향으로 갔어요. Zig 코어 팀이 릴리스 빌드에도 런타임 안전 검사를 넣는 'zig-hardened'라는 빌드 모드를 시작했는데, 누가 봐도 Bun이 떠난 이유에 대한 응답이거든요. 간판 프로젝트를 잃는 게 언어를 더 단단하게 만들 수도 있는 거죠. 그리고 글쓴이가 가장 곱씹는 대목은 이거예요. 이 마이그레이션은 코딩 에이전트 이전에는 경제적으로 불가능했다는 것. 62만 줄 재작성은 원래 대규모 팀이 3~4년을 갈아 넣어야 하는 일이었는데, 지금 Bun은 엔지니어 5명과 변환 툴, CI 예산으로 해내고 있어요. 다만 그렇게 만든 코드가 10년을 유지보수할 만큼 좋은지는 아직 아무도 모른다는 단서가 붙지만요.

우리에게 주는 시사점

레거시 마이그레이션을 고민하는 팀이라면 여기서 쓰인 패턴, 그러니까 점진적 전환에 탄탄한 테스트 스위트를 안전망으로 깔고, 자동 변환과 에이전트 반복과 휴먼 리뷰를 층층이 쌓는 파이프라인은 규모를 줄여서 우리 프로젝트에도 적용해 볼 만한 틀이에요. 재작성의 비용 구조 자체가 바뀌고 있다는 신호이기도 하고요.