네트워크 가이드

MQTT 센서 노드 구성 흐름

MQTT는 여러 IoT 장치가 센서 값과 제어 명령을 주고받기 좋은 메시지 방식입니다. 장치가 한두 대일 때는 아무 토픽이나 써도 동작하지만, 장치가 늘어나면 토픽 구조, 상태 메시지, 재접속, 로그 기준이 운영 품질을 결정합니다.

MQTT 센서 노드 구성 흐름 이미지

기본 흐름

센서 노드는 보통 센서 → ESP 보드 → Wi-Fi → MQTT Broker → 대시보드 또는 자동화 서버 순서로 움직입니다. 온습도 값 하나를 보내는 장치라도 실제로는 부팅 상태, Wi-Fi 연결 상태, 마지막 측정 시각, 배터리 또는 전원 상태, 오류 횟수까지 같이 봐야 합니다.

[3편] 집 안 온습도, 감으로 보지 말고 숫자로 보자처럼 작은 장치에서 시작하더라도, 나중에 방마다 장치가 늘어나면 이름 규칙이 중요해집니다. 처음부터 room01, room02처럼 위치와 역할을 구분하면 대시보드와 로그를 읽기 쉬워집니다.

토픽 나누기

상태iothub/device/room01/status
센서 값iothub/device/room01/telemetry
제어 명령iothub/device/room01/command
설정iothub/device/room01/config

상태와 센서값을 같은 토픽에 섞으면 처음에는 편하지만 나중에 필터링이 어려워집니다. 상태 토픽에는 online, offline, firmware version, uptime 같은 값을 넣고, telemetry에는 온도·습도·전압처럼 시간에 따라 쌓이는 값을 넣는 편이 관리하기 쉽습니다.

데이터 형태

온도와 습도처럼 여러 값을 함께 보낼 때는 JSON 형태가 관리하기 쉽습니다. 예를 들어 장치 ID, 측정 시각, 온도, 습도, 배터리 상태를 함께 보낼 수 있습니다. 단, 너무 큰 JSON을 너무 자주 보내면 네트워크와 Broker 부하가 늘어나므로 필요한 값만 보냅니다.

실제 운영에서는 숫자만 보내는 것보다 단위와 기준을 명확히 하는 것이 중요합니다. 온도는 섭씨인지, 습도는 상대습도인지, 배터리는 전압인지 퍼센트인지 정해야 합니다. 이런 기준이 없으면 대시보드가 예쁘게 보여도 나중에 데이터를 비교하기 어렵습니다.

retain과 QoS 기준

retain은 새로 접속한 대시보드가 마지막 값을 즉시 볼 수 있게 해 줍니다. 실내 온습도나 장치 상태처럼 마지막 값이 의미 있는 데이터에는 유용합니다. 반대로 “문이 열렸다” 같은 이벤트성 메시지에 retain을 잘못 쓰면 새로 접속할 때 오래된 이벤트가 다시 보이는 문제가 생길 수 있습니다.

QoS는 메시지 전달 보장 수준입니다. 가정용 센서 노드에서는 QoS 0 또는 1이면 충분한 경우가 많습니다. 중요한 것은 QoS 숫자보다 네트워크가 끊겼을 때 장치가 어떻게 재접속하고, 실패한 전송을 로그로 남기는지입니다. 이 부분은 MQTT 장치에도 로컬 로그가 필요한 이유와 연결됩니다.

확인 도구

MQTT Explorer 같은 도구로 토픽과 메시지를 눈으로 확인하면 장치 문제인지 서버 문제인지 빠르게 나눌 수 있습니다. 장치가 publish를 했는지, Broker가 받았는지, 대시보드가 구독 중인지가 분리되어야 디버깅이 빨라집니다.

현장 운영 체크리스트

  • 장치 ID와 위치 이름을 사람이 읽을 수 있게 정합니다.
  • 상태, 센서값, 명령, 설정 토픽을 분리합니다.
  • 마지막 전송 시각과 uptime을 payload에 포함합니다.
  • Wi-Fi와 MQTT 재접속 실패 횟수를 로컬에 남깁니다.
  • 전송이 끊겼을 때 장치가 안전 상태를 유지하는지 확인합니다.
  • 펌웨어 변경이 잦은 장치라면 OTA 업데이트 전략을 함께 설계합니다.

예시 시나리오

거실 온습도 노드가 5분마다 값을 보내고, 에어컨 제어 장치가 명령 토픽을 구독한다고 가정해 봅니다. 온습도 노드는 telemetry에 현재 값을 보내고, status에는 online과 uptime을 보냅니다. 에어컨 제어 장치는 command를 구독하되, 명령을 실행한 뒤 result 토픽에 성공·실패를 다시 남기는 편이 좋습니다. 그래야 대시보드가 명령을 보냈다는 사실과 장치가 실제 실행했다는 사실을 구분할 수 있습니다.

장치가 오프라인일 때도 기준이 필요합니다. 마지막 전송 시각이 30분 이상 오래되면 대시보드에서 회색 처리하고, 2시간 이상 끊기면 알림을 보내는 식으로 운영 규칙을 정할 수 있습니다. 이런 규칙이 없으면 MQTT는 메시지를 잘 전달해도 현장 상태를 판단하기 어렵습니다.