메시지 브로커(Message Broker) 핵심 정리
서비스가 많아지고 MSA 구조로 가면, 서비스끼리 직접 REST로만 붙어 있는 구조는 한계가 금방 온다.
이때 사이에서 메시지를 받아 저장해두고, 필요한 서비스가 꺼내 가서 처리하도록 중개해 주는 게 메시지 브로커다.
이 글에서는 메시지 브로커 개념부터 RabbitMQ vs Kafka, 실제 활용 포인트까지 한 번에 정리해 본다.
1. 메시지 브로커란 뭐냐
메시지 브로커는 프로듀서(Producer)가 보낸 메시지를 받아 저장하고,
컨슈머(Consumer)가 꺼내 처리할 수 있게 해 주는 비동기 통신 중개 시스템이다.
1-1. 메시지 브로커가 하는 일
- 메시지 수신, 저장, 전달
- 큐(queue) 또는 토픽(topic) 기반 메시지 전송
- 메시지 유실 방지, 중복 방지 등 신뢰성 보장
- 서비스 간 통신을 비동기로 만들어 결합도 낮추기
1-2. 기본 구성 요소
-
Queue (메시지 큐)
- 메시지를 순서대로 쌓고, 꺼내 쓰는 구조
- Point-to-Point 통신에 사용
-
Topic (Pub/Sub)
- 한 메시지를 여러 구독자가 동시에 받을 수 있는 구조
- Publish / Subscribe 패턴에 사용
2. 메시지 전달 방식 두 가지
2-1. Point-to-Point (Queue 기반)
- 메시지가 하나의 큐에 들어가고, 한 컨슈머만 소비
- 같은 큐를 바라보는 컨슈머가 여러 개면, 메시지를 나눠 가져가면서 작업 분산 가능
대표적인 사용 예
-
작업 분산 (Work Distribution)
- 여러 워커가 하나의 큐를 보고 있다가 메시지를 하나씩 가져가서 처리
- 예: 이미지 리사이징, 대량 이메일 발송, 리포트 생성 등
-
백그라운드 처리 (Background Job)
- 사용자가 요청한 작업을 바로 처리하지 않고 큐에 넣어두고 나중에 처리
- 예: 결제 완료 후 영수증 메일, 알림 발송, 썸네일 생성
2-2. Publish / Subscribe (Topic 기반)
- 프로듀서가 메시지를 토픽/익스체인지에 발행(Publish)
- 여러 컨슈머가 그 토픽을 구독(Subscribe) 하면서 메시지를 동시에 수신
대표적인 사용 예
-
이벤트 브로드캐스트
- 주문 발생 이벤트를 재고 시스템, 배송 시스템, 알림 시스템이 모두 받아서 각자 처리
- 하나의 이벤트로 여러 서비스가 동시에 반응
-
다중 시스템 알림
-
로그인 이벤트 하나로
- 보안 시스템
- 로그 수집 시스템
- 관리자 알림 시스템
에 동시에 이벤트 전달
-
3. 메시지 브로커를 쓰면 좋은 점
3-1. 내결함성 (Reliability)
메시지를 유실 없이, 한 번만 처리하도록 보장하는 특성이 중요하다.
-
ACK (Acknowledgement)
- 컨슈머가 “메시지 처리 완료”라고 브로커에 알려주는 신호
- 브로커는 ACK를 받으면 해당 메시지를 안전하게 삭제
-
NACK (Negative Acknowledgement)
- 처리 실패 시 “처리 못 했다”고 브로커에 알림
- 브로커는 메시지를 다시 보내거나, 재시도 대기 상태로 두는 식으로 처리
예시 흐름:
- 이메일 발송 컨슈머가 큐에서 메시지를 가져감
- 이메일 발송 성공 → ACK → 브로커가 메시지 삭제
- 이메일 서버 오류로 실패 → NACK → 브로커가 나중에 다시 전달
3-2. 로드 레벨링 (Load Leveling)
트래픽이 한 번에 몰려도 큐에 버퍼링해 두고 순차적으로 처리하면서 서버 과부하를 막는 패턴이다.
- 갑자기 요청이 수천 개 몰려도, 웹 서버는 일단 큐에 메시지를 넣고 빠르게 응답
- 실제 무거운 작업은 컨슈머들이 큐에서 메시지를 하나씩 가져가면서 처리
- 시스템이 일정한 속도로 안정적으로 처리할 수 있게 만들어 준다
예:
- 명절 이벤트로 쇼핑몰 주문 폭주
- 주문 요청을 큐에 쌓아두고, 백엔드 워커들이 순차적으로 처리
- 웹 서버는 다운되지 않고 응답 유지
3-3. 확장성 (Scalability)
- 컨슈머 인스턴스를 수평으로 늘리기만 해도 처리량이 같이 올라간다.
- 큐는 하나여도, 그 큐를 바라보는 컨슈머가 10개면 최대 10개 작업을 동시에 처리 가능
- 서비스 중단 없이 워커만 늘렸다 줄였다 할 수 있어서 확장성이 좋다
예:
- 이미지 처리 작업이 폭주하면 컨슈머를 1개에서 10개로 늘려서 처리 속도를 올림
- 작업량이 줄면 다시 10 → 2로 줄이는 것도 가능
3-4. 서비스 간 결합도 감소 (장애 전파 방지)
동기 호출 구조:
- A 서비스가 B 서비스에 HTTP 요청
- B가 죽어 있으면 A도 응답을 못 하고 장애 전파
메시지 브로커 기반 비동기 구조:
- A가 B에게 직접 요청하지 않고, 브로커에 메시지를 넣고 바로 반환
- B는 나중에 큐에서 메시지를 꺼내 처리
- B가 잠시 죽어 있어도 메시지는 브로커에 남아 있음
- 복구 후 다시 처리하면 되므로, A는 영향을 안 받는다
예:
- 주문 서비스가 “주문 생성” 메시지를 브로커에 발행
- 배송 서비스가 잠깐 내려가 있어도 메시지는 큐에 쌓여 있다가
- 배송 서비스가 살아나면 그때부터 처리 재개
4. 대표 메시지 브로커 비교
4-1. RabbitMQ vs Kafka 핵심 비교
| 항목 | RabbitMQ | Kafka |
|---|---|---|
| 기반 프로토콜 | AMQP | 자체 프로토콜 (Kafka Protocol) |
| 전송 방식 | Push (브로커 → 컨슈머) | Pull (컨슈머 → 브로커) |
| 저장 구조 | 큐에 저장 후 보통 소비하면 삭제 | 디스크 로그에 append-only로 저장, 기본적으로 보존 |
| 처리 철학 | 메시지를 안전하게 전달하고 라우팅하는 데 초점 | 대용량 스트리밍 로그를 안정적으로 저장·처리하는 데 초점 |
| 강점 | 낮은 지연, 유연한 라우팅, 전통적인 MQ 패턴 | 대용량 처리, 확장성, 재처리/복구에 강함 |
| 적합한 용도 | 결제 흐름, 업무 이벤트, 실시간 알림, MSA 메시징 | 로그 수집, 실시간 분석, IoT, 이벤트 스트리밍, 데이터 파이프라인 |
요약:
-
RabbitMQ
- 복잡한 라우팅, 빠른 응답, 전통적인 메시지 큐 패턴이 필요할 때 선택
-
Kafka
- “많은 양의 이벤트/로그를 저장 + 스트리밍 처리”해야 할 때 최적
4-2. 그 밖의 브로커들
ActiveMQ
- JMS(Java Message Service) 기반
- 다양한 프로토콜 지원, Java 레거시 환경과 잘 맞는다
- 기존 JMS 기반 프로젝트를 마이그레이션할 때 자주 등장
AWS SQS
- AWS에서 제공하는 완전관리형 큐 서비스
- 서버 설치 없이 바로 사용 가능
- 자동 확장, 지연 큐, FIFO 큐 지원
- 클라우드 환경에서 빠르게 큐 기반 아키텍처를 구성할 때 유용
5. 메시지 브로커 활용 사례 모음
5-1. MSA 간 통신
-
마이크로서비스끼리 REST로만 직접 통신하면 결합도가 높아지고 장애 전파가 심해진다.
-
메시지 브로커를 사이에 두면
- 서비스끼리 서로를 몰라도 되고
- 장애 전파를 크게 줄일 수 있다.
예:
- 주문 서비스가 “주문 생성 이벤트” 발행
- 재고 서비스, 배송 서비스, 알림 서비스가 각각 구독해서 독립적으로 처리
- 특정 서비스 하나가 죽어도 나머지는 영향 없이 동작
5-2. 트래픽 폭주 대응
- 피크 시간에 들어온 요청을 큐에 쌓고, 백엔드가 순차적으로 처리
- 웹 서버는 빨리 응답만 주고, 무거운 작업은 워커들이 나중에 처리
예:
- 대규모 할인 이벤트 시 결제/주문 요청이 폭주
- 웹 서버는 주문 생성 메시지를 큐에 넣고 바로 200 응답
- 백엔드 워커들이 큐에서 메시지를 가져가면서 순차 처리
5-3. 사용자 응답 속도 개선
- 오래 걸리는 작업을 비동기 메시지로 분리하면 사용자는 빠르게 응답을 받을 수 있다.
예:
-
회원가입 시
- DB에 유저 정보 저장 → 즉시 “가입 완료” 응답
- 인증 메일 발송은 큐에 메시지 넣고 비동기 처리
5-4. 실시간 기능 (SSE, 채팅, 알림 등)
서버를 여러 대로 수평 확장하면
- A는 서버1에 연결
- B는 서버2에 연결
하는 식으로 나뉘기 때문에, 서버끼리 메시지를 공유해야 한다.
이때 Pub/Sub 기반 메시지 브로커가 중간에서 서버 간 메시지를 전달해 준다.
예:
- A가 채팅 메시지를 Kafka/Redis Pub/Sub에 발행
- 서버1, 서버2 모두 이 채널을 구독
- 서버2에 붙어 있는 B도 A의 메시지를 실시간으로 수신
5-5. 로그 및 모니터링 이벤트 수집
-
각 서비스에서 발생하는 이벤트/로그를 브로커로 모아서
- ELK (Logstash → Elasticsearch → Kibana)
- 모니터링 시스템
과 연동하는 구조를 많이 쓴다.
예:
- Kafka에 서비스 로그를 쌓고
- Logstash가 Kafka에서 읽어와 Elasticsearch에 저장
- Kibana에서 검색·시각화
5-6. 지연 처리 (Delay Queue)
- 지연 큐를 사용하면 “지금 말고, 일정 시간이 지난 후에 처리”도 가능하다.
예:
-
비밀번호 변경 안내 메일을 10분 뒤에 보내고 싶을 때
-
RabbitMQ의 TTL + Dead Letter Exchange 패턴으로
- 메시지를 일정 시간 동안 보관했다가
- 만료 시 다른 큐로 옮겨서 처리하는 구조 구현 가능
마무리
요약하면:
- 메시지 브로커는 서비스 간 비동기 통신 + 버퍼링 + 신뢰성을 책임지는 중간 계층이다.
- RabbitMQ는 전통적인 메시지 큐, 복잡한 라우팅·실시간 이벤트 처리에 잘 맞고
- Kafka는 대량 이벤트 스트림, 로그·분석·데이터 파이프라인에 최적화되어 있다.
- MSA, 트래픽 폭주, 실시간 기능, 로그 수집, 지연 처리 등에서 쓰면 구조가 훨씬 깔끔해진다.
프로젝트에서 동기 REST 호출만으로 한계가 보이기 시작한다면,
어디에 메시지 브로커를 끼워 넣을 수 있을지 한 번씩 그려 보는 게 좋다.
개발자 희망자