Mar 23, 2026

마지막 업데이트 Mar 31, 2026

RabbitMQ Publisher Confirms 가이드

Publisher confirm은 RabbitMQ에서 가장 자주 오해되는 신뢰성 기능 중 하나입니다. 많은 팀이 이것을 end-to-end 성공 보장처럼 말하지만, 실제로는 훨씬 더 좁고 구체적인 경계를 확인해 주는 기능입니다. confirm path가 건강해도 routing, backlog, consumer 쪽은 충분히 망가져 있을 수 있습니다.

핵심은 먼저 broker가 정확히 무엇을 confirm하는지 정의하고, producer-to-broker safety와 consumer completion, business success를 분리해서 봐야 delivery가 보장됐다는 말을 제대로 할 수 있다는 점입니다.

broker acceptance와 downstream completion을 먼저 분리하세요

이 구분이 가장 중요합니다.

Publisher confirm은 producer 쪽 질문에 답합니다. broker가 publish된 메시지를 받았는가를 확인해 줍니다. 하지만 아래 질문에는 답하지 않습니다.

consumer가 이미 받았는가
consumer가 성공적으로 처리했는가
business operation이 끝났는가

이 보장들을 섞어 말하면 RabbitMQ incident가 아주 빠르게 헷갈려집니다.

publisher confirm은 실제로 무엇을 위한 기능인가

RabbitMQ 문서에서 confirm은 publisher가 broker가 메시지를 받아들였는지 알기 위한 메커니즘입니다.

그래서 producer-side safety와 retry 판단에는 유용합니다. 하지만 consumer acknowledgement, DLX 확인, backlog 모니터링, business-level observability를 대체하지는 못합니다.

가장 흔한 오해

전형적인 실패 패턴은 이렇습니다.

publisher가 confirm을 받는다
팀이 delivery flow 전체가 성공했다고 믿는다
실제 문제는 routing, backlog, dead lettering, slow consumer 쪽에 있다

그래서 confirm path는 건강한데 시스템 전체는 unhealthy한 상태가 충분히 가능합니다.

confirm과 consumer acknowledgement는 다릅니다

RabbitMQ는 publisher confirm과 consumer delivery acknowledgement를 서로 다른 메커니즘으로 다룹니다.

즉 confirm은 문제없어도 시스템은 아래 상태일 수 있습니다.

backlog 증가
unacked 증가
dead-letter 누적
consumer stall

“메시지는 confirm됐는데 실제 작업은 안 됐다”를 보고 있다면 이미 confirm boundary 바깥 문제를 보는 것입니다.

흔한 troubleshooting 패턴

1. confirm은 건강한데 queue는 계속 밀린다

producer safety는 괜찮고 consumer throughput이 문제입니다.

2. confirm이 있는데도 운영자는 delivery를 신뢰하지 못한다

실제 공백은 routing, dead letter, retry, downstream completion tracking에 있습니다.

3. confirm이 느리거나 timeout이 난다

producer path가 broker 상태, resource pressure, 측정되지 않은 publish path를 기다리고 있을 수 있습니다.

4. 팀이 confirm이 증명하는 범위를 과대평가한다

broker acceptance를 application success처럼 취급합니다.

실전 점검 순서

1. 우리가 실제로 필요한 보장이 무엇인지 정의합니다

producer acceptance, broker durability, consumer completion, business success는 서로 다릅니다.

2. 진짜 관심사가 producer safety인지 downstream completion인지 구분합니다

문제가 “broker가 받았는가”라면 confirm이 중요합니다. “앱이 끝까지 처리했는가”라면 confirm은 전체 그림의 일부일 뿐입니다.

3. backlog, dead letters, `unacked`를 같이 봅니다

많은 incident에서 실제 모양은 여기서 드러납니다. publish path는 멀쩡한데 consumer 쪽은 분명히 unhealthy할 수 있습니다.

4. confirm timing과 downstream timing을 따로 측정합니다

broker acceptance boundary와 downstream completion boundary를 분리해서 봐야 합니다.

5. 이 보장 경계를 팀 안에 문서화합니다

많은 RabbitMQ incident가 반복되는 이유는 guarantee boundary가 명확히 합의되지 않았기 때문입니다.

바로 확인할 명령

rabbitmqctl list_connections name state send_pend
rabbitmqctl list_channels connection name confirms_uncommitted
rabbitmq-diagnostics status

이 명령으로 confirm 지연이 broker pressure, channel 상태, resource alarm 때문인지 빠르게 볼 수 있습니다.

가장 도움이 되는 질문 하나

좋은 질문은 “RabbitMQ가 delivery를 보장하나?”보다 “RabbitMQ가 어떤 경계를 confirm하나?”입니다.

이 관점이 있으면 대화가 훨씬 정확해집니다.

broker acceptance는 하나의 경계
consumer completion은 다른 경계
business success는 또 다른 경계

팀이 이 경계를 합의하면 retry 로직과 incident 분석 둘 다 훨씬 쉬워집니다.

FAQ

Q. publisher confirm은 consumer 처리 성공까지 보장하나요?

아니요. producer-to-broker 쪽 경계만 알려줍니다.

Q. confirm과 acknowledgement는 같은 것인가요?

아니요. 서로 다른 부분을 위한 다른 메커니즘입니다.

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

우리가 필요한 보장이 정확히 무엇인지 정의하고, 문제를 producer acceptance와 downstream completion 중 어디로 볼지 결정하는 것입니다.

Q. confirm 다음에는 무엇과 비교해 봐야 하나요?

보통 queue backlog, dead letter, consumer acknowledgement, downstream completion metric입니다.

먼저 읽어볼 가이드

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