왜 톰캣인가?

톰캣이 뭔지 보기전에..

서블릿이란?

Java를 기반으로 웹 애플리케이션을 개발할 때 사용되는 서버측 컴포넌트
HTTP 요청을 처리하고 그에 대한 응답을 생성

• 역할: 클라이언트의 요청을 받아 비즈니스 로직을 처리
  그 결과를 HTML, JSON 등의 형식의 응답으로 반환
• 주요 기능: request 파라미터 처리, 세션 관리, 응답 데이터 생성 등

응? 컨트롤러 아니야?

Controller

보통 MVC 패턴에서 사용되는 컴포넌트

• 클라이언트의 요청을 받아 처리한 후, Model을 통해 데이터를 처리, 뷰(View)를 통해 결과를 사용자에게 전달
• Spring 프레임워크 : @Controller 어노테이션을 사용

Servlet VS Controller

• 서블릿:
  • 더 낮은 레벨에서 동작
  • 요청과 응답을 수동으로 처리
  • 개발자가 모든 작업을 직접 처리해야 하므로, 코드가 복잡하다.
  • 기능 확장이나 재사용이 제한적
• 컨트롤러:
  • 서블릿을 기반으로 동작하지만, 더 높은 레벨의 추상화를 제공
  • 프레임워크의 도움을 받아 개발이 더 편리
  • 프레임워크가 많은 작업을 자동으로 처리

서블릿이 전달 해주면 컨트롤러가 받는거임

DispatcherServlet

디스패처 서블릿은 스프링 MVC에서 중앙 컨트롤러 역할을 수행하는 서블릿

• 모든 HTTP 요청이 먼저 디스패처 서블릿으로 전달
• 디스패처 서블릿은 이 요청을 적절한 컨트롤러로 전달
• 응답을 처리하여 클라이언트에게 반환
• 해당 어플리케이션으로 들어오는 모든 요청을 핸들링하고, 공통 작업을 처리 - 개발자는 컨트롤러를 구현해두기만 하면 디스패처 서블릿이 알아서 적합한 컨트롤러로 위임을 해줌

서블릿 컨테이너

서블릿을 관리하고, 생명 주기를 관리하며, 요청을 서블릿으로 전달하고 그 결과를 클라이언트에게 반환하는 역할을 수행하는 서버 환경.

• 서블릿 객체의 생성, 초기화, 요청 처리, 소멸 등을 관리
• HTTP 요청과 응답을 처리하는 데 필요한 여러 가지 기능을 제공

톰캣 (Tomcat)

Apache 재단에서 제공하는 오픈 소스 서블릿 컨테이너이자 WAS
자바 서블릿과 JSP(JavaServer Pages)를 실행할 수 있는 환경을 제공

Spring에는 이녀석이 내장되어 있음

• 서블릿 컨테이너와 웹 서버의 기능을 모두 제공
• JSP 페이지를 웹서버에 요청하면 이 페이지를 해석하고 서블릿으로 바꾸어 실행
• Web Server에서 요청한 동적 페이지를 읽어 프로그램을 실행
• 그 결과를 다시 HTML로 재구성하여 Web Server에게 전달
• 정적 파일 제공과 동적 웹 애플리케이션 실행을 모두 지원
• 경량화된 웹 애플리케이션 서버
• 다양한 운영체제에서 실행 가능

HTTP 요청이 들어와?

• WAS(톰캣)가 Request, Response 객체를 만들어서 서블릿 호출
• 개발자는 Request객체에서 요청 정보를 꺼내서 사용
• 개발자는 Response객체에 응답 정보를 입력
• WAS(톰캣)가 Response 객체에 담아 있는 내용으로 HTTP 응답 정보 생성

서블릿 컨테이너는 서블릿 객체를 싱글톤으로 관리한다.

• Client 가 요청할 때 마다 객체를 생성하는 것은 비효율 적이다.
• 최초 로딩 시점에 만들어서 재활용한다.
• 여러 Client가 동시에 같은 서블릿 객체에 접근할 수 있다.
• 공유 변수 사용에 주의 해야 한다.

그래서 왜 톰캣인가?

1. Servlet/JSP 표준을 지원하는 Java 웹 서버

Tomcat은 Java Servlet과 JSP의 레퍼런스 구현체로, Java 기반 웹 애플리케이션을 실행하기 위한 기본 환경을 제공한다.

Java로 작성된 웹 애플리케이션은 HTTP 요청을 처리할 수 있는 컨테이너가 필요하다.
톰캣은 이 역할을 수행하며, Spring MVC나 JSP 기반의 웹 서비스를 실행할 수 있게 해준다.

Spring Boot + Thymeleaf 기반의 웹 애플리케이션을 만들고, 사용자가 /login으로 접속하면 LoginController의 메서드가 호출되는 구조. 이때 HTTP 요청을 Servlet으로 처리하는 역할을 톰캣이 담당한다.

2. 가볍고 빠르고 간편하고

Tomcat은 불필요한 Java EE 스펙(EJB, JMS 등)을 제거한 경량 서버로, 빠르게 개발 및 배포가 가능하며 학습 곡선이 낮다.

복잡한 설정 없이 빠르게 애플리케이션을 구동할 수 있다. 특히 Spring Boot는 내장 톰캣을 기본으로 제공하므로 따로 설치할 필요도 없다.

개발자가 ./gradlew bootRun 또는 java -jar app.jar 명령어만으로 Spring Boot 앱을 실행 → 내부적으로 Tomcat이 내장되어 자동 실행된다.

3. 안정성과 검증된 커뮤니티

오랜 기간 다양한 서비스에서 사용되며, 안정성, 유지보수성, 보안성 측면에서 높은 신뢰를 얻고 있다.

새로운 웹 서버보다 장애 사례나 설정 정보가 많고, 문제가 생겼을 때 검색만으로 대부분의 해결이 가능하다.

10년 이상 운영된 레거시 시스템에서 여전히 톰캣을 사용하는 사례가 많다.
사소한 설정 오류에도 Stack Overflow, 공식 문서, 블로그 등에서 바로 해결 방법을 찾을 수 있다.

일간 수십만 요청을 받는 커머스 웹사이트에서 톰캣 기반으로 서비스를 운영.
성능 병목이 있을 경우, 애플리케이션 최적화 또는 Nginx 캐싱 추가 등으로 대응.

4. Spring과의 강력한 호환성

Spring Boot, Spring MVC 등의 프레임워크는 Tomcat과의 호환성을 전제로 설계된 부분이 많다.

Spring Boot에서는 기본적으로 내장 Tomcat을 제공하므로, 특별한 설정 없이 실행 파일만으로 서버를 띄울 수 있다.

CI/CD 파이프라인에서 .jar 파일 하나만 배포 → 별도 WAS 설치 없이 애플리케이션 구동
→ java -jar app.jar 실행 시, 자동으로 8080 포트에서 Tomcat이 뜬다.

5. 확장 가능한 아키텍처와 Nginx와의 조합

Tomcat은 정적 자원 처리에 약하지만, Nginx나 Apache와의 연동을 통해 확장성과 성능을 보완할 수 있다.

톰캣은 동적 요청(JSP/Servlet 등)에 집중하고, 정적 요청은 프론트 서버(Nginx 등)에서 처리하는 분리된 구조로 고성능 시스템을 구성할 수 있다.

Nginx가 /static, /images, /css 요청은 직접 처리하고, /api 요청만 Tomcat으로 프록시를 전송하도록 한다.

정적 리소스 빠른 응답 + 동적 로직은 톰캣 처리 → 서버 부담 분산.

다른거 없나? Netty

Netty는 비동기 이벤트 기반의 네트워크 어플리케이션 프레임워크.
TCP/UDP 기반의 네트워크 서버나 클라이언트를 고성능으로 구현할 수 있도록 도와주는 라이브러리

1. 비동기, 논블로킹 I/O 기반

Java NIO 기반으로, 한정된 스레드로 수천 개의 연결을 처리할 수 있다.
이벤트 기반으로 작동하여 IO 작업 대기 시간 낭비를 최소화한다.

실시간 채팅 서버, 대규모 IoT 게이트웨이, 게임 서버 등에서 수천 명의 사용자가 동시에 접속해도 효율적으로 처리 가능

2. 고성능, 저지연 네트워크 처리

TCP/UDP 모두 지원하며 커넥션 풀, 파이프라인 기반 처리로 효율적.
HTTP, WebSocket, gRPC 등 다양한 프로토콜을 직접 처리할 수 있음.

Netty 기반 gRPC 서버는 낮은 지연(latency)을 요구하는 마이크로서비스 간 통신에 적합.

3. 유연한 프로토콜 설계

Netty는 HTTP 서버일 수도 있고, WebSocket 서버일 수도 있으며, TCP 기반 게임 서버일 수도 있음. 모든 것은 ChannelHandler 기반으로 구성.

커스텀 바이너리 프로토콜(예: 게임의 패킷)을 직접 정의하여 처리 가능.

4. Spring과의 통합은 제한적

Spring Boot 기본 WAS는 Tomcat이며, Netty는 Reactor Netty 등을 통해 WebFlux와 함께 비동기 처리 시 사용된다.

spring-boot-starter-webflux를 사용하면 기본 내장 WAS는 Netty로 바뀜. 하지만 기존 MVC(Model-View-Controller) 구조와는 맞지 않음.

5. 초기 설정과 구현 난이도 높음

직접 ChannelPipeline, EventLoop, ByteBuf 등을 설계해야 하므로 진입 장벽이 있음.
반면에 자유도와 성능은 매우 높음.

HTTP가 아닌 프로토콜을 설계할 경우, Netty는 거의 유일한 선택지. 단, 복잡한 에러 핸들링과 쓰레드 관리도 직접 해야 함.

Tomcat vs Netty 비교

WAS	Tomcat	Netty
목적	Java Servlet 기반 웹 앱 실행 (WAS)	고성능 네트워크 서버 프레임워크
처리 방식	동기/멀티쓰레드 기반	비동기, 이벤트 기반
개발 편의성	Spring MVC, JSP 등과 바로 연동	직접 핸들러 구성 필요
성능	일반적 웹 서비스에 충분	초고성능/초경량 서비스에 최적
확장성	프록시 + 톰캣 구조로 확장	자체적으로 수만 연결 처리 가능
Spring 연동	Spring Boot 기본 WAS	WebFlux로만 사용
예시	웹사이트, 쇼핑몰, 사내 시스템	게임 서버, 채팅, IoT, WebSocket, gRPC 등