[2025.11.21 주간 개발 트렌드] Spring Boot 4 정리 (모듈화, Jackson 3, 마이그레이션)

![주간 개발 트렌드](https://librarian-blog-images.s3.ap-northeast-2.amazonaws.com/b28d786c-9ec3-46ec-8055-adcd53a303c5_thumbnail_2.png)

# Spring Framework의 다음 세대가 시작됐다

Spring을 사용하다보면 Boot 버전을 먼저 확인하는 경우가 많다. 그런데 그 아래에서 요청 처리와 의존성 주입, 트랜잭션 같은 기반을 담당하는건 Spring Framework다.

이번주 11월 13일에 [Spring Framework 7](https://spring.io/blog/2025/11/13/spring-framework-7-0-general-availability/)이 정식 출시됐다. Java 25를 지원하면서 Java 17 기준은 유지하고, Jakarta EE 11과 JSpecify, Jackson 3 같은 변화가 들어왔다.

이번주에는 새 프레임워크 세대에서 API의 계약과 주변 생태계가 어떻게 달라지는지 정리해보려고 한다.

# 1. Java 25 지원과 최소 버전은 다르다

Java 25를 지원한다는 말을 듣고 최소 실행 버전도 25로 올라갔다고 생각할 수 있다. Spring Framework 7은 Java 17 baseline을 유지한다.

즉 사용할 수 있는 새로운 JDK와 최소 요구사항을 나눠서 봐야한다. 실제 프로젝트에서는 프레임워크 외에 빌드 도구와 다른 라이브러리의 지원 범위도 확인해야한다.

```text
프로젝트의 실행 조건
JDK + Spring + 라이브러리 + 빌드 도구 + 운영 Agent
```

이 중 하나가 새 버전을 지원한다고 전체 조합이 바로 검증되는것은 아니다. Java와 프레임워크를 동시에 올리려면 어떤 변경에서 문제가 생겼는지 구분할 기준이 필요하다.

기존 코드를 먼저 새 프레임워크에서 실행하고, 이후 JDK나 문법 변경을 적용하는 식으로 나눌 수도 있다. 실제 순서는 프로젝트의 현재 버전과 의존성에 맞춰 정하면 되겠다.

# 2. null 가능성이 API에 더 명확하게 드러난다

메서드가 String을 반환한다고 해서 반드시 값이 있다는 뜻은 아니다. 문서나 구현을 읽어봐야 null이 가능한지 알 수 있는 코드도 많다.

Spring Framework 7은 [JSpecify 기반 null 안전성](https://docs.spring.io/spring-framework/reference/core/null-safety.html)을 사용해 API의 null 가능성을 표현한다. IDE와 정적 분석 도구, Kotlin에서 이 계약을 활용할 수 있다.

예를 들어 다음처럼 값이 없을 수 있는 반환값을 명시할 수 있다.

```java
import org.jspecify.annotations.NullMarked;
import org.jspecify.annotations.Nullable;

@NullMarked
interface MemberLookup {
    @Nullable
    String findNickname(long memberId);
}
```

위의 코드는 JSpecify 의존성이 있다는 전제의 예시다. NullMarked 범위에서 기본적인 null 계약을 정하고, 예외적으로 null이 가능한 위치를 Nullable로 표시한다.

중요한건 애너테이션을 붙인다고 실행 중 검증 코드가 자동으로 생기는것은 아니라는 점이다. 정적 분석과 도구 설정을 통해 계약을 확인하는 흐름이다.

외부 요청의 입력 검증이나 데이터베이스 제약과도 역할이 다르다. null이 가능한 타입이라고 표시하는것과 사용자에게 해당 입력을 허용할지는 별도로 정해야한다.

# 3. null 경고를 없애는것보다 의미를 정하자

기존 프로젝트에 새로운 null 분석을 적용하면 경고가 늘어날 수 있다. 이때 전부 억제하거나 강제로 값이 있다고 처리하면 계약을 표현하는 장점이 줄어든다.

예를 들어 회원의 별명이 없는 상황은 정상일 수 있다. 반면 저장된 주문의 필수 식별자가 없는 상황은 데이터 오류일 수 있다. 둘을 같은 방식으로 처리하기는 어렵다.

```text
값이 없는 이유
├── 정상적으로 선택하지 않은 값
├── 조회한 대상이 없음
├── 아직 처리되지 않은 상태
└── 발생하면 안되는 오류
```

어떤 의미인지 정한 다음 빈 응답과 오류, 기본값 중 무엇을 사용할지 결정하면 좋겠다. 단순히 NullPointerException을 피하는것 다음에 서비스의 동작이 필요하다.

공개 인터페이스의 계약을 바꾸면 호출하는 쪽도 영향을 받는다. 내부 구현만 수정하고 끝내기보다 사용하는 모듈과 테스트까지 같이 확인해야한다.

Kotlin을 사용하는 프로젝트에서도 Java API 경계에서 어떤 값이 들어올 수 있는지 더 분명해진다는 점이 중요해보인다. 같은 코드에서 다른 언어가 다른 가정을 하지 않도록 맞춰야겠다.

# 4. API Versioning도 정책이 먼저다

이번 버전에는 API Versioning 지원과 HTTP Interface Client 설정 개선도 포함됐다. 요청의 버전에 따라 동작을 나누거나 외부 HTTP 서비스를 구성하는 기반이 넓어졌다.

하지만 API 버전 기능이 생겼다고 서비스의 호환성 정책까지 정해지는것은 아니다. 어떤 변경을 새 버전으로 볼지부터 합의해야한다.

예를 들어 응답 필드를 추가하는것과 기존 필드의 의미를 바꾸는것은 영향이 다를 수 있다. 클라이언트가 알 수 없는 필드를 무시하는지, 필수값을 어떻게 처리하는지도 연결된다.

| 먼저 정할것 | 질문 |
| --- | --- |
| 버전 전달 방식 | URL과 헤더 등 어떤 경로로 구분할까 |
| 기본 동작 | 버전이 없는 요청은 어떻게 처리할까 |
| 지원 범위 | 이전 버전을 언제까지 유지할까 |
| 검증 | 각 버전의 계약을 어떻게 테스트할까 |

외부 HTTP 클라이언트도 인터페이스 선언만으로 운영이 끝나지는 않는다. 연결과 응답 제한 시간, 오류 매핑, 재시도 범위를 서비스별로 정해야한다.

같은 재시도라도 조회와 결제 요청의 의미는 다르다. 선언이 간단해지는것과 작업의 성격을 이해하는것은 별개의 문제다.

# 5. 생태계 변경을 함께 확인하자

이번 세대는 Jakarta EE 11 API 수준과 Kotlin 2.2, JUnit 6 같은 주변 기술 변화도 포함한다. Jackson 3 지원과 함께 Jackson 2 지원은 deprecated 상태로 남아있다.

개별 버전 숫자를 외우기보다 프로젝트가 직접 설정하는 의존성을 먼저 찾아보면 좋겠다. 프레임워크가 관리하는 버전을 일부만 덮어쓰고있다면 조합을 다시 확인해야한다.

```text
현재 의존성 목록
    ↓
직접 고정한 버전과 확장 기능 확인
    ↓
컴파일과 테스트
    ↓
직렬화 / 요청 처리 / DB 연동 비교
```

Spring Framework 7은 Spring Boot 4의 기반으로 소개됐다. Boot를 사용하는 서비스라면 Framework 의존성만 임의로 바꾸기보다 Boot의 지원 조합과 전환 안내를 같이 살펴보는게 좋겠다.

# 마무리

이번 Spring Framework 7은 JDK 지원뿐 아니라 null 계약과 API 구성, 주변 라이브러리까지 다음 세대로 연결하는 변화다.

개인적으로는 null 가능성이 프레임워크 API에 드러나는 부분이 눈에 들어왔다. 구현을 열어보거나 실행 중 오류를 기다리기 전에 값의 의미를 이야기할 수 있기 때문이다.

우선 우리 코드의 공개 인터페이스와 직접 고정한 의존성부터 확인해보면 좋겠다. 새 버전에서 컴파일되는것과 같은 계약으로 동작하는것을 같이 확인해야겠다..


[2025.11.14 주간 개발 트렌드] Spring Framework 7 정리 (Java 25, null 안전성, API 버전)

독자의 메모