Bun이 Zig를 버리고 Rust로 간다 — 오픈소스 언어 선택의 무게

JavaScript 런타임 시장에 또 한 번 큰 파장이 일고 있습니다. Node.js의 대안으로 빠르게 자리잡은 Bun이 자신의 핵심 코드베이스를 Zig에서 Rust로 옮긴다고 발표했습니다. Zig 진영에서는 가장 화려한 간판이었던 프로젝트의 이탈이라, 충격이 작지 않습니다.

Bun과 Zig, 그 짧고 강렬했던 동거

Bun이 처음 등장했을 때 가장 큰 화제는 사실 속도가 아니라 언어 선택이었습니다. 거의 모든 차세대 시스템 도구가 Rust로 쓰이던 시절, Bun의 창업자 Jarred Sumner는 굳이 Zig를 골랐습니다. C에 가까운 단순함, 명시적인 메모리 관리, 빠른 컴파일 시간이 이유였죠.

결과는 인상적이었습니다. Bun은 출시 직후부터 Node.js 대비 3~4배 빠른 시작 시간, 압도적인 패키지 설치 속도로 주목받았습니다. Zig 입장에서는 “실전에서 검증된 대형 프로젝트"라는 가장 강력한 마케팅 포인트가 생긴 셈이었습니다.

왜 지금 Rust로 갈아타나

Bun 팀이 밝힌 이유는 크게 세 가지입니다.

첫째, 인력 풀입니다. Zig는 아직 1.0이 나오지 않은 언어입니다. 능숙한 Zig 개발자를 채용하는 건 사실상 “가르쳐서 쓰는” 수준이고, 외부 기여자도 한정적입니다. 반면 Rust는 이미 수십만 명의 시스템 프로그래머가 매일 쓰는 언어입니다.

둘째, 생태계 라이브러리입니다. HTTP 파서, 압축, TLS, 정규표현식 같은 핵심 인프라 코드가 Rust에는 production-grade로 깔려 있습니다. Bun은 그동안 상당 부분을 직접 짜거나 C 라이브러리를 바인딩해야 했습니다.

셋째, 안정성입니다. Zig의 빌드 시스템과 컴파일러는 아직도 자주 깨집니다. 새 버전이 나올 때마다 Bun 팀이 마이그레이션에 시간을 쏟아야 했고, 이건 런타임처럼 안정성이 생명인 제품에는 치명적인 비용입니다.

Zig 커뮤니티가 받은 충격

Zig 공식 포럼과 관련 커뮤니티 반응은 두 갈래로 나뉩니다. 한쪽은 “올 것이 왔다”는 반응입니다. 1.0 전 언어로 상용 제품을 만드는 건 무리였고, Bun이 이렇게 오래 버텨준 것만 해도 감사하다는 의견이죠.

다른 한쪽은 실망감입니다. Zig의 가장 큰 쇼케이스가 사라지면서, “Zig로 진지한 프로젝트를 시작해도 될까"라는 질문에 답하기가 더 어려워졌기 때문입니다. Zig 창시자 Andrew Kelley는 짧게 “각자 도구를 고를 자유가 있다"는 코멘트를 남겼습니다.

진짜 메시지는 따로 있습니다

이 사건이 단순히 “Zig가 졌다"는 이야기일까요. 저는 다르게 봅니다. 핵심은 오픈소스 인프라 프로젝트가 언어를 고르는 기준이 명확해졌다는 점입니다.

성능만 보면 Zig도 Rust 못지않습니다. 하지만 런타임처럼 수년간 운영되어야 할 프로젝트는 컴파일러 안정성, 채용 가능성, 외부 기여자 유입, 라이브러리 생태계가 성능보다 훨씬 중요합니다. Bun 팀은 결국 이 네 가지에서 Rust의 손을 들어준 겁니다.

또 하나 주목할 지점은 VC 자본의 영향입니다. Bun은 이제 단순한 사이드 프로젝트가 아니라 수천만 달러 투자를 받은 회사 제품입니다. 투자자 관점에서 “엔지니어 채용이 어려운 언어로 짠 코드베이스"는 명백한 리스크고, Rust로의 전환은 그 리스크를 줄이는 의사결정이기도 합니다.

우리는 무엇을 배워야 할까

새 언어를 도입할 때 우리는 보통 벤치마크부터 봅니다. 하지만 Bun의 사례는 장기적으로는 생태계가 성능을 이긴다는 사실을 다시 한번 보여줍니다. 6개월 사이드 프로젝트라면 어떤 언어든 괜찮습니다. 하지만 5년, 10년 갈 인프라라면, “지금 가장 빠른가"보다 “5년 뒤에도 채용할 수 있는가"가 더 중요한 질문일 수 있습니다.

여러분의 회사 핵심 코드베이스는 어떤 언어로 쓰여 있나요. 그리고 그 선택은 5년 뒤에도 같은 답일까요.