WAS는 웹서버와 데이터베이스 사이에서 비즈니스 로직·트랜잭션·세션을 처리하는 미들웨어 계층으로, Java 환경에서는 서블릿과 JSP를 실행하는 표준 실행 환경을 가리킵니다.

Apache Tomcat은 서블릿·JSP를 실행하는 경량 WAS입니다. 풀스택 Jakarta EE 규격은 지원하지 않지만 대부분의 웹 애플리케이션에는 충분합니다.

상용 WAS를 오픈소스로 바꾸면 무엇이 좋아지는가?

라이선스·유지보수 비용을 줄여 총소유비용(TCO)을 낮추고 지원 종료(EOL) 리스크에서 벗어납니다. 세션·트랜잭션·성능은 자동화 튜닝과 모니터링, 세션 클러스터링으로 관리합니다.

WAS란 무엇인가 — 구조와 기능, 제품 선택 기준까지

Q: 웹서버와 WAS의 차이는?

웹서버는 정적 콘텐츠를 전달하는 1계층 관문이고, WAS는 로직을 실행하는 2계층입니다. 둘을 분리하면 계층별로 독립 확장과 보안 강화가 가능합니다.

WAS(웹 애플리케이션 서버)의 정의와 웹서버와의 차이, 서블릿 컨테이너·트랜잭션·커넥션 풀·세션 등 핵심 기능, Jakarta EE 표준과 Tomcat·JBoss 등 대표 제품 선택 기준, 오픈소스 WAS 현대화 방향까지 한 편에 정리했습니다.

WAS란 무엇인가 — 웹 애플리케이션 서버의 정의와 미들웨어에서의 위치

WAS는 웹 브라우저의 요청을 받아 애플리케이션 로직을 실행하고, 그 결과를 동적으로 만들어 돌려주는 서버 소프트웨어입니다. 정적인 HTML 파일을 그대로 전달하는 데서 그치지 않고, 사용자 인증·주문 처리·재고 조회 같은 비즈니스 로직을 실제로 수행한다는 점이 핵심입니다. 그래서 WAS를 흔히 “애플리케이션을 담아 실행하는 그릇”이라고 부릅니다.

WAS는 소프트웨어 계층에서 미들웨어(middleware, 응용 프로그램과 운영체제·데이터베이스 사이를 잇는 중간 계층 소프트웨어)에 속합니다. 애플리케이션 개발자는 트랜잭션 처리, 데이터베이스 연결 관리, 보안, 동시 접속 제어 같은 공통 기능을 매번 직접 구현하지 않습니다. 이런 공통 기능을 표준화된 형태로 제공하는 것이 WAS의 역할이며, 개발자는 비즈니스 로직에만 집중할 수 있게 됩니다. IBM은 애플리케이션 서버를 “애플리케이션 실행에 필요한 런타임 환경과 공통 서비스를 제공하는 소프트웨어 프레임워크”로 정의합니다.

Java 진영에서 WAS는 서블릿(Servlet)과 JSP를 실행하는 표준 실행 환경을 뜻하는 경우가 많습니다. 국내 엔터프라이즈·공공 시스템의 상당수가 Java 기반이기 때문에, 국내에서 “WAS”라고 하면 대개 Java EE(현 Jakarta EE) 규격을 따르는 애플리케이션 서버를 가리킵니다.

웹서버와 WAS는 어떻게 다른가 — 3-tier 아키텍처로 보는 역할 분담

가장 자주 나오는 혼동이 “웹서버와 WAS가 같은 것 아닌가”입니다. 둘은 역할이 분명히 다릅니다. 웹서버(Web Server)는 이미지·CSS·HTML 같은 정적 콘텐츠를 빠르게 전달하고, 동적 요청은 뒤쪽 WAS로 넘기는 관문입니다. Apache HTTP Server나 Nginx가 대표적입니다. WAS는 그 넘겨받은 요청에서 실제 로직을 실행하고 데이터베이스와 통신해 결과를 만들어 냅니다.

이 구분은 전형적인 3-tier 아키텍처(3계층 구조)로 정리됩니다.

1계층 — 웹서버: 정적 자원 처리, 요청 분배, SSL 종료, 부하 분산. 외부에 직접 노출되는 관문 역할입니다.
2계층 — WAS: 서블릿·JSP 실행, 비즈니스 로직 수행, 트랜잭션·세션 관리. 시스템의 두뇌에 해당합니다.
3계층 — 데이터베이스(DB): 데이터의 영구 저장과 조회를 담당합니다.

웹서버와 WAS를 분리하는 이유는 성능과 보안 때문입니다. 정적 요청은 가벼운 웹서버가 대량으로 빠르게 처리하고, 무거운 동적 로직은 WAS가 전담하면 각 계층을 독립적으로 확장할 수 있습니다. 또한 WAS를 내부망에 두고 웹서버만 외부에 노출하면 공격 표면을 줄일 수 있습니다. 다만 Apache Tomcat처럼 정적 파일 전송과 서블릿 실행을 한 프로세스에서 모두 처리하는 제품도 있어, 소규모 시스템에서는 웹서버 없이 WAS 단독으로 운영하기도 합니다. 규모가 커지면 앞단에 웹서버를 두어 역할을 나누는 구성이 표준입니다.

WAS의 심장부 — 서블릿 컨테이너·트랜잭션·커넥션 풀·세션 관리

WAS가 “그릇” 이상의 값을 하는 이유는 네 가지 핵심 기능에 있습니다. 이 기능들을 이해하면 왜 상용 WAS와 경량 WAS의 가격·성능 차이가 생기는지도 함께 보입니다.

첫째, 서블릿 컨테이너(Servlet Container)입니다. 서블릿은 웹 요청을 처리하는 Java 프로그램이고, 컨테이너는 그 서블릿의 생성·실행·소멸 전 과정을 관리하는 실행 환경입니다. 요청이 들어오면 컨테이너가 스레드를 할당하고, 서블릿을 호출하며, 응답을 반환한 뒤 자원을 회수합니다. 개발자가 스레드 관리나 요청 파싱을 직접 하지 않아도 되는 것은 컨테이너가 이 일을 대신하기 때문입니다.

둘째, 트랜잭션 관리(Transaction Management)입니다. 하나의 업무가 여러 데이터베이스 작업으로 나뉠 때, WAS는 이 작업들을 하나의 묶음으로 처리해 “전부 성공하거나 전부 취소”되도록 보장합니다. 계좌 이체에서 출금과 입금이 반드시 함께 성사돼야 하듯, 중간에 오류가 나면 이미 실행한 작업을 되돌립니다. 여러 데이터베이스에 걸친 분산 트랜잭션까지 처리하는 수준은 상용·풀스택 WAS의 대표적인 강점입니다.

셋째, 커넥션 풀(Connection Pool)입니다. 데이터베이스 연결을 매 요청마다 새로 맺고 끊으면 비용이 큽니다. 커넥션 풀은 연결을 미리 여러 개 만들어 두고 재사용하는 기법으로, 응답 속도와 처리량을 크게 좌우합니다. 커넥션 풀 크기를 잘못 잡으면 접속 폭주 시 대기가 쌓여 시스템이 멈추기도 하므로, 운영 튜닝에서 가장 먼저 점검하는 지점입니다.

넷째, 세션 관리(Session Management)입니다. WAS는 사용자별 로그인 상태나 장바구니 같은 정보를 세션으로 유지합니다. 서버가 한 대일 때는 단순하지만, 여러 대로 확장하면 “어느 서버에 접속해도 같은 세션을 유지하는” 문제가 생깁니다. 이를 해결하는 세션 클러스터링(session clustering)은 이중화 구성의 필수 요소이며, WAS 제품의 안정성을 가르는 핵심 기술입니다.

Jakarta EE 표준과 WAS — 스펙 준수 수준이 제품 선택을 가른다

Java 기반 WAS를 이해하려면 Jakarta EE(자카르타 EE, 옛 Java EE)를 알아야 합니다. Jakarta EE는 서블릿, JSP, JPA, 트랜잭션(JTA), 메시징(JMS) 등 엔터프라이즈 애플리케이션에 필요한 표준 규격의 모음입니다. Oracle이 관리하던 Java EE가 2017년 이후 Eclipse Foundation으로 이관되면서 이름이 Jakarta EE로 바뀌었습니다.

WAS 제품은 이 표준을 어느 수준까지 구현하느냐에 따라 성격이 갈립니다. Eclipse Foundation은 전체 플랫폼 규격을 모두 구현한 제품에 “Jakarta EE 호환(Compatible)” 인증을 부여합니다. 전체 플랫폼을 구현한 제품을 흔히 풀스택(full-stack) WAS라 부르고, 서블릿·JSP 같은 웹 규격만 구현한 제품을 웹 컨테이너(web container) 또는 경량 WAS라고 부릅니다.

이 차이는 제품 선택에 직접 영향을 줍니다. 애플리케이션이 분산 트랜잭션이나 메시징 같은 고급 규격을 쓴다면 풀스택 WAS가 필요합니다. 반대로 대부분의 웹 애플리케이션이 서블릿·JSP 수준만 사용한다면 경량 WAS로 충분하며, 이 경우 상용 풀스택 WAS의 라이선스 비용은 과잉 투자가 됩니다. 실제로 많은 시스템이 표준의 일부만 사용하면서도 관행적으로 값비싼 상용 WAS를 유지하고 있습니다. 그래서 “우리 애플리케이션이 실제로 어느 규격까지 쓰는가”를 점검하는 일이 비용 최적화의 출발점입니다.

대표 WAS 제품군 한눈에 보기 — Tomcat·JBoss·WebLogic·WebSphere·JEUS·OPENMARU iAP

시장에는 오픈소스·상용·국산 WAS가 공존합니다. 각 제품의 성격을 표로 정리하면 다음과 같습니다.

제품	구분	규격 수준	라이선스	특징
Apache Tomcat	오픈소스	웹 컨테이너(서블릿·JSP)	무상	가장 널리 쓰이는 경량 WAS. 단순·안정
WildFly	오픈소스	풀스택 Jakarta EE	무상	Red Hat이 후원하는 커뮤니티 풀스택 WAS
JBoss EAP	상용	풀스택 Jakarta EE	구독	WildFly 기반, Red Hat의 상용 기술 지원 포함
Oracle WebLogic	상용	풀스택 Jakarta EE	상용 라이선스	대형 엔터프라이즈에서 오래 쓰인 풀스택
IBM WebSphere	상용	풀스택 Jakarta EE	상용 라이선스	경량 변형(Liberty)도 제공
TmaxSoft JEUS	국산 상용	풀스택 Jakarta EE	상용 라이선스	국내 공공·금융에서 점유율 높음
OPENMARU iAP	국산 상용	풀스택 Jakarta EE	상용 라이선스	WAS에 세션 클러스터링·APM·운영관리를 묶은 국산 통합 플랫폼

핵심은 “풀스택이냐 경량이냐”와 “상용 라이선스냐 오픈소스냐”라는 두 축입니다. Tomcat은 라이선스 비용이 없고 구조가 단순해 가장 많이 채택되지만 풀스택 규격은 지원하지 않습니다. JBoss EAP·WebLogic·WebSphere·JEUS는 풀스택 규격과 상용 지원을 제공하는 대신 비용이 높습니다. 특히 WebLogic·WebSphere 같은 상용 제품은 라이선스 비용과 지원 종료(EOL) 부담이 커지면서, 오픈소스 WAS로의 현대화 수요가 꾸준히 늘고 있습니다.

이 구도에서 눈여겨볼 국산 선택지가 통합 WAS 플랫폼인 OPENMARU iAP입니다. 자세한 성격은 아래 현대화 섹션에서 다룹니다.

WAS를 운영할 때 부딪히는 다섯 가지 — 성능·세션·이중화·장애·비용

제품을 고르는 것보다 더 오래 이어지는 것이 운영입니다. WAS 운영에서 반복적으로 부딪히는 이슈는 크게 다섯 가지이며, 각 주제는 이 필러와 연결된 심화 글에서 더 깊이 다룹니다.

성능 튜닝: JVM(Java 가상 머신) 힙 크기와 GC(가비지 컬렉션, 사용하지 않는 메모리 회수) 정책, 스레드 풀·커넥션 풀 크기를 잘못 잡으면 응답 지연과 메모리 누수로 이어집니다.
세션 클러스터링: 서버를 여러 대로 늘릴 때 세션을 어떻게 공유·외부화할지가 무중단 운영을 좌우합니다.
이중화(HA): 한 대가 죽어도 서비스가 멈추지 않도록 이중화 아키텍처를 어떻게 설계하느냐의 문제입니다.
장애 대응: 장애의 원인은 대개 애플리케이션·WAS·DB 중 어디인지가 불분명합니다. 병목 구간을 빠르게 특정하는 체계가 필요합니다.
라이선스 비용: 상용 WAS의 라이선스와 유지보수 비용은 코어 수에 비례해 늘어나며, 총소유비용(TCO)에서 큰 비중을 차지합니다.

이 다섯 이슈는 결국 하나의 질문으로 모입니다. “지금 쓰는 WAS가 규모·비용·안정성 측면에서 여전히 최선인가.” 상용 WAS의 지원 종료가 다가오거나 라이선스 갱신 시점이 오면, 이 질문은 미룰 수 없는 결정 사항이 됩니다.

더 읽어보기 — WAS 심화 시리즈

이 필러에서 요약한 주제는 다음 심화 글로 이어집니다(순차 발행).

WAS와 웹서버의 차이 — 3-tier 구성 실전
Tomcat vs 상용 WAS — 언제 무엇을 선택할까
국내 WAS 시장 지형 — 상용·오픈소스·국산
WAS 성능 튜닝 — JVM·GC·커넥션 풀 기준
WAS 세션 클러스터링 — 세션 외부화 설계
WAS 이중화(HA) 아키텍처
WAS 장애 대응 가이드
지원 종료(EOL) 미들웨어 마이그레이션
공공부문 WAS 도입 기준
WAS 라이선스 비용과 TCO 절감

상용 WAS의 부담을 줄이는 길 — 오픈소스 WAS 현대화와 OPENMARU

WAS 구조를 이해하고 나면 다음 판단이 선명해집니다. 대부분의 애플리케이션은 실제로 서블릿·JSP 수준만 사용하는데도, 관행적으로 값비싼 상용 WAS를 유지하는 경우가 많습니다. 상용 WAS의 지원 종료와 라이선스 갱신은 이 관행을 재검토할 자연스러운 계기가 됩니다.

이 전환의 걸림돌은 대부분 기술이 아니라 운영 리스크입니다. “오픈소스 WAS로 옮기면 세션·트랜잭션·성능이 상용만큼 안정적으로 유지될까”라는 불안이 결정을 늦춥니다. OPENMARU는 이 지점에서 오픈소스 WAS(Apache Tomcat·JBoss/WildFly) 기반의 현대화를 지원합니다. 설치·구성·튜닝을 자동화하고 설치 보고서를 자동 생성해 이관 과정의 불확실성을 줄이며, 시스템 진단 서비스로 장애 원인과 성능 병목을 특정합니다.

이 여러 요소를 하나로 묶은 제품이 OPENMARU iAP(Intelligent Application Platform)입니다. iAP는 Web/WAS 런타임에 세션 클러스터링, 성능관리(APM), 운영관리를 결합한 국산 통합 WAS 플랫폼으로, 상용 WAS의 고가 라이선스와 벤더 종속에서 벗어나면서도 “WAS만으로는 운영이 어려워 서드파티 제품을 여러 개 붙여야 하던” 비효율을 단일 플랫폼으로 대체하는 것을 목표로 합니다. 상용 WAS의 단종(EOL) 대응, 세션 유실 방지, 성능관리 일원화가 핵심입니다. iAP는 엔터프라이즈와 공공의 기존 서버·가상화(VM) 환경을 대상으로 하며, 과학기술정보통신부 혁신제품으로 지정되고 조달청 디지털서비스몰에 등록되어 공공기관이 수의계약으로 도입할 수 있습니다.

플랫폼을 구성하는 핵심 요소는 다음과 같습니다. OPENMARU APM은 애플리케이션과 WAS를 100% 트랜잭션 단위로 모니터링해 장애 구간을 빠르게 찾아냅니다. 여기서 APM은 애플리케이션 성능 관리(Application Performance Management)를 뜻하며, 단순 지표 수집을 넘어 어느 요청이 어디서 느려졌는지 추적하는 관리 체계입니다. 세션 외부화가 필요한 이중화 구성에서는 OPENMARU Cluster가 세션 클러스터링을 담당해, 여러 WAS로 확장해도 사용자 세션이 끊기지 않도록 합니다. 운영 현황은 OPENMARU Dashboard로 한눈에 확인할 수 있습니다.

정리하면, OPENMARU iAP를 통한 WAS 현대화의 실익은 세 가지로 요약됩니다. 첫째, 상용 라이선스와 유지보수 비용, 서드파티 보완 제품 비용을 함께 줄여 총소유비용(TCO)을 낮춥니다. 둘째, 지원 종료로 인한 기술 부채와 보안 리스크에서 벗어납니다. 셋째, 세션·성능관리·운영관리를 하나로 묶어 운영 부담을 줄입니다. WAS가 무엇인지 이해하는 일은 결국 “지금 쓰는 미들웨어가 여전히 최선인가”를 스스로 판단하는 출발점입니다.

자주 묻는 질문 (FAQ)

Q. WAS란 무엇인가요?
WAS(Web Application Server)는 웹 요청을 받아 애플리케이션 로직을 실행하고 결과를 동적으로 만들어 돌려주는 서버 소프트웨어입니다. 웹서버와 데이터베이스 사이에서 비즈니스 로직·트랜잭션·세션을 처리하는 미들웨어 계층입니다. Java 환경에서는 서블릿과 JSP를 실행하는 표준 실행 환경을 가리킵니다.

Q. 웹서버와 WAS의 차이는 무엇인가요?
웹서버는 이미지·HTML 같은 정적 콘텐츠를 빠르게 전달하는 관문이고, WAS는 넘겨받은 요청의 로직을 실제로 실행하는 계층입니다. 3-tier 구조에서 웹서버는 1계층, WAS는 2계층, 데이터베이스는 3계층을 맡습니다. 둘을 분리하면 각 계층을 독립적으로 확장하고 보안을 강화할 수 있습니다.

Q. Tomcat도 WAS인가요?
그렇습니다. Apache Tomcat은 서블릿·JSP를 실행하는 경량 WAS(웹 컨테이너)입니다. 다만 분산 트랜잭션·메시징 같은 풀스택 Jakarta EE 규격은 지원하지 않습니다. 대부분의 웹 애플리케이션이 서블릿·JSP 수준만 사용하기 때문에, Tomcat만으로 충분한 경우가 많습니다.

Q. 상용 WAS를 오픈소스로 바꾸면 무엇이 좋아지나요?
라이선스와 유지보수 비용을 줄여 총소유비용(TCO)을 낮추고, 지원 종료(EOL)로 인한 기술 부채와 보안 리스크에서 벗어납니다. 관건은 세션·트랜잭션·성능을 상용만큼 안정적으로 유지하는 것이며, 설치·튜닝 자동화와 트랜잭션 모니터링, 세션 클러스터링으로 이 리스크를 관리할 수 있습니다.

Q. WAS 세션 클러스터링은 왜 필요한가요?
WAS를 여러 대로 확장하면 사용자가 어느 서버에 접속하든 같은 로그인·장바구니 상태를 유지해야 합니다. 세션 클러스터링은 세션을 서버 간에 공유하거나 외부 저장소로 분리해, 한 대가 죽어도 세션이 끊기지 않게 합니다. 무중단 이중화 운영의 필수 요소입니다.

참고 리소스

OPENMARU · CNCF · MSAP.ai (자사)
– JBoss EAP와 WildFly 차이점 비교 분석 — OPENMARU
– Apache Tomcat 설치의 모든 것 — OPENMARU
– Apache·Tomcat·JBoss·WildFly 설치 구성 가이드 — OPENMARU
– 시스템 진단 서비스 — 장애 해결과 성능 개선 — OPENMARU
– Introduction to JBoss — OPENMARU 기술문서
– 비싼 WAS의 시대는 끝났다 — 클라우드 네이티브 최적화 WAS로 전환 — CNCF
– 단종된 WebLogic 환경의 기술 부채 해소와 WAS 현대화 — CNCF
– JBoss·Tomcat·JEUS·WebLogic·WebSphere 비교 — CNCF
– MSA 기초 — 마이크로서비스 아키텍처의 핵심 개념 — MSAP.ai

OPENMARU iAP — 오픈소스 통합 WAS 플랫폼 (자사)
– 조달물품 OPENMARU iAP — 제품 소개
– 지능형 애플리케이션 플랫폼 OPENMARU iAP — 과기정통부 혁신제품 선정
– Web/WAS 비용 절감의 해법 — OPENMARU iAP 백서
– 지능형 애플리케이션 플랫폼 OPENMARU iAP 브로슈어

표준·공식 문서 (외부)
– What is an Application Server? — IBM
– What Is Middleware? — IBM
– Jakarta EE Platform Specification — Eclipse Foundation
– Jakarta Servlet Specification — Eclipse Foundation
– Jakarta EE Compatible Products — Eclipse Foundation
– Apache Tomcat 공식 사이트
– Introduction to Red Hat JBoss EAP 8.0 — Red Hat
– WebSphere Application Server Liberty overview — IBM

문의

WAS 현대화와 오픈소스 전환, 운영 모니터링이 필요하시면 OPENMARU가 도와드립니다.

OPENMARU iAP 제품 알아보기 — https://www.openmaru.io/iap/
OPENMARU APM 무료 체험 — https://www.openmaru.io/openmaru-apm/
도입 레퍼런스 확인 — https://www.openmaru.io/clients/
오픈소스 WAS·Red Hat 제품 문의 — https://www.openmaru.io/request-for-quote/

Featured image alt 후보: WAS(웹 애플리케이션 서버)의 3-tier 구조와 대표 제품군을 정리한 OPENMARU 기술 배너.