Bun vs Node.js, 2026년 현실적 비교

Bun이 빠르다는 벤치마크는 많이 봤다

Twitter에서 "Bun이 Node.js보다 3배 빠르다" 같은 벤치마크를 수도 없이 봤다. HTTP 서버 벤치마크, 번들링 속도, 패키지 설치 속도. 전부 Bun이 이기는 그래프만 돌아다닌다.

근데 벤치마크와 실제 프로덕션은 다르다. 그래서 직접 해봤다. 사이드 프로젝트 API 서버를 Node.js 22에서 Bun 1.2로 옮겨봤다.

npm install이 47초 걸리던 게 bun install로 3초가 됐다. 이건 진짜 체감이 크다. CI에서도 차이가 났다. 패키지 설치 단계가 45초에서 4초로 줄었다.

근데 lock 파일이 다르다. package-lock.json이 아니라 bun.lockb를 쓴다. 팀 프로젝트에서 일부만 Bun을 쓰면 lock 파일이 충돌한다. 이건 의외로 큰 문제다.

간단한 HTTP 벤치마크로는 Bun이 2-3배 빠르다. 근데 실제 API 서버에서 DB 쿼리하고 비즈니스 로직 돌리면 차이가 줄어든다. 대부분의 시간이 네트워크 I/O와 DB에서 소비되니까.

내 사이드 프로젝트 기준으로 평균 응답 시간이 Node.js에서 182ms, Bun에서 156ms였다. 14% 정도 개선. 벤치마크에서 본 3배와는 거리가 있다.

(솔직히 유저가 182ms와 156ms의 차이를 느낄까 싶다.)

대부분의 npm 패키지는 Bun에서 잘 돌아간다. 근데 네이티브 바인딩을 쓰는 패키지에서 문제가 생겼다. sharp(이미지 처리)가 처음에 설치가 안 됐다. Bun 이슈 트래커를 뒤져서 해결법을 찾았는데 30분이 걸렸다.

그리고 node: 프리픽스를 쓰는 내장 모듈 일부에서 미묘한 동작 차이가 있었다. crypto.randomUUID()는 됐는데 crypto.createCipheriv()에서 옵션 처리가 달랐다.

이런 호환성 문제가 사이드 프로젝트에서는 괜찮지만, 프로덕션 서비스에서 터지면 대응이 어렵다.

Bun에 내장된 번들러도 써봤다. esbuild만큼 빨랐고 설정도 간단했다. 근데 아직 프로덕션용으로 쓰기엔 플러그인 생태계가 부족하다. webpack이나 Vite의 풍부한 플러그인에 비하면 갈 길이 멀다.

개인 프로젝트, 스크립트, CLI 도구에는 Bun을 쓸 만하다. 패키지 설치 속도만으로도 DX 개선이 크다. 근데 팀 프로젝트나 프로덕션 서비스에서는 아직 Node.js가 안전하다. 호환성 이슈를 디버깅하는 시간이 성능 개선보다 비싸니까.

1년 뒤에는 달라질 수 있다. Bun의 발전 속도가 빠르니까. 근데 지금 당장 프로덕션에 넣을 거냐고 물으면, 나는 아직이라고 답하겠다.