WebFlux는 왜 스레드를 8개만 쓰는가
Thread-per-Request 모델이 I/O 앞에서 무너지는 이유부터 epoll 이벤트 루프, Reactive Streams 스펙, 그리고 WebFlux vs MVC 선택 기준까지 하나의 흐름으로 추적한다.
총 7편 · 순서대로 읽기를 권장
Thread-per-Request 모델이 I/O 앞에서 무너지는 이유부터 epoll 이벤트 루프, Reactive Streams 스펙, 그리고 WebFlux vs MVC 선택 기준까지 하나의 흐름으로 추적한다.
Mono/Flux의 지연 평가부터 Backpressure 전략, Reactor Context까지 — WebFlux가 왜 이 방식으로 동작하는지, 그 근본 원리를 추적한다.
Boss/Worker EventLoopGroup 분리부터 ChannelPipeline, EventLoop 블로킹 위험, ConnectionProvider 연결 풀 튜닝까지, Spring WebFlux의 성능 설계를 추적한다.
DispatcherHandler의 Reactive 위임 구조부터 WebClient 병렬 호출, SSE/WebSocket 스트리밍, WebFilter 불변 패턴까지 — WebFlux 설계 철학의 일관된 흐름을 추적한다.
JPA의 블로킹 JDBC가 EventLoop를 점유하는 원리부터 R2DBC의 논블로킹 구조, Reactor Context 기반 트랜잭션, N+1 해결 패턴까지 WebFlux 데이터 계층의 설계 결정을 추적한다.
MVC Security의 ThreadLocal 기반 설계가 Reactor Context로 대체되는 과정부터, JWT 필터 체인·Method Security·OAuth2 Client Credentials 흐름까지, Reactive Security 전체를 관통하는 설계 원칙을 추적한다.
I/O 집약 고동시성 환경에서 WebFlux가 MVC를 압도하는 조건부터, 블로킹 의존성·팀 역량·도메인 복잡도가 만드는 함정까지, 도입 판단의 기준을 추적한다.