조용한 개발 노트

Spring Web을 다루다 보면, 반드시 한 번은 마주치는 질문이 있다.“Spring Web MVC로 충분한데, WebFlux는 왜 존재할까?”Spring WebFlux는 Spring Web MVC의 대체재가 아니라, 서로 다른 실행 모델을 제공하는 또 하나의 선택지다.이 글에서는 Spring WebFlux가 등장한 배경과 실행 모델의 차이를 살펴보고, 실무에서 언제 WebFlux를 선택해야 하는지 기준을 정리한다.1. Spring Web MVC의 실행 모델 다시 보기Spring Web MVC는 서블릿 기반의 블로킹 I/O 모델을 사용한다.요청 처리 방식은 비교적 단순하다.요청 1건당 스레드 1개가 할당된다해당 스레드는 요청 처리 전체를 담당한다I/O 작업 동안 스레드는 대기 상태가 된다이 모델은 구현..

37편에서는 WebFlux를 언제 선택해야 하는지를 실행 모델과 트래픽 특성 관점에서 정리했습니다.하지만 실무에서는 이런 질문이 더 자주 나옵니다.“기존 Spring MVC를 전부 WebFlux로 바꿔야 할까?”결론부터 말하면,대부분의 경우, 그렇지 않다입니다.이번 글에서는 Servlet 기반과 Reactive 기반을 현실적으로 함께 사용하는 전략을 정리해보겠습니다.1. 왜 혼합 아키텍처가 필요한가대부분의 서비스는 다음과 같은 특성을 동시에 가집니다.일반적인 CRUD 요청 (동기 MVC에 적합)외부 API 호출이 많은 요청 (Reactive에 적합)실시간성/스트리밍 요청 (Reactive에 적합)이 모든 요청을전부 Servlet으로 처리하거나전부 Reactive로 처리하는 것은 현실적으로 비효율적인 선택..

36편에서는 Spring MVC 환경에서 비동기 처리(Callable, DeferredResult)를 통해 Servlet Thread 병목을 우회하는 방법을 살펴봤습니다.이번 글에서는 그 다음 질문에 답해보겠습니다.“그럼 언제부터는 비동기가 아니라 WebFlux를 써야 할까?”이 질문에 대한 답은 기술 선호가 아니라 실행 모델과 트래픽 특성에 있습니다.1. WebFlux는 무엇이 다른가Spring WebFlux는Servlet Thread 모델이 아닌, Reactive(Event Loop) 모델위에서 동작합니다.즉,요청 하나당 스레드 하나 ❌적은 수의 이벤트 루프 스레드로 다수 요청 처리 ⭕가 핵심 차이입니다.이 차이로 인해 WebFlux는Thread 점유를 최소화하고I/O 대기 동안 다른 작업을 수행할 ..