WAS와 웹서버의 차이 — 요청 흐름부터 분리 배치 이유까지

WAS란 무엇인가 — 동적 요청을 처리하는 애플리케이션 실행 계층

WAS는 요청마다 달라지는 동적 응답을 만들기 위해 애플리케이션 코드를 실행하는 서버입니다. 로그인 검증, 주문 처리, 재고 조회처럼 데이터베이스와 통신하며 비즈니스 로직을 수행하고, 그 결과를 HTML이나 JSON으로 만들어 돌려줍니다. IBM은 두 계층의 차이를 “웹서버는 HTTP 요청에 정적 콘텐츠로 응답하고, 애플리케이션 서버는 비즈니스 로직을 실행해 동적 콘텐츠를 생성한다”로 요약합니다(출처: IBM — Web Server vs. Application Server).

Java 환경에서 WAS는 서블릿(Servlet)과 JSP를 실행하는 컨테이너를 뜻하며, 트랜잭션 관리·커넥션 풀·세션 관리 같은 공통 기능을 표준화된 형태로 제공합니다. 달리 말하면 WAS는 웹서버가 단독으로 처리할 수 없는 동적 콘텐츠를 맡는 미들웨어입니다. 개발자가 만든 애플리케이션을 요리에 비유하면, WAS는 그 요리를 사용자 앞에 내놓는 그릇에 해당합니다(출처: OPENMARU — 마케터가 이해하는 WAS).

같은 Java WAS라도 구현 범위는 갈립니다. Apache Tomcat과 Eclipse Jetty는 Java EE 사양 가운데 일부를 구현한 오픈소스 서블릿 컨테이너이고, Red Hat JBoss EAP·Oracle WebLogic·Tmax JEUS는 사양 전체를 구현한 인증 상용 제품입니다(출처: OPENMARU — WAS, Java Servlet 동작 방식). 이 구현 범위 차이가 뒤에서 다룰 “Tomcat만으로 충분한가”라는 질문의 실제 근거입니다. WAS의 정의와 내부 구조, 제품군 전체 지형이 궁금하다면 기준 문서인 WAS란 무엇인가 글에서 한 편으로 정리해 두었습니다. 이 글에서는 “웹서버와의 관계”에 집중합니다.

한 문장으로 가르면 이렇습니다. 웹서버는 이미 만들어진 것을 전달하고, WAS는 요청받은 순간에 만들어 냅니다. 이 구분이 이후 모든 배치 결정의 출발점입니다.

그림 1. 웹서버와 WAS의 역할 구분 — 전달하는 계층과 만들어 내는 계층

요청 한 건은 어떤 경로를 거치는가 — 브라우저에서 DB까지

사용자가 주문 버튼을 누르면 요청은 웹서버 → WAS → 데이터베이스 순서로 흘러가고, 응답은 역순으로 돌아옵니다. 로그인 화면으로 바꿔 놓아도 순서는 같습니다. 화면의 입력 폼과 이미지·폰트는 웹서버가 그려 주고, 사용자가 입력한 계정 정보는 WAS로 넘어가 데이터베이스 조회로 검증되며, 그 결과가 다시 웹서버를 거쳐 화면에 표시됩니다(출처: OPENMARU — 마케터가 이해하는 WAS). 각 구간의 책임을 단계별로 따라가 보면 두 계층의 역할 차이가 선명해집니다.

1. 브라우저 → 웹서버: 브라우저가 HTTPS 요청을 보내면 웹서버가 TLS 암호화를 해제(SSL 종료)하고 요청을 해석합니다.
2. 웹서버의 분기: 요청 URL이 이미지·CSS 같은 정적 자원이면 웹서버가 직접 응답하고 여기서 끝납니다. /order처럼 동적 처리가 필요한 경로면 뒤쪽 WAS로 전달(프록시)합니다.
3. WAS의 로직 실행: WAS는 요청을 받아 스레드를 할당하고, 해당 서블릿·컨트롤러 코드를 실행합니다. 로그인 세션을 확인하고 주문 검증 로직을 수행합니다.
4. WAS → 데이터베이스: 재고 차감·주문 저장 같은 데이터 작업은 커넥션 풀에서 꺼낸 DB 연결로 처리하고, 여러 작업을 하나의 트랜잭션으로 묶어 전부 성공 또는 전부 취소를 보장합니다.
5. 응답의 귀환: WAS가 만든 결과(HTML·JSON)가 웹서버를 거쳐 브라우저로 돌아갑니다.

그림 2. 요청 한 건의 경로 — 브라우저에서 데이터베이스까지

이 경로에서 성능 문제의 위치도 갈립니다. 정적 자원이 느리면 웹서버·네트워크 구간을, 동적 응답이 느리면 WAS의 스레드 풀·힙 메모리·커넥션 풀과 DB 쿼리를 의심하는 것이 진단의 첫 원칙입니다. WAS 구간의 병목을 잡는 파라미터 기준은 WAS 성능 튜닝 — JVM 힙·GC·풀 설정 글에서 실전 수치와 함께 다룹니다.

웹서버와 WAS는 어떻게 연동하는가 — mod_jk와 mod_proxy, AJP

웹서버와 WAS는 커넥터(connector)라는 연결 통로로 묶입니다. Apache HTTP Server와 Tomcat을 연동하는 대표 방식은 두 가지입니다(출처: Apache Tomcat Connectors 공식 문서).

• mod_jk: Tomcat 전용 커넥터 모듈로, AJP(Apache JServ Protocol)라는 이진 프로토콜로 웹서버와 WAS를 연결합니다. 워커(worker) 단위의 세밀한 로드 밸런싱 설정이 가능해 전통적인 국내 엔터프라이즈 구성에서 오래 쓰였습니다.
• mod_proxy 계열: Apache에 기본 포함된 프록시 모듈로, mod_proxy_http는 HTTP로, mod_proxy_ajp는 AJP로 요청을 전달합니다. 별도 모듈 설치가 필요 없고 설정이 단순해 최근 구성의 기본값이 됐습니다.
• mod_cluster: JBoss·WildFly 계열에서 쓰이는 동적 로드 밸런싱 모듈입니다. WAS 인스턴스가 자신의 존재와 부하 상태를 웹서버에 알리면 웹서버가 그에 맞춰 요청을 분배하므로, 워커 목록을 사람이 적어 넣는 mod_jk와 달리 인스턴스 등록·해제가 자동으로 반영됩니다(출처: OPENMARU — Apache·Tomcat·JBoss·WildFly 설치 구성 가이드).

Nginx는 AJP를 기본 지원하지 않으므로 proxy_pass 지시자로 HTTP 리버스 프록시 연동을 사용합니다. 어느 방식이든 핵심 개념은 같습니다. 웹서버가 받은 요청 중 동적 요청만 골라 WAS의 포트(HTTP 8080, AJP 8009 등)로 넘기고, 응답을 받아 클라이언트에 되돌려 주는 구조입니다.

그림 3. 웹서버–WAS 커넥터 선택지 — mod_jk·mod_proxy·mod_cluster·proxy_pass

한 가지 보안 주의점이 있습니다. AJP 포트는 웹서버–WAS 사이 내부 통신 전용으로 설계된 통로라서 외부에 직접 노출하면 안 됩니다. 2020년 공개된 Ghostcat 취약점(CVE-2020-1938)은 외부에 노출된 AJP 커넥터로 웹 애플리케이션 파일을 읽을 수 있는 문제였고, Apache Tomcat은 이후 AJP 커넥터를 기본 비활성화하고 바인딩 주소를 루프백으로 제한했습니다(출처: Apache Tomcat 보안 공지). 커넥터 설정은 “연결되게 만드는 것”보다 “필요한 구간에만 열리게 만드는 것”이 요점입니다.

커넥터 방식을 골랐다고 끝이 아닙니다. 워커 수와 타임아웃, Apache의 Worker MPM 설정, Tomcat의 스레드 풀, JVM 옵션과 커널 파라미터가 서로 맞물려야 실제 처리량이 나옵니다. 이 구성값을 항목별로 확인하고 싶다면 실제 설치 보고서 형태로 정리한 Apache·Tomcat·JBoss·WildFly 설치 구성 가이드가 참고가 됩니다.

왜 분리 배치하는가 — 보안·부하 분산·장애 격리·SSL 오프로드

기능이 겹치는데도 두 계층을 나누는 이유는 성능이 아니라 설계 원칙에 가깝습니다. 오픈마루도 둘 중 하나만 쓰기보다 함께 두고 기능을 나누는 쪽이 응답 속도·서버 부하·보안 세 측면에서 모두 유리하다고 정리합니다(출처: OPENMARU — 마케터가 이해하는 WAS). 실무에서 분리 배치를 표준으로 삼는 근거는 네 가지입니다.

첫째, DMZ 보안 구성입니다. 웹서버만 DMZ(외부와 내부망 사이 완충 구역)에 두고 WAS와 DB는 내부망에 배치하면, 외부 공격자가 직접 닿을 수 있는 표면이 웹서버 하나로 줄어듭니다. WAS에는 애플리케이션 코드와 DB 접속 정보가 있으므로, 침해 시 피해가 큰 자산일수록 안쪽에 두는 원칙입니다. 방화벽은 웹서버→WAS의 지정 포트만 허용합니다.

둘째, 정적/동적 부하 분리입니다. 웹 페이지 한 화면을 그릴 때 요청의 다수는 이미지·CSS·스크립트 같은 정적 자원입니다. 이 요청까지 WAS가 받으면 비싼 애플리케이션 스레드가 파일 전송에 소모됩니다. 가벼운 정적 요청은 웹서버가 흡수하고 WAS는 로직 실행에 전념하면, 같은 하드웨어로 더 많은 동시 사용자를 감당할 수 있습니다.

셋째, 장애 격리와 무중단 운영입니다. 웹서버가 앞에서 여러 WAS 인스턴스로 부하를 나누고 있으면, WAS 한 대가 재기동되거나 장애가 나도 웹서버가 나머지 인스턴스로 요청을 우회시킵니다. 애플리케이션 배포 시 인스턴스를 순차 재기동하는 무중단 배포도 이 구조가 전제입니다. 이 주제를 아키텍처 수준으로 확장한 내용은 WAS 이중화(HA) 아키텍처 글에서 다룹니다.

넷째, SSL 오프로드입니다. TLS 암호화·복호화는 연산 비용이 큰 작업입니다. 웹서버 계층에서 SSL을 종료하면 WAS는 평문 통신으로 로직 실행에 집중할 수 있고, 인증서 관리도 관문 한 곳으로 모입니다.

그림 4. 분리 배치의 네 가지 이유 — DMZ 경계에 걸리는 보안·부하·장애·SSL

웹서버 없이 WAS 단독으로 운영해도 될까

가능합니다. 다만 어울리는 규모와 조건이 있습니다. Tomcat은 서블릿 컨테이너이면서 웹서버이기도 해서 단독 운영이 되고, 필요하면 Apache 웹서버나 IIS와 연동하는 선택지도 함께 열려 있습니다(출처: OPENMARU — Apache Tomcat). 자체적으로 정적 파일을 서빙할 수 있고 HTTP 커넥터로 직접 요청을 받을 수 있으므로, 사용자 수가 제한된 사내 시스템·개발/테스트 환경·소규모 서비스라면 WAS 단독 구성이 오히려 단순하고 관리하기 쉽습니다. 계층이 하나 줄면 설정·패치·장애 지점도 하나 줄어들기 때문입니다.

한계는 규모와 함께 옵니다. 외부 공개 서비스라면 DMZ 구성이 필요해지고, 트래픽이 늘면 정적 자원 오프로드와 로드 밸런싱이 필요해지며, 인스턴스가 여러 대가 되는 순간 앞단 관문 없이는 부하 분산 자체가 되지 않습니다. 결국 “웹서버를 둘 것인가”는 유행이 아니라 서비스의 노출 범위·트래픽·가용성 요구로 판단하는 문제입니다. 같은 논리로 “Tomcat만으로 충분한가, 상용 WAS가 필요한가”도 워크로드 기준으로 판단해야 하는데, 이 판단 기준은 Tomcat vs 상용 WAS — 언제 무엇을 선택할까 글에서 체크리스트로 정리했습니다.

실무 표준 토폴로지 — Apache+Tomcat, Nginx+WAS 구성 예시

국내 실무에서 가장 자주 만나는 구성은 두 가지입니다.

구성 A — Apache HTTP Server + Tomcat (전통적 엔터프라이즈형)

[브라우저]
   │ HTTPS(443)
[Apache HTTP Server ×2]  ← DMZ, SSL 종료, 정적 자원, mod_jk/mod_proxy 로드 밸런싱
   │ AJP(8009) 또는 HTTP(8080) — 내부망 전용
[Tomcat WAS ×N]          ← 내부망, 서블릿·비즈니스 로직 실행
   │ JDBC
[Database]

공공·금융 등 오래 운영된 Java 시스템의 표준형입니다. mod_jk의 워커 설정으로 인스턴스별 가중치·페일오버를 제어합니다.

구성 B — Nginx + WAS (경량 관문형)

[브라우저]
   │ HTTPS(443)
[Nginx ×2]               ← SSL 종료, 정적 캐싱, proxy_pass HTTP 리버스 프록시
   │ HTTP(8080)
[WAS ×N (Tomcat 등)]
   │ JDBC
[Database]

대량 동시 접속 처리에 유리한 Nginx 특성을 살린 구성으로, 신규 구축에서 채택이 늘고 있습니다. 어떤 구성이든 웹서버 2대 이상 + WAS N대 + 로드 밸런싱이라는 뼈대는 같으며, WAS가 여러 대가 되는 순간 로그인 세션을 어떻게 유지할지가 새 숙제로 등장합니다. 그 해법은 세션 클러스터링이며 별도 글에서 설계 기준까지 다룹니다.

쿠버네티스에서 웹서버의 역할은 왜 달라지는가

컨테이너와 쿠버네티스로 넘어오면 앞의 구성도가 그대로 통하지 않습니다. 웹서버가 없어져서가 아니라, 웹서버가 하던 일이 플랫폼 안으로 흡수되고 이름과 설정 방식이 바뀌기 때문입니다. 요청 경로는 대략 이렇게 바뀝니다.

[브라우저]
   │ HTTPS(443)
[L4 로드밸런서]
   │
[Ingress Controller / Gateway]  ← 클러스터 관문: SSL 종료, 경로 라우팅, 헤더 제어
   │ (Service → Endpoints)
[Pod ×N (WAS 컨테이너)]         ← 서블릿·비즈니스 로직 실행
   │ JDBC
[Database]

첫째, 웹서버가 “장비”에서 “클러스터 구성요소”가 됩니다. Ingress Controller의 실체는 대부분 Nginx나 Envoy입니다. Apache·Nginx가 사라진 것이 아니라 파드로 들어가 관문 역할을 계속 맡는 것입니다. 달라진 것은 설정 방법입니다. httpd.conf나 nginx.conf를 서버에 직접 고치는 대신, Ingress나 Gateway API 리소스를 YAML로 선언하면 컨트롤러가 실제 설정으로 옮겨 적습니다. 라우팅 규칙이 서버 파일이 아니라 클러스터 상태로 관리된다는 뜻이며, Gateway API는 Ingress의 표현력 한계를 보완하는 후속 표준으로 자리를 넓히고 있습니다(출처: Kubernetes 공식 문서).

둘째, 로드 밸런싱과 무중단 배포가 플랫폼 기본 기능으로 내려갑니다. mod_jk 시절에는 워커 목록에 WAS 인스턴스의 주소를 사람이 적어 넣고, 인스턴스를 늘릴 때마다 설정을 고쳐 반영했습니다. 쿠버네티스에서는 파드가 뜨고 지는 대로 Service의 엔드포인트 목록이 자동으로 갱신되고, readiness probe가 준비되지 않은 파드를 라우팅 대상에서 빼며, 롤링 업데이트가 순차 재기동을 대신합니다. 앞서 정리한 “장애 격리와 무중단 운영”이라는 목적은 그대로인데, 그것을 달성하는 주체가 웹서버 설정에서 스케줄러와 컨트롤러로 옮겨 간 셈입니다.

셋째, 경계가 네트워크 구역에서 정책으로 바뀝니다. DMZ는 물리적·논리적 망 분리를 전제한 개념입니다. 클러스터 안에서는 파드가 노드를 옮겨 다니고 IP도 수시로 바뀌므로, 방화벽 룰 대신 네임스페이스 분리와 NetworkPolicy로 “누가 누구에게 접근할 수 있는가”를 규정합니다. 서비스 메시를 얹으면 파드 간 통신을 mTLS로 암호화해 내부망이라는 이유만으로 평문 통신을 허용하던 관행도 걷어냅니다. 보호해야 할 자산을 안쪽에 둔다는 원칙은 같고, 그 “안쪽”을 규정하는 수단이 달라진 것입니다.

그림 5. 쿠버네티스로 옮겨 간 책임 — 같은 목적, 달라진 주체

실무에서 자주 나오는 질문 하나. 파드 안에 Apache를 사이드카로 함께 넣어야 할까요? 대개 필요 없습니다. SSL 종료와 경로 라우팅은 이미 관문에서 처리되고, 정적 자원은 뒤에서 설명할 CDN이나 오브젝트 스토리지로 빠지기 때문입니다. 웹서버와 WAS를 한 컨테이너에 몰아넣으면 이미지가 무거워지고 기동 시간이 늘며, 둘 중 하나만 고쳐도 전체를 다시 배포해야 합니다. 컨테이너 하나에 프로세스 하나라는 원칙을 지키는 편이 롤링 업데이트 단위를 깔끔하게 유지합니다.

CDN이 일반화되면서 달라진 것 — 정적 자원 오프로드의 이동

두 번째 변화는 앞단에서 왔습니다. CDN(Content Delivery Network, 콘텐츠 전송 네트워크)이 기본 옵션이 되면서, 웹서버의 본업이던 정적 파일 전달의 상당 부분이 사용자와 가까운 엣지로 옮겨 갔습니다. 이미지·CSS·스크립트·폰트는 엣지 캐시에서 응답되고 오리진까지 오지 않습니다. 오리진에 도착하는 요청은 캐시가 없는 첫 요청과, 애초에 캐시할 수 없는 동적 요청뿐입니다.

이 변화가 만드는 결과는 세 가지입니다.

• 정적/동적 부하 분리의 경계가 한 칸 올라갑니다. 예전에는 웹서버가 정적 요청을 흡수해 WAS를 보호했다면, 이제는 CDN이 웹서버까지 포함한 오리진 전체를 보호합니다. 오리진 웹서버가 다루는 트래픽 총량은 눈에 띄게 줄어듭니다.
• SSL 종료·압축·보안 필터링의 1차 지점도 엣지로 이동합니다. TLS 핸드셰이크가 엣지에서 끝나고, WAF와 봇 차단, DDoS 완화도 엣지에서 먼저 걸러집니다. 오리진 앞 웹서버는 여전히 TLS를 처리하지만, 대상이 일반 사용자 트래픽 전체가 아니라 CDN에서 넘어오는 요청으로 좁혀집니다.
• 웹서버의 무게중심이 처리량에서 정책으로 옮겨 갑니다. 남은 핵심 업무는 캐시 제어 헤더를 정확히 내려주는 일입니다. Cache-Control·ETag·Vary를 어떻게 설정하느냐가 캐시 적중률을 결정하고, 잘못 설정하면 캐시가 아예 동작하지 않거나 더 나쁜 일이 벌어집니다. 개인화된 응답이나 Set-Cookie가 붙은 응답이 공용 캐시에 저장되면 다른 사용자에게 그대로 노출될 수 있습니다(출처: MDN — HTTP Caching). 헤더 한 줄이 성능과 보안을 동시에 좌우하는 구간입니다.

그림 6. CDN 도입 후 계층별 책임 — 엣지가 흡수하고 오리진에 남는 것

그렇다면 CDN이 있으면 오리진 웹서버는 빼도 될까요. 그렇지 않습니다. CDN은 오리진을 대체하는 것이 아니라 오리진 앞에 캐시 계층을 하나 더 얹는 구조입니다. 캐시가 만료되는 순간 동일한 요청이 한꺼번에 오리진으로 몰리는 상황을 흡수하려면 앞단 관문이 필요하고, 경로 기반 라우팅과 인증 헤더 정규화도 오리진 쪽 책임입니다. 무엇보다 CDN을 우회한 직접 접근을 막는 일 — 오리진 IP를 감추고, CDN에서 온 요청만 서명 헤더나 허용 목록으로 통과시키는 설정 — 은 오리진 관문에서만 할 수 있습니다.

진단 관점도 한 겹 늘어납니다. 사용자가 느린 이유가 엣지 문제인지 오리진 문제인지부터 갈라야 하므로, 캐시 적중률과 오리진 응답 시간을 따로 보는 습관이 필요합니다. 적중률이 정상인데 체감이 느리다면 원인은 캐시 뒤편, 즉 WAS와 DB 구간에 있습니다.

두 변화를 겹쳐 보면 결론은 하나로 모입니다. 웹서버의 역할이 없어진 것이 아니라 자리를 옮겼습니다. 정적 전달은 위쪽 엣지로, 라우팅과 SSL 종료는 클러스터 관문으로 흩어졌습니다. 남은 오리진에서는 WAS가 동적 처리에만 집중하게 되는데, 이는 곧 앞단이 걸러 주지 못하는 지연이 전부 WAS 계층의 문제라는 뜻이기도 합니다. 계층을 나눌수록 “어디가 병목인가”를 가려내는 일이 더 중요해지는 이유입니다.

구성은 시작일 뿐 — 연동 이후의 운영 과제와 OPENMARU

웹서버–WAS 분리 구성을 마치면 아키텍처의 절반이 끝난 것입니다. 나머지 절반은 운영입니다. 커넥터 타임아웃과 워커 수는 WAS 스레드 풀과 맞물려야 하고, 인스턴스가 늘면 세션 공유가 필요하며, 장애가 나면 “웹서버·WAS·DB 중 어디가 병목인가”를 빠르게 특정해야 합니다. 계층을 나눈 만큼 관찰해야 할 구간도 늘어나는 셈입니다.

OPENMARU는 이 운영 구간을 제품으로 지원합니다. OPENMARU iAP(Intelligent Application Platform)는 Web/WAS 런타임에 세션 클러스터링·성능관리·운영관리를 결합한 국산 통합 WAS 플랫폼으로, 엔터프라이즈와 공공의 기존 서버·가상화(VM) 환경을 대상으로 합니다. 웹서버–WAS 구성 자동화와 설치 보고서 자동 생성으로 구축 품질을 표준화하는데, 이 보고서에는 mod_jk·mod_cluster·mod_proxy 같은 웹 커넥터 설정과 Worker MPM·스레드 풀·JVM 옵션·커널 파라미터 값이 그대로 담깁니다. 구성 근거가 문서로 남으면 인수인계와 장애 회고의 출발점이 달라집니다.

관측 쪽은 OPENMARU APM(Application Performance Management, 애플리케이션 성능 관리)이 맡습니다. 이 글에서 나눈 두 계층을 그대로 나눠서 봅니다. 웹서버 구간은 Apache·Nginx의 초당 처리 건수와 트래픽, 워커 상태를 보고, WAS 구간은 트랜잭션 프로파일링·SQL 실행 내역·JVM 스레드와 데드락·응답시간 분포로 들어갑니다. Tomcat·JBoss EAP·WildFly·WebLogic·WebSphere·JEUS·Jetty·Resin·Spring Boot까지 국내 현장에서 만나는 WAS 제품군을 폭넓게 지원하므로, 제품이 섞인 환경에서도 “웹서버가 느린가, WAS가 느린가”를 같은 화면에서 가릅니다.

세션은 별도 계층으로 떼어 냅니다. 세션이 WAS 내부 메모리에만 있으면 인스턴스가 죽는 순간 로그인도 함께 사라지므로, OPENMARU Cluster는 세션을 WAS 밖의 인메모리 데이터 그리드(IMDG)에 두어 인스턴스 장애나 순차 재기동에도 세션이 살아남게 합니다(출처: OPENMARU — WAS 장애·세션 유실·APM 선택 기준). 상용 WAS의 EOS/EOL 주기마다 반복되는 업그레이드·회귀 테스트 부담을 플랫폼 단위로 걷어내는 접근은 WAS 단종(EOS/EOL) 대응 글에서 따로 다룹니다.

iAP가 겨냥하는 구간은 지금 운영 중인 서버·가상화 기반 Web/WAS 환경이며, 쿠버네티스로 재구축한 워크로드는 클라우드 네이티브 전환 라인업이 따로 맡습니다. 웹서버와 WAS의 차이를 이해하는 일은 결국 “각 계층을 제대로 배치하고, 배치한 만큼 관측하는” 운영 역량으로 이어질 때 값을 합니다.

자주 묻는 질문 (FAQ)

Q. 웹서버와 WAS의 차이는 무엇인가요?
웹서버는 HTML·이미지 같은 정적 콘텐츠를 전달하고 리버스 프록시·SSL 종료를 맡는 관문이며, WAS는 비즈니스 로직을 실행해 동적 응답을 만드는 계층입니다. 웹서버는 만들어진 것을 전달하고, WAS는 요청 시점에 결과를 만들어 냅니다.

Q. 웹서버 없이 WAS만 운영해도 되나요?
소규모 사내 시스템이나 개발 환경이라면 가능합니다. Tomcat은 정적 파일 서빙과 HTTP 직접 수신을 지원합니다. 다만 외부 공개 서비스는 DMZ 보안 구성, 정적 부하 오프로드, 다중 인스턴스 로드 밸런싱이 필요해 앞단 웹서버를 두는 것이 표준입니다.

Q. mod_jk와 mod_proxy 중 무엇을 써야 하나요?
새 구성이라면 Apache 기본 포함 모듈인 mod_proxy 계열(mod_proxy_http/mod_proxy_ajp)이 단순합니다. 워커 단위의 세밀한 로드 밸런싱·페일오버 제어가 필요한 기존 엔터프라이즈 구성에서는 mod_jk가 여전히 쓰입니다. 어느 쪽이든 AJP 포트는 내부망 전용으로 제한해야 합니다.

Q. 웹서버와 WAS를 분리하면 무엇이 좋아지나요?
공격 표면이 DMZ의 웹서버로 줄어 보안이 강화되고, 정적 요청을 웹서버가 흡수해 WAS 자원이 로직 실행에 집중됩니다. WAS 장애·재기동 시 요청을 우회시켜 무중단 운영이 가능하고, SSL 연산을 관문에 모아 WAS 부담을 줄입니다.

Q. 쿠버네티스를 쓰면 웹서버는 필요 없나요?
필요합니다. 다만 형태가 바뀝니다. SSL 종료·경로 라우팅·헤더 제어 같은 관문 역할은 Ingress Controller나 Gateway가 이어받고, 그 실체는 대개 Nginx나 Envoy입니다. 설정은 서버의 설정 파일이 아니라 클러스터 리소스(YAML)로 선언하며, 로드 밸런싱과 무중단 배포는 Service와 롤링 업데이트가 담당합니다.

Q. CDN을 쓰면 오리진 웹서버를 빼도 되나요?
아닙니다. CDN은 오리진을 대체하지 않고 앞에 캐시 계층을 더하는 구조입니다. 캐시 만료 시 몰리는 요청 흡수, 경로 라우팅, 캐시 제어 헤더 관리, CDN 우회 접근 차단은 오리진 관문의 몫입니다. 특히 Vary나 Set-Cookie 처리를 잘못하면 개인화 응답이 공용 캐시에 저장돼 다른 사용자에게 노출될 수 있습니다.

Q. 3-tier 구조에서 WAS는 어느 계층인가요?
웹서버(1계층)와 데이터베이스(3계층) 사이의 2계층입니다. 프레젠테이션 관문 뒤에서 애플리케이션 로직과 트랜잭션·세션을 처리하는 시스템의 두뇌 역할이며, 확장(스케일아웃)이 가장 빈번하게 일어나는 계층입니다.

참고 리소스

OPENMARU (자사)
– WAS란 무엇인가 — 구조와 기능, 제품 선택 기준까지
– 마케터가 이해하는 WAS — 웹서버와의 역할 구분
– WAS, Java Servlet 동작 방식 한눈에 알아보기
– Apache Tomcat — 오픈소스 서블릿 컨테이너 소개
– Apache Tomcat 설치의 모든 것 — OPENMARU
– Apache·Tomcat·JBoss·WildFly 설치 구성 가이드 — OPENMARU
– OPENMARU APM — WEB/WAS 모니터링
– WAS 장애·세션 유실·APM 선택 기준 정리
– WAS 단종(EOS/EOL) 대응 — 업그레이드 말고 다른 선택지
– OPENMARU iAP — 제품 페이지
– 조달물품 OPENMARU iAP — 제품 소개

표준·공식 문서 (외부)
– Apache HTTP Server 2.4 Documentation
– Apache Tomcat Connectors Documentation
– Web Server vs. Application Server — IBM
– Nginx Documentation
– Apache Tomcat Security Considerations
– Kubernetes Ingress — Kubernetes Documentation
– Kubernetes Gateway API
– HTTP Caching — MDN Web Docs