메시지 큐잉으로 비동기 통신과 시스템 결합도 낮추기
메시지 큐잉의 비동기 통신 구조, 전달 모델, 브로커별 특성과 분산 시스템 설계 시 고려할 요소를 정리합니다.
2026-08-14 · 최초 발행 2026-01-03
송신자와 수신자 사이에 큐를 둔다
메시지 큐잉은 프로세스, 애플리케이션, 시스템 사이의 메시지를 비동기로 전달하는 통신 방식이다. 송신자는 메시지를 큐에 넣고 다음 작업으로 넘어가며, 수신자는 준비된 시점에 메시지를 꺼내 처리한다.
이 중간 계층은 단순한 전달 통로가 아니다. 송신자와 수신자를 직접 연결하지 않아도 되게 만들고, 서로의 위치·실행 시점·확장 속도를 분리한다. 분산 시스템과 마이크로서비스에서 메시지 큐가 핵심 인프라로 쓰이는 이유다.
큐는 일반적으로 FIFO(First In First Out) 방식으로 메시지를 저장하고 전달한다. 송신자는 메시지를 보낸 뒤 응답을 기다리지 않고 다른 일을 할 수 있으며, 수신자는 송신자와 동시에 실행 중일 필요가 없다.
비동기 처리에서 얻는 성질
메시지 큐는 송신과 수신의 시간을 분리한다. 수신자가 즉시 처리할 수 없어도 메시지는 큐에 남아 있다가 처리될 수 있고, 송신자는 전송 이후 블로킹되지 않는다.
이 구조에서는 위치도 분리된다. 송수신자는 서로의 위치를 알 필요가 없으며, 메시지 큐 프로토콜을 준수하는 한 독립적으로 확장할 수 있다. 여러 생산자가 하나의 큐에 넣고 여러 소비자가 이를 나눠 처리하는 방식으로 로드 밸런싱과 수평 확장도 가능하다.
신뢰성은 메시지 영속성, 실패 시 재시도, 전송·수신의 트랜잭션, 선택적인 FIFO 순서 보장으로 다룬다. 다만 모든 시스템이 같은 수준의 보장과 순서 정책을 제공하는 것은 아니므로, 구현체의 특성과 요구사항을 함께 확인해야 한다.
작업을 하나에게 넘길지, 모두에게 알릴지
포인트 투 포인트 모델에서는 하나의 메시지를 하나의 수신자만 처리한다. 여러 수신자가 같은 큐를 감시할 수 있지만, 경쟁 소비자로서 메시지를 나눠 받는다. 처리된 메시지는 큐에서 제거되며, 작업 분배에 맞는 구조다.
발행-구독 모델은 메시지를 토픽으로 분류하고, 해당 토픽을 구독한 대상에 메시지 사본을 전달한다. 이벤트 하나에 여러 서비스가 반응해야 할 때 적합하다. 메시지는 수신 뒤에도 일정 시간 유지될 수 있다.
구현체에 따라 두 모델은 섞여 쓰인다. Kafka는 토픽과 파티션을 이용해 병렬 처리를 지원하고, RabbitMQ는 Exchange와 Routing으로 메시지 경로를 유연하게 정한다. 연속적인 메시지 스트림을 처리하는 방식도 이 범주에 포함된다.
브로커가 맡는 일과 메시지의 형태
메시지 브로커는 메시지를 수신·저장·라우팅·전달하는 중앙 서버다. 큐의 생성과 삭제, 모니터링, 디스크 영속화, 인증과 권한 관리도 브로커의 역할에 포함된다.
메시지는 보통 헤더, 속성, 바디로 구성된다. 헤더에는 ID·타임스탬프·우선순위 같은 메타데이터가 들어가고, 속성에는 TTL과 라우팅 키 같은 특성이 담긴다. 바디는 텍스트, JSON, 바이너리 등의 실제 데이터다. 송수신 확인에는 ACK/NACK 메커니즘을 사용한다.
메시지 큐 시스템별 성격
RabbitMQ는 AMQP 프로토콜을 구현하며 Direct, Topic, Fanout, Headers Exchange 타입을 제공한다. 복잡한 라우팅 규칙과 MQTT, STOMP 등의 플러그인 확장, 웹 기반 관리 UI가 필요한 환경에 맞는다.
Apache Kafka는 고성능 로그 스트리밍을 위한 분산 스트리밍 플랫폼이다. 토픽을 파티션으로 분할해 병렬 처리하며, 메시지를 디스크에 저장하고 장기 보관한다. 초당 수백만 메시지를 처리할 수 있고, Consumer Group으로 로드 밸런싱을 수행한다. 로그 수집, 이벤트 스트리밍, 실시간 분석에 적용된다.
Redis는 인메모리 기반으로 Pub/Sub와 로그 형태의 Streams를 제공한다. 설정과 운영이 가볍고 고속 처리에 적합하지만, 영속성은 제한적이며 메모리에 의존한다.
Amazon SQS는 AWS의 완전 관리형 서비스다. 자동 확장을 제공하며, 표준 큐는 At-least-once 전달과 높은 처리량을, FIFO 큐는 Exactly-once 전달과 순서 보장을 제공한다. 인프라를 직접 관리하지 않는 서버리스 환경에 사용할 수 있다.
ActiveMQ는 Java Message Service 표준을 구현하며 AMQP, MQTT, STOMP, OpenWire를 지원한다. 트랜잭션과 클러스터링을 제공하는 엔터프라이즈 환경, 특히 Java 애플리케이션에 적합하다.
큐를 사용하는 대표적인 흐름
작업 큐는 이미지 처리, 이메일 발송, 리포트 생성처럼 시간이 걸리는 일을 백그라운드로 넘기는 패턴이다. 워커를 늘려 작업을 분산할 수 있다.
이벤트 버스에서는 주문 생성 같은 이벤트를 발행하고, 재고·알림·분석 서비스가 각자 반응한다. 서비스 간 직접 호출을 줄이면서 새 서비스를 추가하기 쉬워진다.
로그 수집에서는 여러 애플리케이션의 로그를 큐에 모아 급증하는 로그를 버퍼링하고, 로그 처리기와 저장소로 이어지는 스트림을 만든다. Kafka를 사용한 대규모 로그 수집, 실시간 스트림 분석, ETL 파이프라인이 여기에 해당한다.
IoT에서는 수많은 디바이스의 센서 데이터를 수집하고 MQTT 같은 경량 메시지 프로토콜을 쓴다. 네트워크가 불안정할 때 메시지를 저장하는 버퍼링도 중요하다. 이커머스에서는 주문·재고·결제·배송 서비스 연계, 비동기 이메일 발송, 사용자 행동 이벤트의 추천 시스템 분석에 쓰이며, 게임에서는 매치메이킹·리더보드·게임 내 이벤트 알림에 활용된다.
요청-응답 패턴은 큐로 원격 호출을 구성한다. 요청과 응답의 CorrelationID를 맞춰 처리하며, 일정 시간 안에 응답이 없으면 실패로 처리한다.
설계에서 먼저 정할 조건
전달 보장 수준은 메시지 손실과 중복 처리의 경계를 정한다. At-most-once는 최대 1회 전달되지만 손실될 수 있고, At-least-once는 최소 1회 전달되지만 중복될 수 있다. Exactly-once는 정확히 1회 전달하지만 구현이 복잡하다.
순서도 별도 요구사항으로 다뤄야 한다. FIFO는 전송 순서대로 수신하는 방식이고, 파티션 순서는 같은 파티션 안에서만 보장된다. 전체 메시지의 글로벌 순서를 보장하면 성능이 저하될 수 있다.
운영에서는 처리량, 메시지 전달 레이턴시, 배치 처리, 압축을 함께 본다. 큐 길이, 메시지 소비 속도, 실패한 메시지 비율, 평균 메시지 지연은 지속적으로 모니터링할 항목이다.
메시지 큐는 비동기 처리, 느슨한 결합, 수평 확장, 메시지 영속성과 재시도, 로드 밸런싱, 트래픽 급증 시의 부하 완충을 제공한다. 반대로 추가 인프라와 관리 복잡도, 큐를 거치며 생기는 지연, 시스템별 순서 보장 제약, 비동기 흐름의 디버깅 어려움, At-least-once 전달에서의 중복 가능성, 브로커 장애에 따른 통신 중단 가능성도 감수해야 한다.
서버리스 환경에서는 AWS Lambda와 SQS, Azure Functions와 Service Bus, Google Cloud Pub/Sub 조합이 사용된다. 엣지 환경에서는 경량 브로커와 로컬 버퍼링, 클라우드 동기화가 중요해지고, AI/ML에서는 실시간 스트림 학습, AI 기반 메시지 라우팅 최적화, 메시지 패턴 이상 탐지와의 통합이 이어진다.