Axum 대 Actix-web: 프로덕션에 어떤 Rust 프레임워크가 있나요?

Axum과 Actix-web은 둘 다 Rust의 참조 비동기 런타임인 Tokio에서 실행됩니다. Actix-web README에서는 이를 "Tokio 전체 호환성"이라고 직설적으로 설명하고 있으며 공식 코드 예제에서는 역사적인 actix 프레임워크의 행위자를 사용하지 않습니다. #[get(...)]주석이 달린 클래식 async fn 핸들러이면 충분합니다. "Actix-web에는 반드시 행위자가 필요합니다"라는 혼란은 더 이상 현재 API에 해당하지 않습니다.

Axum은 도쿄의 직접적인 궤도에서 탄생했습니다. 저장소는 GitHub 조직 tokio-rs에 속하며 공식 문서는 명확합니다 — "axum은 tokio 및 hyper와 함께 작동하도록 설계되었습니다. 적어도 당분간은 런타임 및 전송 계층 독립이 목표가 아닙니다."

따라서 경쟁하는 두 런타임 사이의 선택이 아니라 동일한 비동기 엔진 위에 HTTP API를 구축하는 두 가지 방법 사이의 선택입니다. 이 비교에서는 미들웨어 모델, 선언된 메모리 보안, 기본 HTTP 표면, crates.io 및 GitHub에서 측정된 채택 등 네 가지 검증 가능한 영역을 다룬 다음 지원 코드와 함께 Aurabase의 Rust 코어가 Axum을 선택한 이유를 설명합니다.

Axum은 독점 미들웨어 시스템을 구축하지 않습니다. 시간 초과, 추적, 압축, 승인 등 tower::Service에 전적으로 의존합니다. 자체 README에 따르면 모든 것이 Tower 생태계를 통해 "무료"로 제공됩니다. Hyper 또는 Tonic 애플리케이션용으로 작성된 미들웨어는 조정 없이 Axum 애플리케이션에서 그대로 재사용할 수 있습니다.

Actix-web은 반대 경로를 취합니다. 즉, 사용자 가이드에 설명된 자체 미들웨어 시스템(Logger, Session, CORS 등)과 자체 관련 HTTP 클라이언트(awc)를 내장합니다. 이는 더욱 통합된 플랫폼입니다. 조립할 부품 수가 적지만 일반 Rust 비동기 생태계의 나머지 부분과의 직접적인 재사용도 적습니다.

라우팅은 동일한 명시적 구성 논리를 따릅니다. Axum은 경로 선언을 위한 "매크로 없는 API"를 주장합니다. Router::new().route(...)는 일반적인 Rust 값으로 유지됩니다. 여기서 Actix-web은 핸들러 바로 위에 배치된 HTTP 메서드(#[get(...)])에 의한 전용 매크로에 의존합니다. 두 가지 진술 스타일, 능력의 차이가 아닙니다.

Axum은 소스 코드에서 #![forbid(unsafe_code)]를 주장합니다. 프레임워크의 100%는 허점 없이 안전한 Rust로 작성되었습니다. Actix-web은 README에 이에 상응하는 설명을 하지 않습니다. 이는 프레임워크가 위험하다는 의미가 아니라 프로젝트에서 공개적으로 그러한 보증을 표시하지 않는다는 의미입니다.

두 프레임워크는 서로 다른 Rust 최소 버전을 설정합니다. Axum은 Rust 1.80과 호환되고 Actix-web에는 Rust 1.88이 필요합니다. 툴체인이 이전 버전에 멈춰 있는 경우 문제가 될 수 있는 Actix-web의 더 좁은 창입니다.

Actix-web은 HTTP/1.x 및 HTTP/2, WebSocket, 투명한 압축(br, gzip, deflate, zstd), OpenSSL 또는 Rustls를 통한 TLS 등 대규모 HTTP 표면을 크레이트에 직접 나열합니다. 선택할 추가 종속성 없이 모든 것이 함께 제공됩니다.

Axum은 라우팅, 추출기, 오류 처리 등 의도적으로 최소한으로 유지됩니다. 나머지(압축, CORS, 요청 제한, 추적)는 동일한 생태계의 동반 크레이트인 tower-http에서 제공됩니다. 예를 들어, Aurabase는 tower-http의 cors, trace, compression-gzip, request-id, timeout 및 limit 기능만 활성화합니다. 이는 전체 패키지가 아닌 의도적인 선택입니다.

Actix-web은 정확한 외부 소스를 인용하여 속도를 주장합니다. "TechEmpower Framework Benchmark(라운드 r21, 복합)에 따라 사용할 수 있는 가장 빠른 웹 프레임워크 중 하나이며 자체 README에 techempower.com에 대한 직접 링크가 포함되어 있습니다. 직접 확인할 수 있는 견적 유형입니다.

Axum은 이에 상응하는 주장을 하지 않습니다. README는 공식적인 프로젝트 수치가 아닌 타사 커뮤니티 벤치마크에 대한 두 개의 링크가 포함된 "axum은 하이퍼 위에 상대적으로 얇은 레이어이며 오버헤드가 거의 추가되지 않습니다"라는 보다 겸손한 설명으로 제한됩니다.

crates.io에서 Axum은 지난 90일 동안 109,000,226건을 포함하여 총 436,464,896건의 다운로드를 기록했습니다. Actix-web는 동일한 최근 창(crates.io, 2026년 8월 23일 액세스)에서 9,730,975건을 포함하여 총 78,074,020건의 다운로드를 누적했습니다. 이 점에서 격차는 분명합니다. 현재 Axum은 Actix-web보다 최근 다운로드 수가 약 11배 더 많습니다.

역설: Actix-web은 Axum의 2021년 7월과 비교하여 2017년 10월부터 crates.io에 게시된 두 가지 중 더 오래된 것입니다. GitHub에서는 인기 격차가 더 좁습니다. tokio-rs/axum의 별 26,931개, actix/actix-web의 별 24,793개(GitHub, 2026년 8월 23일 액세스) — Actix-web은 더 많은 별을 유지합니다. 포크(1,880 대 1,462)는 역사적인 기여자 기반이 여전히 활성화되어 있음을 나타냅니다.

Actix-web은 아직 폐기되지 않았습니다. 해당 버전 4.15.0은 이 기사를 작성하기 3일 전인 2026년 8월 21일에 게시되었습니다. GitHub 문제 대기열에서 Axum은 Actix-web의 192개와 비교하여 75개의 공개 티켓을 표시합니다. 이는 주의해서 읽어야 하는 유지 관리 신호입니다. 거의 4년이 더 긴 기록이 더 긴 대기열을 기계화하지만 이는 덜 신중한 프로젝트의 증거가 아닙니다.

Aurabase 루트 Cargo 작업 공간에는 11개의 서비스가 있습니다. Ten은 인증 및 저장을 포함하여 API 게이트웨이(aura-gateway)에서기본 AI 엔진(aura-ai)까지 Axum에 직접 의존합니다. 열한 번째인 aura-migrator는 HTTP 서버가 없는 마이그레이션 CLI 도구입니다. 선택할 수 있는 것이 아무것도 없습니다. 저장소의 Cargo.toml 또는 루트 Cargo.lock의 항목은 전이적 종속성에서도 actix-web를 선언하지 않습니다. .rs 파일에는 use actix_web::명령어가 포함되어 있지 않습니다.

axum       = { version = "0.8", features = ["ws", "multipart", "macros"] }
tower      = { version = "0.5", features = ["full"] }
tower-http = { version = "0.6", features = ["cors", "trace", "compression-gzip", "request-id", "timeout", "limit"] }
hyper      = { version = "1", features = ["full"] }

이 선택은 겉모습이 아닙니다. Aurabase 게이트웨이(aura-gateway)는 tower::ServiceBuilder 및 Layer 타워(TraceLayer, TimeoutLayer, RequestBodyLimitLayer)로 미들웨어를 스택하고 요청 식별자, 인증 및 보안 헤더를 위해 axum::middleware::from_fn를 통해 내부 레이어로 보완됩니다. 이것이 바로 Axum의 README가 강조하는 구성 모델입니다. Tower 미들웨어는 라우터의 나머지 부분과 독립적으로 스택, 테스트 및 재사용됩니다.

출처: crates.io API(/api/v1/crates/axum, /api/v1/crates/actix-web) 및 GitHub API, 2026년 8월 23일 액세스. 나머지는 공식 README tokio-rs/axum 및 actix/actix-web.

모듈식 다중 서비스 Rust 백엔드를 시작합니다. Axum은 자연스러운 선택입니다. Axum의 Tower 구성을 통해 Aurabase가 10개의 HTTP 서비스 간에 미들웨어를 공유하는 것처럼 서비스 간에 미들웨어를 더 쉽게 공유할 수 있습니다.

기존 및 작동 중인 Actix-web 코드 베이스가 있습니다. 마이그레이션을 서두르지 않습니다. Actix-web은 적극적으로 유지 관리되며 추가 종속성 없이 기본적으로 HTTP/2, WebSocket 및 압축을 지원합니다.

tower-http을 직접 조립하지 않고도 단일 상자에 최대한 많은 HTTP 기능을 제공하기를 원합니다. Actix-web은 이러한 요구에 직접적으로 응답합니다.

이미 Tower 미들웨어를 다른 Hyper 또는 Tonic(gRPC) 서비스와 공유하고 있습니다. Axum은 이러한 레이어를 그대로 재사용합니다. 이것이 Aurabase의 중요한 주장입니다.