JAR vs WAR, 그리고 WAS의 관계
스프링 부트(Spring Boot) 기반 애플리케이션을 AWS, EC2, 또는 자체 서버에 배포할 때 “JAR? WAR? WAS?” 이 세 개념이 많이 헷갈렸다.
설명에는 “그냥 빌드만 하면 된다”고 하지만, 실제 운영환경에서는 이 차이를 정확히 이해해야 장애 없이 배포가 가능하므로 이렇게 정리해보려고 한다.
1. JAR — 독립 실행 가능한 패키지
JAR와 내장 톰캣
전통적인 웹 애플리케이션(WAR)은 개발자가 만든 코드만 압축하여 별도의 외부 웹 애플리케이션 서버(WAS, 예를 들어 톰캣 설치 파일)에 올려서 실행해야 했다.
반면, 스프링 부트 애플리케이션의 실행 가능한 JAR(Executable JAR)는 다음과 같은 구조이다.
- 개발자가 작성한 애플리케이션 코드
- 스프링 프레임워크 라이브러리
- 내장된 웹 서버 (주로 Apache Tomcat, Jetty 또는 Undertow)
(이 모든 것이 하나의 거대한 JAR 파일 안에 포함되어 있음)
정의: 일반 자바 애플리케이션을 패키징한 .jar 파일.
Spring Boot 특징:
- 내장 웹 서버(embedded WAS — Tomcat, Jetty, Undertow 중 하나)를 포함.
- 별도 WAS 설치 없이
java -jar myapp.jar하나로 실행 가능.
장점:
- 환경 의존성이 낮고, 어디서나 동일하게 동작
- 별도의 WAS 설치나 구성이 필요 없음, WAS 버전에 대한 의존성 문제가 줄어듦
- 어느 환경에서든 동일한 방식으로 실행
- Docker, CI/CD, 클라우드 배포에 최적화
- 배포 파이프라인 단순화
- 단일 실행 파일
java -jar your-app.jar명령 하나로 애플리케이션을 즉시 실행 가능
- 마이크로서비스 아키텍처에 적합
- 배포와 실행이 간편해 컨테이너 환경(Docker 등)에 적재하기 매우 용이요약하자면, JAR 파일 자체가 서버의 역할을 할 수 있도록 필요한 모든 요소를 가지고 있는 '자기 완결적(self-contained)'인 패키지다.
단점 / 주의:
- JSP / JSP-Servlet 기반의 레거시 웹앱과는 호환성이 낮을 수 있음.
- 기존 WAS 정책이 있는 조직에서는 적용이 어려움
2. WAR — 외부 WAS 위에서 동작하는 웹 애플리케이션
WAR 파일의 목적은 "배포될 준비가 된 웹 애플리케이션의 내용물"을 표준화된 형식으로 묶는 것이다.
이 파일은 반드시 외부에 별도로 설치된 WAS(예: Apache Tomcat, Jetty, WebLogic 등)에 배포(설치)되어야만 실행될 수 있다.
WAS가 WAR 파일의 압축을 풀고 그 안에 있는 서블릿과 JSP를 실행시켜 주는 역할을 한다.
- JSP, 서블릿 클래스, HTML, CSS, JS 같은 정적 리소스
- 필요한 라이브러리(.jar 파일들)
정의: .war 파일은 웹 애플리케이션 전용 아카이브.
동작 방식:
- 외부 WAS(Server like Tomcat, Jetty 등)가 설치된 서버에 배포
- WAS가 WAR를 읽고 풀어서 애플리케이션을 실행
장점:
- 기존 WAS 기반 레거시 시스템과 호환성 유지
- 하나의 서버에 여러 앱 배포 가능
- JSP, 전통 웹 기술 스택 유지 가능
단점:
- WAS 설치/관리 필요 → 설정, 권한, 포트 관리 복잡
- 배포 + WAS 구성 + 운영 자동화 작업 추가 필요
3. WAS (Web Application Server) — WAR를 돌리는 서버
정의: 웹 애플리케이션(WAR)의 실행 환경을 제공하는 서버.
기능:
- HTTP 요청 수신 + 정적/동적 리소스 제공
- 서블릿 컨테이너 (Servlet / JSP / Filter / Session)
- 보안, 세션 관리, 로깅, 멀티 웹앱 호스팅 등 웹 애플리케이션 서비스 환경
언제 사용하나?
- 회사 인프라가 외장 WAS 기반일 때
- 여러 개의 WAR를 한 서버에서 관리해야 할 때
- 전통적인 자바 웹앱 + 레거시 연속성을 유지해야 할 때
쉽게 이해하려면: “WAS = 웹앱을 실행해주는 웹 서버 + 서블릿 컨테이너”라고 생각하면 됨.
4. 언제 JAR / 언제 WAR + WAS를 쓸 것인가?
| 상황 / 요구 | 추천 방식 |
|---|---|
| 마이크로서비스, 컨테이너(Docker), 클라우드 배포, 독립 서비스 | JAR + Embedded WAS |
| 기존 레거시 웹앱, JSP/Servlet 사용, 여러 웹앱 공존, 기업 정책 | WAR + External WAS |
| 빠른 배포, CI/CD, 운영 자동화, 환경 독립성 | JAR 방식 |
| 여러 애플리케이션을 한 서버에서 운용해야 할 때 | WAR + Tomcat 등 WAS |
5. Maven / Gradle 설정 예시
<!-- pom.xml에서 JAR(default) -->
<packaging>jar</packaging><!-- WAR로 바꾸려면 아래처럼 -->
<packaging>war</packaging>// build.gradle 예시 (Gradle 기반)
plugins {
id 'org.springframework.boot' version '3.5.6'
id 'java'
id 'war'
}WAR로 전환 시 SpringBootServletInitializer 상속 필요 (외장 WAS 배포용)
6. AWS + CI/CD 기반 실전 배포 전략
방식 흐름 예시 JAR + 내장 톰캣 Git push → CI(Jenkins/GitHub Actions) → mvn package→ 생성된app.jar→ Docker 이미지 생성 → AWS ECS / EC2에 배포 →java -jar또는 컨테이너 실행WAR + 외장 톰캣 Git push → CI → mvn package(war) → SCP / FTP / Deploy plugin → EC2 Tomcat webapps → 톰캣 재시작 또는 자동 배포 → 웹 앱 실행
7. 주의해야 할 점
-
JSP 사용 + JAR 방식 → 호환성 문제 생길 수 있음!
-
외장 WAS는 설정·권한·포트 충돌 관리 필요
-
JAR 방식은 설정 환경변수나 프로퍼티 관리가 중요 (env, config 파일, secrets 등)
-
CI/CD + Docker + JAR 조합은 “현대적인 배포 + 안정 + 단순화”를 동시에 챙길 수 있음
8. 정리
“어떤 방식이 더 낫다”는 정답은 없다. 요구사항과 환경에 맞추는 것 — 그리고 그 선택이 무엇인지 아는 것이 훨씬 중요하다.
“JAR + Embedded WAS” ← 현대적, 단순, 클라우드 친화
“WAR + External WAS” ← 전통, 레거시 호환, 여러 앱 공존
🔹오늘의 나는 무엇을 잘했는지
JAR/WAR 개념이 헷갈렸는데, 관련 문서를 정리하며 전체 흐름을 스스로 이해하려고 노력했다.
🔹어떤 문제를 겪었고, 어떻게 해결할지
Tomcat이 /usr/local/tomcat10/bin/setclasspath.sh를 찾지 못해 계속 오류가 발생했다. 검색 끝에 심볼릭 링크가 잘못 연결된 걸 확인하고 절대경로 재설정으로 해결 방향을 잡았다.
🔹오늘 배운 것 (학습)
JAR vs WAR의 근본적인 차이와, 배포 환경에 따라 왜 사용 방식이 달라지는지 배웠다. 그리고 Spring Boot JAR는 내장 WAS를 포함하고, WAR는 외장 WAS(Tomcat 등)가 있어야 한다는 점을 정리했다.
🔹좋았던 점 & 아쉬웠던 점
문제의 원인을 끝까지 캐면서 실제 서버 환경에서의 디렉토리 관리 실력을 키울 수 있었다. 다만, Tomcat 구조를 정확히 파악하지 못한 상태에서 시도하다 보니 해결까지 시간이 오래 걸려 아쉬웠다.
🔹나만의 팁 or 복습 방법
서버 파일 구조를 폴더 트리 형태로 정리해두면 나중에 문제 생겼을 때 훨씬 빠르게 원인을 찾을 수 있다. 개념이 헷갈리면 JAR/WAR처럼 표·비교·그림으로 정리하면 훨씬 이해가 쉬워진다.
