어떤 Kafka 면접 질문을 예상해야 하나요?

Kafka가 분산 로그라는 사실은 이미 알지만, 면접관이 일상적인 사용 경험보다 한 단계 더 깊이 들어갈까 걱정될 수 있습니다. 실제로 이러한 질문은 바로 그 지점을 파고들기 때문에, 여기서는 면접관이 일반적으로 묻는 순서대로 용어를 살펴보고 각 용어에 뒤따르는 추가 질문을 짚습니다.

• 토픽과 파티션. 토픽은 파티션으로 나뉘며, 각 파티션은 추가만 가능하고 순서가 정해진 로그입니다. 추가 질문: Kafka는 단일 로그를 더 빠르게 만드는 대신 파티션을 추가해 쓰기 처리량을 확장하는 이유가 무엇인가요?
• 오프셋. 파티션 안에서 컨슈머가 읽고 있는 위치입니다. 추가 질문: 커밋된 오프셋은 누가 저장하며, 컨슈머가 커밋 전에 중단되면 어떻게 되나요?
• 컨슈머 그룹. 그룹의 컨슈머들은 토픽의 파티션을 나눠 처리하며, 한 시점에 그룹 내 하나의 파티션은 최대 하나의 컨슈머에만 배정됩니다. 추가 질문: 그룹의 컨슈머 수가 파티션 수보다 많으면 처리량은 어떻게 되나요?
• 브로커와 컨트롤러. 브로커는 파티션을 저장하고, 컨트롤러는 리더 선출과 메타데이터를 처리합니다. 추가 질문: Kafka가 메타데이터 관리를 ZooKeeper에서 KRaft로 옮기면서 무엇이 달라졌나요?
• 프로듀서와 키. 키가 있는 메시지는 키를 해싱해 선택한 파티션에 들어가고, 키가 없는 메시지는 여러 파티션에 분산됩니다. 추가 질문: 이 두 방식 중 한 고객의 이벤트 순서를 보존하는 것은 무엇인가요?

구호가 아니라 작동 원리로 답하세요. 파티션이 병렬성을 제공한다고 말하는 것은 기본에 불과합니다. 순서는 파티션 내부에서만 존재하며, 따라서 키가 순서 보장 범위를 결정한다고 설명해야 다음 면접 단계로 나아갈 수 있습니다.

이 영역에서 많은 지원자가 점수를 잃습니다. 용어는 쉽지만 절충점은 쉽지 않기 때문입니다. 면접관이 특정 보장 수준을 제시하고 설정을 조합해 이를 구현해 보라고 할 수 있습니다.

• At-most-once와 at-least-once. 처리 전에 오프셋을 커밋하면 메시지를 잃을 수 있고, 먼저 처리한 뒤 커밋하면 메시지를 중복 처리할 수 있습니다. 각 순서가 어떤 장애를 감수하는지, 그리고 자신의 시스템은 어느 방식을 선호하는지 설명하세요.
• 멱등성 프로듀서와 exactly-once. 멱등성 프로듀서는 파티션 내 재시도 중복을 제거합니다. 트랜잭션은 이를 여러 파티션과 consume-transform-produce 과정의 컨슈머 오프셋까지 확장합니다. Exactly-once가 보장하지 않는 것도 말할 준비를 하세요. 트랜잭션 외부의 다운스트림 데이터베이스 쓰기는 여전히 직접 해결해야 합니다.
• acks, 복제 계수, 동기화된 복제본. acks=all은 동기화된 복제본 집합을 기다리고, min.insync.replicas는 쓰기가 거부되기 전까지 그 집합이 얼마나 작아질 수 있는지를 정합니다. 면접관은 흔히 이 내구성을 위해 무엇을 희생하는지 묻습니다. 바로 브로커 손실 시의 지연 시간과 가용성입니다.
• 보존과 압축. 시간 또는 크기 기반 보존은 오래된 세그먼트를 삭제하고, 로그 압축은 키별 최신 레코드를 유지합니다. 추가 질문: 키-값 저장소의 변경 로그에는 어느 방식이 적합하며, 그 이유는 무엇인가요?
• 리밸런싱. 컨슈머가 합류하거나 이탈하면 파티션이 다시 배정됩니다. 추가 질문: 긴 리밸런싱은 지연 시간에 민감한 서비스에 어떤 영향을 주며, 협력적 리밸런싱과 정적 멤버십은 그 부담을 어떻게 줄이나요?

유용한 습관이 있습니다. 언급하는 모든 설정에 대해 그것이 방지하는 장애와 추가하는 비용을 함께 말하세요. 이 구조라면 본 질문과 추가 질문에 한 번에 답할 수 있습니다.

시니어 면접에서는 정의 대신 시나리오를 제시하고 지원자의 추론 과정을 봅니다. 전형적인 문제는 이렇습니다. 결제 회사의 플랫폼 직무에 지원한 백엔드 엔지니어에게 한 계정의 모든 거래가 순서대로 처리되고, 트래픽 증가에 따라 처리량이 늘어나며, 브로커 장애에도 데이터가 유실되지 않는 이벤트 파이프라인을 설계하라고 합니다. 좋은 답변은 계정 ID로 메시지 키를 지정해 한 계정의 이벤트가 같은 파티션에 들어가게 하고, 예상 최대 부하와 향후 성장을 위한 여유를 고려해 파티션 수를 정하며, 내구성을 위해 복제와 acks=all을 설정하고, 장애 발생 시 건너뛰는 대신 다시 처리되도록 컨슈머가 오프셋을 커밋하는 방식을 설명합니다.

반복해서 등장하는 다른 시나리오도 있습니다. 뒤처지는 컨슈머의 지연을 감지하고 따라잡게 하는 방법, 후회되는 토픽 파티션 수와 재파티셔닝이 키 순서를 깨뜨리는 이유, 컨슈머를 중단시키는 독성 메시지와 이를 격리하는 데드 레터 패턴, 프로듀서와 컨슈머 전반의 스키마 변경 및 스키마 레지스트리가 제공하는 가치 등입니다. 면접관은 단 하나의 정답 아키텍처를 찾는 것이 아닙니다. 제약 조건을 밝히고, 적절한 메커니즘을 선택하고, 절충점을 소리 내어 설명하기를 원합니다.

면접 전에 읽기만 하지 말고 이러한 답변을 소리 내어 연습하세요. 추가 질문으로 깊이 파고드는 AI 면접관과 시나리오 질문을 연습하는 기능은 모의 면접 페이지에 있으며, 더 폭넓은 직무별·주제별 질문 모음은 직무 및 주제별 면접 질문에서 볼 수 있습니다.

대화형 면접이라면 정직한 한계 안에서 가능합니다. SubcueAI의 네이티브 macOS 및 Windows 데스크톱 앱은 면접관의 오디오와 사용자의 마이크를 캡처하고 로컬 오버레이에 짧은 답변 제안을 표시합니다. 따라서 면접관이 min.insync.replicas가 무엇으로부터 보호하는지 물으면, 화면에 표시된 작동 원리를 보면서 자기 말로 설명할 수 있습니다. 브라우저 확장 프로그램은 브라우저 탭 통화에서 같은 기능을 제공하며 회의 탭의 오디오만 캡처합니다. 어느 쪽도 통화에 봇을 추가하거나 회의 페이지에 무언가를 삽입하지 않습니다. 설정 방법은 튜토리얼 페이지에서 확인할 수 있습니다.

홍보 문구보다 한계가 더 중요합니다. 감독되는 코딩 시험, 화면이 녹화되는 시험, 회사에서 관리하는 노트북은 지원 범위 밖이며, 지켜보는 가운데 컨슈머를 구현해야 하는 실시간 코딩 과제는 직접 수행해야 합니다. 이 도우미는 앞서 설명한 용어와 절충점 관련 질문에는 가장 유용하지만, 평가 플랫폼에 입력해야 하는 작업에는 가장 적합하지 않습니다. 사용하기 전에 이력서를 등록해 제안이 실제로 수행한 Kafka 업무를 반영하도록 하세요. 해당 프로필은 이력서 작성 도구에서 관리할 수 있습니다.