Rust 웹 프레임워크 비교: Actix Web vs Axum — 2026년 가이드와 면접 대비

2026년 현재, Rust를 활용한 웹 백엔드 개발은 더 이상 실험적인 선택이 아닙니다. 프로덕션 환경에서의 Rust 웹 프레임워크 채택이 빠르게 증가하고 있으며, Actix Web 4.13과 Axum 0.8이 업계 표준으로 자리잡았습니다. 어떤 프레임워크를 선택하느냐에 따라 팀 온보딩 속도부터 프로덕션 처리량까지 모든 측면에 영향을 미칩니다.

Actix Web과 Axum의 아키텍처 차이

두 프레임워크 간의 아키텍처 차이가 성능과 개발 경험 사이의 트레이드오프 대부분을 설명합니다.

Actix Web은 물리 코어당 하나의 단일 스레드 Tokio 런타임을 생성합니다. 태스크는 스레드에 고정(pinning)되어 스레드 간 데이터 이동이 발생하지 않습니다. 이를 통해 워크 스틸링 오버헤드와 캐시 라인 충돌이 제거되며, 지속적인 고부하 환경에서의 처리량 우위를 확보합니다.

Axum은 워크 스틸링 기능을 갖춘 단일 멀티스레드 Tokio 런타임에서 실행됩니다. Tokio 팀이 Axum을 설계한 목적은 런타임의 역량을 최대한 보여주는 것이며, 모든 설계 결정이 Tokio 생태계와의 호환성을 최적화합니다. 핸들러는 일반 async 함수이며, 미들웨어에는 Tower의 Service 트레이트가 사용됩니다.

use actix_web::{web, App, HttpServer, HttpResponse};

async fn health() -> HttpResponse {
    HttpResponse::Ok().json(serde_json::json!({ "status": "ok" }))
}

#[actix_web::main]
async fn main() -> std::io::Result<()> {
    HttpServer::new(|| {
        App::new()
            .route("/health", web::get().to(health))
    })
    .bind("0.0.0.0:8080")?
    .run()
    .await
}

use axum::{Router, Json, routing::get};
use serde_json::{json, Value};

async fn health() -> Json<Value> {
    Json(json!({ "status": "ok" }))
}

#[tokio::main]
async fn main() {
    let app = Router::new()
        .route("/health", get(health));

    let listener = tokio::net::TcpListener::bind("0.0.0.0:8080")
        .await
        .unwrap();
    axum::serve(listener, app).await.unwrap();
}

두 코드 모두 컴파일 및 실행이 가능하지만, 차이점이 분명합니다. Actix Web은 자체 #[actix_web::main] 매크로를 사용하고 std::io::Result를 반환합니다. Axum은 표준 #[tokio::main]을 사용하며 Router 구조체로 라우트를 구성합니다. Axum의 핸들러는 타입이 지정된 추출자(Json<Value>)를 반환하므로 HttpResponse를 수동으로 구성할 필요가 없습니다.

성능 벤치마크: Actix Web 4.13 vs Axum 0.8

TechEmpower Round 22 및 커뮤니티의 재현 가능한 테스트에서 얻은 벤치마크 데이터는 일관된 패턴을 보여줍니다.

| 지표 | Actix Web 4.13 | Axum 0.8.9 | |------|---------------|-------------| | JSON 직렬화 (req/s) | 약 720,000 | 약 640,000 | | 일반 텍스트 (req/s) | 약 980,000 | 약 870,000 | | DB 단일 쿼리 (req/s) | 약 180,000 | 약 170,000 | | 메모리 사용량 (hello world) | 약 8 MB | 약 6 MB | | P99 레이턴시 (JSON) | 1.2 ms | 1.4 ms |

Actix Web은 모든 카테고리에서 10~15%의 처리량 우위를 유지합니다. Axum은 공유 Tokio 런타임 덕분에 메모리 사용량이 약간 적습니다. 참고로, 두 프레임워크 모두 동일한 하드웨어에서 Go 표준 라이브러리 HTTP 서버보다 2~3배, Node.js보다 5~8배 높은 성능을 발휘합니다.

이 성능 차이가 중요해지는 분야는 광고 서빙, 실시간 분석 파이프라인, 고빈도 트레이딩 게이트웨이 등입니다. 초당 10,000개의 요청을 처리하는 일반적인 REST API에서는 두 프레임워크 모두 병목 지점을 훨씬 넘어서며, 실제 병목은 데이터베이스나 외부 서비스 호출에 있습니다.

추출자(Extractor)와 요청 처리 비교

추출자는 프레임워크가 수신 요청을 파싱하는 방식을 정의합니다. Axum 0.8에서는 #[async_trait]를 제거하고 네이티브 async trait를 채택했으며, OptionalFromRequestParts 도입으로 Option<T> 처리가 개선되었습니다.

use axum::{
    extract::{Path, Query, State, Json},
    routing::get,
    Router,
};
use serde::Deserialize;
use std::sync::Arc;

#[derive(Deserialize)]
struct Pagination {
    page: Option<u32>,    // defaults to None if missing
    per_page: Option<u32>,
}

// State shared across handlers
struct AppState {
    db_pool: sqlx::PgPool,
}

// Axum 0.8: /{id} syntax (replaced /:id)
async fn get_user(
    State(state): State<Arc<AppState>>,
    Path(user_id): Path<i64>,
    Query(pagination): Query<Pagination>,
) -> Json<serde_json::Value> {
    let page = pagination.page.unwrap_or(1);
    // Query database using state.db_pool
    Json(serde_json::json!({
        "user_id": user_id,
        "page": page
    }))
}

use actix_web::{web, HttpResponse};
use serde::Deserialize;

#[derive(Deserialize)]
struct Pagination {
    page: Option<u32>,
    per_page: Option<u32>,
}

struct AppState {
    db_pool: sqlx::PgPool,
}

async fn get_user(
    state: web::Data<AppState>,
    path: web::Path<i64>,
    query: web::Query<Pagination>,
) -> HttpResponse {
    let user_id = path.into_inner();
    let page = query.page.unwrap_or(1);
    HttpResponse::Ok().json(serde_json::json!({
        "user_id": user_id,
        "page": page
    }))
}

Axum의 추출자는 함수 매개변수에서 튜플 구조분해를 직접 사용합니다. Actix Web은 모든 것을 web::Path, web::Query 등으로 감싸며 .into_inner() 호출이 필요합니다. 두 접근 방식 모두 컴파일 시점에 타입 안전성이 보장되지만, Axum의 방식이 더 자연스럽게 읽힙니다.

미들웨어 아키텍처: Tower vs Actix 미들웨어

미들웨어 구성은 아키텍처 차이가 가장 실질적인 영향을 미치는 영역입니다.

Axum은 Tower의 Service와 Layer 트레이트를 사용합니다. Tower 호환 미들웨어(레이트 리미터, 트레이싱, 압축, 인증 레이어 등)는 모두 Axum에서 동작합니다. 이 호환성은 HTTP를 넘어 확장되어 Tonic을 통해 gRPC 서비스에도 동일한 미들웨어를 적용할 수 있습니다.

use axum::{
    Router, middleware,
    routing::get,
    extract::Request,
    response::Response,
};
use tower_http::{
    cors::CorsLayer,
    compression::CompressionLayer,
    trace::TraceLayer,
};
use std::time::Instant;

// Custom middleware as a plain async function
async fn timing_middleware(
    request: Request,
    next: middleware::Next,
) -> Response {
    let start = Instant::now();
    let response = next.run(request).await;
    let duration = start.elapsed();
    tracing::info!("Request took {:?}", duration);
    response
}

fn build_router() -> Router {
    Router::new()
        .route("/api/data", get(|| async { "ok" }))
        .layer(middleware::from_fn(timing_middleware))
        .layer(CompressionLayer::new())
        .layer(CorsLayer::permissive())
        .layer(TraceLayer::new_for_http())
}

Actix Web은 자체 미들웨어 시스템을 갖고 있으며, Transform과 Service 트레이트(Tower의 것과는 다른)를 사용합니다. Tower 생태계의 미들웨어를 활용하려면 어댑터를 만들거나 다시 작성해야 합니다.

Tonic(gRPC)이나 Hyper를 통해 이미 Tower 생태계에 투자한 팀에게 Axum의 미들웨어는 큰 이점입니다. 독립적인 HTTP 서비스를 구축하는 팀에게는 Actix Web의 미들웨어 시스템도 동등한 기능을 갖추고 있지만, 상호 호환성은 없습니다.

SQLx를 활용한 데이터베이스 통합

두 프레임워크 모두 컴파일 시점에 쿼리를 검증하는 async 우선 SQL 툴킷인 SQLx와 잘 연동됩니다. 통합 패턴에는 약간의 차이가 있습니다.

use sqlx::PgPool;

// This struct works identically with Actix Web and Axum
#[derive(sqlx::FromRow, serde::Serialize)]
struct User {
    id: i64,
    email: String,
    created_at: chrono::NaiveDateTime,
}

// sqlx::query_as! validates against a live DB at compile time
async fn find_user_by_email(
    pool: &PgPool,
    email: &str,
) -> Result<Option<User>, sqlx::Error> {
    sqlx::query_as!(
        User,
        "SELECT id, email, created_at FROM users WHERE email = $1",
        email
    )
    .fetch_optional(pool)
    .await
}

데이터베이스 레이어는 프레임워크 선택과 관계없이 동일합니다. SQLx의 query_as! 매크로는 컴파일 시점에 라이브 데이터베이스에 연결하여 컬럼 이름, 타입, 테이블 존재 여부를 검증합니다. 컬럼 이름의 오타는 런타임 크래시가 아닌 컴파일 에러를 발생시킵니다.

에러 핸들링 패턴 비교

에러 핸들링에는 두 프레임워크의 설계 철학 차이가 드러납니다. Actix Web은 ResponseError 트레이트 구현을 사용하고, Axum은 IntoResponse와 Result 타입의 조합에 의존합니다.

use axum::{
    http::StatusCode,
    response::{IntoResponse, Response},
    Json,
};

// Define application-level errors
enum AppError {
    NotFound(String),
    DatabaseError(sqlx::Error),
    ValidationError(String),
}

// Convert errors into HTTP responses
impl IntoResponse for AppError {
    fn into_response(self) -> Response {
        let (status, message) = match self {
            AppError::NotFound(msg) => (
                StatusCode::NOT_FOUND, msg
            ),
            AppError::DatabaseError(_) => (
                StatusCode::INTERNAL_SERVER_ERROR,
                "Internal server error".to_string(),
            ),
            AppError::ValidationError(msg) => (
                StatusCode::BAD_REQUEST, msg
            ),
        };
        (status, Json(serde_json::json!({ "error": message })))
            .into_response()
    }
}

// Handlers return Result<T, AppError>
async fn get_user(
    axum::extract::Path(id): axum::extract::Path<i64>,
) -> Result<Json<serde_json::Value>, AppError> {
    if id <= 0 {
        return Err(AppError::ValidationError(
            "ID must be positive".to_string()
        ));
    }
    Ok(Json(serde_json::json!({ "id": id })))
}

Axum의 접근 방식은 Rust의 ? 연산자와 Result 타입과 자연스럽게 결합됩니다. Actix Web에서는 ResponseError를 통해 동일한 결과를 달성하지만, Display와 ResponseError 두 트레이트를 모두 구현해야 합니다. 두 방식 모두 동작하지만, From 트레이트와 에러 전파에 익숙한 Rust 개발자에게는 Axum의 패턴이 더 관용적으로 느껴집니다.

Actix Web을 선택해야 하는 경우

다음과 같은 시나리오에서는 Actix Web이 적절한 선택입니다.

• 최대 처리량이 필요한 경우: 광고 서빙, 실시간 입찰, 분석 데이터 수집 파이프라인 등 10~15%의 req/s 향상이 트레이드오프에 충분히 가치 있는 상황입니다.
• WebSocket 중심 애플리케이션: Actix Web의 WebSocket 지원은 더 많은 프로덕션 환경에서 검증되었습니다. Axum의 WebSocket 지원(axum::extract::ws 기반)도 잘 동작하지만 프로덕션 실적이 상대적으로 짧습니다.
• 기존 Actix Web 코드베이스: Actix Web 3.x에서 4.x로의 마이그레이션은 간단합니다. 안정적인 서비스를 Axum으로 재작성하면 얻는 이점은 제한적입니다.
• 팀의 기존 역량: 팀이 이미 Actix Web에 익숙한 경우, 인체공학적 개선을 위해 프레임워크를 전환하는 것은 단기적으로 거의 이점이 없습니다.

Axum을 선택해야 하는 경우

다음과 같은 상황에서는 Axum이 더 적합합니다.

• 2026년 신규 프로젝트: Tokio 생태계(Tonic, Hyper, Tower)와의 연동으로 통합 시 마찰이 줄어듭니다.
• gRPC와 HTTP 혼합 서비스: Tower 미들웨어가 어댑터 레이어 없이 두 프로토콜 모두에서 동작합니다.
• Rust 입문 팀: Axum의 타입 기반 추출자와 컴파일 시점 에러 메시지가 더 완만한 학습 곡선을 제공합니다. /{id} 경로 구문(OpenAPI와 통일)은 즉시 친숙하게 느껴집니다.
• 마이크로서비스 아키텍처: Tower의 Service 트레이트를 통해 서비스 간 미들웨어를 재사용할 수 있어 보일러플레이트가 줄어듭니다.

면접 대비: Rust 백엔드 프레임워크 질문

백엔드 Rust 면접에서 웹 프레임워크에 대한 지식이 점점 더 중요해지고 있습니다. 다음은 시니어 백엔드 및 시스템 엔지니어링 면접에서 출제되는 질문들입니다.

Q: Actix Web과 Axum의 런타임 모델에서 아키텍처적 차이를 설명하십시오.

Actix Web은 CPU 코어당 하나의 단일 스레드 Tokio 런타임을 생성합니다. 태스크가 스레드에 고정되어 워크 스틸링 오버헤드가 제거됩니다. Axum은 워크 스틸링을 사용하는 공유 멀티스레드 Tokio 런타임에서 실행됩니다. Actix Web의 모델은 고부하 시 캐시 라인 경합을 줄여 더 높은 처리량을 실현합니다. Axum의 모델은 모든 태스크가 하나의 런타임을 공유하기 때문에 공유 상태 관리가 간소화됩니다.

Q: Axum 0.8에서 #[async_trait] 제거가 커스텀 추출자에 미치는 영향은 무엇입니까?

Axum 0.8은 2023년 후반에 안정화된 Rust의 네이티브 return-position impl Trait in traits를 활용합니다. FromRequestParts 또는 FromRequest를 구현하는 커스텀 추출자는 #[async_trait] 어트리뷰트 없이 async 메서드를 직접 정의할 수 있게 되었습니다. 이를 통해 Box<dyn Future>의 힙 할당이 제거되고 컴파일 시간이 개선됩니다. 기존 추출자는 매크로 제거와 트레이트 구현 조정이 필요합니다.

Q: Tower 미들웨어와 Actix Web 미들웨어의 차이를 설명하십시오.

Tower는 프로토콜에 구애받지 않는 범용 Service<Request> 트레이트를 정의합니다. Tower의 타임아웃 레이어는 HTTP(Axum), gRPC(Tonic), 그리고 커스텀 프로토콜에서 모두 동작합니다. Actix Web의 미들웨어는 프레임워크에 특화된 Transform과 Service 트레이트를 사용합니다. 실질적 영향은 다음과 같습니다: Axum 미들웨어는 Tower 생태계 전반에서 재사용이 가능하며, Actix Web 미들웨어는 프레임워크에 한정됩니다.

Q: SQLx 컴파일 시점 쿼리 검증의 작동 원리와 트레이드오프는 무엇입니까?

SQLx의 query_as! 매크로는 컴파일 중에 라이브 PostgreSQL 데이터베이스에 연결합니다. SQL 구문, 컬럼 이름, 타입, 테이블 존재 여부를 검증합니다. 트레이드오프로는 빌드 시 데이터베이스 접근이 필요하여 CI 파이프라인이 복잡해집니다. SQLx는 sqlx prepare 명령으로 오프라인 쿼리 메타데이터를 생성할 수 있으며, 검증 결과를 버전 관리에 커밋되는 .sqlx 디렉터리에 캐시합니다.

Q: Axum 대신 Actix Web을 선택하는 것이 기술적으로 올바른 판단이 되는 경우는 언제입니까?

Actix Web이 올바른 선택이 되는 것은 지속적인 처리량이 주요 제약 조건인 경우입니다. 광고 서빙, 실시간 분석 데이터 수집, 고빈도 트레이딩 게이트웨이 등이 해당됩니다. 고정 스레드 런타임 모델이 워크 스틸링 오버헤드를 제거하여 고부하 시 10~15% 더 높은 req/s를 실현합니다. Axum이 올바른 것은 특히 HTTP와 gRPC를 모두 사용하는 마이크로서비스 아키텍처에서 Tokio 생태계와의 호환성이 근소한 처리량 차이보다 더 중요한 경우입니다.

결론

• Actix Web 4.13은 고정 스레드 런타임 모델을 통해 10~15% 높은 처리량을 실현하며, 지연 시간에 민감한 고처리량 서비스에 적합한 선택입니다
• Axum 0.8은 네이티브 async trait, /{id} 경로 구문, HTTP와 gRPC 전반에 걸친 Tower 미들웨어 완전 호환성으로 뛰어난 개발 경험을 제공합니다
• 두 프레임워크 모두 동일한 데이터베이스 레이어(컴파일 시점 검증이 포함된 SQLx)를 사용하므로 프레임워크 선택이 데이터 접근 패턴에 영향을 미치지 않습니다
• 극도의 처리량 요구 사항이 없는 2026년 신규 Rust 웹 프로젝트에서는 Axum의 Tokio, Tonic, Tower 생태계 연동이 장기적 유지보수 비용을 절감합니다
• 이 주제의 면접 질문은 런타임 모델, 미들웨어 아키텍처, 트레이드오프 추론 능력을 평가하는 것이지 프레임워크 선호도가 아닙니다
• Rust 면접 준비에는 두 프레임워크의 아키텍처적 결정에 대한 이해가 필요하며, API 구문만으로는 충분하지 않습니다