Kafka vs RabbitMQ – 메시지 큐 선택 가이드

백엔드 시스템을 설계하다 보면 반드시 마주치는 질문이 있습니다. “Kafka와 RabbitMQ 중 무엇을 써야 할까?” 둘 다 메시지 브로커라고 불리지만, 내부 동작 방식과 강점이 완전히 다릅니다. 잘못 선택하면 성능 병목이나 운영 부담으로 이어지므로, 구조적 차이를 제대로 이해하고 결정해야 합니다. 이 글에서는 두 기술의 핵심 차이를 개념부터 실전 선택 기준까지 단계별로 정리합니다.

목차

1. 메시지 큐란 무엇인가 – 기초 개념 정리
2. Kafka와 RabbitMQ의 핵심 구조 차이
3. 성능과 확장성 – Kafka가 빛나는 순간
4. 유연한 라우팅과 신뢰성 – RabbitMQ의 강점
5. 실전 사용 사례별 선택 가이드
6. 도입 전 체크리스트 – 전문가 관점과 추천 도구

1. 메시지 큐란 무엇인가 – 기초 개념 정리

메시지 큐의 역할

시스템 A가 시스템 B에게 데이터를 직접 전달하는 구조는 단순해 보이지만, B가 잠깐 다운되거나 느려지면 A까지 멈춥니다. 이 문제를 해결하기 위해 등장한 것이 **메시지 큐(Message Queue)**입니다. 메시지 큐는 발신자(Producer)와 수신자(Consumer) 사이에서 데이터를 임시로 저장하고, 수신자가 준비됐을 때 안전하게 전달하는 중간 버퍼 역할을 합니다.

택배에 비유하면 이해하기 쉽습니다. 발신자는 물건을 택배 터미널(메시지 큐)에 맡기고, 수신자는 자신이 받을 준비가 됐을 때 찾아가는 구조입니다. 발신자와 수신자가 동시에 온라인일 필요가 없으므로 시스템 간 결합도를 낮추고 장애 전파를 막을 수 있습니다.

메시지 브로커는 이 큐를 관리하는 소프트웨어 전체를 가리키며, 대표적인 구현체가 바로 Apache Kafka와 RabbitMQ입니다.

두 기술의 탄생 배경

Kafka는 하루 수천억 건의 로그를 처리해야 했던 LinkedIn의 필요에서 탄생했습니다. 반면 RabbitMQ는 엔터프라이즈 환경에서 신뢰성 높은 메시지 전달을 위해 설계된, 보다 전통적인 메시지 브로커입니다. 출발점이 다르기 때문에 강점도 다릅니다.

2. Kafka와 RabbitMQ의 핵심 구조 차이

메시지 저장 방식 – 로그 vs 큐

Kafka와 RabbitMQ의 가장 근본적인 차이는 메시지를 어떻게 저장하고 소비하느냐입니다.

Kafka: 분산 로그(Distributed Log) 방식

Kafka는 메시지를 토픽(Topic) 안에 순서대로 기록(append)하고, 디스크에 영속적으로 저장합니다. 소비자는 자신이 어디까지 읽었는지 **오프셋(Offset)**으로 관리하며, 메시지를 읽어도 삭제되지 않습니다. 설정한 보존 기간(예: 7일) 동안 메시지가 남아 있어, 여러 컨슈머 그룹이 동일 메시지를 독립적으로 재소비할 수 있습니다.

[Producer] → Topic (Partition 0) : [msg1][msg2][msg3][msg4]...
                                          ↑            ↑
                               Consumer Group A   Consumer Group B
                               (Offset: 2)        (Offset: 4)

RabbitMQ: 전통적 큐(Queue) 방식

RabbitMQ는 메시지를 Exchange → Queue 경로로 라우팅하고, 소비자가 메시지를 가져가면(ack) 큐에서 삭제됩니다. 메시지는 기본적으로 한 번만 소비되며, 소비가 완료된 메시지는 사라집니다.

[Producer] → Exchange → Queue A → [Consumer 1]  (메시지 소비 후 삭제)
                      → Queue B → [Consumer 2]

이 구조적 차이가 성능, 확장성, 유연성 전반에 영향을 미칩니다.

전송 보장 모델 비교

3. 성능과 확장성 – Kafka가 빛나는 순간

대용량 처리에서 Kafka가 압도적인 이유

Kafka는 초당 수십만~수백만 건의 메시지를 처리할 수 있도록 설계됐습니다. 이 성능의 핵심은 세 가지 구조적 특성에 있습니다.

① 파티션 기반 수평 확장 토픽은 여러 **파티션(Partition)**으로 분할되고, 각 파티션은 서로 다른 브로커 서버에 분산 저장됩니다. 처리량이 부족하면 파티션 수를 늘리고 브로커를 추가하면 되므로, 거의 선형적으로 확장이 가능합니다.

② 순차 I/O와 배치 처리 Kafka는 메시지를 디스크에 순차적으로 기록합니다. 랜덤 I/O보다 순차 I/O가 훨씬 빠르기 때문에, 물리 디스크에 저장함에도 불구하고 높은 처리 속도를 유지합니다. 또한 프로듀서와 컨슈머 모두 메시지를 배치 단위로 처리해 네트워크 오버헤드를 줄입니다.

③ Zero-Copy 전송 Kafka는 OS의 sendfile() 시스템 콜을 활용해 데이터를 메모리에 복사하지 않고 디스크→네트워크로 직접 전송합니다. CPU 사용률이 낮아지고 처리 속도가 크게 향상됩니다.

[일반 방식]    디스크 → 커널 버퍼 → 사용자 공간 → 소켓 버퍼 → 네트워크
[Zero-Copy]   디스크 → 커널 버퍼 ────────────────────────→ 네트워크

Kafka가 빛나는 대표 시나리오

• 실시간 로그 집계: 수십 개 서버의 로그를 Kafka로 수집 → Elasticsearch/S3 적재
• 이벤트 소싱(Event Sourcing): 모든 상태 변경을 이벤트로 기록하고 재현
• 스트리밍 분석: Kafka Streams / Apache Flink와 연계한 실시간 집계
• 데이터 파이프라인: 여러 시스템이 동일 이벤트를 각자 소비 (예: 주문 이벤트 → 재고 서비스, 알림 서비스, 분석 서비스 동시 처리)

4. 유연한 라우팅과 신뢰성 – RabbitMQ의 강점

Exchange 라우팅 – RabbitMQ의 핵심 기능

RabbitMQ의 가장 큰 강점은 Exchange 타입을 활용한 정교한 메시지 라우팅입니다. 프로듀서는 큐에 직접 메시지를 보내지 않고 Exchange에 전달하며, Exchange가 규칙에 따라 적절한 큐로 분배합니다.

[Producer] → Topic Exchange (라우팅 키: "order.paid")
               ├── "order.*"  → Queue: 주문팀 알림
               ├── "*.paid"   → Queue: 결제팀 처리
               └── "#"        → Queue: 전체 감사 로그

이런 유연성 덕분에 RabbitMQ는 복잡한 워크플로우를 메시지 라우팅만으로 구현할 수 있습니다.

RabbitMQ가 빛나는 시나리오

① 작업 큐(Work Queue) 패턴 여러 워커(Consumer)가 큐의 작업을 나눠서 처리하는 패턴에 최적화돼 있습니다. 이미지 리사이징, 이메일 발송, PDF 변환처럼 CPU 집약적인 백그라운드 작업을 분산 처리할 때 탁월합니다.

② 요청-응답(RPC) 패턴 reply_to 속성과 임시 큐를 활용해 동기식 RPC 패턴을 쉽게 구현할 수 있습니다. 마이크로서비스 간 동기 통신이 필요한 경우에 유용합니다.

③ 우선순위 메시지와 Dead Letter Queue 긴급 메시지를 일반 메시지보다 먼저 처리하는 우선순위 큐를 기본 지원합니다. 처리 실패한 메시지는 자동으로 **Dead Letter Exchange(DLX)**로 이동시켜 재처리하거나 분석할 수 있습니다.

5. 실전 사용 사례별 선택 가이드

언제 Kafka를 선택해야 하는가

아래 조건 중 2개 이상 해당하면 Kafka가 더 적합합니다.

✅ 초당 10만 건 이상의 메시지를 처리해야 한다
✅ 같은 메시지를 여러 서비스가 독립적으로 소비해야 한다
✅ 메시지를 나중에 다시 재처리(리플레이)해야 한다
✅ 실시간 스트리밍 분석 파이프라인이 필요하다
✅ 데이터 보존 기간이 며칠~몇 달 이상 필요하다
✅ 이벤트 소싱 또는 CQRS 패턴을 구현한다

대표 도입 사례: 넷플릭스(실시간 모니터링), 우버(위치 데이터 스트리밍), 라인(메시지 처리)

언제 RabbitMQ를 선택해야 하는가

아래 조건 중 2개 이상 해당하면 RabbitMQ가 더 적합합니다.

✅ 복잡한 라우팅 규칙이 필요하다 (Topic/Headers Exchange)
✅ 메시지 처리 실패 시 자동 재시도·DLQ가 필요하다
✅ 우선순위 큐가 필요하다
✅ 마이크로서비스 간 RPC 패턴을 구현한다
✅ 처리량보다 개별 메시지의 신뢰성이 더 중요하다
✅ 팀이 AMQP 표준에 익숙하거나 레거시와 호환이 필요하다

대표 도입 사례: 결제 시스템, 이메일 발송 큐, 작업 스케줄러

핵심 비교 요약표

6. 도입 전 체크리스트 – 전문가 관점과 추천 도구

도입 결정 전 반드시 확인할 5가지

① 메시지 처리량(Throughput) 요구사항 측정 실제 피크 타임 기준으로 초당 메시지 수를 추산하세요. 수천 건 수준이라면 RabbitMQ로 충분합니다. 수십만 건을 넘어간다면 Kafka를 고려해야 합니다.

② 소비 패턴 분석 동일 이벤트를 여러 시스템이 각자 독립적으로 처리해야 한다면 Kafka의 컨슈머 그룹 모델이 유리합니다. 단순히 작업을 분산 처리하는 것이라면 RabbitMQ의 경쟁 소비자(Competing Consumers) 패턴으로 충분합니다.

③ 팀의 운영 역량 고려 Kafka는 클러스터 구성, 파티션 설계, 오프셋 관리 등 학습 곡선이 가파릅니다. 소규모 팀이나 빠른 도입이 필요한 경우 RabbitMQ가 현실적인 선택일 수 있습니다.

④ 인프라 비용 계산 Kafka는 디스크에 메시지를 보존하므로 저장 공간 비용이 발생합니다. 또한 고가용성을 위해 최소 3개 브로커가 필요합니다. 클라우드 매니지드 서비스(MSK, Confluent Cloud, CloudAMQP)를 활용하면 운영 부담을 줄일 수 있습니다.

⑤ 함께 사용하는 것도 전략 실제 대규모 시스템에서는 Kafka와 RabbitMQ를 역할 분담하여 함께 사용하는 경우도 많습니다.

[서비스 이벤트] → Kafka (실시간 스트리밍, 로그 수집)
                       ↓
              [이벤트 처리 서비스]
                       ↓
              RabbitMQ (개별 작업 큐, 이메일/SMS 발송)

추천 관리 도구 및 생태계

결론

Kafka와 RabbitMQ 차이는 단순히 기능 목록의 차이가 아니라, 메시지를 어떻게 저장하고 소비하느냐라는 철학의 차이입니다. Kafka는 대용량 이벤트 스트림을 영속적으로 기록하고 여러 컨슈머가 재소비할 수 있도록 설계된 플랫폼이고, RabbitMQ는 복잡한 라우팅과 신뢰성 있는 개별 메시지 전달에 특화된 브로커입니다. 처리량과 재소비가 중요하다면 Kafka를, 라우팅 유연성과 빠른 도입이 필요하다면 RabbitMQ를 선택하세요. 지금 바로 팀의 요구사항을 체크리스트에 대입해 보고, 최적의 메시지 브로커를 결정해 보시기 바랍니다.

⚠️ 면책 고지: 본 글은 기술 정보 제공을 목적으로 작성된 참고 자료입니다. 실제 시스템 아키텍처 결정은 팀의 기술 역량, 인프라 예산, 서비스 규모 등 구체적인 요구사항을 종합하여 판단하시기 바랍니다. 특정 기술 도입으로 인한 장애·손실에 대해 본 블로그는 책임을 지지 않습니다.