1038. MQTT 퍼블리시 서브스크라이브 모드 - 사물인터넷 초경량 메시지 큐 텔레메트리 트랜스포트 브로커 Publish/Subscribe 토픽 라우팅 아키텍처 QoS 보장

핵심 인사이트: 집 온도를 스마트폰으로 보고 싶다. 옛날 웹 브라우저(HTTP) 방식이면, 폰이 1초마다 집 온도계한테 계속 질문(Request)해야 한다. "온도 몇 도야?" "20도." "지금은 몇 도야?" "20도." 쓸데없는 질문에 서버와 배터리가 다 터져 나간다. IBM이 빡쳐서 판을 뒤집었다. "야! 폰은 입 다물고 온도계한테 직접 말 걸지 마! 중간에 거대한 우체국(브로커 서버)을 하나 세워! 폰은 우체국에 '나 온도 관심 있음(구독)'이라고 예약만 해놔! 그럼 온도계가 온도가 변할 때만 우체국에 '지금 21도!' 하고 신문을 던지고(발행), 우체국이 그걸 예약한 폰들에게 알아서 배달(푸시)해주면 한 방에 해결되잖아!" 사물인터넷(IoT) 데이터 중계의 신, MQTT다.

Ⅰ. 기존 클라이언트-서버(HTTP) 모델의 한계

  • 462번 HTTP는 폰(Client)이 온도계(Server)에게 질문(Request)을 던져야만 대답(Response)을 해줍니다.
  • 방 안의 수백 개 센서 온도를 알고 싶으면, 폰이 1초마다 수백 번의 접속과 질문을 날려대야(Polling) 해서 회선 낭비와 배터리 소모(오버헤드)가 재앙 수준이었습니다.

Ⅱ. MQTT (Message Queuing Telemetry Transport)의 탄생 🌟

  • 개념: 제한된 대역폭(쓰레기 같은 통신망)과 불안정한 환경(배터리 쪼들리는 센서)에서, 가볍고 빠르게 사물 간(M2M, IoT) 센서 데이터를 주고받기 위해 IBM이 1999년에 만든 초경량 메시징 프로토콜입니다. (현재 ISO 표준)
  • HTTP 패킷 껍데기는 엄청 크고 무겁지만, MQTT의 헤더(껍데기)는 고작 2바이트로 깃털처럼 가벼워 저전력 통신망에 최고의 효율을 뽑습니다.

Ⅲ. 극강의 흑마법: Publish / Subscribe (발행-구독) 아키텍처 🌟 핵심 🌟

센서와 폰이 서로를 몰라도 통신이 되는 완벽한 '비동기 3자 분리' 아키텍처입니다.

1. 3대 핵심 등장인물

  1. Publisher (발행자): 데이터를 만드는 센서 (온도계). "나 온도 데이터 던진다!"
  2. Subscriber (구독자): 데이터를 보고 싶어 하는 폰 (나의 앱). "온도 데이터 들어오면 나한테 줘!"
  3. Broker (브로커 / 우체국 서버) 🌟: 중간에 서서 모든 메시지를 받아서 분류하고 나눠주는 핵심 중계 서버입니다. (센서와 폰은 서로의 IP 주소를 전혀 모른 채, 오직 브로커하고만 연결됩니다.)

2. 토픽 (Topic) 라우팅 - 카테고리 분배

  • 우체국(브로커)은 편지를 어떻게 분류할까요? 주소가 아니라 **'토픽(관심사)'**으로 분류합니다.
  • 동작:
    1. 폰(구독자)이 브로커에게 말합니다. "나 Home/LivingRoom/Temp (거실 온도) 토픽 구독할게!"
    2. 거실 온도계(발행자)가 온도를 재고 브로커에게 던집니다. "[토픽: Home/LivingRoom/Temp] 메시지: 24도!"
    3. 브로커는 이 토픽을 구독 중인 모든 폰들에게 동시에 카톡 푸시 알람을 쏘듯 24도라는 데이터를 확 뿌려버립니다.

Ⅳ. QOS (Quality of Service) 3단계 배달 보증 🌟 시험 단골 🌟

네트워크가 쓰레기 같을 때 메시지가 사라지는 걸 막기 위해, 배달 확인증(QoS) 레벨을 폰에서 조절할 수 있습니다.

  • QoS 0 (At most once, 최대 1번):
    • "보냈어! 가다 잃어버렸다고? 알빠노!" 한 번 툭 던지고 마는 가장 가볍고 무책임한 방식 (온도 데이터에 적합).
  • QoS 1 (At least once, 최소 1번):
    • 우체국이 "잘 받았음(ACK)" 도장을 찍어줄 때까지 온도계가 똑같은 데이터를 계속 끈질기게 다시 보냅니다. 메시지 분실은 절대 없지만, 우체국이 똑같은 온도를 중복해서 여러 번 받을 수 있습니다.
  • QoS 2 (Exactly once, 정확히 1번):
    • 무조건 딱 한 번만 완벽하게 도착하도록, 보내고-확인하고-지우고-완료하는 미친 4단계 확인 절차를 밟습니다. 통신은 제일 무겁지만, 돈과 직결된 과금 센서(가스 검침 결제)에서 절대 오류가 안 나게 할 때 씁니다.

📢 섹션 요약 비유: HTTP 방식이 **'엄마(폰)가 아들(온도계) 방에 1분마다 문 열고 들어가 "공부 다 했어?" 묻는 잔소리 통신'**이라면, **MQTT(발행-구독 모델)**는 중간에 **'거실 칠판(브로커 서버)'**을 하나 놔두는 기적의 독립 생활입니다. 엄마(구독자)는 칠판에 "아들 수학 점수 칸 관심 있음"이라고 적어둡니다(토픽 구독). 아들(발행자)은 엄마 방에 찾아갈 필요 없이, 수학 시험을 치고 오면 그냥 거실 칠판 수학 칸에 "100점"이라고 적어놓고 쿨하게 자기 방으로 갑니다(발행). 그럼 칠판 관리자(브로커)가 알아서 엄마 방 문에 "아들 100점 맞음!"이라고 카톡 알림을 쏴줍니다. 엄마와 아들이 얼굴 한 번 보지 않고(IP 독립성), 엄마가 아들 방문을 두드릴 필요도 없이(Polling 제로), 정보가 업데이트되는 즉시 칠판을 통해 자동으로 뿌려지는 가장 이상적인 짠돌이 스마트홈의 데이터 우체국 시스템입니다.