Bun의 Rust 전환, AI 코딩이 대규모 재작성의 기준을 바꿨어요

Bun의 Rust 전환, AI 코딩이 대규모 재작성의 기준을 바꿨어요

AI 뉴스 썸네일

728x90

JavaScript 런타임 Bun이 Zig 기반 코드 대부분을 Rust로 옮겼어요. 흥미로운 대목은 언어 선택만이 아니에요. 53만 줄이 넘는 Zig 코드를 한 명의 엔지니어가 Claude Code 워크플로를 지휘하며 11일 만에 옮겼고, Bun 팀은 그 결과를 v1.4.0 canary로 내놓았어요. 1

핵심 요약

구분	핵심	왜 볼 만한가요
런타임	Bun v1.4.0 canary가 Rust 기반 첫 버전으로 나왔어요	JavaScript 런타임의 내부 구현 언어가 안정성 전략과 맞물려 바뀌었어요
개발 방식	약 50개 워크플로와 최대 64개 Claude 인스턴스를 병렬로 돌렸어요	AI 코딩이 단순 보조를 넘어 대규모 이식 작업에 쓰인 사례예요
품질 관리	6개 플랫폼 CI, 기존 TypeScript 테스트, 보안 리뷰, 퍼징을 함께 썼어요	AI가 쓴 코드보다 검증 루프 설계가 더 중요한 사례로 볼 수 있어요
결과	128개 버그 수정, instrumentable 메모리 누수 수정, Linux·Windows 바이너리 약 20% 축소를 내세웠어요	언어 전환이 성능보다 안정성·운영 비용 문제와 연결돼 있어요

1. Bun은 왜 Zig에서 Rust로 옮겼나요

Bun은 빠른 JavaScript 런타임과 패키지 매니저, 번들러를 한데 묶은 도구예요. 초기 구현은 Zig로 시작했고, Bun 팀은 Zig의 낮은 수준 제어와 성능 지향 설계가 초기 속도에 큰 도움이 됐다고 설명해요. 지금은 월 2,200만 회 이상 다운로드되는 런타임으로 커졌고, Vercel·Railway·DigitalOcean 같은 서비스도 공식 지원해요. 2

전환의 직접적인 이유는 메모리 안정성이에요. Bun은 JavaScriptCore 같은 GC 기반 엔진과 자체 네이티브 코드를 함께 다뤄요. 이 조합에서는 JavaScript 값의 lifetime, 수동으로 관리하는 메모리, 예외 처리, 네이티브 포인터가 계속 맞물려요. Bun 팀은 v1.3.14에서 use-after-free, double-free, out-of-bounds 접근, race condition, 메모리 누수 같은 문제를 계속 고쳤다고 밝혔어요. 2

Rust로 옮기면 모든 문제가 자동으로 사라지는 건 아니에요. Bun 코드에는 JavaScriptCore, SQLite, BoringSSL, uWebSockets 같은 C/C++ 라이브러리가 남아 있고, Rust 코드 일부도 `unsafe`를 써요. 그래도 Rust의 borrow checker, `Drop`, Miri, LeakSanitizer를 함께 쓰면 적어도 흔한 메모리 실수 일부를 컴파일러와 도구가 더 일찍 잡아줘요. Bun 팀이 이번 전환을 성능 개선보다 안정성 개선 도구 확보로 설명한 이유예요. 2

2. 53만 줄 이식은 어떻게 11일 만에 끝났나요

원래 Zig 코드는 주석을 제외해 535,496줄이었다고 해요. Bun 팀은 작은 팀이 1년가량 걸릴 수 있는 작업이라고 봤지만, 버그 수정과 기능 개발을 1년 멈출 수는 없었어요. 그래서 사용자 동작을 바꾸는 리팩터링보다, Zig 코드를 Rust 코드로 최대한 기계적으로 옮기는 쪽을 택했어요. 2

작업의 중심에는 Claude Code가 있었어요. Bun 팀은 약 50개 동적 워크플로를 만들고, 최대 64개 Claude 인스턴스를 병렬로 돌렸어요. 먼저 Zig 패턴을 Rust 타입과 패턴으로 옮기는 `PORTING.md`를 만들었고, lifetime 분석 결과를 `LIFETIMES.tsv`로 정리했어요. 그다음 `.zig` 파일을 `.rs` 파일로 옮기고, crate별 컴파일 오류를 고치고, CLI 하위 명령과 테스트 실패를 차례로 줄였어요. 2

흥미로운 점은 AI가 코드를 쓰는 동안 사람의 역할이 사라지지 않았다는 점이에요. 구현자 역할의 Claude와 별도로, diff만 보고 버그를 찾는 적대적 리뷰어 Claude를 2개 이상 붙였어요. 사람은 워크플로 출력과 실패 패턴을 보고 규칙을 계속 조정했어요. 예를 들어 여러 Claude가 `git stash`, `git reset`으로 서로 충돌하자 해당 명령을 금지하는 규칙을 넣었고, 긴 설명 주석으로 workaround를 합리화하려는 패턴도 리뷰 규칙으로 막았어요. 2

3. 결과는 단순한 언어 교체보다 넓어요

Bun v1.4.0 canary는 v1.3.14에서 재현되던 128개 버그를 고쳤다고 해요. in-process `Bun.build()`를 2,000번 반복하는 테스트에서는 v1.3.14가 빌드마다 약 3MB씩 메모리를 계속 잃었지만, v1.4.0에서는 메모리 사용량이 약 609MB 근처에서 안정됐다고 공개했어요. Linux와 Windows 바이너리 크기는 약 20% 줄었다고 해요. 2

성능도 소폭 개선됐어요. Bun 팀이 공개한 Linux x64 벤치마크에서는 `Bun.serve` 처리량이 169.6k req/s에서 177.7k req/s로 올라갔고, `next build`는 13.62초에서 13.03초로 줄었어요. 큰 폭은 아니지만, 대규모 언어 전환 뒤에도 성능이 뒤로 가지 않았다는 점이 더 중요해 보여요. 2

다만 위험이 없던 작업은 아니에요. Rust 이식 이후 알려진 regression 19개가 나왔고 모두 수정됐다고 해요. `debug_assert!`의 release build 동작, odd byte slice 처리, bounds check 같은 언어 차이에서 생긴 문제였어요. 이 대목은 AI 이식이 빨라도 최종 품질은 테스트, CI, 퍼징, 실제 사용자 피드백에 계속 기대야 한다는 점을 보여줘요. 2

4. 개발팀이 봐야 할 포인트

첫 번째 포인트는 “AI가 대규모 재작성을 해냈다”보다 “검증할 수 있는 작업일수록 AI를 더 강하게 쓸 수 있다”예요. Bun은 기존 TypeScript 테스트 스위트가 구현 언어와 분리돼 있었고, 6개 플랫폼 CI가 있었고, 런타임 API와 parser 퍼징까지 갖췄어요. Claude가 만든 변경이 맞는지 판단할 보상 신호가 많았던 셈이에요. 2

두 번째는 비용이에요. Bun 팀은 병합 전까지 캐시되지 않은 입력 토큰 59억 개, 출력 토큰 6억 9천만 개, 캐시된 입력 토큰 read 720억 개를 썼고, API 가격 기준 약 16만 5천 달러라고 밝혔어요. 사람 팀 1년과 비교하면 싸게 보일 수 있지만, 일반 팀이 같은 모델·같은 컨텍스트·같은 코드베이스 이해도를 바로 가질 수 있는지는 별도 문제예요. 2

세 번째는 커뮤니티 리스크예요. GeekNews에 함께 정리된 Hacker News와 Lobste.rs 반응을 보면, Rust 전환 자체보다 릴리스 운영, Zig 버전 지원, `unsafe` 비율, Anthropic과 Bun의 관계를 걱정하는 의견도 많아요. 기술적으로 성공한 포팅이어도, 런타임 사용자는 “내 프로덕션 앱이 안전하게 넘어갈 수 있나”를 먼저 봐요. 1

왜 중요한가요

이번 사례는 AI 코딩 도구가 “파일 하나 고쳐주는 조수”에서 “대규모 변경을 병렬로 밀어붙이는 실행 환경”으로 넘어가고 있다는 신호예요. 하지만 이 신호를 그대로 모든 팀에 복사하긴 어려워요. Bun에는 강한 테스트 스위트, 언어 구현을 깊게 아는 엔지니어, 명확한 이식 가이드, 실패를 줄이는 리뷰 루프가 있었어요. 그중 하나라도 약하면 11일짜리 성공 사례가 아니라 긴 장애 대응 기록이 될 수 있어요. 2

개발팀 입장에서는 “우리도 AI로 전부 다시 쓰자”보다 “AI가 고칠 수 있을 만큼 검증 루프를 촘촘하게 만들자”가 더 현실적인 교훈이에요. 컴파일러, 타입 시스템, CI, 회귀 테스트, 퍼징, 보안 리뷰가 촘촘할수록 AI가 만든 대규모 변경을 더 빨리 판단할 수 있어요. Bun의 Rust 전환은 결국 코딩 도구 뉴스이면서, 테스트와 운영 규율 뉴스이기도 해요. 2

참고 자료

1. Bun을 Rust로 다시 작성하기 — GeekNews
2. Rewriting Bun in Rust — Bun Blog