Node vs Deno vs Bun, 2026년 런타임 선택 기준

자바스크립트 런타임을 고르는 일이 몇 년 전까지는 고민거리가 아니었다. Node.js 말고 선택지가 없었기 때문이다. 지금은 Node, Deno, Bun 셋이 각자 다른 이유로 쓰인다. 이 글은 2026년 기준으로 셋이 어디가 어떻게 다른지, 그리고 무엇을 기준으로 골라야 하는지를 정리한다. 결론부터 말하면 성능 숫자만 보고 고르면 대개 후회한다.

메모리와 속도에서 차이가 난다

먼저 자주 인용되는 수치를 보자. 유휴 상태의 프로세스 메모리다.

부하가 걸리면 격차가 더 벌어진다. 웹소켓 5,000개 동시 연결 기준으로 Bun이 620MB, Node가 890MB라는 측정이 있다.

패키지 설치 속도 차이는 더 극적이다. bun install이 npm install보다 10배에서 30배 빠르다는 수치가 돌고, 스크립트 기동도 5배 정도 빠르다고 보고된다. CI에서 의존성 설치가 파이프라인의 절반을 차지하는 프로젝트라면 이 차이는 무시하기 어렵다.

다만 벤치마크를 읽을 때는 항상 조건을 봐야 한다. 유휴 메모리 차이는 프로세스를 수백 개 띄우는 환경에서는 의미가 크지만, 서버 한두 대를 돌리는 상황에서는 체감이 거의 없다. 설치 속도도 캐시가 warm한 상태에서는 격차가 줄어든다.

호환성이 실제 선택을 좌우한다

성능보다 먼저 확인해야 하는 것이 npm 생태계 호환성이다. 2026년 초 기준으로 Bun은 npm 패키지의 95% 이상을 수정 없이 처리하고, Deno 2.x는 복잡한 패키지 기준 80~90% 수준으로 알려져 있다.

숫자만 보면 Bun이 앞서지만, 문제는 남은 5%가 무엇이냐다. 네이티브 애드온을 쓰는 패키지, Node 내부 API에 의존하는 패키지, 특정 빌드 도구가 여기 걸리기 쉽다. 프로젝트에서 그 5%에 해당하는 패키지를 하나라도 쓴다면 호환성 95%는 0%와 같다.

그래서 실제 판단 방법은 단순하다. 지금 쓰는 package.json을 그대로 옮겨서 설치하고 테스트를 돌려 보는 것이다. 통계는 참고일 뿐이고, 내 프로젝트가 되는지 안 되는지는 이진값이다.

보안 모델이 근본적으로 다르다

셋을 가르는 가장 큰 설계 차이는 성능이 아니라 권한이다.

Deno는 기본적으로 아무 권한이 없다. 파일 시스템, 네트워크, 환경 변수 접근을 명시적으로 허용해야 한다.

deno run --allow-net=api.example.com --allow-read=./data app.ts

Node와 Bun은 기본적으로 전체 시스템 권한을 갖는다. 설치한 패키지가 무엇을 하든 막을 장치가 런타임에 없다.

이 차이는 공급망 공격이 늘어난 상황에서 점점 무게가 실린다. npm install 한 번으로 수백 개 패키지가 딸려 오고, 그중 하나가 탈취되면 빌드 서버의 환경 변수가 통째로 빠져나간다. 실제로 그런 사고가 반복해서 일어났다. Deno의 권한 모델은 이 위험을 런타임 수준에서 줄인다.

그래서 무엇을 골라야 하나

정리하면 이렇다.

Node.js는 여전히 기본값이다. 생태계가 가장 넓고, 채용 시장에서 인력을 구하기 쉽고, 문제가 생겼을 때 검색하면 답이 나온다. 그리고 Node도 멈춰 있지 않다. 26에서 Temporal API가 기본으로 켜졌고, 내장 테스트 러너와 .env 파일 지원처럼 예전에는 라이브러리가 하던 일을 런타임이 가져가고 있다. 경쟁이 Node를 개선시킨 부분이 분명히 있다.

Bun은 기존 Node 코드베이스의 성능이 문제일 때다. 호환성이 높아 옮기는 비용이 낮고, 패키지 매니저·번들러·테스트 러너가 하나에 들어 있어 도구 체인이 단순해진다. CI 시간을 줄이는 목적만으로 bun install만 도입하는 것도 실용적인 선택이다.

Deno는 보안이 우선이거나 표준 웹 API에 맞추고 싶을 때다. 엣지 런타임에 배포한다면 웹 표준을 따르는 코드가 이식성이 좋다. 타입스크립트를 설정 없이 바로 실행하는 것도 작은 도구를 만들 때 편하다.

런타임을 바꾸는 것이 답이 아닐 때

마지막으로 반대 의견을 하나 적어둔다. 나는 성능 때문에 런타임을 바꾸는 결정에 신중한 편이다.

이유는 대부분의 웹 서비스에서 병목이 런타임이 아니기 때문이다. 느린 응답의 원인은 대개 데이터베이스 질의, 외부 API 호출, N+1 문제, 캐시 미스다. 런타임을 바꿔 얻는 몇 밀리초는 인덱스 하나를 제대로 거는 것보다 작다. 측정 없이 런타임부터 바꾸면, 마이그레이션 비용은 치르고 문제는 그대로 남는다.

그리고 런타임은 되돌리기 어려운 선택이다. 프레임워크는 바꿀 수 있지만 런타임은 배포·모니터링·디버깅 도구가 전부 얽혀 있다. 팀 전체가 그 런타임의 특성을 알아야 장애에 대응할 수 있다.

먼저 프로파일링하고, 병목이 실제로 런타임에 있을 때 바꾼다. 그게 아니라면 Node를 쓰면서 Bun을 패키지 매니저로만 도입하는 식의 부분 채택이 현실적이다. 셋 다 좋아진 것은 경쟁 덕분이지만, 경쟁의 수혜자가 되는 방법이 꼭 갈아타는 것일 필요는 없다.

세 런타임을 한 프로젝트에서 섞어 쓸 수 있나

의외로 자주 나오는 질문이다. 답은 "부분적으로 가능하다"이다.

가장 흔한 조합은 패키지 매니저만 바꾸는 것이다. bun install로 의존성을 설치하고 실행은 node로 한다. node_modules 구조가 호환되므로 대체로 문제없이 동작한다. CI 시간을 줄이는 효과가 즉시 나오면서 런타임 위험은 지지 않는다.

도구만 바꾸는 것도 가능하다. 테스트는 Bun으로 돌리고 프로덕션은 Node로 배포하는 식이다. 다만 이 경우 테스트 환경과 실행 환경이 달라진다는 점을 감수해야 한다. 런타임 차이에서 오는 버그는 테스트에서 안 잡힌다.

스크립트만 Deno로 쓰는 것도 실용적이다. 배포 스크립트나 일회성 도구를 타입스크립트로 쓰고 deno run으로 실행하면, 빌드 설정 없이 타입 안정성을 얻는다. 애플리케이션 런타임과 무관하므로 위험이 없다.

핵심은 바꾸는 범위를 좁게 잡는 것이다. 전면 교체는 얻는 것에 비해 감수할 것이 많다. 부분 도입으로 이득의 상당 부분을 가져올 수 있다면 그쪽이 합리적이다.

참고 자료

• Node.js vs Deno vs Bun: The Ultimate Runtime Guide for 2026 — DEV Community — 메모리·설치 속도 등 비교 수치
• Bun vs Node.js vs Deno: Which Runtime in 2026? — daily.dev — 호환성 비율과 생태계 현황
• Node.js 26.0.0 (Current) — 공식 릴리스 노트 — Node 쪽의 최신 개선 내용