Bun vs Node.js 2026 — 성능, 호환성, 실사용 비교
Bun과 Node.js 비교. 벤치마크 성능, 패키지 호환성, 실제 프로젝트에서의 차이점 정리.
Node.js가 자바스크립트 서버 사이드의 유일한 선택지이던 시절이 있었다. Deno가 나왔을 때도 "재밌는 프로젝트네" 정도였는데, Bun이 등장하면서 분위기가 달라졌다. 벤치마크에서 Node.js를 압도하는 숫자가 나오니까 "이거 진짜 바꿔야 하나?" 하는 사람이 생겼다.
결론부터 말하면, 2026년 현재 대부분의 프로덕션 프로젝트에서는 Node.js가 여전히 안전한 선택이다. 근데 Bun이 못 쓸 물건이라는 뜻은 아니다. 상황에 따라 답이 다르다.
Bun이 뭔데
Bun은 Jarred Sumner가 만든 자바스크립트 런타임이다. Zig 언어로 작성했고, JavaScriptCore(Safari의 JS 엔진)를 사용한다. Node.js가 C++과 V8(Chrome의 JS 엔진) 기반인 것과 대비된다.
런타임만 제공하는 게 아니라 번들러, 테스트 러너, 패키지 매니저까지 내장되어 있다. Node.js에서는 webpack/vite, jest/vitest, npm/yarn/pnpm을 따로 설치해야 하는 걸 Bun 하나로 해결하겠다는 거다.
# Node.js 생태계
npm install # 패키지 설치
npx vitest # 테스트
npx vite build # 번들링
# Bun
bun install # 패키지 설치 (훨씬 빠름)
bun test # 테스트 (내장)
bun build ./src/index.ts # 번들링 (내장)
성능 차이
Bun이 가장 내세우는 게 성능이다. 공식 벤치마크를 보면 숫자가 화려하다.
패키지 설치 속도 — bun install은 npm install보다 수 배에서 수십 배 빠르다. 로컬 캐시가 있을 때는 거의 즉시 완료된다. pnpm도 빠른 편인데 Bun이 더 빠르다.
HTTP 서버 처리량 — 단순 HTTP 응답 벤치마크에서 Bun이 Node.js보다 2~4배 높은 RPS(초당 요청 수)를 기록한다.
스크립트 시작 속도 — bun run script.ts가 node script.js보다 빠르게 시작된다. TypeScript를 트랜스파일 없이 바로 실행하는 것도 한몫한다.
근데 벤치마크 숫자를 그대로 실전에 대입하면 안 된다. 실제 웹 서버의 병목은 보통 DB 쿼리, 외부 API 호출, 비즈니스 로직이지 런타임 자체가 아니다. HTTP 응답만 찍는 벤치마크에서 2배 빨라도, 실제 앱에서 체감되는 차이는 그보다 훨씬 작을 수 있다.
의미 있는 차이가 나는 건 패키지 설치 속도와 스크립트 시작 속도다. CI/CD에서 bun install이 30초 만에 끝나면 매 빌드마다 시간을 절약할 수 있고, 로컬 개발에서 TypeScript 파일을 바로 실행하는 건 DX(개발자 경험) 측면에서 확실히 편하다.
Node.js 호환성
Bun은 Node.js API의 대부분을 지원한다고 주장하고, 실제로 상당 부분이 호환된다. fs, path, http, crypto 같은 핵심 모듈은 잘 작동하고, package.json의 scripts도 bun run으로 실행된다.
호환되지 않는 부분은:
- Node.js 네이티브 모듈(C++ 애드온) —
node-gyp로 빌드하는 모듈은 Bun에서 작동하지 않을 수 있다. bcrypt, sharp 같은 패키지가 해당. 다만 sharp는 최근 Bun을 공식 지원하기 시작했고, 이런 지원 범위는 점점 넓어지고 있다. - Node.js 특유의 내부 API —
vm모듈의 일부 기능,worker_threads의 세부 동작 등에서 미묘한 차이가 있을 수 있다. - 프레임워크 호환성 — Express는 잘 돌아간다. Fastify도 대부분 된다. Next.js는 부분적으로 지원하지만, Vercel 배포 시에는 Node.js 런타임을 쓰게 된다. NestJS는 호환성 이슈가 보고된 바 있다.
npm에 있는 패키지의 대부분은 Bun에서도 작동한다. 근데 "대부분"이 100%는 아니다. 프로젝트에서 쓰는 핵심 패키지가 Bun에서 잘 돌아가는지는 직접 확인해야 한다.
Node.js의 강점
생태계 성숙도. 15년 넘게 쌓인 생태계가 있다. npm에 200만 개 이상의 패키지가 있고, 대부분이 Node.js를 기준으로 테스트됐다. 트러블슈팅할 때 Stack Overflow에 답이 있을 확률이 높다.
안정성. 프로덕션에서 수년간 검증된 런타임이다. 메모리 누수 패턴, 성능 프로파일링, 디버깅 도구가 성숙하다. Node.js의 --inspect 플래그로 Chrome DevTools 연결하는 식의 디버깅 워크플로우는 잘 확립되어 있다.
LTS 정책. 짝수 버전은 LTS(Long-Term Support)로 30개월 동안 보안 패치를 받는다. 기업 환경에서 중요한 부분이다.
클라우드 지원. AWS Lambda, Google Cloud Functions, Azure Functions 전부 Node.js를 1급 시민으로 지원한다. Bun을 서버리스 환경에서 쓰려면 커스텀 런타임을 세팅해야 하는 경우가 많다.
어떤 상황에서 Bun이 유리한가
새 프로젝트를 빠르게 시작할 때. bun init, bun install, bun run의 속도가 빨라서 프로토타이핑에 좋다. TypeScript를 설정 없이 바로 실행하는 것도 편하다.
스크립트나 CLI 도구. 짧게 실행되는 스크립트에서는 시작 속도 차이가 체감된다. ts-node나 tsx 대신 bun run script.ts를 쓰면 빠르다.
내장 도구가 충분한 프로젝트. Bun의 번들러, 테스트 러너, 패키지 매니저만으로 커버 가능하면 의존성이 줄어든다.
패키지 설치가 잦은 CI/CD. bun install의 속도 차이가 매 빌드마다 쌓이면 시간 절약이 유의미하다.
어떤 상황에서 Node.js가 나은가
프로덕션 서비스를 운영할 때. 안정성과 디버깅 도구의 성숙도가 중요하다면 Node.js가 맞다.
네이티브 모듈 의존성이 있을 때. bcrypt, canvas, 이미지 처리 라이브러리 등 C++ 바인딩이 필요한 패키지를 쓴다면 Node.js가 안전하다.
팀 프로젝트. 팀원 모두가 Bun에 익숙하지 않다면 전환 비용이 생긴다. Node.js는 대부분의 개발자가 이미 알고 있다.
서버리스 환경. AWS Lambda 등에서 기본 지원되는 건 Node.js다.
같이 쓰는 방법도 있다
꼭 하나만 골라야 하는 건 아니다. Bun의 패키지 매니저만 가져다 쓰는 식의 부분 도입도 가능하다.
// package.json
{
"packageManager": "bun@1.1.0"
}
bun install로 패키지를 설치하고 런타임은 Node.js를 쓰는 조합. 패키지 설치 속도의 이점은 가져가면서 런타임 호환성 걱정은 안 해도 된다.
로컬 개발에서는 bun run으로 TypeScript를 빠르게 실행하고, 배포할 때는 Node.js로 빌드하는 식도 된다.
Bun의 발전 속도가 빠르다. 호환성 문제가 계속 해결되고 있고, 커뮤니티도 커지고 있다. 지금 당장 전면 전환하긴 이르지만, 1~2년 뒤에는 상황이 많이 달라져 있을 수 있다. 새 프로젝트를 시작할 때 한번 써보면서 자기 환경에서의 호환성과 체감 성능을 확인해보는 걸 추천한다.