TIL

5. WebFlux 개요

• Reactor(1~4단계) 위에 올라가는 웹 프레임워크 — 서블릿 스택 Spring MVC의 리액티브 짝
• 짝이 되는 서블릿 스택은 Web MVC 참고

두 개의 웹 스택

• Spring은 서로 다른 두 웹 스택을 나란히 제공하며, 애플리케이션은 하나를 고르거나 (마이크로서비스 단위로) 혼용한다

	Spring MVC	Spring WebFlux
기반 API	서블릿 (동기·블로킹 전제)	리액티브 스트림 (논블로킹)
스레딩	요청당 스레드, 큰 풀	이벤트 루프, 소수 고정 스레드
기본 서버	Tomcat	Netty
반환 타입	도메인 객체	Mono/Flux
데이터 접근	JPA/JDBC (블로킹)	R2DBC·리액티브 드라이버 (논블로킹)

WebFlux는 왜 만들어졌나

• (a) 논블로킹 웹 스택의 필요 — 적은 스레드로 동시성을 처리하고 더 적은 자원으로 확장하기 위해
  • 서블릿 3.1이 논블로킹 I/O를 줬지만, 서블릿 API의 나머지 계약이 동기(Filter, Servlet)·블로킹(getParameter, getPart)이라 끝까지 논블로킹으로 가기 어려움 → 논블로킹 런타임 공통 기반으로 쓸 새 API가 필요했음
• (b) 함수형 프로그래밍 — Java 8 람다로 함수형 웹 엔드포인트를 애노테이션 컨트롤러와 함께 제공할 여지가 생김

프로그래밍 모델 두 가지

• 애노테이션 컨트롤러: @Controller/@RequestMapping 등 Spring MVC와 동일한 애노테이션, 리액티브 반환 타입(Mono/Flux)·리액티브 @RequestBody 지원 (6단계에서)
• 함수형 엔드포인트: RouterFunction 기반의 가볍고 람다 중심적인 모델 (7단계에서)

DispatcherHandler — 프런트 컨트롤러

• Spring MVC의 DispatcherServlet에 대응하는 중앙 WebHandler — 공통 요청 처리 알고리즘을 제공하고, 실제 작업은 위임 컴포넌트가 수행
• 위임 컴포넌트를 스프링 설정에서 발견 (빈 이름 webHandler), 자신도 스프링 빈
• 위임하는 특수 빈

특수 빈	역할
HandlerMapping	요청 → 핸들러로 매핑 (애노테이션 컨트롤러, URL 패턴 등 구현별 기준)
HandlerAdapter	매핑된 핸들러를 일반화된 방식으로 호출 — 호출 세부를 DispatcherHandler로부터 숨김
HandlerResultHandler	핸들러 결과를 처리해 응답을 완성 (직접 쓰기 또는 뷰 렌더링)

• 리액티브 HttpHandler/ServerWebExchange 추상화 위에서 동작하며, 처리 완료는 Mono<Void>로 신호

서버와 스레딩 모델

• 서버: Netty(Spring Boot 기본 — 비동기·논블로킹 영역에서 널리 쓰이고 클라이언트/서버가 자원 공유), 그리고 Tomcat·Jetty·Undertow·서블릿 컨테이너(서블릿 3.1+ 논블로킹 I/O)
• 스레딩: 논블로킹 서버는 “앱이 블로킹하지 않는다“고 전제 → 소수 고정 크기 이벤트 루프 워커(보통 CPU 코어 수)로 요청 처리
  • 대조: 서블릿 컨테이너는 요청 처리 중 블로킹을 흡수하려고 큰 스레드 풀 사용
  • “확장”과 “적은 스레드”가 모순 같지만, 절대 블로킹하지 않고 콜백에 의존하면 블로킹을 흡수할 여분 스레드가 애초에 필요 없다는 논리
  • ⚠️ 이벤트 루프를 블로킹하면 안 됨 → 불가피한 블로킹은 publishOn/boundedElastic로 오프로드(4단계)

언제 WebFlux를 쓰나 (Applicability)

• 공식 지침
  • 잘 도는 MVC 앱은 바꿀 필요 없다 — 명령형이 작성·이해·디버깅이 가장 쉬움
  • 의존성으로 판단: 블로킹 영속성(JPA/JDBC)·네트워킹 API를 쓰면 대개 MVC가 낫다
  • MVC에서 원격 호출만 리액티브로 바꾸려면 WebClient 도입 — 컨트롤러에서 리액티브 타입을 그대로 반환 가능
  • 마이크로서비스에선 MVC/WebFlux/함수형을 혼용 가능
  • 큰 팀은 논블로킹·함수형·선언형으로의 전환에 가파른 학습 곡선을 감안
• 정리: 끝까지 논블로킹(R2DBC·리액티브 드라이버)일 때, 스트리밍/SSE, 높은 동시성을 적은 자원으로 감당해야 할 때 WebFlux가 유리

리액티브 vs 가상 스레드

• WebFlux의 핵심 이점은 “적은 스레드로 확장” — 그런데 Java 21 가상 스레드(Loom)는 블로킹 코드를 그대로 두고도 스레드를 값싸게 만들어 비슷한 확장성을 노린다
• 가상 스레드가 푸는 것: 스레드당 비용(요청당 스레드 모델의 확장 한계) → Spring MVC + 가상 스레드(spring.threads.virtual.enabled=true)로 블로킹 API도 높은 동시성 처리
• 가상 스레드가 못 푸는 것: 배압, 선언형 합성, 스트리밍 파이프라인 — 이건 여전히 리액티브의 몫
• 선택 기준
  • 블로킹 라이브러리 중심 + 동시성만 필요 → MVC + 가상 스레드가 단순
  • 끝까지 논블로킹 + 스트리밍·배압이 필요 → WebFlux
• 가상 스레드 자체는 가상 스레드 참고