Web Server, Was, Reverse Proxy에 대해 알아보자.
웹 서버(Web Server)
브라우저와 같은 Client로부터 HTTP 프로토콜 요청을 받으면 HTML 문서 등의 정적 웹 페이지를 응답해주는 소프트웨어를 말합니다.
동적 컨텐츠를 요청 받으면 WAS에게 요청을 넘겨주고 WAS에서 처리한 결과를 Client에 전달하는 역할도 합니다.
대표적으로 Apache, NginX, WebtoB 등이 있습니다.
웹 서버가 하는 일
정적 파일 제공
HTML, CSS, JS, 이미지 같은 정적 파일 제공
기본적인 HTTP 처리
요청 라우팅, 헤더 관리, 캐싱 정책, 압축(gzip/brotli), HTTP/2, TLS 등
SSL/TLS 처리(HTTPS)
HTTPS 인증서 관리
리버스 프록시 역할
단순 파일 서버가 아니라 리버스 프록시로 사용
왜 웹 서버가 필요한가?
브라우저와 직접 통신하는 역할은 가볍고 빠른 웹 서버가 적합하기 때문입니다.
정적 파일 처리 속도 ↑
요청 필터링/보안/캐싱 최적화 가능
Application Server를 직접 노출시키지 않아 더 안전
WAS (Web Application Server)
웹 서버가 파일을 제공하는 서버라면, WAS는 동적으로 데이터를 생성하는 ‘애플리케이션 로직을 실행하는 서버’입니다.
HTTP 프로토콜을 기반으로 수행되는 미들웨어로 주로 DB 서버와 같이 수행합니다.
대표적으로 Tomcat, JBoss, WebSphere 등이 있습니다.
WAS가 하는 일
DB와 통신
SQL 실행, ORM, 트랜잭션 관리
백엔드 로직 처리
인증/인가, 비즈니스 규칙, API 응답 작성 등
동적 페이지 생성
JSON 또는 HTML 템플릿 렌더링
Reverse Proxy
리버스 프록시(Reverse Proxy)는 클라이언트가 보낸 요청을 대신 받아 내부 서버(WAS/웹 서버)로 전달하고, 내부 서버가 보낸 응답을 클라이언트에게 다시 전달하는 중개 서버입니다.
즉, 외부 사용자는 실제 백엔드 서버의 주소나 인프라 구조를 알지 못하고, 오직 리버스 프록시(예: nginx)만 바라보게 됩니다.
리버스 프록시가 필요한 이유
SSL/TLS 종료
HTTPS 암호화/복호화를 리버스 프록시가 대신 수행 HTTPS → HTTP로 변환하여 WAS의 부담을 줄임
보안
WAS를 외부에 직접 노출시키지 않음
로드밸런싱
여러 대의 백엔드 서버로 트래픽 분산
1 2 3
Client → Nginx → WAS #1 → WAS #2 → WAS #3
캐싱 & 정적 파일 처리
반복되는 API 응답을 캐싱하여 부하 감소
요청 필터링
CORS, 헤더 조작, 특정 User-Agent 차단 등
‘웹 서버 + WAS’ 조합을 쓸까?
성능 최적화
nginx가 I/O 중심 작업을 압도적으로 잘함
보안
백엔드 서비스를 직접 노출하지 않음
확장성
WAS 여러 개 띄워 로드밸런싱
구조적 분리
정적(nginx) + 동적(WAS) 역할을 명확히 분리
배포 유연성
웹 서버는 변경 없이 WAS만 롤링 배포 가능
결론
Web Server를 WAS 앞에 두고 처리해 WAS를 Web Server가 필요에 따라 요청할 수 있는 플러그인 형태로 설정하면 효율적인 분산 처리가 가능할 것입니다.
예시 구성: React + Express + Nginx