결론부터 말하면, Kafka와 RabbitMQ는 더 나은 쪽을 고르는 문제가 아닙니다. 다루는 메시지가 “명령”인지 “기록”인지에 따라 답이 갈리는, 태생이 다른 두 도구입니다. 누군가 처리할 작업을 분배하고 복잡하게 라우팅해야 한다면 RabbitMQ가, 일어난 사실을 쌓아 두고 여러 소비자가 각자 다시 읽어야 한다면 Kafka가 자연스럽습니다. 이 한 문장이 이 글의 전부이고, 나머지는 그 근거입니다.
근본 차이 — 삭제하는 큐 vs 보관하는 로그
가장 큰 차이는 메시지를 다루는 철학입니다. RabbitMQ는 전통적인 메시지 브로커로, 큐에 넣은 메시지를 소비자가 가져가면 큐에서 사라집니다. 한 번 처리되면 끝인 “전달 후 삭제” 모델입니다.
Kafka는 브로커라기보다 분산 로그(distributed log)에 가깝습니다. 메시지가 소비된 뒤에도 보관 기간 동안 디스크에 그대로 남고, 소비자는 자신의 오프셋(offset)을 기준으로 같은 데이터를 몇 번이고 다시 읽을 수 있습니다. 이 한 가지 차이가 거의 모든 특성을 가릅니다.
한눈에 보는 구조 비교
| 구분 | RabbitMQ | Kafka |
|---|---|---|
| 모델 | 메시지 브로커(큐) | 분산 로그 |
| 소비 후 | 큐에서 삭제 | 보관 기간 동안 유지 |
| 재처리(replay) | 기본 어려움 | 오프셋으로 재소비 |
| 라우팅 | 풍부(exchange) | 단순(파티션 키) |
| 순서 보장 | 큐 단위 | 파티션 단위 |
| 강점 처리 특성 | 낮은 지연(latency) | 높은 처리량(throughput) |
RabbitMQ는 AMQP 기반으로 익스체인지와 큐의 바인딩을 통해 “특정 조건의 메시지만 이 큐로” 같은 복잡한 분배를 유연하게 표현합니다. Kafka는 토픽을 파티션으로 쪼개 분산 저장하고, 파티션 수만큼 소비자를 늘려 병렬 처리량을 끌어올립니다. 라우팅은 단순한 대신 처리량과 확장성에서 압도적입니다.
성능과 운영 — 좁혀지는 격차
흔히 “Kafka가 빠르다”고 하지만 정확히는 측정 기준이 다릅니다. Kafka는 디스크 순차 기록과 배치 처리로 초당 수십만 건 규모의 높은 처리량에 강하고, RabbitMQ는 메시지 하나하나를 빠르게 전달하는 낮은 지연과 즉시성에 강합니다.
운영 난이도도 과거와 달라졌습니다. Kafka는 4.0부터 ZooKeeper를 완전히 제거하고 브로커 내부 쿼럼이 메타데이터를 관리하는 KRaft 모드만 지원해 구성 요소가 줄었습니다. RabbitMQ도 쿼럼 큐와 로그 기반 스트림을 더하며 신뢰성과 처리량을 보강했습니다. 즉 둘 다 “못 하는 것”이 줄어드는 추세라, 절대 성능보다 워크로드 성격으로 판단하는 편이 안전합니다.
실제 선택 — 채팅 서비스에 RabbitMQ를 고른 이유
저는 채팅 서비스를 만들며 RabbitMQ를 택했습니다. 기준은 “ChatRoom별로 메시지를 얼마나 빠르게 꽂아 넣는가”였습니다. 채팅은 대량 이벤트를 쌓아 두고 분석하는 작업이 아니라, 지금 그 방에 있는 사람에게 메시지 한 건을 즉시 전달하는 것이 전부입니다. 처리량보다 건당 지연이 중요했고, 이 지점이 RabbitMQ의 강점과 정확히 맞았습니다.
구성 편의성도 결정적이었습니다. 익스체인지와 라우팅 키로 방 단위 분배를 자연스럽게 표현할 수 있었고, 여러 서버 인스턴스를 같은 큐에 등록해 부하를 나누기도 쉬웠습니다. 만약 같은 메시지를 여러 시스템이 나중에 다시 읽거나 이력 분석이 필요했다면 Kafka를 골랐겠지만, 실시간 전달이 핵심인 이 서비스에는 RabbitMQ가 더 단순하고 빠른 답이었습니다.
그래서, 상황별 선택 기준
| 상황 | 추천 |
|---|---|
| 대용량 이벤트·로그 수집, 분석 파이프라인 | Kafka |
| 이벤트 재처리·이력 보관 필요 | Kafka |
| 여러 소비자가 같은 데이터를 각자 소비 | Kafka |
| 복잡한 라우팅·조건부 메시지 분배 | RabbitMQ |
| 요청-응답, 작업 큐, 낮은 지연 | RabbitMQ |
| 빠른 도입·가벼운 구성 | RabbitMQ |
한 가지만 덧붙이면, 단일 애플리케이션 내부의 후속 처리라면 둘 다 과합니다. 그 수준에서는 스프링 기본 이벤트로 충분하고, 트랜잭션 경계만 잘 맞추면 됩니다. 메시지 큐는 서비스 간 통신이나 유실 방지가 필요해지는 순간 비로소 꺼내는 도구입니다. 도입을 고민 중이라면, 메시지 큐를 꺼내기 전에 “지금 정말 필요한가”를 먼저 물어보시기 바랍니다.
“Kafka vs RabbitMQ, 무엇을 언제 선택할까”에 대한 2개의 생각