Undertow란? Tomcat, Netty와 비교해 언제 쓰면 좋을까

최근에 Undertow를 다시 다뤄볼 일이 생겼는데, 예전에도 이걸 사용한 적이 있었습니다.

그래서 왜 선택했는지 떠올려보면서 정리해보려고 합니다.

결론부터 말하면, 빠르고 가볍고 유연해서였고, 당시엔 내부 API 서버 용도로 사용했었습니다.

 

▶️ Undertow란? 

Undertow라는 것이 익숙하지 않을 분들이 많을 것 같습니다. (저도 처음에 그랬습니다)

Undertow는 Java 기반의 경량 웹 서버로, 논블로킹 비동기 IO를 지원하고, 서블릿 4.0 스펙까지 지원하는 웹 서버입니다.

(https://undertow.io/)

기본적으로 Netty 위에서 동작하며, Servlet Container로도 사용할 수 있고, JAX-RS, HTTP2, WebSocket 등도 잘 지원하는 꽤 다재다능한 웹 서버입니다.

Spring Boot에서는 2.x까지 Undertow를 embedded web server로 선택할 수 있었습니다.

 

하지만 안타깝게도 3.x 버전에서는 제거되었지만, 여전히 사용은 할 수 있는 것 같습니다.

 

▶️ 왜 Undertow를 쓸까?

Tomcat을 비롯한 많은 웹 서버가 있지만, Undertow를 굳이 선택하는 이유는 명확합니다.

• ✅ 기동 속도가 빠르다
  → 톰캣보다 훨씬 빠르게 올라온다. 작은 API 서버에선 꽤 체감된다.
• ✅ 메모리 사용량이 적다
  → 경량 서버로 설계되어서, 도커 컨테이너에서도 부담이 덜하다.
• ✅ 논블로킹 구조
  → 내부적으로 Netty를 사용하여 비동기/논블로킹 IO 기반
• ✅ 유연하고 모듈화된 구조
  → 필요 기능만 붙여 쓰는 식의 구성 가능 (Tomcat은 기본 패키지가 무겁다)

실제로 저도 예전에 내부 시스템용 API 서버를 만들면서 사용했었는데, 기동 속도나 리소스 소비가 중요한 상황이었고, UI도 필요 없는 API 서버여서 Undertow를 선택했었습니다.

 

▶️ Tomcat, Netty와의 비교

 

 

▶️ 언제 Undertow를 선택할까?

Undertow는 아무 때나 쓰는 도구는 아니고, 다음과 같은 상황에서 꽤 유리하다고 생각됩니다.

• 🌀 서버 기동 속도가 중요한 경우
  → CI/CD 파이프라인에서 서버를 자주 재기동하는 환경
• 🧠 메모리나 리소스가 적은 환경
  → 도커로 묶은 작은 서비스들, 혹은 Lambda 같은 제약 환경
• 🚀 UI 없이 API 응답만 빠르게 처리하는 서버
  → HTML 렌더링 필요 없는 REST API 백엔드
• 🌐 IO 중심 처리나 프록시 서버 구성 시
  → 대용량 요청 처리에도 유리한 논블로킹 구조

 

설정 방법도 크게 복잡하지 않고 간단한데요.

// build.gradle

dependencies {
    implementation 'org.springframework.boot:spring-boot-starter-web'
    implementation 'org.springframework.boot:spring-boot-starter-undertow'
}


configurations {
    all{
	    // 아래는 명시적으로 제거 (톰캣 기본 내장 제거)
        exclude module: 'spring-boot-starter-tomcat'
    }
}

 

이렇게 설정하면, 이렇게 설정하면 embedded undertow를 자동으로 사용하게 됩니다.

 

정리하자면,

Undertow는 톰캣과 비슷한 역할을 하면서도, 훨씬 빠르고 가벼운 웹 서버입니다.

특히 API 서버나 경량 컨테이너 환경에서 기동 속도와 리소스를 아낄 수 있습니다.

다만 운영 편의성이나 공식 지원 측면에선 톰캣이 더 낫기 때문에 (특히 spring boot 3.x 버전 지원 안함 등등...)
상황에 따라 전략적으로 선택하는 것이 좋을 것 같습니다.

 

그럼 간단한 정리 글을 마치겠습니다.

감사합니다.