IT 인프라의 패러다임이 물리 서버와 가상 머신(VM)을 넘어 클라우드 네이티브로 급격히 전환되면서, 애플리케이션의 심장과도 같은 웹서버와 WAS (Web Application Server) 에 요구되는 기능 또한 근본적으로 변화하고 있습니다. 과거 온프레미스 환경에서 강력한 기능으로 무장했던 무겁고 거대한 (Monolithic) WAS는 더 이상 현대적인 MSA (Microservices Architecture) 와 쿠버네티스 환경의 민첩성을 따라가지 못하고 있습니다.

이 글에서는 클라우드 네이티브 시대를 맞이하여 전통적인 웹서버/WAS의 기능들이 왜 더 이상 유효하지 않게 되었는지, 그리고 앞으로 어떤 새로운 기능들이 핵심 역량으로 자리 잡게 될 것인지 심도 있게 살펴보고자 합니다. 이 글은 MSA와 쿠버네티스 환경을 처음 접하시거나, 기술 도입을 고민하는 의사결정자분들께서 현대적인 아키텍처의 흐름을 이해하는 데 훌륭한 가이드가 될 것입니다.

과거에는 WAS 자체의 강력하고 통합된 기능이 큰 장점이었습니다. 하지만 이제는 그 기능들이 오히려 클라우드 네이티브환경의 유연성과 확장성을 저해하는 족쇄가 되기도 합니다. 우리가 당연하게 여겼던 기능들이 왜 더 이상 필요하지 않게 되었는지 살펴보겠습니다.

전통적인 WAS 환경에서 Admin Console은 관리자의 가장 친한 친구와도 같았습니다. 직관적인 그래픽 인터페이스(GUI)를 통해 애플리케이션 배포, 데이터 소스 설정, 스레드 풀 조정 등 거의 모든 설정을 처리할 수 있었습니다. 소수의 안정적인 서버를 운영하는 환경에서는 매우 효율적인 방식이었습니다.

WebLogic Admin Console

JBoss Admin Console

WebSphere Admin Console

JEUS Web Admin

하지만 쿠버네티스와 컨테이너 환경은 근본적으로 다릅니다. 이 환경에서는 수십, 수백, 심지어 수천 개의 컨테이너가 트래픽에 따라 동적으로 생성되고 소멸합니다. 관리자가 일일이 Admin Console에 접속하여 각 컨테이너를 설정하는 것은 물리적으로 불가능하며, 그래서도 안됩니다.

현대적인 환경에서는 IaC(Infrastructure as Code, 코드형 인프라) 와 GitOps 가 그 자리를 대체합니다. 모든 인프라 구성과 애플리케이션 설정은 YAML 같은 텍스트 파일로 정의되고, Git과 같은 버전 관리 시스템을 통해 관리됩니다. 변경 사항이 발생하면, 쿠버네티스와 같은 컨테이너 오케스트레이션 도구가 이 설정 파일을 읽어 자동으로 전체 시스템에 일관되게 적용합니다.

이러한 선언적(Declarative) 구성 관리 방식은 다음과 같은 압도적인 이점을 제공합니다.

• 자동화와 재현성: 수작업으로 인한 실수를 원천적으로 차단하고, 언제든 동일한 환경을 코드로부터 재현할 수 있습니다.
• 확장성: 수천 개의 컨테이너에도 동일한 설정을 일관되게 적용하는 것이 가능합니다.
• 가시성과 추적: 모든 변경 사항이 Git에 기록되므로, 누가, 언제, 무엇을 변경했는지 명확하게 추적하고 문제 발생 시 이전 버전으로 쉽게 롤백할 수 있습니다.

결론적으로, Admin Console의 ‘클릭 기반’ 관리는 동적이고 자동화된 클라우드 네이티브 환경의 철학과 맞지 않습니다. 이제 WAS는 GUI가 아닌, 코드와 자동화 도구를 통해 제어되는 것이 표준입니다.

과거 고가용성(High Availability)을 위해 WAS가 제공하는 가장 중요한 기능 중 하나는 세션 클러스터링이었습니다. 여러 WAS 인스턴스가 서로 세션 데이터를 복제하여 특정 서버에 장애가 발생하더라도 사용자의 로그인 상태나 장바구니 정보가 유지되도록 보장하는 기능이었죠.

하지만 이 방식 역시 컨테이너 환경의 핵심 특징인 탄력적 확장(Auto Scaling) 과 무상태(Stateless) 원칙에 정면으로 위배됩니다. 컨테이너 환경에서는 트래픽이 몰리면 순식간에 수십 개의 WAS 컨테이너(Pod)가 새로 생성되고, 트래픽이 줄면 가차 없이 사라집니다. 이렇게 수명이 짧고 가변적인 컨테이너들끼리 세션 데이터를 복제하는 것은 매우 비효율적이고 복잡합니다. 새로 생성된 컨테이너가 기존 세션을 이어받기 위한 동기화 과정은 시스템에 큰 부하를 주며, 스케일링 속도를 저해합니다.

따라서 현대적인 아키텍처에서는 WAS를 무상태(Stateless) 로 설계하는 것을 강력하게 권장합니다. 즉, WAS 자체는 사용자의 상태 정보(세션)를 저장하지 않고 오직 비즈니스 로직 처리만 담당합니다. 그렇다면 세션은 어디에 저장할까요? 바로 외부 분산 캐시(External Distributed Cache) 입니다.

OPENMARU Cluster 와 같은 인메모리 기반의 분산 캐시 솔루션을 별도로 구축하고, 모든 WAS 컨테이너는 이곳에 세션을 저장하고 조회합니다. 이러한 아키텍처는 다음과 같은 장점을 가집니다.

• 자유로운 스케일링: WAS 컨테이너는 상태를 갖지 않으므로, 언제든지 부담 없이 생성하거나 제거할 수 있습니다. 이는 신속한 오토스케일링을 가능하게 합니다.
• 높은 안정성: 세션 저장소가 WAS와 분리되어 있기 때문에, WAS 컨테이너에 장애가 발생해도 세션 데이터는 안전하게 보존됩니다.
• 중앙 집중식 관리: 세션 데이터가 한 곳에서 관리되므로, 데이터 일관성을 유지하고 모니터링하기 용이합니다.

이제 WAS는 세션 클러스터링이라는 무거운 짐을 내려놓고, 외부의 전문화된 솔루션과 협력하여 더 가볍고 유연한 구조를 지향해야 합니다.

일부 WAS 제품은 ‘도메인 모드’와 같은 기능을 통해 여러 WAS 인스턴스를 하나의 그룹으로 묶어 중앙에서 구성을 배포하고 관리하는 기능을 제공했습니다. 이는 여러 서버의 설정을 일관되게 유지하기 위한 매우 유용한 기능이었습니다.

하지만 이 역할은 이제 명백히 컨테이너 오케스트레이션 도구의 영역이 되었습니다. 특히 사실상의 표준(De facto standard)으로 자리 잡은 쿠버네티스는 WAS의 도메인 모드가 하던 일을 훨씬 더 정교하고 범용적인 방식으로 수행합니다.

• 구성 관리: 쿠버네티스의 ConfigMap과 Secret은 애플리케이션의 설정 정보나 민감한 데이터를 WAS 컨테이너와 분리하여 관리하고, 필요할 때 동적으로 주입해 줍니다.
• 그룹 관리 및 배포: Deployment나 StatefulSet과 같은 쿠버네티스 오브젝트는 여러 개의 WAS 컨테이너 그룹을 정의하고, 롤링 업데이트나 카나리 배포와 같은 정교한 배포 전략을 손쉽게 구현하도록 돕습니다.
• 리소스 관리: WAS의 스레드 풀, 힙 메모리 설정 등은 이제 WAS 자체 설정보다는 쿠버네티스의 Resource 요청(requests) 및 제한(limits)을 통해 관리되며, 이는 전체 클러스터의 리소스를 효율적으로 사용하는 데 기여합니다.

특정 WAS 벤더에 종속된 그룹핑 기능 대신, 쿠버네티스라는 표준화된 플랫폼을 통해 모든 종류의 워크로드를 동일한 방식으로 관리하는 것이 훨씬 효율적이고 이식성이 높습니다.

과거의 WAS는 운영체제(OS) 위에 직접 설치되는 무거운 소프트웨어였습니다. 설치 과정도 복잡했고, OS나 다른 애플리케이션과의 의존성 문제도 빈번했습니다.

컨테이너 시대의 WAS는 더 이상 독립적인 ‘프로세스’가 아니라, 애플리케이션과 함께 패키징되는 하나의 ‘런타임 라이브러리’에 가깝습니다. 개발자는 자신의 애플리케이션 코드와 이를 실행할 경량 WAS를 포함하여 컨테이너 이미지를 만듭니다. 이 이미지는 그 자체로 완결된 실행 단위가 됩니다.

이러한 변화는 ‘Build once, run anywhere’라는 컨테이너의 핵심 철학을 실현합니다. 개발자의 로컬 환경에서 테스트된 컨테이너 이미지는 개발, 테스트, 운영 환경 어디에서든 OS나 라이브러리 버전에 상관없이 동일하게 동작함을 보장합니다. 이는 고질적인 “제 PC에서는 잘 됐는데요” 문제를 해결하는 강력한 해법입니다.

과거에는 WAS를 개별 서버에 설치하고 프로비저닝하는 과정이 필요했습니다. 시스템 관리자는 OS에 적합한 패키지를 내려받아 설치한 뒤, 환경변수와 JVM 옵션을 설정하고, 애플리케이션을 배포할 디렉토리를 만드는 작업을 반복했습니다. 설치형 WAS는 버전 업그레이드와 패치 적용 또한 시스템 단위로 진행해야 했기 때문에 유지보수 부담이 컸습니다.

그러나 클라우드 네이티브 환경에서 이러한 설치·프로비저닝 개념은 의미를 잃었습니다. 애플리케이션과 WAS 런타임은 하나의 컨테이너 이미지에 빌드 타임에 묶여 배포되며, 쿠버네티스나 다른 오케스트레이터가 이 이미지를 클러스터 전체에 스케줄링해 줍니다. 설치형 제품을 미리 준비할 필요 없이 이미지 레지스트리에서 내려받아 실행하는 즉시 기동되는 구조입니다.

• 이미지 기반 패키징

컨테이너 이미지 안에는 애플리케이션 코드와 WAS 런타임, 필요한 라이브러리까지 모두 포함되어 있어 추가 설치가 필요 없습니다. 개발 단계에서 동일한 이미지를 빌드하고 검증하면 운영 환경에서도 그대로 사용할 수 있습니다.

• 인프라 자동화와 확장

컨테이너 오케스트레이터는 Deployment 나 StatefulSet 같은 리소스를 통해 필요한 만큼의 복제본을 자동으로 생성합니다. 수평 확장과 롤링 업데이트가 기본 기능으로 제공되기 때문에 서버를 추가로 프로비저닝하는 작업 없이도 트래픽 변화에 대응할 수 있습니다.

• 리소스 관리의 표준화

컨테이너는 CPU·메모리 요청/제한 값을 명시하여 실행되며, 클러스터 전체의 리소스를 효율적으로 사용하도록 자동 배치됩니다. 과거처럼 서버마다 JVM 힙 사이즈를 조정하거나 OS 커널 파라미터를 수정할 필요가 없습니다.

특정 WAS 벤더가 제공하던 설치·프로비저닝 기능은 쿠버네티스라는 표준 플랫폼에서 모든 종류의 워크로드를 동일한 방식으로 관리하는 것이 훨씬 효율적이며 일관성이 높습니다.

과거에는 WAS 자체의 강력하고 통합된 기능이 큰 장점이었습니다. 하지만 이제는 그 기능들이 오히려 클라우드 네이티브환경의 유연성과 확장성을 저해하는 족쇄가 되기도 합니다. 우리가 당연하게 여겼던 기능들이 왜 더 이상 필요하지 않게 되었는지 살펴보겠습니다.

마이크로서비스 아키텍처(MSA) 환경에서는 수많은 서비스가 필요에 따라 빠르게 확장 및 축소되어야 합니다. 이를 위해 WAS는 적은 메모리와 CPU를 사용하며, 컨테이너 시작 시 매우 빠른 부팅 시간을 가져야 합니다. 과거의 복잡하고 무거운 기능을 모두 포함한 전통적인 WAS는 이러한 요구사항을 충족하기 어렵습니다.

이제 WAS는 애플리케이션 실행을 위한 최소한의 런타임 환경을 제공하는 역할에 집중합니다. MicroProfile이나 Jakarta EE Core Profile처럼 필요한 기능만 선택적으로 포함하는 모듈화된 구조를 통해, 개발자가 비즈니스 로직에만 집중할 수 있도록 가볍고 유연한 런타임이 요구됩니다.

• 피처 기반 구조: Open Liberty와 같이 필요한 기능(Feature)만 선택하여 런타임을 구성함으로써 경량화를 달성합니다.
• 애플리케이션 중심 환경: Spring Boot, Quarkus, Micronaut 같은 마이크로서비스 프레임워크와 시너지를 내는 데 집중합니다.

모든 WAS 제품은 이제 컨테이너 환경을 기본으로 상정하고, 쿠버네티스와의 원활한 통합 및 관리 기능을 제공해야 합니다. 이는 단순히 컨테이너 이미지를 제공하는 것을 넘어, 쿠버네티스 생태계 안에서 효율적으로 운영될 수 있는 구조를 의미합니다.

• 배포 자동화: WebLogic Toolkit이나 JBoss EAP Operator와 같은 쿠버네티스 오퍼레이터를 통해 도메인 생성, 롤링 업데이트, 오토스케일링 같은 복잡한 운영 작업을 자동화합니다.
• 설정 관리의 분리: 애플리케이션 설정이나 민감한 데이터는 쿠버네티스의 ConfigMap과 Secret을 통해 컨테이너 이미지와 분리하여 관리하고, 필요할 때 동적으로 주입합니다.
• 효율적인 컨테이너 이미지: Dockerfile을 통한 빌드가 용이해야 하며, 작고 효율적인 컨테이너 이미지를 생성할 수 있어야 합니다.

과거 WAS가 제공하던 내장(In-Memory) 세션 클러스터링 기능은 컨테이너 환경에서 비효율적입니다. Pod가 재시작되거나 다른 노드로 이전될 때 세션이 유실될 위험이 크며, 상태를 가지는(Stateful) 서비스는 스케일링에 큰 제약을 받습니다.

클라우드 네이티브 환경에서는 대부분 무상태(Stateless) 아키텍처를 지향합니다. 세션 데이터가 필요한 경우, WAS 자체 기능에 의존하기보다 OPENMARU Cluster 와 같은 외부 분산 캐시나 데이터베이스에 세션을 저장하고 공유하는 방식이 권장됩니다. 이를 통해 WAS는 상태 없이 자유롭게 확장 및 축소될 수 있습니다.

분산된 마이크로서비스 환경에서는 시스템의 상태를 통합적으로 파악하고 문제를 추적하는 Observability 확보가 매우 중요합니다. WAS는 이제 분산 트레이싱, 메트릭 수집, 헬스 체크 기능을 표준화된 방식으로 기본 제공해야 합니다.

운영자는 이러한 표준 기술을 통해 여러 종류의 애플리케이션 상태를 하나의 통합된 대시보드에서 모니터링할 수 있습니다.

• 표준 API 지원: MicroProfile의 Health, Metrics, Telemetry API 등을 통해 애플리케이션의 상태 정보를 표준화된 형식으로 외부에 노출합니다.
• 모니터링 도구 연동: OPENMARU Observability 통합 모니터링 시스템과 손쉽게 연동됩니다.

GUI 기반의 수동 설정 및 관리 방식은 CI/CD 파이프라인과 GitOps 환경에 적합하지 않습니다. 이제 모든 WAS 설정과 관리는 API를 통해 자동화될 수 있어야 하며, 선언적(Declarative) 설정 파일을 통해 인프라를 코드로 관리할 수 있어야 합니다.

또한, 컨테이너 시대에는 보안 패치 등을 위해 애플리케이션 서버를 지속적으로 재배포해야 하므로, 설치 및 패치 관리의 자동화가 중요합니다. JBoss EAP 8의 설치 관리자나 WebLogic의 단순화된 패치 번들처럼 운영자가 손쉽게 업데이트를 적용할 수 있는 기능이 요구됩니다.

Java 플랫폼이 발전함에 따라 WAS 역시 최신 기술을 빠르게 지원하여 성능을 극대화해야 합니다. 특히 대규모 동시 접속을 효율적으로 처리하기 위한 Java의 가상 스레드(Virtual Thread) 지원은 향후 WAS의 핵심 경쟁력이 될 것입니다.

Tomcat 11이 StandardVirtualThreadExecutor를 통해 요청을 가상 스레드로 처리하여 높은 처리량을 달성한 것처럼, 다른 WAS 제품들도 이러한 새로운 Java 기능을 적극적으로 도입해야 합니다.

요약하면, 클라우드 네이티브 시대의 웹서버와 WAS는 더 이상 중앙 콘솔에서 수작업으로 관리되는 거대 소프트웨어가 아닙니다. 쿠버네티스와 오케스트레이션 플랫폼이 배포·확장·구성 관리를 담당하고, 세션 관리는 외부 분산 캐시를 통해 무상태로 구현됩니다. WAS는 컨테이너 안에서 애플리케이션과 함께 패키징되어 빠르게 시작되고, 가벼운 런타임이 요구되며, AI 기반 운영 도구와 서비스 메시 등 주변 인프라와 긴밀하게 통합됩니다.

마이크로서비스와 클라우드 환경에서는 수백~수천 개의 인스턴스와 무수한 로그·메트릭·트레이스가 생성됩니다. 사람이 모든 이벤트를 분석하고 장애를 진단하는 것은 불가능에 가깝습니다. AIOps와 LLM 기반 시스템은 이러한 문제를 해결하기 위해 등장했습니다. 팔로알토 네트웍스의 AIOps 사례는 머신러닝이 이벤트 상관 관계 분석, 자동화된 근본 원인 분석, 예측 분석, 용량 계획, 사전 모니터링 등을 수행한다고 설명합니다. 또한 머신러닝은 과거 리소스 사용 패턴을 분석해 미래의 수요를 예측하고, 이상 징후를 감지하여 운영자가 장애를 경험하기 전에 조치할 수 있도록 돕습니다.

앞으로의 웹서버와 WAS는 로그와 메트릭뿐 아니라 코드와 구성까지 모델에 학습시켜, 장애 발생 시 LLM이 로그를 요약하고 원인을 추론하며 적절한 조치 방법을 추천하는 형태로 진화할 것입니다. ChatOps 방식으로 운영자가 자연어로 시스템 상태를 묻고, LLM이 모니터링 데이터를 분석해 응답하는 형태도 가능해집니다. 이는 인력의 부담을 줄이는 동시에, 복잡한 시스템에서 빠르고 정확한 대응을 가능하게 합니다.

첨부된 표는 대표적인 WAS 제품을 클라우드 네이티브‧MSA 관점에서 비교한 것입니다.

• JBoss EAP/WildFly

오픈소스 기반으로 여전히 무겁다는 단점이 있습니다. WildFly의 기동 시간은 비교적 빠르며 쿠버네티스용 오퍼레이터가 있어 친화성이 향상됐지만, 기존 JBoss CLI를 기반으로 한 Admin Console이 필요합니다.

• Oracle WebLogic

기동 속도가 느리고 쿠버네티스 친화성이 낮으며 무거운 관리 콘솔을 사용해야 합니다. 기존 엔터프라이즈 레거시 시스템과의 호환성은 뛰어나지만, 클라우드 네이티브 환경에서 사용하기에는 적합하지 않고 라이선스 비용 부담도 큽니다.

• IBM WebSphere Liberty

매우 빠른 기동 시간과 모듈식 구조를 갖춘 가벼운 서버로, YAML이나 API를 통해 설정을 처리하므로 별도의 콘솔이 필요 없습니다. 쿠버네티스 Operator를 공식 지원해 클라우드 네이티브 환경에 적합하며, 스프링 부트 등과의 연동도 우수합니다. 다만 기존 WebSphere와 비교할 때 엔터프라이즈 기능이 축소돼 무거운 기능을 요구하는 시스템에는 맞지 않을 수 있습니다.

• JEUS

국내에서 가장 많이 사용 하지만 기동 속도가 보통 수준이며 쿠버네티스 친화성이 낮고, 무거운 관리 콘솔을 사용합니다. 클라우드 네이티브 전환 속도가 느리고 상대적으로 무거워 현대적인 MSA 환경에서는 한계가 있다는 평가를 받습니다.

• Tomcat

단순하고 가벼운 서블릿 컨테이너로 기동 속도가 매우 빠르며, Spring Boot에 내장 WAS로 채택될 정도로 높은 채택률을 보입니다. 공식 Operator는 없지만 경량성을 바탕으로 컨테이너 환경에 자연스럽게 적응합니다. 다만 JMS 등 부가기능이 없고 서블릿 컨테이너 역할에 집중되어 있어, 복잡한 엔터프라이즈 기능을 필요로 하는 경우에는 부족할 수 있습니다.

클라우드 네이티브 및 MSA 환경에서는 Wildfly 와 Tomcat (Spring Boot 내장 Tomcat 포함)이 가장 유리한 위치를 차지할 것으로 예상됩니다. 이들은 경량성, 빠른 시작 시간, 컨테이너 친화적인 구조를 가지고 있으며, 애플리케이션 중심의 개발에 적합합니다.

WildFly 기반의 경량화 노력과 Quarkus 프레임워크와의 연계를 통해 클라우드 네이티브 전환을 시도하고 있으나, 기존 EAP 버전은 여전히 무거운 측면이 있습니다.

WebLogic과 JEUS와 같은 전통적인 엔터프라이즈 WAS는 쿠버네티스 환경의 관리 철학 및 비용 효율성과 맞지 않아 점차 그 입지가 줄어들 것으로 보입니다. 이들은 기존 레거시 시스템의 유지보수 용도로는 계속 사용될 수 있으나, 새로운 MSA 프로젝트에는 적합하지 않습니다.

향후 5년 이후에는 WAS의 개념 자체가 점차 희미해지고, Spring Boot, Quarkus, Micronaut 등 내장형 웹 서버를 포함하는 마이크로서비스 프레임워크가 애플리케이션 런타임의 주류를 이룰 것으로 전망됩니다. WAS는 애플리케이션을 호스팅하는 플랫폼이 아니라, 애플리케이션에 내장된 경량 컨테이너의 형태로 존재하게 될 것입니다.

이러한 변화 속에서 가장 중요한 것은 WAS의 무상태화 (Stateless)와 외부 분산 캐시를 활용한 세션 관리입니다. 관리 콘솔 또한 개별 WAS 인스턴스보다는 쿠버네티스 오케스트레이션 툴을 통한 통합 관리가 핵심이 될 것입니다.