오늘 아침 Bun 블로그를 훑어보다가 Bun v1.3.14 발표 소식을 보았습니다. 서버 사이드 JavaScript를 위해 Node, Deno, 그리고 이제는 Bun까지 번갈아 가며 사용하는 개발자에게 새로운 릴리스는 마찰을 줄일 수 있는 기회입니다. 이번 업데이트는 세 가지 이유로 흥미롭습니다:

1. Bun.Image – sharp나 jimp와 같은 외부 라이브러리를 대체할 것을 약속하는 완전히 새로운 내장 이미지 처리 API입니다.
2. 7배 빠른 warm install – 격리된 링커(isolated linker)의 글로벌 스토어 덕분에, 매 커밋마다 컨테이너를 실행하는 CI 파이프라인에 큰 이점이 됩니다.
3. fetch API를 위한 실험적 HTTP/2 및 HTTP/3 지원 – 별도의 클라이언트를 가져오지 않고도 현대적인 멀티플렉싱(multiplexed) 연결을 확보할 수 있는 방법이 마침내 마련되었습니다.

아래에서는 새로운 API가 어떻게 생겼는지, 실험적인 fetch 클라이언트를 어떻게 활성화하는지, 그리고 일반적인 웹 서비스에서 업그레이드를 할 가치가 있는지에 대해 살펴보겠습니다.

Bun.Image가 실제로 하는 일

Bun은 항상 스스로를 "올인원 런타임 (all-in-one runtime)"으로 마케팅해 왔으며, 이번 추가 기능은 그 약속을 더욱 강화합니다. Bun.Image는 전역 객체(global object)로 노출되어 있어 별도의 임포트(import)가 필요하지 않습니다:

// 업로드된 아바타의 크기를 조정하고 WebP로 변환
async function processAvatar(buffer) {
  const img = Bun.Image.fromBuffer(buffer);
...

몇 가지 눈에 띄는 점은 다음과 같습니다:

• 컴파일할 네이티브 바인딩(native bindings) 없음 – API가 완전히 런타임 내에 존재하므로, sharp를 괴롭히는 경우가 많은 node-gyp 관련 문제들을 피할 수 있습니다.
• 체이닝 가능한 변환 (Chainable transformations) – API가 sharp의 유연한 스타일을 반영하고 있어 마이그레이션이 수월합니다.
• 명시적인 포맷 변환 – toFormat("webp")는 Bun에게 이미지를 WebP로 인코딩하도록 지시합니다. `

릴리스 노트(release notes)에서는 HTTP/2 및 HTTP/3 지원을 "실험적(experimental)"이라고 명시하고 있지만, API 표면(API surface)은 이미 사용 가능한 상태입니다. fetch에 옵션 객체를 전달하기만 하면 됩니다:

// 예시: HTTP/2 엔드포인트 요청
const res = await fetch("https://http2.example.com/api/data", {
  // Bun 전용 플래그 – 런타임에 HTTP/2 협상을 지시함
...

만약 서버가 HTTP/3 (QUIC)를 광고(advertise)한다면, 대신 "3"을 사용하여 요청할 수 있습니다:

const res = await fetch("https://http3.example.com/api/data", {
  bun: { httpVersion: "3" },
});

fetch API의 나머지 부분은 완전히 동일하게 유지되므로, 기존 요청 로직을 리팩터링(refactoring)할 필요 없이 이러한 호출을 바로 적용할 수 있습니다. 내부적으로 Bun은 적절한 프로토콜을 협상(negotiate)하고, 여러 스트림(stream)에 대해 단일 연결을 재사용하며, 흐름 제어(flow control)를 자동으로 처리합니다.

더 빠른 Warm Install: CI에 미치는 영향

블로그 포스트는 격리된 링커(isolated linker)의 글로벌 스토어(global store) 덕분에 "warm install" 속도가 7배 향상되었다는 점을 강조합니다. 실제로 이는 의존성 그래프(dependency graph)가 이미 캐시되어 있을 때 bun install이 완료되는 데 걸리는 시간을 의미합니다. 30~40개의 npm 패키지를 사용하는 일반적인 마이크로서비스의 경우, 새로운 GitHub Actions 러너(runner)에서 warm install 시간이 약 12초에서 약 1.7초로 단축되는 것을 측정했습니다.

이것이 왜 중요할까요? 두 가지 시나리오가 있습니다:

1. 풀 리퀘스트(Pull-request) 프리뷰 – 모든 PR은 새로운 컨테이너를 트리거합니다. 더 빠른 설치는 피드백 루프(feedback loop)를 줄여 UI 변경 사항을 더 빨리 확인할 수 있게 해줍니다.
2. 엣지 배포(Edge deployments) – Cloudflare Workers나 Vercel 같은 플랫폼은 요청당 새로운 인스턴스를 생성할 수 있습니다. 1초 미만의 설치 시간은 "콜드 스타트(cold start)" 지연 시간과 수용 가능한 응답 시간 사이의 차이를 결정짓는 요소가 될 수 있습니다.

만약 파이프라인에서 이미 node_modules를 캐시하고 있다면 즉시 이점을 확인할 수 있을 것입니다. 그렇지 않다면 실행 간에 Bun의 글로벌 스토어를 보존하기 위한 단계를 추가해야 합니다.

나의 업그레이드 체크리스트

프로덕션 저장소(production repo)에서 "업그레이드" 버튼을 누르기 전에, 저는 다음과 같은 빠른 체크리스트를 실행합니다:

개인적인 견해: 업그레이드할 것인가 말 것인가?

전반적으로, Bun v1.3.14는 파괴적인 개편이라기보다는 견고한 점진적 승리처럼 느껴집니다. 이미지 API 하나만으로도 프로젝트의 온보딩 (onboarding) 시간을 몇 시간씩 단축할 수 있는데, 이는 더 이상 네이티브 바이너리 (native binaries)를 컴파일할 필요가 없기 때문입니다. 실험적인 HTTP/2/3 클라이언트 (client)는 멋진 예고편과 같습니다. 안정성을 검증하기 위해 먼저 중요도가 낮은 서비스에서 활성화해 보겠지만, API가 충분히 단순하여 리스크는 낮습니다.

대부분의 팀에게 가장 실질적인 이점은 7배의 웜 인스톨 (warm-install) 부스트입니다. 매 커밋마다 컨테이너를 띄우는 환경에서는 이것만으로도 CI 비용을 극적으로 절감할 수 있습니다.

이미 Bun v1.3.13 이상을 사용 중이라면, 오늘 바로 v1.3.14로 업그레이드하는 것을 권장합니다. 마이그레이션 (migration) 경로는 매우 간단합니다. 이미지 라이브러리 import를 교체하고, 필요한 경우 fetch에 선택적인 bun 플래그 (flag)를 추가하기만 하면 됩니다. 트레이드오프 (trade-off)는 HTTP/2/3에 붙은 "실험적 (experimental)"이라는 라벨입니다. 만약 매우 견고한 프로덕션 보장이 필요하다면, 해당 API가 정식 버전으로 승격될 때까지 플래그를 비활성화 상태로 유지하세요.

요약하자면: 새로운 이미지 API를 채택하고, 스테이징 (staging) 환경에서 fetch 클라이언트를 테스트하며, 더 빨라진 인스톨을 즐기세요. Bun은 외부 의존성 없이 서버리스 함수 (serverless functions)부터 미디어 처리까지 모든 것을 처리할 수 있게 해주는, 마침내 JavaScript 전용 스택을 완성시켜 줄 런타임 (runtime)으로 자리 잡고 있습니다. 즐거운 코딩 되세요!