벤치마크는 거짓말을 하지 않기 때문에 Vercube를 만들었다

Source: Dev.to

소개

명백한 것부터 시작하자: 네, 이것은 또 다른 Node.js 프레임워크입니다.
나도 알고 있다. 너도 알고 있다. 어딘가에서 카운터가 오버플로우되고 백엔드 개발자가 조용히 탭을 닫았다.

대부분의 경우, 그것이 올바른 반응이다. 이미 NestJS, Fastify, 그리고 몇몇 내부 헬퍼가 있을 것이다. 또 다른 프레임워크를 추가하는 것은 보통 의미가 없어 보인다.

Vercube는 다음과 같이 시작되지 않았다:
우리는 새로운 프레임워크가 필요하다.
시작은 다음과 같이였다:
왜 사용하기 좋은 모든 프레임워크는 느려지고, 빠른 프레임워크는 마치 싸우는 느낌이 들까?

이 글은 외부 리뷰가 아니다. 나는 Vercube의 저자다. 내가 그것을 만든 이유, 내가 더 이상 받아들이지 않게 된 가정들, 그리고 벤치마크 결과가 이것이 단순한 부수 프로젝트가 아니라는 것을 알게 된 순간에 대한 이야기다.

문제

오랫동안 백엔드 개발은 강제 선택처럼 느껴졌습니다.

Vercube는 이 두 세계 사이를 계속 선택하고 싶지 않았기 때문에 존재합니다.

동기

1. 장기적인 가독성 – 백엔드 코드는 첫 스프린트가 끝난 뒤에도 읽기 쉬워야 합니다.
2. OOP는 여전히 훌륭한 선택 – 명확한 책임, 명시적인 의존성, 스크립트가 아닌 시스템처럼 읽히는 코드. 데코레이터는 잡음을 추가하지 않고 의도를 표현하는 데 도움이 됩니다.

문제는 OOP 자체가 아니라 대부분의 Node.js 프레임워크가 OOP를 구현하는 방식입니다.

• 대부분의 데코레이터 기반 프레임워크는 런타임 리플렉션에 크게 의존합니다.
• reflect-metadata가 전역 의존성이 됩니다.
• 타입은 런타임에 검사되고, 컨테이너는 동적으로 의존성을 추론하며, 메타데이터는 애플리케이션이 이미 실행 중일 때 스캔·병합됩니다.

이 모든 것이 비용을 발생시키며, 그 비용은 빌드 시간, 콜드 스타트, 레이턴시, 처리량 등 여러분이 원하지 않는 곳에 나타납니다.

Vercube의 접근 방식

여러 면에서 Vercube는 routing-controllers와 같은 프로젝트가 목표로 했던 것이지만, 현대 TypeScript, 현대 런타임, 그리고 성능을 최우선으로 재구성한 것입니다.

핵심 아이디어

그것들을 모두 제거하면 어떻게 될까요?

• Vercube에서는 데코레이터가 런타임 트릭이 아닙니다. 타입을 검사하거나 메타데이터를 스캔하거나 전역 리플렉션 API에 의존하지 않고 구조를 설명합니다.
• 런타임에 결정을 내리지 않으며, 프레임워크를 예측 가능하게 유지하고 일반적인 리플렉션 중심 모델을 완전히 피합니다.

런타임‑무관 설계

• srvx와 기본 제공 Request / Response 인터페이스 위에 구축되었습니다.
• 같은 애플리케이션 모델이 어댑터나 호환성 레이어 없이 Node.js, Bun, Deno에서 동작합니다.

내부의 단순성

• 의존성이 존재한다면, 그것은 당신이 등록했기 때문입니다.
• Vercube의 핵심은 아주 작은 IoC 컨테이너이며, 그 이상도 이하도 없습니다. 의존성을 등록하고 해결할 뿐입니다.
• 숨겨진 스코프도, 프록시 체인도, 요청 시점 의존성 그래프도 없습니다. 컨테이너는 설정 단계에서 작업을 수행하고, 그 이후에는 요청 처리가 가능한 한 직접적입니다.

지루하게 들릴 수도 있지만—그것이 의도된 것입니다.
어느 순간 설계 아이디어만으로는 흥미가 사라지고, 숫자가 우위를 차지합니다.

벤치마크

These benchmarks are not about “winning” against every framework. They’re about showing the real cost of different architectural choices.

All tests use identical endpoints, identical load, and the same environment. Raw data and methodology are public – you can find them on GitHub:

https://github.com/vercube/benchmarks

Build Time

• Build time directly affects developer experience and CI pipelines – yet it’s rarely discussed.
• Vercube builds ~4.6× faster than NestJS in the same setup.
• The difference comes from removing reflection, metadata scanning, and complex bootstrap logic.
• Vercube uses Rolldown – a blazing‑fast bundler that complements this simplified architecture perfectly.

Cold Start

• Cold start matters in serverless environments, autoscaling setups, and frequent restarts.
• Vercube cold starts ~35 % faster than NestJS and over 3× faster than Ts.ED.

Throughput

• Throughput is the metric everyone expects.
• Vercube delivers ~16 % higher throughput than NestJS, while still using decorators and dependency injection.
• The goal isn’t to dominate throughput charts – it’s to stay competitive without giving up structure.

Latency

• Average latency hides problems. p95 shows real behavior under load.
• Vercube stays stable under load and avoids long‑tail latency spikes common in heavier frameworks.

Full‑Lifecycle Performance

• Most frameworks talk about runtime performance.
• Vercube cares just as much about everything that happens before the first request: build time, cold start, startup memory.
• In modern systems – CI‑heavy workflows, serverless deployments, short‑lived instances – these costs add up quickly. The benchmarks show that Vercube performs well across the entire lifecycle, not just during request handling.

왜 작동하는가

결과 뒤에 단일 트릭은 없습니다. 성능은 전체적인 오버헤드 클래스를 제거함으로써 얻어집니다:

• 런타임 리플렉션 없음
• 메타데이터 스캔 없음
• 요청 시점 의존성 해결 없음
• 모든 호출에 추상화 레이어가 존재하지 않음

비싼 작업은 한 번만 발생합니다. 요청당 실행되는 것은 순수 JavaScript입니다.

이는 또한 예상치 못한 상황이 적다는 것을 의미합니다. 무언가가 특정 방식으로 동작할 때, 그 이유가 보통 명확합니다.

많은 개발자들이 데코레이터를 느리거나 과도하게 설계된 시스템과 연관 짓습니다. 이는 도구 문제이며 – 패러다임 문제는 아닙니다.

Vercube는 OOP를 유지하고, 데코레이터를 유지하며, 깔끔한 구조를 유지하면서도 일반적으로 훨씬 더 최소화된 프레임워크에만 기대되는 성능 수치를 달성할 수 있음을 보여줍니다.

결론

나는 Vercube를 단순히 성능에 대한 주장을 증명하기 위해 만든 것이 아니라, 프레임워크가 숨겨진 비용을 더하면서 사라지는 개발자 경험을 되찾기 위해 만들었습니다. 리플렉션, 메타데이터 스캔, 런타임에 무거운 추상화를 없애면서 Vercube는 속도를 희생하지 않으면서 익숙하고 구조화된 OOP 경험을 제공합니다.

“빠르지만 기능이 부족한”과 “기능은 풍부하지만 느린” 사이에서 선택하는 것이 지겹다면 Vercube를 한 번 사용해 보세요 – 숫자와 코드, 그리고 철학 모두가 공개되어 검토할 수 있습니다.

프레임워크에 대한 포인트

제가 다시 백엔드 코드를 즐겨 쓰고 싶어서 만들었습니다—빌드 시간, 시작 시간, 런타임 성능에서 그 편의를 포기하지 않고.

벤치마크는 의견을 배제하고 논의를 객관화하기 때문에 중요합니다. 디자인을 좋아하거나 철학에 동의할 필요는 없습니다. 숫자만 보면 됩니다.

그리고 그 숫자들은 OOP가—신중히 적용될 때—현대 백엔드 개발에서도 여전히 자리를 차지하고 있음을 보여줍니다.