백엔드 메시지 큐 설계, Kafka만 도입하면 기술면접에서 떨어지는 진짜 이유

by 그릿 | GROWTH_ESSAY | 2026-11-11

면접관이 Kafka 도입에서 검증하려는 것은 브로커를 띄워 메시지를 쏜 경험이 아닙니다. 비동기 분산 환경에서 필연적인 네트워크 지연, 메시지 중복, 소비 실패를 어떻게 방어했는지 확인하려는 것입니다. 큐에 메시지를 넣었다고 비즈니스가 안전해지지 않는다는 사실을 모른 채 도구 이름만 나열하면 탈락합니다.

메시지가 두 번 들어오면 결제도 두 번 됩니까?

200명 넘게 멘토링을 하면서 자주 마주친 장면이 있습니다. 3년차 백엔드 멘티의 이력서에 카프카로 주문 비동기 파이프라인을 구축했다고 적혀 있었습니다. 제가 "네트워크 지연으로 동일한 결제 메시지가 컨슈머에 두 번 전달되면 어떻게 되나요?"라고 물었습니다. 멘티는 카프카가 정확히 한 번(Exactly-once)을 지원하니 문제없다고 답했습니다.

현업 분산 환경은 기본적으로 최소 한 번(At-least-once) 전송을 전제로 움직입니다. 브로커 트랜잭션과 애플리케이션 비즈니스 로직은 별개입니다. 컨슈머가 메시지를 처리하고 오프셋을 커밋하기 직전에 서버가 꺼지면 새 컨슈머는 방금 처리한 메시지를 다시 읽습니다. 이때 애플리케이션 레벨에서 멱등키(Idempotency Key)나 고유 번호로 걸러내는 멱등성 설계가 없다면 중복 결제 사고가 터집니다.

컨슈머가 죽으면 실패한 메시지는 어디로 갑니까?

외부 API 장애나 이상 데이터 유입을 대비했는지도 단골 질문입니다. 대책 없이 재시도(Retry)만 걸어두면 처리 불가능한 메시지 하나 때문에 컨슈머가 멈추고 큐의 랙(Lag)이 수만 건으로 치솟습니다.

면접관은 시스템이 깨졌을 때 복구하는 과정을 봅니다. 재시도 횟수를 제한하고 끝까지 실패한 메시지를 별도 실패 큐(DLQ, Dead Letter Queue)로 격리해 알림을 띄우는 파이프라인을 증명해야 합니다. 장애를 통제 가능한 영역으로 분리하는 태도가 진짜 설계 역량입니다.

DB 저장과 메시지 발행이 어긋나면 어떻게 됩니까?

주문 데이터를 DB에 저장했는데 카프카 메시지 전송 중 타임아웃이 나면 어떻게 될까요? 반대로 카프카에는 메시지가 발행되었는데 DB 커밋이 실패하면 데이터 정합성은 깨집니다. 이 이중 쓰기(Dual Write) 문제는 분산 백엔드에서 결코 피해 갈 수 없는 현실입니다.

이때 Transactional Outbox Pattern을 통해 DB 트랜잭션 안에서 아웃박스 테이블에 이벤트를 기록하고 별도 프로세스로 발행하는 대안을 설명해야 합니다. 완벽한 도구는 없습니다. 트레이드오프를 알고 내 시스템에 맞는 선택을 내렸는지 설명하는 개발자가 면접관을 설득합니다.

기술 스택을 얹는 것보다 분산 환경의 실패를 방어하는 논리를 세우는 것이 백엔드 엔지니어의 진짜 경쟁력입니다. 지금 내 백엔드 설계와 커리어 방향이 제대로 가고 있는지 점검이 필요하다면 https://teamgrit.co/direction 에서 확인해보세요.