[2025.11.28 주간 개발 트렌드] Redis 8.4 정리 (Hybrid Search, 벡터 검색, RAG)

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

# Spring Boot 4로 옮기는건 메이저 전환 작업이다

지난주에는 Spring Framework 7의 변화를 정리했다. 이번주에는 그 위에서 애플리케이션 설정과 의존성 구성을 담당하는 Boot의 새 버전이 나왔다.

11월 20일에 [Spring Boot 4.0](https://spring.io/blog/2025/11/20/spring-boot-4-0-0-available-now/)이 정식 출시됐다. Framework 7을 기반으로 모듈화와 JSpecify 지원, Java 25 지원 등이 들어왔다. Java 17 호환성도 유지한다.

이번주에는 기존 Boot 3 서비스를 옮길때 무엇을 먼저 확인하면 좋을지 정리해보려고 한다.

# 1. 우선 현재 의존성부터 정리하자

Boot 버전은 애플리케이션의 여러 의존성과 연결된다. 빌드 파일의 숫자 하나를 바꿔도 JSON 처리와 웹 서버, 테스트 도구가 같이 달라질 수 있다.

[공식 마이그레이션 가이드](https://github.com/spring-projects/spring-boot/wiki/Spring-Boot-4.0-Migration-Guide)는 먼저 사용 가능한 3.5.x 업데이트를 적용하고 deprecated API를 확인하도록 안내한다. 관리되는 의존성과 직접 고정한 의존성도 구분해야한다.

```text
확인할 목록
├── Boot가 버전을 관리하는 라이브러리
├── 프로젝트에서 직접 고정한 버전
├── 별도 지원 조합을 확인해야하는 확장
└── 사내 공통 라이브러리와 Starter
```

예를 들어 공통 라이브러리가 Boot 3의 특정 구현에 의존하고있다면 서비스만 4로 올려도 문제가 생길 수 있다. 빌드가 성공하기 전에 어떤 조합을 지원할지부터 맞춰보는게 좋겠다.

여러 의존성을 임의로 이전 버전에 고정해서 오류를 없애는 방식도 신중해야한다. 일단 실행되더라도 프레임워크가 기대하는 조합에서 벗어날 수 있기 때문이다.

# 2. 모듈화는 필요한 기능을 다시 보는 계기다

이번 Boot 4에서는 코드가 더 작고 목적이 분명한 jar로 나뉘었다. 기존에 간접 의존성으로 들어오던 기능을 당연하게 사용하고있었다면 필요한 모듈을 확인해야할 수 있다.

애플리케이션 코드와 테스트 코드의 의존성도 따로 살펴보면 좋겠다. 테스트에서만 사용하는 기능이 운영 의존성에 섞여있거나, 반대로 필요한 테스트 지원이 빠질 수도 있다.

```text
빌드 오류가 났을때
클래스 이름 확인
    ↓
패키지 이동인지 기능 제거인지 확인
    ↓
필요한 모듈과 Starter 확인
    ↓
기능을 사용하는 테스트 실행
```

찾을 수 없는 클래스가 나왔다고 예전 jar를 무조건 추가하기보다는 새 구조에서 어떤 기능을 사용해야하는지 확인하는게 좋겠다.

사내 Starter를 만드는 팀이라면 영향이 더 넓다. 자동 설정이 어떤 조건에서 적용되는지와 함께 해당 라이브러리를 사용하는 작은 소비자 프로젝트에서도 확인해야한다.

# 3. Jackson 3는 JSON 계약으로 검증하자

Boot 4는 Jackson 3를 기본 JSON 라이브러리로 사용한다. 주요 패키지가 tools.jackson으로 바뀌지만 jackson-annotations는 기존 com.fasterxml.jackson 계열을 유지하는 예외가 있다.

그래서 import 경로를 한꺼번에 문자열 치환하는것만으로 끝내기는 어렵다. 직접 ObjectMapper를 구성하거나 커스텀 직렬화 코드를 사용하는 부분부터 확인하면 좋겠다.

컴파일이 통과한 다음에는 실제 JSON 결과를 비교해야한다. API를 사용하는 클라이언트는 Java 클래스의 내부보다 응답의 필드와 값에 의존하기 때문이다.

```json
{
  "orderId": "order-demo",
  "amount": 12000,
  "paidAt": null,
  "status": "WAITING"
}
```

위의 응답을 예시로 생각해보자. null 필드가 빠지는지, 날짜 표현이나 enum 값이 달라지는지, 숫자가 문자열로 바뀌지는 않는지 비교할 수 있다.

이 변화들이 반드시 발생한다는 뜻은 아니다. 서비스가 보장하고있는 계약을 기준으로 실제 결과를 확인하자는 의미다.

오류 응답과 외부 API로 보내는 요청도 포함해야한다. 정상 조회 응답만 같아도 예외 처리나 이벤트 메시지의 형식이 달라질 수 있다.

# 4. 새 기능 도입과 전환 작업을 나눠보자

이번 버전에는 API Versioning과 HTTP Service Clients 지원도 포함됐다. null 안전성도 JSpecify를 중심으로 개선됐다.

이 기능들을 업그레이드와 동시에 전부 적용할 필요는 없다. 먼저 기존 동작을 유지한 채로 Boot 4에서 실행한 다음 필요한 개선을 개별 작업으로 나누면 비교하기 쉽다.

```text
첫번째 목표: 기존 서비스가 같은 계약으로 동작하기
다음 목표: 새 기능으로 구조와 개발 경험 개선하기
```

예를 들어 프레임워크를 올리면서 API 버전 전달 방식을 함께 바꾸면 클라이언트 오류가 어디서 시작됐는지 다시 나눠봐야한다.

null 관련 경고도 값이 없는 이유를 확인하면서 해결하면 좋겠다. 경고를 없애기 위한 강제 변환과 실제로 null이 불가능하다는 계약은 다르다.

Java 25를 선택하는 작업도 같은 관점으로 볼 수 있다. Boot가 지원한다는 사실과 우리 의존성 전체가 그 환경에서 검증됐다는 사실은 구분해야한다.

# 5. 시작 성공 다음에 운영 동작을 보자

애플리케이션이 올라오면 가장 큰 고비를 넘긴것처럼 느껴진다. 그래도 요청을 처리하고 외부 자원과 연결되는 경로를 확인해야한다.

| 영역 | 확인할 사례 |
| --- | --- |
| 웹 | 정상 응답, 입력 오류, 인증과 권한 |
| 데이터 | 조회, 저장, 트랜잭션과 롤백 |
| 외부 통신 | 제한 시간, 오류 매핑, 재시도 |
| 운영 | 상태 확인, 메트릭, 로그와 종료 |

특히 배포 플랫폼이 확인하는 health endpoint와 애플리케이션의 상태도 함께 보자. 프로세스가 실행중이어도 준비되지 않은 서버로 트래픽이 전달되면 문제가 생길 수 있다.

DB 스키마 변경까지 포함한다면 이전 버전으로 돌아갈 수 있는지도 확인해야한다. 애플리케이션 이미지만 되돌려도 이전 코드가 새 데이터 구조를 이해할 수 있는지 살펴보는것이다.

전환 전후의 대표 API와 배치 결과를 남겨두면 리뷰할때도 도움이 된다. 테스트가 통과했다는 문장과 함께 무엇을 확인했는지 설명할 수 있어야겠다.

# 마무리

이번 Spring Boot 4는 Framework 7과 함께 다음 Spring 애플리케이션의 기반을 제공하는 릴리스다. 모듈과 JSON 처리 등 기존 서비스에 직접 연결되는 변화가 있다.

개인적으로는 새 기능을 적용하는 속도보다 의존성과 외부 계약을 얼마나 명확히 알고있는지가 전환 난이도를 결정할것 같다.

우선 작은 서비스나 테스트 환경에서 빌드와 API 결과를 비교해보면 좋겠다. 버전 숫자를 바꾼 작업을 서비스가 같은 동작을 하는지 확인하는 작업까지 이어가야겠다..


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

독자의 메모