STOMP와 웹소켓을 활용한 실시간 메시징

개요

---

웹소켓만을 이용해 실시간 채팅 서비스를 구현하려 했을 때, 여러 제약이 있음을 느꼈다. 웹소켓 자체에는 메시지 전송 규칙이 정해져 있지 않아 클라이언트와 서버가 데이터를 직접 정의해야 하는 불편함이 있고, PUB/SUB 개념이 없어 특정 사용자나 그룹을 대상으로 메시지를 전달하는 기능을 직접 구현해야 했다.

 

이러한 문제를 해결하기 위해 STOMP를 도입했지만, 초기 설정 과정에서 발생한 여러 시행착오와 개념 부족으로 인해 예상치 못한 문제들을 경험했다.

이에 STOMP의 개념과 동작 방식을 깊이 있게 학습하여 정리하고자 한다.

 

 

웹소켓만으로 실시간 통신을 구현할 수 없는 이유

---

웹소켓은 기본적으로 클라이언트와 서버 간 양방향 통신을 지원하는 저수준 프로토콜이다.

하지만 단순한 데이터 전송 채널일 뿐, 메시지 라우팅, 그룹 관리(PUB/SUB), 메시지 구조 정의 등의 기능이 부족하다.

 

웹소켓이 가진 한계

 

﹒ 메시지 라우팅, Routing: 특정 사용자를 구분하거나, 특정 그룹(채널)에 메시지를 전달하는 기능이 없다.

﹒ 메시지 포맷 정의 부족: 메시지를 주고받을 때, 전송할 데이터의 포맷을 정의하는 표준이 없다.

﹒ 구독(Publish-Subscribe) 모델 미지원: PUB/SUB 모델을 직접 구현해야 한다.

 

이러한 문제를 해결하기 위해 STOMP, Simple Text Oriented Messaging Protocol이 등장했다.

 

 

STOMP란?

---

STOMP는 웹소켓 위에서 동작하는 메시징 프로토콜로, 메시지 라우팅 및 PUB/SUB 기능을 지원하는 고수준 메시징 프로토콜이다.

즉, 웹소켓은 단순한 데이터 통로이며, STOMP는 그 위에서 메시지를 어떻게 주고받을지 정의하는 프로토콜이다.

 

 

STOMP가 제공하는 주요 기능

 

1. 메시지의 목적지(destination) 지정

 

﹒ 클라이언트가 특정 채널(”/topic/chat”)을 구독하면, 서버가 해당 경로로 전송된 메시지를 브로드캐스트 할 수 있다.

 

 

2. Pub/Sub 모델 지원

 

﹒ STOMP를 사용하면 여러 클라이언트가 같은 채널을 구독하고, 서버가 해당 채널로 메시지를 브로드캐스트할 수 있다.

 

 

3. 메시지 헤더 지원

 

﹒ HTTP 헤더처럼, STOMP 메시지에도 추가 정보를 담을 수 있는 헤더를 포함할 수 있다.

 

 

4. ACK(확인 응답) 지원

 

﹒ 메시지를 보낸 후, 수신 확인(Acknowledgment, ACK)을 받을 수 있다.

 

 

STOMP의 동작 구조 (PUB/SUB 모델)

---

아래 그림처럼, 발행자(Publisher)가 메시지를 브로커(Broker)에 전송하면, 이를 구독자(Subscriber)들이받아볼 수 있다.

즉, 클라이언트는 서버에 직접 요청하는 방식이 아니라, 특정 채널(Topic)을 구독하여 메시지를 받는 방식이다.

 

 

﹒ Publisher(발행자)가 특정 주제(Topic)로 메시지를 전송한다.

﹒ Broker(중앙 메시지 관리자)는 이 메시지를 구독자들에게 전달한다.

﹒ Subscriber(구독자)는 해당 토픽을 구독하고 있다면, 해당 메시지를 자동으로 수신한다.

 

이처럼, STOMP는 웹소켓을 활용하여 메시지를 목적지(토픽)로 분배하는 역할을 수행한다.

 

 

STOMP 메시지 프레임 구조

---

STOMP는 텍스트 기반 프로토콜로, 프레임이라는 단위로 데이터를 송수신한다.

 

[ STOMP 메시지 기본 구조 ]

﹒ COMMAND: 해당 프레임이 수행할 동작 (CONNECT, SEND, SUBSCRIBE 등)

﹒ Header: 추가적인 메타데이터(목적지, 메시지 ID 등)

﹒ Body: 메시지의 실제 내용

﹒ ^@(NULL 문자): STOMP 프레임의 끝을 의미

 

 

STOMP의 핸드셰이크 과정

 

웹소켓과 마찬가지로, STOMP도 클라이언트-서버 간의 연결을 설정하는 과정(핸드셰이크)이 필요하다.

이 과정에서 주요한 STOMP 프레임은 다음과 같다.

 

 

1. 클라이언트 연결 요청, CONNECT

 

﹒ 클라이언트가 STOMP 서버에 연결을 요청할 때 사용된다.

﹒ 웹소켓의 Upgrade: websocket 요청과 유사한 역할을 한다.

 

 

 

2. 서버의 연결 승인, CONNECTED

 

﹒ 서버가 연결을 승인하면 CONNECTED 프레임을 반환한다.

﹒ 웹소켓의 101 Switching Protocols 응답과 유사한 역할을 한다.

 

 

 

3. 특정 주제 구독 요청, SUBSCRIBE

 

﹒ 클라이언트가 특정 채널(Topic)을 구독할 때 사용된다.

﹒ 클라이언트는 “/topic/chat”의 메시지를 받을 수 있다.

 

 

 

4. 메시지 전송, SEND

 

﹒ 클라이언트가 특정 채널로 메시지를 보낼 때 사용된다.

﹒ 서버는 해당 채널을 구독한 모든 클라이언트에게 해당 메시지를 전송한다.

 

 

 

5. 메시지 수신, MESSAGE

 

﹒ 서버가 구독 중인 클라이언트들에게 메시지를 전송할 때 사용된다.

﹒ 구독한 클라이언트는 자동으로 해당 메시지를 수신한다.

 

 

 

6. 구독 해제, UNSUBSCRIBE

 

﹒ 클라이언트가 구독을 취소할 때 사용된다.

﹒ 구독을 중단하고 메시지를 더 이상 받지 않도록 설정한다.

 

 

 

7. 연결 종료, DISCONNECT

 

﹒ 클라이언트가 연결을 종료할 때 사용된다.

﹒ 웹소켓의 socket.close( ) 와 같은 역할을 한다.

 

 

STOMP와 웹소켓의 관계

---

STOMP는 웹소켓을 기반으로 동작하는 상위 프로토콜로, 웹소켓이 통신을 위한 저수준 연결을 제공하면, STOMP는 이를 활용하여 메시징을 관리하는 역할을 수행한다. 즉, 웹소켓 없이 STOMP는 단독으로 동작할 수 없다.

 

아래 그림은 STOMP가 웹소켓 위에서 어떻게 동작하는지 시각적으로 표현한 것이다.

﹒ TCP/IP Network Layer: 네트워크 통신을 담당한다.

﹒ WebSocket Communication: 클라이언트-서버 간 실시간 연결을 관리한다.

﹒ STOMP Messaging Layer: 메시지 라우팅, PUB/SUB, ACKC 등을 관리한다.

﹒ Web Application: UI가 메시지를 송수신하는 최상위 계층이다.

 

STOMP는 웹소켓이 제공하지 않는 메시징 기능을 추가하여, 보다 효율적이고 체계적인 실시간 메시징을 가능하게 한다.

웹소켓을 통해 클라이언트-서버 간 연결이 이루어지고, STOMP가 이를 활용하여 메시지를 목적지에 따라 라우팅하고, PUB/SUB을 지원하며, 메시지 확인(ACK) 등의 기능을 제공한다.

 

따라서 웹소켓만으로 구현이 어려운 실시간 채팅, 알림 시스템, 주식 데이터 스트리밍 같은 서비스에서 STOMP는 필수적인 역할을 한다.