Spring Boot 2 ~ 4버전 알아보기

얼마전 감사하게도 면접 기회를 얻어서 면접을 보게되었다.

그런데 스프링부트 버전 차이와 최신 버전에 대한 질문에 답을 못했다...(흑..)

하지만 어제 몰랐으면 오늘 알면 되는 것이다. 

그런 의미에서 오늘은 스프링부트 버전에 대해서 포스팅을 해보려한다. 

---

1. Spring Boot 2.x 버전

1-1) Spring WebFlux 도입

Spring WebFlux는 Spring Framework 5.0에 도입된 새로운 리액티브 웹 프레임워크다.

Spring Boot 2.x 버전에 처음으로 Reactive 웹 스택(WebFlux)가 처음으로 도입됐다.

이전까지 Spring의 웹 스택은 거의 Servlet 기반의 Spring MVC가 전부였다.

 

💡Spring MVC 와 Spring WebFlux의 차이

구분	Spring MVC	Spring WebFlux
처리 방식	Blocking	Non-blocking
요청 처리	요청 1개 = 쓰레드 1개 점유	적은 쓰레드로 다수 요청 처리
기반 기술	Servlet API	Reactive Streams
서버	Tomcat	Netty

 

포인트 1. WebFlux 를 쓰려면 Reactive DB를 함께 사용하자.

WebFlux의 처리방식은 Non-blocking이다. 

JPA+Hibernate와 같은 JDBC 기반의 DB는 설계 자체가 DB 응답이 올때까지 리턴하지 않도록 설계되어있다.

WebFlux 성능이점을 누리려면 DB도 Reactive DB를 써야한다.

 

포인트 2. Spring MVC와 Spring WebFlux 처리방식

기존 Spring MVC 방식에서는 요청 1개에 쓰레드 1개를 점유했기때문에 트래픽이 많아지면 쓰레드가 고갈되고 성능이 저하됐었다.

WebFlux 방식은 요청이 오면 이벤트 루프가 처리하고 DB를 기다리는 동안 쓰레드를 안 잡고 있고 응답 준비가 되면 콜백으로 이어서 처리한다. 

 

포인트 3. 언제 Spring MVC를 쓰고, 언제 WebFlux를 쓰는가?

- 일반 CRUD 서비스는 Spring MVC로 충분하다.

- 많은 요청을 효율적으로 처리해야 하는 경우 WebFlux가 유리하다. 

ex) 고동시성, 스트리밍, 채팅 등의 서비스

 

1-2)  최소 Java 8 버전을 사용해야함

왜 최소 버전이 Java 8 이상일까?

Spring Boot 2는 Spring Framework 5 기반이고, Spring Framwork 5는 최소 JDK 8을 요구하기 때문이다.

Java 8이 최소사양이 되면서 람다(Lambda) , 스트림(Stream) API를 적극 활용하기 시작했다.

 

1-3) Micorometer 라이브러리를 통해 Prometheus 같은 외부 모니터링 도구와 쉽게 연동가능해짐

공식문서를 보면 Spring Boot Actuator는 Micrometer에 대해 의존성 관리와 자동설정을 제공한다고 되어있다.

 

즉, 이전에는 Prometheus를 쓰면 Prometheus용 코드로 수정을 해야했고 Datadog를 쓰면 Datadog용 코드로 바꿔줘야했는데 

Micrometer 도입 후에는 모니터링 도구가 바뀌어도 코드 수정이 거의 없게되는 것이다.

 

1-4)  Kotlin 지원 강화

이전에는 Kotlin 코드가 돌아가기는 했지만, 공식문서 대부분 Java 기준이었다.

하지만 Spring Boot 2부터는 돌아가기만 하는 언어가 아니라 공식지원해주는 언어로 승격되었다.

 

2. Spring Boot 3.x 버전

2-1) Java 17 최소 사양

 

 

2-2) 패키지 네임스페이스가 javax.*에서 jakarta.*로 전면 변경

(신입 시절에 차세대 프로젝트에 참여했었는데, AS-IS는 패키지명이 javax고 TO-BE의 패키지명은 jakarta였던게 생각난다.)

Java EE가 Oracle에서 Eclipse 재단으로 넘어가면서 패키지명이 바뀐 것이라고 한다.

 

2-3)  Native Image 지원 (GraalVM)

Spring Boot 3 버전에서는 AOT 엔진을 도입하여 GraalVM Native Image를 공식 지원하며, 이를 통해서 빠른 기동 시간과 낮은 메모리 사용량을 제공하여 클라우드 및 서버리스 환경에 최적화되었다.

 

💡JVM 과 Native Image 의 차이

구분	JVM 실행	Native Image
실행 방식	인터프리터 + JIT	미리 기계어 생성
기동속도	느림	매우 빠름
메모리 사용	큼	적음
런타임 최적화	가능	제한적
리플렉션	자유로움	제한있음

 

JVM은 실행 중에 필요한 클래스와 기능을 동적으로 로딩할 수 있어 유연성이 높다.

반면, Native Image는 빌드 시점에 모든 실행 경로를 분석해 고정된 실행 파일을 생성하기 때문에, 런타임에 동적으로 결정되는 기능에는 제약이 있다.

 

3. Spring Boot 4.x 버전

2025년 11월 20일에 스프링 부트 4.0.0이 정식 출시됐다.

Spring Boot 4.0.0 available now

3-1) API 버전 관리 및  HTTP 서비스 클라이언트 내장

기존에는 API 버전 관리를 우리가 직접 설계해야 했고, HTTP 클라이언트도 외부 라이브러리에 많이 의존했다.
Boot 4는 이걸 프레임워크 레벨에서 구조화해준다.

 

💡실무에서 중요한 이유

 

• 마이크로서비스 환경에서 직접적인 생산성 변화
• 외부 API 호출 방식 표준화
• 버전 전략을 프레임워크 레벨에서 지원
• 팀 간 협업 구조에 직접 영향

3-2) 코드베이스의 완전한 모듈화

이전에는 큰 덩어리 JAR 안에 여러 기능이 같이 들어있었는데, 이제 스프링 부트 내부 구조가 더 작고 집중된 JAR 단위로 쪼개졌다.

따라서, 애플리케이션 빌드 시 불필요한 코드가 같이 딸려오지 않도록 구조 개선이 이뤄졌다.

개발 방식 자체를 바꾸는 변화는 아니지만, 의존성 경량화와 빌드 안정성, 그리고 클라우드 환경에서의 실행 효율을 개선하는 기반이 된다.

 

💡실무에 영향을 미치는 것

 

• 의존성 충돌 감소
• 빌드 시간 단축
• 메모리 사용량 감소
• 내부 유지보수성 증가

3-3) JSpecify를 통한 Null 안정성 강화

JSpecify는 Java에서 null 가능 여부를 표준 어노테이션으로 정의하려는 프로젝트다.

 

Java는 기본적으로 모든 참조 타입이 null이 가능하고 단순히 코드만 보고 null을 반환하는지 아닌지 모른다.

이전 버전에서는 런타임에 NullPointerException이 터졌다면, 이제 컴파일 시점에 경고를 받게 된다.

코드로 이해해보자.

 

✅Before

String nickname = user.getNickname();
nickname.length(); // 런타임에서 NPE

 

✅After

@Nullable String nickname = user.getNickname();
nickname.length(); // 컴파일 시점 경고

 

 

3-4) Java 25 공식 지원 (Java 17 호환성 유지)

Java 25는 2025년 9월에 발표된 최신 LTS 버전이다.

Java 21에서 도입된 가상 스레드가 Java 25에서 더욱 안정화 되었다.

Spring Boot 4.0에서는 WebFlux 없이도 높은 동시성을 구현할 수 있는 기반이 강화되었다.