Spring Boot 실무 가이드 · Part 14

버전과 업그레이드 판단

언제 올려야 하고 무엇이 깨지는지 근거를 갖고 판단하기

작성 기준2026년 7월버전과 지원 현황은 이후 달라질 수 있으니 공식 문서를 함께 확인하세요.

이 파트에서 다루는 내용

지원 정책현재 지원 현황버전별 전환 비용업그레이드 절차
01

지원 기간에는 구조가 있습니다

Spring Boot는 마이너 버전마다 최소 12개월의 오픈소스 지원을 제공하고, 메이저 라인은 최소 3년간 유지됩니다. 지원이 끝나면 보안 패치가 오픈소스로는 제공되지 않습니다.

지원 종료가 곧 동작 중단은 아닙니다. 애플리케이션은 계속 돌아갑니다. 문제는 취약점이 발견됐을 때 공식 수정본을 받을 수 없다는 것입니다.

오픈소스 지원
무료

정해진 기간 동안 버그 수정과 보안 패치가 공개됩니다. 대부분의 조직이 이 기간 안에 있어야 합니다.

상용 지원
유료 연장

오픈소스 지원이 끝난 버전도 상용 계약으로 보안 패치를 받을 수 있습니다. 당장 올리기 어려운 대형 시스템의 선택지입니다.

지원 종료의 실제 위험
보안·감사

취약점 대응 불가에 더해, 보안 감사나 발주처 점검에서 지적 사항이 됩니다. 공공·금융에서는 특히 문제가 됩니다.

02

2026년 7월 기준 현황

지금 어떤 버전을 쓰고 있는지에 따라 대응이 달라집니다. 아래는 조사 시점 기준이며, 판단 전에 공식 릴리스 정보를 다시 확인해야 합니다.

2.7 이하
지원 종료

오픈소스 지원이 끝난 지 오래됐습니다. 신규 개발은 물론 유지보수도 위험 구간입니다. 3.x 이상으로 올리는 계획이 필요합니다.

3.5.x
2026-06-30 OSS 종료

최종 오픈소스 릴리스 이후 공개 패치가 끊겼습니다. 상용 지원은 남아 있지만, 오픈소스만 쓴다면 4.x 이동을 검토할 시점입니다.

4.0.x
지원 중

2025년 11월 릴리스입니다. Spring Framework 7 기반이며 모듈 분리와 Jackson 3 전환이 포함됩니다.

4.1.x
최신

2026년 6월 릴리스입니다. 신규 프로젝트라면 이 라인에서 시작하는 것이 자연스럽습니다.

확인 방법

지원 종료일은 바뀔 수 있습니다. 프로젝트 계획을 세울 때는 이 문서가 아니라 Spring 공식 릴리스 정보를 근거로 삼아야 합니다. 코스 목차 하단의 참고 자료에 링크가 있습니다.

03

2.x에서 3.x는 큰 공사입니다

메이저 전환 중 가장 부담이 큰 구간입니다. 코드 수정 범위가 넓고, 사용하는 라이브러리가 모두 대응돼 있어야 합니다.

javax → jakarta
전면 수정

패키지 이름이 바뀌었습니다. 엔티티, 검증 애노테이션, 서블릿 관련 임포트를 모두 고쳐야 합니다. 자동 변환 도구가 있지만 검증은 필요합니다.

Java 17 이상
런타임 조건

운영 서버의 JDK를 먼저 올려야 합니다. 서버 담당 부서와 일정 조율이 필요한 경우가 많습니다.

Hibernate 6
쿼리 검증

생성되는 SQL과 일부 매핑 기본값이 달라졌습니다. 기존 쿼리 결과를 반드시 재검증해야 합니다.

Spring Security 6
설정 재작성

기존 설정 방식이 제거됐습니다. SecurityFilterChain 빈 방식으로 다시 작성해야 합니다.

04

3.x에서 4.x는 범위가 좁지만 함정이 있습니다

Jackson 3
직렬화 변화

JSON 처리 라이브러리가 바뀌었습니다. 날짜 형식, null 처리, 설정 속성 이름이 달라질 수 있어 API 응답을 비교 검증해야 합니다.

모듈 분리
의존성 조정

자동 설정이 기술별 모듈로 나뉘었습니다. 필요한 모듈이 빠지면 기동 시점에 설정이 적용되지 않습니다.

@MockBean 제거
테스트 코드

3.4에서 사용 중단, 4.0에서 제거됐습니다. @MockitoBean으로 바꿔야 하며 패키지도 다릅니다.

Spring Security 7
문법 제한

람다 DSL만 지원합니다. 예전 체이닝 문법이 남아 있으면 컴파일되지 않습니다.

연동 라이브러리
가장 흔한 병목

MyBatis 스타터처럼 외부에서 제공하는 연동 모듈이 해당 버전을 지원하는지 먼저 확인해야 합니다. 여기서 막히는 경우가 많습니다.

05

업그레이드는 절차로 진행합니다

  • 1. 현재 버전의 최신 패치로 먼저 올립니다. 같은 마이너 안에서는 위험이 가장 적습니다.
  • 2. 사용 중인 외부 라이브러리와 연동 스타터의 대상 버전 지원 여부를 확인합니다.
  • 3. 릴리스 노트와 마이그레이션 가이드에서 제거·변경 항목을 목록으로 뽑습니다.
  • 4. 별도 브랜치에서 한 단계씩 올립니다. 2.7에서 4.x로 한 번에 건너뛰지 않습니다.
  • 5. 테스트를 돌리고, 자동 테스트가 없는 영역은 수동 검증 항목을 정리합니다.
  • 6. API 응답 형식과 쿼리 결과를 이전 버전과 비교합니다.
  • 7. 롤백 절차를 확인한 뒤 배포합니다.
지금 올려야 하는 경우
판단
  • 현재 버전의 오픈소스 지원이 끝났다
  • 보안 취약점 대응이 필요하다
  • 보안 감사나 발주처 점검 대상이다
  • 새 기능이 상위 버전에만 있다
미뤄도 되는 경우
판단
  • 현재 버전이 지원 기간 안에 있다
  • 연동 라이브러리가 아직 대응되지 않았다
  • 검증할 테스트가 부족해 위험이 더 크다
  • 직전에 대형 배포가 예정돼 있다
미루기로 했다면
관리

그냥 두는 것과 미루는 것은 다릅니다. 언제 다시 검토할지 시점을 정하고, 지원 종료일을 일정에 등록해 둡니다.

실무 기준

업그레이드에서 가장 흔한 실패는 기술 문제가 아니라 계획 문제입니다. 한 번에 여러 단계를 건너뛰고, 검증 항목을 정하지 않고, 롤백 준비 없이 배포하면 원인을 찾을 수 없는 장애가 됩니다. 한 단계씩, 비교 가능한 상태로 진행합니다.

버전

3.x와 4.x 차이

본문은 현장에서 가장 많이 쓰는 3.x 기준입니다. 4.x에서 달라진 부분만 아래에 정리합니다.

  • 이 파트의 지원 현황은 2026년 7월 조사 시점 기준입니다. 지원 일정은 변경될 수 있으므로 실제 판단에는 공식 정보를 사용합니다.
  • 메이저 버전은 최소 3년, 마이너 버전은 최소 12개월의 오픈소스 지원이 기준입니다.
  • Spring Boot 4.x는 최소 Java 17을 요구하며 Java 25·26 환경에서도 동작합니다. Java를 함께 올릴지는 별도 판단 항목입니다.
체크

이 파트 완료 기준