MQTT에 대해 알아보자

개요

MQTT (Message Queuing Telemetry Transport)는 IoT 환경에서 사용하는 경량의 Publish/Subscribe (발행/구독) 프로토콜이다. 저전력과 낮은 대역폭 환경에서도 메시지를 효율적으로 전달할 수 있다는 특징이 있다.

• Publisher: 데이터를 전송하는 클라이언트
• Subscriber: 특정 데이터를 받는 클라이언트
• Broker: 중개자로서 Publisher가 보낸 데이터를 받아 Subscriber에게 전달

  

  chatGPT가 그린 MQTT 흐름도

 

---

상세

다음은 MQTT에서 자주 쓰이는 용어와 프로토콜의 특징이다.

• Topic: 메시지의 주제를 나타내는 이름으로, 데이터를 구분하는 역할을 한다.
• MQTT Broker: 메시지 중개자
• 인증 방식: 안전한 통신을 위해 ID/PW 또는 PSK (Pre-Shared Key)를 활용한다.
• QoS (Quality of Service): MQTT는 메시지 전송의 신뢰성 수준을 QoS로 설정이 가능하다.
  • QoS 0: 한번만 보내고 확인하지 않음 (가장 빠른 속도)
  • QoS 1: 최소 한번 전달 (브로커에서 확인 응답)
  • QoS 2: 정확히 한번만 전달 (가장 신뢰성 높음, 복잡함)

---

SNMP/TCP vs MQTT

이미 SNMP/TCP 프로토콜이 많은 산업 환경이 자리 잡았다. 근데 MQTT를 써야 하는 이유는 무엇일까? 먼저 표로 비교해보자.

항목	SNMP / Modbus	MQTT
통신 모델	Poll-based (요청→응답)	Push-based (발행→구독)
메시지 흐름	클라이언트가 주기적으로 GET/READ 요청 ⇒ 장비가 응답(RESPONSE)	퍼블리셔가 이벤트 발생 시 PUBLISH ⇒ 브로커가 SUBSCRIBER에 배포
세션 유지	없음 (매번 독립 요청)	연결 유지(Keep-alive) 후 제어 패킷만 교환
오버헤드	SNMP: UDP 패킷 + PDU 구조 (약 40B 이상) Modbus/TCP: TCP 헤더 + MBAP 헤더(7B)	최소 2바이트 고정 헤더 + 토픽·페이로드
네트워크 부하	폴링 주기에 비례해 트래픽 증가	이벤트 발생 시점에만 트래픽 발생
지연(latency)	폴링 주기(ms~s) 의존	즉시 전송 → 대기시간 최소화
확장성	요청 수×장비 수만큼 서버 부담	라이트웨이트 세션 테이블 관리로 수만~수십만 동시 접속
리소스 제약	장비 부담↑ (요청 처리·PDU 생성)	장치 부담↓ (긴 세션 유지 후 소량 데이터 교환)
QoS(신뢰성)	없음 (재시도 로직 직접 구현)	QoS 0/1/2 내장 지원
보안	SNMPv3: TLS/SHA 기반 인증·암호화 Modbus TLS: 추가 모듈 필요	TLS (포트 8883), PSK/인증서, ACL
오프라인 내구성	네트워크 복구 시 “최신값” 보장 불가	Retain, Last Will, Offline 큐잉
토폴로지 관리	일대일 통신, 직접 연결 필요	브로커 중심 탈중앙화, 다중 구독자 지원
클라우드 연동	별도 게이트웨이·어댑터 필요	AWS IoT·Azure IoT 등 네이티브 지원
구현 복잡도	단순 레지스터/벤더 MIB 정의	브로커 설정·토픽 설계 필요
장점 요약	• 익숙한 산업 표준 • 실시간 제어(Polling)	• 이벤트 기반 실시간성 • 저전력·저대역폭 • 대규모 확장성

1. 통신 모델 & 네트워크 부하
   • SNMP/Modbus: 제어 서버가 주기적으로 센서 장비에 요청을 보내야 하므로, polling 주기가 짧을수록 트래픽이 증가
   • MQTT: 한번 세션을 맺으면 계속 유지. 이벤트 발생 시점에만 패킷과 페이로드를 보내므로 대역폭 부담이 적음.
2. 지연 & 실시간성
   • SNMP/Modbus: 요청-응답 사이클이 polling 주기에 묶여 있어 최대 주기만큼 지연될 수 있음
   • MQTT: 장비에서 publish 호출 즉시 브로커가 subscribe된 소비자에게 전달하므로 실시간 알림/제어에 유리
3. 확장성 & 동시 접속
   • SNMP/Modbus: 장비 수가 늘어날수록 polling 요청 수가 선형적으로 증가 → 서버 성능 저하 우려
   • MQTT: 브로커는 경량 세션 테이블과 이벤트 라우팅 구조로 설계되어, 동시 세션과 메시지 분배를 효율적으로 처리함
4. QoS (신뢰성) & 오프라인 대응
   • SNMP/Modbus: 메시지 전송 보장/재시도 로직/재전송 관리 등을 직접 구현해야 함
   • MQTT
     • QoS 0/1/2로 신뢰성 레벨 선택 가능
     • Last Will: 비정상 종료 시 유언 메시지 자동 발행
     • Retain: 재접속 클라이언트가 마지막 상태를 즉시 수신
     • 네트워크 끊김 시 메시지 큐잉 지원
5. 보안 & 인증
   • SNMP(v3): 사용자 기반 인증, 암호화 지원
   • Modbus TLS: 기본 프로토콜에는 미지원 (추가 모듈 필요)
   • MQTT
     • PSK 또는 TLS 기반
     • ACL (Access Control List), 사용자 인증
6. 클라우드, 플랫폼 연동
   • SNMP/Modbus: AWS/Azure 등 클라우드와 직접 연결 불가  → 별도의 게이트웨이/어댑터 필요
   • MQTT
     • AWS IoT, Azure IoT Central 등 주요 서비스에서 네이티브 지원
     • TLS만으로 손쉽게 다이렉트 연결 가능

---

결론

SNMP/Modbus는 익숙하고 안정적인 polling 기반 산업 표준이지만, MQTT는 이벤트 중심 push, 저전력/저대역, 대규모 확장, 클라우드 네이티브, QoS, 오프라인 내구성 등 현대적인 요구사항을 모두 만족시키는 현대형 IoT 프로토콜이다.

따라서 산업용 게이트웨이나 허브 같은 장비에 기존 프로토콜인 SNMP/Modbus와 MQTT를 병행함으로써 

• polling이 필요한 레거시 제어 환경
• 이벤트 기반 실시간 모니터링 및 알림
• 대규모 배포 및 클라우드 통합

위와 같은 요구사항을 동시에 충족할 수 있기 때문에 촉망받는 프로토콜이라고 할 수 있겠다.