국내 WAS 시장 지형 — 국산·외산·오픈소스 구도와 교체 검토 기준

JEUS는 왜 국내에서 강한가 — 공공·금융 레퍼런스와 정책 배경

JEUS의 국내 강세는 세 요인이 겹친 결과입니다. 첫째, 레퍼런스의 누적입니다. JEUS는 TmaxSoft가 공급하는 자바 기반 WAS로 Jakarta EE 8 풀 스펙 지원을 표방하고 있으며(출처: TmaxSoft — JEUS 제품 소개), 2000년대 전자정부 사업 이후 공공·금융 프로젝트에서 레퍼런스가 쌓이면서 “검증된 국산 WAS”라는 위치를 확보했습니다. 공공 정보화 사업은 유사 사업의 도입 실적을 중시하므로, 레퍼런스가 레퍼런스를 부르는 구조가 만들어졌습니다.

둘째, 국산 소프트웨어 우대 정책입니다. 공공 조달에서 국산 소프트웨어의 판로를 지원하는 제도적 흐름(중소기업 소프트웨어 판로 지원, 혁신제품 지정 등)은 국산 WAS가 공공 시장에 진입하는 통로가 되어 왔습니다. 셋째, 한글 기술지원과 근접 대응입니다. 장애 시 국내 엔지니어가 현장에 대응하고 한글 문서·교육을 제공한다는 점은, 글로벌 벤더의 원격·영문 지원과 비교되는 실질적 차별점입니다.

다만 국산 상용 WAS도 라이선스 비용 구조는 외산과 같은 “상용” 모델입니다. 조달 등록 품목의 구성을 보면 국산 상용과 외산 상용의 과금 방식이 사실상 같은 계열입니다. 둘 다 코어 단위 영구 라이선스이고, 웹서버(WebtoB·Web Tier)를 별도 품목으로 구매해야 하며, APM도 별도입니다. 교체 검토의 축이 “국산 vs 외산”에서 “상용 vs 오픈소스 기반”으로 이동하고 있는 배경입니다.

WebLogic·WebSphere의 포지션 — 대형 레거시와 벤더 종속의 무게

WebLogic과 WebSphere는 대형 엔터프라이즈의 핵심 레거시 시스템에 깊이 뿌리내린 제품입니다. Oracle WebLogic은 Java EE 시대부터 대규모 트랜잭션 시스템의 표준 플랫폼 역할을 해 왔고(출처: Oracle — WebLogic Server), IBM WebSphere는 금융권 중심으로 미션 크리티컬 시스템을 오래 지탱해 왔습니다(출처: IBM — WebSphere Application Server). 성숙한 기능과 글로벌 지원 체계는 지금도 유효한 강점입니다.

그러나 세 가지 부담이 커지고 있습니다. 첫째, 라이선스·유지보수 비용입니다. 코어 수 기반 과금 구조에서 서버 증설은 곧 비용 증설이며, 연간 유지보수 비용이 총소유비용에서 차지하는 비중이 큽니다. 둘째, 벤더 종속(lock-in)입니다. 제품 고유 설정·배포 방식·관리 도구에 운영 체계가 묶이면서, 교체 비용이 커져 협상력이 약해지는 구조가 됩니다. 셋째, 버전 수명주기 부담입니다. 구버전의 지원 종료(EOL) 일정에 맞춰 업그레이드를 반복해야 하고, 업그레이드 자체가 대형 프로젝트가 되는 경우가 많습니다.

세 부담은 개별 사건이 아니라 하나의 구조에서 나옵니다. 코어당 과금은 확장할수록 비용을 키우고, 클러스터링·고가용성·보안 같은 기능이 상위 에디션에만 들어 있어 기능 하나를 더하려면 전체 등급을 올려야 합니다. 여기에 벤더 고유 API와 관리 콘솔이 애플리케이션과 운영 절차를 함께 묶습니다.

상용 WAS의 비용이 나오는 세 구조 (출처: OPENMARU iAP 제품 자료 · OMDM Technology 「공공기관 WAS 도입 가이드」)

수명주기 부담은 특히 구체적으로 확인할 수 있습니다. Oracle의 지원 정책은 Premier Support → Extended Support → Sustaining Support 3단계로 내려갑니다. Premier 단계에서는 보안 패치·버그 수정·신규 인증 매트릭스가 모두 제공되고, Extended 단계에서는 추가 비용을 내면 보안 패치와 주요 버그 수정을 받을 수 있습니다. 문제는 마지막 Sustaining 단계입니다. 기존 문서와 이미 나온 패치는 계속 받을 수 있지만 신규 보안 패치·버그 수정·인증 매트릭스 갱신이 모두 멈춥니다. 실무에서는 “지원은 되지만 고칠 수는 없는” 상태입니다.

(출처: Oracle Fusion Middleware Lifetime Support Policy, MOS Note 950131.1 — OPENMARU 기술자료 「단종된 WebLogic 서버의 기술적 위험과 대응 전략」 정리 기준)

이 표가 드러내는 두 번째 제약은 JDK 천장입니다. WAS 버전이 지원 JDK 범위를 고정하기 때문에, 구버전 WebLogic을 쓰는 한 최신 JDK의 GC 개선이나 TLS 1.3 같은 기능을 적용할 수 없습니다. 결국 OS·JDK·WAS를 함께 올려야 하는 상황이 되고, 계층 하나만 손봐서는 기술 부채가 해소되지 않아 프로젝트 범위와 비용이 함께 커집니다. 단종 환경의 위험과 전환 경로는 단종된 WebLogic 환경의 기술 부채 해소와 WAS 현대화 글에서 더 자세히 다룹니다.

이 부담이 임계점을 넘는 시점 — 대개 EOL 통보나 유지보수 계약 갱신 시점 — 이 곧 교체 검토가 시작되는 시점입니다.

오픈소스 기반 WAS는 왜 부상하는가 — 비용과 표준 호환성

오픈소스 기반 WAS의 부상은 두 요구가 이끌고 있습니다. 라이선스 비용 절감과 표준 호환성입니다. Apache Tomcat은 웹 컨테이너 수준의 워크로드에서 사실상 표준 지위를 굳혔고, WildFly와 이를 기반으로 한 Red Hat JBoss EAP는 풀스택 Jakarta EE 규격이 필요한 영역에서 상용 WAS의 대안으로 자리 잡았습니다. 표준 규격(서블릿·JSP·Jakarta EE) 중심으로 애플리케이션을 유지하면 특정 벤더에 묶이지 않는다는 점이 오픈소스 진영의 구조적 강점입니다.

오픈소스 진영이 파고든 두 번째 틈은 조립식 구매 구조입니다. 상용 WAS는 제품 하나만으로 운영이 끝나지 않습니다. 웹서버, 세션 클러스터링, APM, 운영 콘솔을 각각 다른 품목으로 사서 연동해야 하고, 계층마다 별도 라이선스·별도 유지보수·별도 기술지원이 붙습니다. 그 결과 비용을 예측하기 어려워지고, 장애가 나면 어느 계층의 문제인지를 두고 벤더 간 책임 공방이 벌어져 복구가 늦어집니다. 계층마다 갱신 주기와 지원 계약이 따로 돌아가므로 관리 포인트도 그만큼 늘어납니다.

통합 라이선스와 조각난 라이선스(조립식 비용)의 구성 차이 (출처: OPENMARU iAP 경쟁제품 비교 자료)

국산 제품 중에는 OPENMARU iAP(Intelligent Application Platform)가 이 흐름 위에 있는 선택지입니다. iAP는 오픈소스 Web/WAS 런타임에 세션 클러스터링·성능관리(OPENMARU APM — Application Performance Management)·운영관리를 결합한 국산 통합 WAS 플랫폼으로, 엔터프라이즈와 공공의 기존 서버·가상화(VM) 환경을 대상으로 합니다. 오픈소스의 비용 구조와 국산 상용의 기술지원·조달 접근성(과학기술정보통신부 혁신제품 지정, 조달청 디지털서비스몰 등록, GS 1등급 인증)을 함께 갖춘 형태로, “상용 vs 오픈소스”의 절충 지점에 위치합니다(출처: OPENMARU iAP 제품 소개). 조달 경로와 등록 현황은 OPENMARU iAP 조달청 디지털서비스몰 등록 안내에서 확인할 수 있고, 오픈소스 단독 운영과 상용 WAS 사이의 기능·지원 차이를 항목별로 비교한 내용은 Tomcat vs 상용 WAS — 언제 무엇을 선택할까 글에서 다룹니다. 오픈소스 진영 안에서 JBoss EAP와 WildFly가 어떻게 갈리는지는 JBoss EAP와 WildFly 차이점 비교 글이 정리하고 있습니다.

도입·교체 검토는 어떤 축으로 비교하는가 — 다섯 가지 기준

후보군을 좁히는 비교 축은 다섯 가지입니다. 어느 진영이든 이 축으로 나란히 놓으면 판단이 빨라집니다.

1. 표준 스펙 준수 — 애플리케이션이 사용하는 규격(서블릿·JSP 수준인가, 분산 트랜잭션·메시징까지인가)을 실측하고, 제품의 Jakarta EE 호환 수준과 맞춥니다. 과잉 스펙은 곧 과잉 비용입니다.
2. 기술지원 체계 — 장애 대응 SLA, 국내 엔지니어 현장 지원 여부, 한글 문서·교육 제공을 확인합니다. 공공·금융은 감사 대응 관점에서 지원 계약의 증빙 가치도 봅니다.
3. 레퍼런스 — 자사와 유사한 규모·업종의 도입 실적을 확인합니다. 유사 환경 레퍼런스는 기술 검증 비용을 줄여 줍니다.
4. 라이선스 정책 — 코어 기반인지 서버 기반인지, 유지보수 요율은 얼마인지, 증설 시 비용 곡선이 어떻게 그려지는지 5년 시야로 계산합니다. 공공 조달 품목은 조달청 디지털서비스몰에서 등록 여부와 구성 품목을 확인할 수 있습니다.
5. 마이그레이션 용이성 — 기존 애플리케이션의 이관 난이도입니다. 표준 규격 준수 수준이 높은 애플리케이션일수록 이관이 쉽고, 제품 고유 기능(벤더 전용 API·설정)에 의존할수록 이관 비용이 커집니다. 실제 이관 절차와 점검 항목은 WebLogic·WebSphere에서 오픈소스 WAS로 안전하게 전환하기 글에서 확인할 수 있습니다.

네 번째 축에서 실수가 가장 자주 나옵니다. 제품 단가만 나란히 놓고 비교하면 구성 품목이 서로 다른 견적을 비교하게 되기 때문입니다. 상용 WAS 진영은 WAS 단가에 웹서버(Web Tier·WebtoB)가 코어 단위로 더해지고 APM이 또 별도로 붙습니다. 반면 오픈소스 기반 제품군은 웹서버를 포함해 산정되고, 통합 플랫폼형은 APM과 세션 클러스터링까지 단일 라이선스에 넣습니다. 같은 코어 수라도 “무엇이 포함되어 있는가”에 따라 누적 비용의 기울기가 달라지므로, 비교표를 만들 때는 반드시 구성 품목을 먼저 맞춘 뒤 견적을 나란히 놓아야 합니다. 과금 단위(코어·CPU·노드)와 라이선스 형태(영구·구독)를 함께 표기하는 것도 같은 이유입니다.

공공기관이라면 여기에 조달 방식(경쟁 입찰·수의계약 가능 여부)과 도입 절차 요건이 더해집니다. 혁신제품으로 지정된 품목은 수의계약 경로가 열리므로 조달 절차의 난이도가 달라집니다. 관련 제도와 지정 현황은 지능형 애플리케이션 플랫폼 OPENMARU iAP — 과기정통부 혁신제품 선정 안내에서 확인할 수 있습니다.

시장은 어디로 가는가 — EOL·구독 전환이 만드는 교체 수요

향후 국내 WAS 시장의 변수는 외산 제품의 수명주기와 과금 모델 변화입니다. 첫째, EOL발 교체 수요입니다. 외산 상용 WAS 구버전의 지원 종료가 도래할 때마다 “고비용 업그레이드 vs 대안 검토”의 갈림길이 만들어지고, 이 갈림길에서 오픈소스 기반 또는 국산 제품으로의 전환을 검토하는 조직이 늘고 있습니다. 지원이 끝난 미들웨어를 방치하면 보안 패치 공백이라는 기술 부채가 쌓이므로, EOL은 미룰 수 없는 결정 시점입니다.

앞의 지원 단계 표에서 봤듯 WebLogic은 10.3.6부터 12.2.1.3까지 이미 Sustaining 단계에 들어가 있습니다. 신규 CVE가 나와도 공식 패치가 나오지 않는 구간이라, 감사 지적이나 컴플라이언스 위반, 외부 연동 거부 같은 형태로 위험이 현실화됩니다. 반대로 업그레이드를 택하면 특정 버전에 묶인 애플리케이션 종속성, Deprecated API 대응, 소스 수정과 재컴파일, 전체 회귀 테스트가 한꺼번에 따라옵니다. 단종 시점에 조직이 실제로 마주하는 선택지는 WAS 단종(EOS/EOL) 대응, 업그레이드 말고 다른 선택지는 없을까요? 글에서 항목별로 정리했습니다.

둘째, 구독 전환 흐름입니다. 글로벌 소프트웨어 벤더 전반이 영구 라이선스에서 구독 모델로 이동하면서, 사용자 조직은 비용 구조를 다년 시야로 재계산할 계기를 맞았습니다. 이 재계산 과정에서 “실제 사용하는 스펙 대비 지불하는 비용”이 드러나고, 경량 런타임으로 충분한 시스템의 다운사이징 검토가 뒤따르는 경우가 많습니다.

셋째, 신규 구축의 무게중심 이동입니다. 신규 웹 시스템에서 스프링 부트+톰캣 계열 구성이 보편화되면서, 풀스택 상용 WAS의 신규 수요는 미션 크리티컬 영역으로 좁혀지는 추세입니다. 정리하면, 국내 WAS 시장은 “설치 기반은 상용이 두텁고, 신규와 교체의 흐름은 오픈소스 기반으로 기우는” 전환기에 있습니다. 교체를 검토하는 조직이라면 이 흐름을 협상력의 지렛대로 쓸 수 있는 시기이기도 합니다.

자주 묻는 질문 (FAQ)

Q. 국내 WAS 시장의 주요 제품은 무엇인가요?
국산 상용은 TmaxSoft JEUS와 OPENMARU iAP 등, 외산 상용은 Oracle WebLogic과 IBM WebSphere, 오픈소스 계열은 Apache Tomcat·WildFly·Red Hat JBoss EAP가 대표적입니다. 국산·외산·오픈소스 3자 구도가 국내 시장의 특징입니다.

Q. JEUS가 국내 공공·금융에서 강세인 이유는 무엇인가요?
전자정부 사업 이후 누적된 공공·금융 레퍼런스, 국산 소프트웨어 판로 지원 정책, 한글 기술지원과 국내 엔지니어의 근접 대응이 겹친 결과입니다. 공공 사업이 유사 도입 실적을 중시하는 구조도 레퍼런스 누적 효과를 키웠습니다.

Q. WebLogic·WebSphere에서 교체를 검토하는 이유는 무엇인가요?
코어 기반 라이선스·유지보수 비용 부담, 제품 고유 기능에 묶이는 벤더 종속, 지원 종료(EOL) 일정에 따른 반복적 업그레이드 부담이 주요 이유입니다. EOL 통보나 유지보수 갱신 시점이 검토의 계기가 되는 경우가 많습니다.

Q. WAS 교체 검토 시 무엇부터 확인해야 하나요?
애플리케이션이 실제 사용하는 표준 스펙 범위 실측이 첫 단계입니다. 이후 기술지원 체계, 유사 환경 레퍼런스, 라이선스 정책의 5년 비용 곡선, 마이그레이션 난이도 순서로 비교 축을 좁히면 후보군이 정리됩니다.

Q. 오픈소스 기반 WAS로 바꾸면 기술지원은 어떻게 확보하나요?
오픈소스 런타임에 벤더 기술지원을 결합한 상용 구독 모델을 선택하면 됩니다. Red Hat JBoss EAP가 대표적이고, 국산으로는 Legacy/VM 환경 대상의 OPENMARU iAP처럼 오픈소스 기반에 국내 기술지원과 조달 접근성을 더한 제품이 있습니다.

Q. WebLogic의 Premier·Extended·Sustaining 지원 단계는 무엇이 다른가요?
Premier는 보안 패치·버그 수정·신규 인증 매트릭스가 모두 제공되는 단계이고, Extended는 추가 비용을 내고 보안 패치와 주요 버그 수정을 받는 연장 단계입니다. Sustaining은 기존 문서와 이미 배포된 패치만 받을 수 있고 신규 보안 패치·버그 수정·인증 매트릭스 갱신이 중단되는 단계로, 실무에서는 “지원은 되지만 고칠 수는 없는” 상태에 해당합니다.

Q. WAS 제품 견적을 비교할 때 무엇을 맞춰야 하나요?
구성 품목을 먼저 맞춰야 합니다. WAS 단가만 비교하면 웹서버·APM처럼 별도 품목으로 사야 하는 요소가 빠진 채 비교하게 됩니다. 과금 단위(코어·CPU·노드)와 라이선스 형태(영구·구독)도 함께 표기해야 5년 누적 비용을 같은 기준으로 놓을 수 있습니다. 공공 조달 품목이라면 조달청 디지털서비스몰에서 등록 여부와 구성 품목을 확인할 수 있습니다.

참고 리소스

시장 구도와 제품 선택 (자사)

• WAS란 무엇인가 — 구조와 기능, 제품 선택 기준까지
• WAS와 웹서버의 차이 — 요청 흐름부터 분리 배치 이유까지
• Tomcat vs 상용 WAS — 기능·지원·TCO로 가르는 선택 기준
• JBoss EAP와 WildFly 차이점 비교 분석

EOL 대응과 오픈소스 전환 (자사)

• WAS 단종(EOS/EOL) 대응, 업그레이드 말고 다른 선택지는 없을까요?
• 웹로직 단종 환경 실무 적용 전략 — 오픈소스 WAS 마이그레이션 도입 가이드
• WebLogic·WebSphere에서 오픈소스 WAS로 안전하게 전환하기
• 단종된 WebLogic 환경의 기술 부채 해소와 WAS 현대화 — CNCF

제품·조달 (자사)

• 조달물품 OPENMARU iAP — 제품 소개
• 지능형 애플리케이션 플랫폼 OPENMARU iAP — 과기정통부 혁신제품 선정
• OPENMARU iAP 조달청 디지털서비스몰 등록
• WAS 장애·세션 유실·APM 선택 기준 정리

벤더 공식 자료 (외부)

• JEUS — TmaxSoft
• WebLogic Server — Oracle
• WebSphere Application Server — IBM
• Oracle Fusion Middleware Lifetime Support Policy (PDF)