Rust 대 Node.js: 백엔드 벤치마크 및 대기 시간

Sharkbench는 동시 HTTP 요청, I/O 작업 및 JSON 직렬화를 처리하는 프레임워크의 기능이라는 세 가지를 측정하는 독립적인 커뮤니티 프로젝트입니다. 테스트는 Ryzen 7 7800X3D의 Docker/Linux에서 실행되며 최종 공개 업데이트는 2025년 8월 24일입니다(sharkbench.dev/web, 2026년 8월 24일 액세스).

출처: Sharkbench, 2025년 8월 24일 — Docker/Linux, Ryzen 7 7800X3D.

Axum(Cargo.toml에서 검증된 Aurabase가 Rust 코어에 사용하는 프레임워크)인 Axum은 이 벤치에서 초당 21,030개의 요청을 처리합니다. 프로덕션에서 가장 많이 사용되는 Node.js 프레임워크인 Express는 동일한 하드웨어에서 5,766개를 처리합니다(3.6배). 이것은 고립된 사례가 아닙니다. 테스트된 4개의 Rust 프레임워크는 모두 18,00022,000req/s의 좁은 범위에 속하는 반면, 테스트된 3개의 Node.js 프레임워크는 5,7669,340개 사이로 제한됩니다.

실제로 "req/s"는 트래픽이 적은 사이트에서 격리된 요청의 속도가 아니라 지속적인 동시 로드 시 처리량을 측정합니다. 몇 초마다 한 번씩 호출되는 엔드포인트의 경우 차이가 전혀 나타나지 않습니다. 실시간 흐름, 트래픽이 많은 공개 API, 수천 건의 호출을 하나로 묶는 작업 등 동일한 하드웨어에 대해 CPU 코어당 처리된 요청 수가 인프라 비용을 직접적으로 설정하는 핫 엔드포인트에서 결정적인 역할을 합니다.

평균 대기 시간은 이 벤치에서 동일한 계층 구조를 따릅니다. 테스트된 Rust 프레임워크의 경우 1.41.7ms인 반면, 테스트된 Node.js 프레임워크의 경우 3.45.5ms입니다.

출처: Sharkbench, 2025년 8월 24일 — p99가 아닌 중간 대기 시간.

이 수치는 p99가 아닌 평균입니다. 관리되는 런타임의 가비지 일시 중지는 대부분 디스패치 큐(중앙값이 아닌 가장 느린 요청)에 영향을 미칩니다. 이는 이 시리즈의 전용 기사의 주제입니다: 가비지 수집기가 없으면 p99 대기 시간이 변경되는 이유.

Rust는 소유권에 따라 메모리를 관리하며, 컴파일 타임에 확인됩니다. 백그라운드에서 실행되거나 실행을 방해하는 가비지 수집기가 없습니다. 공식 Rust Book은 이를 다음과 같이 요약합니다: "소유권의 어떤 기능도 프로그램이 실행되는 동안 속도를 늦추지 않습니다." (The Rust 프로그래밍 언어, doc.rust-lang.org, 2026년 8월 24일 액세스). 메모리는 자신을 소유한 변수가 범위를 벗어나자마자 해제됩니다. 이는 런타임에 예측할 수 없는 일시 중지가 아니라 컴파일 타임에 알려진 시간입니다.

fn main() {
    let data = String::from("réponse API"); // `data`는 문자열을 소유합니다
    process(data); // 소유물은 여기에서 떠난다
    // 여기서 `data`는 더 이상 유효하지 않습니다. 매달린 포인터도 없고 이중 해제도 없습니다.
} // 여기서 '데이터'는 결정론적으로 공개됩니다.

fn process(s: String) {
    println!("{s}");
} // 여기서 `s`는 범위를 벗어납니다. 가비지 수집 패스 없이 즉시 릴리스됩니다.

반대로 Node.js는 단일 JavaScript 스레드에서 실행되고 다단계 이벤트 루프(타이머, 지연된 콜백, 폴링, 검사...)를 통해 I/O 작업을 커널에 위임합니다. 하지만 V8 엔진의 가비지 수집 전달을 포함하여 해당 스레드의 모든 동기식 계산은 실행되는 동안 실행을 차단합니다(공식 Node.js 문서, nodejs.org, 8월 24일 액세스). 2026). 이는 구현 세부 사항이 아니라 메모리 모델의 차이입니다.

동일한 벤치에서 가장 반직관적인 결과는 Rust와 관련된 것이 아니라 Node.js 자체와 관련된 것입니다. 하나의 동일한 코드, 하나의 동일한 API인 Express는 애플리케이션 코드 줄을 변경하지 않고 Node.js의 5,766개 요청/초에서 Bun의 18,917개 요청/초로 ×3.3배로 증가합니다(Sharkbench, 2025년 8월 24일).

출처: Sharkbench, 2025년 8월 24일 — 동일한 Express 코드, 3개의 JavaScript 런타임.

Deno에서 동일한 Express 코드는 6,088 req/s로 제한됩니다. Bun과는 거리가 멀고 Node.js에 가깝습니다. JavaScript 언어는 세 가지 경우 모두 동일합니다. 게임을 변화시키는 것은 런타임(JS 엔진, 이벤트 루프 구현, 가비지 수집)입니다. 런타임, 버전, 프레임워크를 지정하지 않고 "Rust"를 "Node.js"와 비교하는 것은 언어가 아닌 구성을 비교하는 것과 같습니다.

TechEmpower 프레임워크 벤치마크는 동일한 아이디어를 더 큰 규모로 보여줍니다. 오픈 소스 저장소는 2026년 3월 24일에 업데이트되었으며 가장 최근 라운드(23라운드)는 2026년 3월 16일자 게시물의 주제였습니다(TechEmpower, 2026년 8월 24일 액세스). 이 프로젝트는 수백 가지 구현에 대해 다양한 유형의 테스트를 실행합니다. 이는 단일 테스트가 언어는 물론 프레임워크를 나타내지 않기 때문입니다.

데이터베이스 시장의 플레이어인 Convex는 이 주제에 대해 가장 명확한 입장을 공식화했습니다. 즉, 오해의 소지가 있는 것으로 간주되는 경쟁 데이터베이스 간의 마케팅 "막대 차트 전쟁"에 참여하는 것을 거부하는 것입니다. "확장이 아닌 극장 확장입니다", 팀이 썼습니다(Convex, 2026년 8월 24일 액세스). 우리는 다음과 같은 결론을 공유합니다. 공개된 방법론 없이 단순한 수치는 경쟁사에게도 우리에게도 아무 것도 증명하지 못합니다.

What it changes in concrete terms: hardware (CPU, RAM), exact version of the framework and runtime, size of the JSON payload, level of competition and duration of the test all vary the ranking — sometimes more than the choice of language itself. A bench that does not publish these parameters does not reproduce, therefore does not verify itself — see our complete and reproducible methodology for benchmarking abackend.

The core backend of Aurabase is written in Rust, on axum and tokio — checked in the Cargo.toml of the monorepo: ten services (aura-gateway, aura-auth, aura-db…) share the same workspace dependency axum (0.8) and the same runtime tokio, in 2021 edition. The gateway which routes data plane and management plane traffic relies on hyper in addition to axum — the full details are in our article on the data plane / management plane architecture of the gateway. The structure of the Cargo workspace that supports these ten services is documented in our article on the Cargo workspace.

아직 우리가 가지고 있지 않은 것은 문서화된 방법론 및 하드웨어와 함께 게시된 Aurabase 처리량 또는 대기 시간 수치입니다. 이는 의도적인 것입니다. 우리는 방법론을 그림의 반대 방향보다 먼저 게시하는 것을 선호합니다. 이는 이 시리즈의 향후 기사의 주제입니다.

완전한 아키텍처 비교(Aurabase의 통합 Rust 코어와 직접적인 경쟁업체에서 문서화된 이기종 스택 Elixir/Go/TypeScript/Node)에 대해서는 자세한 비교 Aurabase vs Supabase를 참조하세요. 이미 프로젝트를 마이그레이션하고 있는 경우 Supabase에서 Aurabase로의 마이그레이션 가이드에서 스키마, RLS 정책 및 SDK를 다룹니다.

이 기사에 인용된 모든 라인은 2025년 8월 24일 Sharkbench에서 게시된 내용입니다(Docker/Linux, Ryzen 7 7800X3D).

다음 데이터를 인용하십시오: Sharkbench, "웹 프레임워크 벤치마크", sharkbench.dev/web, 마지막 업데이트: 2025년 8월 24일.

여기에 인용된 벤치에서 Rust 프레임워크는 모두 좁은 범위(18,00022,000req/s, 1.41.7ms)에서 실행됩니다. 이는 Node.js 자체의 Node.js 프레임워크(5,7669,340req/s, 3.45.5ms)보다 훨씬 앞선 것입니다. 그러나 런타임은 언어만큼 상황을 변화시킵니다. Express on Bun은 Rust의 Axum을 거의 따라잡습니다.

원시 성능만으로 백엔드를 평가하는 경우 하드웨어, 버전, 페이로드 크기, 경쟁 수준 등 숫자 앞에 방법론이 필요합니다. Aurabase는 아직 자체 수치를 출시하지 않았습니다. 그렇게 되면 방법론이 먼저 나올 것입니다.