Kafka 면접 단골 질문 모음
Apache Kafka 보안(인증/인가) 공식 문서·기술 블로그 종합 및 면접 단골 질문 정리 (웹 리서치, 2026) — Apache Kafka 공식 문서(kafka.apache.org/40/security) + Confluent/Conduktor 등 기술 블로그 종합 여러 Kafka 인터뷰 준비 자료·기술 블로그에서 공통으로 반복되는 질문을 교차 확인해 정리
이 모듈을 다 읽으면
- 면접에서 반복적으로 나오는 Kafka 핵심 질문에 짧고 정확하게 답할 수 있다
- 각 질문의 답이 이 카테고리의 어느 심화 모듈과 연결되는지 알아 필요하면 더 깊이 파고들 수 있다
이 카테고리의 43개 심화 모듈(01-43)에서 이미 다룬 내용을 전제로, 실제 면접에서 반복적으로 나오는 질문만 뽑아 짧고 정확한 모범답안 형태로 재구성했다. 각 답변 끝에 더 깊이 알고 싶을 때 참고할 모듈을 명시했다.
Q. Kafka는 무엇이고, 왜 메시지 큐(RabbitMQ 등) 대신 Kafka를 쓰는가?
Kafka는 분산 커밋 로그(distributed commit log) 기반의 이벤트 스트리밍 플랫폼이다. 전통적 메시지 큐와의 핵심 차이는 '소비해도 메시지가 사라지지 않는다'는 점 — 컨슈머가 읽어가도 로그에는 그대로 남아 보존 기간(retention) 동안 다른 컨슈머 그룹이 독립적으로 처음부터 다시 읽을 수 있다. 이 덕분에 하나의 토픽을 여러 다른 목적(실시간 알림, 배치 집계, 감사 로그 등)의 서로 다른 컨슈머 그룹이 동시에 각자 속도로 소비할 수 있다. 대량의 처리량을 순차 디스크 I/O와 페이지 캐시 활용으로 낮은 지연시간에 처리하도록 설계된 것도 특징이다(kafka-learn-01, 25 참고).
핵심 포인트
- 핵심 차이: 소비해도 메시지가 삭제되지 않고 retention 기간 동안 로그에 남는다
- 여러 컨슈머 그룹이 같은 토픽을 독립적으로, 각자 다른 속도로 소비할 수 있다
Q. 파티션은 왜 필요하고, 메시지 순서 보장은 어디까지 되는가?
파티션은 하나의 토픽을 여러 브로커에 분산해 병렬 처리(생산·소비 모두)를 가능하게 하는 단위다. 순서 보장은 **파티션 내부에서만** 성립한다 — 같은 토픽이라도 파티션이 다르면 서로 다른 순서로 처리될 수 있다. 그래서 '같은 키를 가진 메시지는 항상 같은 순서로 처리돼야 한다'는 요구사항이 있으면(예: 같은 사용자의 이벤트), 그 키를 파티션 키로 써서 항상 같은 파티션에 가도록 만들어야 한다(기본 파티셔너는 키의 해시값으로 파티션을 정한다).
핵심 포인트
- 순서 보장은 파티션 단위로만 성립 — 토픽 전체 순서는 보장되지 않는다
- 같은 키의 메시지가 같은 순서로 처리돼야 한다면, 그 키를 파티션 키로 써서 항상 같은 파티션으로 보내야 한다
Q. Consumer Group의 리밸런싱은 무엇이고, Eager와 Cooperative는 뭐가 다른가?
같은 그룹 안의 컨슈머 수가 바뀌면(새 컨슈머 추가, 기존 컨슈머 이탈/장애), 파티션을 컨슈머들에게 다시 배분하는 과정이 리밸런싱이다. 전통적인 Eager 리밸런싱은 리밸런싱이 시작되면 그룹의 모든 컨슈머가 자신이 가진 파티션 배정을 전부 반납한 뒤 처음부터 다시 배정받는다 — 이 동안 전체 그룹의 처리가 멈춘다(stop-the-world). Cooperative(Incremental) 리밸런싱은 실제로 옮겨야 하는 파티션만 반납·재배정하고 나머지는 그대로 유지해, 리밸런싱 중에도 대부분의 컨슈머가 계속 처리를 이어간다(kafka-learn-39 참고).
핵심 포인트
- 리밸런싱 = 그룹 내 컨슈머 수 변화에 따른 파티션 재배분
- Eager는 전체 반납 후 재배정(stop-the-world), Cooperative는 변경분만 재배정해 중단을 최소화한다
Q. ISR과 min.insync.replicas는 무엇이고, 왜 acks=all과 함께 봐야 하는가?
ISR(In-Sync Replicas)은 리더 파티션과 '충분히 최신 상태로 따라잡은' 팔로워 복제본들의 집합이다. min.insync.replicas는 프로듀서가 acks=all로 쓸 때 '최소 몇 개의 ISR이 그 메시지를 받아야 성공으로 간주할지'를 정하는 브로커/토픽 설정이다. 예를 들어 복제 팩터 3에 min.insync.replicas=2, acks=all이면, 리더를 포함해 최소 2개 복제본이 메시지를 받아야 프로듀서에게 성공 응답을 준다 — 이 조합이어야 브로커 하나가 죽어도 데이터 유실 없이 남은 복제본으로 계속 서비스할 수 있다. acks=all만 설정하고 min.insync.replicas를 1로 방치하면, ISR이 리더 하나만 남은 상황에서도 '성공'으로 처리되어 그 리더가 죽으면 데이터가 유실될 수 있다 — 두 설정은 항상 같이 봐야 한다(kafka-learn-12 참고).
핵심 포인트
- ISR = 리더를 충분히 따라잡은 복제본 집합
- min.insync.replicas는 acks=all일 때 '최소 몇 개 ISR이 받아야 성공'인지를 정한다 — acks=all만으로는 부족, 두 설정을 함께 봐야 안전하다
Q. Kafka에서 Exactly-Once Semantics(EOS)는 어떻게 달성하는가?
두 가지 메커니즘의 조합이다. (1) 멱등적 프로듀서(enable.idempotence=true): 프로듀서-브로커 간 재시도로 인한 중복을 브로커가 각 프로듀서의 시퀀스 번호로 감지해 걸러낸다(네트워크 재시도로 인한 중복만 방지, 애플리케이션 레벨 재시도는 별개). (2) 트랜잭션(transactional.id 설정): 여러 파티션에 걸친 쓰기를 하나의 원자적 단위로 묶어, 컨슈머 쪽에서 read_committed 격리 수준으로 읽으면 커밋된 트랜잭션의 메시지만 보이게 한다(스트림 처리에서 '읽기-처리-쓰기'를 원자적으로 만드는 데 핵심). 이 둘을 합쳐야 '적어도 한 번(at-least-once)'을 넘어 '정확히 한 번(exactly-once)' 처리 시맨틱을 구현할 수 있다(kafka-learn-13, 35 참고).
핵심 포인트
- 멱등적 프로듀서는 네트워크 재시도로 인한 중복만 방지한다(그 자체로는 EOS 전체를 보장 못함)
- 트랜잭션 + read_committed 격리 수준을 함께 써야 여러 파티션에 걸친 원자적 쓰기와 정확히 한 번 처리가 완성된다
Q. 로그 컴팩션(compaction)과 보존 기간(retention)은 어떻게 다른가?
retention(시간/크기 기반 보존)은 일정 기간이 지나거나 일정 크기를 넘으면 오래된 세그먼트를 통째로 삭제한다 — 이벤트 로그처럼 '과거 이력이 통째로 필요 없어지는' 용도에 맞는다. 컴팩션(cleanup.policy=compact)은 삭제 기준이 시간이 아니라 '키'다 — 같은 키의 메시지가 여러 개 있으면 가장 최신 값만 남기고 이전 값들을 정리한다(키의 '현재 상태'만 필요한 경우, 예: 사용자 프로필 최신값, KTable의 changelog 토픽). 삭제하려는 키는 값에 tombstone(null 값)을 보내면 컴팩션 시점에 완전히 제거된다(kafka-learn-11 참고).
핵심 포인트
- retention: 시간/크기 기준으로 오래된 세그먼트를 통째로 삭제(과거 이력이 필요 없을 때)
- compaction: 키 기준으로 최신 값만 남김(현재 상태만 필요할 때), tombstone(null 값)으로 완전 삭제 가능
Q. KRaft와 ZooKeeper의 핵심 차이는 무엇이고 지금 어느 쪽을 써야 하는가?
ZooKeeper는 Kafka와 별도의 분산 코디네이션 시스템으로 클러스터 메타데이터(토픽/파티션 배치, ACL, 컨트롤러 선출 등)를 관리했다. KRaft는 이 역할을 Kafka 자신의 Raft 기반 합의 프로토콜로 대체해, 별도 시스템 없이 컨트롤러 쿼럼이 메타데이터를 자체 로그(__cluster_metadata 토픽)로 관리한다. Kafka 4.0부터는 ZooKeeper 모드 자체가 완전히 제거됐으므로, 신규 구축은 무조건 KRaft이고 레거시 ZooKeeper 클러스터도 마이그레이션이 필수다(kafka-learn-30, 31, 34, 43 참고).
핵심 포인트
- KRaft = Kafka 자체 Raft 합의로 메타데이터(토픽/ACL/컨트롤러 선출 등)를 관리, ZooKeeper 의존성 제거
- Kafka 4.0부터 ZooKeeper 모드 완전 제거 — 신규 구축은 KRaft가 유일한 선택지
Q. Kafka는 왜 이렇게 빠른가?
세 가지가 함께 작동한다. (1) 순차 디스크 I/O — 랜덤 액세스 대신 로그에 순차적으로만 추가(append-only)하기 때문에 회전 디스크에서도 빠르다. (2) 페이지 캐시 활용 — 프로듀서가 쓴 데이터를 OS 페이지 캐시에 그대로 두고, 컨슈머가 곧바로 읽어가면 디스크까지 안 가고 캐시에서 바로 서빙된다(대부분의 실시간 소비 패턴이 여기 해당). (3) Zero-copy 전송 — 브로커가 디스크의 데이터를 컨슈머에게 보낼 때 커널 공간에서 유저 공간(애플리케이션)을 거치지 않고 sendfile 시스템 콜로 커널이 직접 소켓에 전달해, 불필요한 메모리 복사를 없앤다.
핵심 포인트
- 순차 디스크 I/O(append-only 로그) + 페이지 캐시(디스크까지 안 가는 실시간 소비) + Zero-copy 전송(sendfile, 불필요한 메모리 복사 제거)
Q. 컨슈머 랙(Consumer Lag)이란 무엇이고 왜 중요한가?
컨슈머 랙은 파티션의 최신 오프셋(프로듀서가 쓴 위치)과 그 컨슈머 그룹이 커밋한 오프셋(읽어서 처리를 끝낸 위치) 사이의 차이다. 랙이 계속 늘어난다는 것은 컨슈머의 처리 속도가 유입 속도를 못 따라간다는 뜻이며, 방치하면 (retention이 지난 데이터가 사라지기 전에 못 읽는) 데이터 유실 위험, 또는 실시간성이 요구되는 서비스의 지연 누적으로 이어진다. 컨슈머 랙은 Kafka 운영에서 가장 기본적으로 알람을 걸어야 하는 지표 중 하나다(kafka-learn-24 참고).
핵심 포인트
- 컨슈머 랙 = 최신 오프셋 - 커밋된 오프셋
- 랙이 계속 늘어나면 처리 속도가 유입 속도를 못 따라간다는 신호 — 알람 필수 지표