Spring Boot 번들(.jar) 크기 최적화 전략

개요

Spring Boot 애플리케이션은 편의성 덕분에 많은 라이브러리를 한 번에 포함하는 경향이 있다. 하지만 배포 번들(.jar) 크기가 커지면 전송 비용, 시작 시간, 컨테이너 이미지 크기까지 악영향을 미친다. 본문에서는 초보자도 이해하기 쉽게 의존성과 리소스 관점에서 번들 사이즈를 줄이는 방법을 정리한다.

왜 번들 크기를 줄여야 하나

번들 크기는 단순한 수치 이상의 의미를 가진다. 작은 번들은 네트워크 전송과 이미지 레이어를 줄이며 애플리케이션 시작 속도를 개선한다. 클라우드 환경에서 비용과 안정성 측면에서 긍정적인 효과가 있다.

분석: 현재 번들 구성 파악

1) JAR 내용 확인

우선 생성된 JAR 파일 내부를 확인해 어떤 라이브러리와 리소스가 포함됐는지 파악한다.

jar tf build/libs/app.jar | sort

2) 의존성 분석 도구 사용

Maven과 Gradle은 의존성 트리와 사용하지 않는 의존성을 찾아주는 플러그인을 제공한다. 이를 통해 중복이나 불필요한 라이브러리를 발견할 수 있다.

mvn dependency:tree
mvn dependency:analyze

./gradlew dependencies --configuration runtimeClasspath

의존성 최적화

1) 스타터 과용 피하기

spring-boot-starter는 관련 라이브러리를 묶어 제공한다. 편리하지만 필요 없는 모듈까지 포함될 수 있다. 사용하지 않는 기능이 포함된 스타터는 개별 의존성으로 대체해 필요한 것만 추가한다.

2) 범위(scope)·configuration 조정

테스트 전용 라이브러리는 테스트 범위로, 애플리케이션 서버에서 제공되는 라이브러리는 provided로 설정하면 번들에서 제외된다.

<dependency>
  <groupId>javax.servlet</groupId>
  <artifactId>javax.servlet-api</artifactId>
  <version>4.0.1</version>
  <scope>provided</scope>
</dependency>

3) 중복·전이 의존성 제거

transitive dependency로 인해 같은 라이브러리가 여러 버전으로 포함될 수 있다. 불필요한 전이를 exclude 하거나 버전 정리를 통해 중복을 제거한다.

<dependency>
  <groupId>com.example</groupId>
  <artifactId>example-client</artifactId>
  <version>1.2.3</version>
  <exclusions>
    <exclusion>
      <groupId>org.unused</groupId>
      <artifactId>unused-lib</artifactId>
    </exclusion>
  </exclusions>
</dependency>

4) 라이트웨이트 대안 탐색

특정 기능을 위해 무거운 라이브러리를 사용했다면 더 가벼운 대안을 찾는다. 예를 들어 JSON 처리에 Jackson 대신 적은 기능만 쓰는 경우 다른 경량 라이브러리를 고려할 수 있다.

리소스 최적화

1) 불필요한 정적 리소스 제거

리소스 폴더(src/main/resources)에 사용하지 않는 파일이 남아 있지 않은지 확인한다. 이미지, 샘플 데이터, 미사용 설정 파일을 정리하면 의외로 큰 효과가 있다.

2) 리소스 압축 및 Minification

웹 애셋(css, js, html)은 빌드 시 압축한다. Maven이나 Gradle에서 플러그인을 사용해 빌드 과정에 minification을 추가하면 자동화된다.

빌드·패키징 전략

1) 실행 가능한 JAR 대신 레이어드 이미지 사용

Spring Boot의 레이어드 JAR 기능을 사용하면 의존성 레이어와 애플리케이션 레이어를 분리해 컨테이너 이미지 빌드 시 재사용을 높일 수 있다. Docker 레이어 캐싱을 통해 빈번한 빌드에서 전송 데이터가 줄어든다.

2) Thin launcher 또는 외부 종속성 관리

spring-boot-thin-launcher 같은 접근은 실행 시점에 의존성을 다운로드하게 해 번들 크기를 작게 유지할 수 있다. 단, 네트워크 환경과 시작 시간 트레이드오프를 고려해야 한다.

3) JLink로 런타임 최소화 (Java 11+)

애플리케이션이 사용하는 JDK 모듈만 포함한 커스텀 런타임을 만들면 전체 배포 크기를 줄일 수 있다. 특히 네이티브 이미지 빌드와 조합하면 효과가 크다.

4) 빌드 예제 (Gradle)

plugins {
  id 'org.springframework.boot' version '2.5.4'
  id 'io.spring.dependency-management' version '1.0.11.RELEASE'
}

configurations {
  providedRuntime
}

dependencies {
  implementation 'org.springframework.boot:spring-boot-starter-web'
  providedRuntime 'org.springframework.boot:spring-boot-starter-tomcat'
}

검증과 측정

변경 전후의 JAR 크기, 컨테이너 이미지 크기, 시작 시간(Cold start)과 메모리 사용량을 측정해 개선 효과를 수치로 확인한다. CI 파이프라인에 번들 크기 기준을 추가하면 퇴보를 방지할 수 있다.

결론

번들 사이즈 최적화는 의존성 관리부터 리소스 정리, 빌드 전략까지 연쇄적인 작업이다. 단계별로 분석하고 작은 변경을 반복하면 시작 시간과 배포 비용을 줄일 수 있다. 제시한 방법을 우선순위에 따라 적용하면 실무에서 실질적 개선을 기대할 수 있다.

목차

개요