RabbitMQ에 대해 알아보자 - (2) RabbitMQ vs Kafka

들어가기 앞서

RabbitMQ와 Kafka의 차이에 대해 알아 보려고 합니다. 저는 현업에서 Kafka만 사용해 보아서, 두개의 차이에 대해 정확히 알지 못 합니다. 이번 글에서는 RabbitMQ 위주로 간단하게 정리하고, 차근차근 Kafka까지 깊게 공부해 가며, 두 기술의 차이에 대해 알아볼 예정입니다. 

---

Kafka vs RabbitMQ: 메시지 브로커의 두 축, 언제 어떤 선택을 할 것인가?

1. 개요 및 철학적 차이

항목	Kafka	RabbitMQ
설계 철학	분산 로그 기반의 고성능 스트리밍 플랫폼	클래식 메시지 브로커 + AMQP 기반 라우팅
용도	데이터 스트리밍, 이벤트 소싱, 로그 저장 등	작업 큐, 이벤트 전달, 비동기 메시징 등
메시지 흐름	Append-only log 저장, 컨슈머는 offset 기반으로 읽음	메시지는 큐에 들어가면 소비되고 삭제됨

 

Kafka는 “데이터는 언제든 다시 읽을 수 있다”는 전제로 설계된 반면, RabbitMQ는 “한 번 처리된 메시지는 삭제된다”는 단순하고 명확한 흐름을 가진다.

 

 

2. 메시징 모델 및 라우팅 구조

항목	Kafka	RabbitMQ
라우팅 방식	토픽-파티션 구조 (정적 라우팅)	Exchange → Queue 라우팅 (동적 라우팅 가능)
라우팅 유연성	제한적 (Key → 파티션 해시 기반)	매우 유연 (fanout, topic, headers 등)
메시지 유지	로그 형태로 저장 (보존 기간 설정 가능)	기본적으로 소비 시 삭제 (durable 설정 가능)

 

RabbitMQ의 AMQP 모델은 Exchange, Queue, Binding이라는 3단계 라우팅 구조로 유연한 이벤트 분배를 제공하며, Kafka는 토픽 → 파티션이라는 구조적 단순성을 무기로 고성능을 추구한다.

 

 

RabbitMQ는 AMQP 프로토콜을 기반으로 매우 유연한 메시지 라우팅 구조를 제공한다. AMQP의 핵심 라우팅 모델은 다음과 같은 구성 요소로 이루어진다:

• Exchange: Publisher로부터 수신한 메시지를 하나 이상의 큐로 라우팅하는 역할을 수행하며, 메시지의 라우팅 방식에 따라 Direct, Fanout, Topic, Headers 타입으로 구분된다.
• Queue: 메시지가 실제로 저장되는 버퍼 역할의 공간으로, Consumer가 메시지를 받아가는 위치이다. 디스크 혹은 메모리에 저장 가능하며, 지속성 여부(durable)도 설정할 수 있다.
• Binding: Exchange와 Queue 사이의 연결 설정이다. 어떤 큐에 어떤 조건으로 메시지를 보낼지 라우팅 룰을 지정하는 개념이며, 여러 개의 큐가 하나의 Exchange에 바인딩되거나, 하나의 큐가 여러 Exchange에 바인딩될 수 있다.
• Routing Key: 메시지가 어떤 큐로 전달될지를 결정하는 기준이 되는 가상 주소 역할을 한다. Publisher는 메시지 헤더에 routing key를 지정해 메시지를 발행하고, Exchange는 이 키와 Binding 정보를 기반으로 라우팅을 수행한다.

 

1. Producer는 메시지를 발행하며, 메시지에는 routing key가 포함된다.
2. 메시지는 Exchange에 도달하고, 설정된 Binding에 따라 하나 이상의 Queue로 라우팅된다.
3. 각 Queue는 Consumer에 의해 구독되고, 큐에 쌓인 메시지는 하나씩 소비된다.

 

3. 전달 보장 및 내결함성

항목	Kafka	RabbitMQ
메시지 중복 방지	Producer Idempotency 및 Transaction 지원	수동 ack와 재시도 설정으로 처리
메시지 보존	디스크에 저장, 복제 가능 (ISR)	큐 기반, HA queue 또는 quorum queue 설정 필요
Exactly-once	Kafka Streams 또는 트랜잭션 사용 시 지원	기본 지원 안 됨, 별도 구현 필요

 

Kafka는 높은 쓰기 처리량을 가지면서도 고가용성을 위해 Replication (ISR 구조)를 기본으로 한다. 반면 RabbitMQ는 다양한 queue 유형 (classic, quorum 등)으로 장애 대비 구조를 선택할 수 있다.

 

 

4. 성능 및 확장성

항목	Kafka	RabbitMQ
Throughput	매우 높음 (디스크 기반인데도 수백만 TPS)	중간~높음 (메모리 중심 구조)
Latency	낮음 (batch 처리 기반)	매우 낮음 (단건 처리에 최적화)
확장성	분산 아키텍처, Broker 수평 확장 용이	클러스터 구성은 가능하나 복잡도 높음

 

Kafka는 broker/node 수 증가에 따라 성능이 선형에 가깝게 증가하며, 메시지 파티셔닝으로 수평 확장이 쉽다. RabbitMQ는 네트워크 파티션이나 메시지 복제 동기화 시 latency 증가가 우려될 수 있다.

 

 

5. 운영 및 관리

항목	Kafka	RabbitMQ
운영 복잡도	Zookeeper/KRaft 운영 필요, broker 간 설정 주의	단순하지만 클러스터, HA 구성은 숙련 필요
모니터링	JMX, Prometheus, Control Center 등	웹 UI (15672), CLI, Prometheus exporter
메시지 추적	메시지를 오랫동안 보존하며 추적 가능	큐에 남아있는 동안만 추적 가능

 

Kafka는 offset 단위로 메시지 재처리가 쉬운 반면, RabbitMQ는 ack 누락 또는 중복 발생 시 추적이 어렵고 재처리를 위한 아키텍처가 필요하다.

 

 

6. 서비스 적용 시 고려할 점

Kafka를 선택해야 할 경우

• 스트리밍 처리, 로그 수집, 대량 이벤트 분석 (예: 로그 수집기, CDC, 실시간 분석 파이프라인)
• 메시지의 순서 유지와 재처리 중요
• 처리량 > 응답 시간

RabbitMQ를 선택해야 할 경우

• 동기 API 호출을 비동기로 전환할 때 (예: 주문/결제/알림 처리 큐)
• 유연한 라우팅이 필요한 경우
• 단건 응답 속도와 즉시성이 중요할 때

 

7. 마무리 정리

RabbitMQ의 경우 실제로 Kafka와 조금 비슷한 부분도 있고 다른 부분도 있는데요, RabbitMQ의 가장 큰 특징은 메시지 라우팅 키를 통해 메시지 라우팅을 지원하는 점입니다. 주키퍼(Zookeeper) 같은 코디네이터가 별도로 없으면서 토픽 대신에 익스체인지와 Queue의 바인딩을 통해서 메시지를 소비할 수 있다는 점입니다.

 

Kafka는 대용량의 분산 로그 트래픽을 처리한다는 점에서 유리하다면, RabbitMQ는 높은 처리량보다는 지정된 수신인에게 원하는 방식으로 메시징을 신뢰성 있게 전달하는데 초점이 맞춰져 있습니다. 그래서 RabbitMQ 경우에는 대용량 트래픽에는 조금 불리한 점이 있는 대신 익스체인지 타입이나 라우팅 정책에 따라서 동작 방식을 선택할 수가 있는 장점이 있습니다. 

 

Kafka는 이벤트 소싱과 스트리밍 중심의 데이터 흐름,
RabbitMQ는 유연하고 신속한 비동기 작업 처리에 적합하다.

 

출처 : 카카오 테크 블로그