데드레터 큐란 무엇인가
메시지 큐를 사용하는 시스템에서는 컨슈머(소비자)가 메시지를 처리하다가 실패하는 경우가 종종 발생합니다. 네트워크 오류, 잘못된 데이터 형식, 일시적인 서버 장애 등 원인은 다양합니다. 이때 실패한 메시지를 그냥 버리거나 무한정 재시도하게 두면 시스템 전체가 멈추거나 장애 원인을 파악하기 어려워집니다. 데드레터 큐(Dead Letter Queue, DLQ)는 이렇게 정상적으로 처리되지 못한 메시지를 별도로 격리해서 보관하는 큐입니다. 우체국에서 배달에 실패한 우편물을 반송하지 않고 별도 보관함에 모아두는 것과 비슷한 개념이라고 생각하면 이해하기 쉽습니다.
동작 원리와 예시
일반적으로 메시지 큐 시스템에는 재시도 횟수 제한이 설정되어 있습니다. 예를 들어 AWS SQS에서는 maxReceiveCount 값을 지정해, 메시지가 이 횟수만큼 컨슈머에게 전달되었는데도 처리(ack)되지 못하면 자동으로 DLQ로 이동시킵니다. RabbitMQ에서는 메시지가 거부(nack)되거나 TTL(유효시간)이 만료되었을 때 지정된 데드레터 익스체인지로 라우팅되는 방식으로 동작합니다.
예를 들어 주문 처리 큐에서 재고 확인 API 호출이 실패했다고 가정해봅시다. 컨슈머는 재시도를 몇 차례 시도하지만 계속 실패하면, 해당 주문 메시지는 원래 큐에서 빠져나와 DLQ에 쌓입니다. 이후 개발자는 DLQ에 쌓인 메시지를 확인하여 실패 원인을 분석하고, 데이터 수정 후 재처리하거나 알림을 통해 즉시 대응할 수 있습니다.
실무에서 왜 쓰는가
DLQ를 사용하는 가장 큰 이유는 메시지 유실 방지와 장애 격리입니다. 실패한 메시지가 계속 큐에 남아 재시도만 반복되면 정상 메시지 처리 속도가 느려지고, 큐 전체가 병목 현상을 겪을 수 있습니다. DLQ로 실패 메시지를 분리하면 정상 흐름을 방해하지 않으면서도 실패 데이터를 안전하게 보관할 수 있습니다.
- 실패 원인 분석 및 디버깅이 쉬워짐
- 재처리(reprocessing) 로직을 별도로 구현 가능
- 모니터링 시스템과 연동해 장애 알림 자동화 가능
결국 데드레터 큐는 단순히 실패를 숨기는 장치가 아니라, 실패를 ‘가시화’하여 시스템 안정성과 운영 효율성을 높이는 핵심적인 아키텍처 패턴이라고 할 수 있습니다.