이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
분산 시스템 수업 프로젝트에서 Kafka를 처음 써봤습니다. 메시지가 한 번씩만 처리되는 줄 알았는데, 컨슈머가 처리 도중 실패하면 같은 메시지를 다시 받는다는 걸 직접 겪고 나서야 이해했습니다.
처음에는 컨슈머 코드가 단순히 DB에 값을 저장하는 구조였는데, 같은 메시지가 2번 들어오면 중복 데이터가 생겼습니다. 이를 해결하려고 메시지 ID를 저장해두고 이미 처리된 메시지인지 확인하는 로직을 추가했습니다. 단순해 보이는 처리인데 멱등성을 고려하지 않으면 의외의 오류가 생긴다는 걸 그때 배웠습니다.
Kafka 자체보다 비동기 시스템에서 실패를 어떻게 다루는가가 핵심이라는 걸 그 프로젝트에서 처음 실감했습니다. 정상적인 흐름보다 실패했을 때 어떤 일이 생기는지를 먼저 생각해야 한다는 감각이 생겼습니다.
졸업 프로젝트에서 사용자 행동 이벤트를 Kafka로 수집하고 처리하는 구조를 만들었습니다. 처음에는 메시지를 받는 즉시 오프셋을 커밋하도록 설정했는데, 처리 도중 오류가 나면 그 메시지가 그냥 사라지는 문제가 생겼습니다.
오프셋을 처리 완료 후에 커밋하도록 바꿨더니 실패한 메시지를 다시 처리할 수 있게 됐습니다. 그런데 이번에는 반대로 같은 메시지가 중복으로 처리되는 경우가 생겼습니다. 처리는 완료됐는데 커밋 전에 컨슈머가 재시작된 것이었습니다.
비동기 처리에서 "정확히 한 번"을 보장하는 게 왜 어려운지를 그때 처음 실감했습니다. 적어도 한 번 이상 처리되는 것을 허용하되, 같은 메시지를 처리해도 결과가 같도록 로직 자체를 설계하는 게 더 현실적인 방향이라는 걸 배웠습니다.
비동기 처리 수업에서 Kafka 파티션 구조를 배울 때, 순서 보장이 파티션 내에서만 된다는 점이 처음에 잘 이해되지 않았습니다.
실습에서 주문 이벤트를 3개 파티션으로 나눠서 처리했더니, 같은 주문에 대한 "생성"과 "취소" 이벤트가 서로 다른 파티션으로 들어가서 취소가 먼저 처리되는 경우가 생겼습니다. 같은 키를 가진 메시지가 같은 파티션으로 가도록 파티션 키 설정을 바꾸고 나서야 순서가 맞춰졌습니다.
Kafka를 쓸 때 구조 설계 단계에서 어떤 메시지가 순서를 지켜야 하는지를 먼저 따져봐야 한다는 걸 배웠습니다. 파티션 수를 늘리면 처리량은 올라가지만, 순서 보장 범위가 좁아진다는 점을 설계 단계에서 고려하는 편입니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 마켓컬리 백엔드 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.