Skip to main content
주문 서비스가 배송 서비스를 직접 부르지 않았는데도, 잠시 뒤 배송 준비가 시작될 수 있어요.
처음에는 조금 이상하게 느껴지죠? 보통 코드는 한 객체가 다른 객체의 메서드를 호출하거나, 한 서버가 다른 서버에 HTTP 요청을 보내는 모습으로 시작해요. 그런데 시스템이 커지면 상대가 잠시 느리거나 멈추더라도 지금 할 일을 먼저 넘겨두고 싶을 때가 생겨요. 이때 중간에서 메시지를 받아 보관하고 전달하는 **메시지 브로커(message broker)**가 등장해요. 근데요, Kafka와 RabbitMQ는 둘 다 메시지 브로커로 불리지만 메시지를 바라보는 중심이 같지는 않아요. 이름부터 비교하기보다, 먼저 “메시지를 왜 직접 전달하지 않을까?”를 이해하고 각 제품이 무엇을 중심으로 움직이는지 따로 보는 편이 덜 헷갈려요.

먼저 공통 그림부터 잡아볼게요

카페에서 주문한 사람이 주방 문을 열고 요리사에게 직접 부탁하지는 않잖아요. 주문표를 남기면 주방은 자기 속도에 맞춰 주문을 확인하고 처리해요. 이 비유에서 중요한 것은 “중간에 주문표가 있다”는 점이에요. 보내는 쪽과 처리하는 쪽이 같은 순간에 움직이지 않아도 되지만, 그 대신 주문표가 늦게 처리되거나 다시 전달되거나 처리하지 못한 채 쌓이는 상황도 함께 관리해야 해요. 메시지 브로커를 사이에 두면 “보내기 성공”과 “업무 처리 성공”이 서로 다른 사건이 돼요. 이 차이가 중복 전달, 재시도, 순서, 장애 복구를 이해하는 출발점이에요.

Kafka와 RabbitMQ는 따로 시작하는 편이 좋아요

두 제품을 처음부터 기능표로 비교하면 topic, partition, exchange, queue 같은 낯선 단어만 한꺼번에 늘어나기 쉬워요. 먼저 각 제품 안에서 메시지 하나가 지나가는 길을 끝까지 따라가 보세요.

Kafka를 볼 때 붙잡을 질문

Kafka에서는 메시지가 topic의 partition에 이어지는 기록으로 놓이고, consumer group이 어디까지 읽었는지를 따라가는 그림이 중요해요.
  • Topic과 partition은 왜 나뉠까요?
  • 같은 key를 가진 record는 어느 partition으로 갈까요?
  • Consumer group과 offset은 무엇을 기억할까요?
  • 이미 읽은 record를 왜 다시 읽을 수 있을까요?
  • 처리량을 늘릴 때 partition 수가 왜 중요할까요?
Kafka가 왜 전달보다 기록을 중심에 두는지부터 보고 싶다면 Kafka 읽기 안내에서 시작해보세요.

RabbitMQ를 볼 때 붙잡을 질문

RabbitMQ에서는 publisher가 보낸 메시지를 exchange가 규칙에 따라 queue로 routing하고, consumer가 queue의 메시지를 처리하는 그림이 중요해요.
  • Publisher는 왜 queue가 아니라 exchange로 보낼까요?
  • Exchange, binding, routing key는 어떻게 목적지를 정할까요?
  • 하나의 메시지를 여러 queue로 보내려면 무엇이 필요할까요?
  • Acknowledgement와 redelivery는 언제 생길까요?
  • Consumer 수와 prefetch는 처리 흐름을 어떻게 바꿀까요?
처음에는 Kafka를 “무조건 이벤트용”, RabbitMQ를 “무조건 작업용”처럼 외우지 않는 편이 좋아요. 각자의 기본 전달 구조를 이해한 다음, 보관과 다시 읽기, routing, 처리량, 순서, 운영 방식이 현재 문제에 어떤 영향을 주는지 비교해야 해요.

이런 순서로 읽으면 덜 헷갈려요

Kafka와 RabbitMQ 중 하나만 사용할 예정이어도 공통 기초를 먼저 잡는 것이 좋아요. 그다음 선택한 제품의 내부 흐름을 익히고, 마지막에 framework 코드를 연결하면 Annotation이나 설정 뒤에서 broker가 무엇을 하는지 보이기 시작해요. 이미 두 제품의 기본 구조가 익숙하고 Spring Boot에서 연결하는 방법이 궁금하다면 Kafka와 RabbitMQ는 event를 어떻게 다르게 전달할까요?로 이어가도 좋아요.

자, 정리해볼까요?

  • 메시징은 producer와 consumer 사이에 broker를 두면서 보내기와 처리의 시간을 분리하는 방법이에요.
  • Kafka는 topic, partition, consumer group, offset이 만드는 기록과 읽기 흐름부터 살펴봐요.
  • RabbitMQ는 exchange, binding, routing key, queue가 만드는 전달 경로부터 살펴봐요.
  • 각 제품의 기본 구조를 이해한 뒤에 중복 전달, retry, dead-letter, 순서 같은 공통 운영 문제를 연결해요.
  • Framework 코드는 마지막에 붙여야 자동 설정 뒤에서 실제로 움직이는 구조를 놓치지 않아요.