Bun과 Claude의 합작, 다음 버전엔 AOT와 LINT?! 지금 Bun으로 바꿔야 할까?

그런데 2026년, Bun의 내부가 크게 바뀌었습니다. Bun 팀은 Zig로 작성한 주요 코드를 Rust로 옮겼고, 그 과정에 Claude Code를 대규모로 활용했습니다. 최초 전환 작업에는 약 11일이 걸렸다고 합니다. 이후 안정화 과정을 거쳐 Rust 기반 코드가 Bun 1.4 정식판에 들어갔습니다.

이 이야기는 단순히 “Zig보다 Rust가 빠르다”거나 “AI가 개발자를 대체했다”는 결론으로 끝나지 않습니다. 전환에는 메모리 안정성 문제가 있었고, 테스트가 모두 통과한 뒤에도 회귀가 발견됐습니다. 성능이 개선된 부분 중에는 언어 전환과 별도로 진행한 최적화도 있습니다.

Bun 1.3.14부터 1.4.4까지 무엇이 달라졌는지, Node.js와 Deno를 상대로 어떤 차이가 있는지, 그리고 커뮤니티에서 어떤 이야기가 오갔는지 차례로 살펴보겠습니다.

먼저 짚고 갈 핵심

• Bun 1.3.14는 Zig 시대의 마지막 안정판이고, 1.4.0은 Rust 전환을 포함한 첫 안정판입니다.
• Bun은 2025년 12월 Anthropic에 인수됐습니다. Bun 창시자 Jarred Sumner는 Claude Code와 출시 전 Claude Fable 5를 이용해 전환했다고 밝혔습니다.
• 최초 포트는 약 11일 만에 main에 병합됐지만, 병합과 정식 출시 사이에는 추가 검증과 안정화 기간이 있었습니다.
• Rust로 옮겼다고 Bun 전체가 안전한 Rust만으로 구성된 것은 아닙니다. JavaScriptCore와 여러 C·C++ 라이브러리도 계속 사용합니다.
• Bun 1.4의 시작 시간과 메모리 개선은 확인할 만하지만, 그 수치를 Rust 언어 하나의 효과로 해석할 수는 없습니다.
• 2026년 11월 6일 확인한 최신 안정판은 1.4.4입니다. 그 이후 main에서는 실험적인 AOT 컴파일과 bun lint 등이 개발되고 있습니다. Bun 릴리스 목록

Bun은 원래 무엇을 만들고 있었을까?

Bun은 흔히 Node.js의 대안으로 소개되지만, 실행기 하나만을 뜻하지는 않습니다.

하나의 도구에 JavaScript·TypeScript 런타임, 패키지 관리자, 테스트 실행기, 번들러를 묶었습니다. 개발자는 기존 Node.js 프로젝트에서 bun install이나 bun test만 사용할 수도 있고, 애플리케이션 자체를 Bun에서 실행할 수도 있습니다.

기술 구조도 Node.js와 다릅니다. Node.js와 Deno는 Google의 V8 엔진을 사용하지만, Bun은 WebKit의 JavaScriptCore를 사용합니다. 엔진 위에 운영체제, 네트워크, 파일 시스템, 패키지 관리 기능을 연결하는 부분이 있으며, 이전에는 그 상당 부분이 Zig로 작성됐습니다.

Bun 창시자 Jarred Sumner는 Zig의 단순함과 저수준 제어 덕분에 초기 Bun을 빠르게 만들 수 있었다고 설명합니다. 동시에 Bun이 커지면서 JavaScript의 가비지 컬렉션과 수동으로 관리하는 네이티브 메모리 사이의 수명을 올바르게 맞추는 일이 어려워졌다고 밝혔습니다. Bun: Rewriting Bun in Rust

1.3.14에서 1.4.4까지: 무엇이 달라졌나

인수는 Anthropic의 2025년 12월 발표에서 확인할 수 있습니다. Rust 포트의 병합 시점과 Claude Code 적용에 관한 설명은 Bun의 전환기, 버전별 변경은 Bun 블로그에서 확인할 수 있습니다.

1.4.0: 언어 전환과 함께 커진 도구 상자

Bun 1.4는 Rust 포트 외에도 Node.js 호환성 개선, 병렬 테스트와 스크립트 실행, Bun.Image, Bun.WebView, Bun.markdown, 터미널 및 cron 관련 API 등을 발표했습니다.

Node.js 호환성 측면에서 Bun 팀은 Node.js 테스트 스위트에서 추가로 1,517개 테스트가 통과했다고 밝혔습니다. 다만 Bun은 공식 발표에서도 Node.js와 아직 100% 호환되지 않는다고 명시합니다. 일부 모듈의 통과율을 전체 npm 패키지의 호환율로 읽어서는 안 됩니다. Bun 1.4 발표

1.4.1과 1.4.2: 출시 뒤에도 계속된 안정화

1.4.1은 Bun.serve의 HTTP/2 지원, 유휴 메모리 사용량 개선, 오프라인 설치 옵션 등을 추가했습니다. 1.4.2는 Elysia 빌드와 AsyncLocalStorage 등에 영향을 준 회귀, 드문 JIT·가비지 컬렉션 충돌 등을 수정했습니다.

여기서 중요한 점은 모든 후속 버그를 Rust 포트의 직접적인 결과로 볼 수 없다는 것입니다. 반대로 대규모 테스트를 통과했다는 이유만으로 새 버전에 회귀가 없다고 가정해서도 안 됩니다. Bun 1.4.1, Bun 1.4.2

1.4.3과 1.4.4: 타입 검사와 포맷까지

1.4.3의 눈에 띄는 변화는 bun check입니다. Bun 팀은 이 타입 검사기가 TypeScript 7 계열 구현을 바탕으로 하며, 발표 당시 선택한 여러 프로젝트에서 tsc 7.0.2보다 빨랐다고 설명했습니다.

예를 들어 16코어 Apple Silicon Mac에서 측정한 VS Code 소스의 타입 검사 시간은 bun check가 1.24초, tsc 7.0.2가 5.98초였습니다. 이는 Bun 팀이 선택한 프로젝트와 환경에서의 결과입니다. 또한 bun check는 타입 검사기이며, 그 자체로 JavaScript나 .d.ts 파일을 출력하는 도구는 아닙니다. Bun 1.4.3 발표와 측정 조건

1.4.4는 bun fmt, Yarn Berry 잠금 파일 이관, 설치 재시도 개선, SQL과 WebSocket 변경 등을 더했습니다. TLS·네트워크·패키지 관리자 등에 대한 보안 수정도 포함돼 있으므로, 운영 환경에서는 새 기능뿐 아니라 릴리스 노트의 수정 범위를 확인할 필요가 있습니다. Bun 1.4.4 릴리스 노트

Claude는 어떻게 Bun을 Rust로 옮겼을까?

“AI에게 한 문장을 입력했더니 Bun이 완성됐다”는 이야기는 실제 과정과 거리가 있습니다.

Bun 팀의 설명에 따르면 먼저 Zig의 타입과 패턴을 Rust에 어떻게 대응할지 정리했습니다. 이후 Claude Code의 작업 흐름을 이용해 파일별 변환, 컴파일 오류 수정, 명령별 동작 확인, 테스트 실패 수정과 정리 작업을 반복했습니다.

Sumner는 약 50개의 작업 흐름을 활용했으며, 가장 바쁠 때는 여러 작업 흐름에 걸쳐 약 64개의 Claude가 동시에 동작했다고 설명합니다. 사람이 결과를 관찰하고, 문제가 발견되면 작업 흐름과 지침을 수정했다고도 밝혔습니다. Bun의 전환 과정 설명

11일은 어디까지의 시간일까?

Bun 측의 11일은 초기 포트 작업부터 main 병합까지의 기간입니다. 안정판 1.4가 바로 그날 출시된 것은 아닙니다.

또한 병합 전에 기존 테스트가 통과했지만, Bun 팀은 이후 19개의 알려진 전환 회귀를 발견해 수정했다고 밝혔습니다. 테스트 통과가 중요한 근거인 것은 맞지만, 테스트가 모든 실제 사용 환경과 오류를 포괄한다는 뜻은 아닙니다.

실제 사례도 있습니다. Zig 코드의 검증 표현식을 Rust의 debug_assert!로 옮기는 과정에서, 릴리스 빌드에서는 필요한 부수 효과까지 실행되지 않아 특정 개발 서버의 갱신 기능이 깨졌다고 Bun 팀은 설명합니다. 문법이 비슷해 보여도 언어의 실행 의미가 다르면 문제가 생길 수 있다는 사례입니다. Bun의 전환 오류 사례

“16만 5천 달러”는 총사업비가 아니다

Bun과 Anthropic은 병합 전 전환에 사용한 토큰을 API 가격으로 환산하면 약 16만 5천 달러라고 밝혔습니다. 이 수치는 해당 범위의 토큰 사용량을 기준으로 한 환산치입니다.

여기에 기존 Bun 개발에 들인 수년의 작업, 사람의 관리와 검토, 컴퓨팅 환경, 병합 후 안정화와 후속 개선까지 모두 포함된 총비용으로 읽어서는 안 됩니다. 수작업 예상 기간 역시 Bun 창시자의 추정치이며 실제로 같은 팀이 수작업 전환을 수행해 측정한 값은 아닙니다. Anthropic의 전환 비용 설명

Rust로 옮기면 Bun이 자동으로 안전해질까?

Rust의 소유권과 수명 체계는 특정 종류의 메모리 오류를 컴파일 단계에서 줄이는 데 도움이 됩니다. Bun 팀이 반복해서 경험한 메모리 누수, 해제 후 사용, 수명 관리 문제를 고려하면 전환 이유를 이해할 수 있습니다.

하지만 Rust라는 이름만으로 프로그램 전체의 안전성이 증명되지는 않습니다.

Bun은 JavaScriptCore를 비롯한 C·C++ 라이브러리를 계속 사용합니다. Rust의 unsafe는 컴파일러가 일부 안전 조건을 자동으로 보장하지 않는 경계를 표현하며, 그 안의 코드는 작성자와 검토자가 조건을 지켜야 합니다. unsafe가 있다는 사실만으로 곧바로 오류라는 뜻도 아니고, 없애는 것만으로 모든 오류가 사라진다는 뜻도 아닙니다.

Bun 팀은 전환 설명을 작성할 당시 Rust 코드의 약 4%가 unsafe 블록 안에 있었다고 밝혔습니다. 이 비율은 당시 코드와 집계 기준의 수치이며 현재 버전 전체의 위험도를 나타내는 점수는 아닙니다. Bun의 `unsafe` 설명

Zig 버전과 Rust 버전, 성능은 얼마나 달라졌나?

아래는 Bun 팀이 발표한 결과입니다. 직접 재현한 측정이 아니며, 각 수치는 해당 테스트와 환경에서만 해석해야 합니다.

시작 시간과 메모리

Bun 1.4 발표의 hello.js 측정값입니다.

Windows 비교의 이전 Bun은 1.3.14로 표기됐고, Linux 표는 1.3으로 표기됐습니다. 이 결과는 작은 시작 테스트이므로 장시간 실행되는 API 서버, 대형 빌드, 실제 사용자 응답 시간을 그대로 대표하지 않습니다. Bun 1.4 성능 발표

서버 메모리도 줄었지만, 원인을 구분해야 한다

Bun 팀은 부하 테스트에서 Express의 최대 메모리가 169MB에서 92MB로, Fastify는 233MB에서 120MB로 줄었다고 발표했습니다. 테스트는 대부분 64개 연결에서 100만 요청을 보냈고, Next.js와 Vite는 10만 요청을 활용했습니다.

그런데 Bun 팀이 설명한 개선에는 JavaScriptCore와 Bun의 메모리 할당 방식 변경, 가비지 컬렉션 관련 최적화 등이 포함됩니다. 따라서 “Rust로 바꿔서 메모리가 정확히 이만큼 줄었다”고 말할 수는 없습니다. 버전이 바뀌는 동안 여러 변화가 함께 들어갔기 때문입니다. Bun 1.4 메모리 측정

Node.js·Deno·Bun: 무엇이 다른가?

세 제품 모두 계속 발전하므로 위 표는 선택을 위한 출발점입니다. 특히 TypeScript 파일을 실행할 수 있다는 것과 프로젝트 전체를 타입 검사한다는 것은 별개의 기능입니다.

Node.js는 오랜 운영 경험과 방대한 생태계가 장점입니다. 이미 Node.js의 특정 버전과 네이티브 모듈에 의존하는 서비스라면 안정적인 기준점이 됩니다.

Deno는 권한 모델과 웹 표준 API를 중심으로 출발했지만, 현재는 npm과 Node.js 호환성도 적극적으로 개선하고 있습니다. 제한된 권한으로 스크립트를 실행하려는 환경이라면 권한 설정을 살펴볼 만합니다.

Bun은 설치·실행·테스트·번들링을 한 도구로 묶고, 시작 시간과 개발 도구의 속도에 강한 관심을 보여 왔습니다. 다만 특정 npm 패키지가 설치되는 것과 운영 환경에서 모든 동작이 Node.js와 동일한 것은 다릅니다.

경쟁 벤치마크: 누가 항상 빠를까?

결론부터 말하면, 공개된 측정은 작업에 따라 순위가 바뀐다는 것을 보여줍니다.

Deno가 자체 사이트에 공개한 측정 중 하나에서는 다음과 같은 결과가 나왔습니다.

HTTP 측정은 AMD EPYC x86_64에서 동시 연결 100개, 세 번 실행의 중앙값을 활용했다고 설명합니다. 시작 시간은 Apple M5에서 측정했으며, Deno 2.9 및 Bun 1.4의 카나리 빌드와 Node.js 26 계열을 활용했습니다. 서버와 시작 시간 행은 같은 기기에서 측정한 것이 아닙니다. Deno가 발표한 수치라는 점도 고려해야 합니다. Deno의 벤치마크와 조건

같은 Deno 자료에서 패키지 설치 결과도 캐시 상태에 따라 달랐습니다. 테스트한 18개 패키지 의존성 트리에서는 준비된 캐시에서 Deno가 598ms, Bun이 766ms였지만, 빈 캐시에서는 각각 5.3초와 4.9초였습니다. 설치 스크립트는 꺼져 있었습니다.

이 숫자는 “누가 패키지를 항상 더 빨리 설치한다”는 결론보다 어떤 조건을 기록해야 비교가 가능한가를 보여줍니다. 레지스트리, 네트워크, 잠금 파일, 캐시, 디스크, 설치 스크립트에 따라 결과가 바뀔 수 있습니다.

실무에서 비교한다면

자신의 프로젝트를 기준으로 다음 항목을 나눠 측정하는 편이 유용합니다.

1. 개발 명령: 의존성 설치, 테스트, 타입 검사, 빌드 시간.
2. 시작: 프로세스 시작부터 첫 요청에 응답할 때까지 걸리는 시간.
3. 장시간 처리량: 충분히 예열한 뒤의 요청 수와 CPU 사용량.
4. 지연 분포: 평균뿐 아니라 p95·p99 지연.
5. 메모리: 최대 사용량과 부하가 끝난 뒤 남는 사용량.
6. 호환성: 인증, 데이터베이스, 네이티브 모듈, 관측 도구와 장애 처리.

런타임 버전과 CPU, 운영체제, 테스트 코드, 연결 수, 캐시 상태, 반복 횟수도 함께 기록해야 다음 측정과 비교할 수 있습니다.

1.4.4 이후 Git에서는 무엇을 만들고 있을까?

2026년 11월 6일 확인 당시, GitHub main은 Bun 1.4.4 태그보다 90개 커밋 앞서 있었습니다. 비교한 기준은 1.4.4의 38afee6과 당시 main의 b1305dd입니다.

아래는 main에 병합된 개발 내용입니다. 다음 안정판에 어떤 형태로 들어갈지는 출시 전까지 달라질 수 있습니다. 1.4.4와 main 비교

1. 실험적인 AOT: TypeScript를 미리 기계어로

가장 눈에 띄는 변경은 bun build --compile --aot입니다. JavaScript와 TypeScript를 빌드 시점에 기계어로 컴파일해 독립 실행 파일을 만드는 실험 기능입니다. 짧게는 bun compile 명령도 제공합니다.

일반적인 JIT 실행에서는 프로그램이 실행되는 동안 자주 쓰는 코드를 최적화합니다. AOT는 실행 전에 컴파일하므로 초기 예열 비용을 줄일 가능성이 있습니다. Bun 팀은 TypeScript 타입 정보를 이용해 일부 객체 접근을 최적화하는 방식도 설명합니다.

Bun이 흥미로운 점은 TypeScript의 타입 정보를 단순히 제거하지 않고 AOT 기계어 최적화에 활용한다는 것입니다. 따라서 타입이 잘 정의된 TypeScript 프로젝트일수록 AOT의 잠재적인 이점이 커집니다.

여기서 핵심은 타입 주석의 개수보다 컴파일러가 타입과 실제 객체 구조를 확인할 수 있는 범위입니다. Bun 팀의 설명에서는 특정 객체만 접근한다는 사실을 증명할 수 있을 때 고정된 필드 배치와 단순한 메모리 접근을 활용합니다. 확신할 수 없는 경로에는 검사와 느린 실행 경로를 남기므로, 타입을 적었다는 이유만으로 모든 코드의 성능 향상이 보장되는 것은 아닙니다.

다만 빠르기만 한 것은 아닙니다. Bun의 PR에 실린 서버 테스트에서 첫 1초의 Express 처리량은 AOT가 약 46,562 req/s, JIT가 24,181 req/s였지만, 충분히 예열한 뒤에는 AOT가 47,935 req/s, JIT가 51,587 req/s였습니다. 같은 PR에서 다른 프레임워크의 결과도 각각 달랐습니다.

측정은 Linux x64의 AMD EPYC 9R14에서 수행됐으며, 서버와 부하 생성기를 별도 코어에 고정하고 64개 연결을 활용했습니다. 이는 Bun 팀의 실험 결과이며 직접 재현한 수치는 아닙니다.

현재 문서는 AOT를 실험 기능으로 표시합니다. 크로스 컴파일을 지원하지 않고, 실행 파일에서 중단점과 단계별 디버깅에도 제한이 있습니다. AOT 구현 PR과 측정

서버리스·Lambda·짧은 워커에서 AOT가 중요한 이유

AOT는 서버리스 함수, AWS Lambda, 짧게 실행되는 이벤트·작업 워커의 콜드스타트 부담을 줄이는 대안으로 특히 주목할 만합니다. 실행 전에 기계어를 준비하므로 프로세스가 막 시작했을 때의 파싱·JIT 예열 부담을 줄일 수 있습니다. 오래 실행되는 서버의 최대 처리량만 보기보다 첫 응답 시간, 초기 메모리와 실제 작업 시간을 함께 비교해야 하는 이유입니다. 이는 앞의 Bun 실험에서 얻을 수 있는 적용 관점이며, 이 글에서 Lambda 성능을 직접 측정한 결과는 아닙니다.

배포 방식도 중요합니다. AWS Lambda에서는 OS 전용 런타임 계열과 커스텀 런타임을 통해 네이티브 실행 파일을 연결할 수 있지만, 실행 진입점과 Runtime API를 통한 이벤트·응답 처리를 갖춰야 합니다. 초기화는 인스턴스당 한 번 일어나며 이후 호출에서 재사용될 수 있으므로 모든 요청이 콜드스타트인 것도 아닙니다. AWS Lambda 커스텀 런타임 요구사항

여기서 워커는 이벤트·큐 작업을 처리하는 실행 단위를 뜻합니다. Cloudflare Workers는 V8 isolate 기반의 별도 실행 모델을 쓰므로 Bun AOT 실행 파일을 모든 워커 플랫폼에 그대로 배포할 수 있다는 의미는 아닙니다. 네이티브 실행을 허용하는 환경과 플랫폼 통합 조건을 확인한 뒤 비교할 대안입니다. Cloudflare Workers 실행 구조

2. bun lint: 검사 도구까지 내장하려는 움직임

1.4.4에는 포함되지 않았던 bun lint를 릴리스 빌드에서 사용할 수 있도록 하는 변경이 main에 병합됐습니다. 기존 프로젝트에 자체 lint 스크립트가 있는 경우의 동작과 플러그인 호환성도 함께 다룹니다.

이미 bun check와 bun fmt를 제공하는 흐름을 보면 Bun이 실행기뿐 아니라 개발 도구 전반을 한곳에 묶으려는 방향을 읽을 수 있습니다. 다만 어떤 설정과 플러그인이 기존 ESLint 환경과 동일하게 동작하는지는 프로젝트별 검증이 필요합니다. bun lint 변경 PR

3. unsafe 줄이기와 네이티브 의존성 교체

1.4.4 이후 main에는 Rust의 수명과 빌림을 더 명시해 여러 영역의 unsafe 블록을 줄이는 변경이 이어졌습니다. 이벤트 루프, 파일 시스템, 네트워크, 번들러와 패키지 관리자 등이 대상입니다.

또 기존 libarchive 의존성을 제거하고 tar 읽기·쓰기와 gzip 컨테이너 처리를 안전한 Rust 코드로 옮기는 변경도 병합됐습니다. 단, DEFLATE 처리에는 여전히 zlib를 사용한다고 PR은 설명합니다. 일부 구성 요소가 안전한 Rust로 바뀌었다는 뜻이지, Bun 전체에서 C·C++가 사라졌다는 뜻은 아닙니다. 아카이브 변경 PR

커뮤니티 반응: 감탄과 불안이 동시에 나왔다

반응은 크게 두 방향으로 갈렸습니다.

한쪽에서는 오래된 코드베이스와 방대한 테스트를 활용해, 사람이 직접 모든 파일을 다시 작성하기 어려운 전환을 짧은 시간에 시도한 점을 높이 평가했습니다. 특히 언어를 바꾸는 일이 과거보다 훨씬 현실적인 선택지가 됐다는 반응이 나왔습니다.

다른 쪽에서는 대규모 AI 생성 코드의 검토 가능성, unsafe 경계, 장기 유지보수 비용을 우려했습니다. 테스트가 확인하는 범위와 실제 운영에서 마주칠 수 있는 입력 사이에는 차이가 있기 때문입니다. Rust 커뮤니티의 논의

이런 게시물은 커뮤니티에서 나온 개별 의견의 사례입니다. 찬성과 반대의 비율이나 전체 개발자 여론을 대표한다고 볼 수는 없습니다.

믿거나 말거나: 커뮤니티에 퍼진 비하인드

“Anthropic이 Zig의 AI 정책 때문에 Rust로 갈아타라고 했다?”

확인된 사실: Anthropic은 Bun을 인수했고, Bun은 Claude를 이용해 Rust 포트를 진행했습니다. Zig 커뮤니티와 Bun의 관계, AI 활용 방식에 관한 의견 차이도 공개적으로 드러났습니다.

확인되지 않은 부분: 인수 후 Anthropic이 Zig의 AI 정책 때문에 언어 전환을 지시했다는 인과관계는 공개된 근거만으로 확인할 수 없습니다. Bun 창시자가 공식적으로 설명한 기술적 이유는 반복되는 메모리 안정성 문제와 유지보수 부담입니다. 두 사건이 이어졌다는 사실과 전환의 결정적 동기는 구분해야 합니다. Bun의 설명, Anthropic의 인수 발표

“Zig 창시자는 Bun이 떠나서 화가 났다?”

이 역시 단순한 한 문장으로 정리하기 어렵습니다. Zig 창시자 Andrew Kelley는 공개 글에서 Bun의 코드 품질과 프로젝트 간 관계를 강하게 비판했고, Rust 전환이 자신들에게는 오히려 반가웠다는 취지로 썼습니다.

Kelley는 Bun의 성능·바이너리 크기 개선 중 일부는 언어 교체와 별개의 엔지니어링 작업일 수 있다고 주장했습니다. 반면 Sumner는 Zig가 초기 Bun을 가능하게 했다고 감사를 표하면서도 Bun의 메모리 관리 문제를 전환 이유로 들었습니다.

두 사람의 글은 각 당사자의 관점입니다. 어느 한쪽의 설명만으로 관계의 모든 경위나 기술적 인과관계를 확정할 수는 없습니다. Kelley의 반론, Sumner의 전환 설명

“Claude가 11일 만에 혼자 100만 줄을 완성했다?”

Bun 측은 병합된 변경에 약 100만 줄이 추가됐고 초기 작업이 11일 걸렸다고 밝혔습니다. 그러나 기존 Zig 코드와 테스트는 수년에 걸친 사람들의 작업이었고, 전환 중에도 사람이 지침을 만들고 작업을 관찰했습니다. 병합 뒤에는 회귀 수정과 안정화가 이어졌습니다.

따라서 11일은 놀라운 규모의 초기 포트 기간이지만, 기존 프로젝트의 축적이나 정식판 출시까지의 전체 작업을 지우는 숫자는 아닙니다. Bun의 작업 통계

“Zig Bun은 완전히 사라졌다?”

공식 Bun의 안정판은 Rust 기반으로 넘어갔지만, 커뮤니티에서는 Zig 기반 코드를 이어 가려는 포크도 등장했습니다. 예를 들어 Cruller는 스스로 Bun의 파생 프로젝트라고 설명합니다. 포크가 존재한다는 사실과 공식 Bun과 같은 속도로 기능·보안 수정을 계속 제공할 수 있는지는 별개의 문제입니다. Cruller 저장소

그래서 지금 Bun으로 바꿔야 할까?

새 프로젝트에서 빠른 설치와 통합 도구가 중요하다면 Bun은 충분히 시험해 볼 만합니다. 기존 Node.js 프로젝트라면 한 번에 런타임 전체를 교체하기보다 패키지 설치, 테스트, 개발 서버, 운영 서버를 각각 나눠 비교하는 편이 좋습니다.

특히 데이터베이스 드라이버, TLS 설정, 네이티브 애드온, 작업자 스레드, 모니터링 도구처럼 장애가 실제 운영에 영향을 주는 부분은 프로젝트의 테스트와 부하 조건으로 확인해야 합니다. Bun의 공식 호환성 개선은 반가운 소식이지만, 내 서비스의 의존성까지 자동으로 보증해 주지는 않습니다.

Bun의 Zig→Rust 전환은 언어 전쟁의 승패보다 더 흥미로운 질문을 남깁니다. AI가 기존 코드와 테스트를 이용해 대규모 전환을 빠르게 수행할 수 있게 됐을 때, 개발팀은 무엇을 먼저 검증하고 어떤 근거로 출시를 결정해야 할까요?

Bun 사례에서 답의 일부는 이미 보입니다. 기존 동작을 설명하는 코드, 충분한 테스트, 사람의 판단, 실제 운영 이후의 수정이 모두 필요했습니다. 그리고 최신 main의 AOT 실험처럼, 전환이 끝난 뒤에도 Bun의 다음 경쟁은 계속되고 있습니다.