메시지 전달 보장이란?
분산 시스템에서 메시지 큐나 이벤트 스트리밍(Kafka, RabbitMQ 등)을 사용할 때, 생산자(Producer)가 보낸 메시지가 소비자(Consumer)에게 얼마나 확실하게 전달되는지를 나타내는 개념이 ‘메시지 전달 보장(Delivery Guarantee)’입니다. 네트워크는 언제든 끊길 수 있고, 서버는 죽었다 살아날 수 있기 때문에 ‘메시지가 정확히 한 번만 처리됐다’는 것을 보장하기란 생각보다 까다롭습니다. 대표적으로 At-Most-Once, At-Least-Once, Exactly-Once 세 가지 방식이 있으며, 오늘은 실무에서 가장 많이 비교되는 At-Least-Once와 Exactly-Once의 차이를 살펴보겠습니다.
동작 원리와 예시
At-Least-Once는 ‘최소 한 번은 전달됨’을 보장합니다. 소비자가 메시지를 받고 처리한 후 ‘잘 받았다’는 ACK을 보내기 전에 장애가 나면, 시스템은 메시지가 처리되지 않았다고 판단해 다시 전송합니다. 그 결과 동일한 메시지가 중복으로 처리될 수 있습니다. 마치 택배 기사가 문 앞에 물건을 두고 갔는데, 배송 확인 문자를 못 받아서 ‘혹시 몰라서’ 하나 더 보내는 것과 비슷합니다. 받는 사람 입장에서는 같은 물건이 두 번 올 수도 있는 거죠.
반면 Exactly-Once는 ‘정확히 한 번만’ 처리됨을 보장합니다. 메시지가 중복 전송되더라도 소비자 측이나 시스템 내부에서 중복을 감지해 실제 처리는 단 한 번만 일어나도록 만듭니다. 예를 들어 Kafka는 프로듀서의 멱등성(Idempotent Producer)과 트랜잭션 기능을 결합해 Exactly-Once에 가까운 처리를 지원합니다. 메시지에 고유한 ID를 부여하고, 이미 처리된 ID는 다시 처리하지 않는 방식(중복 제거, Deduplication)이 핵심 원리입니다.
실무에서 왜 중요한가
결제 시스템을 생각해보면 차이가 명확해집니다. ‘1만원 결제’ 메시지가 중복 처리되면 고객 계좌에서 2만원이 빠져나가는 심각한 문제가 생깁니다. 이런 경우엔 Exactly-Once에 가까운 보장이 필요하며, 실제로는 완벽한 Exactly-Once 대신 At-Least-Once + 애플리케이션 레벨의 멱등성 처리(예: 결제 요청 ID로 중복 체크)를 조합하는 경우가 많습니다.
- At-Least-Once: 구현이 비교적 간단하고 성능 오버헤드가 적지만, 중복 처리 가능성이 있어 소비자 측에서 멱등성을 보장해야 함
- Exactly-Once: 안정성은 높지만 트랜잭션 관리, 상태 저장 등으로 인해 시스템 복잡도와 지연 시간이 증가함
결국 ‘어떤 보장을 선택할 것인가’는 트레이드오프의 문제입니다. 로그 수집처럼 약간의 중복이 허용되는 시스템이라면 At-Least-Once로 충분하지만, 금융 거래처럼 정확성이 생명인 경우에는 Exactly-Once 수준의 설계와 멱등성 처리를 함께 고민해야 합니다.