프로젝트가 커질수록 “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 + 톰캣이라 생각하면 쉽습니다.

패키징 전략 선택 가이드

  1. 단일 서비스, 클라우드 네이티브JAR
  2. 모놀리식 레거시, 다수 모듈 공존WAR
  3. 컨테이너(Kubernetes) 배포 → 둘 다 가능하지만 JAR가 더 흔함 (이미 톰캣 내장)

2. WAS vs Web Server: 역할 · 스택 관점

구분Web ServerWAS (Web Application Server)
주요 책임• 정적 자원(HTML/CSS/JS, 이미지) 전송
• 프록시·로드밸런싱
• TLS 종단 처리
• 동적 로직 실행 (Servlet/JSP, Spring MVC)
• Servlet Container API 구현
대표 제품Nginx, Apache HTTPD, CaddyTomcat, 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)

왜 둘을 분리할까?

  1. 보안 경계 명확화 – TLS·HTTP 헤더 공격 차단을 웹 서버에서 선제 처리.
  2. 정적 캐싱 – Nginx proxy_cache로 WAS 부하 감소.
  3. 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. 배포·운영 체크리스트

체크 항목JARWAR
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 ProbeTomcat ParallelDeployment or LB Draining
모니터링Micrometer + PrometheusJMX Exporter + Prometheus

5. 결론과 베스트 프랙티스

  1. 서비스 경량화·컨테이너화 시대에는 Fat JAR + 경량 WAS(내장 톰캣) + 리버스 프록시가 기본값.
  2. 레거시 EE·다중 WAR 호스팅 필요 시 외부 WAS + WAR가 여전히 유효.
  3. 웹 서버 분리는 TLS 종단·정적 캐싱·DDoS 방어 등 인프라 관점에서 얻는 이점이 크므로 가능한 한 유지.
  4. 세션 상태는 Redis (or Hazelcast) 등 외부 저장소로 옮겨 Stateless WAS 흐름을 지향.

읽어주셔서 고맙습니다!