Poison Message의 정의
Poison Message(포이즌 메시지)란 메시지 큐 시스템에서 정상적으로 처리되지 못하고 계속 실패하는 메시지를 의미합니다. 소비자(Consumer)가 메시지를 처리하려고 할 때마다 예외가 발생하고, 큐 시스템은 실패한 메시지를 다시 큐에 돌려놓는 재시도(Retry) 로직을 갖고 있는 경우가 많습니다. 문제는 이 메시지 자체에 결함이 있어서 아무리 재시도해도 절대 성공하지 못한다는 점입니다. 마치 독약이 든 음식처럼, 한 번 시스템에 들어오면 처리 파이프라인 전체를 마비시킨다고 해서 ‘포이즌’이라는 이름이 붙었습니다.
예를 들어 JSON 형식으로 데이터를 주고받기로 약속했는데, 어떤 이유로 깨진 형식의 메시지 하나가 큐에 들어왔다고 가정해봅시다. 컨슈머는 이 메시지를 파싱하려다 매번 오류를 내고, 큐는 ‘처리 실패했으니 다시 넣어줘’라는 로직에 따라 계속 같은 메시지를 재전달합니다. 이 과정이 반복되면 정상 메시지들은 뒤에서 대기하며 처리되지 못하고, 시스템 리소스는 실패한 재시도에 계속 낭비됩니다.
동작 원리와 발생 예시
포이즌 메시지가 발생하는 원인은 다양합니다.
- 메시지 포맷이 깨져 있어 역직렬화(Deserialize)에 실패하는 경우
- 메시지 내용은 정상이지만 처리 로직에서 예외를 일으키는 특정 값이 포함된 경우 (예: null 값, 존재하지 않는 참조 ID)
- 컨슈머 코드 자체에 버그가 있어 특정 조건의 메시지만 처리하지 못하는 경우
이를 방지하기 위해 대부분의 메시지 큐 시스템은 ‘최대 재시도 횟수’라는 개념을 둡니다. 예를 들어 RabbitMQ나 AWS SQS, Kafka 기반 시스템에서는 특정 횟수(예: 5회) 이상 처리에 실패한 메시지를 별도의 ‘Dead Letter Queue(DLQ)’로 옮기는 방식을 사용합니다. DLQ는 일종의 격리 병동 같은 공간으로, 문제 메시지를 메인 큐에서 빼내어 정상 흐름을 방해하지 않도록 하고, 이후 개발자가 별도로 원인을 분석할 수 있게 해줍니다.
실무에서 왜 중요한가
실무에서 포이즌 메시지 처리는 시스템 안정성과 직결됩니다. DLQ 설정이 없으면 하나의 불량 메시지 때문에 전체 큐가 정체되고, 이는 곧 서비스 장애로 이어질 수 있습니다. 따라서 컨슈머 코드를 작성할 때는 예외 처리를 꼼꼼히 하고, 재시도 횟수 제한과 DLQ 연동을 반드시 설정하는 것이 권장됩니다. 또한 DLQ에 쌓인 메시지는 알림(Alert)을 연동해 개발자가 즉시 인지하고 원인을 파악할 수 있도록 운영하는 것이 좋은 실무 패턴입니다.