Pub/Sub (1)

Pub/Sub 란?

메시징 시스템에서의 기본 개념

Pub/Sub은 Publish / Subscribe의 줄임말로, 메시지를 발행(Publish) 하는 주체와 이를 구독(Subscribe) 하는 주체가 직접 연결되지 않고도 메시지를 주고받을 수 있는 비동기 메시징 패턴입니다.

 

 

즉, 발행자는 “이런 일이 일어났어!” 라고 외치고, 구독자는 “이런 일이 일어나면 알려줘!” 하고 기다리는 구조입니다.

 

• Publisher (발행자)
  • 메시지를 보내는 주체입니다.
  • 예: "새로운 상품이 입고되었어요!" 라고 시스템에 알리는 역할
• Subscriber (구독자)
  • 특정 주제를 구독하고 있다가 메시지를 수신하는 주체입니다.
  • 예: “새 상품 소식이 오면 알림을 받고 싶어요!” 라고 기다리는 사용자 또는 시스템

이 사이를 중재하는 중앙 허브(브로커 또는 메시지 큐)가 존재하여, 발행자와 구독자는 서로에 대해 아무것도 몰라도 됩니다.

 

 

 

---

 

구조 예시 (다이어그램 설명)

[Publisher] → 메시지 발행 → [Broker] → 메시지 전달 → [Subscriber 1]
                                              ↘︎            [Subscriber 2]

 

• Publisher는 “topic = 신상품알림”이라는 주제로 메시지를 발행합니다.
• Broker는 “topic = 신상품알림”을 구독한 Subscriber들에게 해당 메시지를 전달합니다.
• Publisher는 Subscriber가 몇 명인지, 누구인지 전혀 알지 못합니다. → 느슨한 결합

 

---

 

Observer 패턴과의 관계

Pub/Sub은 흔히 Observer 패턴의 확장판이라고 이해하면 좋습니다.

• Observer 패턴
  • 객체 간의 1:N 관계. 한 객체의 상태 변화에 따라 여러 객체가 자동으로 반응함.
• Pub/Sub 모델
  • 이 구조를 네트워크/시스템 전반으로 확장한 버전.
  • 차이점은 이벤트 브로커라는 중간자가 있다는 점
  • 직접적인 참조 없이, 전역 이벤트 시스템처럼 느슨하게 통신

 

---

 

Pub/Sub 모델이 필요한 이유

 

1) 느슨한 결합 (Loose Coupling)

 

프로그래밍에서 느슨한 결합은 시스템 설계에서 매우 중요한 가치입니다.

• Publisher는 Subscriber가 존재하는지 여부조차 모름
• Subscriber는 Publisher가 어떻게 메시지를 보내는지도 모름
• 중간에 브로커만 존재

 

이런 구조 덕분에 각 컴포넌트가 독립적으로 설계/배포/확장될 수 있습니다.

 

예시

// Angular 예시 (RxJS Subject)
const notifier = new Subject<string>();

// 구독자
notifier.subscribe(msg => console.log('구독한 메시지:', msg));

// 발행자
notifier.next('새로운 유저가 가입했습니다.');

 

---

 

2) 실시간성 (Real-time)

 

Pub/Sub은 이벤트가 발생하자마자 구독자에게 즉시 전달됩니다.

• 실시간 채팅
• 실시간 알림
• 스트리밍 시스템

같은 기능에서 필수적인 아키텍처입니다.

 

예) 유튜브에서 실시간 댓글 올라오는 기능 → 댓글 발행 시 구독자 브라우저에 실시간 반영

 

---

3) 이벤트 기반 아키텍처의 핵심

이벤트 기반(Event-driven) 아키텍처는 말 그대로 “무언가가 일어나면, 그에 반응한다”는 구조입니다.

 

이 구조에서 Pub/Sub은 가장 중요한 메시징 방식이에요.

• 사용자 행동 (클릭, 입력 등)
• 백엔드 작업 완료 (결제 완료, 상품 등록 등)
• 센서 데이터 수신 (IoT 등)

모든 게 이벤트로 추상화되며, 그 이벤트를 발행하고 구독하는 구조로 설계하면 유지보수와 확장성이 훨씬 좋아집니다.

 

---

4) 마이크로서비스와의 궁합

마이크로서비스 아키텍처는 각 서비스가 독립적으로 배포되고 실행되어야 합니다.

그런데 서로 직접 호출하게 되면 결합도가 올라갑니다.

 

그래서 대안으로 등장한 것이 바로 Pub/Sub입니다.

• Order Service가 “주문 생성됨” 이벤트를 발행
• Inventory Service는 이를 구독해서 재고를 감소
• Notification Service는 이를 구독해서 이메일 발송

각 서비스는 서로를 호출하지 않고, 오직 이벤트만 주고받는 구조 → 유연성, 확장성, 장애 전파 최소화

 

---

 

요약

 

항목	설명
핵심 개념	발행자와 구독자가 직접 연결되지 않고 중간 브로커를 통해 메시지를 주고받음
구성 요소	Publisher, Subscriber, Broker
장점	느슨한 결합, 실시간성, 이벤트 기반 아키텍처 구현에 적합
실사용 예	Angular RxJS, Redis Pub/Sub, Kafka, GCP Pub/Sub 등
적합한 상황	마이크로서비스, 실시간 알림, IoT, 대규모 메시징