Split View: Modern Backend Runtime 2025 — Node.js 22·Bun·Deno·Cloudflare Workers·WinterJS 완전 비교 가이드 (Season 7 Ep 1)

Modern Backend Runtime 2025 — Node.js 22·Bun·Deno·Cloudflare Workers·WinterJS 완전 비교 가이드 (Season 7 Ep 1)

프롤로그 — "Node 하나만 있으면 되는 줄 알았다"

Season 7이 시작된다. Season 5에서는 데이터 엔지니어링을, Season 6에서는 프런트엔드를 훑었다. 이제 Season 7은 백엔드와 플랫폼 엔지니어링. 서버·인프라·운영·확장성·신뢰성이 주제다.

그 첫 글은 가장 뜨거운 논쟁 중 하나 — "2025년에 어떤 JavaScript 런타임을 써야 하는가?"

2022년까지만 해도 답은 단순했다. "Node.js." 15년 넘게 사실상 유일한 JS 서버 런타임이었다. 2022년 Bun 1.0이 충격적 벤치마크와 함께 등장하면서 지형이 흔들리기 시작했고, 2024~2025년은 다극 체제가 정착한 시기다.

2025년의 JS 런타임 지형:

이 글에서는 13개 챕터로 각 런타임의 내부·성능·생태계·선택 기준을 풀어본다.

1장 · 왜 JS 런타임이 다양해졌나

2022년까지의 Node 독점

2009년 Ryan Dahl이 만든 Node는 "브라우저 밖 JavaScript"의 유일한 선택지였다. V8 + libuv + npm 조합은 빠른 개발·거대한 생태계·쉬운 배포로 서버 JS를 장악했다.

그러나 Node에는 누적된 기술 부채가 있었다:

• ES Modules 지원이 오래 지연
• TypeScript 실행에 번들러 필요
• CLI 속도 (cold start·npm install)가 느림
• 테스트 러너·포매터 등 기본 도구 부재
• 설치 크기 큼

2022 Bun의 등장

Jarred Sumner가 1인 개발로 시작, **"Node를 10배 빠르게, 그리고 TS를 바로 실행"**을 목표로 함. 2022년 9월 베타 공개, JavaScriptCore(JSC) + Zig 구현으로 충격적 벤치마크. 2023년 9월 1.0, 2025년 1.2까지 진화.

2022 Deno 2의 재정비

Ryan Dahl이 2018년 "Node의 후회"를 담아 시작한 Deno는 보안·TS 네이티브·Web 표준에 집중. 하지만 npm 생태계 단절로 채택이 느렸다. 2024년 Deno 2에서 npm 호환성을 전면 복원하며 재도약.

2023~2024 Edge Runtime 범람

Cloudflare Workers(V8 Isolate), Vercel Edge, Deno Deploy, Fastly Compute, Netlify Edge — **"Full Node가 아닌 경량·빠른 실행"**을 지향하며 Edge 컴퓨팅의 주 런타임으로.

결론

"하나의 런타임으로 모두를 커버하는 시대는 끝났다." 2025년엔 목적별 선택.

2장 · Node.js 22 LTS — 안정적 진화의 대명사

2024년 10월 LTS 전환. 2025년 기준 프로덕션의 default.

주요 기능 (22 기준)

• ESM·CommonJS 동시 지원 안정화 (.mjs, .cjs, package.json type)
• Built-in node:test 안정화 — Jest·Vitest 없이 기본 테스트
• --experimental-strip-types — .ts 파일 직접 실행 (타입 체크는 안 함)
• Permission Model — --permission 플래그로 파일·네트워크 제한 (Deno 영향)
• Watch Mode (node --watch) — nodemon 없이
• Built-in fetch/WebSocket
• Corepack으로 pnpm·yarn·bun 통합

Node의 2025 강점

1. 생태계: npm 260만+ 패키지, 모든 라이브러리가 테스트된 곳
2. 안정성: 15년 프로덕션 입증
3. 클라우드 지원: 모든 서버리스·PaaS의 기본
4. 문서·커뮤니티: 한국어 자료도 풍부

Node의 약점

• 시작 속도: 큰 앱에서 cold start 수 초
• CLI·스크립트 경험: Bun에 비해 느림
• 번들러 없이 TS·JSX 못 씀

2025 권장 사용 패턴

• 장기 서비스 (안정성)
• 복잡한 서드파티 의존성
• 엔터프라이즈 SaaS·모니터링이 중요한 환경

3장 · Bun 1.2 — 속도와 DX의 혁명

2023년 9월 1.0, 2024년 말 1.2. JavaScriptCore + Zig + uWebSockets의 결합. 주간 다운로드 700만+ 돌파.

핵심 특징

• Node 호환 — Node API 90% 이상 지원, Express·Fastify·Prisma 등 그대로
• TS·JSX 바로 실행 — 설정 없이
• Built-in: 패키지 매니저(Bun install), 테스트 러너(Bun test), 번들러(Bun build), 포매터
• Bun.serve — HTTP 서버가 Node 대비 3~10배 빠름
• Bun SQLite·Bun S3·Bun Redis — 기본 제공 드라이버

벤치마크 예시 (간이)

실전 서비스에서 410배가 아닌 **1.53배 수준**으로 귀결되지만 여전히 매력적.

Bun.serve 예시

Bun.serve({
  port: 3000,
  fetch(req) {
    const url = new URL(req.url);
    if (url.pathname === "/") return new Response("Hello Bun!");
    return new Response("Not Found", { status: 404 });
  },
});

Bun의 약점 (2025 기준)

• 일부 native addon 호환 이슈 — better-sqlite3, canvas, sharp 일부 경계 케이스
• 생태계 문서 Node 대비 얕음
• Production 규모 트랙 레코드 축적 중
• 디버깅 도구 (Chrome DevTools 연동) 아직 발전 단계

2025 권장 사용

• 스크립트·CLI (가장 강점)
• 소규모·중규모 HTTP 서비스
• 개발 환경의 생산성 툴 (Vitest·Biome 대체)
• React SSR·Next.js의 로컬 실행 (큰 속도 향상)

4장 · Deno 2 — 보안·표준·Typescript 네이티브

Ryan Dahl이 Node의 "10가지 후회"를 바로잡아 2018년 시작. 2024년 Deno 2는 npm 완전 호환 + Node.js API 호환으로 귀환.

핵심 특징

• TS 네이티브 — 설정 없이 .ts 실행
• 보안 기본 — 파일·네트워크·환경변수 접근은 명시적 --allow-*
• Web Platform API 우선 — fetch, URL, Blob, ReadableStream이 모두 표준
• Built-in: 포매터, 린터, 테스트, 문서 생성, 벤치마크
• deno.json 하나로 모든 설정 (tsconfig·eslintrc·prettierrc 통합)
• npm 호환 — import { X } from "npm:lodash" 또는 package.json 지원
• JSR (JavaScript Registry) — Deno 주도 대안 레지스트리

보안 예시

# 파일 읽기 + 네트워크 접근 명시적으로 허용
deno run --allow-read --allow-net server.ts

# 모든 권한 (개발용)
deno run -A server.ts

Deno Deploy — Edge 배포

• V8 Isolate 기반, 글로벌 배포 수 초
• Deno 코드 그대로 배포
• 유료·무료 tier

2025 권장 사용

• 스크립트·자동화 (보안이 중요한)
• TypeScript 집약 프로젝트
• Edge API·Webhook·Cloudflare alternative
• 새 프로젝트의 실험적 런타임

5장 · Cloudflare Workers — V8 Isolate 기반 Edge

2017년 출시, 2024~2025년 Edge 컴퓨팅의 1강.

V8 Isolate란

• V8 엔진의 격리된 실행 컨텍스트
• Container·VM보다 훨씬 가벼움 — 수 밀리초에 생성·제거
• 같은 프로세스 안에 수천 개 Isolate 공존
• 메모리 오버헤드 낮음

Workers의 특징

• Cold Start 5ms 이하
• 전 세계 330+ 도시
• fetch 표준 API 기반
• Node API는 제한적 (fs, child_process 없음)
• 번들 크기 제한 1MB (유료 10MB)

예시

export default {
  async fetch(req: Request, env: Env): Promise<Response> {
    const { pathname } = new URL(req.url);
    if (pathname === "/") return new Response("Hello from Edge!");
    return new Response("Not Found", { status: 404 });
  },
};

함께 쓰는 서비스

• KV — 키-값 저장 (설정·캐시)
• D1 — SQLite at the edge
• R2 — S3 호환 객체 저장
• Durable Objects — 강한 일관성 상태
• Queues·Cron·Pages

2025 Node 호환 (nodejs_compat)

2024년부터 Cloudflare Workers에서 Node API 다수를 호환. fs, buffer, stream, events 등. Express·Hono 앱 이식 가능.

2025 권장 사용

• API·미들웨어·A/B 테스트
• 글로벌 지연 최소화가 필요한 서비스
• 저비용으로 대량 트래픽

6장 · Vercel Edge·Deno Deploy — Workers 생태계의 확장

Vercel Edge Runtime

• Cloudflare Workers와 동일한 V8 Isolate 기반 (내부적으로 Cloudflare·Vercel 자체 인프라)
• Next.js의 runtime: 'edge' 설정으로 쉽게 활용
• Middleware, Edge Function, Edge API Route

Deno Deploy

• Deno의 공식 Edge 서비스
• Deno 코드를 그대로 배포
• Deno KV 기본 제공

2024~2025 추세

Edge에서의 Node API 호환성 확대로 "Edge도 범용 런타임"이 된다. 2020년대 초반 "Edge는 경량 로직만"이라는 제약이 빠르게 무너지는 중.

7장 · 성능 벤치마크의 정직한 이해

왜 벤치마크는 속으는가

• 합성 벤치마크가 실제 서비스 특성을 반영 안 함
• "hello world" RPS는 거의 모든 런타임이 충분
• DB·외부 API 호출이 포함되면 차이가 줄어듦

실전에서 중요한 지표

1. P95·P99 latency — 평균이 아니라 꼬리
2. Memory footprint — Serverless·Kubernetes 비용 직결
3. Cold start — Edge·Serverless에서 critical
4. GC pause — Real-time 서비스 영향
5. Startup time — Serverless·CLI에 직접 영향

참고 도구

• wrk / wrk2 — HTTP 부하
• autocannon — JS 네이티브
• k6 — 시나리오 기반
• Vegeta — 타임 시리즈 분석
• clinic.js — Node 프로파일링

조언

"속도는 코드가 아니라 알고리즘·DB·네트워크가 결정한다." 런타임을 100ms에서 50ms로 줄여봐야, DB 쿼리 500ms면 의미 없다. 병목 측정이 먼저.

8장 · TypeScript 네이티브 — 런타임의 필수 기능이 되다

과거

• Node.js는 ts-node·tsx·esbuild-register 등으로 TS 실행
• 빌드 단계 필수
• 개발과 프로덕션의 실행 방식 차이

2024~2025 흐름

• Bun·Deno: 처음부터 TS 네이티브
• Node 22: --experimental-strip-types 실험 플래그
• Node 23: 기본 활성화

주의

"TS를 실행한다"는 것과 **"타입 체크"**는 다르다. 런타임은 타입을 제거만 한다. 타입 체크는 여전히 tsc 또는 IDE가 담당.

2025 베스트 프랙티스

1. 개발·런타임: Bun·Deno·tsx 직접 실행
2. CI: tsc --noEmit로 타입 체크
3. 프로덕션: Node + esbuild·swc 번들 또는 Bun 직접 실행
4. 에지: wrangler/vercel 전용 번들러 사용

9장 · 패키지 매니저 전쟁 — npm·pnpm·yarn·bun·deno

npm

• 기본. 느리지만 안정적
• 2020년 이후 개선 많음 (install 속도·workspaces)

pnpm

• 하드링크·컨텐츠 주소 저장
• 디스크 90% 절약
• 2025년 모노레포의 주류

Yarn (Berry)

• 2018년 Plug'n'Play로 혁신
• 도입 장벽은 여전 → 점유율 하락

bun install

• 가장 빠름 (8~20배)
• npm registry 호환
• Bun 런타임에 묶이지 않음 — 패키지 매니저로 단독 사용 가능

Deno (JSR·npm)

• deno install 명령
• URL import와 JSR 중심

2025 권장

• 단일 앱: pnpm 또는 bun
• 모노레포: pnpm workspaces + Turborepo/Nx
• 속도 극대화: bun install (Node 프로젝트에도 단독 쓰기 OK)

10장 · 프레임워크와의 궁합

Node.js

• 호환 안 되는 프레임워크 거의 없음
• Express·Koa·Fastify·NestJS·Hapi 모두 1급 시민

Bun

• Hono(신성), Elysia (Bun 전용), Fastify 2-3배 속도 향상
• Next.js·Remix·SvelteKit 개발 모드 극단적으로 빠름
• Prisma·Drizzle 완벽 지원

Deno

• Hono, Fresh (Deno 전용 SSR), Oak
• Next.js·Remix 정식 지원 계속 보강 중

Cloudflare Workers

• Hono가 de facto — 전 런타임 동일 API
• Remix on Workers·Next.js on OpenNext 성숙 진행
• Express·NestJS는 호환 제한

Hono — 2024~2025의 다크호스

• 모든 런타임에서 동일한 코드 (Node·Bun·Deno·Workers·Vercel Edge·Fastly)
• 초경량 (~20KB), 빠름
• TypeScript first
• 주간 다운로드 100만+ 돌파

import { Hono } from "hono";

const app = new Hono();
app.get("/", (c) => c.text("Hello!"));
app.get("/user/:id", (c) => c.json({ id: c.req.param("id") }));

export default app; // 모든 런타임에서 동작

11장 · 전환 전략 — 이미 Node면 어떻게 옮기나

부분 전환 시나리오

시나리오 1 — 스크립트·CLI만 Bun

• 빌드·테스트·마이그레이션 스크립트만 Bun으로 전환
• 프로덕션 서버는 그대로 Node
• ROI 최고, 리스크 최저

시나리오 2 — Edge 레이어 도입

• API·미들웨어 일부를 Hono + Cloudflare Workers로 분리
• 기존 Node 백엔드는 Origin으로
• 지연·비용 개선

시나리오 3 — 전면 Bun 전환

• 소규모 신규 서비스부터
• 프로덕션 모니터링·롤백 계획 필수
• 1-2주 shadow run 후 프로모션

리스크 체크

• Native addon (sharp·canvas·better-sqlite3) 호환 확인
• 메모리 패턴 — Bun JSC는 V8과 GC 전략 다름
• 로깅·모니터링 — Sentry·Datadog 모두 Bun·Deno 지원 확인 (2025 기준 대부분 OK)
• 배포 파이프라인 — Docker 이미지·Alpine 호환·ARM64

12장 · 한국 생태계 현황

도입 사례

• 토스: Node LTS + 일부 Bun 실험
• 쿠팡: Java·Spring + Node Side Services
• 네이버: Spring + Node + Rust (범용성)
• 카카오: Kotlin + Node + Python
• 당근: Ruby + Node + Go 혼합
• 라인: Java·Kotlin + Node
• 스타트업: Next.js·Nest.js + Node/Bun/Edge

한국어 커뮤니티 자원

• FEConf·DEVIEW·if(kakao)·SLASH(Toss) 발표 영상
• Outsider·JunilHwang·milooy·bitkunst·pumpkiinbell 블로그
• Velog·Medium 한국어 튜토리얼 다수
• 디스코드 React Korea·SvelteKit Korea

채용 시장

• 2024~2025년 Node/TypeScript·Next.js 요구가 압도적
• Bun·Deno·Edge는 선호 스킬에 자주 올라옴
• Java·Kotlin·Go·Rust는 백엔드 인프라 중심

13장 · 체크리스트·안티패턴·다음 글 예고

런타임 선택 체크리스트 (12개)

1. 안정성 최우선 장기 서비스 → Node.js LTS
2. 최대 속도·DX → Bun
3. TypeScript 네이티브·보안 우선 → Deno
4. 글로벌 Edge → Cloudflare Workers·Vercel Edge
5. WebAssembly·Polyglot → Fastly Compute
6. 프레임워크는 Hono(런타임 무관) 고려
7. 패키지 매니저 pnpm 또는 bun
8. 번들은 esbuild·swc·Rolldown·Turbopack
9. 테스트는 Vitest·Bun test·Node test
10. 프로덕션 모니터링(Sentry·Datadog) 호환 확인
11. Native addon (sharp·canvas) 호환 확인
12. 팀 역량·학습 곡선 고려

런타임 안티패턴 TOP 10

1. "Bun이 빠르대"로 프로덕션 전면 전환
2. Cold start 테스트 없이 Serverless 배포
3. Edge에서 Node API 쓰다가 배포 직전 깨짐
4. TS 타입 체크를 스킵 (런타임이 실행한다고 안전 X)
5. --experimental-* 플래그를 프로덕션에
6. 동일 앱을 Node + Bun 혼합 실행
7. child_process 과용 (Serverless·Edge에서 동작 X)
8. 커넥션 풀 누수 — Edge에서 특히 심각
9. 모니터링·APM 연동 없이 프로덕션
10. 벤치마크를 그대로 믿기 — 실전은 다르다

다음 글 예고 — Season 7 Ep 2: "Modern Backend Framework"

런타임 위에 올리는 프레임워크. Ep 2는 2025년 백엔드 프레임워크 지도.

• NestJS·Fastify·Hono·Elysia·Encore·AdonisJS
• tRPC·GraphQL·REST·gRPC 선택
• Spring Boot·Quarkus·Micronaut (JVM)
• FastAPI·Django·Litestar (Python)
• Go: Gin·Echo·Chi·Fiber·Huma
• Rust: Axum·Actix·Rocket·Poem
• 선택 기준: 팀·타입·성능·생태계
• tRPC로 Full-stack 타입 공유
• API 게이트웨이와 BFF 패턴
• "Boring Technology" 철학

"프레임워크는 유행이 아니라 팀의 무기고다. 무기는 많이 쓸수록 익숙해지고, 익숙한 무기가 가장 강하다."

다음 글에서 만나자.

"런타임은 도구이지 종교가 아니다. Node·Bun·Deno·Workers 각자의 강점이 있고, 2025년 현명한 팀은 하나를 고집하지 않고 문제에 맞는 도구를 고른다. Season 7을 이 태도로 시작한다."

— Season 7 Ep 1.