← Kafka 모듈로

Learn · Glossary

Kafka 용어 사전

총 113개 용어

로드맵 보기

2PC 참여(KIP-939)

Kafka의 트랜잭셔널 프로듀서가 외부에서 조율되는 2단계 커밋(2PC) 트랜잭션의 참가자로 동작할 수 있게 하는 기능. Kafka 쓰기와 외부 시스템(데이터베이스 등) 쓰기를 함께 원자적으로 묶는 dual write를 가능하게 한다.
2PC 참여(KIP-939) — Kafka를 외부 트랜잭션의 참가자로 만든다 · Apache Kafka KIP-939: Support Participation in 2PC

__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배 과잉 파티셔닝' 서술에 과잉 파티셔닝의 실제 비용을 보강.

ACL (Access Control List)

Principal이 특정 리소스에 대해 특정 작업을 허용/거부받는지를 정의하는 규칙. kafka-acls.sh로 관리한다.
Kafka 보안 — 인증(SASL/SSL)과 인가(ACL) · Apache Kafka 4.0 공식 문서 security/authorization-and-acls + SASL 메커니즘 비교 자료 종합

advertised.listeners

브로커가 클러스터 메타데이터 응답을 통해 클라이언트에게 알려주는, 실제 연결에 사용할 주소. 브로커가 바인딩하는 listeners와 달리 클라이언트가 있는 위치에서 도달 가능한 주소여야 한다.
listeners vs advertised.listeners — 바인딩 주소와 광고 주소는 다르다 · Confluent 공식 블로그 Kafka Listeners – Explained

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년 초 공개 가격 기준 추정치이며 실제 비용은 다를 수 있다'고 명시한 예시 추정값이므로 그대로 예시로 다루고 절대 기준으로 취급하지 않는다.

BACKWARD 호환성

새 스키마로 동작하는 컨슈머가 이전 스키마로 생산된 데이터도 읽을 수 있어야 한다는 규칙. 컨슈머를 프로듀서보다 먼저 업그레이드해야 안전하며, Schema Registry의 기본값이다.
Schema Registry 호환성 모드 — BACKWARD/FORWARD/FULL과 배포 순서 · Confluent 공식 문서 schema-registry/fundamentals/schema-evolution

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)

Dead Letter Queue(DLQ)

Kafka Connect sink 커넥터가 처리 중 실패한 레코드(원본 키/값/헤더 포함)를 버리지 않고 격리해 저장하는 전용 토픽. errors.tolerance=all과 errors.deadletterqueue.topic.name 설정으로 활성화된다.
Kafka Connect Dead Letter Queue — sink 커넥터의 문제 레코드 격리 · Apache Kafka KIP-298 및 Confluent 블로그 Kafka Connect Deep Dive Error Handling and Dead Letter Queues

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% 처리량 저하'는 출처가 명확한 벤치마크가 아니라 워크로드에 따라 크게 달라지는 수치로 다룸.

Fetch Session(KIP-227)

브로커가 메모리에 캐싱하는 파티션 상태 정보. 클라이언트가 이 세션을 이용해 매번 전체 파티션 목록이 아니라 직전 상태에서 달라진 부분만 담은 증분 FetchRequest를 보낼 수 있게 해, 파티션 수가 많은 클러스터의 Fetch 오버헤드를 줄인다.
Fetch Session(KIP-227) — 매번 전체 파티션 목록을 다시 안 보낸다 · Apache Kafka KIP-227: Introduce Incremental FetchRequests to Increase Partition Scalability

forward compatibility (하위 호환성)

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

GlobalKTable

입력 토픽의 모든 파티션 데이터를 애플리케이션의 모든 인스턴스가 로컬에 전부 복제해 갖는 KTable 변형. 정보를 전체 인스턴스에 '브로드캐스트'하는 용도로 쓰이며, 조인 시 co-partitioning이 필요 없다.
GlobalKTable — co-partitioning 없이 조인하기 · Apache Kafka 공식문서 Streams DSL — GlobalKTable

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 Connect Source EOS(KIP-618)

Kafka Connect 3.3.0부터 지원되는 source 커넥터의 정확히 한 번(exactly-once) 처리. 레코드 쓰기와 소스 오프셋 커밋을 하나의 Kafka 트랜잭션으로 묶어, 오프셋이 커밋됐다는 것이 곧 레코드도 반드시 쓰였다는 것을 보장한다.
Kafka Connect Source EOS(KIP-618) — 오프셋 커밋을 트랜잭션 안에 가둔다 · KIP-618: Exactly-Once Support for Source Connectors

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-392(폴로워 페치)

컨슈머가 client.rack 설정으로 자신의 랙 정보를 브로커에 알려, 파티션 리더가 아니라 같은 랙(가용영역)에 있는 레플리카에서 우선적으로 데이터를 읽어올 수 있게 하는 기능. 클라우드 환경의 AZ 간 트래픽 비용을 줄이는 데 쓰인다.
KIP-392 — 컨슈머가 리더 대신 '가장 가까운' 레플리카에서 읽기 · KIP-392: Allow consumers to fetch from closest replica

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% 지연 오버헤드를 추가한다'는 구체 수치 주장은 근거 불명확하여 '워크로드에 따라 달라지는 실질적 오버헤드'로 완화.

Kafka 4.0에서 프로덕션 준비 완료된 차세대 컨슈머 리밸런싱 프로토콜. JoinGroup/SyncGroup 단계를 ConsumerGroupHeartbeat API로 통합하고, 파티션 할당 계산을 클라이언트가 아니라 그룹 코디네이터(서버)가 수행한다.
KIP-848 — JoinGroup/SyncGroup을 없애고 서버가 직접 할당을 계산하는 새 리밸런싱 · KIP-848: The Next Generation of the Consumer Rebalance Protocol

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')는 출처 불명확한 벤치마크 주장이라 판단해 구체 수치 대신 구조적 차이 설명으로 완화.

mTLS (상호 TLS)

서버뿐 아니라 클라이언트도 인증서를 제시해 서로를 인증하는 방식. SASL 없이 인증서 자체로 클라이언트 신원(Principal)을 확인한다.
Kafka 보안 — 인증(SASL/SSL)과 인가(ACL) · Apache Kafka 4.0 공식 문서 security/authorization-and-acls + SASL 메커니즘 비교 자료 종합

node.id

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

num.replica.fetchers

팔로워 브로커가 리더 브로커로부터 데이터를 복제해오는 데 쓰는 전용 fetcher 스레드 수를 지정하는 브로커 설정. 기본값은 1이며, 클라이언트 요청을 처리하는 네트워크·IO 스레드(kafka-learn-10)와는 별개의 스레드 풀이다.
num.replica.fetchers — 복제 전용 스레드 풀의 크기 · Apache Kafka 공식문서 Broker Configs

num.standby.replicas

Kafka Streams의 각 활성 태스크마다 유지할 상태 저장소 그림자 사본(standby task)의 개수를 지정하는 설정(기본 0). 장애 시 이미 따라잡은 standby task로 우선 재배정해 changelog 복원 시간을 줄여준다.
num.standby.replicas — Kafka Streams 상태 저장소의 핫 스탠바이 · Confluent 공식 문서 Plan and Size Capacity for Kafka Streams 및 Configure a Kafka Streams Application

offset.storage.topic

Kafka Connect 분산 모드에서 source 커넥터가 외부 시스템의 읽기 위치를 저장하는 내부 토픽. sink 커넥터의 오프셋은 여기 저장되지 않고 일반 컨슈머 그룹 메커니즘(__consumer_offsets)을 사용한다.
Kafka Connect — source/sink 커넥터 구분과 3개 내부 토픽(offset/config/status) · Apache Kafka 공식 문서 Kafka Connect 및 AWS MSK Kafka Connect 내부 토픽 가이드

onPartitionsLost(KIP-429)

ConsumerRebalanceListener의 콜백으로, 멤버가 리밸런스를 놓쳐 그룹에서 떨어져 나갔을 때 그 시점에 소유하던 모든 파티션에 대해 호출된다. 이미 파티션 소유권을 잃은 상태라 오프셋 커밋을 시도할 필요가 없다는 점이 onPartitionsRevoked와 다르다.
onPartitionsLost — '정상적으로 반납'과 '갑자기 빼앗김'은 다르다 · KIP-429: Kafka Consumer Incremental Rebalance Protocol

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% 처리량 저하'는 출처가 명확한 벤치마크가 아니라 워크로드에 따라 크게 달라지는 수치로 다룸.

Principal

인증을 통해 확인된 요청 주체. SASL 인증이면 User:이름, mTLS면 인증서의 CN 등으로 식별된다.
Kafka 보안 — 인증(SASL/SSL)과 인가(ACL) · Apache Kafka 4.0 공식 문서 security/authorization-and-acls + SASL 메커니즘 비교 자료 종합

ProcessorContext#forward()

커스텀 Processor의 process() 안에서 처리된 레코드를 Topology상 하위(downstream) 프로세서 노드로 전달하는 메서드. DSL의 각 연산자가 내부적으로 의존하는 저수준 메커니즘이다.
Kafka Streams Processor API — DSL 밑의 저수준 세계 · Apache Kafka 공식문서 Streams Processor API

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% 지연 오버헤드를 추가한다'는 구체 수치 주장은 근거 불명확하여 '워크로드에 따라 달라지는 실질적 오버헤드'로 완화.

SASL

Simple Authentication and Security Layer. Kafka가 클라이언트 인증에 쓰는 프레임워크로 PLAIN/SCRAM/GSSAPI/OAUTHBEARER 등 여러 메커니즘을 플러그인 형태로 지원한다.
Kafka 보안 — 인증(SASL/SSL)과 인가(ACL) · Apache Kafka 4.0 공식 문서 security/authorization-and-acls + SASL 메커니즘 비교 자료 종합

sendOffsetsToTransaction()

트랜잭셔널 프로듀서 API 중 하나로, 지정한 컨슈머 오프셋들을 현재 진행 중인 트랜잭션의 일부로 컨슈머 그룹 코디네이터에 전송한다. 트랜잭션이 커밋돼야만 그 오프셋도 함께 커밋된 것으로 확정된다.
sendOffsetsToTransaction — 오프셋 커밋을 트랜잭션 안에 직접 끼워 넣는다 · Apache Kafka KIP-98: Exactly Once Delivery and Transactional Messaging

Sink 커넥터 전달보장

Kafka Connect sink 커넥터가 기본적으로 제공하는 at-least-once 전달. exactly-once 효과를 내려면 프레임워크 차원의 보장이 아니라 대상 외부 시스템의 멱등적 쓰기 능력(예: upsert, 결정론적 문서 ID)에 의존해야 한다.
Kafka Connect Sink 커넥터의 전달보장 — 기본은 at-least-once, exactly-once는 싱크에 달렸다 · Confluent 공식 문서 Message Delivery Guarantees 및 Elasticsearch Sink Connector

SMT (Single Message Transform)

Kafka Connect 커넥터 파이프라인에서 개별 레코드를 그 자리에서 변형하는 경량 기능. transforms 설정으로 체이닝하고 predicates로 조건부 적용할 수 있다.
Kafka Connect SMT(Single Message Transform)와 헤더 활용 · Confluent 공식 문서 kafka-connectors/transforms/overview

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)

Tiered Storage

완료된(더 이상 안 쓰이는) 로그 세그먼트를 브로커 로컬 디스크에서 S3/HDFS 같은 저비용 원격 저장소로 자동 이관하는 기능(KIP-405). local.retention(로컬 보존)과 retention(전체 보존) 두 설정으로 계층을 나눈다.
Tiered Storage — 로컬과 원격 계층으로 나눠 저장하기 · Apache Kafka 공식 문서 operations/tiered-storage (KIP-405, Kafka 3.9부터 프로덕션 레디)

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)