Mar 23, 2026

마지막 업데이트 Mar 30, 2026

RabbitMQ Consumers Not Receiving Messages 가이드

RabbitMQ consumer가 연결되어 있는데도 메시지를 받지 못한다면, 보통 RabbitMQ가 갑자기 멈춘 것이 아닙니다. 실제 트래픽 경로와 queue, binding, consumer state, prefetch 경로가 어긋나 있는 경우가 많습니다.

짧게 말하면, 먼저 메시지가 queue까지 도달하지 못하는 문제인지, queue에는 도달했지만 consumer에게 전달되지 않는 문제인지부터 나눠 봐야 합니다.

publish-path failure와 delivery-path failure를 먼저 나누세요

가장 가치가 큰 첫 분기입니다.

queue에 메시지가 없다면 보통 upstream 문제입니다.

잘못된 exchange
잘못된 routing key
binding mismatch
publisher가 다른 곳으로 보내는 경우

queue에 메시지가 있다면 문제는 delivery나 consumer 쪽에 있습니다.

consumer가 기대한 queue를 실제로 구독했는지 확인하세요

RabbitMQ 문서를 보면 존재하지 않는 queue를 consume하면 channel이 에러와 함께 닫힙니다.

즉 애플리케이션 입장에서는 “연결됐다”고 느껴도 실제 subscription 경로는 건강하지 않을 수 있습니다.

확인할 것은 아래입니다.

정확한 queue name
subscription 성공 여부
channel이 여전히 열려 있는지
consumer tag가 유효한지

connection state보다 consumer activity를 보세요

consumer가 연결돼 있어도 아래 이유로 아무 메시지도 못 받을 수 있습니다.

다른 consumer가 single active consumer로 동작 중임
현재 consumer가 이미 많은 unacked delivery를 들고 있음
consumer priority 때문에 delivery가 다른 쪽으로 감

그래서 “앱이 연결돼 있다”는 사실만으로는 충분한 건강 신호가 아닙니다.

prefetch 때문에 멀쩡한 consumer가 멈춘 것처럼 보일 수 있습니다

consumer가 이미 자신의 outstanding delivery window를 꽉 채웠다면, connection은 건강해 보여도 RabbitMQ는 더 이상 새 work를 주지 않을 수 있습니다.

그래서 이 글은 RabbitMQ Messages Stuck in unacked나 RabbitMQ Prefetch Guide와 자주 같이 봐야 합니다.

흔한 원인

1. Binding mismatch

메시지가 consumer가 기대하는 queue로 아예 오지 않습니다.

2. 잘못된 queue 또는 닫힌 channel

팀이 생각하는 위치에서 consumer가 실제로 구독 중이 아닙니다.

3. Single active consumer 동작

다른 consumer가 활성 상태라 현재 consumer는 아무것도 받지 못합니다.

4. Unacked 또는 prefetch saturation

consumer가 더 이상 새 delivery를 받을 수 없는 상태입니다.

실전 점검 순서

1. queue에 실제로 메시지가 있는지 확인합니다

없다면 consumer code가 아니라 publish path와 routing부터 봐야 합니다.

2. consumer subscription이 실제로 성공했는지 확인합니다

연결된 앱이라고 해서 healthy subscription이라고 가정하면 안 됩니다.

3. binding과 routing key를 봅니다

메시지가 다른 곳으로 퍼지고 있다면 consumer 튜닝은 아무 도움이 안 됩니다.

4. single-active-consumer와 consumer-priority 동작을 확인합니다

연결된 consumer가 의도적으로 아무것도 못 받는 상황이 있습니다.

5. prefetch와 unacked delivery를 봅니다

밖에서 보기엔 idle 같아도 RabbitMQ 입장에서는 이미 꽉 찬 consumer일 수 있습니다.

바로 확인할 수 있는 명령어

rabbitmqctl list_queues name messages_ready consumers
rabbitmqctl list_bindings
rabbitmqctl list_consumers

이 명령어들로 queue 상태, consumer attachment, routing 경로를 빠르게 확인할 수 있습니다.

실전 기준

이 incident는 “consumer가 연결돼 있나?”보다 “경로 어디에서 delivery가 멈췄나?”로 보기 시작하면 훨씬 쉬워집니다.

보통 경로는 아래 순서입니다.

publisher
exchange와 routing key
binding
queue
consumer subscription
consumer delivery eligibility

어느 단계가 끊겼는지 빨리 찾을수록 해결도 빨라집니다.

하나 더 유용한 질문

consumer가 연결돼 있고 queue에도 메시지가 있다면, 다음 질문은 “RabbitMQ가 delivery를 안 하는가, 아니면 이 consumer가 지금 추가 work를 받을 자격이 없는가?”가 되어야 합니다.

이 질문으로 보통 아래 가지를 빨리 좁힐 수 있습니다.

consumer가 이미 너무 많은 unacked 메시지를 들고 있음
single-active-consumer 규칙이나 priority가 delivery를 다른 쪽으로 보냄
보고 있는 queue나 binding이 실제 트래픽 queue가 아님

이 질문이 단순한 “왜 RabbitMQ가 멈췄지?”보다 훨씬 더 실전적입니다.

FAQ

Q. consumer가 연결돼 있어도 inactive일 수 있나요?

네. connection state만으로 delivery를 받을 자격이 있다는 뜻은 아닙니다.

Q. queue가 비어 있으면 consumer부터 봐야 하나요?

보통은 아닙니다. publisher, exchange, routing, binding부터 보세요.

Q. 가장 빠른 첫 단계는 무엇인가요?

consumer code를 보기 전에 queue에 메시지가 있는지 확인하세요.

Q. 여러 consumer 중 하나만 못 받으면 무엇을 봐야 하나요?

consumer priority, single-active-consumer 동작, 그리고 그 consumer가 unacked work에 막혀 있는지 보세요.

먼저 읽어볼 가이드

검색 유입이 많은 핵심 글부터 이어서 보세요.