Bun이 Zig를 버리고 Rust로 갈아탄다? 실험적 재작성 버전이 99.8% 테스트 통과

Bun, Rust로 다시 태어나는 중

JavaScript 런타임 시장은 한동안 Node.js 천하였죠. 그러다 Deno가 등장해서 "Node.js의 단점을 고쳐보자" 했고, 이어서 Bun 이 나타나서 "우리는 그냥 압도적으로 빠르게 만들겠다" 며 판을 흔들었습니다. Bun은 Zig라는 비교적 새로운 언어로 작성됐는데, JavaScriptCore 엔진을 쓰면서 패키지 매니저, 번들러, 테스트 러너까지 하나의 바이너리에 다 때려 넣은 "올인원 툴체인" 으로 인기를 끌었어요.

그런데 Bun의 창립자 Jarred Sumner가 최근 충격적인 소식을 전했습니다. Bun을 Rust로 다시 작성하고 있고, 그 실험 버전이 리눅스 x64 glibc 환경에서 이미 99.8%의 테스트를 통과했다 는 거예요. Zig로 잘 나가던 프로젝트를 왜 갑자기 Rust로 갈아엎느냐, 이게 의외라서 개발자 커뮤니티가 술렁이고 있어요.

Zig vs Rust, 뭐가 달랐길래

잠깐 배경을 짚고 가면, Zig 는 C의 후계자를 자처하는 시스템 언어예요. 문법이 단순하고 컴파일 속도가 빠르며, 메모리를 수동으로 관리합니다. 안전성보다는 "명시적 제어" 와 "단순함" 에 무게를 두는 철학이죠. Bun이 빠른 이유 중 하나가 바로 Zig의 효율적인 코드 생성과 적은 오버헤드 덕분이었어요.

반면 Rust 는 컴파일 시점에 메모리 안전성을 강제하는 걸로 유명하죠. 소유권(ownership)과 빌림(borrowing)이라는 독특한 개념으로, 데이터 경합이나 메모리 누수 같은 버그를 컴파일러가 잡아냅니다. 대신 학습 곡선이 가파르고, 컴파일이 느려요.

Jarred가 밝힌 재작성 이유를 종합하면 크게 세 가지예요. 첫째, 생태계의 성숙도 입니다. Rust는 이미 거대한 크레이트(라이브러리) 생태계를 갖고 있어서, HTTP 파서나 정규식 엔진, SIMD 최적화 라이브러리 같은 걸 이미 검증된 형태로 가져다 쓸 수 있어요. Zig는 아직 표준 라이브러리도 안정화 전이라 직접 짜야 할 게 많죠. 둘째, 메모리 안전성 입니다. Bun처럼 사용자 코드를 받아서 실행하는 런타임은 작은 메모리 버그 하나가 전체 시스템을 흔들 수 있는데, Rust는 컴파일러가 이걸 잡아주니까 안정성 측면에서 큰 이점이에요. 셋째, 개발자 풀 이 훨씬 넓다는 점이에요. Zig 개발자는 아직 소수인데, Rust는 시스템 언어 진영에서 사실상 표준이 됐거든요.

99.8% 테스트 통과의 의미

런타임 재작성에서 "테스트 통과율 99.8%" 라는 숫자는 생각보다 엄청난 의미예요. Bun은 Node.js 호환성을 핵심 가치로 내걸고 있어서, npm 생태계의 수많은 모듈이 그대로 돌아가야 합니다. 테스트 스위트는 fs, http, crypto, child_process 같은 코어 모듈부터 스트림, 워커 스레드, 비동기 훅까지 수천 개에 이르는데, 이걸 99.8%까지 끌어올렸다는 건 이미 거의 production-ready에 근접했다는 뜻이에요.

물론 "리눅스 x64 glibc" 라는 단서가 붙어 있어요. 즉, macOS나 Windows, ARM64, musl libc(Alpine 같은 환경) 에서는 아직 갈 길이 남았다 는 거죠. 그래도 가장 보편적인 서버 환경에서 돌아간다는 사실 자체가 큰 진전이에요. 보통 런타임 재작성 프로젝트는 80% 벽에서 한참 헤매다가 마지막 1~2%에서 멈추는 경우가 많거든요. 거기서 더 나아갔다는 건 핵심 아키텍처가 잘 잡혔다는 신호로 볼 수 있어요.

업계 흐름에서 본 Rust 재작성 트렌드

사실 Bun만 이러는 게 아니에요. 최근 몇 년간 "기존 인프라 도구를 Rust로 다시 짜기" 는 거의 하나의 사조가 됐습니다. Biome (옛 Rome) 은 ESLint와 Prettier를 Rust로 통합했고, Turbopack 은 Webpack의 Rust 후계자를 자처하죠. Oxc 는 JavaScript 파서/린터를 Rust로 처음부터 다시 짜고 있고, swc 는 Babel을 대체하는 Rust 컴파일러예요. Ruff 는 Python의 Flake8을 Rust로 바꿔서 100배 빨라졌고요.

공통점은 명확해요. "기존 JS/TS로 짠 도구가 너무 느리다, Rust로 다시 짜면 10배~100배 빠르다" 는 거죠. Bun의 경우는 좀 다른 게, 이미 Zig로 충분히 빨랐던 걸 Rust로 옮기는 거라 성능 향상보다는 유지보수성, 안정성, 생태계 활용 이 주된 동기로 보여요.

반대 시각도 있어요. "이렇게 큰 코드베이스를 다시 쓰면 기존에 잡았던 미묘한 버그들이 다시 살아난다" 는 우려, 그리고 "Zig 커뮤니티에 대한 배신 아니냐" 는 감정적 반응도 있고요. 실제로 Joel Spolsky의 유명한 글 "Things You Should Never Do" 에서는 "제품을 처음부터 다시 짜는 건 회사가 저지를 수 있는 최악의 실수" 라고 했죠. 이게 Bun에도 적용될지는 시간이 말해줄 거예요.

한국 개발자에게 주는 시사점

당장 프로덕션에서 실험 버전을 쓸 일은 없겠지만, 몇 가지 챙겨볼 포인트가 있어요. 우선 언어 선택이 곧 운명은 아니다 라는 교훈이에요. 잘 나가는 프로젝트도 필요하면 언어를 갈아엎습니다. 우리가 사이드 프로젝트나 회사 도구를 만들 때 "한 번 정한 언어로 끝까지 가야 한다" 는 강박을 가질 필요가 없다는 거죠.

또 Rust 학습의 가치 가 점점 올라가고 있다는 점도 주목할 만해요. 인프라/툴체인 영역에서 Rust는 사실상 표준이 되어가고 있고, 프론트엔드 빌드 도구부터 데이터베이스, 런타임까지 Rust로 다시 쓰이는 흐름이 분명합니다. 백엔드/프론트엔드 가리지 않고 "내가 매일 쓰는 도구의 내부를 이해하고 싶다" 면 Rust 기초는 투자할 가치가 충분해요.

프로덕션 측면에서는, Bun을 이미 쓰고 있다면 당분간은 안정 버전(Zig 기반)을 계속 쓰면 됩니다. Rust 버전이 모든 플랫폼에서 안정화되려면 적어도 1년 이상은 걸릴 거예요.

마무리

빠르게 성장하는 프로젝트가 핵심 언어를 바꾸는 건 흔한 일이 아니에요. Bun의 Rust 전환이 성공적으로 마무리된다면, JS 런타임 경쟁 구도가 한 번 더 흔들릴 가능성이 높아 보입니다.

여러분이라면 이미 잘 돌아가는 프로젝트의 언어를 갈아엎는 결정을 할 수 있을까요? 어떤 조건이 충족되어야 그런 큰 변화를 받아들일 수 있을지 의견이 궁금합니다.