Kafka 가 어울리는 자리, 그렇지 않은 자리

Kafka 는 흔히 "큐" 로 불리지만 정확히 말하면 분산 커밋 로그입니다. 강점은 큐 이상의 자리에서 드러납니다. 동시에 단순한 작업 큐에는 과한 도구이기도 합니다.

1. Kafka 에 대한 이야기

Kafka 는 LinkedIn 에서 시작된 분산 메시지·로그 시스템입니다. 2010 년 사내 프로젝트로 출발해 2011 년 Apache Software Foundation 에 인큐베이션, 2012 년 톱-레벨 프로젝트가 됐습니다. 1.0 정식 릴리스는 2017 년입니다.

사건	시기
사내 개발 시작 (LinkedIn)	2010
Apache 인큐베이션	2011
Apache 톱-레벨 프로젝트	2012
Kafka Streams 도입	0.10 (2016)
Exactly-once semantics	0.11 (2017)
1.0 GA	2017-11
KRaft (ZooKeeper 제거 모드)	3.3 (2022)
ZooKeeper 비-사용이 기본 옵션화	3.5+

설계 의도는 처음부터 "고처리량 · 디스크 추가만으로 보존 기간 연장 · 재처리 가능" 이었습니다. 큐의 일반화가 아니라 분산 로그의 발견이라고 표현되기도 합니다.

2. 토픽 · 파티션 · 컨슈머 그룹

• 토픽 (topic) — 메시지의 논리적 채널.
• 파티션 (partition) — 토픽을 분산·병렬로 다루기 위한 분할 단위. 파티션 안에서는 순서가 보장됩니다.
• 메시지 — 키·값·헤더·오프셋. 키 해시로 파티션이 결정되는 것이 흔합니다.
• 오프셋 (offset) — 파티션 안에서의 위치. 컨슈머가 자기 진행도를 기록합니다.
• 컨슈머 그룹 (consumer group) — 같은 그룹 안의 컨슈머들이 파티션을 나눠 가져갑니다. 한 파티션은 그룹 안에서 한 컨슈머에게만 할당됩니다.

이 모델 덕분에 같은 토픽을 다른 그룹이 각자의 진행도로 따로 읽을 수 있습니다. 큐의 "가져가면 사라진다" 와 다르게, Kafka 는 보존 기간이 다 되기 전까지 메시지가 디스크에 남습니다.

3. 보존 정책

• 시간 기반 (retention.ms) — 예: 7 일.
• 크기 기반 (retention.bytes) — 예: 100 GB.
• 압축 (compaction) — 같은 키의 마지막 값만 남깁니다 — 키-값 스냅샷 토픽으로 활용.

4. 전달 보증

보증	구성
at-most-once	producer 가 ack 미기다림 + 컨슈머 자동 커밋. 손실 가능.
at-least-once	기본. ack=all + 수동 커밋. 중복 가능.
exactly-once	producer 의 idempotent + transactional + 컨슈머의 read-committed. Kafka 토픽 안에서만 성립. 외부 시스템 결합 시에는 멱등 컨슈머가 여전히 권장됩니다.

acks (producer) · enable.idempotence · isolation.level (consumer) 가 핵심 설정입니다.

5. 스토리지 · 복제 · KRaft

각 파티션은 leader + followers 로 복제됩니다. replication.factor 가 보통 3. ISR (In-Sync Replicas) 안의 레플리카들이 leader 와 동기화된 상태입니다. leader 장애 시 ISR 중 하나가 새 leader 가 됩니다.

오랫동안 메타데이터 관리에 ZooKeeper 를 썼습니다. 2022 년부터 KRaft (Raft 합의 알고리즘 기반) 가 등장해 ZooKeeper 없이 Kafka 자체 노드만으로 운영이 가능해졌습니다. 운영 표면이 줄었다는 평가가 많습니다.

6. Kafka 가 강한 자리

• 이벤트 소싱 · CDC — 모든 변경의 보존·재생.
• 여러 컨슈머가 같은 스트림을 다른 속도로 읽는 자리 — 토픽 한 번 발행, 다중 그룹 소비.
• 고처리량 로그 수집 — 초당 수십만 메시지.
• 실시간 분석의 입구 — Flink · Spark Streaming · Kafka Streams.
• 메시지 보존을 통한 백필·재처리.

7. Kafka 가 과한 자리

• 단순한 작업 큐 (이메일 발송, 백그라운드 처리) — RabbitMQ · Redis · SQS 가 더 단순합니다.
• 짧은 TTL · 적은 처리량 — Kafka 의 운영 비용이 정당화되지 않습니다.
• 작업당 사람이 직접 보고 싶은 워크플로 — Airflow 계열이 어울립니다.

8. 다른 후보들

시스템	출자·시기	모델	메모
RabbitMQ	2007, AMQP 0-9-1 기반	큐·exchange·routing	라우팅·라운드로빈·DLQ. 메시지 영속·보존 기간이 Kafka 같지는 않습니다.
NATS	2010, Derek Collison	pub/sub · JetStream	가벼움·낮은 지연. JetStream(2020) 으로 영속 추가.
Redis Streams	2018, Redis 5.0	log + consumer group	Kafka 의 축소판 같은 모델. 보유 데이터 양이 작은 자리에 적합.
AWS SQS	2006	단순 큐	매니지드. FIFO 큐 옵션. 단일 메시지 ≤ 256KB.
AWS Kinesis	2013	스트림	Kafka 와 유사 모델의 매니지드. 24h ~ 365d 보존.
Google Pub/Sub	2015	pub/sub	매니지드. 자동 확장. 순서 옵션.
Apache Pulsar	2016, Yahoo (오픈소스)	다층 (broker + bookie)	멀티 테넌시·지오 복제 강조.

선택의 결정 요인은 다음 중 한두 개로 좁아집니다.

• 데이터 보존 기간 (분 단위인가, 일 단위인가).
• 처리량 (초당 수만~수십만인가).
• 매니지드를 쓸 수 있는가.
• 라우팅·필터링이 복잡한가 (RabbitMQ 가 강함).
• 한 토픽을 여러 컨슈머가 다른 속도로 읽는가 (Kafka 형 모델이 자연스러움).

9. 토픽·컨슈머·운영

토픽 네이밍 — <도메인>.<엔티티>.<이벤트> 형식이 흔합니다 (예: orders.created). 환경을 prefix 또는 별도 클러스터로 분리합니다. 스키마는 Schema Registry (Avro · Protobuf · JSON Schema) 로 관리합니다.

컨슈머 설계 — 멱등 처리가 기본입니다. DLQ (Dead Letter Queue) 로 처리 실패가 반복되는 메시지를 별도 토픽으로 보냅니다. 일시적 외부 의존 (예: API 5xx) 에는 재시도 + backoff + DLQ 를 묶습니다.

파티션 수는 처리량과 컨슈머 수의 상한을 결정합니다. 처음에 너무 작게 잡으면 늘리기는 가능하지만 키-파티션 매핑이 바뀌어 순서 가정이 깨질 수 있습니다.

모니터링 — lag (컨슈머가 leader 끝과 얼마나 떨어졌는가), 메시지율, replication lag.

10. 자주 걸리는 자리

순서 가정 — 토픽 전체가 아니라 파티션 안에서만 순서가 보장됩니다. 여러 파티션을 사용하면 글로벌 순서는 없습니다.

파티션 수 변경 — 늘리는 것은 가능하지만 키 → 파티션 매핑이 바뀝니다. 같은 키의 메시지가 새 파티션으로 가게 되는 점이 운영 사고로 이어질 수 있습니다.

컨슈머 그룹 리밸런싱 — 새 컨슈머 합류·이탈 시 파티션 재할당이 일어납니다. 그동안 처리가 멈출 수 있습니다 (cooperative rebalancing 으로 완화).

exactly-once 의 범위 — 토픽 안에서만이라는 점입니다. 외부 DB 에 쓰는 컨슈머는 결국 멱등 설계가 필요합니다.

운영 자원 — 작은 팀에 매니지드 없이 자가 운영되는 Kafka 는 부담이 큽니다. Confluent Cloud · MSK · Aiven 같은 매니지드를 검토합니다.

하고픈 말

Kafka 는 "큐가 필요한가" 라는 질문에 늘 정답은 아닙니다. 보존·재처리·다중 컨슈머가 진짜 필요한 자리에서만 강합니다. 작은 팀이면 Redis Streams 나 RabbitMQ 로 시작해 키워가는 편이 운영에 안전합니다.

Next

• pgvector-rag
• supabase

Apache Kafka 공식 문서 · Kafka 디자인 · KRaft 가이드 · Confluent 블로그 · RabbitMQ 공식 · NATS JetStream · Apache Pulsar 를 참고합니다.