WAS 핸드북 동적 웹의 심장을 파헤치다

2025-09-22 01:20

• WAS(Web Application Server)는 동적인 웹 페이지 생성을 전담하는 미들웨어로, 웹 서버와는 달리 비즈니스 로직 수행과 데이터베이스 연동을 처리한다.

• 내부적으로 서블릿 컨테이너, 트랜잭션 관리, 커넥션 풀링 등의 핵심 기능을 통해 애플리케이션의 안정적이고 효율적인 실행 환경을 제공한다.

• 현대 웹 아키텍처에서는 웹 서버와 WAS를 연동하여 정적/동적 콘텐츠 처리를 분리함으로써 성능, 안정성, 보안을 극대화하는 구조가 표준으로 사용된다.

WAS 핸드북 동적 웹의 심장을 파헤치다

오늘날 우리가 당연하게 사용하는 수많은 웹 서비스들, 예를 들어 은행 앱에서 계좌를 조회하거나, 쇼핑몰에서 상품을 검색하고, 소셜 미디어에 글을 남기는 모든 활동의 이면에는 보이지 않는 강력한 엔진이 작동하고 있다. 바로 **웹 애플리케이션 서버(Web Application Server, 이하 WAS)**다.

단순히 저장된 정보를 보여주던 초창기 웹을 넘어, 사용자와 실시간으로 상호작용하는 ‘살아있는 웹’을 가능하게 만든 핵심 기술, WAS. 이 핸드북은 WAS가 왜 탄생했으며, 어떤 구조로 이루어져 있고, 어떻게 동작하는지 그 심장부를 A부터 Z까지 상세하게 파헤친다.

1장 WAS의 탄생 배경 정적 웹의 한계와 동적 웹의 서막

인터넷 초창기, 웹의 역할은 단순했다. 서버에 미리 저장된 HTML 파일을 사용자가 요청하면 그대로 전달해 주는 것. 이것이 바로 정적(Static) 웹이다. 마치 도서관 서가에 꽂힌 책을 그대로 꺼내주는 사서와 같다. 이 역할을 수행하는 소프트웨어가 바로 **웹 서버(Web Server)**다. Apache, Nginx 등이 대표적이다.

하지만 웹이 발전하면서 사람들은 더 많은 것을 원하기 시작했다.

• 사용자마다 다른 페이지를 보여주고 싶다. (예: ‘홍길동님, 환영합니다!‘)

• 사용자가 입력한 값에 따라 다른 결과를 보여주고 싶다. (예: ‘서울 날씨’ 검색 결과)

• 데이터베이스에 저장된 정보를 실시간으로 웹에 표시하고 싶다. (예: 최신 상품 목록)

정적 웹 서버만으로는 이런 요구를 처리할 수 없었다. 매번 사용자가 바뀔 때마다 그에 맞는 HTML 파일을 수동으로 만들어 서버에 저장해 둘 수는 없는 노릇이다. ‘요청이 들어오는 그 순간’에, 사용자와 상황에 맞는 HTML을 동적으로 생성할 무언가가 필요해졌다.

초기에는 CGI(Common Gateway Interface)라는 기술이 이 역할을 했다. 웹 서버가 요청을 받으면 CGI 프로그램을 호출하고, 이 프로그램이 로직을 처리해 HTML을 생성한 뒤 웹 서버에 전달하는 방식이다. 하지만 CGI는 요청마다 새로운 프로세스를 생성해야 해서 서버에 엄청난 부하를 주었고, 이는 곧 성능 저하로 이어졌다.

이러한 한계를 극복하기 위해 등장한 것이 바로 WAS다. WAS는 애플리케이션 로직을 효율적으로 실행하고, 데이터베이스와 연동하며, 그 결과를 동적으로 생성하여 웹 서버에 전달하는 데 특화된 전문 미들웨어(Middleware)다. CGI처럼 매번 프로세스를 만드는 대신, 미리 생성된 스레드(Thread)를 재활용하고, 데이터베이스 연결을 관리하는 등 고성능을 위한 다양한 기술을 내장했다. 비로소 동적 웹의 시대가 활짝 열린 것이다.

2장 WAS와 웹 서버의 결정적 차이 환상의 콤비

많은 이들이 WAS와 웹 서버를 혼동하거나, 둘 중 하나만 있으면 된다고 생각한다. 하지만 둘은 명확히 다른 역할을 수행하며, 현대 웹 시스템에서는 서로 협력하는 파트너 관계에 가깝다.

구분	웹 서버 (Web Server)	웹 애플리케이션 서버 (WAS)
주요 기능	정적 콘텐츠(HTML, CSS, JS, 이미지) 제공	동적 콘텐츠 생성 (비즈니스 로직 수행, DB 연동)
처리 내용	HTTP 프로토콜 기반 요청/응답	웹 애플리케이션의 로직 실행
비유	창고 관리인 (요청된 물건을 그대로 내어줌)	요리사 (요청에 따라 재료를 가공해 새로운 요리를 만듦)
대표 제품	Apache HTTP Server, Nginx, Microsoft IIS	Apache Tomcat, JBoss, WebSphere, WebLogic, Jeus

그렇다면 왜 둘을 함께 사용할까?

오늘날 대부분의 대규모 웹 서비스는 아래와 같은 구조를 가진다.

사용자 ↔ 웹 서버 ↔ WAS ↔ 데이터베이스

WAS 자체도 정적 콘텐츠를 처리하는 기능을 가지고 있지만, 굳이 웹 서버를 앞에 두는 이유는 다음과 같다.

1. 기능 분리를 통한 서버 부하 감소: 웹 서버는 정적 콘텐츠 처리에 최적화되어 있다. 이미지나 CSS 파일 같은 정적 파일 요청은 WAS까지 전달하지 않고 웹 서버가 빠르게 처리함으로써, WAS는 오롯이 복잡한 동적 콘텐츠 생성에만 집중할 수 있다. 이는 전체 시스템의 성능을 향상시킨다.

2. 로드 밸런싱(Load Balancing): 여러 대의 WAS를 운영(클러스터링)할 경우, 웹 서버가 앞단에서 사용자 요청을 받아 여러 WAS에 균등하게 분배해주는 ‘교통정리’ 역할을 수행할 수 있다. 이를 통해 특정 서버에 과부하가 걸리는 것을 막고, 안정적인 서비스 운영이 가능해진다.

3. 보안 강화: 웹 서버를 WAS 앞단에 배치하여 리버스 프록시(Reverse Proxy)로 사용하면, 실제 WAS의 IP 주소나 포트 정보를 외부에 노출하지 않을 수 있다. 해커의 공격을 웹 서버단에서 일차적으로 방어하고, 중요한 비즈니스 로직이 담긴 WAS를 보호하는 효과가 있다.

4. 무중단 서비스 운영: WAS 서버에 장애가 발생하거나, 새로운 버전의 애플리케이션을 배포하기 위해 재시작해야 할 때, 웹 서버는 해당 WAS로의 요청을 일시적으로 차단하고 다른 정상적인 WAS로 요청을 넘겨줄 수 있다. 이를 통해 사용자는 서비스 중단을 느끼지 못하게 된다.

결론적으로, 웹 서버와 WAS는 각자의 전문 분야에서 역할을 분담하여 시스템 전체의 효율성과 안정성을 극대화하는 환상의 콤비라고 할 수 있다.

3장 WAS의 내부 구조 심층 분석 동적 웹을 움직이는 5대 핵심 장치

WAS는 단순히 코드만 실행하는 통이 아니다. 웹 애플리케이션이 안정적으로, 효율적으로, 그리고 안전하게 실행될 수 있도록 다양한 환경과 기능을 제공하는 정교한 시스템이다. WAS의 심장부에는 다음과 같은 핵심 장치들이 존재한다.

1. 웹 컨테이너 (Web Container) / 서블릿 컨테이너 (Servlet Container)

• 역할: WAS의 가장 핵심적인 엔진. 웹 애플리케이션(Java의 경우 서블릿, JSP)의 생명주기를 관리하고, HTTP 요청을 받아 스레드를 생성하여 애플리케이션 코드가 실행될 환경을 제공한다.

• 비유: 웹 애플리케이션을 위한 **‘운영체제(OS)‘**와 같다. 개발자는 애플리케이션의 비즈니스 로직에만 집중하면 되고, 복잡한 네트워크 통신, 스레드 관리, 생명주기 관리 등은 컨테이너가 알아서 처리해 준다.

• 작동 방식:

  1. WAS가 실행되면 컨테이너는 설정 파일(web.xml 등)을 읽어 애플리케이션 환경을 구성한다.

  2. HTTP 요청이 들어오면, 컨테이너는 HttpServletRequest와 HttpServletResponse 객체를 생성한다.

  3. 요청 URL에 매핑된 서블릿을 찾아 실행한다. 이때 컨테이너가 관리하는 스레드 풀에서 스레드를 할당한다.

  4. 서블릿의 service() 메소드를 호출하여 비즈니스 로직이 수행되도록 한다.

  5. 로직 수행이 완료되면, 생성된 동적 결과를 HttpServletResponse 객체에 담아 웹 서버로 전달하고, 요청 처리에 사용된 객체들을 소멸시킨다.

2. 트랜잭션 관리 (Transaction Management)

• 역할: 여러 개의 데이터베이스 작업을 하나의 논리적인 단위로 묶어, 모두 성공하거나 모두 실패하도록 보장하는 기능(원자성, Atomicity).

• 비유: **‘은행 계좌 이체’**와 같다. A 계좌에서 10만 원을 출금하는 작업과 B 계좌에 10만 원을 입금하는 작업은 반드시 함께 성공해야 한다. 출금만 되고 입금이 실패하면 큰일이다. 트랜잭션은 이 두 작업을 하나의 ‘거래’로 묶어 데이터의 일관성을 지켜주는 안전장치다.

• 필요성: 쇼핑몰에서 상품 주문 시 ‘주문 정보 기록’, ‘재고 차감’, ‘포인트 적립’ 등 여러 DB 작업이 동시에 일어난다. 이 중 하나라도 실패하면 데이터가 꼬이게 되는데, WAS의 트랜잭션 관리 기능이 이를 막아준다.

3. 데이터베이스 커넥션 풀 (Database Connection Pool, DCP)

• 역할: 데이터베이스와의 연결(Connection)은 비용이 매우 비싼 작업이다. 매번 요청이 올 때마다 DB에 새로 연결하고 끊는 것을 반복하면 시스템 성능이 크게 저하된다. 커넥션 풀은 미리 일정 개수의 DB 커넥션을 만들어 ‘풀(Pool)‘에 저장해두고, 필요할 때마다 빌려주고 반납받는 방식이다.

• 비유: **‘택시 차고지’**와 같다. 승객(요청)이 있을 때마다 공장에서 택시(커넥션)를 새로 만드는 대신, 차고지에 대기 중인 택시를 바로 배차해 주고, 운행이 끝나면 다시 차고지로 돌려보내 다른 승객을 기다리게 하는 것과 같다.

• 효과: DB 연결에 드는 시간을 획기적으로 줄여 애플리케이션의 응답 속도를 크게 향상시킨다. WAS 설정에서 풀의 최대/최소 개수 등을 지정하여 시스템 자원을 효율적으로 관리할 수 있다.

4. 세션 관리 (Session Management)

• 역할: HTTP 프로토콜은 본질적으로 상태가 없는(Stateless) 프로토콜이다. 즉, 서버는 방금 전의 요청과 지금의 요청이 같은 사용자로부터 온 것인지 기억하지 못한다. 세션 관리는 이러한 한계를 극복하고 사용자가 로그인한 상태를 유지하거나 장바구니 정보를 기억하는 등, 여러 요청에 걸쳐 사용자의 상태를 유지해 주는 기능이다.

• 작동 방식: 사용자가 처음 접속하여 로그인을 성공하면, WAS는 고유한 세션 ID를 생성하여 쿠키 등을 통해 사용자 브라우저에 저장시킨다. 이후 사용자가 요청을 보낼 때마다 브라우저는 이 세션 ID를 함께 보내고, WAS는 이 ID를 통해 해당 사용자의 정보(세션 객체)를 찾아 상태를 유지한다.

5. 스레드 관리 (Thread Management)

• 역할: 수많은 사용자의 동시 요청을 효율적으로 처리하기 위해 스레드 풀(Thread Pool)을 운영한다. CGI처럼 요청마다 프로세스를 생성하는 것이 아니라, 미리 만들어 둔 스레드 풀에서 스레드를 할당하여 요청을 처리하고, 처리가 끝나면 스레드를 다시 풀에 반납하여 재사용한다.

• 효과: 프로세스 생성/소멸에 따르는 오버헤드가 없어 서버 자원을 매우 효율적으로 사용할 수 있으며, 동시에 처리할 수 있는 요청의 수를 크게 늘려준다.

4장 더 나아가기 WAS 심화 탐구

기본적인 구조를 이해했다면, 이제 대규모 서비스를 위한 WAS의 고급 기능들을 살펴보자.

클러스터링 (Clustering) 과 로드 밸런싱 (Load Balancing)

• 클러스터링: 여러 대의 WAS 서버를 하나처럼 묶어 운영하는 기술.

• 목적:

  • 고가용성(High Availability): 한 대의 WAS 서버에 장애가 발생하더라도, 다른 서버가 즉시 서비스를 이어받아 중단을 막는다.

  • 확장성(Scalability): 서비스 사용량이 증가하면 WAS 서버를 추가로 증설하여 전체 시스템의 처리 용량을 손쉽게 늘릴 수 있다.

• 로드 밸런싱: 클러스터링된 WAS 서버들 앞단에 로드 밸런서(주로 웹 서버나 L4/L7 스위치 장비)를 두어, 들어오는 요청을 각 서버에 적절히 분배하는 기술이다. 이를 통해 모든 서버가 균등하게 일할 수 있도록 한다.

세션 클러스터링 (Session Clustering)

• 문제점: 로드 밸런싱 환경에서 사용자의 첫 번째 요청은 WAS 1번이, 두 번째 요청은 WAS 2번이 처리할 수 있다. 이때 사용자의 로그인 정보(세션)가 WAS 1번에만 저장되어 있다면, WAS 2번은 해당 사용자를 인식하지 못해 로그인이 풀리는 문제가 발생한다.

• 해결책:

  • 스티키 세션 (Sticky Session): 로드 밸런서가 특정 사용자의 요청은 항상 동일한 WAS 서버로만 보내도록 설정하는 방식. 구현은 간단하지만, 해당 서버가 다운되면 세션 정보가 유실되는 단점이 있다.

  • 세션 복제 (Session Replication): 클러스터 내의 모든 WAS 서버가 세션 정보를 실시간으로 공유(복제)하는 방식. 한 서버가 다운되어도 다른 서버에 세션 정보가 남아있어 서비스 연속성이 보장된다. 다만, 세션 정보를 복제하는 과정에서 네트워크 부하가 발생할 수 있다.

맺음말 동적 웹의 보이지 않는 지휘자

지금까지 우리는 WAS가 단순한 코드 실행기를 넘어, 동적인 웹 서비스를 가능하게 하는 정교하고 강력한 미들웨어임을 확인했다. 웹 서버와의 협력을 통해 성능과 안정성을 확보하고, 내부적으로는 컨테이너, 트랜잭션, 커넥션 풀 등 복잡한 기술들을 통해 개발자가 비즈니스 로직에만 집중할 수 있는 최적의 환경을 제공한다.

WAS는 화려한 사용자 인터페이스 뒤에서 묵묵히 모든 요청을 처리하고, 데이터를 지휘하며, 안정적인 서비스를 유지하는 ‘보이지 않는 지휘자’와 같다. 이 핸드북을 통해 WAS의 역할과 구조에 대한 깊이 있는 이해를 얻고, 더 나은 웹 시스템을 설계하고 개발하는 데 훌륭한 밑거름이 되기를 바란다.