Tech Note · 개발

WAS의 종류 및 역할

3‑Tier 구성에서 WAS가 왜 필요한지, 어떤 제품군으로 분류되는지,

그리고 WAS 연동 솔루션을 붙일 때 무엇을 확인해야 하는지(특히 JDBC/ODBC)를 정리합니다.

1) 3‑Tier 구성에서 WAS의 역할, 존재의 이유

3‑Tier는 보통 클라이언트 → Web 서버 → WAS → DB로 흐릅니다. Web 서버는 정적/전달(프록시, TLS 종료, 캐시)에 강하고, WAS는 동적 처리(비즈니스 로직)와 운영 기능(세션/트랜잭션/풀)을 담당합니다.

그림 1. 3‑Tier에서 WAS의 역할

WAS가 특히 필요한 순간(운영자 관점)

동시성 처리: 요청을 스레드 풀로 처리(큐/대기/타임아웃까지 포함)합니다.
세션/인증: 로그인 세션, 보안 필터, 접근 제어 같은 공통 기능을 제공/연계합니다.
트랜잭션: 여러 DB 작업을 하나의 논리 단위로 묶어 일관성을 지키는 데 유리합니다.
풀링: DB 커넥션 풀처럼 “비싼 자원”을 재사용해 성능을 안정화합니다.

2) WAS의 종류 및 분류

실무에서는 보통 (1) JVM 기반인가, (2) 오픈소스인가/상용(지원 계약)인가로 크게 나눠서 빠르게 판단합니다.

그림 2. 런타임(JVM/비‑JVM) × 라이선스(오픈소스/상용) 분류

2‑1. 제품군 별 분류 및 특징

아래는 많이 사용하는 WAS 솔루션들을 런타임/라이선스 별 분류 및 각각의 특징을 카드 형태로 정리하였습니다.

가격대 표기 기준
상용 제품은 조직/코어 수/인스턴스/클러스터/DR/지원등급에 따라 크게 달라서,

숫자 대신 “견적/구독/계약 기반”으로 표기하고, 가격에 영향을 주는 항목을 체크리스트로 제공합니다.

상용 WAS 견적에 영향 주는 항목(체크리스트)
• 코어/CPU 기준 과금 여부 • 인스턴스/노드 수 • 클러스터/HA 구성 • DR(이중화) 포함 여부
• 관리 콘솔/옵션 • 지원 등급(24x7, SLA) • 장기 유지보수(LTS) 정책

Apache Tomcat

JVM오픈소스서블릿 컨테이너

특징: “가볍게, 많이” 쓰는 표준 컨테이너. 각종 기술자료와 사용자 레퍼런스가 풍부합니다.
장점

구성 단순, 운영 경험자 많음
Spring Boot 내장 서버로도 흔함

주의

엔터프라이즈 기능(관리/클러스터링/표준 EE 풀스택)은 설계/추가 구성 필요

가격대/지원: 무료. 필요 시 파트너 유지보수 계약 형태.

JEUS (TmaxSoft)

JVM상용엔터프라이즈

특징: 기업 환경 기능/운영 도구 + 공식 지원.
장점

정책 기반 운영(지원/패치)
운영 표준화에 유리

주의

라이선스/지원 계약 및 운영 모델 이해 필요

가격대/지원: 견적 기반 + TmaxSoft 지원.

JBoss EAP (Red Hat)

JVM상용(구독)Jakarta EE

특징: WildFly 계열 엔터프라이즈 지원판.
장점

구독형 업데이트/지원 정책
표준 기반 운영

주의

구독 모델/지원 범위/버전 정책 확인

가격대/지원: 구독 기반 + Red Hat 지원.

WebLogic (Oracle)

JVM상용대규모 엔터프라이즈

특징: 전통적인 대규모 엔터프라이즈 제품군.
장점

관리/클러스터링 기능
운영 레퍼런스 풍부

주의

비용/복잡도, 벤더 정책 영향

가격대/지원: 계약/견적 기반 + Oracle 지원.

WebSphere (IBM)

JVM상용엔터프라이즈

특징: 기업 통합/관리 기능이 강한 전통 제품군.
장점

기업 기능/통합
지원 정책 기반

주의

비용/운영 복잡도

가격대/지원: 계약/견적 기반 + IBM 지원.

Spring Boot (내장 서버)

JVM오픈소스 중심자체 실행형

정확한 위치: “WAS 제품”이라기보다 프레임워크이며, 내장 Tomcat/Jetty/Undertow로 실행형 서비스를 만듭니다.
장점

배포 단순, 마이크로서비스 친화

주의

운영 표준(보안/로그/배포/롤백/관측성)을 팀이 설계

가격대/지원: 오픈소스 기반(운영/플랫폼 비용은 설계에 좌우).

Node.js

비‑JVM오픈소스런타임

특징: I/O 중심 서비스에 강점. API 서버로 흔합니다.
장점

빠른 개발/배포

주의

프로세스/워커/클러스터링 모델 이해 필요

가격대/지원: 무료(+플랫폼/지원은 선택).

Python/Go 등

비‑JVM오픈소스프레임워크/런타임

특징: 경량 서비스/마이크로서비스에서 자주 등장.
장점

경량 구성, 빠른 확장

주의

서버 선택(Uvicorn/Gunicorn 등)과 운영 표준을 함께 설계

가격대/지원: 무료(+플랫폼/지원은 선택).

3) APM 연동 솔루션 소개 (운영에 도움 되는 최신 솔루션들)

운영에서는 “느려졌다/에러가 난다”를 감으로 추측하기보다,

트랜잭션·메트릭·로그·트레이스로 로그를 남기는 방식이 유리합니다.

이때 APM/관측성(Observability) 솔루션을 붙여서 원인 분해(예: DB/외부호출/풀 대기)를 빠르게 합니다.

그림 3. 관측성(Observability) 연동의 기본 구성

3‑1. 대표적인 운영 솔루션 카테고리 (예시)

APM: WhaTap, Datadog APM, New Relic, Dynatrace 등
표준 계측: OpenTelemetry(OTel) — 벤더 종속을 줄이는 표준
메트릭: Prometheus + Grafana
로그: Elastic Stack(ELK), Loki 등
인프라 모니터링: 노드/컨테이너/쿠버네티스 모니터링 도구

3‑2. 연동 시 꼭 확인할 점(필수만)

런타임/스택: Java/Node/Python/.NET 중 무엇인지(에이전트/SDK 선택이 달라짐)
DB 접근: JDBC 드라이버/커넥션 풀 종류(슬로우쿼리·풀 대기 관측에 직결)
보안: 개인정보/민감정보 마스킹, 샘플링 정책
오버헤드: 고트래픽에서 샘플링/필터링/리소스 상한
알림 기준: 에러율, p95/p99, 풀 대기, 슬로우쿼리

3‑3. JDBC/ODBC 란?

APM은 보통 DB 서버를 직접 들여다보기보다, 애플리케이션이 DB에 SQL을 보내는 지점(드라이버/풀)을 계측해서 SQL 시간·에러·풀 대기를 만들어냅니다. 그래서 “어떤 드라이버/풀이냐”가 중요해집니다.

부록) Tomcat/JEUS에서 요청이 DB 쿼리로 나가는 상세 흐름

WAS는 요청을 받아 스레드에 할당하고, 애플리케이션 코드(컨트롤러/서비스/DAO)가 실행됩니다. DB가 필요하면 커넥션 풀에서 커넥션을 얻고 JDBC 드라이버로 SQL을 보내며, DB 엔진이 실행 결과를 반환합니다.

그림 4. 요청 → 코드 → 풀/JDBC → DB 쿼리 흐름

참고 레퍼런스

심화) WAS 내부 동작과 DB 쿼리, JDBC/ODBC, APM 계측 포인트

1) WAS ↔ DB 간 상세 동작 및 쿼리 구성

WAS ↔ DB 사이에 보이는 것(ORM/JDBC/커넥션풀)은
대부분 “WAS 내부 자원(라이브러리/리소스 관리)”이며, 보통 이를 별도 Tier로 분리하지는 않습니다.

2) WAS는 “코드를 대신 실행”하는 게 아니라 “요청을 코드로 전달”

Tomcat/JEUS 같은 WAS는 간단히 말해 요청을 처리할 수 있는 실행 환경(컨테이너)입니다.

즉, “WAS가 알아서 비즈니스 로직을 만든다”가 아니라,

우리가 배포한 애플리케이션(WAR/EAR/JAR)의 코드를 실행할 수 있게 요청을 받아서

적절한 지점 (서블릿/프레임워크 엔트리)으로 전달합니다.

그림 1. WAS 내부에서 요청이 ‘코드’를 거쳐 DB로 나가는 실제 흐름

상세 Step별로 정리하면,

① HTTP 요청 수신: Web 서버(Nginx)가 전달한 요청을 WAS의 커넥터가 받습니다.
② 스레드 할당: WAS는 스레드 풀에서 스레드 하나를 할당해 “이 요청 담당자”로 세웁니다.
③ 서블릿/필터(프레임워크 엔트리): 요청이 필터/서블릿/디스패처(예: Spring DispatcherServlet)로 전달됩니다.
④ 비즈니스 로직: 컨트롤러/서비스 코드가 실행되며 인증/권한/규칙/외부 호출 등을 처리합니다.
⑤ DAO/ORM: DB가 필요하면 DAO 계층 또는 ORM(MyBatis/JPA 등)을 통해 SQL을 만들거나 매핑합니다.
⑥ 커넥션 풀: HikariCP/DBCP 같은 풀이 “DB 연결(커넥션)”을 빌려주고 반납받습니다.
⑦ JDBC 드라이버: 실제로 DB와 통신(prepare/execute 등)을 수행하는 라이브러리입니다.
⑧ DB 엔진: DB가 SQL을 실행하고 결과를 반환합니다(플랜/락/IO/트랜잭션).

3) JDBC/ODBC는 뭐고, 왜 APM 연동에서 자꾸 나오나?

3‑1. JDBC / ODBC를 한 문장으로

JDBC: Java에서 DB로 SQL을 보내는 표준 방식 (대부분 Java WAS는 JDBC)
ODBC: 언어/플랫폼 범용 DB 접근 표준 (툴/윈도우/일부 언어에서 흔함)

3‑2. “드라이버가 중요하다”의 진짜 뜻

APM은 보통 DB 서버를 직접 ‘마법처럼’ 보는 게 아니라,
애플리케이션이 DB에 접근할 때 사용하는 드라이버/커넥션풀 호출 지점을 가로채서(계측해서)
SQL 시간, 에러, 풀 대기시간 같은 값을 만들어냅니다.

그래서 현업에서 “JDBC/ODBC가 뭔지 확인해야 한다”는 말은, 보통 아래를 확인하자는 뜻입니다.

어떤 드라이버를 쓰는가? (예: Oracle이면 ojdbc, MySQL이면 mysql-connector-j 등)
어떤 커넥션 풀을 쓰는가? (HikariCP/DBCP 등) → “DB가 느린 게 아니라 풀에서 기다리느라 느린” 경우가 많습니다.
우회/브리지 구조가 있는가? (예: Java인데 ODBC 브리지를 거치거나 프록시가 끼는 구조) → APM이 보는 지점이 달라질 수 있습니다.

4) APM은 어디를 계측해서 보여주나

그림 2. APM이 흔히 훅(hook)을 거는 지점

4‑1. 그래서 운영 화면에 보이는 값들의 의미

화면에 보이는 항목	대개 어디서 측정되는가	해석 포인트
트랜잭션 응답시간	요청 진입 ~ 응답까지(서블릿/프레임워크 훅)	전체가 느리면 먼저 “DB/외부 호출/풀 대기”로 분해해서 봅니다.
DB 시간/슬로우쿼리	JDBC execute 구간(드라이버 훅)	실제 실행이 느린지, 호출이 잦은지(빈도) 함께 봅니다.
커넥션 풀 대기	풀에서 커넥션을 얻기까지의 대기시간	DB가 정상인데도 느리면 “풀 크기/타임아웃/트래픽 급증”을 의심합니다.

5) 언어/런타임 확인 (운영자가 가장 빠르게 확인하는 방법)

요약
WAS는 “요청을 받아 스레드에 할당하고 애플리케이션 코드로 전달”하고,
애플리케이션은 ORM/DAO → 커넥션 풀 → JDBC 드라이버를 통해 DB로 SQL을 보내며,
APM은 이 구간을 계측해 “어디가 느린지”를 분해해서 보여줍니다.

참고 레퍼런스

'Tech Note > 개요 (개발)' 카테고리의 다른 글

4. 내부 마이크로서비스와 웹 프레임워크(Flask·Django·FastAPI) (1)	2026.01.15
3. 3‑Tier(Web–WAS–DB)로 보는 프론트·백·DB·프레임워크 (1)	2026.01.10
2. Node.js 운영 입문 - nvm or docker? (1)	2026.01.09
1. 초보 개발자들의 학습 순서 (1)	2026.01.04

WAS의 종류 및 역할

1) 3‑Tier 구성에서 WAS의 역할, 존재의 이유

WAS가 특히 필요한 순간(운영자 관점)

2) WAS의 종류 및 분류

2‑1. 제품군 별 분류 및 특징

3) APM 연동 솔루션 소개 (운영에 도움 되는 최신 솔루션들)

3‑1. 대표적인 운영 솔루션 카테고리 (예시)

3‑2. 연동 시 꼭 확인할 점(필수만)

3‑3. JDBC/ODBC 란?

부록) Tomcat/JEUS에서 요청이 DB 쿼리로 나가는 상세 흐름

참고 레퍼런스

심화) WAS 내부 동작과 DB 쿼리, JDBC/ODBC, APM 계측 포인트

1) WAS ↔ DB 간 상세 동작 및 쿼리 구성

2) WAS는 “코드를 대신 실행”하는 게 아니라 “요청을 코드로 전달”

상세 Step별로 정리하면,

3) JDBC/ODBC는 뭐고, 왜 APM 연동에서 자꾸 나오나?

3‑1. JDBC / ODBC를 한 문장으로

3‑2. “드라이버가 중요하다”의 진짜 뜻

4) APM은 어디를 계측해서 보여주나

4‑1. 그래서 운영 화면에 보이는 값들의 의미

5) 언어/런타임 확인 (운영자가 가장 빠르게 확인하는 방법)

참고 레퍼런스

'Tech Note > 개요 (개발)' 카테고리의 다른 글

티스토리툴바