Kafka와 RabbitMQ의 차이와 선택 기준은?
한 줄 답변
Kafka는 로그 기반의 고성능 스트리밍에 최적화된 플랫폼이며, RabbitMQ는 유연한 라우팅과 즉각적인 메시지 전달이 강점인 전통적 브로커입니다. 데이터의 양과 처리 방식에 따라 선택합니다.
핵심 개념 정리
메시지 큐(Message Queue)는 현대의 마이크로서비스 아키텍처(MSA)에서 서비스 간 결합도를 낮추고 시스템의 가용성을 높이는 필수 인프라입니다. 대표적 솔루션인 RabbitMQ는 'Smart Broker' 모델로 동작합니다. 브로커가 메시지 상태(전달 여부, 확인 등)를 직접 관리하며 소비자에게 Push하는 방식입니다. 메시지가 성공적으로 처리되면 즉시 삭제하여 자원을 효율적으로 사용하며, Direct나 Topic 같은 복잡한 라우팅 기능을 통해 정교한 메시지 분배가 가능합니다.
반면 Apache Kafka는 'Dumb Broker, Smart Consumer' 철학을 바탕으로 한 분산 커밋 로그 플랫폼입니다. 메시지를 디스크에 순차적으로 기록하여 영구히 보존(Retention)하며, 소비자가 필요한 시점에 스스로 데이터를 Pull해가는 구조입니다. 이 단순함 덕분에 초당 수백만 건 이상의 메시지를 처리하는 압도적 처리량(Throughput)을 보장합니다. 또한 데이터를 보관하기 때문에 과거 시점의 메시지를 다시 읽는 리플레이(Replay)가 가능하여 이벤트 소싱이나 실시간 분석 파이프라인에 최적입니다.
결국 선택은 트레이드오프의 문제입니다. 데이터의 유실 없는 즉각적인 처리와 복잡한 비즈니스 규칙 연동이 우선이라면 RabbitMQ가 유리합니다. 반대로 데이터의 양이 방대하고 실시간 스트리밍 처리가 필요하며, 시스템 장애 시 데이터 복구 안정성이 중요하다면 Kafka를 도입하는 것이 일반적입니다. 두 기술의 근본적인 아키텍처 차이를 이해하는 것이 면접 답변의 핵심입니다.
비교 정리
| 항목 | RabbitMQ (Push형) | Kafka (Pull형) |
|---|---|---|
| 핵심 아키텍처 | 메시지 브로커 (메모리 중심) | 분산 커밋 로그 (디스크 중심) |
| 데이터 보존 | 소비 후 즉시 삭제 | 설정 기간 동안 영구 보존 및 재읽기 가능 |
| 처리 성능 | 수만 건의 TPS, 낮은 지연 시간 | 수백만 건 이상의 고속 처리량 |
| 주요 사용처 | 작업 큐, 실시간 알림, 백엔드 연동 | 로그 수집, 빅데이터 파이프라인, 이벤트 스트리밍 |
면접에서 이렇게 답하세요
면접에서는 단순히 기술 나열에 그치지 말고 '비즈니스 시나리오'와 연결하세요. '결제 알림처럼 정확성이 중요한 1회성 작업은 RabbitMQ를, 사용자 행동 로그처럼 대용량 데이터의 실시간 분석은 Kafka를 선택하겠다'는 식의 논리가 필요합니다. 특히 Kafka 도입 시 주키퍼(Zookeeper) 관리나 파티셔닝 전략 같은 운영상의 복잡도를 함께 언급한다면, 기술의 장단점뿐 아니라 도입 비용까지 고려하는 실무 역량을 보여줄 수 있습니다.
자주 묻는 추가 질문
Q. Kafka의 파티션 개수는 어떻게 결정하나요?
동시 처리량을 결정하는 단위이므로 예상 트래픽과 컨슈머 수를 고려해 설정합니다. 늘리기는 쉽지만 줄이는 것은 매우 어렵습니다.
Q. RabbitMQ의 메시지 순서 보장 방법은?
단일 큐에 단일 컨슈머를 연결하면 순서가 보장됩니다. 병렬 처리가 필요할 때는 일관된 해시 라우팅 등을 사용해야 합니다.
Q. 메시지 큐가 중단되면 어떻게 대비하나요?
생산자 측의 재시도 로직과 로컬 버퍼링, 그리고 브로커 클러스터 구성을 통한 고가용성(HA) 확보가 필수적입니다.
커뮤니티 하이라이트
“Kafka는 초기 설정값이 성능에 큰 영향을 줍니다. 기본값만 믿고 서비스에 올렸다가 낭패 본 적이 많아요.”
“RabbitMQ의 관리 UI가 직관적이라 운영팀 입장에선 훨씬 편할 때가 많습니다. 무조건 Kafka가 답은 아닙니다.”
34명의 개발자가 이 질문에 참여했습니다
관련 면접 질문
앱에서 직접 답변해보세요
매일 3개의 면접 질문에 답변하고,
다른 개발자들의 답변을 비교해보세요.