WAS 서버란?
WAS란?
WAS(Web Application Server)는 HTTP 프로토콜을 기반으로 사용자의 요청을 받아 서버에서 애플리케이션을 실행하고, 그 결과를 HTTP 응답으로 반환하는 미들웨어(Middleware)이다.
단순히 저장된 파일을 전달하는 것을 넘어, 요청에 따라 서버 내부 로직을 수행하고 데이터를 가공하여 동적 콘텐츠를 생성하며, 나아가 웹 애플리케이션이 안정적으로 실행될 수 있도록 실행 환경(Runtime Environment)을 제공하는 것이 핵심 역할이다.
note)
실무적으로 WAS는 Java의 Tomcat처럼 코드가 실행될 수 있는 환경을 제공하며, DB 접근, 트랜잭션 관리, 스레드 관리 등 백엔드의 복잡한 책임을 대신 처리해 주는 서버를 의미한다.
WAS 탄생 배경
초기 웹 서버는 미리 만들어진 HTML 파일을 클라이언트에 전달하는 역할만 수행했다. 하지만 웹 서비스가 발전하면서 다음과 같은 한계에 직면했다.
- 동적 데이터의 필요성
로그인 사용자마다 다른 화면 제공, 실시간 데이터 반영 - 비즈니스 로직 처리 요구
결제, 재고 관리, 권한 판단 같은 서버 측 연산 필요 - 자원 활용의 효율성 문제
요청마다 프로세스를 생성하는 방식은 비용이 과도했음
이러한 문제를 해결하기 위해 스레드 기반으로 요청을 처리하고, 애플리케이션 실행을 전담하는 서버인 WAS가 등장했다.
👉 이 구조 덕분에 서버는 다수의 요청을 효율적으로 처리하면서도 복잡한 비즈니스 로직을 안정적으로 실행할 수 있게 되었다.
WAS vs Web Server
| 구분 | Web Server | WAS |
|---|---|---|
| 주요 역할 | 정적 리소스 전달 | 애플리케이션 실행 및 동적 콘텐츠 생성 |
| 데이터 처리 | 파일 그대로 전달 | DB 조회 및 데이터 가공 |
| 책임 범위 | HTTP 처리 집중 | 로직 실행 + 상태 관리 |
| 대표 예시 | Nginx, Apache | Tomcat, Jetty, GlassFish |
Tip)
현대 아키텍처에서는 보안과 트래픽 분산을 위해 Web Server를 앞단에 두고, WAS를 수평 확장하는 구조가 일반적으로 사용된다.
WAS가 하는 일
- 프로그램 실행 환경 제공
Spring과 같은 프레임워크가 동작할 수 있는 서블릿 컨테이너 제공 - 스레드 관리 (Thread Management)
Thread Pool을 통해 동시 요청을 안정적으로 처리 - DB 커넥션 풀(DBCP) 관리
DB 연결 비용을 줄이고 성능을 최적화 - 트랜잭션 관리
작업 단위의 일관성 보장 - 보안 및 세션 관리
인증·인가, HttpSession 기반 사용자 상태 관리
👉 이 모든 기능은 개발자가 비즈니스 로직에만 집중할 수 있도록 돕기 위한 것이다.
요청 흐름
- Web Server 수신: 클라이언트 요청이 들어오면 Web Server가 정적/동적 요청인지 판단해.
- WAS 위임 (Tomcat): 동적 요청일 경우 WAS(Tomcat)로 넘겨. 이때 Tomcat은 요청을 처리할 스레드를 할당
- DispatcherServlet 동작: Spring의 총지배인인 DispatcherServlet이 요청을 받아 어떤 컨트롤러가 처리할지 결정해.
- 비즈니스 로직 실행 (Service): 실제 핵심 로직이 담긴 Service 레이어에서 연산이 수행
- DB 연동 (JPA/Repository): JPA를 통해 DB에서 데이터를 가져오거나 저장
- 응답 반환: 가공된 데이터를 다시 DispatcherServlet -> Tomcat -> Web Server를 거쳐 클라이언트에게 HTTP 응답으로 전달
이 과정에서 개발자는 비즈니스 로직에만 집중할 수 있고, 스레드 관리와 자원 관리는 WAS가 대신 책임진다.
WAS와 Thread Per Request Model
Thread Per Request Model이란?
Thread Per Request Model은 하나의 HTTP 요청을 하나의 스레드가 전담하여 처리하는 방식이다.
- 요청 1개 → 스레드 1개 할당
- 요청 처리 완료 → 스레드 반환
전통적인 WAS(Tomcat, Jetty)는 이 모델을 기본 동시성 처리 방식으로 사용한다.
WAS 내부 동작 흐름 (Tomcat 기준)
- 클라이언트 요청 수신
- Web Server가 동적 요청을 WAS로 전달
- Tomcat Connector가 Thread Pool에서 스레드 할당
- DispatcherServlet 실행
- Controller → Service → Repository 순으로 로직 수행
- 응답 생성 후 스레드 반환
이 과정에서 요청의 시작부터 끝까지 동일한 스레드가 사용된다.
Thread Per Request Model의 한계
- Blocking I/O 문제
DB나 외부 API 응답을 기다리는 동안 스레드는 대기 상태 - 동시성 확장의 한계
동시 요청 수 증가 = 스레드 증가 → 메모리 및 컨텍스트 스위칭 비용 증가
👉 트래픽이 급증하면 Thread Pool 고갈로 장애가 발생할 수 있다.
한계를 해결한 방법
기능 역할 Thread Pool 스레드 수 제한 및 재사용 Queue 초과 요청 대기 Timeout 비정상 요청 종료 DBCP DB 대기 시간 단축 트랜잭션 관리 스레드 단위 작업 일관성
참고 자료
