Sub (r1)

발행자는 Pub/Sub 패턴에서 메시지를 생성하고 발행하는 주체이다. 발행자는 생산자라고도 불리며, 특정 토픽이나 채널에 메시지를 전송하는 역할을 한다. 발행자는 메시지를 수신할 구독자가 누구인지, 몇 명인지 알 필요가 없다. 이는 시스템 간의 느슨한 결합을 가능하게 하는 핵심적인 특징이다.

발행자는 일반적으로 메시지 브로커라는 중간 매개체에게 메시지를 전달한다. 발행자는 브로커에 연결하여, 메시지와 함께 해당 메시지가 속한 토픽 정보를 함께 제출한다. 이후 메시지의 라우팅과 배달은 전적으로 메시지 브로커가 담당하게 된다. 이 방식은 발행자와 구독자가 서로를 직접 알지 못해도 통신할 수 있게 해준다.

발행자는 다양한 형태를 가질 수 있다. 예를 들어, 마이크로서비스 아키텍처에서 주문 생성 서비스는 '주문생성됨'이라는 이벤트를 발행하는 발행자가 될 수 있다. 또한, IoT 장치가 센서 데이터를 지속적으로 발행하거나, 애플리케이션 서버가 실시간 알림을 발행하는 경우도 흔히 볼 수 있는 발행자의 예시이다.

발행자의 주요 책임은 메시지를 생성하고 명시된 토픽으로 정확히 발행하는 것이다. 발행자는 구독자의 상태나 메시지 처리 결과에 대해서는 일반적으로 관여하지 않으며, 이는 비동기 통신의 본질에 부합한다. 이러한 발행자의 독립성은 시스템의 확장성과 유연성을 크게 향상시킨다.

구독자는 Pub/Sub 패턴에서 특정 토픽이나 채널에 관심을 등록하고, 해당 주제로 발행되는 메시지를 수신하는 주체이다. 구독자는 메시지 브로커에게 자신이 수신하고자 하는 토픽에 대한 구독 의사를 알리며, 이후 해당 토픽으로 발행되는 모든 메시지를 브로커로부터 비동기적으로 전달받는다. 하나의 토픽에는 여러 구독자가 동시에 존재할 수 있으며, 각 구독자는 독립적으로 메시지를 처리한다.

구독자의 핵심 역할은 발행자로부터의 직접적인 의존 없이 필요한 이벤트나 데이터를 수신하는 것이다. 이는 시스템 간 느슨한 결합을 실현하는 데 기여한다. 구독자는 자신의 처리 능력에 맞춰 메시지를 소비하며, 발행자가 메시지를 발행하는 속도와 구독자가 메시지를 처리하는 속도가 다를 수 있는 비동기 통신의 이점을 활용한다.

구독자는 종종 마이크로서비스, 백엔드 서비스, 클라이언트 애플리케이션 등 다양한 형태로 구현된다. 예를 들어, 주문 생성 이벤트를 구독하는 서비스는 재고 관리, 결제 처리, 배송 준비 등 여러 하위 작업을 트리거할 수 있다. 이벤트 주도 아키텍처에서는 이러한 구독자들이 이벤트에 반응하여 비즈니스 로직을 실행하는 주요 구성 요소가 된다.

구독 모델은 토픽 기반, 콘텐츠 기반 필터링 등에 따라 세부 동작이 달라질 수 있다. 또한, 메시지 큐와의 주요 차이점 중 하나는 하나의 메시지를 동일 토픽을 구독하는 모든 구독자에게 브로드캐스트하는 점이다. 구독자는 필요에 따라 동적으로 구독을 시작하거나 중지할 수 있어 시스템의 유연성과 확장성을 높인다.

메시지는 Pub/Sub 패턴에서 교환되는 정보의 기본 단위이다. 발행자가 생성하여 특정 토픽에 게시하는 데이터 덩어리로, 구독자가 최종적으로 수신하는 대상이다. 메시지는 일반적으로 헤더와 본문으로 구성된다. 헤더에는 메시지를 식별하거나 라우팅하는 데 사용되는 메타데이터(예: 메시지 ID, 생성 타임스탬프, 우선순위, 속성)가 포함되며, 본문에는 전달하려는 실제 데이터 페이로드가 담긴다.

메시지의 내용은 매우 다양할 수 있다. 단순한 텍스트 문자열이나 JSON, XML과 같은 구조화된 데이터 형식일 수도 있고, 바이너리 데이터일 수도 있다. 메시지 브로커는 이러한 메시지를 중개하며, 발행자와 구독자 사이의 직접적인 연결 없이도 메시지가 안정적으로 전달될 수 있도록 보장하는 역할을 한다. 이 과정에서 메시지 브로커는 지속성, 전달 보증, 순서 보장 등의 품질을 제공할 수 있다.

효율적인 Pub/Sub 시스템에서 메시지 설계는 중요하다. 메시지는 필요한 정보를 충분히 담아야 하지만, 불필요한 데이터로 인해 네트워크 대역폭과 처리 리소스를 낭비해서는 안 된다. 또한, 메시지의 형식은 발행자와 구독자 모두가 이해할 수 있어야 하며, 이는 API 설계나 스키마 레지스트리 등을 통해 관리된다. 잘 정의된 메시지는 마이크로서비스나 분산 시스템 간의 명확한 계약을 형성하여 시스템 전체의 유지보수성을 높인다.

토픽 또는 채널은 발행자와 구독자 사이의 논리적 연결점이자 메시지 분배의 기준이 된다. 발행자는 특정 토픽에 메시지를 발행하고, 구독자는 관심 있는 토픽을 구독함으로써 메시지를 수신한다. 이는 우편 시스템에서 특정 주소나 관심사를 기준으로 메일을 분류하는 방식과 유사하다. 토픽은 일반적으로 문자열로 식별되며, 계층 구조를 가질 수 있어 세분화된 메시지 라우팅이 가능하다.

토픽 기반 메시징은 콘텐츠 기반 메시징과 대비된다. 토픽 기반에서는 메시지의 내용과 무관하게 사전에 정의된 주제 이름만으로 메시지가 전달된다. 반면 콘텐츠 기반에서는 구독자가 메시지 페이로드의 특정 속성이나 값을 기준으로 필터링 조건을 정의한다. 대부분의 메시지 브로커 시스템은 토픽 기반 방식을 기본으로 지원하며, AMQP와 같은 프로토콜에서는 이를 '익스체인지'와 '라우팅 키'의 조합으로 구현하기도 한다.

토픽의 설계는 시스템의 확장성과 유연성에 직접적인 영향을 미친다. 너무 세분화된 토픽은 관리 부담을 증가시키고, 너무 포괄적인 토픽은 구독자가 필요 없는 메시지를 많이 받게 할 수 있다. 효과적인 토픽 네임스페이스와 와일드카드 구독 패턴을 활용하면, 구독자를 효율적으로 그룹화하고 메시지 흐름을 체계적으로 관리할 수 있어 마이크로서비스 간 통신이나 실시간 데이터 스트리밍 시나리오에서 매우 유용하다.

Pub/Sub 패턴의 가장 중요한 특징 중 하나는 시스템 구성 요소 간의 느슨한 결합을 가능하게 한다는 점이다. 이는 발행자와 구독자가 서로를 직접 알 필요가 없으며, 오직 중간 매개자인 메시지 브로커와 약속된 토픽 또는 채널을 통해 간접적으로 소통하기 때문이다.

이러한 구조 덕분에 시스템의 유연성과 유지보수성이 크게 향상된다. 발행자는 어떤 구독자가 메시지를 받는지 신경 쓸 필요 없이 단순히 메시지를 발행하기만 하면 되며, 구독자 역시 메시지를 누가 보냈는지 알 필요 없이 관심 있는 주제만 구독하면 된다. 이는 마이크로서비스나 분산 시스템에서 서비스 간의 의존성을 최소화하여, 한 서비스의 변경이 다른 서비스에 미치는 영향을 줄이는 데 핵심적인 역할을 한다.

결과적으로 느슨한 결합은 시스템의 확장성을 높인다. 새로운 구독자를 추가하거나 기존 구독자를 제거하는 것이 발행자나 다른 구독자의 동작에 전혀 영향을 주지 않는다. 이는 이벤트 주도 아키텍처를 구현할 때 필수적인 특성으로, 비즈니스 로직의 변화에 따라 유연하게 컴포넌트를 배치하고 조정할 수 있게 해준다.

Pub/Sub는 본질적으로 비동기 통신 모델이다. 발행자는 메시지를 발행한 후, 그 메시지가 언제 누구에게 전달될지 기다리지 않고 즉시 자신의 작업을 계속한다. 마찬가지로 구독자도 메시지가 도착하기를 수동적으로 기다리는 것이 아니라, 자신이 관심 있는 주제를 사전에 구독해두면 메시지 브로커로부터 메시지가 비동기적으로 전달된다. 이는 발행자와 구독자가 서로의 존재나 상태를 직접 알 필요 없이, 오직 메시지 브로커라는 중간 매개체를 통해 간접적으로 소통하게 함으로써 가능해진다.

이러한 비동기 특성은 시스템의 응답성과 처리량을 크게 향상시킨다. 발행자는 구독자의 처리 속도에 구애받지 않고 빠르게 메시지를 계속 생산할 수 있으며, 구독자 역시 자신의 처리 능력에 맞춰 메시지를 소비할 수 있다. 이는 특히 피크 시간대에 발생하는 트래픽 급증이나 일시적인 구독자 장애 상황에서 유용하다. 메시지는 메시지 브로커에 버퍼링되어, 구독자가 준비되었을 때 전달되므로 데이터 유실 없이 시스템의 부하를 평탄화할 수 있다.

비동기 통신은 이벤트 주도 아키텍처의 핵심을 이룬다. 한 서비스에서 발생한 이벤트(예: 주문 생성, 결제 완료)를 Pub/Sub를 통해 발행하면, 해당 이벤트에 관심 있는 여러 다른 마이크로서비스들이 각자의 속도로 비동기적으로 이를 수신하여 후속 작업(재고 감소, 알림 발송, 분석 데이터 기록 등)을 수행할 수 있다. 이는 서비스 간의 직접적인 호출과 동기적 의존성을 제거하여, 전체 시스템의 결합도를 낮추고 복원력을 높이는 데 기여한다.

Pub/Sub 패턴의 확장성은 시스템의 부하 증가에 따라 발행자, 구독자, 그리고 메시지 브로커를 쉽게 추가할 수 있는 구조에서 비롯된다. 발행자와 구독자는 서로를 직접 알 필요 없이 메시지 브로커를 통해 간접적으로 연결되므로, 양측을 독립적으로 확장하는 것이 가능하다. 예를 들어, 특정 토픽에 대한 구독자가 급격히 증가하더라도, 해당 토픽을 담당하는 메시지 브로커 인스턴스를 수평적으로 확장하거나, 클러스터링 기술을 적용하여 처리 용량을 늘릴 수 있다.

이러한 확장성은 특히 마이크로서비스 아키텍처나 실시간 데이터 스트리밍과 같은 대규모 분산 시스템에서 중요한 장점으로 작용한다. 시스템의 한 부분에서 발생하는 트래픽 급증이 다른 부분으로 직접적인 영향을 미치지 않도록 격리할 수 있으며, 비동기 통신 방식 덕분에 구독자의 처리 속도가 느려도 발행자의 작업이 차단되지 않는다. 결과적으로 전체 시스템의 가용성과 처리량을 유연하게 조정할 수 있어, 사용자 수나 데이터 볼륨이 변동하는 환경에 적합한 모델이다.

토픽 기반 Pub/Sub은 가장 일반적으로 사용되는 구현 패턴이다. 이 패턴에서는 메시지 브로커가 관리하는 논리적 채널인 토픽이 메시지의 분배 중심이 된다. 발행자는 특정 토픽에 메시지를 발행하며, 구독자는 관심 있는 토픽을 구독한다. 메시지 브로커는 발행된 메시지를 해당 토픽을 구독한 모든 구독자에게 전달하는 역할을 한다.

이 패턴의 핵심은 발행자와 구독자가 서로를 직접 알 필요가 없다는 점이다. 발행자는 메시지를 어느 토픽에 보낼지만 알고, 구독자는 어떤 토픽에서 메시지를 받을지만 정의한다. 이로 인해 시스템 구성 요소 간의 느슨한 결합이 강력하게 실현된다. 새로운 구독자를 추가하거나 기존 구독자를 제거해도 발행자의 코드는 전혀 변경할 필요가 없다.

토픽 기반 패턴은 주로 메시지의 유형이나 범주에 따라 구독을 필터링하는 경우에 적합하다. 예를 들어, stock.aapl 토픽에는 애플 주가 변동 메시지를, order.completed 토픽에는 주문 완료 이벤트 메시지를 발행하는 방식이다. Apache Kafka나 RabbitMQ와 같은 많은 현대적 메시지 브로커가 이 패턴을 지원하며, 마이크로서비스 간 통신이나 실시간 알림 시스템 구축에 널리 활용된다.

콘텐츠 기반 구현 패턴은 메시지의 내용, 즉 페이로드에 포함된 특정 속성이나 필드 값을 기준으로 메시지를 필터링하고 라우팅하는 방식이다. 이 패턴에서는 구독자가 특정 토픽 이름을 구독하는 대신, 관심 있는 메시지의 내용을 표현하는 구독 조건이나 필터 규칙을 정의한다. 예를 들어, 주식 거래 시스템에서 구독자는 "주식코드가 'XYZ'이고 가격 변동폭이 5%를 초과하는 메시지만 수신하라"는 식의 조건을 설정할 수 있다. 메시지 브로커는 발행된 각 메시지를 평가하여, 구독자가 정의한 조건과 일치하는 경우에만 해당 구독자에게 메시지를 전달한다.

이 방식은 토픽 기반 패턴에 비해 더 세밀하고 유연한 메시지 라우팅이 가능하다는 장점이 있다. 구독자는 자신이 정말 필요로 하는 데이터에 대해서만 메시지를 받을 수 있으므로, 네트워크 대역폭과 처리 리소스를 절약할 수 있다. 또한, 새로운 메시지 유형이나 데이터 속성이 추가되더라도, 단순히 새로운 토픽을 생성하고 관리할 필요 없이 기존의 구독 필터 로직을 확장하는 방식으로 대응할 수 있어 시스템의 유연성을 높인다.

그러나 콘텐츠 기반 패턴은 구현 복잡도가 상대적으로 높고, 성능에 주의를 기울여야 한다는 단점도 있다. 메시지 브로커는 모든 발행된 메시지에 대해 모든 활성 구독자의 필터 조건을 평가해야 하므로, 구독자 수가 많고 메시지 발행 빈도가 높을 경우 처리 부하가 크게 증가할 수 있다. 효율적인 필터링을 위해서는 복잡한 인덱싱이나 평가 엔진이 필요하며, 이는 시스템의 전체적인 복잡성을 증가시킨다. 따라서 대규모 이벤트 주도 아키텍처나 고빈도 실시간 데이터 스트리밍 시나리오에서는 주의 깊게 설계하고 성능을 테스트해야 한다.

Pub/Sub 패턴은 실시간 알림 시스템을 구축하는 데 매우 적합한 아키텍처이다. 발행자는 특정 이벤트(예: 새 글 작성, 주문 완료, 시스템 장애)가 발생하면 해당 이벤트를 메시지로 만들어 사전에 정의된 토픽에 발행한다. 해당 토픽을 구독하고 있는 모든 구독자(알림 수신자)는 메시지 브로커를 통해 거의 실시간으로 이 메시지를 수신하게 된다.

이 모델을 사용하면 알림 발송자와 수신자 간의 직접적인 연결이 필요 없어 시스템이 단순해지고 확장성이 높아진다. 예를 들어, 사용자에게 푸시 알림을 보내는 서비스, 이메일 발송 서비스, 앱 내 알림을 처리하는 서비스 등 다양한 알림 채널을 담당하는 구독자들이 동일한 '주문 완료' 토픽을 구독할 수 있다. 주문 처리 시스템은 복잡한 로직 없이 단 한 번의 메시지 발행으로 모든 채널에 알림이 전파되도록 할 수 있다.

실시간 알림 시스템에서 Pub/Sub는 특히 대규모 사용자 기반을 처리할 때 빛을 발한다. 사용자 수가 급증하거나 새로운 알림 유형이 추가되어도, 새로운 구독자 서비스를 배포하고 해당 토픽을 구독하도록 설정하는 것만으로 시스템을 쉽게 확장할 수 있다. 이는 마이크로서비스 환경에서 각 서비스의 독립적인 배포와 확장을 가능하게 하는 느슨한 결합의 대표적인 장점을 보여준다.

이러한 특성 덕분에 소셜 미디어의 실시간 피드 업데이트, 주식 시장의 가격 변동 알림, 모니터링 시스템의 이상 감지 알림, 협업 도구의 실시간 활동 스트림 등 다양한 실시간 알림 시나리오에서 Pub/Sub 패턴이 광범위하게 활용되고 있다.

이벤트 주도 아키텍처(EDA)는 시스템의 구성 요소들이 이벤트의 생산, 감지, 소비 및 반응을 통해 상호작용하는 소프트웨어 아키텍처 패러다임이다. 이 아키텍처에서 이벤트는 시스템 내에서 발생한 중요한 상태 변화나 사건을 나타내며, Pub/Sub 패턴은 이러한 이벤트를 효과적으로 전파하는 핵심 메커니즘으로 자주 활용된다. 발행자는 특정 이벤트가 발생했음을 알리는 메시지를 토픽에 발행하고, 해당 이벤트에 관심 있는 구독자들은 비동기적으로 이를 수신하여 후속 작업을 처리한다.

이 접근 방식은 마이크로서비스 간 통신에 특히 유용하다. 각 서비스는 자체적인 비즈니스 로직에 집중하면서도, Pub/Sub를 통해 다른 서비스에서 발생한 이벤트를 구독함으로써 느슨하게 결합된 협력 관계를 구축할 수 있다. 예를 들어, '주문 생성' 이벤트가 발행되면, 재고 관리 서비스, 결제 서비스, 배송 서비스 등이 각자 필요한 비즈니스 처리를 독립적으로 수행할 수 있다. 이는 서비스 간의 직접적인 호출 의존성을 제거하여 시스템 전체의 복잡성을 낮추고 확장성을 높인다.

이러한 이벤트 주도 아키텍처와 Pub/Sub의 조합은 실시간으로 데이터를 처리하고 반응해야 하는 현대적 분산 시스템, 예를 들어 금융 거래 시스템, 실시간 추천 엔진, 사물인터넷(IoT) 플랫폼 등에서 광범위하게 적용된다. 이는 시스템의 각 부분이 독립적으로 진화하고 장애에 격리될 수 있도록 하며, 복잡한 비즈니스 워크플로우를 구성하는 데 효과적인 기반을 제공한다.

로그 집계는 여러 개의 분산된 서버나 애플리케이션에서 생성되는 대량의 로그 데이터를 중앙에서 수집, 저장, 처리 및 분석하기 위한 일반적인 Pub/Sub 사용 사례이다. 시스템의 규모가 커지고 마이크로서비스 아키텍처가 보편화되면서, 각 서비스 인스턴스는 로컬에 로그를 남기게 된다. 이러한 로그를 실시간으로 모니터링하거나 오류를 추적하기 위해 각 서버에 직접 접근하는 것은 비효율적이다.

Pub/Sub 패턴을 적용하면, 각 애플리케이션은 로그 메시지를 발행자 역할을 하여 특정 토픽에 발행한다. 중앙의 로그 집계 시스템이나 로그 분석 도구는 해당 토픽을 구독하여 모든 서버에서 발생하는 로그를 실시간으로 수신할 수 있다. 이를 통해 시스템 모니터링, 보안 감사, 성능 분석, 오류 진단 등을 통합된 플랫폼에서 수행할 수 있다. 특히 Apache Kafka나 RabbitMQ와 같은 메시지 브로커는 높은 처리량과 내구성을 제공하여 대규모 로그 스트림을 안정적으로 처리하는 데 적합하다.

이 방식의 주요 장점은 로그를 생성하는 애플리케이션(발행자)과 로그를 소비하는 분석 시스템(구독자) 간의 느슨한 결합을 가능하게 한다는 점이다. 로그 생산자는 로그 데이터를 어디서 어떻게 처리하는지 알 필요 없이 단순히 메시지를 발행하기만 하면 된다. 반대로, 새로운 모니터링 도구를 추가하려면 해당 도구가 원하는 토픽을 구독하기만 하면 되므로 시스템 통합이 용이해진다. 결과적으로 실시간 로그 스트리밍과 효율적인 데이터 파이프라인 구축을 지원한다.

Pub/Sub 패턴의 가장 큰 장점은 시스템 구성 요소 간의 느슨한 결합을 가능하게 한다는 점이다. 발행자는 메시지를 누가 받는지 알 필요가 없으며, 구독자는 메시지를 누가 보냈는지 알 필요가 없다. 양측은 오직 메시지가 전달되는 토픽이나 채널에만 관심을 가진다. 이로 인해 시스템의 한 부분을 변경하거나 확장할 때 다른 부분에 미치는 영향을 최소화할 수 있으며, 이는 마이크로서비스와 같은 분산 시스템 설계에 매우 유리하다.

두 번째 장점은 높은 확장성과 탄력성을 제공한다는 것이다. 새로운 구독자를 추가하거나 제거하는 것이 매우 쉽기 때문에, 시스템의 부하에 따라 실시간으로 구독자 인스턴스를 수평적으로 확장할 수 있다. 또한 비동기 통신을 기본으로 하기 때문에, 발행자는 구독자의 처리 속도나 가용성에 구애받지 않고 메시지를 계속 발행할 수 있다. 이는 이벤트 주도 아키텍처에서 많은 양의 이벤트를 처리해야 할 때 핵심적인 이점으로 작용한다.

마지막으로, Pub/Sub는 복잡한 메시지 라우팅과 브로드캐스트를 효율적으로 지원한다. 하나의 메시지를 여러 수신자에게 동시에 전달하는 일대다 통신이 본질적으로 가능하며, 메시지 브로커를 통해 구독자의 상태나 위치를 관리함으로써 신뢰성 있는 메시지 전달을 보장할 수 있다. 이는 실시간 알림 시스템, 로그 집계, 데이터 스트리밍과 같이 동일한 데이터를 다양한 목적의 여러 소비자가 필요로 하는 사용 사례에 이상적이다.

Pub/Sub 패턴의 주요 단점 중 하나는 메시지 전달 보장의 복잡성이다. 발행자는 메시지를 발행한 후 구독자가 정상적으로 수신했는지 즉시 알 수 없다. 이는 비동기적이고 느슨한 결합 구조의 자연스러운 특성이지만, 시스템에 따라서는 메시지 손실이 치명적일 수 있다. 이를 보완하기 위해 메시지 브로커는 메시지 지속성, 확인 응답, 재시도 메커니즘과 같은 기능을 제공하지만, 이는 설정과 운영의 복잡도를 증가시키고 성능에 영향을 미칠 수 있다.

또 다른 단점은 시스템의 전체적인 흐름과 상태를 파악하기 어려워진다는 점이다. 발행자와 구독자 간의 직접적인 연결이 없기 때문에, 특정 메시지가 어떤 경로를 통해 어떤 구독자에게 전달되었는지 추적하거나, 메시지 처리 파이프라인 전체를 디버깅하는 것이 어렵다. 특히 토픽을 통해 다수의 서비스가 연결된 이벤트 드리븐 아키텍처에서는 이벤트 흐름을 시각화하고 모니터링하기 위한 추가적인 도구와 노력이 필요하다.

마지막으로, 메시지 순서 보장에 대한 문제가 있다. 높은 처리량과 확장성을 위해 여러 구독자 인스턴스가 병렬로 동작하거나, 메시지가 여러 경로를 통해 전달될 경우, 발행된 순서대로 메시지가 도착한다는 것을 보장하기 어렵다. 일부 메시지 브로커는 특정 토픽 내에서의 순서 유지 기능을 제공하기도 하지만, 이는 성능과 확장성에 제약을 줄 수 있으며, 전역적인 순서를 완벽히 보장하는 것은 본질적으로 어려운 과제이다.

메시지 브로커는 발행-구독 패턴을 구현하는 핵심 미들웨어 구성 요소이다. 발행자와 구독자 사이에 위치하여 메시지의 라우팅, 변환, 전달을 담당한다. 발행자는 메시지 브로커에 메시지를 전송하기만 하면 되고, 구독자는 메시지 브로커로부터 메시지를 수신하기만 하면 되므로, 양측은 서로의 존재나 상태를 직접 알 필요가 없는 완전한 느슨한 결합을 달성할 수 있다. 이는 마이크로서비스나 분산 시스템에서 서비스 간의 의존성을 최소화하는 데 중요한 역할을 한다.

메시지 브로커의 주요 기능은 메시지의 안정적인 전달과 효율적인 라우팅이다. 발행자가 보낸 메시지를 영속적으로 저장하여 구독자가 일시적으로 오프라인 상태여도 나중에 메시지를 수신할 수 있도록 보장한다. 또한, 사전에 정의된 규칙에 따라 특정 토픽이나 채널로 메시지를 전달하거나, 메시지의 내용을 분석하여 적절한 구독자에게 라우팅하는 역할을 수행한다. 이를 통해 비동기 통신과 확장성을 실현한다.

AMQP나 MQTT와 같은 표준 메시징 프로토콜을 지원하는 메시지 브로커도 있으며, Apache Kafka, RabbitMQ, Redis의 Pub/Sub 기능 등이 대표적인 구현체이다. 이러한 도구들은 각각 다른 설계 목표를 가지고 있어, 높은 처리량이 필요한 실시간 데이터 스트리밍 환경이나, 복잡한 라우팅이 필요한 이벤트 주도 아키텍처 등 다양한 사용 사례에 맞게 선택되어 활용된다.

MQTT는 경량의 메시지 기반 통신 프로토콜로, 특히 사물인터넷과 모바일 애플리케이션에서 널리 사용된다. 이 프로토콜은 발행-구독 패턴을 기반으로 설계되어, 발행자가 브로커 서버를 통해 특정 토픽에 메시지를 발행하면, 해당 토픽을 구독자가 수신하는 구조이다. 네트워크 대역폭이 제한되고 배터리 수명이 중요한 환경에서 효율적으로 동작하도록 최소한의 오버헤드를 가지는 것이 핵심 특징이다.

MQTT의 주요 장점은 단순성과 낮은 전력 소비에 있다. 프로토콜 헤더가 매우 작고, 연결 상태를 유지하는 데 필요한 리소스가 적어 임베디드 시스템에 적합하다. 또한 TCP/IP 위에서 동작하며, 다양한 서비스 품질 수준을 제공하여 메시지 전달의 신뢰성을 조절할 수 있다. 이러한 특성 덕분에 원격 센서 데이터 수집, 스마트 홈 기기 제어, 실시간 알림 시스템 등에 두루 적용된다.

MQTT는 표준화된 개방형 프로토콜로서, Eclipse Mosquitto나 EMQ X와 같은 여러 오픈 소스 및 상용 브로커 구현체가 존재한다. 이는 다양한 클라이언트 라이브러리와 함께 크로스 플랫폼 호환성을 제공하며, 클라우드 서비스의 완전 관리형 서비스로도 제공되어 시스템 통합을 용이하게 한다.

AMQP(Advanced Message Queuing Protocol)는 메시지 지향 미들웨어를 위한 개방형 표준 응용 계층 프로토콜이다. 이 프로토콜은 메시지의 안정적인 전달을 보장하는 기능을 정의하며, 다양한 메시지 브로커 및 클라이언트 애플리케이션 간의 상호 운용성을 제공하는 것이 주요 목표이다. AMQP는 Pub/Sub 패턴을 포함한 다양한 메시징 패턴을 지원하는 강력한 메시징 표준으로 자리 잡았다.

AMQP의 핵심은 교환기(Exchange), 큐(Queue), 바인딩(Binding)이라는 구성 요소를 통해 메시지의 라우팅을 유연하게 제어하는 모델에 있다. 발행자는 메시지를 특정 교환기에 보내며, 교환기는 미리 정의된 규칙(바인딩)에 따라 메시지를 하나 이상의 큐로 전달한다. 구독자는 특정 큐에서 메시지를 가져와 처리한다. 이 구조를 통해 토픽 기반 라우팅이나 콘텐츠 기반 라우팅 등 복잡한 메시지 배포 패턴을 구현할 수 있다.

이 프로토콜은 신뢰성과 상호 운용성을 중시하여 설계되었다. 메시지 승인, 트랜잭션, 지속성 같은 기능을 명시적으로 정의함으로써, 은행, 거래소, 통신 사업자와 같이 높은 신뢰성이 요구되는 금융 및 엔터프라이즈 환경에서 널리 채택되었다. RabbitMQ가 AMQP 0-9-1 버전을 구현한 대표적인 오픈 소스 메시지 브로커이다.

AMQP는 마이크로서비스 간 통신, 이벤트 주도 아키텍처(EDA), 작업 큐 처리 등 다양한 분산 시스템 시나리오에 적용된다. 특히 서비스 간에 느슨한 결합을 유지하면서도 안정적인 비동기 통신이 필요한 복잡한 엔터프라이즈 애플리케이션 통합에 적합한 프로토콜로 평가받는다.

Redis Pub/Sub은 Redis 데이터베이스가 제공하는 경량의 메시지 브로커 기능이다. 발행-구독 패턴을 구현하여 비동기 통신을 가능하게 한다. 발행자는 특정 채널에 메시지를 발행하고, 해당 채널을 구독한 모든 구독자는 실시간으로 그 메시지를 수신한다. 이 과정에서 Redis 서버가 중앙 메시지 브로커 역할을 수행하여 메시지를 전달한다.

Redis Pub/Sub의 작동 방식은 단순하고 직접적이다. 구독자는 SUBSCRIBE 명령어를 사용하여 하나 이상의 채널을 구독한다. 발행자는 PUBLISH 명령어로 특정 채널에 메시지를 보내면, Redis 서버는 해당 채널을 구독 중인 모든 연결된 구독자에게 즉시 메시지를 전송한다. 이 모델은 기본적으로 메시지 큐와 달리 메시지를 저장하지 않고 즉시 전파하는 특징이 있다. 따라서 구독자가 연결되어 있지 않은 상태에서 발행된 메시지는 영구적으로 유실된다.

이 기술의 주요 특징은 간결함과 빠른 속도에 있다. 별도의 복잡한 메시지 브로커를 설치하거나 관리할 필요 없이 이미 널리 사용되는 Redis 인프라를 활용할 수 있다. 또한 인메모리 데이터베이스인 Redis의 특성상 메시지 전달 지연 시간이 매우 짧아 실시간 알림이나 채팅 애플리케이션에 적합하다. 그러나 메시지의 영속성이나 신뢰성 있는 전송을 보장하지 않으며, 과도한 트래픽 시 메모리 부하를 유발할 수 있다는 한계도 있다.

Redis Pub/Sub은 실시간으로 발생하는 이벤트를 여러 클라이언트에 브로드캐스트해야 하는 간단한 사용 사례에 주로 적용된다. 대표적으로 웹 애플리케이션의 실시간 알림 시스템, 간단한 채팅 룸, 서버 간의 상태 변경 신호 전달, 또는 마이크로서비스 간의 경량 이벤트 드리븐 아키텍처 구현에 활용된다. 보다 복잡하고 내구성이 요구되는 스트리밍 시나리오에는 Apache Kafka나 RabbitMQ와 같은 전문 메시징 시스템이 더 적합할 수 있다.

Apache Kafka는 링크드인에서 개발된 오픈소스 분산 시스템 플랫폼으로, 고성능의 실시간 데이터 스트리밍을 위해 설계되었다. 초기에는 로그 집계 시스템으로 출발했으나, 높은 처리량과 낮은 지연 시간, 내결함성 구조 덕분에 Pub/Sub 모델을 구현하는 핵심 메시지 브로커로 널리 사용되게 되었다. Kafka는 발행자가 특정 토픽에 메시지를 쓰고, 구독자가 해당 토픽을 구독하여 메시지를 읽는 기본적인 Pub/Sub 구조를 따르지만, 메시지를 디스크에 영속 저장하고 순서를 보장하는 점에서 전통적인 메시징 시스템과 차별화된다.

Kafka의 핵심 아키텍처는 토픽, 파티션, 프로듀서, 컨슈머, 브로커로 구성된다. 토픽은 메시지가 발행되는 카테고리이며, 성능과 확장성을 위해 여러 파티션으로 분할될 수 있다. 프로듀서는 메시지를 특정 토픽의 파티션에 발행하고, 컨슈머 그룹은 토픽을 구독하여 메시지를 소비한다. 여러 대의 브로커로 구성된 클러스터는 데이터를 복제하여 저장함으로써 시스템의 고가용성과 내구성을 보장한다.

이 플랫폼은 특히 대규모 이벤트 주도 아키텍처와 실시간 데이터 파이프라인 구축에 적합하다. 마이크로서비스 간의 비동기 통신 채널, 웹사이트 활동 추적, IoT 센서 데이터 수집, 애플리케이션 로그 중앙 집중화 등 다양한 사용 사례에서 활용된다. Kafka는 메시지를 일회성 소비가 아닌, 여러 컨슈머 그룹이 각자의 속도로 반복적으로 읽을 수 있도록 함으로써 데이터 흐름의 유연성을 극대화한다.

Kafka 생태계는 Kafka Connect를 통한 외부 시스템과의 데이터 연동, Kafka Streams 라이브러리를 이용한 스트림 처리 기능 등을 포함하여 지속적으로 확장되고 있다. 이러한 특징들로 인해 Apache Kafka는 현대 분산 애플리케이션에서 Pub/Sub 패턴을 구현하는 사실상의 표준 기술 중 하나로 자리 잡았다.