💡 분산 시스템 환경에서 컴포넌트 간의 결합도를 낮추고(Decoupling) 비동기 통신을 구현하는 메시지 브로커는 필수적인 인프라 요소입니다. 대표적인 두 솔루션인 Apache Kafka와 RabbitMQ는 그 목적은 유사하나, 내부 동작 방식과 아키텍처 철학이 근본적으로 다릅니다. Kafka는 영구적인 로그 기반의 데이터 스트리밍 플랫폼으로서의 정체성을 가지며, RabbitMQ는 메시지 전달에 초점을 맞춘 전통적인 큐(Queue) 기반의 브로커입니다. 본 포스팅에서는 두 시스템의 기술적 차이점을 심층 분석하며, 각 솔루션이 어떤 워크로드에 최적화되어 있는지 탐구합니다.
✨ 핵심 원리: 로그 기반 스트리밍 vs. 전통적인 큐 모델
Kafka와 RabbitMQ의 근본적인 차이는 **데이터를 '저장하는 방식'**과 **컨슈머(Consumer)에게 '전달하는 방식'**에서 발생합니다. Kafka는 불변의 로그 저장소이며, RabbitMQ는 휘발성이 강한 큐를 중심으로 동작합니다.
🔥 1. 동작 모델 (Pull vs. Push) 및 컨슈머 관리
메시지를 컨슈머에게 전달하는 방식에서 두 시스템은 극명하게 대조됩니다.
- RabbitMQ (Push Model):
- 브로커가 컨슈머에게 메시지를 **푸시(Push)**합니다. 컨슈머는 메시지를 수신할 준비가 되었을 때만 연결을 유지합니다.
- 메시지는 기본적으로 **휘발성(Transient)**이며, 컨슈머가 메시지를 수신하고 **ACK(확인 응답)**를 보내면 큐에서 메시지가 삭제됩니다.
- 장점: 컨슈머의 처리 속도에 관계없이 브로커가 즉각적으로 메시지를 전달하므로 **낮은 지연 시간(Low Latency)**이 요구되는 작업에 유리합니다.
- Kafka (Pull Model):
- 컨슈머가 브로커(토픽 파티션)에게 메시지를 풀(Pull) 요청합니다.
- 컨슈머는 자신이 마지막으로 읽은 위치인 **오프셋(Offset)**을 직접 관리하며, 이 오프셋을 기준으로 메시지를 요청합니다.
- 장점: 컨슈머의 처리 능력에 따라 메시지를 가져오는 속도를 스스로 조절할 수 있으므로, 컨슈머의 과부하를 방지하고 처리량(Throughput) 최적화에 유리합니다.

👉 관련 글 : 구글/아마존은 어떻게? 분산 시스템의 데이터 일관성 문제 해결법
구글/아마존은 어떻게? 분산 시스템의 데이터 일관성 문제 해결법
구글, 아마존과 같은 대규모 IT 기업들이 분산 시스템에서 데이터 일관성 문제를 어떻게 해결하는지 심층 분석합니다. CAP 이론의 이해를 바탕으로 최종 일관성(Eventual Consistency) 모델과 리플리케
praymeyer2025.tistory.com
🧘 2. 메시지 저장 및 영속성 아키텍처
메시지 저장소의 구조는 시스템의 확장성과 데이터 무결성을 결정합니다.
- Kafka (Commit Log):
- 메시지는 토픽(Topic) 내의 **파티션(Partition)**에 **불변의 순서(Immutable Sequence)**를 가진 커밋 로그(Commit Log) 형태로 디스크에 기록됩니다.
- 메시지는 컨슈머의 수신 여부와 관계없이 설정된 보존 기간(Retention Policy) 동안 디스크에 영구적으로 보존됩니다.
- 이 구조 덕분에 다수의 컨슈머가 동일한 데이터를 시간차를 두고 재처리(Replay) 할 수 있습니다.
- RabbitMQ (Queue Structure):
- 메시지는 기본적으로 메모리에 저장되며, 영속성 옵션이 설정된 경우에만 디스크에 기록됩니다.
- 메시지가 컨슈머에게 성공적으로 전달되고 ACK를 받으면, 큐에서 즉시 제거됩니다.
- 데이터의 순환이 빠르고, 큐가 비워지는 것이 기본 상태입니다.
💪 3. 메시지 전달 보장 및 복제 (Replication)
두 시스템 모두 메시지 전달의 신뢰성을 높이는 메커니즘을 제공하지만, 그 방식에 차이가 있습니다.
- RabbitMQ (클러스터링 및 고가용성 큐):
- 노드 간 클러스터링을 통해 고가용성을 확보하며, **미러링(Mirroring)**된 고가용성 큐(HA Queue)를 사용하여 메시지를 여러 노드에 복제합니다.
- 메시지 전달 보장은 **발행자 확인(Publisher Confirms)**과 컨슈머 ACK를 통해 이루어지며, 기본적으로 '최소 한 번(At-Least-Once)' 전달을 보장합니다.
- Kafka (파티션과 리플리케이션 팩터):
- 메시지는 리더(Leader) 파티션에 기록된 후 팔로워(Follower) 파티션으로 복제됩니다. 복제 시 ISR (In-Sync Replicas) 메커니즘을 통해 데이터 일관성을 유지합니다.
- 생산자(Producer)는 acks 설정을 통해 메시지가 몇 개의 복제본에 기록된 후 성공으로 간주할지 지정할 수 있어 **내구성(Durability)**을 세밀하게 제어할 수 있습니다.

🎶 4. 확장성 및 워크로드 최적화
- Kafka:
- 확장성: 수평적 확장성에 최적화되어 있습니다. 토픽을 파티션으로 나누어 수평적으로 처리량을 확장합니다. 파티션이 많아질수록 처리량은 증가하지만, 파티션 간의 메시지 순서는 보장되지 않습니다.
- 최적 워크로드: 대규모 데이터 파이프라인, 이벤트 소싱(Event Sourcing), 로그 수집, 실시간 스트리밍 분석 등 높은 처리량과 데이터의 영구적인 보존 및 재처리가 필요한 경우에 적합합니다.
- RabbitMQ:
- 확장성: 주로 클러스터링을 통해 확장되며, 큐의 수를 늘려 처리량을 확장할 수 있습니다.
- 최적 워크로드: 작업 큐(Task Queue), 사용자 알림, 이메일 전송, 금융 거래와 같이 메시지 전달의 확실성과 낮은 지연 시간이 핵심이며, 큐가 빨리 비워지는 것이 중요한 경우에 적합합니다.

✅ 요약 및 아키텍처 비교 💯
| 특징 | Kafka | RabbitMQ |
| 핵심 역할 | 로그 기반 스트리밍 플랫폼 | 전통적인 메시지 브로커 (Queue) |
| 메시지 저장 | 불변의 커밋 로그 (디스크 영구 보존) | 휘발성 큐 (ACK 후 즉시 삭제) |
| 컨슈머 모델 | Pull 방식 (컨슈머가 오프셋 관리) | Push 방식 (브로커가 즉시 전달) |
| 최적 성능 | 높은 처리량 (High Throughput) | 낮은 지연 시간 (Low Latency) |
| 주요 활용 | 이벤트 소싱, 데이터 파이프라인, 실시간 분석 | 작업 큐, 알림, 즉각적인 메시지 전달 |
📚 출처
- Apache Kafka Documentation: Partitioning, Replication, and Consumer Group Mechanisms
- RabbitMQ Documentation: Exchange Types, Clustering, and Message Persistence
- 분산 시스템 설계 원칙: Decoupling and Durability Concepts
👉 함께 보면 도움되는 글 : 모놀리식 → MSA → 모듈러 모노리스, 아키텍처 진화 흐름
'💡 IT 핵심 지식 (Core) > ⚙️시스템 & 개발 구조' 카테고리의 다른 글
| 대규모 서비스에서 설정 파일이 문제를 만드는 순간들: 환경 분리와 관리 구조 이해하기 (0) | 2026.02.25 |
|---|---|
| 프로그램을 한 덩어리로 만들던 방식이 바뀐 이유 (1) | 2025.12.08 |
| Redis가 빠른 이유: 메모리 기반 캐시 구조 (0) | 2025.12.07 |
| API Rate Limit가 필요한 이유: '제한 속도'를 두는 까닭 (0) | 2025.12.06 |
| ORM은 왜 쓰는가? SQL 직접 작성과의 차이 이해하기 (0) | 2025.12.05 |