Bun이 Zig에서 Rust로 옮겨간 일은 단순한 언어 취향의 변화로 보기 어렵다. Bun은 런타임, 패키지 관리자, 테스트 러너, Node API, HTTP, WebSocket까지 포함하는 큰 도구이며, 월간 CLI 다운로드 수는 2,200만 회를 넘는다.1
이 정도 규모가 되면 질문이 달라진다. “어떤 언어가 더 멋진가?”가 아니라 “반복되는 안정성 비용을 어디에서 줄일 것인가?”가 핵심이 된다.
핵심은 Rust가 아니라 안정성 비용의 위치다
Bun 팀이 마주한 문제는 use-after-free, double-free, 메모리 누수, 예외 경로에서의 정리 누락 같은 것들이었다.1 모두 메모리를 언제 해제할지, 누가 책임질지, 한 번만 해제되는지 사람이 계속 정확히 관리해야 할 때 생기기 쉬운 문제다.
Bun은 JavaScript의 가비지 컬렉션 객체와 직접 관리하는 네이티브 메모리를 함께 다루는 프로젝트로 설명된다.1 이런 환경에서는 작은 수명 관리 실수도 런타임 크래시나 추적하기 어려운 버그로 이어질 수 있다.
Rust 전환의 의미는 “더 빠른 언어를 골랐다”보다 “수명과 소유권 문제를 더 이른 단계에서 잡도록 구조를 바꿨다”에 가깝다. safe Rust에서는 해제 책임, 중복 해제, 잘못된 수명 사용과 관련된 많은 문제가 컴파일 오류가 될 수 있다.1 즉, 리뷰와 런타임 디버깅에 의존하던 비용 일부를 컴파일러가 대신 부담하게 만드는 선택이다.
재작성의 성패는 테스트가 결정한다
대규모 재작성은 언제나 위험하다. 기존 동작을 보존해야 하고, 새 구현이 정말 같은 의미인지 계속 확인해야 하기 때문이다.
Bun에는 중요한 안전망이 있었다. 테스트 스위트가 TypeScript로 작성되어 있어, 구현 언어와 독립적으로 동작을 검증할 수 있었다.2 Rust 포트가 맞는지 판단하는 기준은 “코드가 그럴듯한가”가 아니라 “기존 테스트를 통과하는가”였다.
이 차이는 크다. 테스트는 단순한 보조 장치가 아니라 재작성 과정에서 사실상의 동작 명세가 된다. 구현 언어를 바꿔도 외부 동작을 유지해야 한다면, 검증 가능한 테스트 스위트가 재작성의 가장 중요한 자산이 된다.
AI보다 중요한 것은 검증 가능한 경계다
Jarred Sumner는 Bun을 Zig에서 Rust로 재작성한 과정을 블로그에 정리했다.2 Claude Code v2.1.181 및 이후 버전은 Bun의 Rust 포트를 사용하며, 해당 버전은 6월 17일 출시됐다.3
포트 작업에는 캐시되지 않은 입력 토큰 59억 개, 출력 토큰 6억 9천만 개, 캐시된 입력 토큰 읽기 720억 개가 사용됐다.3 숫자만 보면 AI의 규모가 먼저 눈에 들어온다. 하지만 이 사례에서 더 중요한 지점은 AI를 많이 썼다는 사실보다, 결과를 확인할 수 있는 경계가 있었다는 점이다.
재작성에서 AI는 코드를 빠르게 만들 수 있다. 그러나 “맞는 코드인지”를 판단하는 역할까지 대신해주지는 않는다. 그 판단은 테스트, 명세, 호환성 기준처럼 반복적으로 확인 가능한 체계가 맡아야 한다.
실무적으로 읽어야 할 교훈
이번 사례를 “Rust가 Zig를 이겼다”로 읽으면 너무 좁다. 더 정확한 해석은, 규모가 커진 시스템이 안정성 비용을 어디에서 치를지 다시 설계한 사례라는 것이다.
반복되는 메모리 수명 문제가 있다면 선택지는 세 가지다. 리뷰와 규칙으로 계속 막을 수도 있고, 런타임에서 터진 뒤 고칠 수도 있다. 또는 컴파일 단계에서 더 많이 걸러지도록 언어와 구조를 바꿀 수도 있다.
Bun의 Rust 재작성은 세 번째 선택에 가깝다. 메모리와 수명 문제가 핵심 리스크인 영역에서는 언어의 제약이 오히려 생산성일 수 있다. 동시에 어떤 재작성도 검증 가능한 테스트가 없다면 위험한 도박이다. AI를 쓰든 쓰지 않든, 재작성의 핵심은 “얼마나 빨리 옮겼는가”가 아니라 “같은 동작임을 어떻게 확인했는가”에 있다.
참고
1【Rust日报】2026-07-09 Bun 重写转向 Rust
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.