백엔드 데이터 인프라 81편 — Kafka 활용 영역 7가지 (메시징·활동 추적·로그·이벤트 소싱)

이 글은 백엔드 데이터 인프라 시리즈 130편 중 81편이에요. 80편 에서 Kafka 의 정체성 큰 그림을 잡았다면, 이번 81편은 7가지 핵심 활용 영역 — 왜 이런 영역에서 Kafka 가 표준이 됐는지 구체적 예제로 풀어 가요.

Kafka 활용 영역이 어렵게 느껴지는 이유

Kafka 가 "이벤트 스트리밍" 이라는 추상적 개념을 푸는 도구라, 구체적 사용처가 모호 한 경우가 많아요.

첫째, 이름이 다양. 메시지 큐·이벤트 버스·로그 시스템·스트림 처리 — 다 같은 Kafka 인스턴스에서 가능하지만 어느 패턴인지 구분이 안 됨.

둘째, 회사마다 사용 패턴 다름. Netflix 는 모니터링, LinkedIn 은 활동 추적, Uber 는 위치 처리 — 비슷한 회사 안에서도 팀마다 다른 패턴.

이 글에서 7가지 클래식 활용 영역 을 구체적 예제와 함께 풀어요.

1. 메시징 (Messaging)

패턴

Service A → Kafka Topic → Service B
                       → Service C (병렬)

마이크로서비스 간 비동기 메시지. RabbitMQ (전통 메시지 broker)·ActiveMQ (자바 진영 표준 broker) 같은 기존 시스템 대체.

Kafka 가 자연스러운 이유

초당 수만~수십만 건의 대량 메시지 에 강하고, 디스크에 1급으로 적재돼 내구성 이 보장돼요. Consumer 가 여러 명 — 같은 메시지를 여러 서비스가 동시에 처리하고, consumer 가 실수로 잘못 처리해도 offset (consumer 의 읽기 위치 포인터) 되감기 로 재처리 가 가능해요.

구체적 예제

주문이 들어오면 orders 토픽에 publish 하고, 결제 서비스·재고 서비스·알림 서비스가 각자 같은 메시지를 처리 해요. 한 서비스에 문제가 생겨도 나머지는 정상 처리.

vs RabbitMQ — 언제 Kafka?

초당 만 건 이상 대량 처리 와 재처리·과거 메시지 분석 이 핵심이면 Kafka, header·topic exchange 같은 복잡한 라우팅 이나 동기적 RPC 비슷한 흐름 이 핵심이면 RabbitMQ.

2. 웹사이트 활동 추적 (Activity Tracking)

Kafka 의 원래 use case. LinkedIn 이 수많은 사용자 활동 (페이지 뷰·검색·클릭) 을 처리하려고 만든 시스템.

패턴

Web App → Kafka Topic "user-clicks" → Real-time Analytics
                                    → Batch (Hadoop) Analytics
                                    → ML 추천 시스템

각 활동 타입별 별도 topic — page-views·searches·clicks·form-submits. 하나의 활동이 여러 시스템 에서 처리돼요. 위 그림에서 등장하는 Hadoop 은 분산 배치 처리 프레임워크예요.

Kafka 가 자연스러운 이유

사용자 1억 × 페이지 N 개 = 수십억 이벤트/일 규모의 매우 대용량 트래픽을 받고, 실시간 분석 + batch + 추천 처럼 여러 consumer 가 동시에 붙어요. 영구 보존 덕에 과거 데이터로 재분석하거나 새 ML 모델을 학습시키기도 좋아요.

구체적 예제

사용자가 페이지를 본 순간 page-views topic 에 이벤트가 들어가요. 실시간 시스템 은 추천 모델에 즉시 입력하고, Batch 시스템 은 매일 밤 Hadoop 으로 옮겨 통계를 돌리고, 모니터링 은 인기 페이지 trending 을 잡아요.

3. 메트릭 (Metrics) — 운영 모니터링

패턴

Server 1 → metrics → Kafka Topic "server-metrics" → Aggregator → Grafana
Server 2 → metrics →
Server N → metrics →

분산된 수많은 서버·서비스에서 메트릭을 수집 해 중앙에서 집계. 여기 등장하는 Grafana 는 메트릭 시각화 대시보드예요.

Kafka 가 자연스러운 이유

수만 대 서버 의 메트릭을 한 곳에 손실 없이 모으고, Grafana·Prometheus 변환·알림·장기 보관처럼 다양한 후속 처리 로 흘려보낼 수 있어요.

Kafka vs Prometheus

Prometheus (메트릭 수집·저장 시스템) 는 pull 모델로 직접 메트릭을 저장하고 쿼리 까지 해요. 반면 Kafka 는 push 모델로 메트릭 transport (전달) 만 담당하고 저장은 별도 시스템에 맡겨요.

일반적 패턴은 Prometheus + Kafka 조합이거나, Kafka → Elasticsearch (검색·분석 엔진) / InfluxDB·TimescaleDB (시계열 DB).

4. 로그 집계 (Log Aggregation)

패턴

App Server logs → Kafka Topic "app-logs" → Elasticsearch / S3 / HDFS

분산된 모든 서버의 로그 파일 을 중앙에 모아요. Scribe·Flume (페이스북·아파치의 전통 로그 수집 도구) 같은 기존 로그 시스템 대체.

Kafka 가 자연스러운 이유

대량 로그 를 안정적으로 처리하고, 로그 발생부터 검색 가능 시점까지 수 초~수 분 의 낮은 지연이에요. 재처리 가능 덕에 분석 도구를 바꿔도 과거 로그를 재인덱싱 할 수 있어요.

구체적 흐름

[App] → Filebeat → Kafka "logs-prod" → Logstash → Elasticsearch → Kibana
                                     → S3 (장기 보관)
                                     → 알림 시스템

여기서 Filebeat 은 로그 파일을 수집해 보내는 경량 agent, Logstash 는 로그 가공·라우팅 엔진, Kibana 는 Elasticsearch 위의 시각화 UI 예요. 셋을 묶은 ELK (Elasticsearch·Logstash·Kibana) + Kafka 가 운영 로그 인프라의 표준 패턴.

5. 스트림 처리 (Stream Processing)

패턴

Raw 이벤트 → Kafka "input" → Kafka Streams (또는 Flink) → Kafka "output" → ...

여러 단계 처리 파이프라인 — 변환·필터·집계·조인.

Kafka 가 자연스러운 이유

Kafka Streams 는 Kafka 안에 내장된 경량 스트림 처리 라이브러리 (121~129편) 라 Topic-to-Topic 흐름이 자연스럽고, 상태 저장·윈도우·조인 같은 복잡한 패턴 도 지원해요. 외부 도구인 Flink (분산 스트림·배치 처리 엔진)·Spark Streaming (Spark 의 스트림 처리 모듈) 과의 통합도 매끄러워요.

구체적 예제 — 뉴스 추천 파이프라인

RSS 크롤 → "articles-raw"
         → 중복 제거·정규화 → "articles-clean"
         → 카테고리 분류 → "articles-categorized"
         → 사용자 매칭 → "recommendations"
         → 알림 발송

각 단계가 독립 서비스 고 Kafka 가 중간 buffer 역할을 해요. 한 단계가 느려져도 전체가 멈추지 않아요 — Kafka 가 받아 두니까.

6. 이벤트 소싱 (Event Sourcing)

패턴

도메인 이벤트 → Kafka "events" → ...
                              → 현재 상태 재계산
                              → 다른 시스템 sync

"상태를 직접 저장하지 않고, 상태 변화 이벤트만 저장" — Martin Fowler 의 Event Sourcing 패턴.

Kafka 가 자연스러운 이유

대규모 이벤트 로그 를 영구 저장하는 게 Kafka 의 본질이고, partition 안에서 순서 보장 이 돼요. 과거 이벤트로 상태를 재계산 하는 재처리 가 가능하고, 여러 consumer 가 한 이벤트 stream 을 DB·검색·캐시·외부 시스템 으로 동시에 동기화할 수 있어요.

구체적 예제 — 은행 계좌

"이체 +100" "이체 -50" "이자 +5" → Kafka "account-events"
                                  → 현재 잔액 = 모든 이벤트 재계산
                                  → 거래 내역 검색 (Elasticsearch)
                                  → 사기 탐지 (실시간 분석)
                                  → 회계 시스템 (배치)

전통 RDBMS 는 현재 잔액만 저장해요. Event Sourcing 은 모든 변화 를 저장해서 시간 여행·감사·디버깅 이 모두 가능해져요.

7. Commit Log

패턴

분산 시스템의 내부 commit log 로 Kafka 를 써요. 노드 간 상태 복제 와 복구 메커니즘 역할.

Kafka 가 자연스러운 이유

Log Compaction (107편) 으로 키별 최신 값만 유지 하면 infinite retention 이 가능하고, 내구성과 복제 도 자체 분산으로 보장돼요. Apache BookKeeper (전문 분산 로그 저장 시스템) 같은 도구를 대체할 수 있어요.

구체적 예제

분산 캐시 시스템의 write-ahead log, 마이크로서비스 outbox pattern (트랜잭션과 메시지 발행의 일관성을 보장하는 패턴) 의 메시지 저장소, Database CDC (Change Data Capture) 의 sink 등.

영역별 선택 요약

도입 시점 — 언제 Kafka?

여기서 정말 중요한 자리. "Kafka 가 좋다" 와 "내 시스템에 필요하다" 는 다른 질문.

Kafka 가 필요한 신호

메시징 처리량이 초당 1만 건 이상 이거나, 재처리·과거 분석 이 자주 일어나거나, 여러 시스템이 같은 데이터 stream 을 처리해야 하거나, 데이터 영구 보존 이 필요하거나, 이벤트 기반 아키텍처 로 가는 길목.

Kafka 가 과한 신호

메시징이 초당 100 건 미만에 간단한 작업 큐 면 과해요. 복잡한 라우팅 이 핵심이면 RabbitMQ 가 낫고, 운영 인력 부담이 결정적이거나 단순 큐 만 필요하면 Redis Stream 또는 SQS (AWS 의 관리형 메시지 큐) 가 충분해요.

회사 단계별

• 스타트업 초기 (1~5명) — Redis Stream / SQS 충분
• 중간 규모 (100명) — Kafka 도입 고려, Cloud Managed (MSK (AWS 관리형 Kafka)·Confluent Cloud (Kafka 창시자들이 만든 관리형 플랫폼))
• 대규모 (1000명+) — Kafka 자체 운영 또는 Managed 적극 활용
• 데이터 중심 기업 (LinkedIn·Netflix·Uber) — Kafka 인프라 핵심

시험 직전 한 번 더 — Kafka 활용 함정 압축 노트

• 7가지 활용 = 메시징·활동 추적·메트릭·로그 집계·스트림 처리·이벤트 소싱·Commit Log
• Kafka 원래 use case = 활동 추적 (LinkedIn)
• vs RabbitMQ — 대량·재처리·여러 consumer 면 Kafka / 복잡 라우팅이면 RabbitMQ
• vs Prometheus — Prometheus 는 메트릭 자체 저장+쿼리 / Kafka 는 transport
• 일반 패턴 = Prometheus + Kafka 조합
• 로그 집계 = ELK + Kafka 표준
• 스트림 처리 = Kafka Streams (내장) + 외부 Flink·Spark
• 이벤트 소싱 = 상태 저장 X, 상태 변화 이벤트만
• 비유 — 은행 계좌 (모든 거래 = 이벤트, 잔액 = 재계산)
• Commit Log = Log Compaction 으로 infinite retention
• 도입 신호 — 대량 메시징·재처리·여러 consumer·영구 보존·이벤트 기반
• 과한 신호 — 소규모·복잡 라우팅·단순 큐
• 스타트업 = Redis Stream/SQS, 중간 = Cloud Managed, 대규모 = 자체+Managed
• 운영 부담 = Kafka 도입의 가장 큰 비용
• 처음 도입 환경 = Cloud Managed (AWS MSK·Confluent Cloud) 권장

공식 문서: Apache Kafka Uses 에서 자세한 활용 사례를 확인할 수 있어요.

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

이전 글:

• 76편 — Redis Time Series (TS.ADD · Labels · Compaction)
• 77편 — Redis Vector Database (HNSW · 코사인 유사도 · RAG)
• 78편 — Redis Client 라이브러리 종합
• 79편 — Java Redis Client (Jedis vs Lettuce 깊이)
• 80편 — Apache Kafka란 + 이벤트 스트리밍의 표준

다음 글:

• 82편 — Kafka Quickstart (5분 hands-on · topic·producer·consumer)
• 83편 — Kafka Design: Motivation (왜 이렇게 설계됐나)
• 84편 — Kafka Design: Persistence (디스크가 빠르다)
• 85편 — Kafka Design: Efficiency (Zero-Copy · Batch 압축)
• 86편 — Kafka Design: Producer (Partition 선택·ACK·Idempotent)