백엔드 데이터 인프라 80편 — Apache Kafka란 + 이벤트 스트리밍의 표준

이 글은 백엔드 데이터 인프라 시리즈 130편 중 80편이에요. Part 4 Redis 33편 까지 인메모리 데이터 영역 을 다 풀었다면, 이번 80편부터는 시리즈 2 의 마지막 큰 덩어리 — Part 5 Apache Kafka 51편 (80~130) 으로 들어가요. 이벤트 스트리밍·메시지 브로커·로그 시스템의 사실상 표준.

Apache Kafka가 어렵게 느껴지는 이유

처음 Kafka 를 보면 낯선 어휘가 한꺼번에 등장해요. Broker 와 Producer, Consumer, Topic, Partition, Offset, Replication, Consumer Group 에 KRaft (Kafka 자체 메타데이터 관리), ISR (in-sync replicas, 동기 복제본 집합) 까지 한 페이지에 다 나오면 막막.

첫째, 메시지 큐인가, 데이터베이스인가, 로그 시스템인가 가 안 잡힙니다. RabbitMQ 같은 전통 메시지 브로커 와도 다르고, Redis Stream (54편) 과도 비슷한데 더 큼. 그 정확한 위치 를 잡는 게 첫 학습 작업.

둘째, 운영 부담이 큽니다. 단일 인스턴스 Redis 와 달리 Kafka 는 기본적으로 분산 시스템 — 여러 브로커·Zookeeper(이제는 KRaft)·복제·파티션 등 운영 복잡도가 사실상 가장 높은 데이터 도구 중 하나.

셋째, Kafka 가 해결하는 문제 자체가 추상적 . "이벤트 스트리밍" 이라는 개념이 처음에는 모호. 구체적 use case 를 봐야 왜 필요한지 가 잡혀요.

이 글에서 Kafka 의 정체성·핵심 모델·다른 메시지 도구와의 차이·언제 도입하나 까지 큰 그림을 한 번에. 다음 81편 use cases 에서 구체적 활용처, 82편 quickstart 에서 직접 만져 보기.

Kafka가 뭔가 — 한 줄 정의

Apache Kafka = 분산 이벤트 스트리밍 플랫폼.

세 가지를 한 시스템에 묶음:

1. Publish + Subscribe — 이벤트 stream 을 읽고·쓰기
2. Store — 이벤트를 내구성 있게 영구 저장 (원하는 만큼)
3. Process — 실시간 또는 사후 이벤트 처리

이게 메시지 브로커 + 분산 로그 + 스트림 처리 가 한 시스템에 모인 Kafka 의 정체성.

비유 — Kafka 는 회사의 중앙 신경계. 모든 데이터가 Kafka 라는 중심 을 통과하며 실시간으로 흐르고 영구 보존 됨.

핵심 모델 — Producer · Consumer · Topic · Partition

Event (메시지)

key:       "Alice"
value:     "Made a payment of $200 to Bob"
timestamp: "Jun 25, 2020 14:06"
headers:   {trace_id: "abc123"}

각 이벤트 = key + value + timestamp + 메타데이터. 문자열·JSON·바이너리 무엇이든.

Producer

이벤트를 Kafka 에 publish (write) 하는 클라이언트. 마이크로서비스·웹 서버·IoT 디바이스 등.

Consumer

이벤트를 Kafka 에서 subscribe (read) 하는 클라이언트. 분석 시스템·실시간 처리·DB sync 등.

핵심 — Producer 와 Consumer 는 완전 분리. Producer 는 누가 읽는지 모르고, Consumer 는 누가 쓴 것인지 신경 안 씀.

Topic

이벤트가 저장되는 논리적 카테고리. 파일시스템의 폴더 같음. 예: payments·user-clicks·order-events.

특성:

• Multi-producer, Multi-subscriber — 여러 producer 가 write + 여러 consumer 가 read
• 영구 저장 — 전통 메시지 큐와 달리 consume 후 사라지지 않음
• Retention 설정 — N 일 또는 N GB 후 자동 삭제 (or 무한)

Partition — Kafka 의 분산 단위

Topic "payments"
├─ Partition 0 (Broker 1) — [event1, event2, event3, ...]
├─ Partition 1 (Broker 2) — [event4, event5, event6, ...]
├─ Partition 2 (Broker 3) — [event7, event8, event9, ...]
└─ Partition 3 (Broker 1) — [event10, event11, event12, ...]

토픽이 N개 partition 으로 분할. 각 partition 은 다른 broker 에 분산. 분산·확장성·병렬 처리의 핵심 단위.

핵심 — 같은 key 의 이벤트는 항상 같은 partition. 순서 보장은 partition 안에서만 — 전체 토픽 순서는 보장 X. 순서 보장이 필요하면 같은 key 사용.

Broker

Kafka 서버 인스턴스. Topic 의 partition 을 저장하고 producer·consumer 와 통신. Cluster = 여러 broker.

Replication

Partition 0:
  Leader  → Broker 1   (read/write 받음)
  Replica → Broker 2   (자동 복제)
  Replica → Broker 3   (자동 복제)

각 partition 이 N개 broker 에 복제. 일반적 replication factor = 3. broker 한 대 죽어도 다른 복제본이 새 leader 되어 데이터 손실 없음.

Kafka vs Redis Stream (54편) — 정확한 비교

54편에서 본 비교를 다시. Kafka 가 Stream 의 큰 형 같은 위치.

선택

• 소~중규모 + 이미 Redis 있음 → Redis Stream
• 대규모 + 영구 보존 + 처리량 결정적 → Kafka
• 둘 다 검토 = 일반 패턴 (작은 큐 = Redis, 큰 이벤트 스트림 = Kafka)

Kafka vs RabbitMQ — 전통 메시지 브로커와 비교

RabbitMQ = AMQP (Advanced Message Queuing Protocol) 기반 전통 메시지 브로커. 큐 모델·라우팅·복잡한 exchange 패턴 이 강점.

여기서 시험 함정이 하나 있어요 — RabbitMQ 와 Kafka 는 서로 대체가 아님. 문제가 다름. 작업 분배·복잡한 라우팅 = RabbitMQ. 대량 이벤트 로그·재처리·분석 = Kafka.

Kafka 의 4가지 활용 영역 (다음 편 81편에서 깊이)

미리 큰 그림만:

1. 메시징 — RabbitMQ 같은 전통 브로커 대체 (대규모 환경)
2. 활동 추적 — Linkedin 시작점, 사용자 클릭·페이지뷰
3. 로그 집계 — 분산 서버의 로그 중앙 수집
4. 이벤트 소싱·스트림 처리 — 도메인 이벤트 저장 + Kafka Streams 실시간 처리

각각 81편에서 왜 Kafka 가 자연스러운지 풀어 가요.

운영 모델 — 단일 / Cluster / Cloud Managed

단일 인스턴스 (개발용)

Producer → Kafka 1대 → Consumer

학습·테스트 환경. 운영 환경에서는 거의 안 씀.

Cluster (자체 운영)

Producer → [Broker 1, Broker 2, Broker 3, Broker 4, Broker 5] → Consumer
                     + KRaft 또는 Zookeeper

보통 3~10대 broker. 운영 복잡도 높음 — 모니터링·partition 재분배·rolling restart·security 등 다 책임.

Cloud Managed (AWS MSK·Confluent Cloud·Azure Event Hubs)

Producer → [관리형 Kafka 서비스] → Consumer

운영 부담 클라우드 벤더에 위임. MSK (Managed Streaming for Kafka) 처럼 비용은 높지만 운영 자유도 높음. 처음 도입 환경에서 자주 선택.

KRaft — Zookeeper 의 후속

여기까지 따라오셨다면 한 가지 의문 — "Zookeeper 라는 단어를 가끔 보던데?". 답:

전통적으로 Kafka 는 Zookeeper (별도 분산 coordination 시스템) 에 의존. 클러스터 메타데이터·controller 선출·broker registry 등. 별도 시스템 운영 부담.

Kafka 2.8+ 부터 KRaft (Kafka Raft) — Zookeeper 없이 Kafka 자체적으로 메타데이터 관리. Kafka 4.0 부터 Zookeeper 모드 deprecated.

새 도입 = KRaft 모드. 105편에서 깊이.

학습 로드맵 — 51편 어떻게 풀어 갈까

Part 5 Kafka 51편 (80~130) 의 구성:

• 5-1 기본·개념 (80~82, 3편) — intro / use cases / quickstart
• 5-2 Design (83~89, 7편) — motivation·persistence·efficiency·producer·consumer·semantics·replication
• 5-3 API (90~93, 4편) — Producer·Consumer·Admin Client
• 5-4 Configuration (94~98, 5편) — broker·topic·producer·consumer·admin config
• 5-5 Operations (99~104, 6편) — basic ops·monitoring·multi-tenancy·datacenters·geo-replication·hardware
• 5-6 고급 인프라 (105~107, 3편) — KRaft·tiered storage·log compaction
• 5-7 Internals (108~112, 5편) — log·network·message format·rebalance·transaction
• 5-8 Security (113~116, 4편) — overview·SSL·SASL·ACL
• 5-9 Connect (117~120, 4편) — overview·user guide·developer guide·config
• 5-10 Streams (121~129, 9편) — concepts·DSL·Processor API·stateful·testing·운영
• 5-11 통합 (130, 1편) — Spring Kafka

51편 안에 Kafka 의 모든 중요 영역 을 포괄. 처음 Kafka 학습 부터 프로덕션 운영·고급 패턴 까지.

시험 직전 한 번 더 — Apache Kafka 입문 함정 압축 노트

• Apache Kafka = 분산 이벤트 스트리밍 플랫폼
• 3가지 = Publish/Subscribe + Store + Process 한 시스템
• 비유 = 회사의 중앙 신경계 — 모든 데이터가 통과
• Event = key + value + timestamp + headers
• Producer = write, Consumer = read, 완전 분리
• Topic = 논리적 카테고리, 영구 저장 (전통 큐와 다름)
• Partition = topic 의 분할 단위, broker 분산, 순서 보장은 partition 안에서만
• 같은 key = 같은 partition → 순서 보장
• Broker = Kafka 서버, 여러 대 = Cluster
• Replication = partition 복제, factor 3 기본
• Redis Stream vs Kafka — 메모리·소규모 vs 디스크·대규모
• RabbitMQ vs Kafka — 큐(consume 시 제거) vs 로그(재처리 가능)
• 둘 다 대체 X — 문제가 다름
• 활용 영역 = 메시징·활동 추적·로그 집계·이벤트 소싱·스트림 처리
• 운영 모델 — 단일(개발)·Cluster(자체)·Cloud Managed
• Cloud Managed — AWS MSK·Confluent Cloud·Azure Event Hubs
• KRaft = Zookeeper 의 후속, Kafka 2.8+, 4.0 부터 기본
• Zookeeper deprecated (Kafka 4.0+) — 신규는 KRaft
• Replication factor 3 = 데이터 3 copy
• 학습 로드맵 = 11개 영역 51편 (intro→design→API→config→ops→internals→security→Connect→Streams→통합)

공식 문서: Apache Kafka Introduction 에서 자세한 사양을 확인할 수 있어요.

시리즈 다른 편 (앞뒤 글 모음)

이전 글:

• 75편 — RediSearch (FT.CREATE · FT.SEARCH · FT.AGGREGATE)
• 76편 — Redis Time Series (TS.ADD · Labels · Compaction)
• 77편 — Redis Vector Database (HNSW · 코사인 유사도 · RAG)
• 78편 — Redis Client 라이브러리 종합
• 79편 — Java Redis Client (Jedis vs Lettuce 깊이)

다음 글:

• 81편 — Kafka 활용 영역 7가지 (메시징·활동 추적·로그·이벤트 소싱)
• 82편 — Kafka Quickstart (5분 hands-on · topic·producer·consumer)
• 83편 — Kafka Design: Motivation (왜 이렇게 설계됐나)
• 84편 — Kafka Design: Persistence (디스크가 빠르다)
• 85편 — Kafka Design: Efficiency (Zero-Copy · Batch 압축)