이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
사이드 프로젝트에서 Apache Kafka를 도입해 서비스 간 이벤트 기반 통신을 구현한 경험이 있습니다. 주문 서비스와 알림 서비스를 분리하고, 주문 완료 이벤트를 Kafka 토픽으로 발행해 알림 서비스가 소비하는 구조로 만들었습니다. 컨슈머 그룹 개념을 이해하는 데 시간이 걸렸는데, 파티션 수와 컨슈머 수의 관계를 직접 실험하면서 병렬 처리 확장 방식이 어떻게 동작하는지 체득했습니다. 처음에는 메시지 중복 소비 문제가 발생했고, 멱등성 컨슈머 설계와 처리 완료 여부를 DB에 기록하는 방식으로 해결했습니다. 프로듀서 장애 상황을 시뮬레이션해보니 재시도 설정과 acks 옵션이 데이터 유실 여부에 직접적인 영향을 준다는 것을 확인했습니다. Kafka는 연결이 아니라 흐름을 설계하는 도구라는 결을 이 프로젝트에서 얻었습니다.
Kafka 마이크로서비스에서 본인 사례로 닫힌 경험은 멱등성 컨슈머 설계로 중복 처리 문제를 해결한 케이스였습니다. 메시지 중복 소비가 발생했을 때 처음에는 왜 중복이 생기는지부터 파악해야 했습니다. 컨슈머 리밸런싱 과정에서 이미 처리된 메시지가 다시 소비될 수 있다는 것을 이해했습니다.
처리 완료 여부를 DB에 기록하고 확인하는 방식으로 중복 처리를 막았습니다. Kafka 컨슈머는 최소 한 번 처리를 보장하기 때문에 멱등성 설계가 없으면 중복 처리가 발생할 수 있다는 결이 생겼습니다.
Kafka 마이크로서비스에서 측정 가능한 결과로 닫힌 경험은 파티션 수와 컨슈머 수의 관계를 실험으로 확인한 케이스였습니다. 파티션을 늘리면 처리량이 늘 것이라고 생각했는데, 파티션 수가 컨슈머 수보다 많아지면 일부 컨슈머가 여러 파티션을 담당하게 되는 것을 확인했습니다.
컨슈머 수를 파티션 수에 맞게 늘렸을 때 병렬 처리 효과가 나타나는 것을 메시지 처리 속도 변화로 확인했습니다. Kafka에서 처리량을 높이려면 파티션 수와 컨슈머 수를 함께 조정해야 하고, 이론만으로 이해하기보다 실험으로 직접 확인했을 때 더 명확하게 이해됐다는 결이 남아 있습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 코빗 백엔드 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.