Kafka vs RabbitMQ 어떤 상황에서 Kafka를 선택해야 하는가?

이 질문은 데이터 엔지니어링 면접에서도 '끝판왕'급으로 불리는 단골 주제입니다. 단순히 "둘 다 메시지를 전달한다"는 차원을 넘어, 시스템의 철학과 데이터의 생명주기를 대하는 관점 자체가 완전히 다르거든요.

카프카와 RabbitMQ의 결정적 차이를 분석하고, 어떤 상황에서 "이건 무조건 카프카다!"라고 외쳐야 하는지 그 설계적 근거를 낱낱이 파헤쳐 보겠습니다. 🫡

---

🏗️ 메시지 큐(RabbitMQ) vs 이벤트 스트리밍(Kafka)

우선 두 녀석의 '이름표'부터 다시 달아줘야 합니다. RabbitMQ는 메시지 브로커(Message Broker)이고, Kafka는 분산 스트리밍 플랫폼(Distributed Streaming Platform)입니다. 이 차이가 모든 것을 결정합니다.

1. 데이터 보관의 철학: "전달하고 지울 것인가, 기록하고 남길 것인가"

• RabbitMQ (전통적인 집배원): 메시지를 받아서 소비자에게 전달하는 것이 지상 과제입니다. 소비자가 "잘 받았어(Ack)!"라고 신호를 보내는 순간, RabbitMQ는 메모리와 디스크에서 해당 메시지를 즉시 삭제합니다. 큐(Queue)는 항상 비어 있는 것이 이상적인 상태입니다.
• Kafka (거대한 도서관): 메시지를 '이벤트 로그'라는 형태로 디스크에 차곡차곡 쌓아둡니다. 소비자가 읽어갔다고 해서 지우지 않습니다. 설정한 보관 기간(예: 7일)이나 용량이 찰 때까지는 데이터가 그대로 남아있습니다. 이 점이 카프카를 '재생 가능(Replayable)'하게 만듭니다.

💡 Deep Point: 만약 분석 로직에 오류가 있어서 어제 데이터를 다시 처리해야 한다면? RabbitMQ는 이미 데이터를 지웠기 때문에 불가능하지만, 카프카는 '오프셋(Offset)'만 어제로 되돌리면 똑같은 데이터를 다시 읽어올 수 있습니다. 이것이 바로 카프카가 데이터 엔지니어링의 핵심인 이유입니다.

---

2. 처리량과 확장성의 메커니즘 (Throughput & Scalability)

• RabbitMQ의 한계: RabbitMQ는 메시지의 상태(누가 읽었는지, 성공했는지 등)를 브로커가 일일이 관리합니다. 메시지가 많아질수록 브로커의 머리(CPU/RAM)가 복잡해지죠. 수만 건의 메시지가 쌓이면 급격히 느려지는 '성능 저하' 현상이 발생하기 쉽습니다.
• Kafka의 혁신: 카프카는 '누가 어디까지 읽었는지'에 대한 관리를 소비자(Consumer)에게 떠넘깁니다. 브로커는 단순히 파일 끝에 데이터를 이어 붙이고(Append), 요청이 오면 그 파일을 읽어주기만 합니다. 이 단순함 덕분에 초당 수백만 건의 데이터를 처리해도 지치지 않습니다.

---

3. 라우팅 기능의 유연성

• RabbitMQ의 강점: RabbitMQ는 매우 똑똑한 Exchange 기능을 가지고 있습니다. "이 메시지는 헤더 정보 보고 A, B 팀에 보내고, 저 메시지는 단어 필터링해서 C 팀에 보내!" 같은 복잡한 라우팅이 설정만으로 가능합니다.
• Kafka의 강점: 카프카는 라우팅 기능이 단순합니다. 하지만 이를 '컨슈머 그룹(Consumer Group)'과 '토픽(Topic)' 구조로 해결합니다. 하나의 데이터를 여러 팀이 각자의 목적(분석, 저장, 알람)에 맞게 실시간으로 동시에 긁어갈 수 있는 '발행/구독(Pub/Sub)' 모델에 최적화되어 있습니다.

---

🎯 "이럴 땐 무조건 카프카를 선택하세요" (Selection Criteria)

실무에서 아래 4가지 상황 중 하나라도 해당한다면 뒤도 돌아보지 말고 카프카를 고르시면 됩니다.

① 대규모 트래픽과 데이터 로그 수집 (High Throughput)

웹사이트의 클릭 로그, 앱의 행동 데이터, 센서 데이터처럼 초당 수천, 수만 건 이상의 이벤트가 쏟아진다면 RabbitMQ는 감당하기 어렵습니다. 카프카는 이런 '빅데이터의 입구' 역할을 하기 위해 태어났습니다.

② 데이터 재생성과 과거 데이터 분석 (Data Replay)

"내일 새로운 분석 알고리즘이 나올 수도 있으니, 일단 원본 데이터를 일주일 치는 보관해야 해!" 혹은 "시스템 장애로 어제 오후 3시부터 5시까지 데이터가 유실됐으니 다시 복구해야 해!" 같은 요구사항이 있다면 카프카가 유일한 해답입니다.

③ 단일 진실 공급원 (Single Source of Truth)

한 번 들어온 데이터를 여러 서비스가 동시에 활용해야 할 때입니다. 예를 들어 '주문 완료' 이벤트가 발생했을 때, 물류 시스템, 포인트 시스템, 마케팅 분석 시스템이 각각 자신의 속도에 맞춰 그 데이터를 가져가야 한다면 카프카의 토픽 구조가 가장 안정적입니다.

④ 스트림 프로세싱 (Stream Processing)

단순한 전달을 넘어, 흐르는 데이터 위에서 실시간으로 합계(Windowing)를 구하거나 데이터를 변환(Transform)해야 한다면 카프카 생태계(Kafka Streams, KSQL) 혹은 Spark Structured Streaming과의 연동성이 압도적인 카프카를 써야 합니다.

---

⚖️ 반대로, RabbitMQ가 더 나은 상황은?

공정하게 말씀드리면, 모든 곳에 카프카가 정답은 아닙니다.

• 데이터 양이 적고, 메시지의 우선순위(Priority)를 정교하게 관리해야 할 때.
• 복잡한 라우팅 로직이 필요할 때.
• 메시지가 전달되는 즉시 삭제되어야 하는 보안성 높은 업무일 때.
• 카프카 클러스터를 운영할 엔지니어링 리소스가 부족할 때 (RabbitMQ는 상대적으로 운영이 쉽습니다).

---

💡 '요약 정리'

비교 항목	RabbitMQ (The Messenger)	Kafka (The Log Recorder)
핵심 목적	서비스 간 비동기 메시지 전달	실시간 이벤트 스트리밍 및 로그 저장
데이터 보관	전달 후 즉시 삭제 (휘발성)	디스크에 일정 기간 보관 (영속성)
처리 속도	지연 시간(Latency)은 낮으나 처리량 한계	초고속 대용량 처리량(Throughput) 최적화
재처리	불가능	언제든 과거 데이터 재처리 가능
주요 사용처	복잡한 라우팅이 필요한 MSA 간 통신	빅데이터 수집, 실시간 분석 파이프라인

---