Apache Kafka 입문 정리 시리즈 첫 번째 글. 이름과 용어가 외국 SF 같아서 처음 보면 막막한 카프카를 회사 중앙 우체국 비유로 풀어가며 — 왜 만들어졌는지(데이터 통합 문제), 어디에 어떻게 쓰는지(7가지 사용 사례), 이벤트 스트리밍 개념, Connect·Streams·Schema Registry 같은 생태계 도구들의 자기 자리, Zookeeper에서 KRaft로의 전환까지 친절하게 풀어쓴 1편.
이 글은 Apache Kafka 입문 정리 시리즈의 첫 번째 편입니다. 카프카(Kafka)는 빅데이터·마이크로서비스·실시간 분석 같은 단어가 나오는 자리에 거의 항상 등장하는데, 막상 처음 펼치면 Topic·Partition·Offset·Broker·Zookeeper 같은 단어가 줄지어 나와서 "이거 학습 비용이 만만찮겠네" 하는 생각이 듭니다.
다행히 카프카는 한 번 큰 그림을 잡아 두면 그 위에 디테일이 자연스럽게 얹히는 구조예요. 이 시리즈는 7편을 통해 그 큰 그림과 디테일을 차근차근 쌓아 갑니다. 한 번에 다 외우려 하지 마시고, 이번 1편에서는 "카프카가 도대체 뭘 해 주는 시스템인가, 왜 만들어졌는가, 어디에 쓰는가" — 이 세 가지 질문의 답만 머리에 넣고 넘어가셔도 됩니다.
이 시리즈는 Apache Kafka 공식 문서, Confluent 학습 자료, 여러 분산 시스템 강의 노트 등 공개 자료를 참고해 한국어 학습 노트로 풀어쓴 자료입니다.
로컬에 Docker로 카프카 한 노드를 띄우고 토픽 하나를 만들어 메시지를 직접 넣고 빼 보면 흐름이 한 번에 잡혀요.
왜 카프카가 처음엔 어렵게 느껴질까요
이유는 세 가지예요.
첫째, 용어가 외국 SF 같아요. Topic·Partition·Offset·Broker·Zookeeper·KRaft·ISR·Consumer Group — 한 페이지에 이 단어가 다 나오면 "이게 다 뭐야?" 싶어집니다. 같은 한국어 단어로 바꿔 쓸 수 있는 게 거의 없어서 더 어렵죠.
둘째, "이게 메시지 큐랑 뭐가 달라?"라는 의문이 안 풀려요. RabbitMQ·ActiveMQ 같은 메시지 큐를 이미 알고 있다면, 카프카가 그것의 더 빠른 버전인지, 아예 다른 도구인지 처음엔 잘 안 보입니다.
셋째, 분산 시스템이라 동작 원리가 한 번에 안 잡혀요. 카프카는 여러 서버(브로커)가 묶여 함께 일하는 구조라, "어디에 메시지가 저장되는가, 한 서버가 죽으면 어떻게 되는가" 같은 의문이 차곡차곡 쌓여요.
해결법은 한 가지예요. 카프카를 "회사 안 중앙 우체국" 이라고 비유로 잡고, 거기에 "여러 우체국 지점이 묶인 분산 우체국 시스템"이라는 그림을 얹어 풀면 갑자기 명확해집니다. 글 쓰는 사람(Producer)이 우체국에 편지(메시지)를 부치고, 받는 사람(Consumer)이 자기가 구독한 게시판(Topic)에서 편지를 가져가는 식이에요. 이 글은 그 비유를 따라 처음부터 풀어 갑니다.
카프카가 풀어 주는 문제 — 데이터 통합의 난리통
카프카가 왜 만들어졌는지부터 짚고 가는 게 가장 빠릅니다. 답은 한 줄로 — 회사 안 시스템이 늘어나면 시스템 간 연결이 미친 듯이 복잡해지기 때문이에요.
회사 비유로 풀어 봅시다. 처음에는 회사 안에 시스템 두세 개만 있어요. 웹사이트가 데이터베이스에 직접 쓰고, 분석 시스템이 데이터베이스에서 직접 읽고. 단순하죠.
그런데 시간이 지나면서 시스템이 자꾸 늘어납니다. 소스 시스템 4개와 타겟 시스템 6개가 있다고 해 봅시다. 이걸 다 연결하려면 몇 개의 통합 코드가 필요할까요?
[소스 시스템] [타겟 시스템]
웹사이트 이벤트 ──────▶ 데이터베이스
가격 데이터 ──────▶ 분석 시스템
금융 거래 ──────▶ 이메일 서비스
사용자 상호작용 ──────▶ 감사 시스템답은 4 × 6 = 24개. 4개 소스가 각자 6개 타겟에 다 연결돼야 하니까요. 시스템이 10개씩만 돼도 100개 연결, 30개씩이면 900개 연결이 필요해집니다.
게다가 각 연결마다 다음 같은 어려움이 깔립니다.
- 프로토콜 다양성 — TCP·HTTP·REST·FTP·JDBC 등 전송 방식이 제각각
- 데이터 포맷 다양성 — Binary·CSV·JSON·Avro·Protobuf 등 파싱 방식이 다름
- 스키마 변화 — 한쪽에서 데이터 구조 바꾸면 연결된 모든 곳이 깨짐
- 부하 폭증 — 한 소스가 N개 타겟에 동시에 보내야 하니 부하가 N배
이걸 풀려고 등장한 게 카프카입니다. 소스와 타겟 사이에 카프카라는 중앙 허브를 놓아 모든 연결을 카프카 하나로 모으는 거예요.
[소스 시스템] [타겟 시스템]
웹사이트 이벤트 ─┐ ┌─▶ 데이터베이스
가격 데이터 ─┤ ├─▶ 분석 시스템
금융 거래 ─┼─▶ KAFKA─┤─▶ 이메일 서비스
사용자 상호작용 ─┘ └─▶ 감사 시스템이제 소스 시스템은 카프카에만 데이터를 보내고(Producer 역할), 타겟 시스템은 카프카에서만 가져갑니다(Consumer 역할). 카프카가 모든 데이터 스트림을 내부에 저장하고 분배해요.
회사 비유로 — 직원들이 다른 부서에 자료를 보낼 때마다 일일이 들고 가는 게 아니라, 한 곳에 있는 중앙 우체국에 부치고, 받을 사람이 가서 가져가는 식입니다. 우체국이 모든 통신을 표준화해 주니까 부서 간 연결이 깔끔해져요.
카프카는 어디서 왔고 무엇이 특별한가
카프카는 2011년 LinkedIn에서 만들어 오픈소스로 공개한 프로젝트입니다. 지금은 Confluent·IBM·Cloudera·LinkedIn 같은 대기업이 같이 관리하고, 라이선스는 Apache License 2.0이에요. 더 깊은 정의·동작 원리는 Kafka 공식 문서에 자세히 정리돼 있으니, 한 번 훑어 두면 두고두고 찾아보게 됩니다.
특징을 한 표에 정리하면:
| 특징 | 설명 |
|---|---|
| 분산 아키텍처 | 여러 브로커로 구성된 클러스터 형태 |
| 내구성(Durability) | 디스크에 데이터 영속 저장 |
| 수평 확장성 | 브로커 추가로 처리량 선형 확장 가능 |
| 고처리량 | 초당 수백만 건 메시지 처리 가능 |
| 저지연 | 10ms 이하의 실시간 처리 |
| 내결함성 | 브로커 장애 시 자동 복구 |
| 무중단 업그레이드 | 롤링 업그레이드로 다운타임 없음 |
여기서 시험 함정이 하나 있어요. "카프카는 메시지 큐의 더 빠른 버전이다" 라는 단순화는 부정확합니다. 카프카는 로그 기반(append-only log) 시스템이고, 메시지를 큐에서 가져가면 사라지는 RabbitMQ 같은 메시지 큐와 동작 모델이 달라요. 카프카는 메시지를 디스크에 영속 저장하고, 여러 소비자가 같은 데이터를 각자의 속도로 여러 번 읽을 수 있습니다.
규모를 보면 위치가 와닿아요.
- 2,000개 이상의 회사가 공개적으로 카프카 사용 중
- 포춘 100대 기업의 80% 가 활용
- LinkedIn·Airbnb·Netflix·Uber·Walmart 등 대형 기업 거의 다 사용
이제는 사실상 분산 시스템·실시간 데이터 인프라의 표준이에요.
카프카는 어디에 쓰는가 — 7가지 대표 사용 사례
이름과 동작 원리만 봐서는 "그래서 뭐에 쓰는데?"가 안 와 닿습니다. 7가지 대표 자리를 한 번에 풀어 갈게요.
메시지 시스템 (Message Bus)
ActiveMQ·RabbitMQ 같은 기존 메시지 큐를 대체하는 고성능 메시지 브로커로 활용. 마이크로서비스 간 이벤트 기반 통신에 자주 씁니다. 회사 비유로 — 부서 간 자료 전달을 매번 직접 들고 다니는 대신 사내 메일 시스템으로 처리하는 식이에요.
활동 추적 (Activity Tracking)
웹·앱에서 사용자의 모든 행동(클릭·페이지뷰·구매 등)을 실시간으로 수집·분석. 사실 카프카가 LinkedIn에서 처음 만들어진 이유가 이거예요.
대표 사례 — Netflix가 사용자의 시청 행동을 카프카로 흘려보내 추천 시스템에 즉시 반영합니다. "방금 본 드라마와 비슷한 작품"이 몇 초 만에 떠오르는 비결.
메트릭과 로그 수집
분산된 여러 서버·앱의 로그·메트릭을 한 곳으로 모으는 자리. ELK 스택·Splunk·CloudWatch 같은 도구와 자주 묶어 씁니다.
스트림 처리 (Stream Processing)
실시간으로 데이터를 변환·분석하는 파이프라인의 중심.
실시간 데이터 스트림 → Kafka → Kafka Streams/Spark/Flink → 결과 저장대표 사례 — Uber가 사용자·택시·운행 데이터를 실시간 수집해 수요 예측·동적 가격 책정에 활용해요.
이벤트 소싱 (Event Sourcing)
모든 상태 변경을 이벤트로 저장해 시스템의 완전한 감사 로그를 유지하는 패턴. 회사 비유로 — 통장에 잔액만 적어 두는 게 아니라 모든 입출금 기록을 그대로 보관해서 언제든 어떻게 그 잔액이 됐는지 거꾸로 추적할 수 있게 하는 식.
마이크로서비스 디커플링
서비스 간 직접 연결 대신 카프카를 통한 비동기 통신으로 서비스 의존성을 낮춤. LinkedIn이 스팸 방지·사용자 상호작용 수집·실시간 연결 추천에 활용해요.
빅데이터 통합
Hadoop·Spark·Flink 같은 빅데이터 기술과 통합해 대규모 데이터 파이프라인 구축. 카프카가 "데이터 고속도로" 역할을 하는 자리.
> 한 줄 정리 — 카프카는 "여러 시스템 사이의 데이터 운반"이 필요한 거의 모든 자리에 쓰일 수 있다. 메시지 큐·로그 수집·스트리밍·이벤트 소싱·디커플링 — 결국 다 같은 뿌리.
이벤트 스트리밍 — 카프카의 본질 개념
카프카를 한 단어로 정의하면 "이벤트 스트리밍 플랫폼" 입니다. 이 단어가 뭘 의미하는지 풀어 봅시다.
이벤트(Event)란
시간의 특정 순간에 발생한 사실(fact)의 기록이 이벤트입니다. 예를 들어:
{
"event_type": "user_purchase",
"user_id": "user123",
"product_id": "prod456",
"amount": 99.99,
"timestamp": "2024-01-15T10:30:00Z"
}"2024년 1월 15일 10시 30분, user123이 prod456을 99.99달러에 샀다" — 이게 한 이벤트입니다. 이벤트는 변경 불가능한 사실이에요. 한 번 일어난 일은 다시 일어나지 않게 만들 수 없죠.
이벤트 스트리밍
연속적으로 발생하는 이벤트 흐름을 실시간으로 처리하는 패러다임이 이벤트 스트리밍입니다. 배치 처리와 달리 데이터가 생성되는 즉시 처리해요.
배치 처리와 스트림 처리의 차이를 한 번에 보면 이해가 쉬워요.
| 구분 | 배치 처리 | 스트림 처리 |
|---|---|---|
| 처리 시점 | 정해진 시간 (새벽 2시 등) | 데이터 발생 즉시 |
| 지연(Latency) | 수 시간 ~ 하루 | 밀리초 ~ 초 |
| 복잡도 | 낮음 | 높음 |
| 사용 사례 | 리포트, 분석 | 알림, 사기 탐지, 실시간 대시보드 |
여기서 시험 함정이 하나 있어요. "스트림 처리가 더 좋은 거 아닌가요?"라는 의문이 들 수 있는데, 꼭 그렇지는 않습니다. 매일 새벽 한 번 돌리는 매출 리포트 같은 작업은 배치 처리가 훨씬 단순하고 비용도 저렴해요. 스트림 처리는 실시간성이 정말 필요할 때 쓰는 거지, 만능 무기가 아닙니다.
카프카 생태계 — 카프카 본체와 친구들
카프카는 그 자체로도 강력하지만, 주변에 함께 쓰는 도구가 잘 갖춰져 있어 전체 생태계로 봐야 그림이 완성됩니다.
┌─────────────────────────────────────────┐
│ Apache Kafka 생태계 │
│ │
│ Producer ──▶ [Kafka Cluster] ──▶ Consumer
│ │ │
│ [Kafka Connect] │
│ [Kafka Streams] │
│ [Schema Registry] │
│ [ksqlDB] │
└─────────────────────────────────────────┘각자의 자리를 한 줄씩 풀어 봅니다.
Kafka Connect — 외부 시스템 자동 연결 케이블
회사 비유로 — 카프카(중앙 우체국)와 외부 시스템(데이터베이스·검색 엔진·S3 등)을 연결하는 표준 케이블이에요. 매번 코드를 짜서 연결하는 대신 미리 만들어진 커넥터를 꽂으면 됩니다. 자세한 동작은 Kafka Connect 공식 문서에서 확인할 수 있어요.
- 소스 커넥터 — 외부 시스템에서 데이터를 가져와 카프카에 넣음
- 싱크 커넥터 — 카프카에서 데이터를 가져와 외부 시스템에 넣음
- 커넥터 허브 — 212개 이상의 사전 제작 커넥터 제공 (Confluent Hub)
대표 커넥터 — Twitter·Wikipedia·PostgreSQL·MongoDB·Elasticsearch·Amazon S3 등 거의 모든 데이터 시스템에 대해 이미 만들어져 있어요.
Kafka Streams — 실시간 가공 라인
카프카 안에서 데이터 처리·변환을 수행하는 라이브러리입니다. 별도 클러스터를 띄울 필요 없이 표준 Java 애플리케이션으로 실행돼요. 카프카에서 데이터를 읽어 변환한 뒤 다시 카프카에 쓰는 패턴.
가장 큰 강점이 정확히 한 번(Exactly Once) 처리 보장. 분산 시스템에서 정말 어려운 문제인데, Kafka Streams는 이걸 라이브러리 수준에서 해결해 줍니다.
Schema Registry — 데이터 형식 표준 관리실
회사 비유로 — 모든 부서가 자료 양식을 통일해 쓸 수 있게 표준 양식을 중앙에서 관리하는 부서. 카프카로 흘러가는 데이터의 스키마(구조)를 한 곳에서 관리하고, 잘못된 형식의 데이터가 들어가는 걸 사전에 막아 줘요.
지원 포맷 — Avro·Protobuf·JSON Schema 세 가지.
여기서 시험 함정이 하나 있어요. Schema Registry가 없어도 카프카는 동작합니다. 다만 데이터 포맷이 바뀔 때 전 시스템이 깨지는 사고를 막으려면 사실상 필수예요. 본격 운영에서는 거의 다 같이 씁니다.
ksqlDB·Kafka 관리 UI — 보조 도구
ksqlDB는 SQL로 카프카 스트림을 처리하는 도구이고, Kowl·AKHQ·Conduktor 같은 카프카 관리 UI를 같이 쓰면 토픽 관리·모니터링·Consumer Group 추적이 한 화면에서 깔끔하게 됩니다.
> 한 줄 정리 — 카프카 본체는 데이터 운반만, 외부 시스템 연결은 Kafka Connect, 실시간 변환은 Kafka Streams, 데이터 양식 표준화는 Schema Registry. 자기 자리가 명확합니다.
카프카 버전과 KRaft 전환 — 알아둘 큰 변화
카프카가 10년 넘은 프로젝트라 버전마다 의미 있는 변화가 있어요. 큰 흐름만 외우면 됩니다.
| 버전 | 주요 변화 |
|---|---|
| Kafka 0.10 | Consumer Offset을 Zookeeper가 아닌 카프카 내부 토픽(__consumer_offsets)에 저장 |
| Kafka 2.4 | Consumer가 가장 가까운 복제본(Replica)에서 읽는 기능 추가 |
| Kafka 2.8 | KRaft 모드 미리보기 (Zookeeper 없이 실행 가능) |
| Kafka 3.0 | Producer 기본값이 안전한 설정으로 변경 (acks=all, idempotence=true) |
| Kafka 3.3.1 | KRaft 모드 정식 지원 (프로덕션 사용 가능) |
| Kafka 4.0 | Zookeeper 완전 제거, KRaft 전용 |
Zookeeper에서 KRaft로
여기서 시험·실무 모두에 자주 등장하는 큰 변화가 Zookeeper에서 KRaft(Kafka Raft)로의 전환입니다.
Zookeeper는 분산 시스템의 메타데이터(누가 리더인지, 어떤 노드가 살아 있는지 같은)를 관리하는 별도 시스템이에요. 옛날 카프카는 이 Zookeeper에 의존했는데, 다음 같은 문제가 누적됐어요.
- 파티션이 10만 개를 넘으면 확장성 한계
- 별도의 Zookeeper 클러스터를 따로 관리해야 함
- 보안 모델 이중화 (카프카 보안 + Zookeeper 보안 따로)
- 컨트롤러 종료·복구 시간이 길었음
KRaft 모드는 이 문제를 풀려고 카프카 안에 Raft 합의 알고리즘을 직접 박은 거예요. 장점이 분명해요.
- 수백만 개 파티션까지 확장 가능
- 단일 보안 모델 — 카프카만 보호하면 됨
- 단순화된 아키텍처 — 외부 의존성 제거
- 빠른 컨트롤러 페일오버
여기서 시험 함정이 하나 있어요. Kafka 4.0부터는 Zookeeper가 완전히 제거됐습니다. 새로 시작하는 프로젝트는 무조건 KRaft예요. 옛날 자료에 나오는 "Zookeeper 설정" 같은 내용은 4.0 이후에선 의미가 없습니다.
카프카가 적합한 자리 vs 적합하지 않은 자리
카프카가 만능은 아니에요. 다음 자리에서 빛납니다.
적합한 경우
- 여러 시스템 간 실시간 데이터 이동이 필요할 때
- 초당 수천 건 이상 이벤트 처리가 필요할 때
- 여러 소비자가 같은 데이터를 독립적으로 처리해야 할 때 (이게 RabbitMQ와 다른 결정적 차이)
- 데이터 파이프라인의 디커플링이 필요할 때
적합하지 않은 경우
- 소량 데이터 처리 — 카프카는 분산 시스템이라 운영 부담이 큰데, 소량이면 그 부담 대비 이득이 적음
- 단순한 큐잉만 필요 — RabbitMQ가 더 간단할 수 있음
- 복잡한 쿼리 — 카프카는 SQL 같은 쿼리 도구가 아니에요. 데이터베이스 사용 권장
여기서 정말 중요한 시험 함정 — 카프카는 운반 메커니즘(Transport Mechanism)이지 데이터 처리 시스템이 아닙니다. 카프카 자체는 데이터를 이해하거나 처리하지 않아요. 단순히 바이트 스트림을 빠르고 안정적으로 운반하는 게 핵심 역할입니다. 비즈니스 로직은 Producer와 Consumer 안에 구현돼요.
이걸 헷갈려서 "카프카에 SQL 쿼리를 던지면 되지 않나요?" 같은 시도를 하면 안 됩니다. 그건 데이터베이스나 ksqlDB의 자리예요.
시험 직전 한 번 더 — 자주 헷갈리는 함정 모음
여기까지가 카프카 1편의 핵심입니다. 실무에서나 면접에서 헷갈릴 때 다시 펼쳐 볼 수 있게 압축 노트로 마무리할게요.
- 카프카는 소스/타겟 시스템 사이의 중앙 허브 — N×M 통합을 N+M으로 줄임
- 2011년 LinkedIn에서 만들어 오픈소스화 (Apache License 2.0)
- 메시지 큐와 다름 — 로그 기반(append-only), 메시지 영속 저장, 여러 소비자가 각자 속도로 다회 읽기
- 7가지 사용 사례 — 메시지 시스템·활동 추적·로그/메트릭 수집·스트림 처리·이벤트 소싱·MSA 디커플링·빅데이터 통합
- 이벤트 = 시간의 특정 순간에 발생한 사실의 기록 (변경 불가능)
- 배치 = 정해진 시간에 한꺼번에 / 스트림 = 발생 즉시
- 카프카 본체 = 운반, Connect = 외부 시스템 연결, Streams = 실시간 변환, Schema Registry = 양식 표준, ksqlDB = SQL로 스트림 처리
- Kafka Streams = Exactly Once 처리 보장 (라이브러리 수준)
- Schema Registry — Avro·Protobuf·JSON Schema 지원
- Kafka 3.0 — Producer 기본값이 안전 설정 (acks=all, idempotence=true)
- Kafka 3.3.1 — KRaft 모드 프로덕션 정식 지원
- Kafka 4.0 — Zookeeper 완전 제거, KRaft 전용
- KRaft 장점 — 수백만 파티션 확장, 단일 보안 모델, 단순 아키텍처, 빠른 페일오버
- 카프카는 운반 메커니즘 — 데이터 처리·쿼리 시스템 아님
- 적합 — 여러 시스템 실시간 통합, 초당 수천+ 이벤트, 다중 소비자, 디커플링
- 부적합 — 소량 데이터, 단순 큐잉, 복잡한 쿼리
시리즈 다른 편
같은 시리즈의 다른 글들도 같은 친절 톤으로 묶어 정리되어 있어요.