Spring WebFlux 핵심 내용 정리: 진짜 비동기, 논블로킹을 위한 설계 조건

WebFlux에 대해 이해가 잘 가지 않았던 점을 조사하고 정리해 보았다.

 

1. WebFlux는 메서드의 반환을 비동기적으로 처리할 수 있게 해 주며, 메서드들은 Mono 또는 Flux와 같은 비동기 객체를 반환한다. 대부분의 경우, 이 스트림이 완료되었을 때 HTTP 응답을 전송하지만, Flux를 이용한 스트리밍 응답처럼 중간에 데이터를 전송할 수도 있다.
2. 이 구조 덕분에 요청마다 스레드를 붙잡아두지 않아도 되기 때문에, 시스템은 훨씬 더 효율적으로 스레드를 활용할 수 있다.
   즉, WebFlux를 사용하는 가장 큰 이유는 요청 수가 많아질 때도 상대적으로 더 잘 버틸 수 있기 때문이다.
3. 하지만 아무리 비동기 흐름이라도, 중간에 DB I/O나 파일 I/O처럼 블로킹 작업이 포함되면 해당 작업은 별도 스레드에서 대기하게 되고, 결과적으로 WebMVC처럼 병목이 발생할 수 있다.
   (WebFlux는 boundedElastic 풀을 통해 블로킹을 분리할 수 있지만, 결국 스레드는 여전히 점유됨)
4. 따라서 WebFlux의 성능을 제대로 끌어내기 위해선, 전체 흐름을 논블로킹 방식으로 설계해야 한다.
5. 논블로킹이란, 작업 중 스레드를 계속 점유하지 않고, 결과가 준비되면 비동기적으로 후속 처리를 이어가는 방식을 의미하며, 호출 즉시 값을 반환하거나 Mono, Flux 같은 스트림(혹은 Mono, Flux으로 감싼 값)을 반환하는 방식이다.
6. 결론적으로 WebFlux를 제대로 활용하려면, Reactive Stream(Mono, Flux)을 중심으로 코드를 설계하는 것이 필수적이다.
7. 기존의 블로킹 작업이 있다면, Mono.fromCallable() 등으로 감싸고 subscribeOn(Schedulers.boundedElastic())으로 스레드를 분리하거나, 아예 논블로킹 API로 대체해 Reactive Stream으로 구성해야 한다.
8. 대표적인 논블로킹 기술로는 WebClient, R2DBC, Spring Cloud Stream, Reactor Kafka, Lettuce Reactive Client, ReactiveRedisTemplate, WebSocketHandler 등이 있으며, 이들은 모두 Mono 또는 Flux를 반환해 논블로킹 흐름을 구성하는 데 도움을 준다.

결국, WebFlux를 쓸 때, 블로킹 I/O들은 Reactive Stream으로 처리를 할 수 있어야 비동기적으로 프로그래밍이 가능하고 많은 요청이 들어올 경우에도 내구성을 가질 수 있다.