이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
서비스 간 결합을 낮추기 위해 Kafka를 처음 도입한 건 주문 완료 후 이메일 발송 흐름이었습니다. 기존엔 동기 호출로 연결돼 이메일 서비스가 느리면 주문 API도 함께 느려졌는데, 토픽으로 이벤트를 발행하고 컨슈머가 독립적으로 처리하는 구조로 바꿨습니다.
컨슈머 그룹을 활용해 같은 토픽을 여러 서비스가 독립적으로 소비할 수 있게 됐고, 통계 집계 서비스를 추가할 때 프로듀서 코드를 전혀 수정하지 않아도 됐습니다. 처음에는 메시지 중복 소비 문제를 고려하지 않아 이메일이 여러 번 발송되는 버그가 있었고, 멱등성 처리를 추가하는 게 배포 후 긴급 패치가 됐습니다.
at-least-once 보장이 멱등 컨슈머를 전제한다는 걸 직접 겪으며 배웠습니다.
Kafka를 도입하고 나서 처음에는 단순히 동작하는지만 확인했는데, 운영하면서 컨슈머가 처리하는 속도보다 메시지가 쌓이는 속도가 빠른 상황이 생겼습니다. 컨슈머 랙이라고 부르는 지표를 모니터링하기 시작했는데, 특정 시간대에 이벤트가 몰리면서 처리 지연이 발생하는 것을 수치로 확인할 수 있었습니다. 파티션 수와 컨슈머 수를 늘려서 병렬 처리를 확대하니 지연이 줄었는데, 파티션 수보다 컨슈머 수가 많으면 일부 컨슈머가 놀게 된다는 것도 이 과정에서 알게 됐습니다. 이전 동기 방식에서는 처리 지연이 API 응답 시간에 바로 나타났는데, Kafka로 분리한 이후에는 메시지 처리 지연이 별도 지표로 관리되기 때문에 모니터링 방식도 달라져야 한다는 것을 배웠습니다. 비동기 처리 시스템은 동작한다고 끝이 아니라 컨슈머 랙 같은 지표를 지속적으로 관찰해야 실제 서비스 품질을 유지할 수 있다는 것을 이 경험에서 배웠습니다.
메시지 큐를 도입하면서 처리가 완료되기 전에 시스템이 재시작되면 메시지가 유실될 수 있다는 것을 운영 중에 알게 됐습니다. 컨슈머가 메시지를 받은 직후 오프셋을 자동으로 커밋하는 설정이 기본으로 돼 있었는데, 오프셋이 커밋됐지만 실제 처리가 완료되기 전에 장애가 생기면 그 메시지는 다시 처리되지 않았습니다. 오프셋 커밋을 처리 완료 후에 수동으로 하는 방식으로 바꾸니 장애 후 재시작해도 미처리 메시지를 이어받아 처리할 수 있었습니다. 이 변경으로 중복 처리 가능성이 생겼는데, 처리 결과를 저장할 때 같은 메시지 ID를 두 번 처리해도 결과가 달라지지 않도록 멱등성을 보장하는 로직을 추가했습니다. 메시지 큐를 사용할 때 전달 보장 방식과 멱등성 처리는 함께 설계해야 하는 문제라는 것을 이 경험에서 배웠습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 CJ올리브영 백엔드 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.