MSA 아키텍쳐와 같은 분산형 클라우드 서비스 방식이 트렌드로 자리잡고 있는 가운데 Spring WebFlux 또한 최근의 웹 애플리케이션 개발에서 매우 중요한 기술로 자리잡고 있다. 비동기 처리와 반응형 프로그래밍 모델에 기반한 WebFlux는 높은 성능과 유연성을 제공하며, 사용자에게 더 나은 경험을 선사할 수 있다. 이번 포스트에서는 반응형 프로그래밍, Spring WebFlux의 주요 개념 그리고 Spring WebMVC와의 차이점까지 자세히 살펴보도록 하자.
🔥 Reactive Programming
WebFlux에 대해 알기전에 Reactive Programming에 대한 이해가 있어야한다.
Reactive Programming(반응형 프로그래밍)은 데이터 흐름과 변화에 반응하는 프로그래밍 모델이다. 기존의 동기 프로그래밍 방식에서는 데이터를 요청하고 응답이 올 때까지 대기해야 하지만, 반응형 프로그래밍에서는 데이터를 요청한 후 다른 작업을 수행하다가, 데이터가 준비되면 자동으로 응답을 받아 처리할 수 있다.
Reactive Programming의 핵심 개념은 게시자-구독자(Publisher-Subscriber) 패턴(=옵저버 패턴)을 기반으로 동작한다는 점이다. 게시자는 데이터를 생성하고, 구독자는 해당 데이터를 받아 처리하는 구조로 이루어져 있다. 예를 들어, 유튜브에서 특정 채널을 구독하면 새로운 영상이 업로드될 때마다 자동으로 알림을 받는 것과 같은 원리다. 이러한 방식은 데이터가 발생하는 즉시 반응할 수 있도록 만들어 주며, 기존의 요청-응답 방식보다 더 유연한 데이터 처리가 가능하다.
또한, 비동기 & 논블로킹 방식으로 동작한다. 기존의 동기 방식에서는 하나의 요청이 완료될 때까지 기다려야 하지만, 반응형 프로그래밍에서는 요청을 보낸 후 결과를 기다리지 않고 다른 작업을 수행할 수 있으며, 데이터가 준비되면 자동으로 결과를 받아 처리한다. 이는 특히 네트워크 요청, 파일 입출력, 데이터베이스 조회와 같이 시간이 걸리는 작업을 처리할 때 큰 장점을 가진다.
Reactive 시스템에서는 데이터를 빠르게 생성하는 경우가 많지만, 이를 소비하는 쪽에서는 처리 속도가 상대적으로 느릴 수도 있다. 이때, 백프레셔(Backpressure)라는 개념을 사용하여 데이터 흐름을 조절할 수 있다. 백프레셔는 생산자의 속도를 조절하여 소비자가 감당할 수 있는 만큼만 데이터를 받아오도록 하는 기능을 한다. 즉, 생산자가 너무 많은 데이터를 빠르게 보내면 소비자가 처리할 수 있는 수준에서만 받아들이도록 조절하여 시스템의 과부하를 방지한다.
🤔 옵저버 패턴(Observer Pattern)이란?
GoF(Gang of Four) 디자인 패턴 중 하나이며, 객체 간의 일대다(1:N) 관계를 정의하는 패턴이다. 주체(Subject, Publisher)의 상태가 변경될 때, 이를 구독한 옵저버(Observer, Subscriber)들에게 자동으로 알림을 전달하여 상태를 동기화하는 방식으로 동작한다.
이 패턴을 활용하면 객체 간의 결합도를 낮출 수 있으며, 이벤트 기반 시스템에서 많이 사용된다. Spring WebFlux의 Reactor 패러다임(Mono, Flux) 역시 옵저버 패턴을 기반으로 동작한다.
💡 Spring WebFlux
Spring WebFlux는 Spring 5에서 도입된 비동기 논블로킹 웹 프레임워크로, 비동기 및 반응형 애플리케이션을 개발하는 데 사용된다. 이는 이벤트 기반의 비동기 프로그래밍을 지원하며, 데이터 흐름이 많고 동시성이 중요한 애플리케이션에 적합하다.
WebFlux는 서버 리소스를 효율적으로 활용할 수 있도록 설계되었으며, 클라이언트와 서버 간 비동기 통신을 가능하게 한다. 내부적으로 Reactor 라이브러리를 기반으로 동작하며, 비동기 스트림을 다루기 위해 Mono<T>, Flux<T> 같은 리액티브 타입을 제공한다.
또한, WebFlux는 기본적으로 Tomcat 대신 Netty를 사용하는데, Netty는 스레드 풀 대신 이벤트 루프(Event Loop) 기반의 비동기 네트워크 서버 프레임워크다. 이를 통해 높은 동시성을 처리할 수 있으며, 블로킹 없이 효율적인 비동기 요청 처리가 가능하다.
🎯 WebFlux vs MVC
✅ 1. 동기 vs 비동기
- Spring MVC : 요청을 받으면 해당 요청을 처리할 스레드를 생성하고, 스레드가 끝날 때까지 블로킹됨
- Spring WebFlux : 요청이 들어오면 이벤트 루프(Event Loop)를 통해 비동기적으로 처리하여, 적은 수의 스레드로도 많은 요청을 효율적으로 처리 가능
✅ 2. 스레드 모델
- Spring MVC : 스레드 풀(Thread Pool) 기반 → 요청이 많아지면 스레드가 많아지고, 결국 성능 저하 발생
- Spring WebFlux : 이벤트 루프(Event Loop) 기반 → 스레드가 적어도 많은 요청을 효율적으로 처리 가능
✅ 3. 서버 종류
- Spring MVC : 서블릿 컨테이너 기반 (Tomcat, Jetty)
- Spring WebFlux : 논블로킹 서버(Netty) 지원
✅ 4. 데이터 처리 방식
- Spring MVC :
List<T>,T와 같은 전통적인 데이터 타입을 사용하여 한 번에 데이터를 처리 - Spring WebFlux :
Mono<T>,Flux<T>를 사용하여 스트림 형태로 데이터를 처리 (데이터가 준비될 때마다 전송)
📌 정리
- MVC는 전통적인 웹 애플리케이션(REST API, CRUD 중심)에 적합하다.
- WebFlux는 높은 동시성이 필요한 애플리케이션(스트리밍, 실시간 데이터 처리)에 적합하다.
⚠️ 하지만 단순한 CRUD 기반의 웹 애플리케이션이라면 MVC가 더 적합할 수 있다!
→ WebFlux는 리액티브 프로그래밍을 요구하기 때문에 코드가 복잡해질 가능성이 있음
Spring WebFlux는 비동기 논블로킹 방식과 반응형 프로그래밍 모델을 통해 높은 동시성을 요구하는 애플리케이션에 최적화된 솔루션을 제공한다. 특히, MSA 환경에서 마이크로서비스 간의 비동기 통신이 중요해지면서 WebFlux의 활용도가 더욱 높아지고 있다.
하지만 모든 애플리케이션에 WebFlux가 적합한 것은 아니다. 단순한 CRUD 중심의 웹 애플리케이션에서는 MVC 방식이 더 직관적이고 유지보수가 용이할 수 있다. 따라서 프로젝트의 요구사항과 성격을 고려하여 MVC와 WebFlux 중 적절한 방식을 선택하는 것이 중요하다.
앞으로 비동기 및 반응형 프로그래밍이 점점 더 보편화될 것으로 예상되는 만큼, WebFlux에 대한 깊은 이해와 실무 적용 경험을 쌓는 것이 개발자로서 중요한 역량이 될 것이다.
🔍 사진출처 및 참고자료
🔗 https://howtodoinjava.com/spring-webflux/spring-webflux-tutorial/
🔗https://www.digitalocean.com/community/tutorials/spring-webflux-reactive-programming
