You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 3 Next »


Spring WebFlux의 org.springframework.web.reactive.socket 기반의 웹소켓과 전통적인 Spring MVC 기반 웹소켓을 비교해보겠습니다.

1. 아키텍처적 차이

비교 항목Spring WebFlux (org.springframework.web.reactive.socket)Spring MVC (전통적인 웹소켓)
스레드 모델Non-blocking, 이벤트 기반 (Netty, Undertow 등 지원)Blocking, Thread-per-connection (Tomcat, Jetty, Undertow)
리액티브 스트림 지원Flux<Message>, Mono<Message> 기반@MessageMapping 기반
동시성 처리요청 처리에 많은 스레드를 사용하지 않음 (적은 리소스로 높은 성능)많은 동시 접속 시 스레드가 증가, 성능 저하 가능
서버 요구 사항Netty, Undertow, Jetty 등 리액티브 지원 서버 필요Tomcat, Jetty, Undertow 지원
부하 분산가볍고 빠르며 부하를 효과적으로 처리 가능높은 동접자 수 처리 시 성능 저하 가능

2. 성능 및 확장성

비교 항목Spring WebFlux (org.springframework.web.reactive.socket)Spring MVC (전통적인 웹소켓)
성능대량의 동시 요청 처리에 유리동시 연결이 많아지면 성능 저하
부하 분산비동기 이벤트 기반 처리로 효율적스레드 증가로 인한 오버헤드 발생
리소스 관리적은 스레드로 많은 요청 처리 가능많은 동시 요청 시 스레드 리소스 소모 증가
지연 처리이벤트 기반으로 낮은 지연 시간스레드가 많아지면 응답 지연 증가
  • WebFlux 기반 웹소켓은 비동기 이벤트 기반 모델이기 때문에 최소한의 리소스로 높은 동시성을 처리할 수 있습니다.
  • 반면 Spring MVC 웹소켓은 Blocking 모델로서 요청당 하나의 스레드를 할당해야 하므로 동접자가 많아질수록 성능 저하가 발생할 수 있습니다.

3. 프로그래밍 모델 차이

✅ Spring WebFlux 웹소켓 (비동기, 리액티브)

@Component
class ReactiveWebSocketHandler : WebSocketHandler {
    override fun handle(session: WebSocketSession): Mono<Void> {
        val input = session.receive()
            .map { it.payloadAsText }
            .doOnNext { println("Received: $it") }

        val output = Flux.interval(Duration.ofSeconds(1))
            .map { "Server response $it" }
            .map(session::textMessage)

        return session.send(output)
    }
}



✅ Spring MVC 웹소켓 (동기, Blocking)

@Controller
class TraditionalWebSocketHandler {

    @MessageMapping("/message")
    @SendTo("/topic/response")
    fun handleMessage(message: String): String {
        println("Received: $message")
        return "Server response: $message"
    }
}

4. 사용 시 고려 사항

✅ WebFlux 웹소켓이 유리한 경우

  • 대규모 동시 연결 처리 (ex. 실시간 채팅, 금융 데이터 스트리밍)
  • 리소스가 제한적인 환경 (ex. 마이크로서비스)
  • Reactive Stack을 기반으로 애플리케이션을 구축할 경우
  • Netty 기반 서버를 사용할 때 최적화된 성능 제공

✅ Spring MVC 웹소켓이 유리한 경우

  • 기존 MVC 프로젝트와의 통합이 필요할 경우
  • 비교적 적은 연결 수를 처리하는 서비스 (ex. 내부 알림 시스템)
  • 기존의 @Controller 기반 프로그래밍이 익숙한 경우
  • 톰캣(Tomcat)을 사용해야 하는 경우 (WebFlux는 기본적으로 Netty를 사용)

5. 정리

비교 항목Spring WebFlux (org.springframework.web.reactive.socket)Spring MVC (전통적인 웹소켓)
비동기 지원✅ 완전한 비동기 리액티브 모델🚫 동기적 처리
성능✅ 높은 동시성 처리 가능🚫 동접자가 많으면 성능 저하
사용하기 쉬운가?🚫 다소 복잡한 코드 구조✅ 전통적인 MVC 패턴과 유사
서버 호환성🚫 Netty, Undertow 등 필요✅ Tomcat, Jetty 지원
적용 사례✅ 실시간 데이터 스트리밍, 채팅, 알림✅ 단순한 웹소켓 기능

🔥 결론

  • 대규모 동시 연결 및 성능이 중요한 서비스에서는 Spring WebFlux의 비동기 리액티브 웹소켓이 적합합니다.
  • 기존 Spring MVC 기반 프로젝트와의 호환성이 중요하고, 동접자가 많지 않다면 전통적인 Spring MVC 웹소켓이 더 쉬운 선택이 될 수 있습니다.

🚀 즉, 성능과 확장성이 중요한 경우 WebFlux, 익숙한 개발 방식과 기존 시스템 통합이 중요한 경우 MVC 웹소켓을 선택하는 것이 좋습니다.





  • No labels