언어, 프레임워크/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는 수신 대상을 쉽게 명시할 수 있다.