Kafka 면접에서는 데이터가 로그를 통해 어떻게 흐르는지 이해하고 있는지를 확인합니다. 토픽이 파티션으로 어떻게 나뉘는지, 어떤 순서를 신뢰할 수 있는지, 컨슈머가 작업을 어떻게 분담하는지, 그리고 문제가 생겼을 때 무슨 일이 일어나는지를 묻습니다. 랙, 중복, 데이터 손실에 관한 시나리오 질문이 자주 나오는데, 이는 실무에서 자주 겪는 문제이기 때문입니다.
아래에 22개의 질문과 답변이 있습니다. 기본값 같은 세부 사항은 Kafka 버전마다 다르므로, 사용 중인 버전을 확인하겠다고 언급하는 것이 좋습니다.
핵심 개념
1. Kafka란 무엇이며, 어디에 사용하나요?
Kafka는 분산되고 복제된 커밋 로그입니다. 프로듀서는 토픽에 레코드를 추가하고, 컨슈머는 각자의 속도에 맞춰 읽습니다. 이벤트 스트리밍, 로그 및 메트릭 파이프라인, 서비스 간 결합 해제, 분석 시스템으로의 데이터 공급, 스트림 처리 등에 사용됩니다.
2. 토픽, 파티션, 오프셋이란 무엇인가요?
토픽은 이름이 붙은 레코드 스트림입니다. 각 토픽은 파티션으로 나뉘고, 각 파티션은 순서가 있고 추가만 가능한 로그입니다. 파티션의 모든 레코드에는 위치를 식별하는 순차 번호인 오프셋이 있습니다. 오프셋은 해당 파티션 안에서만 고유합니다.
3. 파티션은 순서에 어떤 영향을 주나요?
Kafka는 파티션 내에서만 순서를 보장합니다. 같은 키를 가진 레코드는 기본적으로 같은 파티션으로 가므로, 서로 간의 순서가 유지됩니다. 파티션 간에는 순서가 없습니다. 한 고객의 모든 이벤트를 순서대로 처리해야 한다면 고객 ID를 키로 사용하세요.
4. 브로커란 무엇이며, 컨트롤러는 무슨 일을 하나요?
브로커는 파티션을 저장하고 클라이언트에 서비스를 제공하는 Kafka 서버입니다. 클러스터에는 여러 브로커가 있습니다. 그중 하나가 컨트롤러 역할을 하며, 클러스터 메타데이터와 파티션 리더십을 관리합니다. 최신 Kafka 버전에서는 이 메타데이터를 위해 ZooKeeper 대신 내장 합의 메커니즘인 KRaft를 사용합니다.
5. 복제는 어떻게 동작하나요?
각 파티션에는 복제 계수가 있습니다. 하나의 복제본이 리더로서 읽기와 쓰기를 처리하고, 나머지는 이를 복사하는 팔로워입니다. ISR(In-Sync Replica)은 리더를 따라잡은 복제본입니다. 리더에 장애가 발생하면 ISR에서 새 리더를 선출합니다.
프로듀서
6. acks 설정은 각각 무슨 의미인가요?
| acks | 의미 | 트레이드오프 |
|---|---|---|
| 0 | 프로듀서가 어떤 확인도 기다리지 않음 | 가장 빠르지만 데이터 손실 가능 |
| 1 | 리더가 기록 후 확인 | 리더가 복제 전에 장애 나면 데이터 손실 가능 |
| all | 리더가 모든 ISR을 기다림 | 가장 강한 내구성, 높은 지연 |
내구성 있는 쓰기를 위해서는 acks=all과 함께 min.insync.replicas를 최소 2로, 복제 계수를 3으로 설정하세요.
7. 프로듀서의 중복 메시지를 어떻게 방지하나요?
멱등 프로듀서(enable.idempotence=true)를 활성화하면, 브로커가 파티션 내 재시도로 인한 중복을 걸러낼 수 있습니다. 여러 파티션이나 토픽에 걸쳐 원자적으로 써야 하는 경우에는 트랜잭션을 사용하세요.
8. 프로듀서는 파티션을 어떻게 선택하나요?
키를 지정하면 기본 파티셔너가 키를 해시하여 파티션을 선택합니다. 키가 없으면 프로듀서가 레코드를 여러 파티션에 분산합니다(최신 버전은 배치를 효율적으로 채우기 위해 스티키 방식을 사용합니다). 커스텀 파티셔너를 작성할 수도 있습니다.
9. 프로듀서 처리량에 영향을 주는 요소는 무엇인가요?
배치 처리(batch.size, linger.ms), 압축(lz4나 zstd 등), 파티션 수, acks 등입니다. 배치가 크고 압축을 사용하면 보통 약간의 지연을 대가로 처리량이 높아집니다.
컨슈머
10. 컨슈머 그룹이란 무엇인가요?
토픽을 읽는 작업을 나눠서 수행하는 컨슈머들의 집합입니다. 각 파티션은 한 번에 그룹 내 하나의 컨슈머에 할당됩니다. 따라서 그룹에서 실제로 일하는 컨슈머 수는 파티션 수에 의해 제한되며, 남는 컨슈머는 놀고 있게 됩니다.
11. 리밸런스 중에는 무슨 일이 일어나나요?
컨슈머가 합류하거나 떠나거나, 파티션이 변경되면 그룹이 파티션을 재할당합니다. 전통적인 리밸런스에서는 이 과정 동안 소비가 일시 중단됩니다. 협력적 리밸런싱(cooperative rebalancing)과 정적 멤버십(static membership)은 이런 중단을 줄여줍니다. 잦은 리밸런스는 보통 처리 시간이 너무 긴 컨슈머(max.poll.interval.ms)나 하트비트 누락에서 비롯됩니다.
12. 오프셋은 어떻게 커밋하나요?
컨슈머는 다음에 읽을 레코드의 오프셋을 커밋하며, 이는 내부 토픽에 저장됩니다. 자동 커밋은 간단하지만 처리가 끝나기 전에 커밋될 수 있습니다. 처리가 끝난 뒤 수동으로 커밋하면 "완료"의 기준을 직접 통제할 수 있습니다.
13. at-most-once, at-least-once, exactly-once는 각각 무슨 뜻인가요?
- At-most-once: 처리 전에 오프셋을 커밋합니다. 크래시가 나면 레코드를 잃을 수 있습니다.
- At-least-once: 처리한 뒤 커밋합니다. 크래시가 나면 재처리가 발생해 중복이 생길 수 있습니다.
- Exactly-once: 효과가 한 번만 발생합니다. Kafka에서는 멱등 프로듀서, 트랜잭션, read_committed 컨슈머를 사용해 Kafka 내부에서 이것이 가능합니다. 외부 시스템에 쓸 때는 보통 멱등 쓰기나 키 기반 중복 제거가 필요합니다.
좋은 답변은 "exactly once"가 부수 효과가 어디에서 발생하는지에 달려 있다는 점을 짚어줍니다.
14. 항상 실패하는 포이즌 메시지는 어떻게 처리하시겠어요?
에러를 잡아서 제한된 횟수만큼 재시도한 뒤, 상세 정보와 함께 해당 레코드를 데드 레터 토픽(dead-letter topic)으로 보내고 오프셋을 커밋한 다음 계속 진행합니다. 누군가 조사할 수 있도록 데드 레터 토픽에 알림을 겁니다.
운영과 시나리오
15. 컨슈머 랙이 계속 늘고 있습니다. 어떻게 진단하시겠어요?
- 어느 파티션에 랙이 있는지 확인합니다. 특정 파티션 하나만 뜨거우면 키가 치우쳐 있다는 신호입니다. 모든 곳에 랙이 있으면 처리 지연이나 컨슈머 부족을 뜻합니다.
- 레코드당 처리 시간과 데이터베이스 같은 다운스트림 호출을 확인합니다.
- 잦은 리밸런스가 있는지 확인합니다.
- 프로듀서 유입량이 늘었는지 확인합니다.
- 컨슈머를 늘리거나(파티션 수까지), 처리를 빠르게 하거나, 배치 처리하거나, 파티션을 늘려 해결합니다.
16. 파티션 수는 언제 늘려야 하나요?
현재 컨슈머가 제공할 수 있는 것보다 더 많은 병렬성이 필요하거나, 파티션당 처리량이 한계일 때입니다. 주의할 점: 파티션을 추가하면 새 레코드에 대한 키-파티션 매핑이 바뀌므로, 변경 시점을 기준으로 특정 키의 순서가 깨질 수 있습니다. 순서가 중요하다면 파티션 수를 미리 계획하세요.
17. 데이터는 어떻게 보관되며, 로그 컴팩션이란 무엇인가요?
기본적으로 Kafka는 시간이나 크기(retention.ms, retention.bytes)에 따라 오래된 세그먼트를 삭제합니다. 로그 컴팩션을 사용하면 Kafka가 각 키에 대해 최소한 최신 값을 유지하는데, 이는 체인지로그나 테이블 형태의 토픽에 적합합니다. null 값(툼스톤)은 해당 키를 삭제 대상으로 표시합니다.
18. 브로커에 장애가 나면 어떻게 되나요?
해당 브로커가 리더인 파티션들은 ISR에서 새로운 리더를 선출합니다. 클라이언트는 메타데이터를 갱신하고 계속 동작합니다. 동기화된 레플리카가 없으면, 언클린 리더 선출(unclean leader election)을 허용하지 않는 한 해당 파티션은 사용할 수 없게 되는데, 허용하면 데이터 손실 위험이 있습니다.
19. Kafka 클러스터는 어떻게 보안을 적용하나요?
전송 중 암호화를 위한 TLS, 인증을 위한 SASL(SCRAM이나 OAuth 등) 또는 상호 TLS, 토픽과 그룹에 대한 권한 부여를 위한 ACL, 그리고 네트워크 통제를 사용합니다. 필요하면 애플리케이션 레벨에서 민감한 필드를 암호화합니다.
20. Kafka는 어떻게 모니터링하나요?
핵심 신호는 컨슈머 랙, 복제 부족 파티션(under-replicated partitions), 오프라인 파티션, 요청 지연 시간, 디스크 사용량, ISR 축소/확장 비율이며, JMX 메트릭과 Prometheus, Grafana 같은 도구를 통해 수집합니다.
설계 질문
21. RabbitMQ나 SQS 같은 메시지 큐 대신 Kafka를 선택하는 경우는 언제인가요?
높은 처리량, 과거 이벤트의 재생, 같은 스트림을 소비하는 여러 독립 컨슈머, 또는 스트림 처리가 필요할 때 Kafka를 선택합니다. 메시지별 라우팅, 단순한 작업 큐, 또는 파티션을 관리하고 싶지 않을 때는 전통적인 큐를 선택합니다.
22. 주문 이벤트 파이프라인을 설계해 보세요.
"주문은 주문 ID를 키로 하는 orders 토픽으로 보내서 한 주문의 이벤트가 순서대로 유지되게 합니다. 브로커 3대 이상, 복제 계수 3, acks=all, 멱등 프로듀서를 사용하겠습니다. 청구, 재고, 분석용 컨슈머는 각자 별도의 그룹을 사용합니다. 청구 쓰기는 주문 ID 기준으로 멱등하게 하고, 실패한 레코드는 데드 레터 토픽으로 보내며, 그룹별 랙을 모니터링하겠습니다. 파티션 수는 최대 처리량과 예상 컨슈머 수를 기준으로 여유를 두고 정하겠습니다."
준비 방법
가능하다면 로컬에서 Kafka를 실행하고, 프로듀서와 컨슈머 그룹을 작성한 뒤, 컨슈머 하나를 중지시켜 리밸런스가 일어나는 모습을 직접 확인해 보세요. 느린 컨슈머처럼 일부러 문제를 만들어서 lag이 어떻게 쌓이는지도 살펴보세요. 그리고 여러분이 해결한 데이터 파이프라인 문제에 관한 실제 사례 하나를 준비해 두세요. 관련 주제는 Databricks와 시스템 디자인 인터뷰 가이드를 참고하세요.
전달 보장(delivery guarantees)에 대해 소리 내어 설명하는 연습을 하세요. 답변이 두루뭉술해지는 부분이 바로 여기입니다. 모의 면접과 녹취록을 통해 어디가 약한지 확인할 수 있습니다. 실시간 면접에서는 AI 도구 사용에 관한 회사 규칙을 따르세요.
YesToTheOffer와 함께 Kafka 인터뷰 답변을 연습하세요
모의 기술 인터뷰를 진행하고, 전달 보장을 소리 내어 설명하고, 이후 녹취록을 검토하세요. 30분 무료, 구독 없음.
