STOMP

STOMP 프로토콜의 통신은 프레임 단위로 이루어진다. 각 프레임은 명령어, 헤더, 본문으로 구성되며, 프레임의 끝은 널 문자(0x00)로 표시된다. 이 텍스트 기반의 구조는 디버깅과 구현을 단순하게 만드는 핵심 요소이다.

주요 명령어는 다음과 같다.

헤더는 키:값 쌍으로 이루어지며, 명령어에 필요한 부가 정보를 담는다. 예를 들어, SEND 프레임에는 메시지가 전송될 목적지를 나타내는 destination 헤더가 필수적으로 포함된다. SUBSCRIBE 프레임에는 구독을 식별하는 id 헤더가 필요하다. 본문은 선택 사항이며, 일반적으로 JSON이나 XML과 같은 구조화된 텍스트 데이터를 담는다. 본문의 끝은 널 문자로 구분되며, 본문의 형식과 길이는 content-type과 content-length 헤더로 명시할 수 있다.

STOMP 클라이언트는 브로커에 연결하기 위해 CONNECT 또는 STOMP 프레임을 전송합니다. 이 프레임에는 인증을 위한 login과 passcode 헤더, 요청된 프로토콜 버전을 명시하는 accept-version 헤더 등을 포함할 수 있습니다. 브로커는 연결 요청을 처리한 후, 성공 시 CONNECTED 프레임으로, 실패 시 ERROR 프레임으로 응답합니다. 연결이 수립되면 TCP 소켓 또는 웹소켓과 같은 전송 계층 연결 위에 논리적인 STOMP 세션이 생성됩니다.

세션은 연결된 상태에서 클라이언트와 브로커 간의 메시지 교환을 관리하는 기본 단위입니다. 하나의 물리적 연결 내에서 여러 개의 논리적 구독(Subscription)이 생성되고 관리될 수 있습니다. 각 구독은 고유한 id 헤더로 식별되며, 클라이언트는 SUBSCRIBE 프레임으로 특정 목적지(예: 토픽 또는 큐)를 구독하고, UNSUBSCRIBE 프레임으로 구독을 해제합니다.

연결을 종료하려면 클라이언트가 DISCONNECT 프레임을 전송합니다. 브로커는 이 프레임을 받으면 해당 클라이언트와 관련된 모든 리소스(세션, 미확인 메시지, 구독 등)를 정리한 후 전송 계층 연결을 닫습니다. 비정상적 종료 시에도 브로커는 세션 리소스를 정리하는 것이 일반적입니다. 세션 관리의 핵심은 연결, 구독 라이프사이클, 그리고 정리 과정을 통해 메시지의 신뢰성과 순서를 보장하는 데 있습니다.

STOMP는 단순 텍스트 기반 프로토콜로 설계되었다. 이는 프로토콜의 프레임 구조와 명령어가 모두 사람이 읽을 수 있는 일반 텍스트 형식을 사용한다는 것을 의미한다. 예를 들어, 메시지를 보내는 CONNECT 명령이나 메시지를 구독하는 SUBSCRIBE 명령은 모두 영어 단어로 구성되어 있으며, 헤더와 본문도 UTF-8로 인코딩된 문자열로 표현된다. 이러한 텍스트 기반 특성은 프로토콜의 동작을 직관적으로 이해하고 디버깅하는 것을 용이하게 만든다.

이 단순성은 개발과 통합 과정에서 큰 장점으로 작용한다. 네트워크 패킷을 캡처하거나 로그를 확인할 때, 전송되는 데이터의 내용을 별도의 복잡한 디코딩 과정 없이 바로 확인할 수 있다. 또한, 새로운 클라이언트나 도구를 구현할 때, 바이너리 프로토콜에 비해 파싱과 처리가 상대적으로 간단하다. 이는 AMQP나 MQTT와 같은 바이너리 중심의 프로토콜과 대비되는 STOMP의 핵심 특징 중 하나이다.

텍스트 기반 구조는 유연성과 확장성을 제공한다. 헤더는 키-값 쌍으로 자유롭게 추가할 수 있어, 메시지에 메타데이터를 첨부하거나 브로커별 특정 기능을 활용하는 데 유용하다. 본문은 텍스트(JSON, XML) 뿐만 아니라 바이너리 데이터도 문자열로 인코딩하여 전송할 수 있다. 이러한 단순함과 유연함의 결합 덕분에 STOMP는 다양한 메시징 브로커와 애플리케이션 사이의 경량 통합 계층으로 널리 채택되었다.

STOMP는 발행-구독 패턴과 메시지 큐라는 두 가지 주요 메시징 패턴을 명시적으로 지원합니다. 이는 프로토콜의 핵심 명령어를 통해 구현되며, 애플리케이션이 다양한 메시지 전달 방식을 선택할 수 있도록 합니다.

발행-구독(PUB/SUB) 패턴에서는 메시지 생산자(퍼블리셔)가 특정 주제(토픽)에 메시지를 발행(SEND)하고, 해당 주제를 구독(SUBSCRIBE)한 모든 소비자(서브스크라이버)가 메시지를 수신합니다. 이 패턴은 일대다(one-to-many) 통신에 적합하며, 실시간 알림이나 주식 시세 배포와 같은 시나리오에서 널리 사용됩니다. STOMP 클라이언트는 SUBSCRIBE 프레임에 destination 헤더를 지정하여 관심 있는 주제를 등록합니다. 이후 브로커는 해당 목적지로 전송된 모든 SEND 프레임을 MESSAGE 프레임으로 변환해 구독자에게 전달합니다.

메시지 큐 패턴에서는 메시지가 명명된 큐에 전송됩니다. 큐에 도착한 메시지는 일반적으로 하나의 소비자에게만 전달되며, 소비자가 메시지를 성공적으로 처리하고 확인 응답(ACK)을 보내면 큐에서 제거됩니다. 이는 작업 분산이나 로드 밸런싱과 같은 일대일(one-to-one) 통신 시나리오에 적합합니다. STOMP에서 큐 기반 통신도 destination 헤더를 통해 이루어지며, 브로커는 이를 통해 특정 큐를 식별합니다. 클라이언트는 SUBSCRIBE 시 ack 헤더를 설정하여 메시지 수신 확인 방식을 제어할 수 있습니다.

두 패턴 모두 destination 헤더 값의 네이밍 규칙(예: /topic/주제이름 또는 /queue/큐이름)에 의해 구분되거나, 브로커의 내부 정책에 의해 결정됩니다. 이 유연성 덕분에 개발자는 단일하고 단순한 프로토콜을 사용하여 복잡한 메시징 토폴로지를 구성할 수 있습니다.

STOMP 프레임은 헤더와 본문으로 구성되며, 이 두 부분 모두 유연한 구조를 가진다. 헤더는 키-값 쌍의 집합으로, 메시지의 메타데이터를 전달하는 역할을 한다. 표준 헤더 외에도 사용자가 임의의 커스텀 헤더를 정의하고 추가할 수 있어, 애플리케이션별 특수한 정보나 라우팅 지시를 포함시키는 것이 가능하다. 예를 들어, 거래 ID나 사용자 정의 우선순위 등을 헤더에 담아 보낼 수 있다.

본문은 선택적이며, 텍스트 또는 바이너리 데이터를 담을 수 있다. 본문의 내용 형식은 content-type 헤더를 통해 명시된다. 일반적으로 JSON이나 XML 같은 텍스트 형식이 널리 사용되지만, 필요에 따라 이미지나 프로토콜 버퍼 같은 바이너리 데이터도 전송할 수 있다. 본문의 길이는 content-length 헤더로 표시된다.

이러한 유연성은 다양한 메시징 요구사항을 충족시킨다. 간단한 텍스트 명령부터 구조화된 데이터나 파일 스트림까지, 단일하고 간결한 프레임 구조 안에서 처리할 수 있다. 다음은 STOMP SEND 프레임의 구조 예시이다.

유연한 헤더와 본문 설계는 STOMP를 교차 플랫폼 통신과 이기종 시스템 간 통합에 적합하게 만드는 핵심 요소 중 하나이다. 프로토콜 자체는 전송 형식에 구애받지 않으면서, 애플리케이션 계층에서 필요한 모든 정보를 효율적으로 포장할 수 있는 수단을 제공한다.

다양한 프로그래밍 언어와 플랫폼을 위해 여러 STOMP 클라이언트 구현체가 존재한다. 이 구현체들은 프로토콜 사양을 준수하며, 애플리케이션에서 STOMP 브로커와의 통신을 쉽게 구현할 수 있도록 API를 제공한다.

웹 브라우저 환경에서는 JavaScript 라이브러리인 stomp.js가 널리 사용된다. 이 라이브러리는 WebSocket 또는 SockJS를 전송 계층으로 사용하여 서버와의 실시간 양방향 통신을 가능하게 한다. stomp.js는 PUB/SUB 및 큐 기반 메시징을 지원하며, 연결 관리, 구독, 메시지 송수신을 위한 간결한 메서드를 제공한다.

서버 측 Java 애플리케이션에서는 Spring Framework의 Spring STOMP 모듈이 강력한 지원을 한다. Spring Boot와 통합되어 손쉽게 STOMP over WebSocket 엔드포인트를 구성할 수 있다. 이 모듈은 메시지 라우팅을 위한 @MessageMapping 어노테이션, 클라이언트 세션 관리, 메시지 전송 인터셉터 등 고급 기능을 포함한다. 다른 언어의 구현체로는 Python의 stomp.py, Go의 go-stomp, .NET용 Stomp.Net 등이 있다.

이러한 클라이언트 라이브러리들은 개발자가 저수준의 프로토콜 처리보다 비즈니스 로직에 집중할 수 있도록 하여, STOMP 프로토콜의 채택과 실시간 애플리케이션 개발을 촉진한다.

STOMP는 단순한 텍스트 기반 프로토콜이기 때문에, 이를 지원하는 다양한 메시지 브로커와의 호환성이 주요 장점 중 하나이다. 대표적인 오픈소스 메시지 브로커인 Apache ActiveMQ와 RabbitMQ는 STOMP 프로토콜을 기본적으로 또는 플러그인을 통해 광범위하게 지원한다. 또한 Apache Artemis, NATS, HornetQ와 같은 다른 브로커들도 STOMP를 구현하고 있다[1].

각 브로커는 STOMP를 구현하는 방식과 제공하는 추가 기능에서 차이를 보인다. ActiveMQ는 자바 기반의 메시지 브로커로, STOMP를 네이티브 프로토콜 중 하나로 지원하며, JMS와의 통합이 용이하다는 특징이 있다. 반면, Erlang으로 작성된 RabbitMQ는 공식 STOMP 플러그인을 활성화함으로써 STOMP 지원을 추가한다. RabbitMQ는 AMQP가 기본 프로토콜이지만, STOMP 플러그인을 통해 더 넓은 범위의 클라이언트 접근성을 제공한다.

브로커 선택 시 고려해야 할 주요 사항은 다음과 같다.

이러한 호환성 덕분에 개발자는 애플리케이션의 요구사항(예: 처리량, 지속성, 클러스터링)에 맞는 브로커를 선택한 후, 표준화된 STOMP 클라이언트 라이브러리를 사용하여 통신할 수 있다. 이는 벤더 종속성을 줄이고 시스템 통합의 유연성을 높이는 데 기여한다.

STOMP over WebSocket은 웹소켓 연결 위에 STOMP 프로토콜을 얹어 동작하는 방식이다. 웹소켓은 TCP 연결을 통해 풀듀플렉스 통신 채널을 제공하지만, 그 자체로는 메시지의 형식이나 의미를 정의하지 않는 단순한 바이너리 프레임 전송 계층이다. STOMP는 이 위에서 동작하는 어플리케이션 레벨 프로토콜로, 클라이언트와 브로커가 교환할 메시지의 구조와 의미를 규정한다. 따라서 웹 브라우저와 같은 웹소켓 클라이언트는 STOMP 프로토콜을 구현함으로써 메시지 브로커와 직접 대화할 수 있게 된다.

동작 방식은 먼저 표준 웹소켓 핸드셰이크를 통해 연결을 수립한 후, STOMP 프레임을 웹소켓 메시지의 페이로드로 전송하는 것이다. 클라이언트는 CONNECT 또는 STOMP 프레임을 보내 연결을 시작하고, 브로커는 CONNECTED 프레임으로 응답한다. 이후 모든 STOMP 명령어(SEND, SUBSCRIBE, MESSAGE 등)는 텍스트 또는 바이너리 웹소켓 메시지 안에 담겨 전송된다. 이 구조는 HTTP를 통한 폴링 방식에 비해 오버헤드가 적고 지연 시간이 짧은 실시간 양방향 통신을 가능하게 한다.

이 방식의 주요 장점은 웹 애플리케이션 개발의 편의성에 있다. 개발자는 낮은 수준의 웹소켓 API를 직접 다루지 않고, 토픽이나 큐 기반의 익숙한 메시징 모델을 사용할 수 있다. 또한 STOMP의 텍스트 기반 프레임 구조는 디버깅과 메시지 검사를 쉽게 만든다. 대부분의 현대 메시지 브로커(예: RabbitMQ, ActiveMQ)와 웹 프레임워크(예: Spring Framework의 STOMP 모듈)는 STOMP over WebSocket을 네이티브로 지원한다.

이러한 계층적 구조 덕분에 STOMP over WebSocket은 실시간 웹 애플리케이션, 특히 대화형 알림 시스템, 라이브 차트, 협업 편집기 및 웹 기반 채팅 애플리케이션을 구축하는 데 널리 채택된다.

웹소켓은 양방향 통신 채널을 제공하지만, 전송할 메시지의 형식에 대해서는 규정하지 않는다. STOMP는 이 위에 메시징 시맨틱(의미 체계)을 정의하는 프로토콜 계층으로 작동하여, 클라이언트와 서버가 구조화된 방식으로 메시지를 교환할 수 있게 한다.

이 조합은 실시간 웹 애플리케이션의 핵심 요구사항을 충족시킨다. 클라이언트는 CONNECT 프레임으로 브로커에 연결한 후, 특정 주제(destination)를 SUBSCRIBE하여 구독할 수 있다. 서버나 다른 클라이언트가 해당 주제에 메시지를 PUBLISH하면, 브로커는 실시간으로 모든 구독자에게 MESSAGE 프레임을 전달한다. 이 Pub/Sub(발행-구독) 패턴은 특정 사용자나 그룹에게만 메시지를 전달하는 선택적 브로드캐스트를 가능하게 한다.

주요 활용 예시는 다음과 같다.

이러한 활용은 Spring Framework의 STOMP 지원이나 stomp.js 라이브러리와 같은 도구를 통해 쉽게 구현된다. 개발자는 낮은 수준의 웹소켓 API를 직접 다루지 않고, 토픽 기반의 메시징 모델에 집중하여 확장성 있고 유지보수 가능한 실시간 기능을 구축할 수 있다.

STOMP는 AMQP나 MQTT와 같은 다른 메시징 프로토콜과 비교했을 때, 설계 목적과 복잡성, 사용 영역에서 차이를 보입니다. 아래 표는 주요 특성을 비교한 것입니다.

STOMP의 가장 큰 장점은 텍스트 기반의 단순함과 낮은 진입 장벽이다. HTTP와 유사한 텍스트 명령어를 사용하기 때문에 디버깅이 쉽고, 다양한 프로그래밍 언어로 클라이언트를 빠르게 구현할 수 있다. 이는 AMQP의 복잡한 이진 프레임 구조와 대비되는 점이다. 반면, AMQP는 트랜잭션, 발행 확인, 정교한 라우팅과 같은 고급 메시징 보증과 기능을 제공하여 금융 거래와 같은 엔터프라이즈 시나리오에서 더 강력한 신뢰성을 보장한다.

MQTT는 STOMP와 마찬가지로 비교적 단순하지만, 설계 철학이 근본적으로 다르다. MQTT는 네트워크 대역폭이 제한되고 연결이 불안정할 수 있는 IoT 장치에 최적화되어 있다. 따라서 프로토콜 오버헤드를 극도로 줄이고, 작은 코드 풋프린트로 구현할 수 있도록 했다. STOMP는 MQTT보다 더 유연한 헤더를 지원하지만, 기본적인 PUB/SUB 모델에서는 MQTT의 경량성과 효율성을 따라가지 못한다. 결국, STOMP는 웹 및 일반 애플리케이션에서의 쉬운 활용, AMQP는 고신뢰성 비즈니스 메시징, MQTT는 제한된 환경의 기기 간 통신에 각각 적합한 프로토콜이다.

실시간 알림 시스템은 STOMP가 가장 널리 활용되는 분야 중 하나이다. 발행-구독 패턴을 기본으로 지원하는 STOMP의 특성은 다수의 사용자에게 동시에 알림을 배포하는 데 매우 적합하다. 서버는 특정 토픽에 알림 메시지를 발행하기만 하면, 해당 토픽을 구독하고 있는 모든 클라이언트에게 메시지가 실시간으로 전달된다. 이 방식은 폴링 방식에 비해 네트워크 부하를 줄이고 지연 시간을 최소화하는 장점을 가진다.

주요 활용 예로는 소셜 미디어의 좋아요나 댓글 알림, 이커머스 플랫폼의 주문 상태 변경 알림, 모니터링 시스템의 장애 발생 알림 등이 있다. 클라이언트는 초기 연결 시 자신이 관심 있는 알림 채널(예: /user/{id}/notifications 또는 /topic/order-updates)을 구독하고, 서버는 관련 이벤트 발생 시 해당 채널로 메시지를 전송한다. 메시지 본문에는 알림 내용을 JSON이나 일반 텍스트 형식으로 담아 전송할 수 있다.

STOMP를 이용한 알림 시스템의 구현은 비교적 단순하다. 웹소켓 위에서 STOMP를 사용하면(STOMP over WebSocket) 웹 브라우저 클라이언트도 쉽게 실시간 알림을 수신할 수 있다. 또한 RabbitMQ나 ActiveMQ와 같은 메시지 브로커를 중간에 두면, 알림 서버의 확장성과 신뢰성을 높일 수 있다. 브로커는 연결된 클라이언트들을 관리하고 메시지의 지속성 또는 미전달 메시지 처리와 같은 고급 기능을 제공한다.

STOMP는 주식 거래 시스템에서 실시간 시세 전달, 주문 실행 상태 알림, 포트폴리오 업데이트와 같은 기능을 구현하는 데 널리 사용된다. 이 프로토콜의 경량성과 텍스트 기반 구조는 빠른 개발과 다양한 클라이언트 언어 지원을 가능하게 하며, PUB/SUB 메시징 패턴은 다수의 트레이더에게 동일한 시장 데이터를 효율적으로 브로드캐스트하는 데 이상적이다.

시스템은 일반적으로 특정 주식 티커나 시장 데이터 채널을 구독하는 다수의 클라이언트를 포함한다. 예를 들어, /topic/market-data.AAPL 채널에 가격 변동 메시지를 발행하면, 해당 채널을 구독한 모든 클라이언트는 실시간으로 업데이트를 수신한다. 주문 실행과 같은 중요한 이벤트는 개별 사용자 전용 대기열(예: /queue/orders.user123)을 통해 전달되어 메시지의 신뢰성과 순서를 보장한다.

STOMP over WebSocket을 사용하면 웹 브라우저 기반의 트레이딩 플랫폼에서도 지연 시간이 짧은 양방향 통신을 구현할 수 있다. 이는 AMQP나 MQTT와 같은 다른 프로토콜에 비해 프로토콜의 단순함으로 인한 오버헤드가 적고, 헤더를 이용한 메타데이터(예: 메시지 유형, 타임스탬프, 주문 ID)의 유연한 첨부가 가능하기 때문이다. 따라서 고빈도 거래에는 적합하지 않을 수 있으나, 대부분의 온라인 증권사 플랫폼과 실시간 모니터링 대시보드의 요구사항을 충족시킨다.

STOMP는 PUB/SUB 메시징 패턴과 메시지 브로커를 통해 다수의 사용자 간 실시간 데이터 동기화를 효율적으로 처리할 수 있어, 협업 도구 개발에 널리 활용된다. 예를 들어, 공유 문서 편집기에서 한 사용자가 텍스트를 입력하거나 수정하면, 해당 변경 사항이 STOMP 메시지로 브로커를 통해 구독 중인 다른 모든 사용자에게 즉시 전달된다. 이를 통해 모든 참여자의 화면이 거의 동시에 갱신되어, 마치 단일 문서를 함께 편집하는 것과 같은 경험을 제공한다.

채팅 애플리케이션 또한 STOMP의 주요 사용 사례이다. 사용자는 특정 채팅방(토픽)을 구독(SUBSCRIBE)하고, 메시지를 발행(PUBLISH)함으로써 그룹 대화에 참여한다. STOMP의 간단한 텍스트 기반 프레임 구조는 채팅 메시지의 헤더(예: 보낸 사람, 시간, 대상 방)와 본문(메시지 내용)을 정의하기에 적합하다. 또한, 일대일 귓속말 기능은 특정 사용자를 목적지로 하는 개인 큐를 통해 구현될 수 있다.

이러한 애플리케이션들은 주로 웹소켓 위에서 STOMP를 사용(STOMP over WebSocket)하여, HTTP의 오버헤드 없이 지속적이고 양방향인 통신 채널을 확보한다. Spring Framework의 STOMP 지원이나 stomp.js 라이브러리와 같은 클라이언트 구현체를 이용하면, 개발자는 낮은 수준의 통신 프로토콜보다는 비즈니스 로직과 메시지 흐름에 더 집중할 수 있다. 결과적으로 STOMP는 실시간 협업 환경을 구축하는 데 있어 표준화되고 효율적인 메시징 백본 역할을 한다.