이 문서를 통해 아래 질문들에 답할 수 있게 됩니다.
- Kafka와 Redis Stream은 이벤트 보관, replay, 확장, 운영 부담에서 어떻게 다른가?
- 어떤 요구에서는 Redis Stream이 충분하고, 어떤 요구에서는 Kafka가 더 자연스러운가?
- 작은 Spring 프로젝트에서 Redis Stream으로 시작해도 되는 경계는 어디까지인가?
- 기술 선택 문서에 어떤 지표와 전환 조건을 남겨야 하는가?
개요
Kafka와 Redis Stream은 둘 다 event 처리에 쓸 수 있다.
하지만 목적과 운영 모델은 다르다.
Redis Stream은 이미 Redis를 쓰는 환경에서 빠르게 내부 비동기 처리를 만들기 좋다.
Kafka는 장기 보관 event log, 여러 consumer group, partition 기반 확장, replay 중심 운영에 강하다.
선택 기준은 “무엇이 더 빠른가”가 아니라 “어떤 실패를 복구해야 하는가”다.
핵심 비교
| 기준 | Redis Stream | Kafka |
|---|---|---|
| 보관 | Redis memory와 trim 정책 영향 | disk 기반 log retention |
| 확장 | Stream key와 consumer group 중심 | topic partition 중심 |
| replay | 짧은 범위에 적합 | 긴 범위와 여러 group replay에 적합 |
| 운영 부담 | 작게 시작하기 쉬움 | cluster 운영 부담이 큼 |
| ecosystem | 단순 command 중심 | connector, schema, stream processing 생태계 |
| 적합한 범위 | 내부 작업, 짧은 비동기 처리 | 조직 event backbone, 분석/CDC 연계 |
둘 중 하나가 항상 우월하지 않다.
요구가 작으면 Kafka는 과하고, 요구가 커지면 Redis Stream은 application 부담이 커진다.
Redis Stream을 고르는 경우
Redis Stream은 다음 조건에서 실용적이다.
- 이미 Redis 운영 경험이 있다.
- 이벤트가 같은 서비스나 작은 bounded context 안에서만 흐른다.
- replay 범위가 짧다.
- consumer group 수가 적다.
- 메시지량과 보관량이 Redis memory 안에서 예측 가능하다.
- Kafka cluster 운영이 프로젝트 규모에 비해 과하다.
예를 들어 결제 완료 후 같은 서비스 내부에서 영수증 생성 작업을 비동기로 처리하는 정도라면 Redis Stream으로 충분할 수 있다.
단, 영수증 생성이 법적 감사 대상이라면 event 원본은 DB/outbox에도 남겨야 한다.
Kafka를 고르는 경우
Kafka는 다음 조건에서 더 자연스럽다.
- 여러 서비스와 팀이 같은 event를 독립적으로 읽는다.
- 며칠 이상 replay가 필요하다.
- topic partition으로 처리량을 확장해야 한다.
- CDC, warehouse 적재, stream processing과 연결된다.
- schema evolution과 consumer compatibility가 중요하다.
- event가 기업 데이터 흐름의 기준 로그가 된다.
주문 결제 event를 정산, 배송, 알림, 추천, 분석이 모두 읽는다면 Kafka가 적합하다.
특히 consumer group별 lag와 replay가 운영의 기본 요구라면 Redis Stream보다 Kafka가 낫다.
선택 질문
기술 선택 전에 다음 질문을 답한다.
- 메시지를 얼마나 오래 보관해야 하는가?
- consumer group은 몇 개이고 누가 소유하는가?
- 같은 event를 며칠 뒤 새 consumer가 처음부터 읽어야 하는가?
- 처리량을 늘릴 때 어떤 key로 병렬성을 나눌 것인가?
- replay 중 운영 DB나 Redis memory에 어떤 부하가 생기는가?
- 장애 때 event 원본은 어디에서 다시 만들 수 있는가?
이 질문에 답하지 못하면 Redis와 Kafka 중 무엇을 골라도 운영 근거가 약하다.
Spring 프로젝트의 현실적인 선택
개인 프로젝트나 작은 서비스에서는 Redis Stream으로 시작할 수 있다.
단, 다음을 문서화한다.
- Stream key
- event id와 dedup key
- consumer group
- pending claim 기준
- trim 정책
- Kafka 전환 조건
이 문서가 있으면 “간단해서 Redis”가 아니라 “현재 요구에는 Redis로 충분하고, 이 조건을 넘으면 Kafka”라고 설명할 수 있다.
전환 조건
전환 조건은 숫자로 둔다.
예시는 다음과 같다.
retention_required_days > 3 -> Kafka 검토
consumer_group_count > 3 -> Kafka 검토
stream_memory_usage > Redis memory 20% -> Kafka 또는 분리 Redis 검토
replay_range > trim retention -> Kafka/outbox 기반 재처리 검토
cross-team consumers exist -> Kafka 검토숫자는 조직마다 다르다.
중요한 것은 장애가 난 뒤가 아니라 설계 단계에서 기준을 정하는 것이다.
운영 지표 비교
Redis Stream에서 보는 지표는 다음이다.
- stream length
- pending entry count
- oldest pending idle time
- memory usage
- trim count
Kafka에서 보는 지표는 다음이다.
- consumer lag by group and partition
- broker disk usage
- under replicated partitions
- produce/fetch latency
- retention and oldest offset
지표가 다르다는 것은 운영 질문이 다르다는 뜻이다.
Redis Stream 선택 문서에 Kafka 지표만 적거나, Kafka 선택 문서에 Redis pending만 적으면 기술 이해가 흐린 것이다.
비용과 복잡도
Kafka는 cluster, broker disk, topic 운영, partition 계획, schema와 consumer 배포 관리가 필요하다.
Redis Stream은 command와 data structure가 단순하지만 Redis memory와 pending 운영을 application 팀이 더 직접 챙겨야 한다.
작은 팀에서는 Redis Stream이 빠른 선택이다.
여러 팀의 데이터 계약이 생기면 Kafka의 복잡도가 오히려 운영 질서를 만들어 줄 수 있다.
위험 신호!
- “Redis가 빠르니까 Kafka 대신 쓴다”로 끝난다.
- “Kafka는 무겁다”는 이유만 있고 replay 요구를 보지 않는다.
- Redis Stream trim 정책이 retention 요구보다 짧다.
- Kafka를 도입했지만 topic key, partition, group owner가 없다.
- 전환 조건 없이 임시 선택이 영구 구조가 된다.
확인 질문
확인 질문
- 새 consumer가 한 달 뒤 과거 이벤트를 처음부터 읽어야 하는가?
- 그렇다면 Kafka 쪽 요구에 가깝다.
- event가 같은 서비스 내부 작업 큐에 가깝고 보관 기간이 짧은가?
- 그렇다면 Redis Stream으로 시작할 수 있다.
- Redis Stream에서 Kafka로 넘어갈 기준은 무엇인가?
- retention, group 수, memory, replay 범위를 숫자로 답해야 한다.
참고 문서
- Redis Streams Documentation
- Apache Kafka Documentation
- Martin Kleppmann, Designing Data-Intensive Applications