[Java] Jar 배포와 War 배포의 차이점

Java 기반 웹 애플리케이션 배포 방식은 크게 Jar 배포와 War 배포로 나뉜다. Spring Boot 등장 이후 JAR 방식이 표준이 되었지만, 실무에서는 여전히 WAR 기반 운영 환경도 많다. 또한 JAR 배포 안에서도 방식이 여러 종류로 존재한다. 파악한 내용을 블로그로 작성해두고자 한다.

---

 

1. JAR 배포와 WAR 배포의 개념 차이

1.1 JAR(Java Archive)

JAR 파일은 애플리케이션 전체를 하나의 실행 패키지로 묶은 형태다. Spring Boot에서는 내장 WAS(Tomcat/Jetty/Undertow)를 포함한 실행형 Boot Jar를 만들 수 있다.

즉, JAR 자체가 서버 역할을 한다.

1.2 WAR(Web Application Archive)

WAR 파일은 외부 WAS에 배포되는 형태다. Tomcat·Jeus·WebLogic·JBoss 같은 서버 위에서 로딩된다.

전통적인 Java EE 기반 구조이며, 공공기관이나 레거시 시스템에서 지금도 매우 자주 사용된다.

---

2. JAR 배포 방식의 3가지 유형

Spring Boot는 JAR 배포라고 해서 전부 같은 방식으로 돌아가는 것이 아니다. 실무에서 다음 세 가지가 존재한다.

2.1 Fat Jar 방식

• 의존 라이브러리까지 전부 JAR 내부에 포함한 형태
• 가장 일반적인 Boot Jar
• 실행 명령: java -jar app.jar
• 독립 실행형이며 별도 WAS 필요 없음
• 배포 자동화와 컨테이너 환경에 최적화

2.2 Thin Jar 방식

• 애플리케이션 코드만 JAR에 포함
• 의존 라이브러리는 외부 저장소에서 불러오거나 별도로 배치
• 장점: JAR 파일 자체는 작아짐
• 단점: 의존성을 따로 관리해야 해서 구조가 복잡해짐
• 회사 내부 Maven Repository 등을 사용할 때 쓰이는 경우가 있다.

2.3 Layered Jar 방식

• JAR 내부를 계층(Layer)로 나눠서 패키징
  1. 의존 라이브러리
  2. 스프링 프레임워크 파일
  3. 애플리케이션 리소스
  4. 애플리케이션 클래스
• Docker 이미지 빌드 시 캐시 효율이 극대화됨
• 코드만 수정했을 때 레이어 하나만 다시 빌드하면 되므로 빌드 속도가 빠름
• 스프링 공식 문서에서도 추천하는 배포 전략

---

3. 배포 구조 차이

3.1 JAR

• 내부에 WAS 포함
• 서버는 단순히 Java 실행 환경이면 된다
• 코드 변경 시 JAR 전체 재빌드 필요
• 재시작이 필수

3.2 WAR

• WAS에 업로드하여 실행
• 리소스는 외부 디렉토리로 분리 가능
• JS·CSS 등 정적 파일 교체 시 WAS 재기동 없이 즉시 반영
• 서비스 중단 시간을 줄일 수 있다

---

4. 프런트엔드 연동 관점의 차이

4.1 JAR 방식의 문제 사례

Spring Boot 프로젝트에서 Vue, React를 빌드 후 static 폴더에 넣어 JAR로 묶는 경우가 많다.

이 구조는 다음 문제를 낳는다.

1. 단일 JAR에 프런트와 백엔드가 모두 묶임
2. JS 하나 수정해도 JAR 전체를 다시 빌드해야 한다
3. 운영 서버 재기동이 필수
4. 프런트 소스를 공유하지 않은 상황에서 누군가 퇴사하면(폐쇄망 + Node 버전 불일치 + 빌드 도구 동작 불가)
5. 원본 빌드 자체가 불가능해질 수 있다

실제로 어떤 팀에서는

“백엔드는 스프링, 프런트는 Vue였는데 둘이 소스를 분리하지 않고 JAR에 빌드 파일만 통째로 넣어 배포했다. 담당자 퇴사 후 소스를 확인해보니 Vue 원본이 없어 프런트 수정 자체가 불가능한 상태가 됐다.”

라는 일이 발생하기도 한다.

이 방식은 협업, 유지보수, 이관 모두에 부담을 준다.

4.2 WAR는 프런트/백엔드 분리 운영에 적합

WAS는 정적 리소스를 외부 디렉토리에서 지정하여 로딩하는 형태가 가능하다.

장점:

• JS/CSS 교체 시 서버 재기동 필요 없음
• 프런트 빌드/배포를 백엔드와 완전히 독립
• 서로 다른 팀이 담당해도 문제 없음
• 운영 중 긴급 패치가 빠르다

---

5. 운영 및 배포 편의성 차이

5.1 JAR

• 단일 파일로 단순
• DevOps·CI/CD에 강함
• Docker/K8s 환경 최적화
• 그러나 일부 파일 수정만으로 배포하는 것이 불가능하다

5.2 WAR

• 부분 교체가 용이
• 대규모 레거시 환경에 맞음
• WAS 튜닝, 세션 클러스터링 등 기존 인프라를 그대로 활용 가능
• WAS 버전 차이로 인해 로컬/운영 차이가 발생할 수 있음

---

6. 장단점 총정리

6.1 JAR 장점

• 배포가 단순
• 내장 WAS로 환경 차이가 없다
• Docker 기반 배포에 매우 유리
• 레이어드 Jar 적용 시 빌드 효율이 높다

6.2 JAR 단점

• 정적 리소스 변경에도 전체 재빌드 필요
• 프런트·백엔드 분리 불가 구조일 경우 협업에서 문제
• 운영 서버 재기동 필수
• 소스가 사라지면 복구 불가

---

6.3 WAR 장점

• 정적 파일 교체가 쉽다
• 서버 재시작 없이 프런트 수정 가능
• 팀 단위 역할 분리가 명확
• 레거시·공공기관 환경과 잘 맞는다

6.4 WAR 단점

• WAS 버전/설정 문제 가능
• 배포 동작이 WAS에 종속
• Spring Boot 기본 철학과는 맞지 않는다
• DevOps 자동화는 JAR보다 약함

---

7. 어떤 상황에서 어떤 방식을 선택해야 하는가

JAR 선택

• 신규 서비스
• DevOps 필수
• Docker/K8s 기반
• 백엔드 중심 팀 구성
• 전체를 단일 패키지로 관리하고 싶을 때

WAR 선택

• 프런트 변경이 잦은 서비스
• 프런트/백엔드 팀 분리
• 레거시 WAS 중심 운영
• JS/CSS 핫스왑이 필요한 서비스
• 공공기관 환경에서 기존 인프라 유지가 필요한 경우

---

8. 결론

JAR과 WAR 중 어느 하나가 절대적으로 뛰어난 것은 아니다.

프로젝트 구조, 팀 구성, 운영 환경, 배포 도구, 프런트 구조에 따라 최적 선택이 달라진다.

• JAR은 단일 패키지로 단순하고 현대적인 배포 방식
• WAR은 프런트/백엔드 독립 운영과 레거시 호환에 강력한 방식

Boot Jar 방식(Thin, Fat, Layered)까지 고려하면,

서비스 특성에 맞춰 가장 효율적인 배포 체계를 설계할 수 있다.