언어, 프레임워크/Spring

WebSocket(SockJS, STOMP)

go_getter 2025. 5. 20. 20:58

스프링 환경에서 웹소켓을 사용할 때 Spring WebSocket, SockJS, STOMP 등 기술을 사용할 수 있다.

이 세 가지 기술은 계층별로 목적이 다르고 상황에 따라 조합하여 사용할 수 있다.

 

1. Spring WebSocket

WebSocket만으로 충분할 때 쓰는 최소 구성

항목 설명
목적 WebSocket 프로토콜 자체를 지원하는 Spring의 기본 모듈
전송 방식 순수 WebSocket (기본 연결)
장점 단순하고 빠르며, STOMP 없이도 사용 가능
단점 클라이언트 구현이 복잡할 수 있음 (JS에서 직접 send/receive 다룸)
사용 예 클라이언트와 서버 간에 JSON 메시지를 직접 처리할 때

 

2. SockJS

WebSocket이 실패할 경우를 대비한 백업 수단

항목 설명
목적 WebSocket이 불가능한 환경(브라우저, 방화벽 등)을 보완하는 폴백(fallback) 라이브러리
전송 방식 WebSocket → XHR-streaming → Long polling 등으로 자동 대체
장점 브라우저 호환성 강화, 네트워크 환경 불량 시도
단점 서버와 클라이언트 모두 SockJS 프로토콜에 맞게 구성 필요
사용 예 IE, 구형 브라우저, 보안 장비가 WebSocket을 막을 수 있는 공공/금융 시스템 등

 

3. STOMP (Simple Text Oriented Messaging Protocol)

WebSocket에 채널 구조메시징 기능을 더한 고급 메시징 프로토콜

항목 설명
목적 WebSocket 위에서 동작하는 고수준 메시징 프로토콜 (메시지 주제 기반 publish/subscribe)
특징 /topic, /queue, 구독/발행 모델, 헤더, Ack 지원
장점 구조적 메시징 가능 (채널, 인증, 사용자별 큐 등), 대규모 시스템에 적합
단점 복잡도 증가 (프레임 구조, 클라이언트 지원 필요)
사용 예 실시간 채팅, 알림, 대기열 번호 전파 등 publish/subscribe 패턴 기반 기능

 

ex. 대기열 기능은 서버에서 클라이언트로 응답메세지를 보낸 이후에도 대기번호를 실시간으로 전송해줘야 하기 때문에(지속적인 연결 필요) pub/sub 기능을 갖춘 STOMP 방식이 적합

 

STOMP를 사용하는 이유

이유 설명
1. 메시지 구조화 및 구분 WebSocket은 기본적으로 단순한 텍스트/바이너리 전송만 제공함 → STOMP는 메시지를 헤더 + 바디 구조로 보내며, 이벤트 유형, 목적지, 구독 채널 등을 명확히 구분 가능
2. subscribe/send 등 고수준 명령 지원 단순 문자열 대신 SUBSCRIBE, SEND, ACK, DISCONNECT 등의 표준화된 명령을 사용 가능함
3. 여러 채널 구독 지원 클라이언트가 다양한 목적지(/topic, /queue)에 메시지를 보내고, 여러 채널을 동시에 구독할 수 있음
4. 서버 메시지 라우팅이 쉬워짐 Spring에서 @MessageMapping, @SendTo, @SubscribeMapping 등을 통해 라우팅과 응답이 쉬움
5. ACK/NACK 기능 (신뢰성 향상) 메시지를 받았는지 확인하는 ACK 기능으로 전송 성공 여부 추적 가능
6. Spring과의 통합성 Spring WebSocket 모듈은 STOMP를 내장 지원함. 설정이 명확하고, 메서드 단위 메시지 핸들링이 가능함.

 

즉, Redis Pub/Sub은 브로드캐스트지만, STOMP는 수신 대상을 쉽게 명시할 수 있다.