MQTT는 장치, 애플리케이션, 센서, 게이트웨이, 클라우드 플랫폼, 제어 시스템 사이의 효율적인 통신을 위해 설계된 경량 메시징 프로토콜입니다. 대역폭, 전력 또는 네트워크 안정성이 제한될 수 있는 IoT 네트워크, 텔레메트리 시스템, 스마트 빌딩, 산업 모니터링, 차량 플랫폼, 에너지 시스템, 홈 자동화, 원격 장비 관리, 모바일 애플리케이션에서 널리 사용됩니다.

이 프로토콜은 발행/구독 모델을 기반으로 합니다. 한 장치가 다른 장치로 데이터를 직접 보내는 대신, 메시지는 브로커로 전송됩니다. 브로커는 해당 토픽을 구독한 클라이언트에게 메시지를 배포합니다. 이 구조는 통신을 유연하고 확장 가능하게 만들며, 많은 장치가 서로의 네트워크 주소를 알 필요가 없는 시스템에 적합합니다.

장치 메시징을 이해하는 다른 방식

전통적인 클라이언트-서버 통신은 보통 직접 요청과 응답처럼 동작합니다. 클라이언트가 서버에 정보를 요청하면 서버가 응답합니다. MQTT는 다른 방식을 따릅니다. 한 장치는 누가 받을지 몰라도 메시지를 게시할 수 있고, 다른 장치는 누가 게시할지 몰라도 토픽을 구독할 수 있습니다.

이러한 분리는 대규모 분산 시스템에서 유용합니다. 온도 센서는 어떤 대시보드, 데이터베이스, 모바일 앱 또는 자동화 규칙이 데이터를 사용할지 알 필요가 없습니다. 정의된 토픽에 게시하기만 하면 되고, 배포는 브로커가 처리합니다.

결과적으로 장치 간의 강한 결합을 줄이는 통신 패턴이 만들어집니다. 시스템은 센서를 변경하지 않고 새 구독자를 추가할 수 있습니다. 또한 모든 애플리케이션을 다시 작성하지 않고 새 게시자를 추가할 수 있습니다. 이것이 MQTT가 IoT와 텔레메트리 설계에서 널리 쓰이는 이유 중 하나입니다.

메시지 허브로서의 브로커

브로커는 아키텍처의 중심 구성 요소입니다. 클라이언트 연결을 수락하고, 필요한 경우 클라이언트를 인증하며, 게시된 메시지를 받고, 토픽과 구독을 매칭한 뒤 올바른 구독자에게 메시지를 전달합니다.

브로커는 클라우드 플랫폼, 개인 서버, 엣지 게이트웨이, 산업용 컴퓨터, 임베디드 장치 또는 관리형 메시징 서비스에서 실행될 수 있습니다. 작은 배포에서는 하나의 브로커가 모든 트래픽을 처리할 수 있습니다. 큰 배포에서는 여러 브로커가 클러스터링, 브리지, 로드 밸런싱 또는 지역 분산으로 구성될 수 있습니다.

브로커는 세션 상태, 보존 메시지, 접근 제어, QoS 전달, keepalive 시간 초과, 연결 수 제한, 토픽 권한, 메시지 지속성 같은 많은 운영 동작도 제어합니다. 따라서 브로커 설계는 신뢰성, 확장성, 보안에 직접적인 영향을 줍니다.

연결 수명 주기

클라이언트가 세션을 설정함

클라이언트는 먼저 브로커에 네트워크 연결을 엽니다. MQTT는 일반적으로 TCP 위에서 동작하며, 보안 배포에서는 TLS 암호화를 자주 사용합니다. 전송 연결이 설정되면 클라이언트는 클라이언트 ID, 인증 데이터, keepalive 값, 세션 동작, 선택적인 유언 메시지 설정 등이 포함된 CONNECT 패킷을 보냅니다.

브로커는 연결 요청을 확인하고 CONNACK 패킷으로 응답합니다. 연결이 수락되면 클라이언트는 게시, 구독, 구독 해제, 메시지 수신을 시작할 수 있습니다. 연결이 거부되면 브로커는 프로토콜 버전과 설정에 따라 이유를 제공합니다.

하트비트가 링크를 유지함

keepalive 메커니즘은 양쪽이 끊어진 연결을 감지하는 데 도움을 줍니다. 합의된 시간 동안 데이터가 교환되지 않으면 클라이언트는 PINGREQ 패킷을 보내고 브로커는 PINGRESP로 응답합니다.

이는 중요합니다. IoT 장치는 불안정한 네트워크, 모바일 링크, Wi-Fi, 셀룰러 연결, 위성 링크 또는 원격 WAN 경로에서 동작할 수 있습니다. 네트워크는 연결을 정상적으로 닫지 않고 조용히 실패할 수 있습니다. keepalive는 이런 상태를 감지하는 데 도움을 줍니다.

연결 해제와 재연결

클라이언트는 DISCONNECT 패킷을 보내 정상적으로 연결을 해제할 수 있습니다. 또한 전원 손실, 네트워크 장애, 펌웨어 충돌 또는 신호 손실 때문에 갑자기 사라질 수도 있습니다. 그러면 브로커는 해당 클라이언트에 설정된 세션 규칙과 유언 메시지 규칙을 적용합니다.

실제 배포에서는 재연결 동작이 중요합니다. 장치는 네트워크 중단을 안정적으로 처리하고, 과도한 재연결 폭주를 피하며, 필요한 세션 정책에 따라 통신을 재개해야 합니다.

토픽 이름과 메시지 라우팅

토픽은 메시지를 분류하는 텍스트 기반 경로입니다. 토픽은 building/floor1/room102/temperature 또는 factory/line3/motor7/status처럼 계층 구조처럼 보일 수 있습니다. 게시자는 토픽으로 메시지를 보내고, 구독자는 자신이 구독한 토픽에서 메시지를 받습니다.

좋은 토픽 설계는 성공적인 배포에서 가장 중요한 부분 중 하나입니다. 토픽 이름은 예측 가능하고 읽기 쉬우며 실제 시스템 구조와 일치해야 합니다. 잘못된 토픽 설계는 필터링, 권한, 모니터링, 장기 유지보수를 어렵게 만듭니다.

구독자는 정확한 토픽 또는 와일드카드 구독을 사용할 수 있습니다. 단일 레벨 와일드카드는 하나의 토픽 레벨을 매칭하고, 다중 레벨 와일드카드는 여러 레벨을 매칭할 수 있습니다. 와일드카드는 많은 장치의 메시지를 받아야 하는 대시보드, 분석 플랫폼, 모니터링 도구, 관리 애플리케이션에 유용합니다.

게시와 구독 흐름

데이터 게시

클라이언트가 데이터를 게시할 때 브로커에 PUBLISH 패킷을 보냅니다. 이 패킷에는 토픽 이름, 페이로드, 서비스 품질 수준, 보존 플래그, 선택한 QoS 수준에서 필요한 경우 패킷 식별자가 포함됩니다.

페이로드에는 다양한 데이터 형식이 들어갈 수 있습니다. 일반 텍스트, JSON, 바이너리 데이터, 센서 값, 상태 메시지, 명령, 알람, 텔레메트리 기록 또는 인코딩된 애플리케이션 데이터가 될 수 있습니다. MQTT 자체는 페이로드의 의미를 정의하지 않습니다. 애플리케이션이 구조와 해석 방식을 결정합니다.

구독 수신

클라이언트는 하나 이상의 토픽 필터가 포함된 SUBSCRIBE 패킷을 보내 구독합니다. 브로커는 SUBACK으로 응답하고, 요청되고 허가된 QoS 수준에 따라 해당 클라이언트에 매칭되는 메시지를 전달하기 시작합니다.

구독자는 대시보드, 데이터베이스, 자동화 엔진, 클라우드 서비스, 모바일 앱, 장치 컨트롤러 또는 기타 현장 장치일 수 있습니다. 하나의 게시 메시지가 동시에 많은 구독자에게 전달될 수 있습니다.

관심 제거

클라이언트가 특정 메시지를 더 이상 원하지 않으면 UNSUBSCRIBE 패킷을 보냅니다. 브로커는 요청을 확인한 뒤 매칭되는 토픽 메시지의 전달을 중단합니다.

이를 통해 애플리케이션은 데이터 관심 범위를 동적으로 바꿀 수 있습니다. 예를 들어 사용자가 한 건물을 보고 있을 때 대시보드가 그 건물을 구독하고, 다른 사이트로 이동하면 구독을 해제할 수 있습니다.

발행/구독 모델은 데이터 생산자와 소비자가 독립적으로 발전하도록 하며, 브로커는 라우팅, 세션 동작, 전달 제어를 관리합니다.

서비스 품질 수준

QoS 0: 최대 한 번

QoS 0은 가장 단순한 전달 수준입니다. 메시지는 한 번만 전송되며, MQTT 계층에서 수신자의 확인 응답이 없습니다. 메시지가 손실되면 프로토콜은 재전송하지 않습니다.

이 수준은 가끔 업데이트를 잃어도 괜찮은 빈번한 텔레메트리에 유용합니다. 예를 들어 몇 초마다 데이터를 보내는 온도 센서는 모든 측정값이 반드시 도착할 필요가 없을 수 있습니다.

QoS 1: 최소 한 번

QoS 1은 확인 응답을 요구합니다. 송신자는 확인을 받지 못하면 메시지를 다시 전송합니다. 전달 신뢰성은 높아지지만 수신자는 중복 메시지를 받을 수 있습니다.

QoS 1을 사용하는 애플리케이션은 중복 처리를 준비해야 합니다. 이는 알람, 상태 변화, 명령, 중요한 텔레메트리처럼 중복 회피보다 전달이 더 중요한 경우에 흔합니다.

QoS 2: 정확히 한 번

QoS 2는 더 복잡한 핸드셰이크를 사용하여 프로토콜 수준에서 메시지가 정확히 한 번 전달되도록 합니다. 가장 강한 전달 보장을 제공하지만 오버헤드와 지연이 증가합니다.

중복 처리가 해로울 때 이 수준을 사용할 수 있습니다. 그러나 많은 실제 배포에서는 성능과 신뢰성의 균형이 더 좋은 QoS 0 또는 QoS 1을 사용합니다.

보존 메시지와 마지막 알려진 상태

보존 메시지는 브로커가 특정 토픽의 최신 메시지로 저장하는 메시지입니다. 새 구독자가 해당 토픽을 구독하면, 브로커는 즉시 보존 메시지를 보내 구독자가 가장 최근에 알려진 상태를 볼 수 있게 합니다.

이는 장치 온라인 상태, 스위치 상태, 센서 값, 설정 버전, 알람 상태 또는 현재 운전 모드 같은 상태 정보에 유용합니다. 보존 메시지가 없으면 새 구독자는 현재 상태를 알기 위해 다음 업데이트를 기다려야 할 수 있습니다.

보존 메시지는 신중하게 사용해야 합니다. 상태에는 유용하지만 이벤트 스트림에는 항상 적절하지 않습니다. 보존된 “문 열림” 이벤트는 더 이상 사실이 아닐 때 새 구독자를 혼란스럽게 할 수 있습니다. 상태 토픽과 이벤트 토픽은 별도로 설계해야 합니다.

세션 동작과 오프라인 전달

MQTT는 클라이언트가 연결을 끊고 나중에 다시 연결할 때 어떤 일이 발생할지 결정하는 세션 동작을 지원합니다. 프로토콜 버전과 설정에 따라 브로커는 클라이언트의 구독, 대기 메시지, 세션 상태를 저장할 수 있습니다.

이는 절전 상태로 들어가거나, 네트워크 사이를 이동하거나, 일시적으로 연결을 잃는 장치에 유용합니다. 장치가 다시 연결되면 세션 정책과 QoS 규칙이 허용하는 경우 오프라인 동안 대기 중이던 메시지를 계속 받을 수 있습니다.

세션 지속성은 장치 역할에 맞아야 합니다. 배터리 구동 센서는 모든 명령을 영구히 대기시킬 필요가 없을 수 있습니다. 원격 컨트롤러는 대기 중인 설정 업데이트가 필요할 수 있습니다. 오프라인 큐가 너무 많으면 브로커 자원을 소비하고, 너무 적으면 명령 누락이 발생할 수 있습니다.

예상치 못한 장애를 위한 유언 메시지

유언 메시지는 클라이언트가 예상치 못하게 연결이 끊겼을 때 브로커가 게시해야 할 메시지를 클라이언트가 정의할 수 있게 합니다. 이를 통해 다른 시스템은 장치 장애, 네트워크 손실 또는 비정상 종료를 감지할 수 있습니다.

예를 들어 장치는 device/123/status 같은 상태 토픽에 유언 메시지를 설정할 수 있습니다. 장치가 정상적인 연결 해제를 보내지 않고 전원을 잃으면 브로커는 설정된 오프라인 메시지를 게시합니다.

이 기능은 모니터링 대시보드, 장치 상태 시스템, 산업 텔레메트리, 게이트웨이 감시, 원격 자산 관리에서 널리 사용됩니다. 비정상 연결 해제를 시스템의 다른 부분에 알리는 간단한 방법입니다.

보안과 접근 제어

인증

브로커는 접근을 허용하기 전에 클라이언트 신원을 확인해야 합니다. 인증은 사용자 이름과 비밀번호, 클라이언트 인증서, 토큰, API 자격 증명 또는 외부 신원 시스템 연동을 사용할 수 있습니다.

약한 인증은 권한 없는 장치가 거짓 데이터를 게시하거나, 민감한 토픽을 구독하거나, 메시징 환경을 방해하도록 만들 수 있습니다.

권한 부여

신원이 확인된 뒤 브로커는 클라이언트가 어떤 토픽에 게시할 수 있고 어떤 토픽을 구독할 수 있는지 결정해야 합니다. 센서는 관련 없는 장치에 명령을 게시할 수 없어야 합니다. 한 테넌트의 애플리케이션은 다른 테넌트의 데이터를 받아서는 안 됩니다.

토픽 수준 권한은 다중 장치, 다중 사이트, 다중 테넌트 배포에서 필수적입니다.

암호화

TLS 암호화는 클라이언트와 브로커 사이를 이동하는 데이터를 보호합니다. 메시지가 공용 네트워크, 셀룰러 네트워크, 클라우드 연결 또는 신뢰할 수 없는 인프라를 지날 때 중요합니다.

암호화는 인증서 관리, 안전한 키 저장, 신중한 클라이언트 프로비저닝과 함께 사용해야 합니다. 자격 증명이 펌웨어나 설정 파일에 노출되어 있다면 안전한 전송 계층만으로는 충분하지 않습니다.

배포 패턴

장치에서 클라우드로

많은 IoT 시스템에서 센서와 게이트웨이는 데이터를 클라우드 브로커에 게시합니다. 클라우드 애플리케이션은 이후 데이터를 저장, 시각화, 분석하고 조치를 실행합니다. 이 모델은 스마트 빌딩, 에너지 관리, 차량 모니터링, 원격 장비 플랫폼에서 흔합니다.

주요 설계 관심사는 보안, 네트워크 복원력, 장치 신원, 메시지 양, 클라우드 측 확장성입니다.

엣지 게이트웨이 집계

엣지 게이트웨이는 로컬 장치에서 데이터를 수집하고 요약 또는 필터링된 데이터를 중앙 브로커로 게시할 수 있습니다. 또한 명령 토픽을 구독하고 로컬 장비에 지시를 전달할 수 있습니다.

이는 대역폭을 줄이고, 로컬 제어를 개선하며, 클라우드 연결이 불가능할 때도 사이트가 일부 기능을 계속 수행할 수 있게 합니다.

사이트 시스템용 로컬 브로커

일부 배포에서는 공장, 건물, 연구실, 캠퍼스 또는 제어실 내부에 로컬 브로커를 사용합니다. 장치와 애플리케이션은 낮은 지연으로 로컬에서 데이터를 교환하고 외부 네트워크 의존도를 줄입니다.

로컬 브로커는 나중에 선택된 데이터를 클라우드 또는 기업 플랫폼으로 브리지할 수 있습니다. 이를 통해 시스템 설계자는 데이터 흐름과 네트워크 의존성을 더 잘 제어할 수 있습니다.

연결 시스템에서의 응용

산업 모니터링

공장과 유틸리티 현장은 MQTT를 사용해 장비 상태, 센서 데이터, 알람 메시지, 에너지 값, 온도 측정값, 진동 데이터, 생산 지표를 수집합니다. 이 프로토콜은 많은 장치가 감독 플랫폼으로 작은 메시지를 보내는 환경에 적합합니다.

산업 배포에서는 네트워크 분할, 브로커 이중화, QoS 선택, 보존 상태, 안전한 장치 프로비저닝을 고려해야 합니다.

스마트 빌딩

빌딩 시스템은 이 프로토콜을 사용해 조명, HVAC, 출입 통제, 재실 센서, 계량기, 엘리베이터, 룸 패널, 대시보드를 연결할 수 있습니다. 토픽 구조는 건물, 층, 방, 장치 계층을 반영할 수 있습니다.

이렇게 하면 데이터를 더 쉽게 구성하고 자동화 규칙이 관련 이벤트나 상태만 구독하도록 도울 수 있습니다.

에너지와 계량

에너지 플랫폼은 MQTT를 사용해 계량기 판독값, 인버터 데이터, 배터리 상태, 부하 정보, 전력망 관련 텔레메트리를 수집할 수 있습니다. 많은 장치가 작은 값을 주기적으로 보고할 때 경량 메시징이 유용합니다.

에너지 시스템은 과금, 제어 또는 안전에 영향을 줄 수 있으므로 인증과 메시지 무결성을 신중하게 처리해야 합니다.

커넥티드 차량과 모빌리티

차량 플랫폼, 충전소, 차량 관리 시스템, 모빌리티 서비스는 텔레메트리, 위치 업데이트, 진단, 경보, 원격 제어 기능에 이 프로토콜을 사용할 수 있습니다.

모바일 네트워크는 불안정할 수 있으므로 세션 처리, 재연결 로직, 효율적인 페이로드 설계가 중요합니다.

소비자 및 홈 자동화

홈 자동화 시스템은 MQTT를 사용해 센서, 스위치, 조명, 온도 조절기, 카메라, 허브, 자동화 규칙을 연결합니다. 발행/구독 모델은 하나의 센서 이벤트가 여러 동작을 쉽게 트리거하게 합니다.

가정 배포에서는 혼란과 무단 접근을 피하기 위해 간단한 토픽 이름과 안전한 로컬 브로커 설정이 중요합니다.

성능과 확장성 고려 사항

메시지 크기는 합리적으로 유지해야 합니다. MQTT는 작은 메시지에 효율적이지만 매우 큰 파일이나 무거운 미디어 스트림에는 적합하지 않습니다. 큰 페이로드는 브로커 메모리 사용, 네트워크 혼잡, 처리 지연을 증가시킬 수 있습니다.

토픽 설계는 성능에 영향을 줍니다. 넓은 와일드카드 구독을 과도하게 사용하면 많은 메시지를 매칭하고 많은 클라이언트에게 전달해야 하므로 브로커 부하가 커질 수 있습니다. 명확한 토픽 계층은 시스템이 더 예측 가능하게 확장되도록 돕습니다.

연결 수 역시 중요한 요소입니다. 수천 또는 수백만 클라이언트를 처리하는 브로커는 keepalive 트래픽, 인증, 세션 상태, 보존 메시지, 대기 메시지, 네트워크 제한을 처리해야 합니다. 확장에는 클러스터링, 로드 밸런싱, 엣지 집계, 토픽 분할이 필요할 수 있습니다.

QoS 수준도 성능에 영향을 줍니다. QoS 2는 더 강한 전달 의미를 제공하지만 패킷 교환이 많아집니다. 대량 텔레메트리에서는 QoS 0 또는 QoS 1에 애플리케이션 수준 로직을 결합하는 방식이 더 실용적일 수 있습니다.

흔한 설계 실수

불명확한 토픽 이름

무작위이거나 일관성 없는 토픽 이름은 권한, 대시보드, 경보, 분석을 관리하기 어렵게 만듭니다. 대규모 배포 전에는 토픽 계획을 먼저 만들어야 합니다.

이벤트에 보존 메시지 사용

보존 메시지는 현재 상태에 가장 적합합니다. 일회성 이벤트에 사용하면 새 구독자가 오래된 이벤트를 방금 발생한 것처럼 받을 수 있어 오해를 만들 수 있습니다.

중복 처리 없음

QoS 1은 중복 메시지를 전달할 수 있습니다. 중복 메시지가 문제를 일으킬 수 있다면 애플리케이션은 타임스탬프, 메시지 ID, 시퀀스 번호 또는 멱등 처리를 사용해야 합니다.

약한 자격 증명 관리

하드코딩된 공유 비밀번호, 재사용된 클라이언트 ID, 보호되지 않은 인증서는 심각한 보안 위험을 만들 수 있습니다. 각 장치는 관리 가능한 신원과 폐기 경로를 가져야 합니다.

브로커 장애 무시

브로커는 아키텍처의 중심입니다. 브로커가 실패하고 이중화나 복구 계획이 없다면 통신이 중단될 수 있습니다. 중요한 배포에서는 클러스터링, 백업 브로커, 브리지 설계 또는 로컬 폴백 동작을 고려해야 합니다.

MQTT는 토픽, 세션, QoS, 보존 상태, 보안, 브로커 용량을 따로 설정하는 것이 아니라 함께 설계할 때 잘 동작합니다.

유지보수와 모니터링

운영 팀은 브로커 CPU, 메모리, 연결 수, 메시지 속도, 보존 메시지 수, 구독 수, 대기 메시지, 인증 실패, 끊어진 연결, 네트워크 지연을 모니터링해야 합니다.

클라이언트 상태도 보여야 합니다. 반복적인 재연결, 만료된 세션, 중복 클라이언트 ID, 비정상적인 게시 속도, 예상치 못한 토픽 접근은 장치 장애나 보안 문제를 나타낼 수 있습니다.

설정 백업도 중요합니다. 브로커 설정, 접근 제어 목록, 인증서, 토픽 정책, 브리지 설정, 보존 상태 동작은 문서화되어야 하며 복구 가능해야 합니다.

자주 묻는 질문

MQTT는 WebSocket에서 동작할 수 있습니까?

예. 많은 브로커가 WebSocket 기반 MQTT을 지원하므로 브라우저 기반 애플리케이션과 웹 대시보드가 웹 친화적인 전송 경로를 통해 통신할 수 있습니다.

대용량 비디오나 파일 콘텐츠 전송에 적합합니까?

일반적으로 기본 방법으로는 적합하지 않습니다. MQTT는 작은 메시지, 텔레메트리, 이벤트, 명령, 상태 업데이트에 더 적합합니다. 큰 파일은 보통 다른 프로토콜로 전송하고, 메시지는 파일 참조를 전달합니다.

두 클라이언트가 같은 클라이언트 ID를 사용하면 어떻게 됩니까?

많은 브로커는 새 클라이언트가 같은 ID로 연결되면 기존 클라이언트를 끊습니다. 고유한 클라이언트 ID는 안정적인 세션 동작에 중요합니다.

하나의 브로커가 다른 브로커에 연결될 수 있습니까?

예. 브로커 기능에 따라 브로커 브리징 또는 클러스터링을 사용하여 사이트, 지역, 엣지 게이트웨이, 클라우드 플랫폼 사이에서 선택된 토픽을 교환할 수 있습니다.

토픽 이름은 어떻게 계획해야 합니까?

사이트, 시스템, 장치, 데이터 유형, 기능을 기준으로 일관된 계층을 사용합니다. 무작위 이름, 토픽 경로 안의 민감한 정보, 지나치게 넓은 와일드카드 의존은 피해야 합니다.