Spring Boot 버전 선택: Java·Jakarta·지원 기간으로 고르는 법

Spring Boot 버전은 기능 목록을 오래 비교하기보다 현재 지원되는 release line, Java 기준선, 의존하는 Spring 생태계의 호환성, major migration 비용으로 고르는 편이 안전하다. 새 프로젝트라면 오래된 글의 추천 숫자를 복사하지 말고 Spring Initializr가 제공하는 stable version에서 시작하는 것이 기본이다.

2026년 8월 2일 공식 Spring Initializr metadata를 확인했을 때 stable 선택지는 4.1.0과 4.0.7이었다. 현재 Spring Boot 4.1.0은 Java 17 이상을 요구하고 Java 26까지 호환되며, Spring Framework 7.0.8 이상을 사용한다. 이 숫자는 시간이 지나면 바뀌므로 실제 프로젝트를 만들 때 Spring Initializr와 System Requirements를 다시 확인해야 한다.

새 프로젝트와 기존 프로젝트의 답이 다르다

상황	우선 판단
새 프로젝트, 주요 라이브러리가 Boot 4 지원	Initializr의 최신 stable minor와 최신 patch를 우선 검토한다.
Boot 4.0 운영 중	4.1 release note와 deprecation·dependency 변경을 확인한 뒤 minor upgrade를 검증한다.
Boot 3.x 운영 중	먼저 최신 3.5.x로 정리한 뒤 Boot 4 migration guide 순서를 따른다.
Boot 2.x 또는 javax.* 의존이 많음	Java 17, jakarta.*, Spring Framework 6/7 전환을 별도 migration으로 계획한다.
Spring Cloud·보안·데이터 제품과 강결합	해당 프로젝트의 compatibility matrix가 지원하는 Boot line을 먼저 확인한다.

최신 버전이 항상 무조건 정답이라는 뜻은 아니다. 새 버전의 이점보다 호환되지 않는 핵심 dependency와 migration risk가 더 크면 한 단계 이전의 아직 지원되는 line을 선택할 수 있다. 다만 이미 지원이 끝난 버전을 편의상 새 프로젝트의 기준으로 삼는 것은 security patch와 ecosystem 호환 비용을 뒤로 미루는 결정이다.

Java 버전만 맞으면 되는 것이 아니다

원문은 토이 프로젝트에서 Java 17을 쓰기 위해 Spring Boot 2.5.5 이상을 선택할지 고민한 기록이었다. 당시의 호환성 질문으로는 의미가 있었지만, 그 숫자를 지금 새 프로젝트의 기준으로 재사용할 수는 없다.

버전 선택에는 최소 네 층이 함께 맞아야 한다.

1. JDK: 실행·compile 대상 Java와 CI·container image의 Java가 일치하는가?
2. Spring Boot: 해당 minor가 현재 security·critical bug 지원 대상인가?
3. Spring portfolio: Spring Cloud, Security, Data, Batch 등 필요한 release train이 호환되는가?
4. third-party library: ORM, DB driver, observability agent와 사내 starter가 새 major를 지원하는가?

Java만 올리고 Boot를 그대로 두거나, Boot만 올리고 build tool과 agent를 확인하지 않으면 compile은 되더라도 test·runtime에서 문제가 드러날 수 있다. Java 자체의 변화는 자바 버전별 특징과 함께 보는 편이 좋다.

Spring Boot 4에서 달라진 큰 경계

Spring Boot 4 migration guide가 요구하는 핵심 기준선은 다음과 같다.

• Java 17 이상
• Spring Framework 7.x
• Jakarta EE 11
• Servlet 6.1
• Gradle 8.14 이상 또는 9.x, Maven 3.6.3 이상
• 더 세분화된 Boot module과 starter 구성
• Jackson 3을 기본으로 한 migration 고려

특히 Boot 2에서 바로 넘어오는 프로젝트라면 javax.*에서 jakarta.*로 바뀐 namespace가 큰 경계다. 단순히 plugin version 한 줄만 바꾸는 upgrade가 아니다. Boot 4에서는 starter 이름과 package 배치도 달라질 수 있어 직접 import한 auto-configuration API나 사내 starter가 많을수록 영향이 커진다.

Spring 팀은 Boot 3.x에서 4.0으로 갈 때 먼저 최신 3.5.x로 올리고 deprecated API를 제거한 뒤 migration하라고 안내한다. 한 번에 여러 major와 dependency를 함께 바꾸기보다 실패 원인을 분리할 수 있는 순서다.

버전을 고르는 실제 순서

1. 실행 환경부터 적는다

다음 항목을 먼저 고정한다.

• production에서 허용하는 JDK와 container base image
• 빌드 도구와 CI runner
• 배포 대상의 Servlet container 또는 native image 필요 여부
• 반드시 써야 하는 Spring Cloud release train과 third-party starter
• security support가 필요한 기간

2. 현재 상태를 명령으로 확인한다

Gradle 프로젝트라면 wrapper와 runtime dependency tree부터 본다.

./gradlew --version
./gradlew dependencies --configuration runtimeClasspath

Maven 프로젝트라면 다음처럼 확인할 수 있다.

./mvnw --version
./mvnw dependency:tree

IDE가 보여 주는 JDK와 실제 wrapper가 사용하는 JDK가 다를 수 있으므로 명령 출력의 JVM을 함께 확인한다.

3. 최신 patch를 기준으로 후보를 만든다

Spring Boot는 major를 최소 3년 지원하지만 지원 중인 minor를 사용해야 하며, minor는 최소 12개월 지원하는 정책을 둔다. 따라서 4.x라는 major 숫자만 보고 안전하다고 판단할 수 없다. Supported Versions와 각 release page에서 현재 유지되는 minor를 확인한다.

4. migration을 기능별로 검증한다

• 애플리케이션 context가 뜨는가?
• web·security filter chain이 기존 계약을 지키는가?
• JPA schema validation과 주요 query가 통과하는가?
• JSON 직렬화 결과가 바뀌지 않았는가?
• metric·trace·log agent가 정상 동작하는가?
• container 시작 시간과 memory limit 안에서 동작하는가?

부팅 성능 자체를 다룰 때는 Spring 애플리케이션 부팅 속도 최적화의 측정 항목도 함께 확인할 수 있다.

자주 묻는 질문

Java 17이면 Spring Boot 2.5.5를 써도 될까?

기술적으로 실행 가능한 조합과 새 프로젝트에 권할 조합은 다르다. Boot 2.5는 현재 새 프로젝트의 지원 기준이 아니므로, 재현해야 하는 legacy application이 아니라면 현재 지원되는 Boot line에서 dependency 호환성을 확인하는 편이 안전하다.

Spring Boot 4.1이 나왔으면 4.0은 바로 못 쓰게 되나?

그렇지는 않다. minor마다 지원 기간이 있고 최신 patch가 제공되는 동안 운영할 수 있다. 다만 새 프로젝트라면 이전 minor를 선택할 구체적인 dependency 또는 migration 이유가 있어야 한다.

버전은 latest로 자동 추적하면 될까?

빌드 재현성을 위해 실제 version은 고정해야 한다. 새 patch를 자동으로 바로 production에 적용하기보다 dependency update PR, test, vulnerability scan과 canary 같은 검증 절차를 둔다.

결론

Spring Boot 버전 선택은 “버전별 특징 중 무엇이 좋아 보이는가”가 아니라 다음 질문으로 정리된다.

1. 지금 공식적으로 지원되는 minor인가?
2. 조직이 사용하는 Java와 build tool이 요구사항을 만족하는가?
3. Spring Cloud와 핵심 third-party dependency가 호환되는가?
4. major 경계의 namespace·starter·serialization 변경을 감당할 수 있는가?
5. 최신 patch로 test와 rollback을 검증했는가?

원문의 Java 17 고민은 남기되, 결론은 특정 오래된 숫자에서 현재 지원 정책을 확인하는 절차로 바뀌었다. 버전은 한 번 고르고 잊는 값이 아니라, 지원 종료 전에 다음 line으로 이동할 수 있도록 계속 관리하는 운영 항목이다.

참고 자료

• Spring Boot System Requirements
• Spring Initializr
• Spring Boot 4.1 Release Notes
• Spring Boot 4.0 Migration Guide
• Spring Boot Supported Versions