Spring Boot 4.0의 등장 : 작아지고 빨라지고

Spring Boot 4.0 주요 변경점

AI 진영까지 영역전개하는 스프링팀

2025년 겨울, 스프링 진영에는 큰 변화가 찾아왔다.
Spring 7의 등장과 JDK 25의 동시 릴리즈는 그 자체로 하나의 시대 전환처럼 느껴졌다.
이번 업데이트를 통해 스프링 역시 현대적인 개발 환경에 적극적으로 반응하고 있으며, AI 시대에 발맞춰 진화하고 있다는 인상을 강하게 받았다. 무엇보다 인상 깊었던 점은, 실무에서 자주 마주치는 문제들을 기대 이상으로 해소해 주었다는 점이다.
 
그리고 가장 감명 깊었던 부분은, 이 모든 변화와 개선 사항을 반영한 대규모 버전 업그레이드임에도 불구하고 기존 코드 수정이 사실상 필요 없었다는 점이다.

이를 통해 스프링 팀이 오랫동안 일관되게 지켜온 강력한 추상화 철학을 다시 한 번 체감할 수 있었다.
스프링 개발자로서, 팀에서 함께 개발할 때도 이와 같은 수준의 추상화를 구현하고 싶다는 생각과 소망... 추구미.. 그런것..
 
 
Spring Boot 4.0.0 available now

Spring Boot 4.0.0 available now

 
Spring Boot 4.0 Release Notes

Spring Boot 4.0 Release Notes

 
Spring Boot 4.0은 단순한 버전 업이 아니라, 생태계 전반의 현대화를 반영한 메이저 업데이트다.
2025년 11월 20일 정식 출시된 이 메이저 릴리스는 기존 3.x 버전에서 개발자들이 겪던 핵심 문제들을 해결하는 데 초점을 맞추고있다.
그리고 이 변화의 특징은 코드변경없는 성능향상입니다. 이는 스프링의 핵심 설계 철학인 캡슐화와 추상화라는것의 강력함을 다시한번 느끼게해준다.
 

Spring Framework 7.0 & Spring Boot 4.0 핵심 변경사항

Derived Queries의 성능향상 : 믿고있었다! JPA

Spring Data JPA의 파생 쿼리(Derived Queries)는 메서드 이름만으로 JPA 쿼리를 생성해주는 편리한 기능이다.

public interface UserRepository extends JpaRepository<User, Long> {
    List<User> findById(Long id);
}

내부적으로 Spring Data는 이러한 파생 쿼리를 구현하기 위해 JPA Criteria API를 주로 사용했다.
개발자들은 Criteria API가 가장 효율적일 것이라고 생각했었다.
그러나 벤치마크 결과는 예상과 달랐다.

• Criteria API vs. String-based Query (JPQL): 인메모리(H2) 환경에서 JPQL과 같은 문자열 기반 쿼리가 Criteria API보다 약 6배 더 빠른 성능을 보였다.
• 실제 프로덕션 환경: PostgreSQL과 같은 실제 데이터베이스 환경에서도 Criteria API 기반 쿼리는 문자열 기반 쿼리보다 약 25% 느리게 실행되는 것으로 나타났다.

Spring Data 팀은 약 15년간 Criteria API를 사용해온 방식에서 벗어나, 파생 쿼리를 Criteria API 대신 문자열 기반 JPQL 쿼리로 렌더링하는 방법을 연구했다.
그 결과 Spring 릴리즈 이후에, Spring Data 4.0으로 업그레이드하기만 하면, 기존 파생 쿼리들이

@Query 어노테이션으로 작성된 쿼리와 동일한 성능을 자동으로 얻게 된다.

Spring AI 1.0 출시: 자바 진영의 AI 애플리케이션 개발 시작

Spring AI 1.0 General Availability 가 릴리스 되었다. Spring 팀이 약 2년 반의 개발을 마친 후 마침내 정식 출시하였다. Spring AI는 자바 개발자들이 생성형 AI 애플리케이션을 쉽게 구축할 수 있도록 돕는 기반 기능을 제공한다.
핵심 기능 및 빌딩 블록

• RAG (Retrieval Augmented Generation): 데이터를 LLM에 가져와 애플리케이션에 최적화된 답변을 생성
• 채팅 메모리(Chat Memory): 비상태(stateless) API 환경에서도 대화의 맥락을 유지
• 도구 호출(Tool Calling): LLM이 외부 API를 호출하여 동적으로 정보를 얻거나 작업을 수행
• 평가(Evaluation): AI 애플리케이션의 효과를 평가
• 안전 및 디버깅: 프로덕션 환경에서의 안전성, 비용 관리, 디버깅 지원

GraalVM 네이티브 이미지 지원 강화: 서버리스 성능 극대화

문제상황
기존 Spring Boot 3.x 애플리케이션을 AWS Lambda 등의 서버리스 환경에 배포하면 콜드 스타트 시 첫 요청 응답에 4~6초가 걸리고, 함수 메모리도 512MB~1GB로 많이 필요했다.
이로 인해 타임아웃이 빈발하고 서버리스를 고려하기 어렵다는 문제가 있었습니다.
변경점
Spring Boot 4.0은 GraalVM 24 기반으로 네이티브 이미지 빌드 지원을 대폭 개선했다.
AOT (Ahead-of-Time) 컴파일 최적화로 불필요한 클래스와 메타정보를 제거하여 시작 속도와 메모리 사용을 획기적으로 줄였다.
실제로 Spring Boot 4.0으로 빌드한 네이티브 이미지를 서버리스에 적용하면:

• 첫 요청 응답 시간이 0.5~1초로 단축 (기존 대비 80% 감소)
• 메모리 사용이 128~256MB로 절감 (기존 대비 50~75% 감소)
• 네이티브 이미지 크기도 약 70% 작아짐

의미
이제 서버리스 환경에서도 Spring Boot를 부담 없이 사용할 수 있을 정도로 콜드스타트 지연이 개선되었다.
코드 수정은 거의 필요 없고, Gradle/Maven 설정에 GraalVM 빌드 플러그인만 추가하면 손쉽게 적용 가능하다.

plugins {
    id 'org.graalvm.buildtools.native' version '0.10.4'
}

가상 스레드 (Virtual Threads) 지원: 동시성 성능 향상

문제상황
전통적인 스레드 풀 기반 Spring MVC 애플리케이션에서, 예를 들어 외부 API를 많이 호출하는 경우 스레드 풀을 많이 늘려도 CPU 사용률은 낮은데 요청은 대기하는 병목이 발생하곤 했다.
예를 들어 스레드풀 200개 설정에서 동시 500요청이 오면 300개는 스레드 부족으로 대기하고, CPU는 20%만 쓰는데도 서비스는 지연되는 식이다.
기존 스프링의 멀티스레딩 기술은 커널 스레드와 1대1로 매칭시켜 사용했기때문인데, 때문에 한정된 자원에서 스레드풀을 키우면 컨텍스트 스위칭으로 인한 오버헤드로 오히려 성능 문제가 생긴다.
변경점
Spring Boot 4.0에서는 Java 21 이상의 가상 스레드(Virtual Threads)를 쉽게 활용할 수 있도록 지원합니다. 간단히 한 줄 설정만 하면 기존 코드를 대폭 수정하지 않고도 가상 스레드를 사용할 수 있다.

spring:
  threads:
    virtual:
      enabled: true

Observability 통합 (Micrometer 2 + OpenTelemetry): 장애 대응 시간 단축

문제상황
MSA 환경에서는 하나의 요청이 여러 서비스를 거치므로, 병목이나 장애 발생 시 원인 파악을 위해 다양한 모니터링 도구를 모두 뒤져야 하는 어려움이 있었다.

그냥 다시해봐 이제 될수도있어!!

 
 
변경점

Spring Boot 4.0에는 spring-boot-starter-opentelemetry 스타터가 새로 추가되어, OpenTelemetry 기반의 분산추적과 관측성이 자동 구성됩니다. 이 스타터 하나로 다음이 가능해진다.

• 트레이스(Traces) : 애플리케이션 간 분산 요청 추적이 자동으로 활성화되어, 각 요청에 고유 Trace ID가 부여되고 전달된다.
• 메트릭(Metrics) : Micrometer 2가 OpenTelemetry 포맷으로 메트릭을 내보내며, CPU/메모리/응답시간 등의 지표를 수집한다.
• 로그(Logs) : 애플리케이션 로그에 Trace ID가 자동으로 주입되어, 해당 요청의 로그를 손쉽게 연결해 볼 수 있다.

즉, 하나의 Trace ID로 해당 요청의 로그-메트릭-트레이스를 모두 추적할 수 있게 되었고, 덕분에 장애 원인 파악 시간이 기존 15-30분에서 3-5분 수준으로 단축될 수 있습니다.
 
의미
Spring Boot 4.0 덕분에 운영 환경에서의 가시성이 획기적으로 높아져 문제를 빠르게 진단하고 대응할 수 있습니다. 이제 별도 설정이나 복잡한 연동 없이 애플리케이션에 Observability가 내장된 형태가 되므로, 서비스 안정성과 운영 효율성 측면에서 큰 향상을 기대할 수 있습니다.

 

API Versioning: 버전 관리의 해법

문제상황
모바일 앱 등 클라이언트가 여러 버전(v1, v2, v3 등)을 동시에 사용하면, 서버는 버전별로 응답 구조를 다르게 처리해야 한다.
아래와 같이 분기로 버전을 관리해야했다.

if (version.equals("v1")) { 
                            ... 
                }
else if (version.equals("v2")) { 
                        ... 
                }

 
변경점
Spring Boot 4.0부터 Spring MVC와 WebFlux 모두에서 API 버저닝을 자동구성으로 지원한다.
컨트롤러 메서드에 애노테이션으로 지원 버전을 명시하면 해당 버전에 맞는 요청만 자동 라우팅되도록 해준다.

@RestController
@RequestMapping("/api/orders")
public class OrderController {

    @GetMapping(version = "1.0")
    public OrderV1Response getOrder(@PathVariable Long id) {
        // v1 로직
    }

    @GetMapping(version = "2.0")
    public OrderV2Response getOrder(@PathVariable Long id) {
        // v2 로직
    }

}

또한 ApiVersionResolver, ApiVersionParser 등의 빈을 직접 정의해 커스터마이징할 수도 있습니다.

 

Resilience Annotations: 안정성을 코드에 선언하라!

 
문제 상황
예를들어 위임등록 API가 간헐적으로 실패하는 문제가 있다고 해보겠습니다. 이를 해결하기 위해 재시도 로직을 직접 구현하면, 아래와 같이 while 문과 try문 등으로 구현을 해야한다.

int attempts = 0;
while (attempts < 3) {
    try {
        return delegationApi.process(order);
    } catch (Exception e) {
        attempts++;
        Thread.sleep(1500 * attempts);
    }
}

 
변경점
Spring Framework 7 (Spring Boot 4.0이 기반으로 하는 프레임워크)에서 Resilience 관련 애노테이션 지원이 내장되었습니다.
Spring Boot 4.0에서는 이를 바로 활용할 수 있다.

• @Retryable과 @Backoff 애노테이션으로 자동 재시도 및 지수 백오프를 손쉽게 적용가능
• @CircuitBreaker 나 @RateLimiter 등 Spring Cloud 없이도 사용할 수 있는 내장 제한기능 (일부는 Spring Cloud CircuitBreaker 통합)
• @ConcurrencyLimit 애노테이션으로 동시 실행 제한 등 (ex: @ConcurrencyLimit(maxConcurrent = 50))

@Service
public class DelegationService implements DelegationUseCase {

    @Retryable(
        maxAttempts = 3,
        backoff = @Backoff(delay = 1000, multiplier = 2)
    )
    public DelegationResult insertDelegation(DelegationCommand command) {
        return DelegationApi.process(command);
    }
}

이렇게 어노테이션만 붙이면 Spring이 해당 메서드 호출을 프록시하여 실행 안정성 패턴을 적용해준다.
효과
이제 별도 라이브러리(Resilience4j) 추가 없이도 장애 내성 패턴들을 구현할 수 있어 코드가 간결해지고 일관성있게 된다.

모듈화 및 경량화 (필요한 것만 로딩): 메모리/스타트업 최적화

문제상황
비교적 단순한 서비스라도 Spring Boot를 사용하면 JAR 파일 크기가 크고, 네이티브 이미지도 거대하며, 부팅 시간도 길어지는 경향이 있었습니다.
변경점
Spring Boot 4.0에서는 코드베이스 전면 모듈화를 통해 의존성 트리밍과 경량화가 이루어졌습니다.
사용하지 않는 부분은 클래스패스에 아예 포함되지 않도록 설계되었고, 많은 Auto-config가 세분화되었다.
 
효과
필요한 것만 포함하는 Pay-as-you-go 모듈화로 인해 다음과 같은 개선이 나타났습니다:

• JAR 빌드 결과물 크기 약 40~50% 감소 (예: 80MB -> 45MB 수준)
• GraalVM 네이티브 이미지 크기 60% 이상 감소 (200MB+ -> 80MB 수준)
• 애플리케이션 시작 시간 1초 미만으로 단축 (기존 2~3초 -> 0.9초 내외)

이로써 메모리 및 스토리지 비용이 절감되고 컨테이너 배포 시에도 이미지를 더 작고 빠르게 배포할 수 있다. 특히 마이크로서비스 환경에서 이러한 경량화는 서비스 밀도 증가와 비용 절감으로 직결된다.
 
 

결론: Spring Boot 4.0, 도입해야 할까요?

Spring Boot 4.0은 단순한 프레임워크 업그레이드가 아니라 우리 백엔드 스택의 다음 세대를 여는 전환점이라고 할 수 있다.
이번 버전에서 소개된 변화들은 모두 실무에서 부딪히는 문제들을 해결하고 개발/운영을 개선하는 데 초점을 맞추고 있다.
업그레이드의 필요성은 명확합니다. 성능 측면에서 더 빠르고 가벼운 서비스로 비용을 절감할 수 있고, 개발 생산성 측면에서 반복 작업을 줄이고 품질을 높일 수 있다.
운영 측면에서는 관측성과 안정성이 강화되어 서비스 신뢰도를 높일 수 있다.
결론적으로, Spring Boot 4.0 도입은 선택이 아니라 필수에 가까운 변화로 보인다.
 
 
 
출처
https://devloo.tistory.com/entry/Spring-Boot-40-완벽-가이드-실무-성능-9배-향상시킨-5가지-핵심-변화#:~:text=Spring Boot 4,설정 한 줄이면 됩니다
https://spring.io/blog/2025/11/20/spring-boot-4-0-0-available-now