왜 Tomcat은 WAS가 아닐까? 그런데 왜 실무에서는 WAS처럼 쓰일까?

개발자라면 한 번쯤 들어본 말, “Tomcat은 WAS가 아니다.”

하지만 또 다른 자리에서는 “우리는 Tomcat으로 WAS를 운영한다.” 라는 이야기를 듣습니다.

 

도대체 Tomcat은 WAS일까요, 아닐까요?
그리고 왜 실무에서는 Tomcat이 사실상 WAS처럼 쓰일 수 있을까요?

1. WAS의 전통적 정의

WAS(Web Application Server)는 원래 Java EE(지금의 Jakarta EE) 표준을 구현한 서버 소프트웨어를 의미했습니다.즉, 단순히 웹 요청을 처리하는 것 이상으로, 다음과 같은 기능을 제공해야 했죠.

• 트랜잭션 관리 (JTA)
• ORM (JPA, 과거엔 EJB 엔티티 빈)
• 메시징 (JMS)
• 보안/세션 관리
• DI, 의존성 주입 (CDI)

IBM WebSphere, Oracle WebLogic, JBoss 같은 “전통적인 WAS”가 바로 이 역할을 수행했습니다.

2. Tomcat의 본질: Servlet/JSP 컨테이너

Tomcat은 오픈소스, 가볍고 빠른 Servlet/JSP 컨테이너입니다.

 

즉, Jakarta EE 풀 스펙을 모두 지원하지 않고, HTTP 요청 → Servlet 실행 → 응답 반환이라는 단순한 동작에 집중합니다.

따라서 전통적인 기준으로 보면, Tomcat은 “불완전한 WAS”입니다.

3. Spring이 가져온 변화

하지만 판도를 바꾼 건 Spring Framework입니다. Spring은 Tomcat이 가지지 못한 WAS 기능들을 자체적으로 제공합니다.

• @Transactional → 트랜잭션 관리 (JTA 대체)
• Spring Data JPA → JPA API 지원
• Spring Security → 인증/인가 (Jakarta EE Security 대체)
• DI/IoC 컨테이너 → 의존성 관리 (CDI 대체)
• 메시징 통합 → JMS, Kafka 등 다양한 브로커 연동

즉, Tomcat + Spring 조합 = 전통적 WAS가 제공하던 기능을 거의 모두 충족하게 된 것입니다.

4. 그래서 실무에서는?

• 과거: WebSphere, WebLogic 같은 대형 WAS에 의존
• 현재: Tomcat + Spring 조합으로 충분 → 비용 저렴, 가볍고 유연
• 결과: Spring Boot가 Tomcat을 내장 서버로 기본 제공 → 사실상 표준처럼 자리잡음

이제 “WAS”라는 단어는 더 이상 Jakarta EE 풀 스펙 서버만을 가리키지 않습니다.
실무에서는 단순히 “웹 서버(Nginx)와 구분되는, 동적 로직을 수행하는 서버” 정도의 의미로 확장되었죠.

5. 마치며

정리하면, Tomcat이 WAS처럼 쓰일 수 있는 건 Spring이 그 공백을 메워주기 때문입니다.

• Tomcat = Servlet 컨테이너 (기본기 담당)
• Spring = 엔터프라이즈 기능 세트 (부족한 기능 채워줌)

지금도 이 조합이 수많은 서비스의 표준 구조가 되고 있습니다.