TL;DR — 인수받은 서버는 Spring WebFlux였지만 데이터 접근은 블로킹 **JPA(Hibernate/JDBC)**였다. WebFlux의 핵심인 논블로킹 I/O 이점은 하나도 못 얻으면서, Mono/Flux의 복잡성과 소수 이벤트루프 스레드가 DB 호출에 막히는 위험만 떠안고 있었다. auth/course/submit 전 모듈을 Spring MVC(서블릿)로 전환하고, 리액티브는 게이트웨이(Spring Cloud Gateway) 경계로만 한정했다.

배경

• 프로젝트: CodeQuest — Spring Boot 3.4.3, Spring Data JPA(Hibernate), MySQL, K8s
• 구조: gateway / auth / course / submit 멀티모듈. 전부 spring-boot-starter-webflux 기반이었다.
• 왜 들여다봤나: 데이터 계층이 JPA(블로킹 JDBC)인데 웹 계층만 WebFlux인 불일치가 고용아. 부하테스트에서 제출 경로가 동시성에 취약한 게 드러났다.

문제 (증상)

• WebFlux는 적은 수의 이벤트루프 스레드(보통 CPU 코어 수)로 논블로킹 I/O를 처리하는 모델이다.
• 그런데 JPA/Hibernate는 블로킹 JDBC — repository.findById() 한 번이 DB 응답까지 그 이벤트루프 스레드를 통째로 점유한다.
• 결과: 동시 요청이 조금만 몰려도 몇 개 안 되는 이벤트루프 스레드가 전부 DB 대기로 막혀 스롯업 → 지연 폭발. 동기 MVC보다 오히려 나쁜 상황도 나온다.
• 그 대가로 얻는 건 없다 — R2DBC 같은 리액티브 드라이버가 아니라 논블로킹 체인이 끊기므로, WebFlux의 이점(적은 자원으로 높은 동시성)은 0이고 Mono/Flux 학습·디버깅 비용만 남는다.

원인 분석

• 핵심: 리액티브 스택은 "끝까지 논블로킹"일 때만 의미가 있다. 체인 중간에 블로킹 JDBC가 끼면 그지점이 병목이 되고, 하필 그 지점이 가장 빈번한 데이터 접근이다.
• 우회로 Schedulers.boundedElastic()로 블로킹 호출을 별도 스레드풀로 밀어낼 수도 있지만, 그러면 결국 thread-per-request를 손으로 재현하는 꼴 — 처음부터 MVC(서블릿, 요청당 스레드) 모델이 블로킹 JPA에 자연스럽다.
• 결론: 이 서비스의 I/O 모델과 정합하는 건 WebFlux가 아니라 MVC다. 리액티브가 진짜 필요한 곳은 고동시 프록시·라우팅 계층인 게이트웨이뽐이다.

해결 — 전 모듈 MVC 전환

auth → course → submit 순으로 전환하고, common의 리액티브 JWT 빈은 게이트웨이로 이전했다.

1) 의존성

- implementation 'org.springframework.boot:spring-boot-starter-webflux'
+ implementation 'org.springframework.boot:spring-boot-starter-web'
+ implementation 'org.springframework.boot:spring-boot-starter-websocket'
- implementation 'org.springdoc:springdoc-openapi-starter-webflux-ui:2.7.0'
+ implementation 'org.springdoc:springdoc-openapi-starter-webmvc-ui:2.7.0'

2) 필터 · 시큐리티: WebFilter(ServerWebExchange/Mono) → OncePerRequestFilter(HttpServletRequest/FilterChain)

- public class IpAddressFilter implements WebFilter {
-     public Mono<Void> filter(ServerWebExchange exchange, WebFilterChain chain) { ... }
+ public class IpAddressFilter extends OncePerRequestFilter {
+     protected void doFilterInternal(HttpServletRequest req, HttpServletResponse res, FilterChain chain) { ... }