예시 답변 1
약 90초
Kafka 활용 실시간 파이프라인 구축
저는 Kafka를 활용해 실시간 이벤트 스트리밍 파이프라인을 구축한 경험이 있습니다. 당시 배치 처리 방식으로 데이터를 수집하다 보니 지연이 10분 이상 발생했고, 실시간 대시보드가 사실상 무용지물이었습니다. 이 문제를 해결하기 위해 Kafka를 도입해 Producer-Consumer 구조로 전환했습니다.
토픽을 서비스 도메인별로 분리하고 파티션을 3개로 나눠 병렬 처리를 보장했으며, 컨슈머 그룹 전략으로 다운타임 없는 확장을 확보했습니다. 도입 후 데이터 지연이 2초 이내로 줄었고, 트래픽 3배 증가에도 처리 속도를 유지했습니다. 기술 선택 이유는 메시지 유실 없는 at-least-once 보장과 재처리 가능한 오프셋 관리 덕분이었습니다. 이 경험으로 스트리밍 아키텍처 설계와 장애 시나리오 대응 역량을 키웠습니다.
이 결의 특징
토픽을 도메인별로 분리하고 파티션을 3개로 나눈 구체적 설계가 '도입했다'는 선언과 결을 가릅니다. at-least-once 보장과 오프셋 재처리 가능성을 선택 이유로 든 점이 트레이드오프를 이해하는 결로 자주 읽힙니다.
면접관이 다음에 할 행동
'컨슈머 그룹 장애 시 오프셋 관리는 어떻게 했나요?'를 이어받을 가능성이 높습니다. 아키텍처 설계를 구체적으로 설명했기 때문에 운영 장애 시나리오로 심화 탐색이 이어지는 결이 자주 보입니다.