Hono v4 vs Elysia v1.4: 250만 RPS 벤치마크와 타입 추론 지연 해결법

TypeScript 백엔드 개발에서 성능과 타입 안전성은 더 이상 타협할 수 없는 기준이 되었습니다. 이 흐름을 주도하는 Hono v4와 Elysia v1.4는 가볍고 빠른 RPC 기반 개발 경험을 제공하며 현대적인 백엔드 아키텍처의 강력한 대안으로 떠올랐습니다. 하지만 단순히 벤치마크 수치만 보고 선택했다가는 멀티 런타임 호환성 문제나 스키마 검증 성능 병목, 심지어 대규모 모노레포에서 에디터가 멈추는 타입 컴파일러 지연 현상에 직면할 수 있습니다. 각 프레임워크의 내부 동작과 아키텍처 한계를 비교하며 우리 팀에 맞는 현실적인 선택지를 찾아봅니다.

성능 벤치마크 분석: 250만 요청과 현실적인 처리량의 차이

프레임워크를 평가할 때 단순 문자열을 반환하는 벤치마크 수치만 맹신하는 것은 위험합니다. Elysia v1.4는 Bun의 HTTP 엔진에 맞춰진 정적 코드 분석과 실시간 JIT 컴파일 기술을 활용해 헬로월드 벤치마크에서 초당 최대 250만 요청을 처리해 냅니다. 반면 Hono는 Bun에서 120만~180만 요청, Node.js에서 약 35만 요청을 기록하며 겉보기에는 큰 격차를 보입니다.

하지만 데이터베이스 조회나 라우팅이 결합하는 실제 운영 환경에 가까워질수록 이 격차는 급격히 줄어듭니다. 현실적인 시나리오에서 Elysia의 평균 처리량은 초당 약 6만 5천~7만 1천 요청 수준으로 감소하며, Hono 역시 초당 약 5만 5천~6만 2천 요청을 기록하며 바짝 추격합니다. 여기에 기본적인 데이터 검증 파이프라인까지 추가되면 Elysia조차 초당 약 3만 3천 요청 수준으로 떨어집니다.

결국 마케팅용 벤치마크의 초당 수백만 요청은 실제 운영 환경과 큰 괴리가 있습니다. 진짜 성능 병목은 프레임워크 라우팅 엔진보다 데이터베이스 입출력이나 스키마 검증 단계에서 발생하기 마련입니다. 따라서 단순한 처리량 지표보다는 서비스의 아키텍처 구조와 배포 환경에 맞는 현실적인 제약 조건을 먼저 검토해야 합니다.

런타임 이식성: 모든 웹 표준 vs Bun 전용 최적화

Hono v4의 가장 큰 무기는 압도적으로 가벼운 약 14KB의 번들 크기와 뛰어난 이식성입니다. 웹 표준 단체인 WinterCG 규격을 엄격히 준수하여 설계되었기 때문에 Request, Response, fetch와 같은 표준 API를 적극적으로 활용합니다. 덕분에 개발자는 작성한 애플리케이션 코드를 전혀 수정하지 않고도 Cloudflare Workers, Fastly Compute, Deno, 심지어 전통적인 Node.js 환경까지 자유롭게 넘나들며 배포할 수 있습니다. 멀티 클라우드나 서버리스 에지 인프라를 우선적으로 고려하는 팀에게는 매우 합리적인 선택지입니다.

반면 Elysia v1.4는 설계 단계부터 Bun의 런타임 성능을 극대화하도록 최적화되었습니다. Bun의 자바스크립트코어(JavaScriptCore) JIT 컴파일 특성과 하위 레벨 HTTP 엔진에 밀접하게 결합되어 있어, Bun 환경 안에서만 본래의 압도적인 처리 속도를 제대로 발휘합니다. Node.js 환경을 지원하는 공식 어댑터인 @elysia/node가 제공되기는 하지만, Bun을 벗어나는 순간 Elysia 고유의 속도 우위는 대부분 무색해집니다. 따라서 구동 환경을 특정 런타임에 종속시키지 않고 유연하게 가져가야 하는 아키텍처라면 인프라 요구사항과 프레임워크의 특성을 먼저 대조해 보아야 합니다.

검증 오버헤드: TypeBox JIT 컴파일 vs Zod 런타임 평가

실제 백엔드 애플리케이션의 성능 병목은 라우팅보다 데이터 검증 레이어에서 더 자주 발생합니다. 대다수 개발자가 애용하는 Zod는 런타임에 스키마를 재귀적으로 분석하고 평가하므로, 요청이 몰릴 때 CPU 오버헤드가 급증하는 한계가 있습니다.

반면 Elysia는 스키마를 고도로 최적화된 JavaScript 함수로 실시간 컴파일하는 TypeBox를 기본 탑재했습니다. 미리 컴파일된 검증 함수를 실행하는 방식 덕분에 TypeBox는 Zod 대비 약 2배에서 4배 더 빠른 검증 속도를 보여줍니다.

최근 웹 생태계는 검증 라이브러리의 파편화를 해결하기 위해 공통 규격인 Standard Schema 표준을 도입했습니다. Hono v4는 @hono/standard-validator 미들웨어를 통해, Elysia v1.4는 라우트 정의에서 기본적으로 Zod나 Valibot 같은 표준 스키마를 직접 수용하며 두 프레임워크 모두 뛰어난 호환성을 갖췄습니다.

두 프레임워크가 Standard Schema를 통해 동일한 Zod 스키마를 처리하는 방식은 다음과 같이 직관적입니다.

// Hono v4: @hono/standard-validator 활용
import { sValidator } from '@hono/standard-validator';
app.post('/user', sValidator('json', userSchema), (c) => {
  const data = c.req.valid('json');
  return c.json({ success: true, data });
});

// Elysia v1.4: 네이티브 스키마 입력 지원
app.post('/user', ({ body }) => ({ success: true, body }), {
  body: userSchema // Zod 스키마 직접 전달
});

이러한 표준 스키마 통합 덕분에 개발자는 프레임워크를 전환하더라도 기존 검증 로직을 그대로 재사용할 수 있으며, 필요에 따라 성능이 극도로 중요한 경로에만 TypeBox를 선택적으로 도입하는 유연한 설계가 가능해졌습니다.

타입 안전성의 함정: Eden Treaty와 Hono RPC의 tsserver 병목 해결

Elysia의 에덴 트리티(Eden Treaty)와 Hono의 hc 클라이언트는 별도의 코드 생성 단계 없이 완전한 타입 안전성을 동기화해 주는 훌륭한 기술입니다. 하지만 프로젝트가 성장하여 단일 라우터의 엔드포인트가 100개를 넘어가기 시작하면 심각한 개발자 경험 저하가 발생합니다. 복잡하게 중첩된 재귀 제네릭을 실시간으로 추론하는 과정에서 TypeScript 언어 서버(tsserver)가 처리 한계에 도달하기 때문입니다. 이로 인해 코드 자동완성이 10초 넘게 지연되거나 편집기 CPU 점유율이 폭주하는 병목 현상이 일어납니다.

이 병목을 해결하는 가장 확실한 방법은 거대한 단일 라우터 체이닝 구조를 버리고 하위 플러그인 모듈로 라우터를 완전히 격리하는 것입니다. 최상위 앱 인스턴스에 수십 개의 체인을 직접 연결하는 대신, 도메인별로 독립된 인스턴스를 설계한 뒤 조립해야 합니다.

// Elysia 예시: 라우터를 도메인별 플러그인으로 조립
// posts.ts
import { Elysia, t } from 'elysia';

export const posts = new Elysia({ prefix: '/posts' })
  .post('/', ({ body }) => body, {
    body: t.Object({ title: t.String() })
  });

// app.ts
import { Elysia } from 'elysia';
import { posts } from './posts';

const app = new Elysia().use(posts).listen(3000);
export type App = typeof app;

모노레포를 사용하는 대규모 프로젝트라면 각 도메인 라우터를 별도의 빌드 가능한 하위 패키지로 완전히 격리하는 아키텍처를 권장합니다. 타입 추론 엔진이 모든 소스 코드를 실시간으로 깊게 탐색하게 두지 않고, 빌드된 선언 파일(.d.ts)만 참조하도록 제어하여 컴파일러의 연산 부담을 줄이는 방식입니다. 이와 함께 로컬 개발 시에는 전체 타입 검사를 건너뛰고 빌드 파이프라인에서만 엄격하게 검증하도록 빌드 과정을 이원화해야 원활한 편집기 반응 속도를 유지할 수 있습니다.

결론: 이식성과 극한 성능 중 우리 팀에 필요한 것은?

프로젝트의 배포 환경과 우선순위에 따라 선택은 명확하게 갈립니다. 멀티 클라우드나 서버리스 에지 환경으로의 이식성, 그리고 일관되게 짧은 콜드 스타트가 최우선이라면 Hono v4가 가장 안전하고 유연한 선택입니다. 반면 Bun 단일 런타임의 성능을 극대화하여 저지연 초고속 실시간 JSON 검증 인프라를 구축하려 한다면 Elysia v1.4가 최고의 대안이 됩니다.

다만 어떤 프레임워크를 선택하든 프로젝트가 성장하면서 발생하는 타입 컴파일러 지연 현상은 미리 대비해야 합니다. 단일 라우터 파일에 수많은 엔드포인트를 욱여넣기보다는, 처음부터 도메인별 플러그인이나 독립된 서브 모듈로 라우터를 분할 설계해야 코드 편집기 버벅임 없이 쾌적한 개발 경험을 장기적으로 유지할 수 있습니다.

참고 링크