Spring Boot 4.0 변경점 정리: 실무에서 먼저 확인할 7가지 마이그레이션 포인트

English version: Spring Boot 4.0 Major Changes: 7 Migration Points Worth Checking First

Spring Boot 4.0은 단순한 버전 업그레이드라기보다, 실무 프로젝트의 기준선을 한 단계 올리는 메이저 전환에 가깝습니다.

겉으로 보면 4.0이라는 숫자 변화지만, 실제로는 의존성 구조, 웹 서버 선택, 설정 키, 테스트 구성, 관측성(Observability)까지 영향을 주는 변화가 많습니다. 그래서 기존에 Spring Boot 3.x를 운영하던 팀이라면 “무엇이 새로 생겼나?”보다 “어디서 깨질 수 있나?”를 먼저 보는 편이 훨씬 중요합니다.

이 글에서는 Spring Boot 4.0에서 특히 중요하게 봐야 할 변환점을 실무 관점에서 정리해보겠습니다.

먼저 결론부터

Spring Boot 4.0에서 가장 중요한 변화는 아래 3가지로 요약할 수 있습니다.

• 기준선이 올라갔다: 서블릿/런타임 기준이 올라가면서 기존 선택지가 일부 사라졌습니다.
• 모듈과 starter 구조가 더 세분화됐다: 예전처럼 “대충 맞던 의존성”이 이제는 명시적으로 정리돼야 합니다.
• 운영 관점이 더 강조됐다: Observability, tracing, HTTP client 구성처럼 운영 친화적 변화가 많습니다.

즉, Spring Boot 4.0은 새 기능 몇 개 추가된 릴리스가 아니라, 프로젝트 구조를 다시 점검하게 만드는 버전입니다.

왜 Spring Boot 4.0을 ‘변환점’이라고 보는가

대부분의 마이너 업데이트는 기존 방식 위에 기능이 조금씩 추가되는 느낌입니다. 하지만 메이저 업데이트는 다릅니다. 팀이 오랫동안 쌓아온 암묵적 전제를 흔듭니다.

Spring Boot 4.0이 그런 이유는 다음과 같습니다.

• 오래된 선택지를 정리하고
• 기술별 지원 범위를 더 명확하게 나누고
• 설정과 테스트, 배포 방식까지 정비하도록 유도하기 때문입니다.

실제로 규모가 있는 프로젝트일수록, 이번 업그레이드는 버전만 바꾸는 작업이 아니라 의존성 구조 점검 + 설정 정리 + 테스트 보강 작업에 가깝습니다.

1. Undertow 지원 종료: 웹 서버 선택 기준이 달라졌다

가장 먼저 눈에 띄는 변화 중 하나는 Undertow 지원 종료입니다.

Spring Boot 4.0은 Servlet 6.1 기준선을 요구하는데, Undertow가 이 기준과 맞지 않으면서 내장 서버 선택지에서 빠졌습니다. 즉, 기존에 Undertow 기반으로 운영하던 프로젝트라면 더 이상 그대로 올라갈 수 없습니다.

실무적으로 중요한 이유는 단순합니다.

• 일부 팀은 성능 특성이나 기존 운영 경험 때문에 Undertow를 선호해왔고
• 관련 튜닝값, 운영 문서, 장애 대응 방식도 Undertow 기준으로 맞춰져 있을 수 있기 때문입니다.

이 경우 Spring Boot 4.0 전환은 단순 업그레이드가 아니라, Tomcat 또는 Jetty 기준으로 운영 방식을 재정리하는 작업이 됩니다.

체크 포인트

• 현재 내장 서버가 Undertow인지 확인
• Undertow 전용 설정이 남아 있는지 확인
• 전환 후 성능/타임아웃/스레드 관련 운영값 재검토

2. 모듈화 강화: starter 의존성을 다시 봐야 한다

Spring Boot 4.0의 핵심 변화 중 하나는 새로운 모듈 설계입니다.

예전에는 어떤 기능이 특정 서드파티 라이브러리 하나만 추가돼도 자연스럽게 연결되는 경우가 있었습니다. 하지만 4.0에서는 역할이 더 분리되고, 기술별 starter가 더 명확해졌습니다.

예를 들면 다음과 같은 흐름입니다.

• spring-boot-starter-webmvc
• spring-boot-starter-webflux
• spring-boot-starter-restclient
• spring-boot-starter-webclient
• spring-boot-starter-opentelemetry

이 구조의 장점은 분명합니다.

• 의존성이 더 명시적이고
• 프로젝트 역할이 더 분명해지고
• 불필요한 라이브러리 혼입을 줄일 수 있습니다.

하지만 기존 프로젝트 입장에서는 주의할 점이 있습니다.

예전엔 우연히 맞아떨어지던 설정이나 의존성이, 이제는 starter를 명확하게 선언하지 않으면 동작하지 않을 수 있습니다. 특히 Flyway, Liquibase, 테스트 관련 의존성은 꼭 다시 보는 게 좋습니다.

체크 포인트

• starter 없이 직접 라이브러리만 넣어둔 부분이 있는지 확인
• 기술별 test starter를 적절히 쓰고 있는지 확인
• 보안/웹/데이터 계층 테스트 의존성 분리 여부 점검

3. 설정 키 변경과 제거: application.yml이 생각보다 많이 흔들릴 수 있다

메이저 버전 업그레이드에서 늘 아픈 부분이 바로 설정입니다.

Spring Boot 4.0에서는 일부 설정 프로퍼티가 이름이 바뀌거나 제거되었습니다. 그래서 애플리케이션 코드가 아니라 application.yml, application.properties, 환경 변수 쪽에서 먼저 문제가 드러날 가능성이 높습니다.

여기서 중요한 점은, 이런 변경이 빌드 단계보다 실행 시점에 더 늦게 발견되기 쉽다는 겁니다.

그래서 공식적으로도 spring-boot-properties-migrator 사용이 권장됩니다.

이 모듈을 런타임에 잠시 추가하면:

• 변경된 설정 키를 진단해주고
• 일부는 임시로 매핑해주며
• 업그레이드 과정에서 놓친 설정을 찾는 데 큰 도움이 됩니다.

다만 이건 어디까지나 마이그레이션 보조 도구라서, 정리 후에는 제거하는 것이 맞습니다.

체크 포인트

• application.yml / application.properties 전체 재검토
• 환경 변수 이름까지 같이 점검
• 운영/개발/테스트 프로파일별 설정 차이 확인
• 마이그레이션 후 properties-migrator 제거

4. HTTP Client와 API Versioning: 웹 계층이 더 명확해졌다

Spring Boot 4.0에서는 HTTP Service Client 지원과 API Versioning 구성 지원이 더 눈에 띄게 정리됐습니다.

HTTP Service Client는 인터페이스 기반으로 외부 HTTP 호출을 더 선언적으로 구성할 수 있게 해줍니다. 팀에 따라서는 기존 RestTemplate, RestClient, WebClient, Feign 계열과의 역할 분담을 다시 정리할 계기가 됩니다.

또 API Versioning도 설정 레벨에서 다룰 수 있게 되면서, 단순 구현을 넘어서 버전 전략을 운영 정책으로 관리하기 쉬워졌습니다.

이 변화가 중요한 이유는 기능 추가보다도, 팀 내 API 설계 방식이 더 일관되게 정리될 수 있기 때문입니다.

체크 포인트

• 외부 API 호출 방식이 팀 내에서 제각각인지 확인
• RestTemplate를 계속 유지할지, 더 현대적인 방식으로 정리할지 판단
• API 버전 정책을 URI/Header/Media Type 중 어떤 방식으로 가져갈지 정리

5. Observability 강화: 운영 친화성이 더 올라갔다

Spring Boot 4.0은 운영 관점에서도 의미가 큽니다.

대표적으로 OpenTelemetry starter가 추가되었고, tracing/metrics 쪽 구성도 더 정리되었습니다. 예전에는 observability 구성이 팀별로 꽤 제각각이었는데, 이제는 기본 지원 방향이 더 또렷해졌습니다.

이건 단순히 “모니터링 도구를 붙이기 쉬워졌다” 수준이 아닙니다.

실무에서는 결국 아래 질문에 빨리 답할 수 있어야 합니다.

• 어디서 느려졌는가
• 어느 외부 호출이 병목인가
• 장애가 어디서 시작됐는가
• 메트릭과 트레이스를 어떻게 같이 볼 것인가

Spring Boot 4.0은 이런 질문에 답하기 쉬운 구조로 점점 이동하고 있습니다.

체크 포인트

• 현재 팀이 Micrometer 중심인지, OpenTelemetry 중심인지 정리
• tracing 관련 프로퍼티 이름 변경 여부 확인
• 로그/메트릭/트레이스 연결 방식을 운영 환경에서 검증

6. 테스트 구성 변화: 이제는 테스트 의존성도 더 명시적으로 가야 한다

테스트 쪽도 꽤 중요합니다.

Spring Boot 4.0에서는 기술별 test starter 개념이 더 강화됐고, RestTestClient 지원도 추가됐습니다. 즉, 테스트도 이제는 “일단 spring-boot-starter-test 하나 넣고 시작”하는 방식보다, 무엇을 테스트하는지에 맞는 의존성 구성이 더 중요해진 방향입니다.

이 변화는 작은 프로젝트에서는 크게 체감되지 않을 수 있습니다. 하지만 모듈이 많고 테스트 종류가 다양한 서비스라면 체감이 큽니다.

예를 들어:

• 보안 테스트
• MVC 슬라이스 테스트
• 통합 테스트
• 외부 API 연동 테스트

이런 것들이 더 명확히 분리될수록, 테스트 안정성과 가독성도 좋아집니다.

체크 포인트

• 기술별 테스트 의존성이 정확히 분리되어 있는지 확인
• spring-security-test 사용 시 관련 starter 구성 재점검
• 통합 테스트와 슬라이스 테스트 역할 분리

7. “그동안 그냥 되던 것들”이 사라질 수 있다

Spring Boot 4.0에서 진짜 조심해야 하는 건, 화려한 신규 기능보다 기존에 당연하게 쓰던 방식이 더 이상 권장되지 않거나 제거되는 지점입니다.

대표적으로 아래 같은 항목은 프로젝트 성격에 따라 직접 영향이 갈 수 있습니다.

• Undertow 지원 종료
• 일부 통합/지원 기능 제거
• fully executable jar를 위한 embedded launch script 제거
• 특정 생태계 연동 방식 재정리

이런 변경은 코드 한 줄보다도 배포 스크립트, 운영 가이드, CI/CD 문서에 더 크게 영향을 줄 수 있습니다.

즉, Spring Boot 4.0 업그레이드는 개발팀만의 작업이 아니라, 경우에 따라서는 플랫폼/인프라/운영 절차까지 같이 보는 작업이 됩니다.

그래서 실무에서는 어떻게 접근하는 게 좋을까

제 기준에서는 Spring Boot 4.0 전환을 이렇게 접근하는 편이 가장 안전합니다.

1. 먼저 3.x 최신 안정 버전 정리

한 번에 오래된 버전에서 4.0으로 점프하기보다, 가능하면 3.x 최신 안정 상태를 먼저 맞추는 게 좋습니다.

2. 의존성부터 정리

코드보다 먼저 starter, 테스트 의존성, 내장 서버, 운영 라이브러리를 정리합니다.

3. 설정 파일을 전수 점검

특히 application.yml과 환경 변수는 생각보다 많이 흔들릴 수 있습니다.

4. 테스트를 보강한 뒤 전환

빌드 성공보다 중요한 건 회귀 검증입니다. 특히 인증, 외부 API, DB 마이그레이션, 배치, 캐시, 메시징은 꼭 확인해야 합니다.

5. 운영 관점 검증

트레이싱, 메트릭, 로그, 헬스체크, 배포 스크립트까지 실제 운영 기준으로 다시 봐야 합니다.

마무리

Spring Boot 4.0의 핵심은 “새 기능이 많다”가 아니라, 실무 프로젝트의 기준선을 다시 정렬하게 만든다는 데 있습니다.

개인적으로는 이번 변화를 이렇게 봅니다.

• 더 명시적으로
• 더 운영 친화적으로
• 더 모듈화된 방향으로
• 그리고 예전의 암묵적 편의에 덜 기대는 방향으로

그래서 Spring Boot 4.0은 분명히 반가운 업그레이드이지만, 동시에 준비 없이 올리면 생각보다 아픈 메이저 버전이기도 합니다.

만약 현재 팀이 Spring Boot 3.x 서비스를 운영 중이라면, 지금 가장 먼저 해야 할 일은 버전 숫자 변경이 아니라 의존성 구조, 설정 키, 테스트 체계, 운영 방식을 한 번에 점검하는 것입니다.

그 작업까지 포함해서 본다면, Spring Boot 4.0은 단순 업그레이드가 아니라 좋은 구조로 넘어갈 수 있는 꽤 괜찮은 기회입니다.

함께 보면 좋은 체크리스트

• 현재 프로젝트가 Undertow를 쓰는가
• starter 없이 직접 의존성을 묶어 쓰는가
• 설정 키 변경에 대비했는가
• 테스트가 기술별로 분리되어 있는가
• tracing/metrics를 운영 기준으로 보고 있는가
• 배포 스크립트와 운영 문서까지 같이 점검했는가

---

참고:

• Spring Boot 4.0 Release Notes
• Spring Boot 4.0 Migration Guide

이 글은 2026-04 기준 공개된 공식 릴리스 노트와 마이그레이션 가이드를 바탕으로 정리했습니다.