Publish / Subscribe

주문 완료 이벤트가 발생했을 때 알림 팀, 분석 팀, 검색 인덱스 팀이 각자 그 데이터를 필요로 한다고 생각해 보십시오. 초반에는 주문 서비스 안에 알림 호출 코드를 직접 추가했지만, 팀이 늘어날수록 주문 서비스는 점점 더 많은 시스템의 주소와 호출 방식을 알아야 합니다. 새 팀이 합류할 때마다 주문 서비스를 함께 변경해야 하고, 그중 하나가 느리거나 장애가 나면 발행 흐름 전체가 흔들립니다. 생산자가 소비자를 직접 챙기는 이 구조는 소비자가 늘수록 유지하기 어려워집니다.

시스템 규모가 커지면서 단일 상태 변화가 여러 팀의 시스템에 동시에 영향을 줘야 하는 상황이 일반화됐습니다. 발행자 코드 안에 모든 후속 처리를 직접 담으면 변경과 배포가 한곳에 집중됩니다. 이벤트 브로커와 토픽 기반 메시징 인프라가 성숙하면서, 발행자는 사건만 선언하고 구독 여부는 각 시스템이 결정하는 방식이 운영과 조직 모두에 더 맞아떨어졌습니다. Publish/Subscribe는 그 흐름 속에서 fan-out 문제를 발행자 바깥으로 밀어내는 실용적인 패턴으로 자리 잡았습니다.

발행자는 메시지를 특정 토픽에 올리고, 그 토픽을 구독한 각 구독자는 브로커로부터 메시지를 전달받아 독립적으로 처리합니다. 구독자가 새로 추가되면 해당 토픽만 구독 등록하면 되고, 발행자는 아무것도 바꿀 필요가 없습니다. 각 구독자는 자신의 처리를 자신의 속도로 수행하며, 한 구독자의 장애가 다른 구독자나 발행자에 직접 영향을 주지 않습니다.

Publish/Subscribe와 Message Queue는 모두 메시지를 전달하는 구조이지만 전달 대상이 다릅니다. Pub/Sub는 메시지 하나를 여러 구독자 전체에게 복사해 전달하는 fan-out 구조이고, Message Queue는 메시지 하나를 소비자들 중 하나가 가져가 처리하는 경쟁 소비 구조입니다. 같은 이벤트를 여러 팀의 시스템이 각자 처리해야 한다면 Pub/Sub가 맞고, 동일 작업을 여러 워커 중 하나만 처리하면 된다면 Message Queue가 맞습니다.

새로운 소비자 시스템을 발행자 변경 없이 붙일 수 있어야 하거나, 한 사건을 서로 다른 책임의 여러 시스템이 독립적으로 처리해야 할 때가 Publish/Subscribe를 고려할 시점입니다. 알림, 분석, 검색 인덱싱, 감사 로그처럼 같은 원천 데이터를 다양한 목적으로 소비하는 흐름에서 특히 자연스럽습니다. 다만 fan-out이 쉬운 만큼 어느 구독자가 메시지를 받았는지, 처리가 성공했는지를 발행자 입장에서 추적하기 어렵습니다. 소비자 관리와 이벤트 계약을 운영 관점에서 함께 유지해야 합니다.