길리랩blog

MQTT 경량 메시징 프로토콜의 구조와 QoS

MQTT의 Pub/Sub 구조, 토픽 설계, QoS 전달 보장 방식과 IoT 환경에서의 보안·구현 고려사항을 정리한다.

2026-08-15 · 최초 발행 2025-06-28

제한된 IoT 환경에서 MQTT가 맡는 역할

MQTT는 1999년 IBM의 Andy Stanford-Clark와 Arcom의 Arlen Nipper가 개발한 메시징 프로토콜이다. 제한된 환경에서 동작하는 IoT 디바이스를 대상으로 설계됐으며, 적은 네트워크 대역폭으로 운용할 수 있는 경량 바이너리 프로토콜이다.

TCP/IP 기반으로 동작하고 오버헤드가 작아 배터리와 대역폭이 제한된 기기에 맞는다. ISO/IEC 20922로 채택되면서 IoT 통신의 사실상 표준으로 자리 잡았다. HTTP와 비교하면 오버헤드를 줄이고 전력 소모를 낮추는 데 초점이 맞춰져 있다.

헤더 크기는 2바이트다. 연결을 유지하는 데 필요한 리소스도 적어 소형 디바이스에서 효율적으로 동작하며, 불안정한 네트워크에서도 신뢰성 있는 통신을 제공한다.

브로커를 중심으로 메시지를 분리하는 방식

MQTT는 기존 클라이언트-서버 모델과 달리 Publisher와 Subscriber를 분리한다. 두 클라이언트는 직접 통신하지 않고 Broker를 통해 메시지를 주고받는다. 브로커가 메시지를 중계하므로 1:1, 1:N, N:N 통신을 모두 구성할 수 있다.

발행자는 메시지를 특정 토픽으로 보내고, 브로커는 해당 토픽을 구독한 클라이언트에 메시지를 배포한다. 이 구조는 토픽 기반 분류와 라우팅을 가능하게 하며, 일대다(1:N) 메시지 배포에 적합하다.

Publisher는 센서나 디바이스처럼 메시지를 생성하는 클라이언트다. 온도 센서, 습도 센서, 모션 감지기 등이 특정 토픽과 메시지 페이로드를 브로커에 전송할 수 있다.

Broker는 중앙 허브로서 발행된 메시지를 수신하고 토픽을 기준으로 필터링한 뒤 구독자에게 전달한다. 클라이언트 연결, 세션, 구독 정보도 관리한다. Mosquitto, HiveMQ, EMQ X 등이 대표적인 브로커다.

Subscriber는 관심 있는 토픽을 등록한 뒤 브로커로부터 관련 메시지를 자동으로 받는다. 모바일 앱, 서버, 다른 IoT 디바이스, 모니터링 애플리케이션, 컨트롤러가 이 역할을 수행할 수 있다.

⤢✕publish to topicforward messageforward messageforward messagePublisherMQTT BrokerSubscriber 1Subscriber 2Subscriber 3

토픽으로 메시지를 식별하고 구독한다

토픽은 계층형 문자열이다. 예를 들어 home/livingroom/temperature처럼 /로 여러 레벨을 구분한다.

와일드카드도 사용할 수 있다.

  • #은 다중 레벨 와일드카드다. home/#은 home 아래의 모든 토픽을 구독한다.
  • +는 단일 레벨 와일드카드다. home/+/temperature는 home 아래 모든 방의 temperature 토픽을 구독한다.
home/livingroom/temperature
home/livingroom/humidity
home/bedroom/temperature
home/+/temperature  # 모든 방의 온도
home/#  # 집의 모든 센서 데이터

토픽은 단순한 이름 규칙이 아니라 발행자와 구독자의 결합도를 낮추는 경계다. 센서 데이터와 제어 메시지를 구분하고, 구독자가 필요한 범위만 받아보게 하는 기준이 된다. 메시지 흐름과 권한 정책을 고려해 구조를 설계해야 한다.

연결부터 종료까지의 메시지 교환

클라이언트는 브로커에 CONNECT 메시지를 보내 연결을 시작한다. 이 메시지에는 클라이언트 식별자, 인증 정보, Keep Alive 간격 등이 들어가며, 브로커는 CONNACK으로 연결 성공 또는 실패를 응답한다.

구독이 필요하면 클라이언트는 관심 토픽을 담은 SUBSCRIBE 메시지를 보낸다. 여러 토픽을 한 번에 구독할 수 있고, 브로커는 SUBACK으로 응답한다.

메시지 발행 시에는 토픽 이름, 페이로드, QoS 수준 등을 포함한 PUBLISH 메시지를 사용한다. 브로커는 그 토픽의 모든 구독자에게 메시지를 전달한다. QoS 1에서는 PUBACK가 사용되며, 연결 유지에는 PINGREQ와 PINGRESP가 쓰인다. 연결을 정상적으로 끝낼 때는 DISCONNECT를 보내며, 브로커는 클라이언트 상태를 정리하고 세션을 관리한다.

⤢✕BrokerClientBrokerClientCONNECTCONNACKSUBSCRIBE (topic: home/temperature)SUBACKPUBLISH (topic: home/temperature, payload: 23.5)Message (topic: home/temperature, payload: 23.5)DISCONNECT

전달 보장 수준은 QoS에서 선택한다

MQTT는 메시지 전달 신뢰성을 조절할 수 있도록 세 가지 QoS 수준을 제공한다. 신뢰성이 높아질수록 통신 오버헤드도 커진다.

QoS 0은 최대 한 번 전달하는 방식이다. "fire and forget" 패턴으로 동작하며, 전달 자체는 보장하지 않는다. 가장 낮은 오버헤드와 높은 성능이 필요한 지속 갱신형 센서 데이터나 일부 손실을 허용할 수 있는 환경에 맞는다.

QoS 1은 최소 한 번 전달한다. PUBACK으로 수신을 확인하고, 확인이 없으면 메시지를 재전송한다. 중복 전달 가능성이 있으므로 중요 알림이나 결제 정보처럼 반드시 전달돼야 하는 메시지에 사용한다.

QoS 2는 정확히 한 번 전달하는 방식이다. 4단계 핸드셰이크를 사용해 중복 없이 메시지를 전달하며, 세 수준 중 신뢰성이 가장 높고 오버헤드도 가장 크다. 금융 트랜잭션이나 중요 제어 명령에 적합하다.

⤢✕QoS 2 (Exactly once)PUBLISHPUBRECPUBRELPUBCOMPPUBLISHPUBRECPUBRELPUBCOMPPublisherBrokerSubscriberQoS 1 (At least once)PUBLISHPUBACKPUBLISHPUBACKPublisherBrokerSubscriberQoS 0 (At most once)PUBLISHPUBLISHPublisherBrokerSubscriber

MQTT 연결에 필요한 보안 경계

인증은 사용자 이름과 비밀번호, 클라이언트 인증서(TLS/SSL), JWT나 OAuth 기반 토큰으로 구성할 수 있다. ACL(Access Control List)을 사용하면 토픽별 권한도 제어할 수 있다.

전송 계층은 TLS/SSL로 암호화한다. 기본 포트는 1883이며 비암호화 연결에 사용되고, 8883은 TLS/SSL 연결에 사용된다. 페이로드 암호화는 엔드투엔드 보안을 강화하는 방법이다.

운영 환경에서는 MQTT 5.0 사용, 강력한 인증 메커니즘, 정기적인 인증 정보 갱신, 세분화된 ACL, 보안 모니터링과 침입 탐지 시스템 구축을 함께 고려해야 한다. 연결 수가 늘어나는 환경에서는 클러스터링을 지원하는 브로커, 부하 분산, 메시지 영속성 설정을 검토하고, Keep-Alive 타이머와 메시지 성격에 맞는 QoS, 토픽 구조, 연결 끊김 대응 전략인 Last Will and Testament도 함께 결정해야 한다.

MQTT 3.1.1과 MQTT 5.0의 차이

MQTT 3.1.1은 2014년 OASIS 표준으로 채택됐고, 대부분의 현재 구현에서 사용된다. 기본적인 Pub/Sub 기능과 QoS를 제공한다.

MQTT 5.0은 2018년에 발표됐다. 메시지 만료 기능, 상세 오류 정보를 위한 Reason Code, 부하 분산을 위한 Shared Subscription, 확장된 메시지 Properties, 강화된 세션 및 메시지 제어 기능을 제공한다.

연결 거부와 구독 실패 이유를 전달하는 사유 코드가 추가됐고, 메시지에는 TTL(Time-To-Live)을 설정할 수 있는 메시지 만료 기능이 생겼다. 주제 별칭은 긴 토픽 이름 대신 숫자 ID를 사용해 오버헤드를 줄인다. 사용자 속성으로 메시지에 메타데이터를 추가할 수 있으며, 공유 구독은 로드 밸런싱을 지원한다. 세션 및 메시지 최대 크기 제한도 리소스 관리 개선을 위한 기능으로 포함됐다.

토픽 설계가 드러나는 적용 장면

스마트홈에서는 온도, 습도, 조명 제어 등 가정 내 IoT 기기를 연동할 수 있다. 스마트 냉장고가 home/kitchen/fridge/temperature 토픽으로 온도 정보를 발행하고, 홈 컨트롤러가 이를 구독해 모니터링하는 방식이다. home/bedroom/light/control처럼 제어용 토픽을 구분할 수도 있다.

산업용 IoT(IIoT)에서는 공장 자동화, 설비 모니터링, 예측 유지보수에 사용할 수 있다. 생산 라인의 센서는 factory/line1/machine3/vibration 토픽으로 진동 데이터를 발행하고, 분석 시스템은 이를 구독해 장비 이상을 조기 감지한다. 공장 기계를 원격 제어하고 설비 상태를 실시간으로 추적할 때는 factory/line1/machine3/status, factory/maintenance/alerts처럼 토픽을 나눌 수 있다.

텔레매틱스와 커넥티드 카에서는 차량 위치 추적과 진단 정보 수집에 활용된다. 차량이 vehicle/ABC123/location 토픽으로 GPS 좌표를 발행하면 플릿 관리 시스템이 이를 구독해 위치를 모니터링할 수 있다. 차량 위치와 상태 정보, 연료 효율성을 전송할 때는 fleet/truck123/location, fleet/truck123/diagnostics 같은 토픽도 사용할 수 있다.

의료 모니터링에서는 환자 생체 신호 모니터링과 의료 장비 원격 관리에 적용할 수 있다. 웨어러블 기기가 patient/1234/heartrate 토픽으로 심박수를 발행하고, 의료진 모니터링 시스템이 이를 구독해 실시간 건강 상태를 확인한다. 의료 장비 상태를 추적할 때는 hospital/ward3/patient45/heartrate, hospital/equipment/status처럼 구분할 수 있다.

구현 단계에서 선택할 클라이언트와 브로커

클라이언트 라이브러리는 언어와 실행 환경에 맞춰 선택한다.

  • Java: Eclipse Paho, HiveMQ MQTT Client
  • Python: Paho-MQTT
  • JavaScript: MQTT.js
  • C/C++: Eclipse Paho C/C++
  • Arduino: PubSubClient

브로커는 오픈소스와 상용 제품으로 나뉜다.

  • 오픈소스: Mosquitto, EMQ X, VerneMQ
  • 상용: HiveMQ, AWS IoT Core, Azure IoT Hub, Google Cloud IoT Core

Mosquitto는 오픈 소스 경량 단일 스레드 브로커로 Eclipse Foundation 프로젝트이며 저사양 기기에 적합하다. HiveMQ는 고가용성과 클러스터링을 지원하는 엔터프라이즈급 브로커다. EMQ X는 대규모 IoT 연결에 최적화되어 있으며 클러스터링, 고성능, 다양한 프로토콜 브리지를 지원한다.

클라이언트 측에서는 Paho가 Java, Python, C, JavaScript 등 다양한 언어를 지원한다. MQTT.js는 Node.js와 브라우저 환경에서 사용할 수 있고, Eclipse Paho는 안드로이드 및 임베디드 시스템용으로 제공된다. MQTT의 경량성은 이런 운영 설계와 결합될 때 IoT 환경의 효율적이고 안정적인 통신으로 이어진다.

MQTTIoT메시징 프로토콜Publish SubscribeQoS