프로젝트가 커질수록 “JAR로 배포해야 할까, WAR가 나을까?”,
“Nginx 같은 웹 서버랑 Tomcat 같은 WAS는 뭐가 달라?” 같은 질문이 자주 등장합니다.
이번 글에서는 Jar · War 패키징 형식과 WAS(Web Application Server) · 웹 서버의 근본적인 차이를 한눈에 정리합니다.
1. JAR vs WAR: 패키징 관점
구분 | JAR (Java ARchive) | WAR (Web ARchive) |
---|---|---|
용도 | 자바 애플리케이션·라이브러리 전용 패키지 | 서블릿 기반 웹 애플리케이션 배포 |
표준 디렉터리 | META-INF/ 만 필수 (매니페스트·의존성) | WEB-INF/ 필수 └ classes/ , lib/ , web.xml 등 |
실행 방법 | java -jar app.jar (Spring Boot fat JAR) | WAS에 배포: $CATALINA_BASE/webapps/*.war |
장점 | • 배포 단순, 독립 프로세스 • 컨테이너 불필요 (내장 Tomcat) | • 여러 애플리케이션을 한 WAS에 호스팅 • 전통적 EE 에코시스템 호환 |
단점 | • 애플리케이션마다 JVM · 포트 필요 • Session 공유·로드밸런싱 고민 필요 | • CI/CD 파이프라인 복잡 • WAS 버전 종속 위험 |
Spring Boot ≥ 1.4 임베디드 Tomcat 덕분에
fat JAR = 실행 가능한 WAR + 톰캣
이라 생각하면 쉽습니다.
패키징 전략 선택 가이드
- 단일 서비스, 클라우드 네이티브 → JAR
- 모놀리식 레거시, 다수 모듈 공존 → WAR
- 컨테이너(Kubernetes) 배포 → 둘 다 가능하지만 JAR가 더 흔함 (이미 톰캣 내장)
2. WAS vs Web Server: 역할 · 스택 관점
구분 | Web Server | WAS (Web Application Server) |
---|---|---|
주요 책임 | • 정적 자원(HTML/CSS/JS, 이미지) 전송 • 프록시·로드밸런싱 • TLS 종단 처리 | • 동적 로직 실행 (Servlet/JSP, Spring MVC) • Servlet Container API 구현 |
대표 제품 | Nginx, Apache HTTPD, Caddy | Tomcat, Jetty, Undertow, WebSphere |
프로토콜 | HTTP 1/2, TLS, gRPC-web(역할) | Servlet API 4.0+, WebSocket, JASPIC |
스레드 모델 | 논블로킹 (event-loop) or Prefork | 자바 스레드 풀 (Request-Thread Mapping) |
확장 방식 | 리버스 프록시 → 다중 WAS 노드 | 클러스터링 세션 레플리케이션 (Sticky Session or Redis) |
왜 둘을 분리할까?
- 보안 경계 명확화 – TLS·HTTP 헤더 공격 차단을 웹 서버에서 선제 처리.
- 정적 캐싱 – Nginx
proxy_cache
로 WAS 부하 감소. - Scale-out 유연성 – 웹 서버는 L4/L7 로드밸런서처럼 다수 WAS 노드로 트래픽 분산.
컨테이너 환경에서는
nginx-sidecar + spring-boot jar
조합이 사실상의 표준 패턴입니다.
3. 현대 아키텍처에서의 조합 패턴
3.1 Fat JAR + Nginx (가장 흔함)
- 장점: JAR마다 버전을 독립적으로 관리, Blue-Green 배포 용이
- 주의: 세션 공유 필요 시 Redis, Spring Session 연동
3.2 WAR 배포 + Tomcat Cluster
- 장점: 전통적인 기업 WAS 운영팀 프로세스에 적합
- 주의:
server.xml
·context.xml
세션 Cluster 설정 필수
4. 배포·운영 체크리스트
체크 항목 | JAR | WAR |
---|---|---|
CI 파이프라인 | ./gradlew bootJar | ./gradlew war && scp |
Dockerfile 예시 | FROM eclipse-temurin:21-jre … CMD ["java","-jar","app.jar"] | FROM tomcat:10-jdk21 … COPY app.war /usr/local/tomcat/webapps/ |
무중단 배포 | 쿠버네티스 Readiness Probe | Tomcat ParallelDeployment or LB Draining |
모니터링 | Micrometer + Prometheus | JMX Exporter + Prometheus |
5. 결론과 베스트 프랙티스
- 서비스 경량화·컨테이너화 시대에는 Fat JAR + 경량 WAS(내장 톰캣) + 리버스 프록시가 기본값.
- 레거시 EE·다중 WAR 호스팅 필요 시 외부 WAS + WAR가 여전히 유효.
- 웹 서버 분리는 TLS 종단·정적 캐싱·DDoS 방어 등 인프라 관점에서 얻는 이점이 크므로 가능한 한 유지.
- 세션 상태는 Redis (or Hazelcast) 등 외부 저장소로 옮겨 Stateless WAS 흐름을 지향.
읽어주셔서 고맙습니다!