
Spring WebFlux에 대하여 알아보자
Spring WebFlux는 반응형 리액티브 시스템으로,
스프링에서 나타난 리액티브 프레임 워크이다.
Spring WebFlux에 대하여 알기 이전에, 우선적으로는
Spring MVC에 대한 파악을 해야한다.
Spring MVC의 기본
기존의 Spring은 Web MVC 패턴을 기반으로 설계하여,
개발자들이 POJO(Plain Old Java Object) 형태로 비즈니스 로직을 작성할 수 있도록 다양한 편의기능들을 제공해주었다.

위의 대표적인 스프링 컨테이너에 대한 그림처럼,
DispatcherServletContainer가 Spring의 가장 큰 핵심적인 요소이다.
이 컴포넌트는 클라이언트의 모든 요청을 "중앙"에서 처리하고,
적절한 컨트롤러로 위임하는 역할을 수행한다.
즉, 서블릿들을 일괄적으로 관리하는 "서블릿 컨테이너"의 역할을 하며,
이는 Spring MVC의 핵심 아키텍처 특징이다.
Spring WebFlux와의 비교
Spring MVC와 Spring WebFlux는 둘 다 웹 계층을 구성하지만,
요청 처리 방식과 프로그래밍 모델의 근본적인 "관점" 차이를 갖는다.
- Spring MVC는 Thread-per-request 모델 기반의 동기(Synchronous) 블로킹 방식이다.
- Spring WebFlux는 Reactive Streams 기반의 비동기(Asynchronous) 논블로킹 방식으로 동작한다.
이러한 차이는 내부 처리 흐름과 핵심 구성 요소에서도 명확히 드러난다.

위는 Spring WebFlux에서 요청이 처리되는 전체 흐름이다.
- client가 요청을 한다
- client로부터 요청이 들어오면 Netty 등의 논블로킹 서버 엔진을 거쳐서 HTTP handler가 들어오는 요청들에 대하여 수신한다. (이 단계까진 Spring MVC와 비슷)
- HttpHandler 진입 및 ServerWebExchange 생성
HttpHandler가 요청을 받아서
ServerWebExchange 객체를 생성한다.
이 객체는 요청 (ServletHttpRequest)와 ServletHttpResponse 정보를 포함하고,
이후 처리 과정 전반에 걸쳐 상태를 보존한다!
4. WebFilter 체인 실행( 위의 생성 객체에 대한 전처리 단계 )
이전 과정에서 생성된 ServerWebExchange는 WebFilter 체인을 통해 전달된다.
Spring MVC(ServletFilter)에서처럼 인증, 로깅, 공통헤더 처리 등 공통 로직이 이 단계에서 수행된다.
5. DispatcherHandler에 진입
필터 체인을 거친 요청은 WebHandler 의 구현체인 DispatcherHandler로 전달된다.
이 시점부터 WebFlux의 리액티브 흐름이 본격적으로 시작된다! (여기까지는 MVC)
6. HandlerMapping 탐색 (Reactive Source 기반)
Dispathcer Handler는 등록된 HandlerMapping목록을 Flux<HandlerMapping> 형태로 조회한다.
이는 기존 MVC의 단일 매핑과 다르게,
Reactive Stream 기반으로 비동기 탐색이 가능하다.
7. 핸들러 조회 및 어댑터 위임
적절한 핸들러가 조회되면, 해당 핸들러를 처리할 수 있는 HandlerAdapter 로 위임한다.
HandlerAdapter는 핸들러 타입에 따라 Controller, RouterFunction, HandlerFunction 등을 실행한다.
8. 핸들러 실행 및 결과 반환
컨트롤러(혹은 함수형 핸들러)는 리액티브 객체로
Mono 또는 Flux 형태로 결과를 반환한다.
즉, 반환값은 즉시 계산된 결과가 아니라 비동기적으로 발행되는 데이터 시퀀스(reactive sequence) 이다.
9. HandlerResultHandler 처리
반환된 Mono/Flux 결과는 HandlerResultHandler 에 의해 직렬화되어 HTTP 응답으로 변환된다.
10. 응답 전송
최종적으로 논블로킹 방식으로 클라이언트에게 응답이 전송된다.
이때 Reactor 시퀀스(Flux/Mono) 는 구독(subscribe())이 발생해야만 실제 데이터 흐름이 시작된다.
그래서 공통된 부분과 공통되지 않은 부분에 대하여 다음과 같이 정리할 수 있다.

이런식으로 확인이 가능하다
주로 핸들러의 반환 타입이 다르다는 점과, 서버의 차이 등 많이 나면서도,
전반적으로는 Spring WebFlux가 기존 Spring MVC의 구조를 계승하기 때문에
위와 같이 겹치는 부분들이 많다
Reactive Streams 사양(Publisher–Subscriber 모델) 을 기반으로 완전히 새로운 관점의 처리 방식을 제공하는 웹 플럭스는
단순히 “비동기 버전의 MVC”가 아니라,
데이터 흐름(Flow) 을 중심으로 설계된 반응형(reactive) 아키텍처이므로
러닝커브가 심하다는 단점도 있지만 그만큼 고부하 환경에서도 높은 확장성과 효율적인 리소스 사용이 가능해지기 때문에 논블로킹이 심화되는 요즘 중요해지고 있다.
'백엔드 > SpringBoot' 카테고리의 다른 글
| [Spring AI] Spring AI 버전 불일치와 설정 타이밍 문제 (4) | 2025.12.24 |
|---|---|
| [SpringBoot] 통합 테스트(Integeration Test) 알아보기 (2) | 2025.11.10 |
| [SpringBoot] 스프링에서의 Service 와 Bean의 차이점 (1) | 2025.10.04 |
| [Spring Boot] Thread 설정 (Spring Boot) (1) | 2025.09.27 |
| [SpringBoot] SpringBoot 트랜잭션과 이벤트 발행에서의 전파 관련 트러블 슈팅 (0) | 2025.09.15 |