Bun 2.0 프로덕션 도입 6개월 — Node에서 옮기며 본 7가지

핵심 요약

Bun 2.0이 안정화되면서 사내 소규모 API 12개를 6개월에 걸쳐 이전. 콜드 스타트 평균 920ms → 295ms, 컨테이너 메모리 240MB → 142MB. 단 worker_threads 호환성, native addon, TypeScript decorator metadata에서 막힘. 사후 정리.

1. 옮길 수 있었던 것

• Hono, Elysia 기반 HTTP 서버 — 그대로 동작
• Drizzle ORM + Postgres — driver bun:sqlite 호환
• Vitest → bun test — 셋업 동일, 실행 4.2배 빠름
• Redis ioredis — 폴리필 없이 동작

2. 못 옮긴 것

• sharp(이미지) — libvips native, sharp 0.34에서 부분 지원
• Prisma — 5.20부터 공식 지원, 그 전 버전 query engine 충돌
• @aws-sdk v3 — credential provider 일부 hang
• NestJS — decorator metadata 동작 불일치

3. 실측 비교

4. monorepo 함정

Turborepo와 함께 쓰면 lockfile 분기점에서 일관성 깨짐. bun.lockb는 binary라 PR diff 안 보임 — 정책상 거부되는 팀 있음. text 형식 bun.lock 옵션 2.0부터 추가.

5. 결정 기준

새 프로젝트 — Bun 우선 검토. 기존 NestJS·Prisma 4 이하·sharp 무거운 코드는 미루기. Lambda는 Bun 런타임 아직 없음(AWS LWA로 우회 가능하나 부담).