RabbitMQ vs Kafka, 언제 무엇을 사용해야 하는지 정리한다

RabbitMQ vs Kafka를 검색하면 비슷한 글이 200개쯤 쏟아지지만, 다 읽어봐도 결국 "둘 다 메시징 시스템인데 다르다"는 한 줄로 귀결된다. 그러나 현업에서 두 시스템을 모두 운영해본 입장에서는 그렇게 단순히 정리될 사안이 아니다. 같은 카테고리의 도구가 아닌데도 자꾸 비교 대상이 되는 이유, 그리고 진정 언제 무엇을 사용해야 하는지를 본 글에서 정리한다. 2025년 기준 최신 정보를 모두 반영했고, 옛 글에서 자주 언급되는 잘못된 통설도 함께 짚는다.

 

RabbitMQ vs Kafka, 두 시스템은 같은 카테고리의 도구가 아니다

 

 

출처: slideshare.net

 

먼저 못 박고 시작하자. RabbitMQ는 메시지 큐(Message Queue)이고, Kafka는 분산 로그(Distributed Log) 또는 스트리밍 플랫폼이다. 한 줄로 요약하면 다음과 같다.

 

메시지를 "전달하고 잊을" 것이라면 RabbitMQ, 메시지를 "쌓아두고 다시 읽을" 것이라면 Kafka이다.

 

다만 왜 자꾸 같이 비교당하는가? 두 시스템 모두 비동기 메시징이라는 큰 카테고리 안에 속하고, 사용처가 일부 겹치기 때문이다. 예컨대 "주문이 들어왔을 때 알림을 발송"하는 케이스는 양쪽 모두로 구현 가능하다. 그래서 입문자 입장에서는 두 시스템이 비슷해 보인다.

 

그러나 조금만 들여다보면 완전히 다르다. RabbitMQ는 라우팅 로직이 정교한 우체국과 같고, Kafka는 모든 사건을 시간 순으로 적어두는 거대한 로그북에 가깝다. 우체국에 "지난주 화요일 편지를 다시 보여달라"고 요청하면 불가능하다. 그러나 Kafka에서는 가능하다.

 

이 차이를 모른 채 잘못된 도구를 고르면 6개월 뒤에 갈아엎게 된다. 실제 사례가 적지 않다.

 

RabbitMQ란 무엇인가 - 핵심 구조를 빠르게 살펴본다

 

 

출처: cloudamqp.com

 

AMQP 프로토콜과 Erlang 기반 구조

 

RabbitMQ는 AMQP 0-9-1(Advanced Message Queuing Protocol) 표준을 구현한 메시지 브로커이다. 2007년에 등장했고 현재 4.x 버전이다. Erlang/OTP로 구현되어 있는데, 이 언어가 분산 시스템에 강한 특성을 지녀 메시징에 매우 잘 어울린다. 결함 격리(fault isolation)가 언어 차원에서 지원된다.

 

RabbitMQ 공식 문서에 따르면 전 세계 수만 개 회사에서 사용 중이며, 한국에서도 카카오, 토스, 우아한형제들 같은 곳에서 운영한다. "스타트업이나 작은 서비스용"이라는 오해가 있으나 사실이 아니다.

 

익스체인지-큐-바인딩 모델

 

RabbitMQ의 가장 큰 특징은 라우팅 유연성이다. 메시지가 큐로 직접 들어가는 것이 아니라 익스체인지(Exchange)를 거쳐 라우팅 룰에 따라 큐로 분배된다. 익스체인지는 4가지 타입을 갖는다.

 

• Direct: 라우팅 키가 정확히 일치하는 큐로 전송한다
• Topic: 와일드카드 패턴(order.*.created)으로 매칭한다
• Fanout: 바인딩된 모든 큐로 복사한다 (브로드캐스트)
• Headers: 헤더 값으로 매칭한다 (거의 사용되지 않는다)

 

이 구조 덕분에 "주문 생성 이벤트는 결제 큐와 알림 큐로 가고, 결제 실패는 재시도 큐로 가고…" 같은 복잡한 라우팅을 코드 한 줄 작성하지 않고 설정만으로 구현할 수 있다. Kafka는 이것이 불가능하다.

 

4.0에서 변경된 점 - Khepri 도입과 Quorum Queue

 

옛 글들은 모두 Mnesia 데이터베이스를 다루지만, 분위기가 바뀌고 있다. RabbitMQ 4.0(2024년 9월 출시)부터 Khepri라는 새로운 데이터스토어가 정식 지원된다. Raft 합의 알고리즘 기반이라 클러스터 분할(network partition) 상황에서 훨씬 안정적이다. 다만 4.0/4.1은 여전히 Mnesia가 기본값이며, 4.2부터 신규 배포의 디폴트가 Khepri로 바뀌었다.

 

또한 Quorum Queue가 4.0부터 기본 큐 타입으로 자리 잡았다. 기존 Classic Mirrored Queue는 3.9에서 deprecated된 후 4.0에서 완전히 제거되었다. Quorum Queue는 Raft 기반 복제로 데이터 손실 위험이 거의 없다. 처리량은 Classic보다 다소 낮지만 내구성이 훨씬 뛰어나다.

 

스트림(Streams) 기능도 추가되었는데, 이는 Kafka를 모방한 것이다. 로그 기반 메시지 보관이 가능하다. 다만 Kafka급 성능은 아니므로 진정한 스트리밍 워크로드에는 그냥 Kafka를 쓰는 편이 낫다.

 

Kafka란 무엇인가 - 분산 로그라는 발상

 

 

출처: storage.googleapis.com

 

토픽-파티션-오프셋 구조

 

Kafka는 LinkedIn이 2011년에 만들어 오픈소스화한 분산 커밋 로그이다. Apache Kafka 공식 문서에 따르면 발상이 RabbitMQ와 완전히 다르다. 메시지를 큐에서 빼는 것이 아니라 로그 파일에 append만 한다. 한 번 기록되면 보관 기간(retention) 동안 그대로 남는다.

 

핵심 개념 3가지는 다음과 같다.

 

• 토픽(Topic): 로그 카테고리이다. RabbitMQ의 큐와 비슷한 위치를 차지한다
• 파티션(Partition): 토픽을 여러 개로 쪼갠 단위이다. 병렬 처리의 핵심이다
• 오프셋(Offset): 파티션 내부에서 메시지 위치를 가리키는 숫자이다

 

컨슈머는 자신이 어디까지 읽었는지를 오프셋으로 기억한다. 그래서 "어제 9시부터 다시 읽어달라" 같은 요청이 가능하다. 이것이 Kafka의 진정 강력한 지점이다.

 

Zookeeper는 더 이상 사용하지 않는다 (KRaft 모드)

 

옛 Kafka 문서를 보면 무조건 Zookeeper를 함께 설치하라고 안내한다. 그러나 이 또한 옛이야기이다. Kafka 2.8부터 KRaft(Kafka Raft) 모드가 도입되었고, 3.3에서 production-ready 상태가 되었다. Kafka 4.0(2025년 출시)부터는 Zookeeper가 완전히 제거되었다.

 

KRaft를 사용하면 운영 복잡도가 확연히 낮아진다. 의존성이 하나 줄어들기 때문이다. 새로 시작하는 프로젝트라면 무조건 KRaft로 가는 것이 옳다.

 

컨슈머 그룹과 리밸런싱

 

Kafka의 또 다른 중요한 개념이 컨슈머 그룹이다. 같은 그룹에 속한 컨슈머들이 파티션을 나누어 가진다. 파티션이 4개이고 컨슈머가 2개라면 컨슈머당 2개씩 가져간다. 컨슈머를 추가하면 자동으로 재분배(리밸런싱)된다.

 

이것이 Kafka의 수평 확장 핵심이다. 처리량이 부족하면 컨슈머를 추가하기만 해도 알아서 분배된다. RabbitMQ도 같은 큐에 컨슈머 여러 개를 붙일 수는 있으나, Kafka처럼 파티션 단위로 명확하게 나뉘지는 않는다.

 

RabbitMQ Kafka 차이 핵심 8가지

 

 

출처: linkedin.com

 

각설하고 진정한 차이점을 정리한다. 표를 먼저 박고 자세한 설명으로 들어간다.

 

항목	RabbitMQ	Kafka
메시지 보관	소비되면 사라진다	보관 기간 동안 유지된다
처리량	~50K msg/sec	~1M msg/sec
지연시간	마이크로초 단위	밀리초 단위
라우팅	Exchange로 정교하다	토픽 기반으로 단순하다
순서 보장	큐 단위	파티션 단위
메시지 크기	작은 메시지에 적합하다	큰 메시지도 가능하다
학습 곡선	완만하다	가파르다
적합한 규모	중소~대규모	대규모

 

메시지 보관 방식 - 큐는 소비되면 사라지고, 로그는 사라지지 않는다

 

가장 본질적인 차이이다. RabbitMQ는 컨슈머가 메시지 ack를 보내면 큐에서 삭제된다. 다시 볼 수 없다. Kafka는 보관 기간(기본 7일, 무한대로도 설정 가능) 동안 그대로 남고, 여러 컨슈머가 같은 메시지를 각자 읽을 수 있다.

 

이 때문에 이벤트 소싱(Event Sourcing)이나 CQRS 패턴은 거의 무조건 Kafka로 가야 한다. 과거 이벤트를 다시 재생할 일이 있기 때문이다.

 

처리량 vs 지연시간 - 누가 진정 빠른가

 

여기서 흔한 오해가 있다. "Kafka가 무조건 빠르다"는 말은 틀렸다. 상황에 따라 다르다.

 

• 처리량(throughput): Kafka가 압도적이다. 초당 100만 건도 가능하다. RabbitMQ는 잘 튜닝해도 5만~10만 건 정도이다.
• 지연시간(latency): 작은 메시지라면 RabbitMQ가 더 빠르다. 마이크로초 단위 응답이 가능하다. Kafka는 배치로 묶어서 보내는 구조라 ms 단위이다.

 

Confluent 벤치마크에 따르면 큰 메시지를 대량으로 처리할 때 Kafka가 RabbitMQ보다 약 15배 빠르다고 한다. 그러나 작은 메시지 1건을 빨리 보내야 하는 케이스라면 RabbitMQ가 낫다.

 

라우팅 유연성 - RabbitMQ가 압도적이다

 

RabbitMQ는 Topic Exchange로 order.kr.seoul, order.us.la 같은 식으로 라우팅 키 패턴 매칭이 가능하다. Kafka는 토픽 단위로만 분리되며, 그 안에서 어디로 갈지는 컨슈머가 알아서 처리해야 한다.

 

복잡한 라우팅 룰이 필요하다면 RabbitMQ가 정답이다. 코드 양 자체가 다르다.

 

메시지 순서 보장 - 파티션 단위 vs 큐 단위

 

RabbitMQ는 큐 단위로 FIFO가 보장된다. 컨슈머가 1개라면 완벽한 순서이다. 여러 개라면 순서가 깨질 수 있다.

 

Kafka는 파티션 단위로 순서가 보장된다. 같은 키를 가진 메시지는 같은 파티션으로 가므로, 그 키 단위의 순서가 보장된다. 예컨대 같은 user_id의 이벤트 순서를 보장하려면 user_id를 파티션 키로 사용하면 된다.

 

장애 복구 - HA Queue vs Replication Factor

 

RabbitMQ는 Quorum Queue로 노드 장애 시 자동 페일오버된다. Kafka는 토픽을 만들 때 replication.factor=3 같이 설정하면 3개 브로커에 복제된다. 한 대가 죽어도 멈추지 않는다.

 

설정을 잘못하면 양쪽 다 데이터 손실이 가능하다. 특히 Kafka에서 acks=0이나 acks=1로 두면 메시지가 사라질 수 있다. "Kafka는 메시지 손실이 없다"는 말은 거짓이다. 설정을 제대로 해야 한다.

 

학습 곡선 - 어느 쪽이 더 까다로운가

 

RabbitMQ는 입문이 매우 쉽다. Docker로 띄우고 5분이면 메시지를 보낼 수 있다. 관리 콘솔(Management UI)도 친절하다.

 

Kafka는 처음 시작하면 답답하다. 토픽을 만들고, 파티션을 정하고, 컨슈머 그룹을 설정하고, 오프셋을 관리하고… 운영 노하우를 쌓으려면 최소 6개월은 잡아야 한다. 그리고 한 번 클러스터를 잘못 설계하면 나중에 갈아엎기가 매우 까다롭다.

 

운영 비용 - CPU/메모리/디스크 차이

 

• 메모리: RabbitMQ가 메모리를 많이 쓴다. 큐가 메모리에 올라가기 때문이다. Kafka는 디스크 위주라 메모리를 덜 쓴다.
• 디스크: Kafka가 디스크를 많이 쓴다. 로그를 보관하기 때문이다. SSD를 추천한다.
• CPU: 양쪽 다 비슷하다. 트래픽에 따라 다르다.

 

규모가 작다면 RabbitMQ가 한 대로 충분하지만, Kafka는 최소 3대 클러스터가 권장된다. 초기 운영 비용은 Kafka가 더 비싸다.

 

생태계 - 클라이언트 라이브러리, 플러그인

 

RabbitMQ는 거의 모든 언어에 공식/비공식 클라이언트가 있다. Kafka도 마찬가지인데, JVM 친화적이라 Java/Scala/Kotlin 쪽이 가장 잘 갖춰져 있다.

 

플러그인은 RabbitMQ가 풍부하다. Shovel, Federation, MQTT, STOMP 모두 지원한다. Kafka는 Kafka Connect, Kafka Streams, ksqlDB 같은 자체 생태계가 강력하다.

 

어떤 상황에서 RabbitMQ가 정답인가

 

작업 큐 (백그라운드 잡, 이메일 발송 등)

 

이메일 발송, 썸네일 생성, PDF 변환 같은 백그라운드 작업은 RabbitMQ가 정답이다. 한 번 처리되면 끝이므로 로그로 보관할 필요가 없다. Celery, Sidekiq 같은 작업 큐 라이브러리도 RabbitMQ를 잘 지원한다.

 

복잡한 라우팅이 필요할 때

 

이벤트 종류별로 다른 컨슈머에게 보내야 하고, 조건부 라우팅 룰이 많고, 우선순위 큐가 필요하다면 RabbitMQ이다. Kafka로 이를 흉내 내려면 코드를 매우 많이 작성해야 한다.

 

RPC 패턴이나 요청-응답 워크플로우

 

RabbitMQ는 RPC 패턴을 기본 지원한다. reply-to 큐를 만들어서 응답을 받는 구조가 자연스럽다. Kafka로는 이 패턴이 매우 번거롭다.

 

메시지가 즉시 처리되어야 하는 케이스

 

지연시간을 ms 이하로 보장해야 한다면 RabbitMQ가 낫다. Kafka는 배치 처리 구조라 약간의 지연이 불가피하다.

 

어떤 상황에서 Kafka가 정답인가

 

이벤트 소싱과 CQRS

 

이벤트를 영구 보관하고 다시 재생할 수 있어야 하는 패턴이라면 무조건 Kafka이다. 과거 이벤트를 모아서 read model을 다시 생성할 수 있어야 하기 때문이다.

 

로그 수집, 메트릭, 분석 파이프라인

 

웹서버 로그, 사용자 행동 데이터, IoT 센서 데이터 같은 것을 모을 때 Kafka가 적합하다. 초당 수십만 건이 들어와도 끄떡없고, Spark, Flink, Kafka Streams로 실시간 분석도 가능하다. 우아한형제들 기술블로그에도 이러한 사례가 많이 등장한다.

 

여러 컨슈머가 같은 데이터를 다시 읽어야 할 때

 

분석팀, 추천팀, 알림팀이 같은 주문 데이터를 각자 다른 방식으로 처리해야 하는 상황이라면 Kafka 컨슈머 그룹으로 깔끔하게 분리된다. 같은 메시지를 여러 그룹이 각자 읽는다.

 

초당 10만 건 이상 처리해야 할 때

 

진정 큰 트래픽이라면 RabbitMQ로는 한계이다. Kafka는 파티션을 늘려 수평 확장이 가능하다. 카카오 광고 플랫폼이나 토스 결제 이벤트 같은 곳에서 Kafka를 쓰는 이유가 여기에 있다.

 

RabbitMQ vs Kafka 비용 비교 - 매니지드 서비스 기준

 

 

출처: vantage.sh

 

자체 운영을 하면 인건비가 매우 크다. 그래서 매니지드 서비스 기준으로 비교한다. 2025년 기준 가격이다.

 

AWS MSK vs Amazon MQ 가격

 

• Amazon MQ for RabbitMQ: mq.t3.micro 기준 시간당 약 $0.04이다. 월 $30 수준이다.
• AWS MSK: kafka.t3.small 기준 시간당 약 $0.05 + 스토리지이다. 월 $40~$50 + 데이터 비용이다.

 

작은 규모라면 비슷하고, 커질수록 Kafka가 더 비싸진다. 클러스터 최소 3대이기 때문이다.

 

Confluent Cloud vs CloudAMQP

 

• Confluent Cloud: Basic 클러스터는 베이스 요금이 없는 사용량 기반 과금이다. 첫 eCKU는 무료이고 이후 eCKU당 시간당 $0.14, 데이터 인/아웃 $0.05/GB, 스토리지 $0.08/GB이다. 트래픽이 어느 정도 있으면 한 달 수백~수천 달러가 우습게 나온다.
• CloudAMQP: Little Lemur는 무료이다. 공유형 Tough Tiger는 $19/월이다. 전용 Big Bunny는 $99/월부터이다.

 

소규모는 CloudAMQP가 압도적으로 저렴하다. 정말로 그렇다.

 

한국 클라우드 옵션

 

네이버 클라우드, KT 클라우드, NHN 클라우드 모두 자체 매니지드 메시지 큐를 보유한다. 네이버 클라우드는 Cloud Hadoop 안에 Kafka 옵션이 있고, NHN 클라우드는 CloudPub/Sub 같은 서비스를 제공한다.

 

다만 한국 클라우드의 매니지드 메시징은 AWS, GCP에 비해 기능이 빈약하다. 큰 회사들도 결국 AWS MSK나 Confluent Cloud를 쓰는 경우가 많다.

 

자체 운영 시 인건비 포함한 진정한 비용

 

여기에 함정이 있다. 서버비만 보면 자체 운영이 저렴해 보이지만, 운영 인력 1명의 인건비(연 6000만원~1억) 추가하면 매니지드가 훨씬 저렴하다. Kafka 클러스터를 운영하다 새벽에 Zookeeper가 죽어 깨어나본 사람만이 이해한다.

 

규모가 진정 큰 회사가 아니라면 매니지드를 쓰는 것이 정답이다. 시간 vs 돈의 트레이드오프이다.

 

RabbitMQ vs Kafka 의사결정 체크리스트 - 그래서 무엇을 선택해야 하는가

 

지금까지의 논의를 정리하면 다음과 같다.

 

의사결정 체크리스트 5문항

 

1. 메시지를 다시 읽어야 하는가? → YES면 Kafka, NO면 RabbitMQ
2. 초당 처리량이 5만 건을 넘는가? → YES면 Kafka
3. 라우팅 룰이 복잡한가? → YES면 RabbitMQ
4. 지연시간 ms 이하가 필요한가? → YES면 RabbitMQ
5. 운영 인력이 충분한가? → NO면 RabbitMQ (또는 매니지드)

 

5개 중 3개 이상이 Kafka 쪽이라면 Kafka, 그 반대라면 RabbitMQ이다.

 

또한 두 가지를 모두 사용하는 케이스도 매우 흔하다. 배민이나 토스도 Kafka로 큰 이벤트 스트림을 처리하고, RabbitMQ로 작업 큐를 돌린다. 도구 하나로 모든 것을 해결하려 하지 말고, 적재적소에 사용하는 것이 옳다.

 

마지막으로 한 번 더 강조한다. RabbitMQ vs Kafka는 "어느 것이 더 좋은가"가 아니라 "어떤 문제를 풀 것인가"의 문제이다. 망치와 드라이버를 비교하는 것과 비슷하다. 못을 박을 것이라면 망치를, 나사를 돌릴 것이라면 드라이버를 쓰는 것이지, 어느 것이 더 좋다고 단언해서는 안 된다.

 

설계 단계에서 이를 잘 정해두면 1~2년 뒤에 갈아엎는 일이 발생하지 않는다. 신중하게 선택하기 바란다.