AMQP

AMQP 모델의 핵심은 메시지 브로커를 통해 발행자와 구독자를 분리하는 데 있으며, 이는 Exchange, Queue, Binding이라는 세 가지 기본 구성 요소를 통해 이루어진다.

Exchange는 메시지를 수신하는 첫 번째 지점이다. 발행자는 특정 Exchange로 메시지를 전송하며, Exchange는 미리 정의된 규칙에 따라 메시지를 하나 이상의 Queue로 라우팅한다. Exchange의 유형에 따라 라우팅 동작이 결정되며, 주요 유형으로는 Direct Exchange, Fanout Exchange, Topic Exchange, Headers Exchange 등이 있다. 각 유형은 서로 다른 라우팅 키(Routing Key) 또는 속성 매칭 방식을 사용한다.

Queue는 메시지가 최종적으로 저장되고 소비자가 이를 가져가기 위해 대기하는 버퍼 공간이다. Queue는 이름을 가지며, 지속성, 자동 삭제, 독점적 사용 등과 같은 속성을 가질 수 있다. 소비자는 특정 Queue를 구독하여 메시지를 수신한다. Exchange가 라우팅 규칙을 처리한다면, Queue는 메시지의 보관 및 전달 책임을 진다.

Binding은 Exchange와 Queue를 연결하는 규칙이다. 이는 "어떤 Exchange의 메시지를 어떤 조건으로 특정 Queue에 전달할 것인가"를 정의하는 다리 역할을 한다. Binding을 생성할 때는 일반적으로 라우팅 키나 헤더 값과 같은 매개변수를 지정하며, 이는 Exchange 유형에 따라 메시지 필터링 기준으로 사용된다. 예를 들어, Topic Exchange에 바인딩할 때는 "stock.us.nyse.*"와 같은 패턴을 사용하여 특정 주제의 메시지만 수신하도록 설정할 수 있다.

이 세 요소의 상호작용은 아래 표와 같이 요약할 수 있다.

이 구조 덕분에 발행자는 메시지를 최종 수신자(Queue)에 대해 알 필요 없이 Exchange만을 알면 되며, 이는 시스템 간의 결합도를 낮추고 유연한 메시지 흐름을 가능하게 한다.

Exchange는 발행된 메시지를 수신하여, 정의된 규칙(Binding)과 메시지의 속성(라우팅 키 또는 헤더)에 따라 하나 이상의 Queue로 전달하는 컴포넌트이다. AMQP의 라우팅 방식은 사용되는 Exchange 타입에 따라 결정되며, 주요 타입으로는 Direct Exchange, Fanout Exchange, Topic Exchange, Headers Exchange가 있다.

Direct Exchange는 메시지의 라우팅 키와 Queue의 바인딩 키가 정확히 일치할 때 메시지를 라우팅한다. 이는 주로 점대점 통신이나 작업 분배에 사용된다. Fanout Exchange는 라우팅 키를 무시하고, 해당 Exchange에 바인딩된 모든 Queue에 메시지를 복사하여 전달한다. 이는 브로드캐스트나 이벤트 알림 시스템에 적합하다. Topic Exchange는 라우팅 키와 패턴(와일드카드 '*', '#' 사용)을 기반으로 매칭하여 라우팅하며, 복잡한 Pub/Sub 패턴을 구현할 수 있다. Headers Exchange는 라우팅 키 대신 메시지 헤더 속성을 기준으로 매칭하여 라우팅한다.

이러한 유연한 라우팅 메커니즘은 발행자와 구독자를 완전히 분리(decouple)시키는 데 핵심적이다. 발행자는 메시지를 최종 목적지인 Queue가 아닌 Exchange로만 보내며, 라우팅 로직은 브로커가 담당한다. 이를 통해 시스템 구성 요소 간의 결합도를 낮추고, 라우팅 정책을 동적으로 변경할 수 있는 유연성을 제공한다.

AMQP의 프로토콜 계층 구조는 네트워크 통신을 효율적으로 관리하기 위해 설계된 다층적 모델이다. 이 구조는 OSI 모델이나 TCP/IP 스택과 유사한 계층화 원칙을 따르며, 각 계층이 명확한 책임을 가진다. 가장 높은 수준의 응용 프로그램 계층부터 가장 낮은 수준의 전송 계층까지, 메시지를 생성, 라우팅, 전송하는 과정을 체계적으로 분리한다. 이 계층화는 프로토콜의 유연성과 구현 간의 상호운용성을 보장하는 핵심 요소이다.

주요 계층은 다음과 같이 구성된다.

이 계층 구조는 하위 계층이 네트워크 통신의 복잡성을 처리하는 동안, 상위 계층이 비즈니스 로직에 집중할 수 있도록 한다. 예를 들어, 응용 계층에서 메시지를 특정 라우팅 키로 발행하면, 하위 계층들은 이 메시지를 프레임으로 나누고, 신뢰성 있게 전송하며, 최종적으로 적절한 큐에 도달하도록 보장한다. 이러한 분리는 AMQP 구현체가 다양한 네트워크 프로토콜 위에서 동작할 수 있는 가능성을 열어주었다[3].

AMQP 1.0은 이전의 AMQP 0-9-1과는 근본적으로 다른 프로토콜로 설계되었으며, 상호운용성 강화와 효율성 개선에 중점을 두었다. 가장 큰 변화는 메시징 모델의 표준화이다. 0-9-1 버전은 Exchange, Queue, Binding 등 브로커의 특정 토폴로지 모델을 프로토콜에 포함시켰지만, AMQP 1.0은 이러한 구체적인 중간 매개체(intermediary)의 내부 구조를 정의하지 않는다. 대신 발신자(송신 링크)와 수신자(수신 링크) 간의 메시지 전송을 보장하는 범용적인 프로토콜 계층에 초점을 맞추어, 다양한 메시징 패턴(예: 일대일, 발행/구독)과 브로커 구현을 지원할 수 있는 유연성을 제공한다.

프로토콜의 효율성도 크게 향상되었다. AMQP 1.0은 이진 프로토콜로서 프레임 구조가 최적화되어 오버헤드가 줄어들었다. 또한 상태 저장(stateful) 링크를 사용하여 연결 설정 후 반복되는 메타데이터 전송을 최소화하고, 배치 처리와 흐름 제어 메커니즘을 통해 네트워크 대역폭 사용을 효율적으로 관리한다. 메시지 포맷은 타입 시스템이 풍부한 효율적인 이진 인코딩을 채택하여, 텍스트 뿐만 아니라 다양한 데이터 타입을 원시 형식 그대로 전송할 수 있다.

보안과 신뢰성 측면에서도 중요한 개선이 이루어졌다. 프로토콜 수준에서 SASL(Simple Authentication and Security Layer)과 TLS(Transport Layer Security)를 통한 강력한 보안 체계를 기본적으로 지원한다. 메시지 배달 보장 수준도 명확히 정의되어 있으며, 발신자가 수신자로부터 배달 상태를 확인받을 수 있는 신뢰할 수 있는 메시징을 구현하는 데 유리하다. 이러한 설계는 금융이나 공공 서비스와 같이 높은 신뢰성이 요구되는 엔터프라이즈 환경과 이기종 시스템 간 통합 시나리오에 특히 적합하다.

AMQP 0-9-1과 AMQP 1.0은 이름만으로는 후속 버전처럼 보이지만, 실제로는 서로 호환되지 않는 별개의 프로토콜 표준이다. 1.0은 0-9-1의 단순한 확장이 아닌, 근본적인 재설계를 거쳤다.

가장 큰 차이는 메시지 모델과 프로토콜 범위에 있다. 0-9-1은 Exchange, Queue, Binding이라는 구체적인 브로커 중심 모델을 명시적으로 정의한다. 반면 1.0은 이러한 구현 세부사항을 배제하고, 발신자(Link Source)와 수신자(Link Target) 간의 비동기적, 신뢰할 수 있는 메시지 전송을 보장하는 더 일반화된 프로토콜에 초점을 맞춘다. 이는 1.0이 특정 토폴로지(예: pub/sub)에 국한되지 않고, 다양한 메시징 패턴(점대점, 요청-응답, 스트리밍 등)을 지원할 수 있는 중립적 프레임워크가 되게 한다.

기술적 차이점은 다음과 같이 요약할 수 있다.

이러한 차이로 인해 0-9-1 클라이언트는 1.0 브로커와 직접 통신할 수 없으며, 그 반대도 마찬가지이다. 0-9-1은 RabbitMQ와 같은 메시지 브로커의 구현과 밀접하게 연관되어 널리 채택되었다. 1.0은 Azure Service Bus, Apache ActiveMQ Artemis 등에서 지원하며, 특히 금융권이나 대규모 엔터프라이즈 시스템 간 상호운용성이 중요한 환경에서 더 중립적인 프로토콜로 사용된다.

RabbitMQ는 Pivotal Software가 주도적으로 개발하고 현재는 VMware 산하에서 관리되는 오픈 소스 메시지 브로커 소프트웨어이다. AMQP 0-9-1 프로토콜을 완벽하게 구현한 대표적인 구현체로, 신뢰성 높은 메시지 지향 미들웨어로 널리 사용된다. Erlang/OTP 플랫폼 위에서 개발되어 높은 가용성과 내고장성을 제공하며, 클러스터 구성과 플러그인 아키텍처를 통해 기능을 확장할 수 있다.

RabbitMQ의 핵심은 Exchange, Queue, Binding으로 구성된 유연한 메시지 라우팅 모델이다. 다이렉트, 팬아웃, 토픽, 헤더즈 등 다양한 타입의 익스체인지를 통해 발행된 메시지를 조건에 맞게 큐에 전달한다. 이 모델은 복잡한 라우팅 로직을 브로커에 위임하고, 생산자와 소비자 애플리케이션을 느슨하게 결합시키는 데 유리하다. 또한 관리용 웹 콘솔과 명령줄 도구를 제공하여 브로커 모니터링과 운영을 용이하게 한다.

RabbitMQ는 다양한 메시징 패턴을 지원한다. 간단한 작업 큐부터 복잡한 Pub/Sub 패턴, RPC 요청-응답 패턴까지 구현이 가능하다. 주요 기능으로는 메시지 지속성, 발행 확인, 소비자 승인, 메시지 TTL, 대기열 및 메시지 우선순위, 죽은 편지 큐 등이 포함되어 엔터프라이즈급 요구사항을 충족한다. 또한 STOMP, MQTT와 같은 다른 프로토콜을 플러그인으로 지원하며, HTTP API를 통한 관리도 가능하다.

Apache Qpid는 AMQP 표준의 오픈 소스 구현체 중 하나이다. Apache Software Foundation의 프로젝트로, 여러 프로그래밍 언어를 위한 클라이언트 라이브러리와 메시지 브로커를 제공한다. Qpid의 주요 목표는 이기종 시스템 간의 안정적이고 상호 운용 가능한 메시징을 지원하는 것이다.

Qpid 프로젝트는 크게 두 가지 구성 요소로 나뉜다. 하나는 Qpid Broker이며, 다른 하나는 다양한 언어를 위한 Qpid Client 라이브러리이다. Qpid Broker는 Java로 작성된 'Qpid Broker-J'와 C++로 작성된 'Qpid Broker-C' 두 가지 구현체를 제공한다. 특히 Broker-J는 AMQP 1.0 및 AMQP 0-10 등을 지원하며, 고가용성(HA) 클러스터링, 관리 도구, 플러그인 아키텍처 등의 고급 기능을 갖추고 있다.

Qpid는 다른 AMQP 브로커와 구별되는 몇 가지 특징을 지닌다. 첫째, 공식 AMQP 1.0 표준(OASIS, ISO/IEC 국제 표준)을 가장 먼저 완벽하게 구현한 프로젝트 중 하나라는 점이다[5]. 둘째, 언어 중립성을 강조하여 C++, Java, Python, .NET 등 광범위한 언어 바인딩을 공식적으로 지원한다. 셋째, Apache 프로젝트 생태계의 일부로서, Apache ActiveMQ나 Apache Kafka와 같은 다른 메시징 시스템과의 통합 가능성을 제공한다.

주요 사용 사례로는 대규모 엔터프라이즈 시스템 통합, 금융 서비스, 그리고 클라우드 컴퓨팅 환경에서의 메시징 인프라 구축 등이 있다. Qpid의 모듈화된 설계와 표준 준수는 복잡한 이기종 환경에서 메시징 미들웨어로 선택되는 이유가 된다.

Azure Service Bus는 마이크로소프트가 제공하는 완전 관리형 엔터프라이즈 메시징 브로커 서비스이다. AMQP 1.0을 기본 프로토콜로 채택하여 개방형 표준을 준수하며, 클라우드 환경에서 고가용성과 확장성을 갖춘 메시지 큐 및 토픽 기능을 제공한다. 서비스는 마이크로소프트 애저 플랫폼의 일부로 운영되며, 사용자는 브로커 인프라를 직접 관리할 필요 없이 메시징 기능에 집중할 수 있다.

주요 기능으로는 큐, 토픽/구독, 릴레이 서비스가 포함된다. 큐는 점대점 통신을, 토픽과 구독은 발행/구독 패턴을 지원한다. 또한 세션, 중복 검색, 배달 보장, 트랜잭션과 같은 고급 메시징 기능을 제공하여 복잡한 엔터프라이즈 시나리오를 처리할 수 있다. 내장된 재시도 정책과 데드 레터 큐 기능은 애플리케이션의 견고성을 높인다.

다른 AMQP 브로커와의 차이점은 완전한 PaaS 제품이라는 점이다. 사용자는 서버 프로비저닝, 패치 적용, 클러스터 구성 또는 모니터링 인프라 구축에 대한 부담 없이 메시징 엔드포인트를 생성하고 사용할 수 있다. 통합된 보안 모델(관리 ID, SAS 토큰)과 Azure Monitor 및 Azure Event Grid와의 긴밀한 통합은 운영과 모니터링을 단순화한다.

이 서비스는 주로 하이브리드 클라우드 애플리케이션, 마이크로서비스 간 통신, 그리고 이벤트 기반 아키텍처를 구현하는 데 널리 사용된다. 완전 관리형 서비스의 편의성과 엔터프라이즈급 안정성, AMQP 표준 준수를 통해 개방성과 상호 운용성을 모두 확보한 것이 주요 강점이다.

AMQP는 느슨한 결합과 비동기 통신을 핵심으로 하는 마이크로서비스 아키텍처에서 중요한 통신 수단으로 사용된다. 서비스 간에 직접적인 호출 대신 메시지 브로커를 중간에 두고 메시지를 교환함으로써, 서비스의 독립적인 배포와 확장을 용이하게 한다. 이는 서비스 간 의존성을 낮추고 시스템 전체의 결합도를 감소시키는 데 기여한다.

AMQP 기반 브로커를 활용한 통신 패턴은 다양하다. 가장 일반적인 요청-응답 패턴 외에도, 이벤트 드리븐 아키텍처를 구현하는 데 적합한 발행-구독(Pub/Sub) 패턴을 효과적으로 지원한다. 한 서비스에서 발생한 이벤트를 메시지로 발행하면, 여러 관심 서비스가 이를 구독하여 필요한 작업을 수행할 수 있다. 또한 워크 큐 패턴을 통해 작업 부하를 여러 워커 인스턴스에 분산시켜 처리 성능을 높일 수 있다.

이러한 방식은 시스템의 신뢰성과 복원력을 향상시킨다. 메시지 브로커는 메시지의 지속성, 전달 보증, 승인 메커니즘을 제공하여 네트워크 불안정이나 일시적인 서비스 장애 시에도 메시지 유실을 방지한다. 특정 마이크로서비스가 다운되더라도 메시지는 브로커에 안전하게 큐잉되어 있으며, 서비스가 복구되면 처리될 수 있다.

마이크로서비스 환경에서 AMQP의 적용은 다음과 같은 이점을 제공한다.

따라서 AMQP는 마이크로서비스가 독립적으로 진화하면서도 효율적으로 협업할 수 있는 견고한 메시징 백본을 구축하는 데 널리 채택된다.

AMQP는 낮은 지연 시간, 높은 신뢰성, 정확한 메시지 전달 보장이 필수적인 금융 거래 시스템의 핵심 인프라로 널리 채택되었다. 특히 주문 전달, 거래 실행, 시장 데이터 배포, 결제 및 청산과 같은 실시간 처리가 요구되는 분야에서 표준 프로토콜 역할을 한다. 교환기(Exchange)와 바인딩(Binding)을 통한 유연한 라우팅은 다양한 유형의 거래 메시지를 목적지에 따라 정확하게 분배하는 데 기여한다.

금융 분야의 주요 사용 사례는 다음과 같다.

* 주문 라우팅 및 실행: 투자자의 주문을 증권사 시스템에서 적절한 거래소나 유동성 공급자(Liquidity Provider)로 안정적으로 전달한다.

* 실시간 시장 데이터 배포: 가격 피드(Price Feed), 호가, 체결 내역과 같은 대량의 시장 데이터를 수많은 가입자(트레이딩 데스크, 알고리즘 등)에게 효율적으로 브로드캐스트한다.

* 이벤트 드리븐 아키텍처: 시스템 내에서 발생하는 거래 체결, 포지션 변경, 위험 한도 초과 등 중요한 이벤트를 다른 모듈에 신속하게 통지하여 조치를 유발한다.

이러한 적용은 AMQP가 제공하는 몇 가지 핵심 메커니즘 덕분에 가능하다. 신뢰성은 퍼시스턴트 큐(Persistent Queue)와 발행 확인(Publisher Confirm)을 통해 메시지 유실을 방지한다. 복잡한 라우팅 요구사항은 토픽 교환기(Topic Exchange)나 헤더 교환기(Headers Exchange)를 사용해 세밀하게 구현할 수 있다. 또한, 트랜잭션이나 보장된 전달 모드를 지원하여 "정확히 한 번"(Exactly-Once) 또는 "최소 한 번"(At-Least-Once) 전달 의미론을 구현할 수 있어, 금융 규정 준수와 데이터 정합성 유지에 필수적이다.

따라서 AMQP는 금융 생태계에서 시스템 간의 견고하고 확장 가능한 통신 백본을 구성하며, 시장의 안정성과 효율성을 유지하는 데 기여한다.

AMQP는 IoT 데이터 스트리밍 환경에서 장치와 서버, 서버와 서버 간의 효율적인 메시지 교환을 위한 표준 프로토콜로 널리 사용된다. 수많은 IoT 장치에서 생성된 센서 데이터, 이벤트, 제어 명령은 일반적으로 규칙적이지 않고 간헐적으로 발생하며, 다양한 네트워크 조건을 통해 전송되어야 한다. AMQP의 신뢰성 있는 메시지 전달, 비동기 통신, 그리고 유연한 라우팅 기능은 이러한 요구사항을 잘 충족시킨다. 특히 교환기(Exchange)와 바인딩(Binding)을 통한 메시지 라우팅은 데이터를 목적지에 따라 분류하여 처리할 수 있게 해준다.

IoT 스트리밍 아키텍처에서 AMQP는 주로 에지 컴퓨팅 게이트웨이 또는 클라우드 기반의 중앙 메시지 브로커와 함께 사용된다. 수천, 수만 대의 장치는 AMQP 클라이언트 라이브러리를 통해 브로커에 연결하여 데이터를 발행한다. 브로커는 이러한 메시지를 사전 정의된 규칙에 따라 적절한 큐(Queue)로 라우팅하며, 데이터를 소비하는 분석 애플리케이션, 저장소 시스템, 또는 다른 마이크로서비스는 각자의 큐에서 메시지를 가져가 처리한다. 이 구조는 장치와 데이터 처리 애플리케이션 간의 결합도를 낮추고, 시스템의 확장성과 유연성을 높인다.

AMQP 1.0 표준은 IoT 환경에 더 적합한 몇 가지 특징을 제공한다. 이진 프로토콜로서의 효율성, 다양한 전송 프로토콜(예: TCP, WebSockets) 위에서 동작할 수 있는 유연성, 그리고 강력한 보안 기능이 대표적이다. 이는 대역폭이 제한적이고 연결 상태가 불안정할 수 있는 IoT 네트워크에서 중요한 장점으로 작용한다. 또한, Apache Qpid의 Proton 라이브러리와 같은 경량 구현체는 리소스가 제한된 임베디드 장치에서도 AMQP 1.0을 사용할 수 있는 가능성을 열어주었다.

그러나 매우 낮은 대역폭과 높은 지연 시간을 가진 환경, 또는 초소형 장치에서는 AMQP보다 더 경량화된 MQTT 프로토콜이 선호되는 경우도 있다. 반면, 복잡한 라우팅 로직, 강력한 트랜잭션 지원, 그리고 기업 시스템과의 통합이 중요한 대규모 IoT 플랫폼에서는 AMQP가 여전히 강력한 선택지로 고려된다.

MQTT는 경량의 메시지 브로커 프로토콜로, 특히 대역폭이 제한되고 연결 상태가 불안정한 환경에 적합하게 설계되었다. 주로 사물인터넷 기기, 모바일 애플리케이션, 머신 대 머신 통신에서 널리 사용된다. 발행-구독 모델을 기반으로 하여, 클라이언트가 브로커에 연결하여 메시지를 발행하거나 특정 토픽을 구독한다.

AMQP와의 주요 차이점은 프로토콜의 복잡성과 목적에 있다. MQTT는 매우 단순하고 헤더 오버헤드가 작은 이진 프로토콜로 설계되어, 배터리 수명이 짧고 컴퓨팅 성능이 낮은 소형 디바이스에서 효율적으로 동작한다. 반면, AMQP는 더 풍부한 기능 세트와 복잡한 라우팅을 제공하는 엔터프라이즈급 프로토콜이다. MQTT의 메시지 라우팅은 계층적 토픽 문자열(예: sensor/room1/temperature)에 의존하는 반면, AMQP는 익스체인지, 큐, 바인딩 키를 통한 더 유연하고 강력한 라우팅을 지원한다.

결론적으로, MQTT는 제한된 리소스 환경에서 간단하고 효율적인 메시징이 필요할 때 최적의 선택이다. 반면, AMQP는 신뢰성, 트랜잭션, 복잡한 메시지 흐름 제어, 상호 운용성이 중요한 기업 애플리케이션 통합 시나리오에 더 적합하다. 두 프로토콜은 서로 다른 문제 영역을 해결하기 위해 공존한다.

Apache Kafka는 AMQP와는 설계 철학과 목적이 다른 분산 스트리밍 플랫폼이다. AMQP가 메시지 지향 미들웨어(MOM)로서 신뢰할 수 있는 메시지 배달과 복잡한 라우팅에 초점을 맞춘다면, Kafka는 고처리량의 실시간 데이터 피드를 장기간 안정적으로 저장하고 처리하는 데 특화되어 있다. Kafka는 발행-구독 모델을 기반으로 하지만, 메시지를 소비 후 즉시 삭제하는 대신 설정 가능한 기간 동안 디스크에 보관한다. 이는 데이터를 재생하거나 새로운 애플리케이션이 과거 데이터를 처리할 수 있게 하는 강력한 기능을 제공한다.

Kafka의 핵심 아키텍처는 파티셔닝되고 복제된 토픽으로 구성된다. 생산자는 특정 토픽에 메시지를 발행하고, 소비자는 토픽을 구독하여 메시지를 가져온다. 메시지는 순서가 보장되는 파티션 내에서 오프셋이라는 고유한 식별자로 관리된다. 이 구조는 수평적 확장성과 장애 허용성을 극대화하며, 초당 수백만 메시지 처리와 같은 대규모 데이터 스트리밍 시나리오에 적합하다.

AMQP와 Kafka의 주요 차이점은 다음 표와 같다.

결론적으로, 복잡한 라우팅, 신뢰성 있는 배달, 그리고 다양한 메시지 패턴(점대점, 작업 큐)이 필요한 엔터프라이즈 메시징에는 AMQP 브로커가 더 적합하다. 반면, 웹사이트 활동 추적, 애플리케이션 로그 집계, 이벤트 소싱, 또는 대량의 스트리밍 데이터를 실시간으로 처리하고 저장해야 하는 경우에는 Kafka가 더 나은 선택이 된다.

STOMP는 단순 텍스트 지향 메시징 프로토콜의 약자로, TCP나 WebSocket과 같은 스트림 기반 전송 프로토콜 위에서 동작하는 텍스트 기반의 간단한 메시징 프로토콜이다. HTTP와 유사한 프레임 기반 구조를 사용하며, 프레임은 명령어, 헤더, 본문으로 구성된다. 이 프로토콜은 클라이언트와 브로커 간의 상호작용을 위한 제한된 명령어 집합(예: CONNECT, SEND, SUBSCRIBE, DISCONNECT)을 정의하여, 구현과 디버깅이 상대적으로 쉽다는 특징을 가진다.

AMQP와의 주요 차이점은 프로토콜의 복잡성과 기능 집합에 있다. AMQP는 풍부한 메시징 기능(세분화된 라우팅, 트랜잭션, 신뢰성 보장 등)과 복잡한 프로토콜 계층을 갖춘 기능 완비형 프로토콜인 반면, STOMP는 최소한의 기능으로 설계되어 가볍고 간결하다. 따라서 STOMP는 웹 브라우저와 같은 경량 클라이언트에서 쉽게 사용하거나, 기능보다는 단순성과 상호운용성이 중요한 환경에 적합하다. 예를 들어, STOMP는 WebSocket을 통해 웹 브라우저가 직접 메시지 브로커와 통신할 수 있는 간편한 방법을 제공한다.

다음은 AMQP, MQTT, STOMP의 주요 특성을 비교한 표이다.

STOMP는 Apache ActiveMQ, RabbitMQ(플러그인 필요), Spring Framework의 메시징 모듈 등 여러 메시지 브로커에서 지원한다. 복잡한 라우팅 로직이나 정교한 서비스 품질(QoS) 보장보다는, 다양한 클라이언트(특히 스크립트 언어나 웹 기반 클라이언트)가 표준화된 텍스트 명령으로 간단히 메시지를 주고받아야 하는 시나리오에서 주로 채택된다.