콘텐츠로 이동

axum

Rust로 웹 서버를 만들 때 가장 흔히 쓰는 질문은 "어떤 프레임워크로 시작할까"예요. axum은 Rust의 async 생태계(tokio) 위에 세워진 비동기 웹 프레임워크로, 컴파일 타임에 타입을 엄격히 검증하면서 타이핑(type) 부담이 없는 처리에서 유리해요. 우리 팀은 다룰 줄 알지만 아직 제품에는 안 쓰는 상태라, 로드맵에 올려두고 성능이 중요한 지점을 염두에 두고 있어요. 상태 배지는 역량으로 표시합니다.

핵심 개념

tokio 위의 async 웹 프레임워크

axum은 Rust의 비동기 런타임인 tokio 위에서 동작해요. #[tokio::main] 매크로와 함께 쓰며, I/O가 많은 작업을 소수의 스레드로 효율적으로 처리합니다. 비동기 핸들러가 자연스럽게 이벤트 루프를 공유해, 높은 동시성에서도 메모리 사용이 작아요.

타입 안전한 라우팅과 핸들러

axum의 라우팅·핸들러는 타입 안전이 핵심이에요. 핸들러의 시그니처(파라미터, 반환형)를 컴파일러가 검증해서, 잘못된 조합이면 실행 전에 오류로 잡아줍니다. Extractor로 요청의 경로·쿼리·바디를 추출하고, IntoResponse로 응답을 만들죠.

레이어(Layer)로 미들웨어를 조립

인증, 로깅, CORS 같은 공통 관심사는 레이어로 조립해요. tower의 미들웨어 스택으로 여러 레이어를 겹쳐 요청 처리 파이프라인을 만듭니다. 기능을 분리해 재사용하기 쉽습니다.

Tower 생태계와의 통합

axum은 tower 계층 위에 있어서, retry·timeout·부하 분산 같은 정교한 미들웨어를 그대로 재사용할 수 있어요. 이런 부분이 로드맵에서 성능·장애 대응 지점에 어울리는 이유죠.

사용 사례 / 실제 적용

axum은 아직 제품에는 안 쓰여요. 다만 팀이 다룰 줄 알고, 언제 쓸 수 있을지 지점을 정리해 두고 있죠.

  • 성능 민감 지점 — 타이핑 없는 async 처리와 낮은 메모리 사용이 유리해서, 요청 처리량·지연 시간이 결정적인 서비스에서 후보가 돼요.
  • 고동시성 프록시·엣지 — Tower 레이어로 rate limit·타임아웃을 얹기 좋아서, 게이트웨이 주변의 고속 처리 계층으로 검토할 수 있어요.
  • Rust 내부 도구 — 팀이 이미 Rust를 다루는 만큼, 운영 도구나 성능에 민감한 내부 서비스를 axum으로 만드는 방안을 열어둡니다.

지금은 역량 단계라 "왜 아직 제품에 안 쓰나"는 질문에 답하면, 제품이 이미 NestJS·Spring Boot로 운영되고 있어 교체보다는 새로 성능이 중요한 지점이 생길 때 도입을 검토하는 상태예요.

더 알아보기