Publish / Subscribe
▶아키텍처 다이어그램
점선 애니메이션은 데이터 또는 요청의 흐름 방향을 나타냅니다
어떤 사건 하나가 여러 후속 반응을 동시에 필요로 할 때, 생산자가 모든 소비자를 직접 호출하기 시작하면 결합도가 급격히 높아집니다. 새 기능을 붙일 때마다 생산자 코드가 수정되면 변화가 한곳에 몰립니다. 누가 무엇을 듣는지도 생산자가 너무 많이 알아야 합니다. Publish/Subscribe는 이 fan-out 문제를 생산자 바깥으로 밀어냅니다.
시스템이 커질수록 하나의 상태 변화가 알림, 분석, 검색, 감사 로그처럼 여러 반응을 동시에 일으키는 경우가 많아졌습니다. 이 모든 후속 처리를 생산자 코드에 붙여 넣는 방식은 변화와 배포를 너무 무겁게 만들었습니다. 이벤트 브로커와 토픽 기반 메시징이 성숙하면서, 생산자는 사건만 알리고 반응은 구독자에게 맡기는 구조가 실무적으로 자리 잡았습니다.
발행자는 토픽이나 이벤트 버스에 메시지를 올리고, 구독자는 자신이 관심 있는 메시지를 받아 처리합니다. 이때 생산자는 구독자 목록을 알 필요가 없고, 구독자는 자기 책임만 구현하면 됩니다. 그래서 후속 기능이 늘어나도 생산자 경계는 비교적 안정적으로 유지됩니다.
Publish/Subscribe와 Message Queue는 모두 메시지를 다루지만 Pub/Sub는 한 사건을 여러 구독자에게 퍼뜨리는 데 초점이 있고, Queue는 작업을 누가 하나 가져가 처리하는 데 더 가깝습니다. 즉 Pub/Sub는 반응의 확장, Queue는 처리율 제어와 버퍼링 쪽에 더 강한 구조입니다.
새로운 후속 소비자를 자주 붙여야 하거나, 한 사건을 서로 다른 책임의 시스템이 동시에 소비해야 할 때 Publish/Subscribe는 자연스럽습니다. 특히 분석, 검색, 알림, 프로젝션 갱신 같은 흐름에 잘 맞습니다. 다만 fan-out이 쉬운 만큼 전체 흐름이 보이지 않기 쉬워서, 이벤트 계약과 소비자 관리를 운영 관점에서 함께 봐야 합니다.
더 읽어보기
현재 페이지의 개념 설명을 본 뒤 배경 설명과 참고 문서를 이어서 볼 수 있습니다.