Nginx는 대표적인 웹 서버(Web Server)로 서버 배포 시 앞단에 두어 로드밸런싱, 리버스 프록시, 정적 리소스 서빙 등 다양한 역할을 수행한다.
그러다 문득 “Spring Boot에는 내장으로 Tomcat이 있는데 배포 환경에서 굳이 앞단에 Nginx를 둬야할 필요가 있을까?” 하는 생각이 들었다.
이번 글에서는 Tomcat이 있음에도 불구하고 앞단에 Nginx를 두고 사용하는 이유에 대해 알아보겠다.
WS vs WAS
먼저 WS(Web Server)와 WAS(Web Application Server)에 대해 알아보겠다.
WS란
WS(Web Server)는 클라이언트의 요청을 받아 정적 리소스(HTML, CSS, JS, 이미지 등)를 그대로 전달하는 서버이다.
초기의 웹은 단순히 사용자가 요청한 파일(정적 리소스)을 그대로 반환하기만 하면 됐기 때문에 WS만으로도 충분했다.
하지만 시간이 지나면서 웹은 점점 동적이고 상호작용적인 콘텐츠를 요구하게 되었다. 단순한 정적 파일만으로는 로그인, 게시글 작성, 데이터 조회 같은 복잡한 기능을 구현하기 어려워졌다.
이러한 한계를 해결하기 위해 등장한 것이 바로 WAS이다.
WAS란
WAS(Web Application Server)는 클라이언트의 요청을 받아 비즈니스 로직을 수행하고 그 결과를 동적으로 생성하여 응답하는 서버이다.
예를 들어 사용자가 로그인 버튼을 눌렀을 때 서버는 단순히 HTML을 반환하는 대신 DB에서 사용자 정보를 조회하고 인증을 처리한 뒤 결과를 만들어 응답한다.
이처럼 WAS는 서버 내부에서 프로그램이 실행되는 환경을 제공한다.
WAS는 단순한 정적 파일 전달을 넘어 데이터베이스 연동, 세션 관리, API 처리, 로직 실행 등 웹 애플리케이션의 핵심 기능을 담당한다.
차이점
| 구분 | WS (Web Server) | WAS (Web Application Server) |
|---|---|---|
| 주요 역할 | 정적 리소스(HTML, CSS, JS, 이미지 등)를 그대로 전달 | 비즈니스 로직을 실행해 동적 결과 생성 |
| 처리 대상 | 정적인 요청 (요청한 파일 그대로 응답) | 동적인 요청 (DB 조회, 연산, 세션 관리 등) |
| 동작 방식 | 요청 → 파일 반환 | 요청 → 애플리케이션 실행 → 결과 생성 |
| 예시 | Nginx, Apache HTTP Server, Caddy, LiteSpeed | Tomcat, Jetty, Undertow, JBoss, WebLogic |
| 리소스 처리 속도 | 빠름 (단순 파일 I/O) | 상대적으로 느림 (로직 실행 필요) |
| 위치 관계 | 클라이언트 요청을 처음 받는 “앞단” | WS 뒤에서 비즈니스 로직을 담당하는 “뒷단” |
| 역할 비유 | 우편 배달원 – 요청한 걸 그대로 전달 | 요리사 – 재료(DB, 로직)로 새 결과를 만듦 |
그렇다면 WAS가 WS의 역할을 완전히 대체할 수 있을까?
이론적으로는 가능하지만 정적 리소스 처리 속도와 효율성의 차이 때문에 WAS가 WS의 역할을 완전히 대체하지는 않는다.
Nginx 역할
WS와 WAS에 대해 알아보았으니 이제 Nginx가 배포 환경에서 어떤 역할을 하는지 알아보겠다.
리버스 프록시
프록시는 클라이언트가 자신을 통해 다른 네트워크 서비스(서버)에 간접적으로 접속할 수 있도록 중간에서 대리 역할을 하는 컴퓨터 시스템 또는 응용 프로그램을 말한다.
- 리버스 프록시: 서버 쪽에 위치해 외부에서 오는 요청을 대신 받아 내부 서버로 전달한다. (서버를 숨김)
- 포워드 프록시: 클라이언트 쪽에 위치해 클라이언트를 대신해 서버에 요청을 전달한다. (클라이언트를 숨김)
Nginx는 처음에 이야기했던 것처럼 Tomcat의 앞단에 둔다. 이를 통해 Tomcat은 아래의 이점을 누릴 수 있다.
- 보안성 향상 (WAS의 실제 IP와 포트를 감춤)
- 안정성 강화 (요청 폭주 시 Nginx가 트래픽을 제어)
- 성능 개선 (정적 리소스는 Nginx가 캐싱하여 빠르게 응답)
정적 리소스 캐싱 / 서빙 최적화
Nginx는 정적 리소스(HTML, CSS, JS, 이미지 등)를 빠르게 전달하도록 최적화되어 있다.
비동기 이벤트 기반 구조를 사용해 요청이 많아도 효율적으로 처리할 수 있으며 자주 요청되는 파일은 메모리나 디스크에 캐싱해 재요청 시 즉시 응답할 수 있다.
이를 통해 다음과 같은 장점을 얻을 수 있다.
- 응답 속도 향상: 캐시된 파일은 WAS를 거치지 않고 바로 응답
- 부하 분산: 정적 파일 처리를 Nginx가 담당해 WAS의 부담 감소
- 리소스 효율: Tomcat은 동적 요청 처리에만 집중 가능
로드 밸런싱
Nginx는 여러 개의 WAS 인스턴스로 트래픽을 분산시킬 수 있는 로드 밸런서로도 사용된다.
클라이언트의 요청을 하나의 서버가 아닌 여러 서버로 균등하게 분배하여 처리 효율을 높이는 구조다.
이를 통해 다음과 같은 장점을 얻을 수 있다.
- 부하 분산: 트래픽이 몰려도 요청이 여러 서버에 고르게 분산되어 안정적이다.
- 장애 대응: 특정 서버가 다운되어도 나머지 인스턴스가 요청을 처리할 수 있다.
- 확장성 확보: 서버를 수평 확장(Scale-out)하여 서비스 처리량을 유연하게 늘릴 수 있다.
nginx.conf를 아래와 같이 작성할 수 있다.
upstream backend {
server 127.0.0.1:8080;
server 127.0.0.1:8081;
server 127.0.0.1:8082;
}
server {
listen 80;
server_name example.com;
location / {
proxy_pass http://backend;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
}
}Nginx는 기본적으로 Round Robin 방식으로 요청을 각 서버(8080, 8081, 8082)에 순차적으로 전달한다. Nginx를 이용한 더 자세한 로드밸런싱 방식은 아래 링크를 참고해보면 된다.
HTTPS(SSL/TLS)
웹 서비스를 운영할 때 클라이언트와 서버 간의 통신을 암호화하기 위해 HTTPS(SSL/TLS) 설정은 필수적이다.
Nginx는 SSL 인증서를 설치해 암호화 통신의 종단을 담당하며 내부의 Tomcat과는 일반적인 HTTP 로 통신하도록 구성하는 것이 일반적이다.
이렇게 구성하면 Tomcat이 직접 SSL을 처리하지 않아도 되기 때문에 부하가 줄고 인증서 관리도 단일화된다.
이를 통해 다음과 같은 장점을 얻을 수 있다.
- 보안성 강화: 클라이언트와의 통신 구간이 암호화되어 데이터 탈취 방지
- 서버 부하 감소: SSL 처리 부담을 Nginx가 담당해 Tomcat의 리소스 절약
- 인증서 관리 용이: 여러 서버를 운영하더라도 Nginx 한 곳에서 SSL 인증서 관리 가능
마무리하며
단순히 “Nginx가 왜 Tomcat 앞에 필요한가”로 시작하여 조사하며 글을 썼는데 생각보다 얻은 점이 많았다. 백엔드에 대한 이해도 한층 더 높아졌고 이를 직접 적용해보며 내 것으로 만들어 봐야겠다.
