Web vs WAS

1. 개념

1.1. Web Server

Web Server는 클라이언트(주로 웹 브라우저)로부터의 요청을 받아서, 필요한 자원을 전달해주는 소프트웨어 혹은 하드웨어를 의미합니다. 가장 기본적인 역할은 정적(Static) 콘텐츠를 제공하는 것이며, HTTP/HTTPS 프로토콜을 통해 HTML, CSS, JavaScript 파일, 이미지, 동영상 등과 같은 정적 파일을 요청에 맞게 응답합니다.

동작 방식

• 클라이언트(브라우저)가 URL로 요청을 보냅니다.

• 웹 서버는 요청된 리소스(예: HTML, CSS, JS 파일 등)가 존재하는지 확인합니다.

• 정적 파일이 존재한다면, 해당 파일을 HTTP Response로 반환합니다.

• 존재하지 않거나 서버 측 연산이 필요한 요청인 경우, 에러나 다른 서버(WAS)에 처리를 위임하기도 합니다.

특징

• 정적 파일 처리 최적화: 요청이 들어오면 빠르게 파일을 찾아서 반환

• 가벼운 프로세스 구조: 리소스 사용이 상대적으로 적음

• Reverse Proxy / Load Balancer 역할: Web Server가 들어오는 트래픽을 여러 서버(WAS 등)로 분산할 수 있음

1.2. WAS

흔히 Servlet Container 혹은 Application Server라고도 부르는데, Java 생태계에서 자주 사용되는 Tomcat, JBoss(WildFly), WebLogic, WebSphere 등이 대표적인 WAS입니다.

역할

• 비즈니스 로직 처리 (예: 데이터베이스 연동, 동적 페이지 생성)

• 트랜잭션 관리, 세션 관리 등 다양한 부가 서비스 제공

• 서블릿(Servlet), JSP, EJB(Enterprise Java Bean) 등 Java 기반 웹 애플리케이션을 실행하는 데 필요한 환경 제공

동작 방식

WAS는 내부적으로 Servlet Container와 같은 엔진을 가지고 있어, 클라이언트 요청이 웹 서버를 통해 혹은 직접 WAS로 전달되면, 그 요청을 처리할 **비즈니스 로직(서블릿, JSP 등)**을 동작시키고, 결과를 생성하여 응답합니다.

1. 요청이 들어오면, WAS는 특정 URL 패턴에 매핑된 Servlet 혹은 JSP를 실행합니다.

2. Servlet/JSP는 필요한 데이터를 조회하거나 비즈니스 로직을 수행합니다. (DB 접근, 연산 등)

3. 실행 결과를 최종적으로 HTML 등의 형태로 만들어서, 다시 HTTP Response로 반환합니다.

주요 기능

• 비즈니스 로직 동작: 동적인 웹 페이지 생성, 데이터베이스 연동, 세션·쿠키 관리 등

• 트랜잭션 관리: 여러 DB 작업이 동시에 일어나도 일관성을 유지할 수 있도록 돕는 기능

• 보안: 인증(Authentication), 권한(Authorization) 같은 기능 제공

• 라이프사이클 관리: 서블릿 객체 생성, 초기화, 서비스, 소멸 등의 과정을 효율적으로 관리

1.3. 차이점

(1) 역할 구분

• Web Server: 정적 콘텐츠 제공이 주 역할.

• WAS: 동적인 로직 처리 및 웹 애플리케이션 실행 환경 제공.

예를 들어, 단순히 HTML 파일이나 이미지 파일을 반환하는 것은 Web Server 혼자서 처리할 수 있지만, 사용자 로그인을 처리하거나 데이터베이스에서 정보를 조회해 화면에 뿌려주는 기능(동적 기능)은 일반적으로 WAS의 역할입니다.

(2) 구성/스펙 차이

• Web Server: 비교적 가벼운 구조, CPU와 메모리를 적게 사용.

• WAS: 내부적으로 JVM(Java Virtual Machine)이나 특정 런타임이 동작하면서 복잡한 로직을 처리하기 때문에, 상대적으로 많은 자원(CPU, 메모리 등)을 필요로 함.

(3) 운영 방식

• 단독 사용:

  • Web Server만 사용하는 경우: 정적 페이지 제공, 간단한 서버 사이드 스크립트(PHP, Python 등) 처리 가능

  • WAS만 사용하는 경우: 웹 서버로서도 동작하며, 동적 로직 처리까지 모두 수행(예: Tomcat 단독 사용).

• 혼합 사용:

  • Web Server + WAS 조합은 실제 대규모 서비스에서 자주 쓰이는 구조. Web Server는 정적 리소스 응답을 담당하고, WAS는 동적 처리에만 집중하도록 하여, 서버 자원과 트래픽을 분산하는 형태입니다.

4) 왜 둘을 분리하는가?

• 성능(Performance) 최적화: 정적 파일(이미지, CSS, JS 등)은 Web Server가 빠르게 처리하고, WAS는 무거운 로직만 담당하도록 해 자원 사용 효율을 높임.

• 보안(Security): Web Server를 외부 네트워크에 두고, WAS는 방화벽 뒤 내부망에 배치해 외부 공격을 차단.

• 유지보수(Maintenance): 정적/동적 자원의 관리 주체를 분리하여, 업데이트나 장애 처리를 좀 더 효과적으로 진행.

• 확장성(Scalability): 필요한 컴퓨팅 자원에 따라 Web Server와 WAS를 독립적으로 수평 확장(Load Balancing)할 수 있음.

2. 질문

1. Web Server와 WAS(Web/Application Server)의 차이점은 무엇인가요?

"Web Server는 정적 리소스(HTML, CSS, JS 등)를 빠르게 제공하고, WAS는 동적 로직(서블릿, JSP 등)을 실행하여 데이터를 가공·처리한 뒤 HTML 응답을 생성합니다. 일반적으로 대규모 환경에서는 두 서버를 분리해서 사용하여 성능과 보안을 높이는 경우가 많습니다."

• Web Server: 정적(Static) 콘텐츠 제공, 가벼운 프로세스, 주로 HTTP 요청 처리

• WAS: 동적(Dynamic) 로직 처리(서블릿/JSP, 트랜잭션 관리 등), 무겁고 복잡한 비즈니스 로직 담당

• 예시 제품

  • Web Server: Apache HTTP Server, Nginx, IIS

  • WAS: Tomcat, JBoss(WildFly), WebLogic, WebSphere

1. 왜 별도의 WAS가 필요한가요? Web Server만으로는 부족한 부분이 무엇인가요?

“정적 파일만 제공한다면 Web Server만으로 충분하지만, 로그인, 결제, DB 연동 등의 동적 기능을 처리하려면 WAS가 필요합니다. WAS는 세션 관리, 트랜잭션 처리 등 복잡한 기능을 제공하므로, 대규모 웹 애플리케이션에서 필수적입니다.”

• Web Server만으로는 동적인 비즈니스 로직(DB 연동, 트랜잭션, 세션 등) 처리에 한계

• WAS는 트랜잭션, 세션, 스레드 관리, 보안 등 부가 기능 제공

• 대규모 확장성, 유지보수 편의성을 위해 WAS가 필요

1. Servlet/JSP가 어떻게 동작하는지 간단히 설명해주실 수 있나요?”

“JSP 파일은 처음 요청 시 서블릿 클래스로 변환되어 컴파일됩니다. 이후 사용자가 요청을 보낼 때마다 해당 서블릿의 service() 메서드가 실행되어 동적 결과를 생성하고, 최종 HTML 형태로 브라우저에게 전달합니다. init() 단계에서는 리소스 초기화를, destroy() 단계에서는 정리를 수행합니다.”

• JSP → 서블릿으로 변환/컴파일

• 서블릿 생명주기: init() → service() → destroy()

• Request/Response 흐름: 사용자 요청 → 서블릿(또는 JSP) 동작 → 동적 HTML 생성 → 응답

1. Web Server에 정적 파일(이미지, HTML, CSS 등)과 동적 콘텐츠(서블릿, JSP)를 어떻게 분산 배치할 수 있나요?

“Apache나 Nginx에서 Reverse Proxy 설정을 통해 정적 파일 경로(/static, /images 등)는 자체적으로 서빙하고, 특정 URL(/api, /app 등)은 AJP 또는 HTTP Proxy 방식으로 Tomcat과 같은 WAS로 포워딩해 분산 배치합니다.”

• Reverse Proxy 또는 Proxy Pass 설정: 정적 리소스는 Web Server에서 직접 서빙

• 동적 요청은 AJP(Mod_jk), HTTP Proxy, Context Path 등을 통해 WAS로 전달

• 예: Apache + Tomcat 연동, Nginx + Tomcat 연동 등

1. WAS에서 세션 관리는 어떻게 이루어지나요?

“WAS는 보통 쿠키(JSESSIONID)를 통해 세션을 구분합니다. 서버가 세션을 생성해 클라이언트에 ID를 할당하고, 이후 요청 시 쿠키로 식별합니다. 세션 클러스터링이 필요한 환경에서는 여러 서버 간 세션 데이터를 복제하거나 외부 세션 스토리지를 사용하기도 합니다.”

• 쿠키 기반 세션(JSESSIONID)

• URL Rewriting(쿠키를 사용할 수 없을 때 대체)

• 세션 클러스터링: 여러 WAS 인스턴스 간 세션 동기화(Replication), In-memory 세션 스토리지(Redis 등)

1. WAS에서 스레드는 어떻게 관리되고, 동시에 많은 요청이 들어오면 어떤 방식으로 처리하나요?

“WAS는 내부적으로 스레드 풀을 운영하여 요청당 스레드를 할당합니다. 요청이 폭주하면 스레드 풀이 가득 차 대기열이 생길 수 있는데, 이를 해결하기 위해 서버를 여러 대 두고 로드밸런싱하거나 서버 성능을 향상시키는 수직 확장을 고려합니다.”

• 스레드 풀(Thread Pool) 기반 요청 처리

• 동시성 제어(임계구역, synchronized)

• 확장성: 수평적 확장(서버 추가, 로드밸런싱), 수직적 확장(CPU/메모리 증설)

1. Web Server와 WAS를 분리해서 구성할 때의 장점은 무엇인가요?

“보안적으로 WAS를 내부망에 배치할 수 있고, Web Server가 정적 파일만 효율적으로 처리하여 부담을 줄일 수 있습니다. 또한 트래픽 증가 시 Web Server나 WAS를 각각 필요에 따라 확장할 수 있어, 유지보수와 확장성이 훨씬 좋아집니다.”

• 보안: 외부망에는 Web Server만 노출, WAS는 내부망에서 보호

• 부하 분산: 정적 vs. 동적 역할 분리, 로드밸런싱 설정 용이

• 확장성 & 유지보수: 각각 독립적으로 모니터링, 튜닝, 재시작

1. HTTPS 연결과 SSL/TLS 인증서 관리는 보통 어디서 처리하나요?

“대부분의 환경에서는 Web Server(Nginx 등) 레벨에서 SSL 인증서를 설치해 HTTPS 연결을 처리합니다. 이렇게 하면 WAS는 내부망에서 평문 HTTP로 통신하며 부담이 줄고, 인증서 관리도 한 곳에서 집중적으로 할 수 있습니다.”

1. WAS 성능을 튜닝해본 경험이 있나요? 어떤 방법을 사용했고 어떤 지표를 확인했나요?

“Tomcat 환경에서 JVM Heap 사이즈 조정, GC 방식을 CMS나 G1GC로 바꿔본 경험이 있습니다. 또한 커넥션 풀을 적절히 조정해 DB 부하를 관리했으며, APM(New Relic, Pinpoint 등)으로 CPU, 메모리, 스레드 덤프 등을 모니터링하여 병목 지점을 발견·개선했습니다.”

• JVM 옵션(Heap, Garbage Collection 알고리즘) 튜닝

• Connection Pool(DB 커넥션 풀) 사이즈 조정

• 모니터링 툴(APM, JMX, 로그 분석) 활용

• CPU 사용량, 메모리, 응답 시간, 스레드 현황 등을 꾸준히 체크

1. Docker, Kubernetes 같은 컨테이너 환경에서 Web Server와 WAS를 어떻게 구성하면 좋을까요?

“각 서버를 컨테이너 이미지로 만들어 K8s에서 Pod로 띄우고, Ingress나 Service를 통해 트래픽을 분산시킵니다. 필요에 따라 Pod 수를 동적으로 조정해 스케일 아웃이 손쉽게 이루어지며, CI/CD 도구와 연계해 버전 배포 자동화를 구현합니다.”

• Docker 이미지로 Web Server(Nginx, Apache) + WAS(Tomcat, etc.)를 각각 컨테이너화

• Kubernetes에서 Deployment, Service, Ingress 등을 이용해 스케일링/로드밸런싱

• CI/CD 파이프라인과 연계하여 자동화된 배포

1. WAS 클러스터링(Clustering) 구성은 왜 필요하며, 어떻게 구현하나요?

“대규모 서비스에서 가용성과 성능을 높이려면 WAS 클러스터링이 필수입니다. 로드밸런서를 두어 트래픽을 여러 서버에 분산하고, 세션은 Sticky Session을 사용하거나 In-memory/Redis를 통해 공유해 사용자를 분산시켜도 세션 문제가 없도록 구현합니다.”

• 고가용성(HA): 한 대의 서버가 다운되어도 다른 서버가 서비스 유지

• 로드밸런싱: 사용자 요청을 여러 대 WAS가 나눠 처리

• 세션 클러스터링: 사용자 세션 정보 공유(Sticky Session, In-memory Replication, DB/Redis 저장)

1. 모놀리식(Monolithic) 아키텍처와 마이크로서비스(MSA) 아키텍처에서 WAS의 역할은 어떻게 달라지나요?

“모놀리식에서는 단일 WAS가 모든 기능을 책임져 배포 시 전체 애플리케이션을 재시작해야 합니다. 반면 MSA는 각 기능별로 독립된 서비스(WAS 또는 경량 웹 프레임워크)로 구성하므로, 부분적인 확장이나 장애 격리가 가능해 운영 유연성이 높아집니다.”

• 모놀리식: 하나의 WAS(큰 애플리케이션)에서 모든 기능 처리

• MSA: 여러 개의 독립적인 서비스(각자 WAS 또는 런타임)로 분산

• 팀 단위 배포, 확장성, 장애 격리 등의 차이

1. WAS에서 발생하는 대표적인 성능 병목(Bottleneck) 원인은 무엇인가요?

“가장 흔한 원인은 DB 연결 문제(커넥션 풀 부족, 느린 쿼리)와 JVM 메모리/GC 문제입니다. 또한 외부 API와의 통신이 지연되면 스레드가 대기 상태가 되어 병목이 발생하기도 합니다.”

• DB 커넥션 부족, 쿼리 최적화 문제

• 스레드 풀 고갈, GC 과도, 메모리 누수

• External API(타 시스템 연동) 지연