우리가 HttpArena를 만든 이유 — HTTP 프레임워크를 벤치마킹하는 더 나은 방법

발행: 2일 전 (2026년 3월 15일 PM 11:06 GMT+9)

10 분 소요

I’m happy to translate the article for you, but I’ll need the text of the post itself. Could you please paste the content you’d like translated (excluding the source line you already provided)? Once I have the article text, I’ll keep the source link at the top and translate the rest into Korean while preserving all formatting, markdown, and code blocks.

문제

모든 프레임워크는 빠르다고 주장합니다. 블로그 게시물에서는 단일 평문 엔드포인트, 하나의 동시성 수준, 하나의 메트릭으로 X와 Y를 벤치마크합니다. 결과는 5분 정도는 흥미롭지만, 새로운 버전이 출시되면 모든 것이 바뀝니다.

개발자들이 직면한 진짜 질문은 더 어렵습니다: 어떤 프레임워크가 내 워크로드에 가장 적합한가? 대부분의 벤치마크가 실제 워크로드를 테스트하지 않기 때문에 아무도 답을 제시할 수 없습니다.

HttpArena란?

HttpArena는 16개의 서로 다른 테스트 프로파일에 걸쳐 HTTP 프레임워크를 전용, 재현 가능한 하드웨어에서 테스트하는 오픈‑소스 벤치마킹 플랫폼입니다. 클라우드 VM이 없습니다. 소음이 나는 이웃도 없습니다. 동일한 머신, 동일한 로드 제너레이터, 모든 프레임워크에 대해 동일한 조건을 제공합니다.

소스는 GitHub에 있으며 결과는 실시간으로 확인할 수 있습니다.

왜 16개의 테스트 프로파일이 필요할까?

단일 “초당 요청 수”는 상황에 대한 맥락 없이 거의 의미가 없습니다. HttpArena는 다양한 현실적인 시나리오에 걸쳐 프레임워크를 테스트합니다.

연결 동작

Baseline: 512, 4 K, 16 K, 32 K 동시 연결에서 — 연결 수를 늘릴수록 성능이 어떻게 확장되는가?
Pipelined — 연결당 16개의 요청을 사용하는 HTTP 파이프라이닝.
Limited connections — 제한된 풀에서의 연결 재사용.

실제 워크로드

JSON 처리 — 데이터셋을 파싱하고, 파생 필드를 계산한 뒤, 응답을 직렬화.
Compression — 큰 페이로드를 실시간으로 gzip 압축.
Upload — 다양한 크기의 요청 본문을 처리.
Database — 동시 부하 하에서 SQLite 쿼리 실행.

복원력

Noisy — 정상 요청, 잘못된 메서드, 존재하지 않는 경로가 뒤섞인 경우. 서버가 안정적으로 유지되는가?
Mixed — 모든 엔드포인트 유형을 동시에 호출. 실제 트래픽에 가장 가깝습니다.

프로토콜

HTTP/2 및 HTTP/3 — 이를 지원하는 프레임워크용.
Static file serving over HTTP/2.
gRPC — TLS 사용 여부에 따른 단일 호출.
WebSocket — 에코 서버 성능.

플레인텍스트에서는 뛰어나 보이던 프레임워크가 JSON 직렬화에서는 무너질 수 있습니다. 512 연결을 멋지게 처리하던 것이 32 K에서는 버벅일 수도 있죠. 개별 테스트마다 최고 성능을 보이던 것이 모든 엔드포인트를 동시에 호출하면 경쟁 문제가 발생할 수 있습니다. 단일 프로파일 벤치마크로는 이런 점들을 전혀 알 수 없습니다.

Source: …

무엇이 다르게 만드는가

재현성

모든 프레임워크는 동일한 전용 하드웨어에서 Docker 컨테이너로 실행됩니다. Dockerfile, 소스 코드, 테스트 설정은 모두 레포에 포함되어 있습니다. 누구든지 레포를 클론하고 결과를 재현할 수 있습니다.

정확성 우선

성능 테스트를 진행하기 전에, 모든 프레임워크는 18‑포인트 검증 스위트를 통과해야 합니다. 이 스위트는 다음을 확인합니다:

쿼리 파라미터와 요청 본문의 올바른 산술 연산.
무작위 입력을 이용한 안티‑치트(하드코딩된 응답 없음).
올바른 HTTP 상태 코드(존재하지 않는 라우트는 404, 잘못된 메서드는 4xx).
정확한 Content-Type 헤더.
계산된 필드를 포함한 유효한 JSON 처리.
실제로 압축되는 Gzip 압축.
손상된 요청에 대한 복원력.

프레임워크가 검증을 통과하지 못하면 벤치마크에 포함되지 않습니다. 서버가 올바르게 동작하지 않으면 성능 수치는 무의미합니다.

사과 대 사과(동일 조건 비교)

모든 프레임워크는 동일한 엔드포인트와 동일한 동작을 구현합니다. JSON 엔드포인트는 동일한 데이터셋을 처리하고, 압축 엔드포인트는 동일한 페이로드를 gzip으로 압축합니다. 데이터베이스 엔드포인트는 동일한 쿼리를 실행합니다. 변수가 되는 것은 오직 프레임워크 자체뿐입니다.

늘어나는 프레임워크 목록

현재 우리는 Rust, Go, C, C++, Java, C#, JavaScript(Node, Bun, Deno), Python, Ruby, Lua 등 다양한 언어의 35개 이상 프레임워크를 테스트하고 있습니다. 새로운 프레임워크가 정기적으로 추가되고 있으며, 최근 추가된 프레임워크로는 Crystal, Zig, Nim, Swift, Gleam 등이 있습니다.

당신의 프레임워크 추가하기

프레임워크를 추가하는 과정은 간단합니다:

Dockerfile 생성 — 멀티‑스테이지 빌드, 최소 런타임 이미지.
엔드포인트 구현 — /baseline11, /pipeline, /json, /compression, /upload 및 선택적으로 /db, /baseline2(HTTP/2), /static/*.
meta.json 추가 — 프레임워크가 구독하는 테스트 프로파일을 선언.
PR 열기 — 검증이 CI에서 자동으로 실행됩니다.

frameworks/ 디렉터리 안에 있는 기존 프레임워크를 살펴보면 작동 예시를 확인할 수 있습니다. 프레임워크에 익숙하다면 전체 과정은 약 한 시간 정도 걸립니다.

이 문서는 누구를 위한 것인가?

프레임워크를 선택하는 개발자 — 후보들이 다양한 워크로드에서 어떻게 성능을 내는지, 단순 텍스트만이 아니라 확인하세요.
프레임워크 작성자 — 다차원 성능 데이터를 얻고, 생태계와 비교할 수 있는 표준화된 방법을 제공합니다.
성능 엔지니어 — 재현 가능하고 오픈소스인 벤치마크를 직접 하드웨어에서 실행할 수 있습니다.
호기심 있는 사람 — 때때로 단순히 얼마나 빠르게 될 수 있는지 알고 싶을 때.

확인해 보세요

실시간 결과:
소스 및 기여:

우리는 이를 공개적으로 구축하고 있으며 적극적으로 기여를 환영합니다. 좋아하는 프레임워크가 아직 포함되지 않았다면 추가해 주세요. 우리의 방법론을 개선할 수 있다고 생각한다면 이슈를 열어 주세요. 목표는 커뮤니티에 가장 유용하고 솔직한 벤치마크 데이터를 제공하는 것입니다.