MQTT & IoT Messaging Protocols

1. Overview

MQTT와 IoT 메시징 프로토콜(MQTT & IoT Messaging Protocols)은 스마트폰과 서버가 통신하던 무겁고 끈적한 HTTP 웹 기술을 쓰레기통에 처박고, 반경 수천 킬로미터에 흩어진 수백만 개의 배터리 구동 센서(IoT)들이 극단적으로 얇은 패킷과 비동기(Asynchronous) 이벤트로 서버와 대화하는 초경량 통신 배관 공학입니다.

학습자는 연결(Connection)을 끊임없이 강요하는 HTTP의 폭력을 벗어나, 중앙의 중개자(Broker)를 두고 게시/구독(Publish/Subscribe) 토폴로지로 서로의 존재조차 모른 채 데이터를 주고받는 MQTT 아키텍처를 뜯어봅니다. 나아가 패킷 헤더를 고작 2바이트로 다이어트한 MQTT의 물리적 경량성, 연결이 툭툭 끊어지는 사막 한가운데서도 데이터 배달을 보장하는 QoS(Quality of Service) 레벨 역학, 그리고 유선망(TCP)마저 버리고 무선망(UDP) 위에서 돌아가는 초경량 **CoAP(Constrained Application Protocol)**의 기하학을 통달하여 전 세계 스케일의 IoT 메시지 라우팅망을 설계하는 아키텍트 역량을 확보합니다.

2. Scope & Boundaries

In-Scope

• 메시징 토폴로지 (Messaging Topology): 클라이언트-서버(HTTP) 모델 vs Publish-Subscribe(Pub/Sub) 모델의 결합도(Coupling) 차이.
• MQTT 코어 역학 (MQTT Core): 브로커(Broker), 토픽(Topic) 계층 트리(ex: home/livingroom/temp), 2바이트 고정 헤더 프레이밍.
• 비동기 전달 보장망 (Delivery Guarantee): QoS Level 0(At most once), 1(At least once), 2(Exactly once), LWT(Last Will and Testament), Session State.
• 제약 환경 프로토콜 (Constrained Protocols): UDP 기반의 CoAP(Constrained Application Protocol), 관찰(Observe) 패턴.

Out-of-Scope

• 거대 엔터프라이즈 메시지 큐: Kafka 파티셔닝, RabbitMQ AMQP 라우팅 키(Routing Key) 분산 아키텍처 $\rightarrow$ 04-03-01. Message Brokers & Event Streams 영역.
• 실시간 웹 양방향 통신: 브라우저 기반의 WebSockets, WebRTC 영상 스트리밍 $\rightarrow$ 08-03-01. Web Protocols Physics 영역.

Boundaries

• MQTT vs. HTTP (08-03-01): HTTP(08-03-01)가 "클라이언트가 서버의 주소를 정확히 알고 전화를 걸어 텍스트 문서를 통째로 주고받는 무거운 동기화 서류 작업"이라면, MQTT는 "센서가 허공(Broker)에 '온도방'이라는 꼬리표만 붙여 데이터를 던지고 도망가면, 그 데이터가 필요한 수만 명의 구독자에게 브로커가 냅다 쏴주는 비동기 확성기 방송망"입니다.

3. Counterexample

• IoT 기기에 HTTP 떡칠 (HTTP Overhead Crash): 온도를 딱 '25'라는 2바이트로 보내려고 센서에 HTTP/REST API 클라이언트를 얹는 치명적인 코딩. 헤더만 수백 바이트(Host, User-Agent, Accept)가 붙고, 전송할 때마다 TCP 3-Way Handshake를 맺었다 끊었다 하며 오버헤드가 배보다 배꼽이 수십 배 커집니다. 수만 대의 센서가 동시에 HTTP GET/POST를 치는 순간 클라우드 웹서버의 스레드가 고갈되어(Connection Pool 터짐) 시스템 전체가 아포칼립스를 맞이합니다.
• QoS 2의 맹신과 배터리 폭사 (QoS 2 Battery Drain): "우리 센서 데이터는 소중하니까 절대로 중복이나 누락 없이 한 번만 보내는 QoS 2를 써야지!"라며 배터리 노드에 최고 등급 전송을 거는 무식함. QoS 2는 데이터를 한 번 보내고 끝나는 게 아니라 PUBLISH -> PUBREC -> PUBREL -> PUBCOMP라는 미친 듯한 4단계 핑퐁 핸드셰이크를 강요합니다. 무선 송수신을 4번이나 해야 하므로 배터리가 살살 녹아내립니다. 온도 센서처럼 1초 뒤에 또 보낼 데이터는 어차피 누락돼도 상관없는 QoS 0(쏘고 버림)으로 던져버리는 타협이 절대 헌법입니다.

4. Prerequisites

• TCP/IP와 UDP 역학 (Basic): 연결성 지향(TCP)과 비연결성(UDP) 소켓 통신의 기본 개념을 알아야 MQTT(TCP 기반)와 CoAP(UDP 기반)의 한계를 이해할 수 있습니다. (08-02-01 TCP & UDP)
• 비동기 이벤트 루프 (Recommended): 내가 데이터를 달라고 기다리는(동기) 대신, 데이터가 오면 콜백 함수가 깨어나는(비동기) 철학을 체득해야 Pub/Sub 통신망을 장악할 수 있습니다. (01-04-02 Event Loop)

5. Learning Map

6. Learning Topics

Basic

Core Topic 01: 공간과 시간의 멱살 풀기, Pub/Sub 토폴로지 (Pub/Sub Topology)

• Why to Learn: 스마트폰(A)이 센서(B)의 IP 주소를 하드코딩해서 직접 찔러보는 연결 모델(HTTP)은, 센서가 1만 개로 늘어나고 배터리를 끄고 자는 순간 서버 아키텍처가 붕괴해 버리므로 이를 타파하기 위함입니다.
• What to Learn:
  • Concepts: 게시자(Publisher), 구독자(Subscriber), 메시지 브로커(Message Broker).
  • Skills: 토픽 트리(Topic Tree) 설계, 디커플링(Decoupling, 공간적/시간적/동기화 단절).
  • Tools: MQTTX, Mosquitto 브로커 테스트.
  • Trade-offs: 단말끼리 직접 붙는(P2P) 구조를 버리고 중앙의 브로커(Broker)를 통하면 프로그래밍은 미친 듯이 자유로워지고 디커플링(분리) 효과가 극에 달하지만, 그 거대한 브로커 서버(Mosquitto, EMQX)가 죽는 순간 전 세계의 모든 센서와 스마트폰이 눈 뜬 장님이 되어버리는 단일 장애점(SPOF) 리스크 폭발.
• How to Learn:
  • 1단계: 온도 센서(Publisher)는 스마트폰이 세상에 존재하는지 알 필요 없이 오직 브로커에게 home/sensor/temp라는 토픽(주제)으로 값을 냅다 던져버리는 공간적 분리(Spatial Decoupling)를 해부합니다.
  • 2단계: 스마트폰(Subscriber)이 잠을 자고 있어도 브로커가 메시지를 쥐고 있다가, 스마트폰이 깨어나 브로커에 접속하는 순간 밀린 데이터를 폭포수처럼 쏟아주는 시간적 분리(Temporal Decoupling) 역학을 뜯어봅니다.
• Implement: 파이썬 딕셔너리로 가짜 Broker 객체 구현. Publisher 스레드가 broker.publish('room/temp', 25)를 쏘면, Broker가 등록된 Subscriber 리스트를 뒤져 콜백(callback(msg))을 터트려주는 이벤트 루프 시뮬레이터 작성.

Recommended

Core Topic 02: 2바이트 다이어트 혁명, MQTT 패킷 프레이밍 (MQTT Framing)

• Why to Learn: 1바이트짜리 데이터("1")를 보내는데 500바이트짜리 HTTP 껍데기를 씌우는 쓰레기 같은 전송 효율을 부수고, 우주에서 가장 가벼운 패킷으로 배터리 수명을 10배 뻥튀기하기 위해서입니다.
• What to Learn:
  • Concepts: MQTT 고정 헤더(Fixed Header, 2 Bytes), 가변 헤더(Variable Header), 페이로드(Payload).
  • Skills: Keep-Alive PINGREQ/PINGRESP, 토픽 필터 및 와일드카드(+, #).
  • Tools: Wireshark MQTT 패킷 덤프.
  • Trade-offs: 통신 프레임을 2바이트(메시지 타입 1B + 길이 1B)까지 깎아버리면 오버헤드는 예술이 되지만, HTTP처럼 데이터가 JSON인지 XML인지(Content-Type) 친절하게 알려주는 껍데기가 없으므로 어플리케이션 개발자가 바이트 덩어리(Payload)를 직접 까보고 뇌피셜로 디코딩해야 하는 원시적 불편함.
• How to Learn:
  • 1단계: Wireshark를 켜고 MQTT 패킷을 잡았을 때, HTTP 패킷이 텍스트로 POST / HTTP/1.1... 주절거리는 것과 달리, MQTT는 맨 앞 1바이트 상위 4비트에 '메시지 타입(PUBLISH=3)'을 쑤셔 넣고 하위 4비트에 '플래그', 그다음 바이트에 '남은 길이'만 적어버리는 극단적 바이너리 압축 프레이밍을 해부합니다.
  • 2단계: 스마트폰이 home/+/temp (방 1개 통과 와일드카드)나 home/# (하위 모든 토픽 싹쓸이 와일드카드)를 구독(Subscribe) 요청할 때, 브로커가 문자열 정규식 트리 검색을 통해 수만 개의 센서 데이터를 라우팅 필터링하는 토픽 트리를 뜯어봅니다.
• Implement: 텍스트 명령(ex: "PUB room 25")을 받았을 때, 0x30(Publish 타입) 바이트와 페이로드 길이 바이트를 struct.pack()을 이용해 실제 바이너리 바이트 배열 b'\x30\x07\x00\x04room\x19' 로 인코딩하고, 이를 HTTP 헤더 문자열(수백 바이트) 크기와 비교(Size=9 vs 150) 출력하여 극강의 바이트 이코노미를 증명.

Practical

Core Topic 03: 사막의 배달 보증과 유언장, QoS와 LWT (QoS & Last Will)

• Why to Learn: 터널을 지나는 자동차처럼 무선 인터넷이 툭하면 끊어지는 환경에서, 서버(Broker)가 어떻게든 기어코 메시지를 센서에게 쑤셔 넣는 재전송(Retransmission) 메커니즘의 수학적 핑퐁을 장악하기 위함입니다.
• What to Learn:
  • Concepts: QoS(Quality of Service) 0, 1, 2, 클린 세션(Clean Session), LWT(Last Will and Testament).
  • Skills: PUBACK (QoS 1), 4-way 핸드셰이크 (QoS 2), 연결 유실 감지(Keep-Alive Timeout).
  • Tools: 브로커 세션 지속성(Persistent Session) 설정.
  • Trade-offs: QoS 1(최소 한 번)을 쓰면 데이터를 무조건 보장받지만 패킷이 중복(Duplicate)되어 에어컨이 두 번 켜질 리스크가 존재하고, QoS 2(정확히 한 번)를 쓰면 완벽하지만 핑퐁을 4번 하느라 레이턴시와 배터리가 박살 나는 트릴레마.
• How to Learn:
  • 1단계: QoS 1: 퍼블리셔가 브로커에게 데이터를 쐈는데 정해진 시간 내에 PUBACK 확인증이 안 날아오면, 무조건 같은 데이터를 재전송(DUP 비트=1)하여 '적어도 한 번'은 도달하게 만드는 물리를 해부합니다.
  • 2단계: 유언장(LWT): 센서가 브로커에 처음 붙을 때 "나중에 나 갑자기 통신 두절(Timeout)로 죽으면, home/sensor/status 토픽으로 'OFFLINE'이라고 네가 대신 뿌려줘"라고 유서(Last Will)를 맡겨두어, 배터리가 폭발해 센서가 즉사해도 서버와 스마트폰이 즉각 그 죽음을 알아채는 기적의 아키텍처를 뜯어봅니다.
• Implement: 파이썬 클라이언트 루프에서 무작위로 $30\%$ 확률의 Packet_Loss를 발생시킴. QoS_0 모드는 그냥 Drop 되어버리지만, QoS_1 루프에서는 Wait_ACK_Timeout이 걸릴 때마다 Resend() 큐가 폭발적으로 작동하여 결코 메시지를 잃어버리지 않는(단, 수신 측에 중복 메시지 수신 로그 발생) 핑퐁 덤프.

Advanced

Core Topic 04: TCP의 무게를 버린 비연결 생존술, CoAP (UDP for Constrained)

• Why to Learn: MQTT조차 기저(Underlay)에 무거운 TCP 소켓을 깔고 3-Way Handshake(SYN-ACK)를 해야 하므로, 메모리 10KB짜리 초소형 칩과 협대역망(NB-IoT)에서는 이마저도 사치일 때, 가벼운 UDP 소켓 위에 얹어 쓰는 극한의 RESTful 프로토콜을 쥐기 위해서입니다.
• What to Learn:
  • Concepts: CoAP(Constrained Application Protocol), UDP 기반 메시징.
  • Skills: Confirmable(CON) / Non-confirmable(NON) 메시지, Observe(관찰) 패턴, CoAP-HTTP 프록시 변환.
  • Tools: Wireshark CoAP 파서, libcoap.
  • Trade-offs: TCP의 무거운 연결 유지 부담을 완전히 날려버린 UDP 위에서 돌아가므로 배터리가 전혀 닳지 않지만(에너지 극강), 중간에 패킷이 꼬이거나 손실됐을 때 순서를 맞추고 재전송하는 로직을 OS(TCP)가 아닌 CoAP 어플리케이션 계층이 직접 다 구현해서 막아내야 하는 복잡성 지불.
• How to Learn:
  • 1단계: 무거운 MQTT 브로커 토폴로지를 버리고, 다시 HTTP처럼 GET coap://sensor/temp 주소를 찌르는(Request/Response) 직관적인 REST API 구조를 취하되, 패킷을 4바이트 바이너리 헤더로 압축해 버리는 극강의 경량화 물리를 해부합니다.
  • 2단계: HTTP라면 온도 변화를 묻기 위해 클라이언트가 1초마다 무한 GET(폴링)을 때려야 하지만, CoAP는 패킷 헤더에 Observe 옵션 딱 하나를 박아서 보내면, 센서가 "어, 온도 바뀌면 내가 알아서 응답(Response) 또 쏴줄게"라며 비동기 푸시(Push) 스트림으로 변신하는 흑마법을 뜯어봅니다.
• Implement: UDP 데이터그램 소켓(socket.SOCK_DGRAM)을 쓰는 로우 레벨 파이썬 스크립트 작성. CON(Confirmable) 비트를 세팅한 4바이트 헥사(Hex) 바이너리 프레임을 쐈을 때, 서버가 ACK 패킷을 돌려주지 않으면 스스로 timeout을 지수 함수적(Exponential Backoff)으로 2배씩 늘려가며 재전송을 시도하는 CoAP 신뢰성 방어 로직 모사.

7. Terminology

8. References

Primary

• [P1] CS2023 - AR/Embedded Systems (Network protocols) — Core requirements.
• [P2] SWEBOK v4.0 - Computing Foundations / Data Communications — Structural standards.

Secondary

• [MQTT Essentials] HiveMQ — Complete protocol guide.
• [IoT Fundamentals] Hanes et al. — Chapters on CoAP and lightweight messaging.

Industry

• [OASIS: MQTT Version 5.0 Standard Specification] — Official full spec.
• [IETF RFC 7252: The Constrained Application Protocol (CoAP)] — Official RFC.

9. Final Checklist

Primary

• 'HTTP' 프로토콜 헤더(수백 바이트)와 'MQTT' 고정 헤더(2바이트)를 비교하여, 왜 MQTT가 임베디드 통신 성능을 물리적으로 향상시키는지 설명 가능한가? (P1)
• '발행/구독' 모델이 '요청/응답' 모델보다 수천 개의 센서를 관리할 때 서버 하드웨어 자원(Memory/Connection)을 왜 더 아낄 수 있는지 입증할 수 있는 가? (P1)

Secondary

• 'QoS Level 1' 설정 시, 통신 장애가 발생했다가 복구되면 동일한 데이터가 왜 두 번 배달될 수 있는지 물리적 확인 절차 관점에서 소통 가능한가?
• 인터넷이 불능인 상황에서 로컬 게이트웨이가 기기 상호 간의 통신을 어떻게 물리적으로 중재(Local Broker)하여 시스템을 유지하는지 분석 가능한가?

Industry

• 스마트 농장의 지하 매설 센서 성능 설계 시, 왜 TCP 기반 MQTT보다 UDP 기반 CoAP가 패킷 재전송 물리 관점에서 유리한지 제안할 수 있는 가? (SFIA)
• 'Last Will and Testament (LWT)' 기능을 사용하여 특정 기기의 물리적 전원 차단을 서버가 어떻게 즉각 인지하고 대체 로직을 가동하는지 시퀀스를 기술할 수 있는 가?