← Kafka 모듈로

Learn · Glossary

Kafka 용어 사전

총 67개 용어

로드맵 보기

__cluster_metadata

KRaft 컨트롤러 쿼럼이 클러스터 메타데이터를 저장·복제하는 내부 시스템 토픽. 일반 Kafka 토픽처럼 복제·압축·스냅샷 메커니즘을 그대로 활용한다.
ZooKeeper에서 KRaft로 — 클러스터 메타데이터 관리의 세대교체 · kafka_ref_01(Q10-13)의 최신 서술을 정확한 기준으로 삼아, kafk_ref_02(Q5,Q6,Q16 — 'ZooKeeper 없이는 Kafka 서버에 연결할 수 없다', 'Kafka 서버를 시작하려면 반드시 ZooKeeper를 먼저 띄워야 한다'), kafka_ref_04('Kafka는 3.x대에 KRaft로 이동 중'이라는 진행형 서술), kafka_ref_05(Q1,Q14 — ZooKeeper를 여전히 현재의 표준 아키텍처로, KRaft를 '미래에 없앨 대상'으로 서술)의 오래된 내용을 Kafka 4.0 기준(ZooKeeper 모드 완전 제거)으로 수정.

KRaft 컨트롤러 쿼럼이 클러스터 메타데이터(리더/ISR 변경 포함)를 기록하는 내부 토픽. 브로커들은 이 로그를 재생해 최신 상태를 반영한다.
클러스터 운영 — 컨트롤러, 랙 어웨어니스, 파티션 설계, 멀티테넌시 · 50 Kafka Interview Questions for Data Engineers (2026), Q5, Q21, Q29, Q33, Q40, Q43, Q45, Q49, FAQ('How does Kafka handle replication?'). Q21의 컨트롤러 설명(ZK 시대의 'LeaderAndIsr 요청 전송' 서술)과 FAQ의 'ZooKeeper or KRaft가 새 리더를 선출' 서술을 현재(4.0+) KRaft 단일 체제 기준으로 정정. Q49의 '2-3배 과잉 파티셔닝' 서술에 과잉 파티셔닝의 실제 비용을 보강.

Amazon MSK

AWS가 브로커 패치·모니터링·교체를 대신 관리해주는 Kafka 완전관리형 서비스. 토픽·설정·컨슈머 관리 책임은 여전히 사용자에게 있다.
스트리밍 플랫폼 선택 기준, 비용 크로스오버, MSK/Confluent Cloud, 흔한 실수 · Kafka vs Kinesis vs Pub/Sub 2026: Streaming Platform Showdown — Pricing Reality Check, When to Choose What, What About Amazon MSK?, Common Mistakes 섹션. 가격 수치는 원문이 '2026년 초 공개 가격 기준 추정치이며 실제 비용은 다를 수 있다'고 명시한 예시 추정값이므로 그대로 예시로 다루고 절대 기준으로 취급하지 않는다.

Confluent Cloud

AWS/GCP/Azure에서 동작하는 완전관리형 Kafka 서비스. Schema Registry, ksqlDB, 200+ 커넥터, 클러스터 링킹을 제공하며 MSK보다 비싼 대신 기능이 넓다.
스트리밍 플랫폼 선택 기준, 비용 크로스오버, MSK/Confluent Cloud, 흔한 실수 · Kafka vs Kinesis vs Pub/Sub 2026: Streaming Platform Showdown — Pricing Reality Check, When to Choose What, What About Amazon MSK?, Common Mistakes 섹션. 가격 수치는 원문이 '2026년 초 공개 가격 기준 추정치이며 실제 비용은 다를 수 있다'고 명시한 예시 추정값이므로 그대로 예시로 다루고 절대 기준으로 취급하지 않는다.

CooperativeStickyAssignor

Kafka 2.4부터 제공되는 파티션 할당 전략. 리밸런싱 시 실제로 이동이 필요한 파티션만 반납·재배정해 그룹 전체가 멈추는 것을 피한다.
프로듀서 신뢰성과 컨슈머 그룹 — acks, 멱등성, 트랜잭션, 리밸런싱 · kafk_ref_03(Section 3 프로듀서, Section 4 컨슈머 메커니즘), kafka_ref_01(Q35-58,75), kafka_ref_05(Q9) 종합. kafk_ref_03의 '리밸런싱은 항상 stop-the-world' 서술을 CooperativeStickyAssignor(2.4+) 및 KIP-848(Kafka 4.0 GA) 기준으로 수정했고, 'EOS는 약 10~20% 지연 오버헤드를 추가한다'는 구체 수치 주장은 근거 불명확하여 '워크로드에 따라 달라지는 실질적 오버헤드'로 완화.

CreateTopicPolicy / AlterConfigPolicy

토픽 생성이나 설정 변경 요청을 검증하는 커스텀 정책 플러그인 인터페이스. KRaft 모드에서는 브로커가 아닌 컨트롤러 프로세스에서 실행된다.
KRaft 모드에서 달라지는 설정·메트릭·기능 · Section 6: KRaft vs ZooKeeper — Differences Between KRaft mode and ZooKeeper mode (pp.34-40)

delivery.timeout.ms

프로듀서가 레코드 전송을 재시도하는 것까지 포함해 성공/실패가 최종 확정되기까지 허용하는 전체 시간의 상한. 이 시간을 넘으면 재시도 여부와 무관하게 실패로 처리된다.
프로듀서 튜닝 디테일 — 재시도, 배치, 압축, 메타데이터 캐싱 · 50 Kafka Interview Questions for Data Engineers (2026), Q9, Q22-26, Q37, Q41

Enhanced Fan-Out

Kinesis에서 컨슈머별로 전용 2MB/sec 읽기 처리량과 HTTP/2 푸시를 제공해 지연을 낮추는 옵션(샤드 시간당 추가 과금).
Kafka vs Kinesis vs Pub/Sub — 아키텍처 철학과 벤치마크 수치 비교 · Kafka vs Kinesis vs Pub/Sub 2026: Streaming Platform Showdown — Apache Kafka/AWS Kinesis/Google Pub/Sub 아키텍처 섹션, Head-to-Head 수치 섹션. 'Pub/Sub는 Dataflow 파이프라인 안에서만 exactly-once'라는 서술을 Pub/Sub의 구독 단위 네이티브 exactly-once delivery 기능 기준으로 정정. Exactly-once의 '10-20% 처리량 저하'는 출처가 명확한 벤치마크가 아니라 워크로드에 따라 크게 달라지는 수치로 다룸.

forward compatibility (하위 호환성)

오래된 버전의 클라이언트/서버가 새 버전과 얼마나 문제없이 통신할 수 있는지를 나타내는 정도. Kafka는 버전 구간별로 Not/Partially/Limited/Fully Compatible 등급을 문서화한다.
호환성 매트릭스와 Docker로 실행하기 · Section 7: Compatibility (pp.41-43), Section 8: Docker (pp.44-45)

GraalVM 네이티브 이미지

JVM 없이 실행되는 AOT 컴파일된 Kafka 실행 파일 기반 Docker 이미지(apache/kafka-native). 3.8.0부터 제공되며 실험적 기능으로 프로덕션에는 권장되지 않는다.
호환성 매트릭스와 Docker로 실행하기 · Section 7: Compatibility (pp.41-43), Section 8: Docker (pp.44-45)

Group Leader

코디네이터가 리밸런싱 시 지정하는 컨슈머 멤버 중 하나로, 실제 파티션 할당 계산을 수행한다(단, KIP-848 신규 프로토콜에서는 이 계산이 서버 쪽으로 이동한다).
컨슈머 그룹 운영 디테일 — 하트비트, 그룹 코디네이터/리더, 파티션 할당, 중복 처리 · 50 Kafka Interview Questions for Data Engineers (2026), Q12-13, Q15-16, Q35, Q42. Q13(Eager vs Cooperative Sticky)에 KIP-848 최신 프로토콜 맥락을 보강.

IBP (Inter-Broker Protocol) / MetadataVersion

브로커 간 통신에 사용하는 프로토콜/메타데이터 스키마 버전. KRaft 모드에서는 inter.broker.protocol.version 설정 대신 metadata.version과 kafka-features.sh로 관리한다.
업그레이드 원칙 — 롤링 업그레이드와 메타데이터 버전 · Section 5: Upgrading — 'Upgrading to X.Y.Z' 반복 패턴 및 'Note' 전제조건 (pp.16-33)

ISR (In-Sync Replicas)

파티션 리더와 충분히 동기화되어 있어 언제든 새 리더로 선출될 자격이 있는 복제본 집합. replica.lag.time.max.ms 이상 뒤처지면 ISR에서 제외된다.
Kafka 핵심 아키텍처 — 토픽, 파티션, 브로커, 리플리케이션 · kafka_ref_01(Q1-9,14-21), kafk_ref_02(Q1-4,7-8,32), kafka_ref_05(Q1-5) 종합. kafk_ref_02의 Kafka vs RabbitMQ 처리량 비교 수치(Q32, '10만 vs 2만 msg/sec')는 출처 불명확한 벤치마크 주장이라 판단해 구체 수치 대신 구조적 차이 설명으로 완화.

kafka-features.sh upgrade --release-version

롤링 업그레이드가 끝난 뒤 클러스터 전체에 새 기능/프로토콜 버전을 확정(finalize)하는 명령. 이 명령 전까지는 새 기능이 활성화되지 않는다.
업그레이드 원칙 — 롤링 업그레이드와 메타데이터 버전 · Section 5: Upgrading — 'Upgrading to X.Y.Z' 반복 패턴 및 'Note' 전제조건 (pp.16-33)

kafka-reassign-partitions

파티션 복제본을 어느 브로커로 옮길지 명시적으로 지정해 데이터를 재분산시키는 관리 도구.
클러스터 운영 — 컨트롤러, 랙 어웨어니스, 파티션 설계, 멀티테넌시 · 50 Kafka Interview Questions for Data Engineers (2026), Q5, Q21, Q29, Q33, Q40, Q43, Q45, Q49, FAQ('How does Kafka handle replication?'). Q21의 컨트롤러 설명(ZK 시대의 'LeaderAndIsr 요청 전송' 서술)과 FAQ의 'ZooKeeper or KRaft가 새 리더를 선출' 서술을 현재(4.0+) KRaft 단일 체제 기준으로 정정. Q49의 '2-3배 과잉 파티셔닝' 서술에 과잉 파티셔닝의 실제 비용을 보강.

KIP-848

Kafka 4.0에서 GA된 새로운 컨슈머 그룹 리밸런스 프로토콜. 리밸런싱 로직을 서버(그룹 코디네이터) 중심으로 옮기고 기본적으로 점진적 재배정을 사용한다.
프로듀서 신뢰성과 컨슈머 그룹 — acks, 멱등성, 트랜잭션, 리밸런싱 · kafk_ref_03(Section 3 프로듀서, Section 4 컨슈머 메커니즘), kafka_ref_01(Q35-58,75), kafka_ref_05(Q9) 종합. kafk_ref_03의 '리밸런싱은 항상 stop-the-world' 서술을 CooperativeStickyAssignor(2.4+) 및 KIP-848(Kafka 4.0 GA) 기준으로 수정했고, 'EOS는 약 10~20% 지연 오버헤드를 추가한다'는 구체 수치 주장은 근거 불명확하여 '워크로드에 따라 달라지는 실질적 오버헤드'로 완화.

KRaft

Kafka Raft — ZooKeeper 없이 Kafka 자체 합의 프로토콜로 클러스터 메타데이터를 관리하는 최신(Kafka 4.x 기본) 모드.
Kafka Quick Start (1) — 설치·브로커 기동·토픽 생성과 이벤트 송수신 · Getting Started 공식문서 — 3. Quick Start, Step 1~6 (pp.8-12)

ZooKeeper 없이 Kafka 자체 Raft 기반 프로토콜로 컨트롤러 쿼럼이 메타데이터를 관리하는 방식. Kafka 4.0부터 유일하게 지원되는 모드다.
Kafka 4.0.0 핵심 변경사항 — ZooKeeper 완전 제거와 API 정리 · Section 5: Upgrading — 'Notable changes in 4.0.0' (pp.26-33)

KRaft (Kafka Raft)

Raft 합의 알고리즘 기반으로 Kafka가 자체적으로 클러스터 메타데이터를 관리하는 프로토콜. KIP-500으로 시작되어 Kafka 3.3에서 프로덕션 준비, 4.0부터 유일한 모드가 되었다.
ZooKeeper에서 KRaft로 — 클러스터 메타데이터 관리의 세대교체 · kafka_ref_01(Q10-13)의 최신 서술을 정확한 기준으로 삼아, kafk_ref_02(Q5,Q6,Q16 — 'ZooKeeper 없이는 Kafka 서버에 연결할 수 없다', 'Kafka 서버를 시작하려면 반드시 ZooKeeper를 먼저 띄워야 한다'), kafka_ref_04('Kafka는 3.x대에 KRaft로 이동 중'이라는 진행형 서술), kafka_ref_05(Q1,Q14 — ZooKeeper를 여전히 현재의 표준 아키텍처로, KRaft를 '미래에 없앨 대상'으로 서술)의 오래된 내용을 Kafka 4.0 기준(ZooKeeper 모드 완전 제거)으로 수정.

ksqlDB

Kafka Streams 기반의 SQL 스트림 처리 엔진. 독립 서버로 동작하며 SQL과 유사한 쿼리로 스트림 처리 로직을 표현한다.
Kafka Streams와 확장 생태계 — KStream/KTable, 윈도우, Connect, ksqlDB · kafka_ref_01(Q68-80), kafk_ref_03(Section 8 Kafka Streams vs Spark Streaming), kafka_ref_04(KTable, 스트림 조인, ksqlDB 관련 문항), kafka_ref_05(Q8,Q13) 종합.

KStream

Kafka Streams에서 끝없이 이어지는 이벤트(레코드) 스트림을 나타내는 추상화. 각 레코드는 독립적인 이벤트로 취급된다.
Kafka Quick Start (2) — Kafka Streams 처리, 환경 종료, Ecosystem · Getting Started 공식문서 — 3. Quick Start Step 7~8, 4. Ecosystem (pp.13-15)

경계가 없는 연속 레코드 스트림 추상화. 모든 레코드가 독립적인 새 이벤트로 처리된다.
Kafka Streams와 확장 생태계 — KStream/KTable, 윈도우, Connect, ksqlDB · kafka_ref_01(Q68-80), kafk_ref_03(Section 8 Kafka Streams vs Spark Streaming), kafka_ref_04(KTable, 스트림 조인, ksqlDB 관련 문항), kafka_ref_05(Q8,Q13) 종합.

KTable

Kafka Streams에서 키별 최신 값을 나타내는 변경 로그(changelog) 기반 테이블 추상화. 같은 키의 새 레코드는 이전 값을 갱신한다.
Kafka Quick Start (2) — Kafka Streams 처리, 환경 종료, Ecosystem · Getting Started 공식문서 — 3. Quick Start Step 7~8, 4. Ecosystem (pp.13-15)

키별 최신 값을 유지하는 체인지로그 테이블 뷰 추상화. 같은 키의 새 레코드가 이전 값을 덮어쓴다.
Kafka Streams와 확장 생태계 — KStream/KTable, 윈도우, Connect, ksqlDB · kafka_ref_01(Q68-80), kafk_ref_03(Section 8 Kafka Streams vs Spark Streaming), kafka_ref_04(KTable, 스트림 조인, ksqlDB 관련 문항), kafka_ref_05(Q8,Q13) 종합.

linger.ms

Producer가 배치를 전송하기 전 추가 레코드를 기다리는 최대 시간(ms). 4.0에서 기본값이 0에서 5로 변경됐다.
Kafka 4.0.0 핵심 변경사항 — ZooKeeper 완전 제거와 API 정리 · Section 5: Upgrading — 'Notable changes in 4.0.0' (pp.26-33)

프로듀서가 배치를 batch.size만큼 채우지 못했더라도 전송하기 전에 추가로 기다릴 최대 시간. 늘리면 처리량은 오르고 지연은 늘어난다.
프로듀서 튜닝 디테일 — 재시도, 배치, 압축, 메타데이터 캐싱 · 50 Kafka Interview Questions for Data Engineers (2026), Q9, Q22-26, Q37, Q41

min.insync.replicas

acks=all 프로듀서 쓰기가 성공으로 인정되기 위해 ISR에 있어야 하는 최소 복제본 수(토픽/브로커 설정).
Kafka 핵심 아키텍처 — 토픽, 파티션, 브로커, 리플리케이션 · kafka_ref_01(Q1-9,14-21), kafk_ref_02(Q1-4,7-8,32), kafka_ref_05(Q1-5) 종합. kafk_ref_02의 Kafka vs RabbitMQ 처리량 비교 수치(Q32, '10만 vs 2만 msg/sec')는 출처 불명확한 벤치마크 주장이라 판단해 구체 수치 대신 구조적 차이 설명으로 완화.

node.id

KRaft 모드에서 브로커/컨트롤러를 식별하는 값. ZooKeeper 모드의 자동 생성 broker.id를 대체한다.
KRaft 모드에서 달라지는 설정·메트릭·기능 · Section 6: KRaft vs ZooKeeper — Differences Between KRaft mode and ZooKeeper mode (pp.34-40)

Ordering Key

Pub/Sub에서 순서 보장을 받고 싶은 메시지들에 명시적으로 부여하는 키. 설정하지 않으면 순서가 보장되지 않는다.
Kafka vs Kinesis vs Pub/Sub — 아키텍처 철학과 벤치마크 수치 비교 · Kafka vs Kinesis vs Pub/Sub 2026: Streaming Platform Showdown — Apache Kafka/AWS Kinesis/Google Pub/Sub 아키텍처 섹션, Head-to-Head 수치 섹션. 'Pub/Sub는 Dataflow 파이프라인 안에서만 exactly-once'라는 서술을 Pub/Sub의 구독 단위 네이티브 exactly-once delivery 기능 기준으로 정정. Exactly-once의 '10-20% 처리량 저하'는 출처가 명확한 벤치마크가 아니라 워크로드에 따라 크게 달라지는 수치로 다룸.

Pub/Sub Exactly-once Delivery

Google Cloud Pub/Sub가 구독 단위로 활성화할 수 있는 네이티브 중복 제거 기능. Dataflow 없이도 pull 구독자에게 적용 가능하며, 활성화 시 처리량/지연 트레이드오프가 있다.
Kafka vs Kinesis vs Pub/Sub — 아키텍처 철학과 벤치마크 수치 비교 · Kafka vs Kinesis vs Pub/Sub 2026: Streaming Platform Showdown — Apache Kafka/AWS Kinesis/Google Pub/Sub 아키텍처 섹션, Head-to-Head 수치 섹션. 'Pub/Sub는 Dataflow 파이프라인 안에서만 exactly-once'라는 서술을 Pub/Sub의 구독 단위 네이티브 exactly-once delivery 기능 기준으로 정정. Exactly-once의 '10-20% 처리량 저하'는 출처가 명확한 벤치마크가 아니라 워크로드에 따라 크게 달라지는 수치로 다룸.

quorum controller

KRaft 모드에서 Raft 프로토콜로 동작하며 클러스터 메타데이터를 관리하는 컨트롤러 노드 집합. ZooKeeper 앙상블의 역할을 대체한다.
KRaft 모드에서 달라지는 설정·메트릭·기능 · Section 6: KRaft vs ZooKeeper — Differences Between KRaft mode and ZooKeeper mode (pp.34-40)

read_committed

컨슈머의 isolation.level 설정 중 하나로, 커밋된 트랜잭션의 레코드만 보이게 하고 중단(abort)된 트랜잭션의 레코드는 걸러낸다.
프로듀서 신뢰성과 컨슈머 그룹 — acks, 멱등성, 트랜잭션, 리밸런싱 · kafk_ref_03(Section 3 프로듀서, Section 4 컨슈머 메커니즘), kafka_ref_01(Q35-58,75), kafka_ref_05(Q9) 종합. kafk_ref_03의 '리밸런싱은 항상 stop-the-world' 서술을 CooperativeStickyAssignor(2.4+) 및 KIP-848(Kafka 4.0 GA) 기준으로 수정했고, 'EOS는 약 10~20% 지연 오버헤드를 추가한다'는 구체 수치 주장은 근거 불명확하여 '워크로드에 따라 달라지는 실질적 오버헤드'로 완화.

static voter / dynamic voter

KRaft 쿼럼 구성원(투표자)을 정적으로 고정할지, 런타임에 동적으로 추가/변경할 수 있게 할지를 가르는 구분. 4.3 이전 컨트롤러 동적 설정 변경은 static voter에서만 지원됐다.
KRaft 모드에서 달라지는 설정·메트릭·기능 · Section 6: KRaft vs ZooKeeper — Differences Between KRaft mode and ZooKeeper mode (pp.34-40)

KRaft 쿼럼의 투표 멤버 구성 방식. static은 설정 파일에 고정, dynamic은 런타임에 추가/변경 가능. 서버 업그레이드 호환성에 영향을 준다.
호환성 매트릭스와 Docker로 실행하기 · Section 7: Compatibility (pp.41-43), Section 8: Docker (pp.44-45)

unclean leader election

ISR 밖의(동기화되지 않은) 복제본을 새 리더로 승격시키는 것. 가용성은 회복하지만 데이터 유실 가능성이 있어 기본적으로 비활성화되어 있다.
Kafka 핵심 아키텍처 — 토픽, 파티션, 브로커, 리플리케이션 · kafka_ref_01(Q1-9,14-21), kafk_ref_02(Q1-4,7-8,32), kafka_ref_05(Q1-5) 종합. kafk_ref_02의 Kafka vs RabbitMQ 처리량 비교 수치(Q32, '10만 vs 2만 msg/sec')는 출처 불명확한 벤치마크 주장이라 판단해 구체 수치 대신 구조적 차이 설명으로 완화.

UnderReplicatedPartitions

팔로워 복제본이 ISR을 벗어나 리더를 따라잡지 못하고 있는 파티션 수를 나타내는 브로커 지표. 0이 정상이다.
Kafka 운영, 성능 튜닝과 장애 대응 · kafk_ref_03(Section 5-6,10 실전 이슈/모니터링), kafka_ref_01(Q25-30,42-45,86-90), kafka_ref_04(성능 튜닝 문항), kafka_ref_05(Q7,Q12) 종합. kafk_ref_02(Q38 'Lack of Pace'를 Kafka 단점으로 서술)는 Kafka의 실제 강점(고처리량)과 상충하는 근거 불명확한 서술로 판단해 반영하지 않음.

zero-copy

OS의 sendfile() 시스템 콜을 이용해 디스크 페이지 캐시의 데이터를 애플리케이션 레이어를 거치지 않고 네트워크 소켓으로 직접 전송하는 최적화.
Kafka 운영, 성능 튜닝과 장애 대응 · kafk_ref_03(Section 5-6,10 실전 이슈/모니터링), kafka_ref_01(Q25-30,42-45,86-90), kafka_ref_04(성능 튜닝 문항), kafka_ref_05(Q7,Q12) 종합. kafk_ref_02(Q38 'Lack of Pace'를 Kafka 단점으로 서술)는 Kafka의 실제 강점(고처리량)과 상충하는 근거 불명확한 서술로 판단해 반영하지 않음.

데이터 중력 (Data Gravity)

데이터 웨어하우스·ML 플랫폼·마이크로서비스가 이미 위치한 클라우드에 스트리밍 플랫폼도 두어야 크로스클라우드 전송 비용을 피할 수 있다는 원칙.
스트리밍 플랫폼 선택 기준, 비용 크로스오버, MSK/Confluent Cloud, 흔한 실수 · Kafka vs Kinesis vs Pub/Sub 2026: Streaming Platform Showdown — Pricing Reality Check, When to Choose What, What About Amazon MSK?, Common Mistakes 섹션. 가격 수치는 원문이 '2026년 초 공개 가격 기준 추정치이며 실제 비용은 다를 수 있다'고 명시한 예시 추정값이므로 그대로 예시로 다루고 절대 기준으로 취급하지 않는다.

랙 어웨어니스 (Rack Awareness)

broker.rack 설정으로 브로커의 물리적 위치를 알려, 같은 파티션의 복제본을 서로 다른 랙/AZ에 분산 배치하는 기능.
클러스터 운영 — 컨트롤러, 랙 어웨어니스, 파티션 설계, 멀티테넌시 · 50 Kafka Interview Questions for Data Engineers (2026), Q5, Q21, Q29, Q33, Q40, Q43, Q45, Q49, FAQ('How does Kafka handle replication?'). Q21의 컨트롤러 설명(ZK 시대의 'LeaderAndIsr 요청 전송' 서술)과 FAQ의 'ZooKeeper or KRaft가 새 리더를 선출' 서술을 현재(4.0+) KRaft 단일 체제 기준으로 정정. Q49의 '2-3배 과잉 파티셔닝' 서술에 과잉 파티셔닝의 실제 비용을 보강.

로그 세그먼트 (Log Segment)

파티션 로그를 구성하는 파일 단위(기본 1GB, log.segment.bytes). 보존 정책은 개별 레코드가 아니라 세그먼트 단위로 적용된다.
Kafka 운영, 성능 튜닝과 장애 대응 · kafk_ref_03(Section 5-6,10 실전 이슈/모니터링), kafka_ref_01(Q25-30,42-45,86-90), kafka_ref_04(성능 튜닝 문항), kafka_ref_05(Q7,Q12) 종합. kafk_ref_02(Q38 'Lack of Pace'를 Kafka 단점으로 서술)는 Kafka의 실제 강점(고처리량)과 상충하는 근거 불명확한 서술로 판단해 반영하지 않음.

로그 수집(log aggregation)

여러 서버의 물리적 로그 파일을 중앙 장소로 모아 처리하는 작업. Kafka는 이를 메시지 스트림 형태로 추상화해 대체한다.
Kafka 활용 사례 (Use Cases) · Getting Started 공식문서 — 2. Use Cases (pp.6-7)

로그 컴팩션(log compaction)

토픽을 특정 키로 생성된 '마지막' 메시지만 남기도록 정리하는 Kafka의 기능.
Kafka 활용 사례 (Use Cases) · Getting Started 공식문서 — 2. Use Cases (pp.6-7)

롤링 업그레이드(rolling upgrade)

브로커를 한 번에 하나씩 순차적으로 재시작하며 새 버전으로 교체해, 클러스터 가용성을 유지한 채 업그레이드하는 방식.
업그레이드 원칙 — 롤링 업그레이드와 메타데이터 버전 · Section 5: Upgrading — 'Upgrading to X.Y.Z' 반복 패턴 및 'Note' 전제조건 (pp.16-33)

멱등 컨슈머 처리 (Idempotent Consumer Logic)

같은 메시지를 여러 번 처리해도 최종 결과가 달라지지 않도록 설계된 컨슈머 로직. 비즈니스 키 기반 UPSERT가 대표적 구현이다.
컨슈머 그룹 운영 디테일 — 하트비트, 그룹 코디네이터/리더, 파티션 할당, 중복 처리 · 50 Kafka Interview Questions for Data Engineers (2026), Q12-13, Q15-16, Q35, Q42. Q13(Eager vs Cooperative Sticky)에 KIP-848 최신 프로토콜 맥락을 보강.

멱등성 프로듀서 (Idempotent Producer)

재시도로 인한 동일 메시지의 중복 쓰기를 브로커가 PID+시퀀스 번호로 감지해 제거하도록 하는 프로듀서 설정(enable.idempotence=true).
프로듀서 신뢰성과 컨슈머 그룹 — acks, 멱등성, 트랜잭션, 리밸런싱 · kafk_ref_03(Section 3 프로듀서, Section 4 컨슈머 메커니즘), kafka_ref_01(Q35-58,75), kafka_ref_05(Q9) 종합. kafk_ref_03의 '리밸런싱은 항상 stop-the-world' 서술을 CooperativeStickyAssignor(2.4+) 및 KIP-848(Kafka 4.0 GA) 기준으로 수정했고, 'EOS는 약 10~20% 지연 오버헤드를 추가한다'는 구체 수치 주장은 근거 불명확하여 '워크로드에 따라 달라지는 실질적 오버헤드'로 완화.

복제 팩터(replication factor)

하나의 토픽-파티션 데이터를 몇 개의 브로커에 복제해 둘지 정하는 값. 운영 환경에서 흔히 3을 사용한다.
이벤트 스트리밍과 Kafka의 3가지 핵심 기능 · Getting Started 공식문서 — 1. Introduction (pp.1-5)

샤드 (Shard)

Kinesis Data Streams의 병렬성 단위. Kafka 파티션에 대응하며 쓰기 1MB/sec, 읽기 2MB/sec의 하드 리밋을 갖는다.
Kafka vs Kinesis vs Pub/Sub — 아키텍처 철학과 벤치마크 수치 비교 · Kafka vs Kinesis vs Pub/Sub 2026: Streaming Platform Showdown — Apache Kafka/AWS Kinesis/Google Pub/Sub 아키텍처 섹션, Head-to-Head 수치 섹션. 'Pub/Sub는 Dataflow 파이프라인 안에서만 exactly-once'라는 서술을 Pub/Sub의 구독 단위 네이티브 exactly-once delivery 기능 기준으로 정정. Exactly-once의 '10-20% 처리량 저하'는 출처가 명확한 벤치마크가 아니라 워크로드에 따라 크게 달라지는 수치로 다룸.

세션 윈도우 (Session Window)

고정 크기가 없고, 설정된 비활성 간격으로 구분되는 활동 구간에 따라 동적으로 형성되는 윈도우.
Kafka Streams와 확장 생태계 — KStream/KTable, 윈도우, Connect, ksqlDB · kafka_ref_01(Q68-80), kafk_ref_03(Section 8 Kafka Streams vs Spark Streaming), kafka_ref_04(KTable, 스트림 조인, ksqlDB 관련 문항), kafka_ref_05(Q8,Q13) 종합.

이벤트 소싱(event sourcing)

애플리케이션의 상태 변화를 시간순으로 정렬된 레코드 시퀀스로 기록하는 설계 스타일.
Kafka 활용 사례 (Use Cases) · Getting Started 공식문서 — 2. Use Cases (pp.6-7)

이벤트 스트리밍(event streaming)

이벤트 소스로부터 데이터를 실시간으로 캡처해 durable하게 저장하고, 실시간/사후로 처리·반응시키며, 필요한 목적지로 라우팅하는 일련의 실천.
이벤트 스트리밍과 Kafka의 3가지 핵심 기능 · Getting Started 공식문서 — 1. Introduction (pp.1-5)

이벤트(event)

Kafka에서 데이터를 읽고 쓰는 최소 단위. 키·값·타임스탬프·선택적 메타데이터 헤더로 구성되며 record/message라고도 부른다.
이벤트 스트리밍과 Kafka의 3가지 핵심 기능 · Getting Started 공식문서 — 1. Introduction (pp.1-5)

커밋 로그(commit log)

분산 시스템에서 노드 간 데이터 복제와 장애 노드의 재동기화를 위해 사용하는 외부 로그. Kafka의 로그 컴팩션이 이 용도를 지원한다.
Kafka 활용 사례 (Use Cases) · Getting Started 공식문서 — 2. Use Cases (pp.6-7)

컨슈머 랙 (Consumer Lag)

파티션의 최신 오프셋과 컨슈머 그룹이 커밋한 오프셋의 차이. 값이 크고 계속 늘어나면 컨슈머가 유입 속도를 따라가지 못한다는 뜻이다.
Kafka 운영, 성능 튜닝과 장애 대응 · kafk_ref_03(Section 5-6,10 실전 이슈/모니터링), kafka_ref_01(Q25-30,42-45,86-90), kafka_ref_04(성능 튜닝 문항), kafka_ref_05(Q7,Q12) 종합. kafk_ref_02(Q38 'Lack of Pace'를 Kafka 단점으로 서술)는 Kafka의 실제 강점(고처리량)과 상충하는 근거 불명확한 서술로 판단해 반영하지 않음.

컨트롤러 쿼럼 (Controller Quorum)

KRaft 모드에서 Raft 합의로 메타데이터를 관리하는 전용(또는 겸임) 노드 집합. 활성 컨트롤러 1개와 대기 컨트롤러들로 구성된다.
ZooKeeper에서 KRaft로 — 클러스터 메타데이터 관리의 세대교체 · kafka_ref_01(Q10-13)의 최신 서술을 정확한 기준으로 삼아, kafk_ref_02(Q5,Q6,Q16 — 'ZooKeeper 없이는 Kafka 서버에 연결할 수 없다', 'Kafka 서버를 시작하려면 반드시 ZooKeeper를 먼저 띄워야 한다'), kafka_ref_04('Kafka는 3.x대에 KRaft로 이동 중'이라는 진행형 서술), kafka_ref_05(Q1,Q14 — ZooKeeper를 여전히 현재의 표준 아키텍처로, KRaft를 '미래에 없앨 대상'으로 서술)의 오래된 내용을 Kafka 4.0 기준(ZooKeeper 모드 완전 제거)으로 수정.

크로스오버 지점 (Crossover Point)

처리량이 늘어남에 따라 완전관리형 서비스보다 자체 운영 Kafka의 총비용이 상대적으로 유리해지기 시작하는 지점. 이 자료 기준으로는 대략 초당 5만~10만 건 부근으로 언급되나 팀의 Kafka 역량에 따라 달라진다.
스트리밍 플랫폼 선택 기준, 비용 크로스오버, MSK/Confluent Cloud, 흔한 실수 · Kafka vs Kinesis vs Pub/Sub 2026: Streaming Platform Showdown — Pricing Reality Check, When to Choose What, What About Amazon MSK?, Common Mistakes 섹션. 가격 수치는 원문이 '2026년 초 공개 가격 기준 추정치이며 실제 비용은 다를 수 있다'고 명시한 예시 추정값이므로 그대로 예시로 다루고 절대 기준으로 취급하지 않는다.

토픽(topic)

이벤트가 조직되어 durable하게 저장되는 논리적 단위. 파일시스템의 폴더에 비유되며, 다중 프로듀서·다중 구독자를 지원한다.
이벤트 스트리밍과 Kafka의 3가지 핵심 기능 · Getting Started 공식문서 — 1. Introduction (pp.1-5)

톰스톤 (Tombstone)

키는 있고 값은 null인 레코드. 컴팩션 토픽에서 해당 키의 삭제를 의미하며, delete.retention.ms 동안 유예된 뒤 제거된다.
클러스터 운영 — 컨트롤러, 랙 어웨어니스, 파티션 설계, 멀티테넌시 · 50 Kafka Interview Questions for Data Engineers (2026), Q5, Q21, Q29, Q33, Q40, Q43, Q45, Q49, FAQ('How does Kafka handle replication?'). Q21의 컨트롤러 설명(ZK 시대의 'LeaderAndIsr 요청 전송' 서술)과 FAQ의 'ZooKeeper or KRaft가 새 리더를 선출' 서술을 현재(4.0+) KRaft 단일 체제 기준으로 정정. Q49의 '2-3배 과잉 파티셔닝' 서술에 과잉 파티셔닝의 실제 비용을 보강.

파티셔너 (Partitioner)

프로듀서가 각 레코드를 어느 파티션에 보낼지 결정하는 컴포넌트. 기본은 키 해시(murmur2) 기반이며, 커스텀 구현도 가능하다.
Kafka 핵심 아키텍처 — 토픽, 파티션, 브로커, 리플리케이션 · kafka_ref_01(Q1-9,14-21), kafk_ref_02(Q1-4,7-8,32), kafka_ref_05(Q1-5) 종합. kafk_ref_02의 Kafka vs RabbitMQ 처리량 비교 수치(Q32, '10만 vs 2만 msg/sec')는 출처 불명확한 벤치마크 주장이라 판단해 구체 수치 대신 구조적 차이 설명으로 완화.

파티션(partition)

토픽을 구성하는 분산 저장 단위(버킷). 같은 키의 이벤트는 항상 같은 파티션에 쓰이고, 파티션 안에서만 순서가 보장된다.
이벤트 스트리밍과 Kafka의 3가지 핵심 기능 · Getting Started 공식문서 — 1. Introduction (pp.1-5)