RabbitMQ와 MQTT의 역할과 용도

 

[개요]

안녕하세요. 오늘은 메시지 브로커(Message Broker) 기술인 RabbitMQ와 MQTT에 대해 쉽게 설명해보겠습니다. 이 두 기술은 보통 서버와 서버, 혹은 디바이스와 디바이스 사이에서 “메시지”를 주고받는 데 사용됩니다. 메시지를 빠르고 효율적으로 주고받게 함으로써, 서로 다른 시스템을 느슨하게 연결하고, 확장성을 높일 수 있죠.

대표적인 예시로, 우리가 친구와 채팅을 나눌 때 메시지가 엄청나게 빠른 속도로 주고받아지거나, 수많은 IoT 센서들이 실시간으로 데이터를 전송할 때, 이 메시지 브로커들이 뒤에서 열일하고 있습니다.

---

[RabbitMQ란?]

RabbitMQ는 **AMQP(Advanced Message Queuing Protocol)**라는 표준 프로토콜 기반 메시지 브로커입니다. 쉽게 말해, "메시지를 잘 전달하고 보관하는 우체국" 역할을 합니다.

• 메일을 보내는 사람(발행자, Publisher)이 편지를 우체국(브로커)으로 보내면,
• 우체국은 이를 큐(Queue)에 쌓아두었다가
• 편지를 받을 준비가 된 사람(소비자, Consumer)에게 그 편지를 전달합니다.

이렇게 발행(Publish)과 소비(Consume)를 분리함으로써, 서로 다른 서비스끼리 독립적으로 발전할 수 있고, 메시지를 받은 쪽이 잠시 바빠 메시지를 즉시 처리할 수 없어도 나중에 큐에 쌓인 메시지를 꺼내 처리할 수 있습니다.

활용 예시:

• 페이스북 채팅: 페이스북 같은 대규모 서비스에서는 메시지를 실시간으로 주고받을 때 직접 서버끼리 “핑퐁”하는 방식이면 엄청나게 비효율적입니다. 대신 RabbitMQ 같은 메시지 브로커를 둬서 “나 메시지 하나 보냈어!”하면, 브로커가 받아 소비자에게 적절히 전달해줍니다. 이렇게 하면 한쪽 서버가 잠시 문제가 생겨도, 메시지는 큐에 남아있다가 나중에 처리될 수 있어 서비스 안정성이 올라갑니다.
• 서버 간 비동기 처리: 예를 들어, 웹 서버가 사용자의 업로드 요청을 받으면 그 처리를 RabbitMQ 큐에 넣고, 그 작업을 처리하는 별도의 워커(Worker) 서버가 큐에서 메시지를 가져와 시간이 오래 걸리는 작업을 수행할 수 있습니다. 웹 서버는 빠르게 응답하고, 처리결과는 나중에 알림으로 보내면 됩니다.

---

[MQTT란?]

MQTT(Message Queuing Telemetry Transport)는 IoT(사물인터넷) 디바이스용 경량 메시지 프로토콜입니다. “아주 가벼운 우편 서비스”라고 보면 됩니다. MQTT는 저전력, 저대역폭 환경에서 최소한의 프로토콜 오버헤드로 데이터를 전송하도록 설계되었습니다.

특징:

• 매우 가벼운 프로토콜: IoT 센서나 드론, 온도계 같이 네트워크가 취약하거나 전력이 제한적인 환경에서도 효율적으로 동작.
• Publish/Subscribe 모델: 디바이스가 특정 토픽(Topic)에 메시지를 발행하면, 그 토픽을 구독한 구독자(Subscribers)는 해당 메시지를 받아볼 수 있습니다. 토픽은 우체국이 제공하는 “사서함” 주소 역할을 하고, 특정 키워드나 경로로 메시지를 그룹화할 수 있습니다.

활용 예시:

• IoT 센서 데이터 전송: 드론이 날며 위치, 속도, 배터리 상태를 MQTT로 보내면, 지상 관제 서버나 다른 디바이스가 그 토픽을 구독해 데이터를 받아볼 수 있습니다.
• 스마트홈: 스마트조명, 스마트에어컨이 MQTT 브로커에 온도·습도·조명 상태를 발행하면, 이를 구독하는 애플리케이션(스마트폰 앱)에서 실시간 상태를 확인하고 제어할 수 있습니다.

---

[페이스북 채팅에서 RabbitMQ 사용 예시]

간단 시나리오:

• A가 B에게 메시지를 보냅니다.
• 메시지는 바로 B 서버로 가지 않고, RabbitMQ에 들어갑니다(“보관”).
• B 서버가 메시지를 받을 준비가 되면, RabbitMQ는 메시지를 B에게 전달합니다.
• B가 메시지를 받아 사용자에게 보여줍니다.

이런 구조라면 갑자기 B 서버가 잠시 처리 불가능한 상태라 하더라도, 메시지는 잃어버리지 않고 큐에서 대기합니다. B 서버가 복구되면 그동안 쌓여있던 메시지를 차례로 가져가면 됩니다.

---

[IoT 환경에서 MQTT 사용 예시]

드론 데이터 흐름:

• 드론 FC(Flight Controller)는 1초마다 현재 위치, 속도, 고도 정보를 MQTT 브로커에 “/drone/position”이라는 토픽으로 발행합니다.
• 관제 앱(구독자)은 “/drone/position” 토픽을 구독하고 있어, 새로운 메시지가 오면 실시간으로 지도에 드론 위치를 업데이트합니다.
• 외부 서버(예: 분석 서버)는 또 다른 토픽 “/drone/telemetry”를 구독해 드론의 센서 데이터를 받아, 이를 DB에 저장한 뒤 이상 상태(배터리 부족, 센서 고장 등)를 감지하면 경보를 발송할 수 있습니다.

---

[여러 디바이스 입력을 받아 결과를 처리하는 메시지 이동 흐름]

이제 RabbitMQ나 MQTT를 이용한 전체 흐름을 예로 들어보겠습니다.
여기서는 IoT 디바이스(드론, 센서)와 서버가 함께 있는 시나리오를 생각해봅시다.

[드론/센서] --(MQTT)--> [MQTT 브로커] --(데이터)--> [서버(소비자)]
                                           |
                                           |--(RabbitMQ를 통한 비동기 작업)---> [분석 서버] 
                                                                |
                                                                V
                                                              [DB 저장 및 처리]

• 드론이나 센서는 MQTT 프로토콜로 가벼운 메시지를 주기적으로 발행합니다(토픽 기반).
• MQTT 브로커는 이 메시지를 받아 구독자(서버)에 전달합니다.
• 서버는 이 데이터를 기반으로 단기 처리(실시간 모니터링)는 직접 수행하고, 더 무거운 분석 작업(빅데이터 처리, AI 분석)은 RabbitMQ에 전달합니다. RabbitMQ는 이 분석 요청 메시지를 대기열에 넣고, 분석 서버(워커)가 이를 천천히 처리합니다.
• 분석이 끝난 결과는 다시 DB에 저장하거나, MQTT를 통해 다른 디바이스에 전송하거나, RabbitMQ를 통해 알림 서버로 전달할 수 있습니다.

이런 식으로 메시지(데이터)는 디바이스 → MQTT 브로커 → 서버 → RabbitMQ → 분석 서버 → DB 처럼 다양한 경로를 거치며 효율적으로 이동합니다. 각각의 단계에서 특정 역할(실시간 처리, 비동기 처리, 데이터 저장)을 분담하므로 전체 시스템이 확장성과 안정성을 확보할 수 있습니다.

---

[정리]

• RabbitMQ: 서버 간 메시지 전달, 비동기 처리에 강한 메시지 브로커. 대기열(큐)에 메시지를 쌓아뒀다가 소비자가 준비되면 꺼내 처리할 수 있어 서비스 안정성과 유연성을 높입니다.
• MQTT: 주로 IoT 환경에서 사용되는 경량 메시지 프로토콜. 디바이스에서 토픽 기반으로 메시지를 발행하고, 구독자는 해당 토픽을 실시간 수신. 저전력, 저대역폭, 실시간 모니터링에 특화되어 있습니다.
• 사용 사례:
  • RabbitMQ: 페이스북 채팅처럼 대규모 메시지 서비스나 서버 간 비동기 작업 처리에 활용
  • MQTT: 드론, 센서, 스마트홈 기기에서 실시간 데이터 전송에 활용
• 메시지 흐름: 디바이스 → 브로커(예: MQTT 브로커) → 서버 → 메시지 큐(RabbitMQ) → 분석/DB 등 다양한 경로로 메시지가 이동하며, 각 단계에서 처리 형태(실시간/비동기), 프로토콜 특성(MQTT/RabbitMQ)이 맞는 방식을 선택해 시스템을 구성합니다.

이런 방식을 통해 대규모 서비스나 IoT 환경에서 안정적이고 확장 가능한 아키텍처를 구현할 수 있습니다.