Dev Hub1 month ago

Fastify vs Hono — Edge와 WebAssembly 환경에서 마주하는 성능 장벽

클라우드플레어 워커나 웹어셈블리(Wasm) 같은 초경량 에지 런타임이 주류로 부상하면서 백엔드 프레임워크를 고르는 기준이 완전히 바뀌었습니다. 기존 Node.js 기반 환경의 강자인 Fastify와 에지 네이티브 프레임워크로 급부상한 Hono는 설계 철학부터 성능 특성까지 극명한 대조를 보입니다. 샌드박스 환경에서 두 프레임워크의 아키텍처 차이가 콜드 스타트와 런타임 성능에 어떤 영향을 미치는지, 그리고 두 기술의 실전 결합 패턴까지 명확히 짚어봅니다.

웹 표준 네이티브 vs Node.js 의존성: 아키텍처의 근본적 차이

Hono와 Fastify의 가장 큰 아키텍처 차이는 프레임워크가 가정하는 기반 런타임의 표준에서 출발합니다. APIScout 등의 분석에 따르면 Hono는 처음부터 웹 표준 API인 Request, Response, FetchEvent를 기반으로 설계되어 외부 의존성이 없으며 번들 크기도 12~14kB 수준에 불과합니다. 반면 Fastify는 단일 Node.js 프로세스의 성능을 극한으로 끌어올리기 위해 node:http, node:net, node:stream 같은 Node.js 핵심 모듈 및 Pino 로거와 깊게 결합되어 있습니다.

이 설계 방향성은 두 프레임워크가 가장 뛰어난 성능을 발휘하는 무대를 완전히 갈라놓습니다. Fastify는 롱러닝 프로세스 기반의 모놀리식 서버 환경에서 고성능 JSON 직렬화와 라우팅 최적화를 통해 압도적인 처리량을 자랑합니다. 하지만 운영체제 수준의 네트워크 소켓이나 완전한 Node.js API가 제공되지 않는 에지나 Wasm 샌드박스 환경에서는 이러한 Node.js 전용 최적화 기법들이 오히려 동작을 무겁게 만드는 원인이 됩니다.

Wasm이나 초경량 에지 런타임에서 Fastify를 무리하게 실행하려면 Node.js 핵심 모듈을 모방하는 복잡한 폴리필 어댑터를 함께 불러와야 합니다. 이는 가볍고 빠른 기동이 핵심인 샌드박스에서 무거운 번들 크기와 콜드 스타트 지연을 유발합니다. 반면 Hono는 별도의 런타임 변환 계층 없이 에지 환경의 웹 표준 규격을 그대로 활용하여 오버헤드 없이 즉각 실행됩니다.

nodejs_compat이 해결하지 못한 '콜드 스타트'와 번들 크기 장벽

클라우드플레어 공식 문서에 따르면 워커가 nodejs_compat 호환성 플래그를 기본 제공하면서 에지 환경에서 일부 Node.js API를 사용할 수 있는 길이 열렸습니다. 하지만 Fastify를 에지 환경이나 WebAssembly(Wasm) 샌드박스 내부에서 직접 구동하는 것은 여전히 까다롭습니다. Fastify가 온전히 동작하려면 node:http, node:net, node:stream 같은 대형 핵심 모듈이 필요하기 때문에, 이를 대체할 무거운 폴리필 심과 어댑터를 함께 번들링해야 하기 때문입니다.

이로 인해 전체 번들 크기가 급격히 늘어나며 에지 환경의 핵심 강점인 콜드 스타트 속도가 치명적인 지연을 겪습니다. 에지 네이티브로 설계된 Hono가 12~14kB 수준의 가벼운 크기로 10ms 이하의 빠른 기동을 달성하는 반면, Fastify를 에지에서 직접 실행하면 번들 오버헤드로 인해 수백 밀리초 수준의 콜드 스타트 지연이 유발될 수 있습니다.

여기서 중요하게 짚고 넘어갈 부분은 프레임워크 자체의 구동 방식입니다. Fastify를 Wasm 샌드박스 내부에서 통째로 실행하려는 시도는 호환성 레이어의 한계와 이중 래핑 때문에 심각한 성능 페널티를 동반합니다. 하지만 일반적인 Node.js 런타임에서 Fastify를 서버로 띄워두고, CPU 집약적인 보안 필터링이나 데이터 변환 같은 특정 로직만 WASI 인터페이스 기반의 로컬 Wasm 바이너리로 넘기는 하이브리드 구조를 채택하면 매우 효율적인 병목 해결이 가능합니다.

컨텍스트 라이프사이클의 충돌: 정적 플러그인 vs 동적 컨텍스트

백엔드 프레임워크가 요청을 처리하고 상태를 관리하는 방식은 서버리스 환경에서 생존을 결정하는 중요한 요소입니다. Hono는 에지 환경의 특성에 맞게 매 요청마다 격리된 독립적인 컨텍스트 객체인 c를 핸들러로 직접 전달하도록 설계되었습니다. 반면 Fastify는 서버가 처음 구동될 때 전역적으로 플러그인을 등록하고 데이터베이스 연결이나 환경 변수를 미리 데코레이터로 주입해 두는 정적 스코프 방식을 지향합니다.

이러한 수명 주기의 차이는 클라우드플레어 워커 같은 서버리스 런타임에서 결정적인 한계로 작용합니다. 에지 환경의 핵심 리소스인 데이터베이스나 키-값 저장소 바인딩은 전역 범위가 아니라 매 요청이 발생하여 fetch 핸들러가 실행되는 시점에만 안전하게 주입되기 때문입니다. 따라서 Fastify의 정적 초기화 방식은 에지 환경에서 실행할 때 자원에 접근하기 어려워지며, 결국 매 요청 내부에서 수동으로 바인딩을 추출하는 비효율적인 우회 코드를 강제하게 됩니다.

Hono는 이러한 수명 주기 불일치를 컨텍스트 객체 하나로 완벽하게 해결합니다. 다음 코드는 Hono v4 기준으로 에지 환경의 바인딩을 어떻게 자연스럽게 다루는지 보여줍니다.

typescript

import { Hono } from 'hono';

const app = new Hono<{ Bindings: { DB: D1Database } }>();

app.get('/users', async (c) => {
  // 요청 컨텍스트 c.env에서 동적으로 주입된 DB 바인딩을 즉시 가져옵니다.
  const db = c.env.DB;
  const { results } = await db.prepare('SELECT * FROM users').all();
  return c.json(results);
});

Hono는 컴파일 타임에 동적 환경 변수나 에지 바인딩의 타입을 완벽하게 지원하면서도, 개발자가 전역 상태 오염 걱정 없이 안전하게 자원을 다룰 수 있게 돕습니다. 반면 Fastify는 모든 리소스를 부트스트랩 단계에서 데코레이터로 동적 할당하려고 하기 때문에, 요청 단위로 격리되는 서버리스 환경의 자원 모델과 끊임없이 충돌하게 됩니다. 결국 에지와 Wasm 환경에서 애플리케이션을 가볍고 직관적으로 빌드하려면, 동적 요청 컨텍스트 기반의 아키텍처를 선택하는 것이 합리적입니다.

대안적 하이브리드 패턴: Fastify와 Wasm의 효율적인 결합

Fastify 프레임워크 자체를 웹어셈블리(Wasm) 에지 런타임 안에서 직접 구동하는 것은 비효율적입니다. 호환성 레이어를 거치느라 무거운 콜드 스타트와 런타임 제약이 발생하기 때문입니다. 하지만 Fastify와 Wasm을 완전히 분리해 생각할 필요는 없습니다. 고성능 Node.js 환경에서 작동하는 Fastify를 인그레스 게이트웨이로 활용하고, CPU 집약적인 무거운 연산만 로컬 Wasm 바이너리에 위임하는 하이브리드 아키텍처는 훌륭한 대안이 됩니다.

이 하이브리드 패턴은 node:wasi를 사용해 로컬 Wasm 모듈을 Node.js 프로세스 안에서 직접 실행하는 방식입니다. AI 토큰화나 암호화 연산, 웹 애플리케이션 방화벽 보안 필터링 같은 연산 집중형 작업을 Wasm에 넘기면 단일 스레드로 동작하는 Node.js의 이벤트 루프가 차단되는 현상을 완벽하게 방어할 수 있습니다. 런타임에 성능 저하를 일으키는 무거운 작업을 격리하면서도 연산 속도를 크게 향상시킬 수 있어 매우 실전적인 해결책이 됩니다.

다만 고주파 마이크로서비스 환경에서는 자바스크립트 엔진과 Wasm 샌드박스의 격리된 메모리 경계를 넘나들 때 발생하는 데이터 직렬화 비용을 정밀하게 측정해야 합니다. 입출력 크기가 작으면서도 내부 연산 비중이 극단적으로 높은 적절한 시나리오를 선택하여 Wasm 오프로딩을 적용해야 데이터 복사 오버헤드로 인한 성능 부작용을 예방할 수 있습니다.

에지와 Monolith의 경계에서 올바른 프레임워크 선택하기

인프라 환경과 애플리케이션의 병목 지점에 따라 Fastify와 Hono의 가치는 완전히 달라집니다. 단일 프로세스에서 대규모 트래픽을 처리하며 엄격한 스키마 검증과 플러그인 생태계가 필요한 컨테이너 기반 아키텍처라면 Fastify가 최상의 선택입니다. 특히 CPU 집약적인 무거운 연산이 필요하다면 Fastify 자체를 WebAssembly 샌드박스에서 실행하여 성능 저하를 겪기보다, Node.js 환경에서 Fastify를 구동하고 연산만 WASI 기반 Wasm 바이너리에 위임하는 하이브리드 패턴이 효율적입니다.

반면 클라우드플레어 워커처럼 지리적으로 분산된 서버리스 환경이나 초경량 에지 런타임을 타깃으로 삼는다면 Hono를 채택해야 합니다. Fastify를 에지 환경에 억지로 맞출 때 발생하는 호환성 레이어의 성능 저하와 번들 크기 비대화, 콜드 스타트 병목을 원천적으로 피할 수 있기 때문입니다. 도구의 우열을 가리기보다 애플리케이션이 실행될 런타임 제약 조건을 먼저 파악하고, 그에 맞는 아키텍처를 영리하게 선택하는 설계 안목이 필요합니다.

참고 링크