Kafka는 강력하지만 항상 올바른 도구는 아닙니다 — 대용량 이벤트 스트리밍, 파이프라인, 이벤트 기반 시스템에 뛰어나지만, 더 단순한 도구가 피하는 운영 복잡성을 더합니다. Kafka가 적합한 때(와 과한 때)를 이해하는 것은 건전한 판단을 반영합니다.
Kafka가 좋은 선택일 때
✓ 대용량 이벤트 스트리밍 / 데이터 → 수백만 이벤트; 높은 처리량 필요
✓ DATA PIPELINES → 여러 시스템 간 데이터를 안정적으로 스트리밍(데이터 백본)
✓ 같은 스트림의 다중 CONSUMER → 여러 독립 consumer/group이 데이터를 읽음
✓ EVENT-DRIVEN 아키텍처 / event sourcing → 이벤트를 내구성 있는 기록으로
✓ REPLAY 필요 → 과거 이벤트 다시 읽기
✓ REAL-TIME 스트림 처리 / 분석
→ Kafka는 확장, 스트리밍, 보존, 다중 consumer에 빛납니다
Kafka가 과할 수 있을 때
⚠️ Kafka는 운영 복잡성을 더함(실행, 튜닝, 모니터링할 분산 클러스터):
→ 단순한 메시징 / 작업 큐 → 더 단순한 큐(RabbitMQ, SQS, Redis)로 충분할 수 있음
→ 낮은 볼륨 → Kafka의 확장이 불필요; 더 단순한 도구가 쉬움
→ 요청/응답, 복잡한 라우팅 → 전통적 큐가 더 적합
→ 단순한 백그라운드 잡 큐만 필요 → Kafka를 쓰지 마세요
→ 기능이 필요 없다면 Kafka의 복잡성을 더하지 마세요(YAGNI)
