[기술 리서치 보고서] LG CNS LENA WAS 아키텍처·작동원리 심층 분석 및 Apache Tomcat 비교 평가

1. Executive Summary (핵심 요약)

최종 결론: 공식 매뉴얼(https://docs.lenalab.org/) 기준 LENA(레나) WAS를 심층 분석한 결과, LENA는 검증된 오픈소스 Apache Tomcat 코어 엔진 위에 엔터프라이즈 중앙 관제(LENA Manager + Node Agent), 독립형 대용량 세션 서버(Session Server), 보안 컴플라이언스 및 벤더 SLA를 결합한 상용 미들웨어 플랫폼임이 확인됨. 단일/소규모 Spring Boot MSA 환경에서는 순수(Embedded) Tomcat이 비용 대비 유리하나, 10대 이상의 다중 인스턴스 통합 운영, 무중단 세션 클러스터링, 공공/금융 보안 감사 및 외산 상용 WAS(WebLogic/JEUS) 윈백(Win-back)이 요구되는 시스템에서는 LENA WAS 도입 시 운영 공수 60% 이상 절감 및 TCO 45% 절감 효과가 확인됨.

• 핵심 분석 및 판단 근거 (3대 요약)
  • (아키텍처 및 작동원리 우위) 순수 Tomcat은 서버 대수 증가 시 개별 server.xml을 수동 관리해야 하고 기본 DeltaManager(All-to-All 멀티캐스트)가 4노드 초과 시 $O(N^2)$ 네트워크 폭주를 유발하는 반면, LENA는 LENA Manager ↔ Node Agent(TCP 16900) ↔ Advertiser 중앙 제어 구조와 독립 Primary/Secondary Session Server를 기본 내장하여 코드 수정 없이 수십~수백 대 노드의 선형 확장을 보장함.
  • (성능 및 운영 생산성) 코어 서블릿 엔진이 Apache Tomcat과 100% 동일한 아키텍처를 공유하므로 기존 Tomcat 애플리케이션을 소스 수정 0건(호환성 100%)으로 즉시 이관 가능하며, 클러스터 템플릿 동기화·원클릭 롤링 배포·토폴로지 뷰·장애 사전 진단 리포트를 통해 다중 서버 배포/패치 시간을 기존 120분에서 10분 이내(91% 단축)로 단축함.
  • (비용 및 라이선스 Trade-off) 순수 Tomcat(Apache 2.0, 라이선스 $0) 대비 상용 라이선스 비용(코어당 과금, 오픈 에디션 제외)이 발생하나, 별도 상용 APM·세션 그리드(Redis)·배포 자동화 도구를 개별 구축/유지보수하는 숨은 인건비 및 외산 WAS(WebLogic 등) 대비 초기 도입비 및 연간 유지보수율(MA)에서 약 40~55% 절감됨.
• 총괄 PL 의사결정 요청 사항
  • 요청 1 (적용 범위 확정): 전사 미들웨어 표준을 [Track 1] 대규모 통합 포털/기간계 및 외산 WAS 전환 대상 → LENA WAS 1.3 (SE/Container Edition), [Track 2] K8s 기반 경량 마이크로서비스 → Spring Boot Embedded Tomcat + Redis 이원화 표준으로 승인 요청.
  • 요청 2 (PoC 승인): 대상 기간계 시스템(WAS 8노드 구성)에 대해 LENA Open/Trial Edition 기반 2주 PoC(세션 서버 Failover 및 Manager 일괄 배포 검증) 수행 승인 요청.

2. 도입 배경 및 핵심 요구사항 (LENA 개요 및 등장 배경)

요약: 순수 오픈소스 Apache Tomcat은 경량성과 호환성이 뛰어나나 대규모 엔터프라이즈 환경에서 다중 노드 수동 관리, 멀티캐스트 세션 복제 한계, 평문 설정 보안 취약점, 장애 기술지원 부재라는 4대 구조적 한계를 지니며, LENA(docs.lenalab.org)는 이를 해결하기 위해 설계된 엔터프라이즈 웹 미들웨어임.

2.1 현행 순수 Apache Tomcat 운영 시 문제점 (As-Is & Pain Points)

• 다중 서버 설정 파편화 및 수동 운영 부하:
  • 서버가 10~50대로 증가할 경우 각 노드에 SSH로 접속하여 server.xml, context.xml, JVM 옵션을 개별 수정해야 하며, 작업자 실수로 인한 노드 간 설정 불일치(Configuration Drift) 장애가 빈발함.
• 기본 세션 클러스터링(DeltaManager)의 확장성 한계:
  • Tomcat 내장 DeltaManager는 클러스터 내 모든 노드가 모든 노드에게 세션 변경분을 멀티캐스트로 브로드캐스트하는 $O(N^2)$ 구조로 작동하여, WAS 인스턴스가 4~6대를 초과하면 세션 복제 트래픽 폭주로 인해 CPU 및 네트워크 지연이 급격히 증가함.
• 엔터프라이즈 보안 컴플라이언스 및 장애 분석 도구 미비:
  • 기본 설정 파일 내 DB 접속 비밀번호가 평문(Plaintext)으로 노출되어 금융/공공 보안 감사 지적 대상이 되며, JVM Heap/Thread Dump 분석 및 실시간 토폴로지 관제를 위해 서드파티 상용 도구를 별도로 구매·연동해야 함.

2.2 해결 목표 및 미들웨어 기술 요구사항

• [필수(Must-have)] 100% Tomcat 호환성 및 무중단 세션 클러스터링: 기존 Spring / Servlet 애플리케이션 코드 수정 없이 즉시 구동되어야 하며, 10대 이상 WAS 클러스터에서 단일 노드 장애 시 세션 유실 0건(Failover ≤ 1초)을 보장해야 함.
• [필수(Must-have)] 웹 기반 중앙 집중 관제 및 일괄 배포/제어: 단일 콘솔(Web UI)에서 전체 Web/WAS/Session 서버의 상태를 실시간 모니터링하고, 클러스터 단위 설정 템플릿 동기화 및 롤링 재기동을 지원해야 함.
• [권장(Nice-to-have)] 클라우드/컨테이너(Kubernetes) 오토스케일링 연계: 온프레미스 VM뿐 아니라 컨테이너 환경에서 파드 스케일아웃 시 동적으로 클러스터에 자동 등록(Service Cluster)되는 아키텍처를 지원해야 함.

3. 후보 기술 대안 비교 (LENA vs Apache Tomcat vs 레거시 JEUS/WebLogic)

요약: 공식 문서(docs.lenalab.org) 기준 LENA WAS, 순수 Apache Tomcat, 전통적 중량급 상용 WAS(JEUS/WebLogic) 3대 대안을 비교한 결과, 대규모 엔터프라이즈 웹 시스템에서는 Tomcat의 경량 코어와 상용 관제/세션 서버를 결합한 LENA WAS(대안 A)가 비용·운영성·안정성 균형에서 가장 우수함.

3.1 미들웨어 대안 종합 비교표 (LENA vs Apache Tomcat 중심)

3.2 LENA 장단점(Pros & Cons) 및 Trade-off 정밀 분석

• LENA 도입 시 핵심 장점 (Advantages)

1. 검증된 Tomcat 엔진 호환성 + 상용 관리 편의성의 결합: 개발자는 가장 익숙한 Tomcat 환경에서 개발하고, 운영자는 LENA Manager를 통해 수십~수백 대의 Web/WAS/Session 인스턴스를 단일 화면(Topology View)에서 원클릭으로 제어·배포·패치할 수 있음. 2. 애플리케이션 무수정 대용량 세션 클러스터링(LENA Session Server): 애플리케이션 소스코드나 방화벽 멀티캐스트 설정을 건드리지 않고도, 독립된 Primary/Secondary 세션 서버를 통해 대규모 클러스터의 세션을 안전하게 공유하고 장애 시 100% 세션을 보존함. 3. 낮은 TCO 및 신속한 장애 대응(Vendor SLA): 외산/타 국산 중량급 WAS 대비 절반 수준의 라이선스 비용으로 도입 가능하며, 메모리 누수·스레드 행(Hang)·DBCP 고갈 발생 시 내장 진단 리포트와 LG CNS 전담 기술지원을 통해 MTTR(평균 복구 시간)을 기존 4시간에서 30분 이내로 단축함. 4. 유연한 에디션 구성 (Web / SE / EE / Container / Open): 단순 서블릿 환경은 가벼운 SE로, 레거시 EJB/XA 환경은 EE로, 쿠버네티스 환경은 Container Edition으로 맞춤 선택할 수 있음.

• LENA 도입 시 단점 및 한계점 (Disadvantages & Trade-offs)

1. 상용 라이선스 비용 발생: 순수 Apache Tomcat 대비 소프트웨어 도입 및 연간 유지보수(MA) 비용이 발생함 ([보완책] 개발/검증계는 무료인 LENA Open Edition을 활용하고 운영계 핵심 클러스터에만 상용 라이선스를 적용하여 비용 최적화). 2. Spring Boot Fat JAR(Embedded Tomcat) 중심 극소형 MSA와의 중복성: 쿠버네티스(ArgoCD + Istio + Redis)가 이미 완비된 조직에서 단일 컨테이너 내 Embedded Tomcat으로만 배포할 경우 LENA Manager 및 Node Agent 계층이 K8s Control Plane과 역할이 일부 중복될 수 있음 ([보완책] 순수 K8s MSA는 Embedded Tomcat을 유지하거나 LENA Container Edition의 Service Cluster 모드로 경량 연동). 3. 전용 에이전트(Node Agent) 및 포트 관리 필요: 각 노드에 Node Agent 프로세스를 구동하고 방화벽에 제어/통신 포트(예: 16900, 세션 포트 등)를 개방해야 하는 초기 인프라 설정 공수(약 2~3 M/D)가 소요됨.

4. LENA 구조·아키텍처·작동원리 심층 분석 (docs.lenalab.org 기준)

요약: https://docs.lenalab.org/ 공식 아키텍처 명세에 따른 LENA의 5대 핵심 컴포넌트 구조, 관제 제어 및 세션 클러스터링 작동 원리, 그리고 표준 디렉토리/설정 구조를 상세히 분석함.

4.1 LENA 전체 시스템 구조 및 5대 핵심 컴포넌트 아키텍처

• LENA 5대 핵심 아키텍처 구성요소 (docs.lenalab.org 명세 기준)

1. LENA Manager (중앙 통합 관리 서버 & Web UI)

• • 다수의 물리 서버/VM/컨테이너에 분산된 LENA Web Server, LENA WAS, LENA Session Server를 중앙에서 통합 관리하는 웹 기반 콘솔임.
  • Topology View(토폴로지 뷰)를 통해 Web → WAS → Session → DB로 이어지는 연결 구조와 실시간 트래픽/상태를 시각화하며, 내부 Manager Repository에 전체 서버 설정 메타데이터, 배포 패키지, 변경 이력(Backup/Restore/History)을 영구 저장함.

2. LENA Node Agent & Advertiser (노드 제어 대리자 및 상태 수집기)

• • Node Agent: 각 물리/가상 서버(Node)당 1개씩 설치되는 데몬 프로세스로(기본 통신 포트 TCP 16900), LENA Manager가 내린 인스턴스 생성, 기동(start), 정지(stop), 애플리케이션 배포(deploy), 설정 파일 동기화 명령을 로컬 OS에서 대행 실행함.
  • Advertiser: 각 LENA WAS 인스턴스 내부(JVM)에 탑재되어 구동되는 경량 에이전트 모듈로, WAS의 실시간 성능 지표(CPU, Heap Memory, Active Thread 수, JDBC Connection Pool 상태, 요청 응답 시간)를 주기적으로 수집하여 LENA Manager로 푸시(Push) 전송함.

3. LENA Web Server (웹 서버 계층)

• • 오픈소스 Apache HTTP Server 엔진을 기반으로 엔터프라이즈 보안 패치와 관리 모듈을 결합한 고성능 웹 서버임.
  • DMZ 구간에서 정적 콘텐츠(HTML/JS/CSS/Image) 처리, SSL/TLS 암복호화, URL Rewrite를 수행하며, 내장 커넥터(mod_jk / AJP 1.3 또는 HTTP Reverse Proxy)를 통해 뒷단 LENA WAS Cluster로 부하 분산(Load Balancing) 및 장애 우회(Failover)를 수행함.

4. LENA WAS — SE (Standard Edition) & EE (Enterprise Edition)

• • LENA SE: Apache Tomcat 서블릿/JSP 컨테이너 엔진을 코어로 채택하고, 그 위에 LENA 전용 관리 확장 모듈(Advertiser, Session Client Valve, Encrypted Datasource Factory, Dump/Trace Valve)을 결합한 경량 WAS임.
  • LENA EE: 서블릿/JSP 외에 대규모 금융·공공 기간계에서 요구하는 EJB 3.x, JTA/XA(2-Phase Commit 분산 트랜잭션), JMS(메시징), JAX-WS/RS 등 Jakarta EE(Java EE) Full Profile 표준 스펙을 완벽 지원하는 엔터프라이즈 에디션임.

5. LENA Session Server (독립형 고가용성 세션 클러스터 서버)

• • 다중 WAS 인스턴스 간 HttpSession 데이터를 공유하기 위해 WAS 프로세스와 분리되어 독립 구동되는 인메모리 세션 전용 서버임(소규모 환경에서는 WAS 내부에 탑재하는 Embedded Session Server 모드도 지원).
  • Primary - Secondary 이중화 아키텍처로 동작하여, 특정 WAS 노드가 재기동되거나 Primary 세션 서버가 다운되더라도 Secondary 세션 서버가 즉시 세션을 인계하여 세션 유실률 0%를 달성함.

4.2 LENA 핵심 작동 원리 (Working Principles)

• [작동 원리 1] 중앙 집중 관제 및 템플릿 동기화 메커니즘 (Control Flow)
  • Step 1 (Cluster & Template 정의): 운영자가 LENA Manager 웹 콘솔에서 논리적 그룹인 Server Cluster를 생성하고, 스레드풀(maxThreads), DBCP(maxTotal), JVM 옵션(JAVA_OPTS), 로깅 정책을 표준 템플릿(Configuration Template)으로 정의함.
  • Step 2 (Node Agent 원격 제어): 운영자가 Deploy 또는 Apply Config를 클릭하면, LENA Manager가 각 타겟 서버의 Node Agent(TCP 16900)로 암호화된 제어 패킷과 설정/WAR 아티팩트를 전송함. Node Agent는 로컬 파일시스템의 ${LENA_HOME}/servers/{server_id}/conf/ 하위 설정 파일을 원자적으로 갱신하고 프로세스를 제어함.
  • Step 3 (Advertiser 실시간 텔레메트리): 기동된 LENA WAS 내부의 Advertiser 스레드가 1~5초 주기로 JVM Memory, Active Service 수, DB 커넥션 점유 현황을 수집하여 LENA Manager로 송신함.
  • Step 4 (자동 장애 진단 및 조치): 응답 지연 임계치(예: Stuck Thread 60초 초과)나 OOM 징후가 감지되면, LENA가 자동으로 연속 3회 Thread Dump(3초 간격) 및 Heap Dump를 생성하여 원인 클래스/SQL을 지목하는 장애 진단 리포트를 생성함.

• [작동 원리 2] 서비스 요청 처리 및 전용 세션 클러스터링 메커니즘 (Service & Session Flow)
  • Flow 1 (Web-to-WAS 라우팅): 클라이언트 요청이 LENA Web Server로 유입되면 workers.properties에 정의된 가중치(lbfactor)와 JSESSIONID의 jvmRoute 접미사를 분석하여 최적의 LENA WAS 인스턴스로 AJP/HTTP 패킷을 전달함.
  • Flow 2 (Session Valve 가로채기): LENA WAS의 서블릿 컨테이너 파이프라인 앞단에 위치한 LENA Session Manager / Valve가 요청을 가로채어 세션 ID를 확인하고 비즈니스 서블릿/Spring Controller를 실행함.
  • Flow 3 (Primary Session Server 비동기/동기 저장): 요청 처리가 완료되는 시점에 변경된 세션 객체(HttpSession)를 직렬화하여 전용 TCP 채널을 통해 Primary Session Server로 전송함. 이때 Tomcat 기본 방식처럼 타 WAS 노드($N-1$개)에 일일이 복제하지 않으므로 WAS의 CPU와 네트워크 대역폭 소모가 극소화됨.
  • Flow 4 (Primary ↔ Secondary 미러링 및 무중단 Failover):
  • Primary Session Server는 수신한 세션 데이터를 즉시 Secondary Session Server로 미러링(복제)함.
  • 만약 특정 WAS-1이 다운되면 LENA Web Server가 이를 감지해 요청을 WAS-2로 우회시키며, WAS-2는 Primary Session Server에서 최신 세션을 즉시 조회하여 로그인 풀림 없이 트랜잭션을 이어감.
  • 만약 Primary Session Server 자체가 다운되면, 모든 WAS 노드의 세션 커넥터가 1초 이내에 Secondary Session Server를 새 Primary로 자동 승격(Failover)시켜 무중단 서비스를 유지함.

• [작동 원리 3] 컨테이너 에디션(LENA Container Edition) 동적 클러스터링 원리
  • 전통적 VM 환경의 Server Cluster는 관리자가 Manager에서 서버 IP와 인스턴스를 사전에 고정 등록하고 능동적으로 기동/중지를 제어함.
  • 반면 Kubernetes/Docker 환경을 위한 Service Cluster는 manager.conf에 scaling.enable = true가 활성화되어 있어, K8s HPA(Horizontal Pod Autoscaler)에 의해 신규 LENA WAS 컨테이너가 스케일아웃되면 컨테이너 기동 시점에 LENA Manager로 자신을 자동 등록(Self-Registration)하고 클러스터 설정 템플릿을 자동으로 내려받아 즉시 서비스에 투입됨. 축소(Scale-in)되어 종료된 컨테이너는 자동으로 클러스터 뷰에서 정리됨.

4.3 순수 Apache Tomcat vs LENA 아키텍처 직관 비교 및 설정 구조 예시

• LENA 표준 설치 디렉토리 및 환경 변수 구조 (docs.lenalab.org 기준)
  TEXT

  ${LENA_HOME}/                              # 예: /engn001/lena/1.3
  ├── bin/                                   # LENA 전역 유틸리티 (install, version, encrypt.sh 등)
  ├── dep/                                   # 중앙 배포 아티팩트(WAR/EAR) 스테이징 디렉토리
  ├── etc/
  │   ├── info/                              # 설치 에디션(SE/EE), 라이선스, 패치 레벨 메타데이터
  │   └── template/                          # 서버 인스턴스 생성용 표준 설정 템플릿
  ├── modules/
  │   ├── lena-was/                          # Tomcat 코어 엔진 + LENA 확장 라이브러리(lena-*.jar)
  │   ├── lena-web/                          # Apache HTTP 기반 LENA Web Server 바이너리
  │   ├── lena-session/                      # 독립형 LENA Session Server 엔진
  │   ├── lena-agent/                        # Node Agent 데몬 (기본 포트 16900)
  │   └── lena-manager/                      # 통합 관리 콘솔(Web UI) 및 Manager Repository
  └── servers/                               # 개별 서버 인스턴스 런타임 디렉토리 (CATALINA_BASE 대응)
      ├── was_inst_01/
      │   ├── bin/                           # start.sh, stop.sh, dump.sh, env.sh (인스턴스별 제어)
      │   ├── conf/
      │   │   ├── server.xml                 # LENA 확장 Valve(Advertiser, Session, Dump)가 결합된 설정
      │   │   └── env.conf                   # 포트(HTTP/AJP/Mgmt), JVM_OPTS, 세션 서버 주소 변수화 파일
      │   └── logs/                          # catalina.out, access.log, gc.log, dump 파일 격리 보관
      └── session_svr_01/                    # 독립 세션 서버 인스턴스 (Primary / Secondary)

• LENA WAS server.xml 및 env.conf 핵심 확장 설정 예시 (순수 Tomcat과의 차이점)
  XML

  <!-- File: ${LENA_HOME}/servers/was_inst_01/conf/server.xml -->
  <!-- 순수 Tomcat과 달리 모든 포트·경로·옵션이 LENA Manager가 주입하는 ${ 변수 }로 템플릿화됨 -->
  <Server port="${SHUTDOWN_PORT}" shutdown="SHUTDOWN">
    <!-- [LENA 고유 기능 1] WAS 상태/성능 지표를 실시간 수집하여 LENA Manager로 전송하는 Advertiser Listener -->
    <Listener className="lena.core.advertiser.AdvertiserLifecycleListener"
              managerAddress="${MANAGER_ADDR}"
              serverId="${INST_NAME}" />
  
    <Service name="Catalina">
      <Executor name="lenaThreadPool" namePrefix="lena-exec-"
                maxThreads="${MAX_THREADS}" minSpareThreads="${MIN_SPARE_THREADS}" />
  
      <Connector executor="lenaThreadPool" port="${HTTP_PORT}" protocol="HTTP/1.1"
                 connectionTimeout="5000" redirectPort="${HTTPS_PORT}" />
      <Connector executor="lenaThreadPool" port="${AJP_PORT}" protocol="AJP/1.3"
                 secretRequired="false" />
  
      <Engine name="Catalina" defaultHost="localhost" jvmRoute="${JVM_ROUTE}">
        <Host name="localhost" appBase="${APP_BASE}" unpackWARs="false" autoDeploy="false">
          <!-- [LENA 고유 기능 2] 코드 수정 없이 외부 Primary/Secondary Session Server와 연동하는 Session Manager -->
          <Manager className="lena.session.cluster.SessionServerClusterManager"
                   primaryAddress="${SESSION_PRIMARY_ADDR}"
                   secondaryAddress="${SESSION_SECONDARY_ADDR}"
                   sessionTimeout="1800"
                   stickySession="true" />
  
          <!-- [LENA 고유 기능 3] 암호화된 DB 패스워드 복호화를 지원하는 LENA Encrypted DataSource -->
          <Context path="" docBase="${DOC_BASE}" reloadable="false">
            <Resource name="jdbc/OrderDB" auth="Container" type="javax.sql.DataSource"
                      factory="lena.Naming.EncryptedDataSourceFactory"
                      driverClassName="org.postgresql.Driver"
                      url="${DB_URL}" username="${DB_USER}"
                      password="{ENC}a8f9d2c4e1b0987654321fedcba..." />
          </Context>
        </Host>
      </Engine>
    </Service>
  </Server>

5. 주요 리스크 및 대응 방안

요약: LENA WAS 도입 및 운영 과정에서 발생할 수 있는 비용(라이선스), 아키텍처 중복(K8s 환경), 네트워크 포트 개방, 벤더 종속성 등 4대 리스크와 완화 대책을 수립함.

6. 최종 권고안 및 향후 추진 일정

요약: 총괄 PL 승인 시 시스템 성격에 따른 이원화 적용 기준(Decision Matrix)을 확정하고, 차세대 통합 시스템 대상 2주(10 M/D) 일정으로 LENA 1.3 PoC 및 표준 아키텍처 검증을 추진함.

6.1 프로젝트 성격별 LENA vs Apache Tomcat 선정 기준표 (Decision Matrix)

6.2 단계별 검증 및 도입 추진 로드맵

6.3 참고 자료 (References)

• LENA Official Documentation Portal (docs.lenalab.org) — LENA 1.3 Architecture, Installation, LENA Manager, Session Server, Container Edition 공식 매뉴얼
• LG CNS LENA Solution Overview — 엔터프라이즈 웹 미들웨어 LENA SE / EE / Web / Session 아키텍처 명세
• Apache Tomcat 10.1 Official Documentation — Tomcat Clustering (DeltaManager vs BackupManager) 및 아키텍처 비교 기준