DevOn Boot 버전 업그레이드 체크리스트
DevOn Boot 파트가 매 정기 패치 사이클마다 수행하는 점검 절차를 단계별로 정리합니다. 버전 선정, 릴리즈 노트 분석, 의존성 갱신 경로 구분, AutoConfiguration 점검, OSS 취약점 스캔, 단계적 배포까지 마이너 업그레이드의 공통 점검 항목과 메이저 업그레이드의 추가 점검 항목을 함께 다룹니다.
서론: 버전 번호 뒤에 있는 작업들
앞서 소개한 Spring Boot 릴리즈 주기와 업그레이드 전략에서 DevOn Boot의 M+1 전략을 다뤘다. Spring Boot 마이너 버전 GA 이후 1개월 이내에 호환성이 검증된 대응 버전을 릴리즈한다는 원칙이다. 그런데 "1개월 이내"라는 목표는 그 기간 안에 수행해야 하는 점검 작업이 구체적으로 정의되어 있을 때 의미가 있다.
점검 항목이 구체적으로 정의되어 있지 않으면, 의존성 호환성 확인이 누락되거나 보안 취약점이 잔존한 채로 배포되는 상황이 발생할 수 있다. 특히 Spring Boot 버전 변경에 따라 자동으로 갱신되는 의존성과 수동으로 확인해야 하는 의존성이 구분되어 있지 않으면, 갱신됐어야 할 라이브러리가 이전 버전으로 남거나 런타임에서만 드러나는 동작 변경이 사후에 확인되는 상황으로 이어진다.
이 점검 구조를 사전에 정의해두는 것이 중요한 이유는 업그레이드의 영향도가 버전 성격에 따라 크게 달라지기 때문이다. 마이너·보안 패치는 영향 범위가 상대적으로 좁다. 반면 메이저 업그레이드는 JDK 버전 변경, Java EE 스펙 계층 전환이 수반될 수 있고, 이 경우 프레임워크 내부뿐만 아니라 WAS, 암호화 솔루션 등 유관 시스템의 영향도까지 종합적으로 파악해야 한다. 동시에 OSS 취약점 공격이 증가하면서 엔터프라이즈 환경에서도 빠른 대응에 대한 요구가 높아지고 있으며, 이러한 상황에서 체계적인 점검 구조는 실질적인 완충 역할을 한다.
이 글은 DevOn Boot 파트가 매 정기 패치 사이클마다 공통으로 수행하는 점검 유형과 그 순서를 설명하고, 버전이 바뀔 때마다 반복적으로 확인해야 하는 구조적 점검 범위를 정리한다.
먼저 마이너 버전 업그레이드를 기준으로 반복되는 점검 항목을 정리하고, 이어서 메이저 버전 업그레이드 시 추가로 확인해야 하는 항목을 별도로 다룬다.
패치 수행 흐름
업그레이드는 단일 작업이 아니라 순서가 정해진 다단계 프로세스다. Spring 버전 관리 담당자, OSS 취약점 조치 담당자, 패치 검증 담당자가 각 단계를 분담한다.
단계 별 점검 항목 요약
| 단계 | 주요 점검 항목 |
|---|---|
| 버전 선정 | GA 여부 확인, EOL 일정 검토, 마이너/메이저 구분, Spring Boot·Spring Framework·Spring Cloud 호환성 매트릭스 교차 확인 |
| 분석 및 처리 | 릴리즈 노트 분석 및 Deprecated API·동작 변경 식별, 의존성 경로별 버전 갱신, 빌드 및 단위 테스트, AutoConfiguration 및 MVC 구성 점검, OSS 취약점 스캔 및 조치 |
| 검증 및 배포 | 전체 JUnit 테스트, 프로토타입 앱 통합 검증, Private Nexus 배포, Public Nexus 배포, 버전 suffix 확인 |
1단계: 버전 선정
패치 사이클은 대상 버전을 확정하는 것으로 시작한다. Spring Boot 릴리즈를 그대로 따라가는 게 아니라, 몇 가지 기준을 검토한 뒤 패치 대상 버전과 시점을 결정한다.
- GA 여부 확인: GA(General Availability) 상태가 아닌 버전(RC, Snapshot 등)은 패치 대상에서 제외한다.
- EOL 일정 검토: 해당 버전의 지원 종료 일정을 확인하여 패치 주기 내에 활용 가능한 버전인지 판단한다.
- 마이너/메이저 구분: 버전 성격에 따라 점검 범위와 대응 방식이 달라지므로 사전에 구분한다.
- 호환성 매트릭스 교차 확인: Spring Boot, Spring Framework, Spring Cloud 세 버전은 각각 독립적으로 관리된다. 세 버전 사이의 공식 호환성 조합을 교차 확인하는 것이 이 단계의 핵심 점검 항목이다.
2단계: 분석 및 처리
릴리즈 노트 분석
Spring Boot 릴리즈 노트를 검토하여 Deprecated 처리된 API와 동작 변경 사항을 식별한다. 동작 변경은 컴파일 오류로 드러나지 않고 런타임에서만 문제가 되는 경우가 있으므로, 릴리즈 노트 분석은 이후 테스트 단계에서 집중 확인해야 할 항목 목록을 만드는 과정이기도 하다.
의존성 버전 갱신
Spring Boot 버전을 변경하면 의존성 버전이 어떻게 반영되는지는 세 가지 경로로 구분된다. 이 구분을 정확히 파악하지 않으면, 갱신됐어야 할 라이브러리가 이전 버전으로 남아 있거나, 의도치 않게 갱신된 라이브러리가 런타임 동작에 영향을 주는 상황이 발생할 수 있다.
- 첫 번째 경로: BOM 관리 의존성 — Spring Boot BOM(Bill of Materials)이 관리하는 라이브러리는 Spring Boot 버전 갱신 시 자동으로 함께 갱신된다. 커넥션 풀, ORM, JSON 직렬화 라이브러리 등이 이 범주에 해당한다. 버전 갱신 자체는 자동이지만, 갱신된 버전의 동작 변경 여부는 별도로 확인해야 한다. BOM을 통해 버전이 올라갔다는 것이 동작 호환성을 보장하지는 않는다.
- 두 번째 경로: 버전을 직접 명시한 의존성 — BOM 외부에 버전을 직접 명시한 의존성은 Spring Boot 버전이 바뀌어도 자동으로 갱신되지 않는다. 이 의존성들의 버전은 프로젝트 전역에서 일괄 관리되며, Spring Cloud, Kafka 클라이언트, MyBatis 계열, 상용 스타터 등이 이 범주에 해당한다. 이 의존성들은 각각 자체적인 Spring Boot 호환성 매트릭스를 가지고 있으며, 매 사이클마다 신규 Spring Boot 버전과의 호환성을 개별적으로 평가해야 한다.
- 세 번째 경로: 모듈 내부 의존성 — 특정 모듈 내에서만 사용되는 의존성 중 일부는 BOM 관리 대상도 아니고 전역 버전 관리에도 포함되지 않는다. JWT 라이브러리, SSH 클라이언트, 메시징 클라이언트, 임베디드 테스트 인프라 등이 이 범주에 해당한다. 두 번째 경로의 의존성은 한 곳에서 버전을 수정하면 해당 의존성을 참조하는 모든 모듈에 일괄 반영되지만, 세 번째 경로의 의존성은 모듈마다 개별적으로 버전이 선언되어 있어 각 모듈의 호환성을 별도로 확인해야 한다.
빌드 및 단위 테스트
의존성 갱신 후 빌드가 정상 완료되는지 확인하고, 전체 단위 테스트를 수행한다. 컴파일 오류가 발생하면 릴리즈 노트 분석 단계로 돌아가 원인을 식별한다.
AutoConfiguration 및 MVC 구성 점검
DevOn Boot는 Spring Boot의 AutoConfiguration 메커니즘을 기반으로 동작한다. Spring Boot 버전이 올라가면, DevOn Boot가 등록한 AutoConfiguration 클래스들이 신규 버전에서 정상 로드되는지, @ConditionalOn* 조건이 의도대로 평가되는지 확인한다. AutoConfiguration 등록 방식 자체가 버전 간에 달라진 선례(spring.factories → AutoConfiguration.imports)가 있으므로 등록 메커니즘 변경 여부도 점검 대상이다.
DevOn Boot는 WebMvcConfigurer를 통해 Interceptor, Argument Resolver, Exception Resolver를 자동으로 등록한다. 버전 변경 시 등록 순서가 달라질 수 있으며, 이는 컴파일 오류 없이 런타임에서만 드러나므로 기능 검증 단계에서 별도로 확인한다.
OSS 취약점 점검
포함된 OSS 라이브러리의 취약점 스캔을 수행한다. 취약점이 확인된 경우 조치 후 재스캔을 수행하여 Critical 및 High 취약점이 잔존하지 않음을 확인한다.
3단계: 검증 및 배포
기술 검증
기술적 점검이 완료되면, 실제 기능이 정상 동작하는지 검증한다. 전체 JUnit 단위 테스트가 통과해야 하며, 프로토타입 앱을 통한 통합 검증이 추가로 수행된다. 프로토타입 앱 통합 검증은 단위 테스트로 포착할 수 없는 런타임 통합 이슈를 확인하기 위한 단계다.
배포
기능 검증이 완료되면 단계적 배포를 진행한다. Private Nexus에 먼저 배포하여 통합 환경 검증을 완료한 후, Public Nexus에 최종 배포된다.
배포 버전에는 대응 Spring Boot 계열을 명시하는 suffix가 붙는다. MAJOR.MINOR.PATCH-sX.X 형식으로, Spring Boot 3.5 계열을 기반으로 하는 버전은 -s3.5로 표기된다. 배포 전에는 suffix가 해당 시점에 통합된 Spring Boot 계열과 일치하는지 확인한다.
메이저 버전 업그레이드 추가 점검 항목
M+1 정기 패치 사이클의 점검 구조는 마이너 업그레이드를 기준으로 설계되어 있다. 메이저 버전 업그레이드(예: Spring Boot 3.x → 4.x)는 변경 범위와 대응 방식이 다르며, 마이너 업그레이드의 점검 항목 외에 추가 확인이 필요하다.
메이저 업그레이드를 결정하기 전에는, 프레임워크 외부로 영향이 확산되는 범위를 먼저 파악해야 한다. JDK 버전이나 Java EE 스펙 계층이 함께 바뀌는 경우, WAS의 서블릿 스펙 지원 범위나 암호화 솔루션의 런타임 호환성이 영향을 받을 수 있다. 이 범위의 영향도를 사전에 확인하는 것이 메이저 업그레이드 결정의 선행 조건이며, 이후 다음 항목을 점검한다.
제거된 API 점검
마이너 업그레이드에서 Deprecated 처리된 API는 경고만 발생하며 동작은 유지된다. 메이저 업그레이드에서는 이전 메이저 버전에서 Deprecated된 API가 실제로 제거(Removed)될 수 있으며, 이 경우 빌드 단계에서 컴파일 오류가 발생한다. 제거 대상 API 사용 여부를 업그레이드 이전에 식별하고 대체해야 하며, 이 점검은 버전 갱신 작업 전에 선행된다.
핵심 의존성 메이저 버전 동시 변경 확인
메이저 Spring Boot 업그레이드는 ORM, 커넥션 풀, 직렬화 라이브러리 등 핵심 의존성의 메이저 버전이 동시에 올라가는 경우가 많다. 각 의존성의 메이저 버전 변경은 자체적인 Breaking Changes를 포함하므로, 영향도 분석 대상이 마이너 업그레이드 대비 크게 확장된다. Spring Boot BOM이 관리하는 의존성이라도, 해당 의존성의 메이저 버전이 변경된 경우 동작 변경 여부를 개별적으로 검토한다.
Jakarta EE 패키지 전환 여부 확인
Spring Boot 2.x에서 3.x로 전환할 때 javax.* 패키지 전체가 jakarta.*로 변경되었다. Jakarta EE가 Eclipse Foundation으로 이관되면서 발생한 변경으로, 서블릿, JPA, Bean Validation 등 jakarta.* 패키지를 직접 import하는 모든 코드가 대상이었다. 메이저 Spring Boot 업그레이드가 Jakarta EE 버전 전환을 수반하는 경우, 해당 패키지를 직접 사용하는 범위를 사전에 식별하고 영향도를 평가한다.
마치며
이 글에서 설명한 점검 항목은 두 유형으로 구성된다. 마이너 버전 업그레이드를 기준으로 한 정기 패치 사이클의 공통 점검 항목과, 메이저 버전 업그레이드 시 추가로 확인해야 하는 항목이다. 둘은 버전 선정, 릴리즈 노트 분석, OSS 스캔, 검증 및 배포라는 기본 절차를 공유하고 있으며, 메이저 업그레이드에서는 추가적으로 API 제거, 스펙 계층 전환, 사전 준비 기간 확장 등 정기 패치 사이클의 구조보다 더 심도 있는 패치 절차가 추가된다.
이 점검 구조는 매 사이클마다 빠짐없이 반복된다. Spring Boot 업그레이드에 따른 의존성 변화, 동작 변경, 보안 취약점이 프레임워크 레벨에서 체계적으로 처리되고, 각 항목에 대한 검증 결과가 버전 단위로 축적된다. 프로젝트 사이트에서는 이 검증 주기의 결과물을 그대로 활용할 수 있다. Spring Boot 버전 추적, 의존성 호환성 검토, OSS 취약점 대응을 DevOn Boot 팀이 선처리하므로, 프로젝트 측에서는 DevOn Boot 업그레이드 버전을 적용하는 것만으로 해당 Spring Boot 계열에 대한 검증된 기반을 확보하게 된다.
※ 본 게시글의 이미지는 AI를 활용해 제작되었습니다.