Network
웹 서버(WS)와 웹 애플리케이션 서버(WAS)의 차이에 대해서 설명해주세요
Nginx와 Tomcat은 왜 함께 쓰이는가? 정적 요청과 동적 요청이 처리되는 방식을 직접 체험하며 이해합니다.
2026년 3월 10일 · 약 10분 읽기
Q. "웹 서버(WS)와 웹 애플리케이션 서버(WAS)의 차이를 설명하고, 프로덕션에서 왜 두 개를 함께 사용하는지 말씀해주세요."
예상 꼬리질문
답변 가이드
"WS(Web Server)는 Nginx, Apache처럼 정적 파일(HTML, CSS, 이미지)을 그대로 반환하며 비즈니스 로직을 실행하지 않습니다. WAS(Web Application Server)는 Tomcat, Node.js처럼 코드를 실행하고 DB를 조회해 동적 콘텐츠를 생성합니다."
"프로덕션에서는 Nginx(WS) + Tomcat/Node.js(WAS) 조합이 표준입니다. WS가 정적 파일과 보안을 담당하고, WAS가 비즈니스 로직을 처리합니다."
"WS는 정적 파일 요청을 WAS 없이 처리해 서버 부하를 크게 줄이고, WAS를 직접 인터넷에 노출하지 않아 보안도 향상됩니다. 또한 Nginx 뒤에 WAS 인스턴스를 여러 개 두어 로드 밸런싱도 가능합니다."
백엔드를 처음 배울 때 "Nginx 뒤에 Tomcat을 붙여라", "WAS 앞에 WS를 두어라"는 말을 자주 듣습니다. 그런데 왜 두 개를 따로 두어야 할까요? 하나로 합치면 안 될까요?
WS와 WAS는 각자 잘하는 일이 다릅니다. WS는 파일을 빠르게 전달하는 데 특화되어 있고, WAS는 복잡한 비즈니스 로직을 처리하는 데 강합니다. 이 구조를 이해하면 왜 Netflix, Facebook 같은 대형 서비스들이 항상 이 패턴을 따르는지 알 수 있습니다.
1. WS와 WAS, 무엇이 다른가?
꼬리질문: "WS와 WAS의 근본적인 차이가 무엇인가요?"
웹 서버(WS)와 웹 애플리케이션 서버(WAS)는 모두 HTTP 요청을 처리하지만, 처리하는 콘텐츠의 종류가 근본적으로 다릅니다.
WS는 클라이언트가 /index.html이나 /logo.png를 요청하면 파일 시스템에서 그 파일을 찾아 그대로 반환합니다. 코드를 실행하거나 DB를 조회하는 일은 전혀 없습니다.
WAS는 클라이언트가 /api/users/1을 요청하면 애플리케이션 코드를 실행하고, DB를 조회하며, 결과를 가공해 동적으로 응답을 생성합니다.
아래 탭을 전환하며 각 서버의 특성을 비교해 보세요.
정적 파일을 그대로 반환하는 서버
파일 시스템에서 요청된 리소스(HTML, CSS, JS, 이미지)를 찾아 그대로 반환합니다. 매번 동일한 파일을 반환하므로 별도의 연산이 필요 없습니다.
비즈니스 로직
없음
DB 연동
없음
대표 소프트웨어
주요 기능
한 가지 오해를 짚고 넘어가겠습니다. WAS도 HTTP 요청을 받을 수 있기 때문에 이론상 WAS 하나로 정적 파일까지 서빙할 수 있습니다. 실제로 개발 환경에서는 Spring Boot나 Node.js 서버 하나로 모든 요청을 처리합니다. 그런데 왜 프로덕션에서는 굳이 WS를 앞에 두는 걸까요? 다음 섹션에서 확인해 보겠습니다.
2. 요청이 처리되는 방식
꼬리질문: "정적 요청과 동적 요청은 처리 경로가 어떻게 다른가요?"
정적 요청(GET /logo.png)과 동적 요청(GET /api/users/1)은 처리 경로가 완전히 다릅니다.
아래 시뮬레이터에서 두 요청이 어떤 경로로 흘러가는지 직접 확인해 보세요.
정적 요청은 Nginx에서 파일 시스템으로 직행해 WAS를 거치지 않습니다. 이것이 핵심입니다.
웹 서비스에서 전체 요청의 상당 부분은 CSS, JS, 이미지 같은 정적 파일 요청입니다. WS가 이를 직접 처리하면 WAS는 진짜 비즈니스 로직에만 집중할 수 있습니다. C로 작성된 이벤트 기반 서버인 Nginx는 정적 파일 서빙에서 Java나 Node.js 기반 WAS보다 월등히 빠릅니다.
3. 프로덕션 표준 아키텍처
꼬리질문: "프로덕션 환경에서 왜 WS와 WAS를 분리하나요?"
실제 서비스는 WS와 WAS를 분리하여 각자의 강점을 극대화합니다.
아래 다이어그램에서 각 컴포넌트를 클릭해 역할을 확인해 보세요.
각 컴포넌트를 클릭해 역할을 확인하세요
- •SSL/TLS 종료 — HTTPS 암복호화를 담당해 WAS CPU 절약
- •정적 파일 서빙 — /static/, /media/ 직접 처리
- •리버스 프록시 — /api/* 요청을 WAS로 전달
- •로드 밸런싱 — 여러 WAS 인스턴스에 트래픽 분산
- •Rate Limiting — 과도한 요청 차단
이 구조가 표준이 된 이유는 4가지입니다.
- - 성능: 정적 파일은 Nginx가 처리해 WAS 부하를 줄입니다.
- - 보안: WAS를 직접 인터넷에 노출하지 않습니다. Nginx가 방화벽 역할을 하며, WAS의 포트는 외부에서 접근할 수 없습니다.
- - 확장성: Nginx 하나 뒤에 WAS 인스턴스를 여러 개 두고 로드 밸런싱할 수 있습니다.
- - SSL 오프로딩: TLS 암복호화를 Nginx에서 처리해 WAS의 CPU를 절약합니다.
4. 핵심 특성 비교
꼬리질문: "Nginx와 Tomcat을 예로 들어 각 역할을 설명해주세요"
6가지 기준으로 WS와 WAS의 특성을 한눈에 비교합니다.
항목에 마우스를 올려 자세한 설명을 확인하세요.
각 행에 마우스를 올려 설명을 확인하세요
면접 체크리스트
이 항목들을 자신 있게 설명할 수 있다면 WS/WAS 질문은 준비 완료입니다.
- - WS vs WAS 핵심 차이: WS는 파일을 전달, WAS는 로직을 실행
- - 정적 vs 동적 요청: 정적 요청은 WAS를 거치지 않고 Nginx에서 직접 처리
- - 분리 이유: 성능·보안·확장성·SSL 오프로딩 4가지
- - 표준 조합: Nginx(WS) + Tomcat/Node.js(WAS) — 각자의 강점 극대화
- - 보안 원칙: WAS를 직접 외부에 노출하지 않고 Nginx 뒤에 위치
참고 자료
- Nginx + Gunicorn으로 Flask 앱 배포하기 — Digital Ocean — WS+WAS 조합을 직접 구성해보는 단계별 튜토리얼
- Mozilla MDN: HTTP 개요 — WS/WAS가 처리하는 HTTP 프로토콜 전반을 한국어로 이해할 수 있는 자료
- Nginx 공식 문서: 리버스 프록시 설정 — proxy_pass, upstream 블록 등 리버스 프록시 관련 모든 지시어 레퍼런스
의견을 들려주세요
서비스 개선에 큰 도움이 됩니다. 익명으로 자유롭게 남겨주세요.