이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
팀 프로젝트에서 여러 서비스 사이에 메시지 브로커 미들웨어를 처음 도입해본 경험이 있습니다. 서비스가 직접 통신하던 구조에서 특정 서비스가 느려지면 호출자까지 블로킹되는 문제가 반복됐고, 이를 해결하기 위해 RabbitMQ를 중간에 두었습니다. 초기 설정에서 가장 까다로웠던 건 큐가 소비되지 않을 때 메시지가 쌓이는 문제였는데, Dead Letter Queue를 설정해 처리 실패 메시지를 별도 흐름으로 보내도록 했습니다.
미들웨어는 서비스를 분리하는 동시에 운영 복잡도를 새로 만든다는 점을 도입 후에야 실감했는데, 브로커 자체가 장애 단위가 되기 때문에 모니터링과 재처리 설계가 처음부터 필요했습니다. 지금도 비동기 아키텍처를 도입할 때 메시지 손실 시나리오를 먼저 그려보는 습관을 유지하고 있습니다.
RabbitMQ를 도입하고 나서 브로커가 재시작했을 때 큐에 쌓여 있던 메시지가 모두 사라진 경험을 했습니다. 지속성 설정을 확인했더니 큐와 메시지 모두 durable 설정이 돼 있지 않아 재시작 후 초기화된 것이었습니다. 설정을 수정했지만, 이미 처리 중이던 메시지를 어떻게 복구하는가에 대한 절차가 없었습니다. 미들웨어를 쓴다는 것은 비동기 처리의 이점을 얻는 대신 메시지 손실·중복·순서 보장 문제를 직접 다루는 결이 있다는 것을 이 경험에서 실감했습니다.
미들웨어는 아키텍처를 단순하게 만들지 않고 복잡도를 이동시키는 결이 있었습니다. 이 한계를 인정하고 나서야 운영 절차를 제대로 갖추게 됐습니다.
미들웨어 운영 중 메시지 중복 처리 문제를 경험했습니다. 네트워크 불안정으로 ack가 전달되지 않아 브로커가 메시지를 다시 전달하는 케이스가 있었습니다. 소비자가 같은 메시지를 두 번 처리하면서 DB에 중복 레코드가 삽입되는 결과가 생겼습니다. 메시지에 고유 ID를 포함하고, 소비자가 처리하기 전에 이미 처리한 ID인지 확인하는 멱등성 소비자를 만들었습니다. 이 설계 덕분에 같은 메시지가 여러 번 전달돼도 결과가 달라지지 않는 구조가 됐습니다.
비동기 시스템에서는 exactly-once 처리 보장이 어렵기 때문에 소비자가 멱등하게 동작하는 것이 현실적인 결이라는 것을 이 경험에서 배웠습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 넥스트증권 백엔드 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.