> For the complete documentation index, see [llms.txt](https://leehyokyun.gitbook.io/openbook/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://leehyokyun.gitbook.io/openbook/2-8.-web-webflux.md).

# 2-8. Web 비동기 (Webflux)

Spring Web flux에 대하여

### 1. 전통적인 Thread per Request 모델의 Blocking I/O 제어 방식과 성능적 한계점

* 전통적인 웹 애플리케이션 처리 구조: Spring WebMVC와 같은 전통적인 서블릿 기반 프레임워크 환경에서는 클라이언트로부터 인입되는 HTTP 요청 한 개당 톰캣(Tomcat)의 워커 스레드(Worker Thread) 하나를 동적으로 배정하는 Thread per Request 모델을 채택하여 구동된다.
* 시스템콜 및 I/O 대기 시의 블로킹(Blocking) 현상: 요청 1은 워커 스레드 1에, 요청 2는 워커 스레드 2에, 요청 3은 워커 스레드 3에 각각 매핑되어 실행된다. 이 구조에서는 각 스레드가 내부 파일 시스템 연산이나 외부 데이터베이스(DB) 및 네트워크 I/O 호출을 수행할 때, 운영체제 커널의 시스템콜 응답이 완전히 반환될 때까지 스레드 자체가 물리적으로 멈추는 블로킹 상태에 정체된다.
* 컨텍스트 스위칭(Context Switching) 오버헤드와 자원 제약: 동시 트래픽이 폭증할수록 시스템은 늘어나는 요청을 처리하기 위해 수많은 스레드를 연이어 생성하게 된다. 이로 인해 한정된 CPU 코어 위에서 수많은 스레드가 실행 공간을 교체하며 발생하는 CPU 레지스터 전환 오버헤드(스레드 컨텍스트 스위칭 비용)가 급격히 증가한다. 결과적으로 무거운 Blocking I/O 연산과 결합하여 전체적인 시스템 처리 처리율(Throughput)이 심각하게 저하되는 태생적 구조성 한계를 지닌다.

### 2. Spring WebFlux의 Reactor 기반 비동기/Non-Blocking 아키텍처 및 이벤트 루프 설계 구조

* WebFlux의 본질적 아키텍처 사상: Spring WebFlux는 전통적인 대기 방식의 한계를 극복하기 위해 Reactive Streams 표준 명세를 구현한 Reactor 라이브러리를 기반으로 설계되었다. 적은 수의 스레드만으로도 대규모 동시 요청을 유연하게 처리할 수 있는 비동기(Asynchronous) 및 논블로킹(Non-Blocking) 이벤트 루프(Event Loop) 모델 서버를 핵심 구동 엔진으로 삼는다.
* 멀티스레드 기반 병렬 처리 및 코어 결합 구조: 싱글 스레드(Single Thread) 엔진 기반으로 작동하는 Redis나 JavaScript(Node.js)의 이벤트 루프 환경과 달리, Spring WebFlux의 내장 서버 환경(Netty 등)은 호스트 OS의 실제 CPU 코어 개수에 비례하여 멀티스레드(Multi-Thread) 방식으로 다중 이벤트 루프를 운용한다.
  * 이벤트 루프 스레드 1 -> CPU 코어 1 연동
  * 이벤트 루프 스레드 2 -> CPU 코어 2 연동
  * 이벤트 루프 스레드 3 -> CPU 코어 3 연동
  * 이벤트 루프 스레드 4 -> CPU 코어 4 연동
* 이와 같이 CPU 코어 수에 맞추어 할당된 각 스레드들이 개별적인 독립 이벤트 루프를 병렬적으로 동시 구동하기 때문에, 자원의 낭비를 완벽하게 차단하면서 고성능 병렬 처리(Parallel Processing) 연산을 극대화하여 실현할 수 있다.

### 3. WebFlux 요청 처리 메커니즘의 단계별 동적 흐름 (Runtime Lifecycle)

* 1단계 (클라이언트 요청 도착): 외부 클라이언트가 웹 서버를 대상으로 HTTP 프로토콜 기반의 전송 요청을 가동하면, 호스트 OS(서버) 레이어의 네트워크 카드를 거쳐 시스템 내부로 요청이 인입된다.
* 2단계 (Netty EventLoop의 epoll 기반 감지 프로세스): WebFlux의 하부 네트워크 구동 인프라인 Netty 엔진이 작동하여, 운영체제 커널이 제공하는 고성능 멀티플렉싱 I/O 시스템콜인 epoll 메커니즘을 통해 해당 인입 요청을 유실 없이 즉각적으로 감지하고 추적한다.
* 3단계 (EventLoop 스레드의 요청 처리 시작): 요청이 정상 감지되면, 준비된 다중 EventLoop 스레드 중 하나가 해당 요청 제어권을 즉시 인계받아 상위 애플리케이션 레이어의 비즈니스 로직 연산을 실행하기 시작한다.
* 4단계 (Non-blocking DB/네트워크 외부 호출 및 스레드 해제): 비즈니스 로직 수행 중 데이터베이스 조회나 외부 API 연동 등 물리적인 I/O 작업이 발생할 때, 해당 데이터 액세스 모듈이 논블로킹(Non-blocking)을 지원하는 구조라면 해당 스레드는 결과를 무작정 서서 기다리지 않는다. 대신 I/O 연산 자체를 하부 커널 및 네트워크 전담 영역으로 완전히 위임하여 처리 제어권을 넘겨버린 뒤, 자기 자신은 즉시 해제되어 큐(Queue)에 대기 중인 다른 사용자의 또 다른 비즈니스 작업을 처리하러 떠난다.
* 5단계 (응답 준비 완료 및 EventLoop 재전송): 외부 I/O 레이어에서 요청한 데이터 처리가 완벽하게 끝나 응답 페이로드가 수신되면, 시스템은 이 완료 상태를 이벤트 형태로 다시 발행한다. 유휴 상태이거나 가용 상태인 EventLoop 스레드가 해당 완료 이벤트를 캐치하여, 최종적으로 정돈된 HTTP 응답 데이터를 원본 클라이언트 측에 안전하게 역전송하며 전체 라이프사이클을 완수한다.

### 4. WebMVC와 WebFlux의 최종 처리 레이어 책임 및 결정적 차이점

* 애플리케이션 영역의 처리 주체성 분리: 인프라 아키텍처 관점에서 클라이언트의 요청 패킷을 호스트 OS 측에서 정밀하게 감지하고 이벤트 루프 기반 스레드로 밀어 넣어 처리하는 일련의 구조는 동일하지만, 최종적으로 인계받은 데이터를 애플리케이션 영역(Application Side)에서 처리하는 방식에서 명확한 결정적 차이점이 발생한다.
* WebMVC (Servlet 프레임워크 구조): 요청이 들어오는 시점부터 동기(Synchronous) 방식으로 작동한다. 배정된 하나의 스레드 선상에서 비즈니스 메서드 호출, DB 조회, 뷰 렌더링 또는 직렬화 연산이 처음부터 끝까지 순차적이고 동기적인 흐름으로 묶여 실행되며, 작업 완료 시까지 해당 스레드의 제어권 점유를 철저하게 유지한다.
* WebFlux (Reactive 프레임워크 구조): 요청을 처리하는 전 과정이 비동기(Asynchronous) 방식으로 쪼개져 작동한다. Publisher와 Subscriber 간의 스트림 파이프라인 안에서 데이터가 인입되는 시점마다 이벤트 기반으로 유기적으로 연동되며, 개별 I/O 연산 시 제어권을 즉시 반환(Return Immediately)받아 스레드 유휴 상태를 원천 배제하는 고도로 최적화된 비동기식 흐름을 관철한다.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://leehyokyun.gitbook.io/openbook/2-8.-web-webflux.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.