MQTT

발행/구독 모델은 MQTT의 근본적인 통신 패러다임이다. 이 모델에서는 메시지를 보내는 주체인 발행자와 메시지를 받는 주체인 구독자가 직접적으로 연결되지 않는다. 대신, 중앙의 MQTT 브로커가 모든 메시지의 중개자 역할을 한다. 발행자는 특정 토픽에 메시지를 게시하고, 구독자는 관심 있는 토픽을 브로커에 등록한다. 브로커는 수신한 메시지를 해당 토픽을 구독하고 있는 모든 클라이언트에게 전달하는 책임을 진다.

이 구조는 전통적인 클라이언트-서버 모델이나 점대점 통신과는 명확히 구분된다. 발행자는 구독자가 누구인지, 몇 명인지 알 필요가 없으며, 구독자 역시 메시지가 어디에서 왔는지 알지 못한 채 원하는 정보만을 받을 수 있다. 이러한 결합도의 감소는 시스템의 확장성과 유연성을 크게 향상시킨다. 새로운 구독자를 추가하거나 발행자를 변경하는 것이 기존 구성 요소에 영향을 미치지 않는다.

발행/구독 모델의 주요 이점은 다음과 같이 정리할 수 있다.

이 모델은 특히 사물인터넷 환경에 적합하다. 수많은 센서(발행자)가 데이터를 생성하고, 다양한 애플리케이션(구독자)이 그 데이터를 선택적으로 소비하는 구조를 자연스럽게 반영하기 때문이다. 예를 들어, 온도 센서는 "home/livingroom/temperature" 토픽에 데이터를 발행하면, 이 토픽을 구독한 스마트폰 앱, 데이터베이스 저장 서비스, 에어컨 제어 장치 등이 각자의 목적에 맞게 해당 데이터를 활용할 수 있다.

MQTT 아키텍처의 중심에는 브로커와 클라이언트라는 두 가지 핵심 구성 요소가 존재한다. 이 두 요소는 발행/구독 모델을 기반으로 메시지 흐름을 관리하며, 브로커는 중앙 허브 역할을, 클라이언트는 메시지를 생산하거나 소비하는 끝단 역할을 담당한다.

브로커는 모든 메시지 교환의 중심 서버이다. 브로커의 주요 임무는 클라이언트로부터 수신한 메시지를 적절한 구독자에게 전달하는 것이다. 브로커는 연결 관리, 인증 및 권한 부여, 토픽 기반 메시지 라우팅, 지정된 QoS 수준에 따른 메시지 전달 보장 등의 기능을 수행한다. 브로커는 수많은 클라이언트의 동시 연결을 처리하고, 오프라인 클라이언트를 위한 메시지 보관(이를 세션과 지속 세션으로 관리함)도 담당한다[3]. 브로커의 구현체에는 Mosquitto, EMQX, HiveMQ 등이 있다.

반면, 클라이언트는 MQTT 프로토콜을 사용하여 브로커에 연결하는 모든 장치 또는 애플리케이션을 의미한다. 클라이언트는 발행자(Publisher), 구독자(Subscriber), 또는 두 역할을 모두 수행할 수 있다. 발행자 클라이언트는 특정 토픽에 메시지를 생성하여 브로커로 보내고, 구독자 클라이언트는 관심 있는 토픽을 브로커에 등록(구독)하여 해당 토픽의 메시지를 수신한다. 클라이언트는 리소스가 제한된 임베디드 장치, 스마트폰 앱, 웹 애플리케이션, 서버 프로그램 등 매우 다양할 수 있다.

브로커와 클라이언트의 관계는 다음과 같은 표로 요약할 수 있다.

이 분리된 아키텍처는 시스템의 확장성과 유연성을 높인다. 클라이언트는 서로를 직접 알 필요 없이 오직 브로커와만 통신하면 되며, 브로커는 클라이언트 간의 결합도를 낮추고 효율적인 메시지 배포를 가능하게 한다.

토픽은 메시지가 전송되는 가상 채널 또는 주소 체계이다. 클라이언트는 특정 토픽을 구독하여 해당 주제의 메시지를 수신하거나, 특정 토픽으로 메시지를 발행한다. 토픽은 계층 구조를 가지며, 슬래시(/)로 구분된 문자열로 표현된다. 예를 들어, home/livingroom/temperature와 같은 형식이다. 와일드카드 문자인 +(단일 레벨)와 #(다중 레벨)을 사용하여 여러 토픽을 한 번에 구독할 수 있다[4].

QoS는 메시지 전달의 신뢰성 수준을 정의하는 MQTT의 핵심 메커니즘이다. 네트워크 환경과 애플리케이션 요구사항에 따라 세 가지 레벨 중 선택할 수 있다.

QoS 설정은 발행 시점에 결정되며, 브로커와 구독 클라이언트 간의 실제 전송 품질은 발행 QoS와 구독 시 요청된 QoS 중 더 낮은 값으로 조정된다. 이는 네트워크 대역폭이 제한된 사물인터넷 환경에서 효율적인 리소스 관리를 가능하게 한다.

MQTT는 이름 그대로 경량성을 최우선 설계 목표로 삼은 메시징 프로토콜이다. 이 프로토콜은 제한된 대역폭과 불안정한 네트워크 환경, 낮은 처리 성능과 메모리를 가진 임베디드 장치에서도 효율적으로 동작하도록 만들어졌다. 이러한 설계 철학은 TCP/IP 위에서 동작하는 다른 프로토콜들에 비해 매우 작은 프로토콜 오버헤드를 가능하게 한다. MQTT의 헤더는 최소 2바이트만으로 구성될 수 있으며, 메시지 페이로드 또한 최소화되어 전송된다.

이러한 경량성은 여러 측면에서 구현된다. 첫째, 고정 헤더가 매우 간결하며, 연결 수립 과정이 단순하다. 둘째, 메시지 유형이 제한적이고 명확하여 파싱과 처리가 빠르다. 셋째, 토픽 기반의 발행-구독 모델은 수신자가 명시적으로 지정되지 않아도 되어 주소 지정 정보가 필요 없다. 결과적으로 MQTT는 HTTP와 같은 프로토콜에 비해 네트워크 트래픽과 장치의 전력 소모를 크게 줄일 수 있다.

경량 프로토콜의 특성은 아래 표와 같이 주요 설계 요소에서 드러난다.

이러한 특성 덕분에 MQTT는 저전력 광역 네트워크(LPWAN)나 셀룰러 네트워크(예: NB-IoT, LTE-M)와 같이 리소스가 극도로 제한된 환경에서도 널리 채택되었다. 경량성은 단순히 패킷 크기만을 의미하는 것이 아니라, 프로토콜 전체의 단순성과 구현의 용이성을 포함하는 핵심 개념이다.

MQTT는 기본적으로 비동기 통신 방식을 채택한다. 이는 메시지를 보내는 클라이언트가 메시지를 받는 클라이언트의 즉각적인 응답을 기다리지 않고, 브로커에게 메시지를 전송한 후 자신의 작업을 계속할 수 있음을 의미한다. 발행자는 메시지를 브로커에 전달하는 즉시 연결을 끊을 수 있으며, 구독자는 자신이 온라인 상태가 될 때까지 메시지를 브로커로부터 비동기적으로 수신할 수 있다. 이 모델은 네트워크 대역폭이 제한적이거나 연결이 불안정한 사물인터넷 환경에 매우 적합하다.

비동기 통신의 핵심은 발행/구독 모델에 기반을 둔다. 발행자와 구독자는 서로를 직접 알 필요가 없으며, 오직 공통의 관심사인 토픽을 통해 간접적으로 연결된다. 발행자가 특정 토픽으로 메시지를 발행하면, 브로커는 해당 토픽을 구독하고 있는 모든 구독자에게 메시지를 비동기적으로 전달한다. 이 과정에서 발행자는 구독자가 메시지를 성공적으로 받았는지 여부를 알 수 없으며, 그 책임은 브로커와 QoS 수준에 의해 관리된다.

이러한 비동기 특성은 시스템의 확장성과 응답성을 크게 향상시킨다. 수천 개의 장치가 브로커에 연결되어 있어도, 개별 장치의 상태나 응답 지연이 전체 시스템에 직접적인 영향을 미치지 않는다. 또한, 클라이언트는 네트워크 연결이 일시적으로 끊어졌다가 복구되어도, 적절한 QoS 설정을 통해 놓친 메시지를 브로커로부터 다시 전달받을 수 있다. 이는 MQTT가 실시간성이 요구되지만 연결이 항상 안정적이지 않은 환경에서 널리 사용되는 주요 이유 중 하나이다.

MQTT는 제한된 대역폭과 불안정한 네트워크 환경에서도 신뢰할 수 있는 메시지 전달을 보장하기 위해 여러 메커니즘을 제공한다. 핵심은 QoS 수준이다. QoS는 메시지 전달의 신뢰성 수준을 정의하며, 0, 1, 2의 세 단계로 구분된다. 각 수준은 네트워크 품질에 따라 적절히 선택되어 사용된다.

QoS 수준은 다음과 같이 동작한다. QoS 0은 '최대 한 번' 전송으로, 메시지는 한 번만 발송되고 수신 확인을 하지 않는다. 이는 데이터 손실이 허용되는 시나리오에 적합하다. QoS 1은 '적어도 한 번' 전송으로, 발신자는 수신 확인(PUBACK) 패킷을 받을 때까지 메시지를 재전송한다. 이로 인해 메시지 중복이 발생할 수 있다. QoS 2는 '정확히 한 번' 전송으로, 네 단계의 핸드셰이크 과정을 통해 메시지 중복을 완전히 제거하며 가장 높은 신뢰성을 보장한다.

이 외에도 MQTT는 연결이 끊겼을 때를 대비한 지속 세션과 Last Will and Testament 메커니즘을 갖추고 있다. 클라이언트는 연결 시 지속 세션을 요청할 수 있으며, 이 경우 브로커는 클라이언트의 구독 정보와 미처리 메시지(QoS 1, 2)를 유지한다. 클라이언트가 재연결하면 이 상태가 복원된다. LWT는 클라이언트가 예기치 않게 연결이 끊어졌을 때 브로커가 대신 지정된 토픽에 '유언' 메시지를 발행하도록 설정하는 기능이다. 이를 통해 시스템은 비정상 종료를 감지하고 대응할 수 있다.

MQTT는 제한된 컴퓨팅 자원과 불안정한 네트워크 환경을 가진 사물인터넷 디바이스에 최적화된 통신 프로토콜이다. 센서, 액추에이터, 게이트웨이 등 다양한 IoT 장치들이 에너지 효율적으로 데이터를 교환할 수 있도록 설계되었다. 경량 프로토콜 특성으로 인해 배터리 수명이 긴 장치에서도 장기간 운영이 가능하며, 발행/구독 모델을 통해 하나의 메시지를 다수의 구독자에게 효율적으로 전파할 수 있다.

주요 적용 사례로는 스마트 홈 환경에서의 조명 제어, 온도 조절, 보안 시스템 연동이 있다. 또한 산업 IoT 분야에서는 공장 자동화 시스템의 기계 상태 모니터링, 원격 제어, 예측 정비에 널리 사용된다. MQTT의 QoS 수준을 활용하면 네트워크 품질에 따라 메시지 전달의 신뢰성을 유연하게 조정할 수 있어, 상황에 맞는 통신을 보장한다.

다음 표는 사물인터넷에서 MQTT가 해결하는 일반적인 과제와 그 대응 방식을 보여준다.

이러한 특성들 덕분에 MQTT는 수많은 IoT 플랫폼과 클라우드 서비스의 표준 통신 수단으로 채택되었다. 예를 들어, Amazon Web Services IoT Core, Microsoft Azure IoT Hub, Google Cloud IoT Core 등 주요 클라우드 제공자들은 MQTT를 기본 프로토콜로 지원한다.

MQTT는 모바일 애플리케이션 환경에서 효율적인 통신을 가능하게 하는 프로토콜이다. 모바일 환경은 배터리 수명, 불규칙한 네트워크 연결, 제한된 대역폭 등 여러 제약 조건을 가지고 있다. MQTT의 경량 설계와 비동기 통신 방식은 이러한 제약을 극복하는 데 적합하다. 애플리케이션이 네트워크에 항상 연결되어 있을 필요 없이, 메시지를 발행하거나 필요한 토픽을 구독할 수 있어 배터리 소모를 줄일 수 있다.

특히 푸시 알림, 실시간 채팅, 위치 기반 서비스, 소셜 미디어 피드 업데이트 등에 활용된다. 예를 들어, 채팅 애플리케이션에서는 각 채팅방을 하나의 토픽(Topic)으로 설정하고, 사용자는 해당 토픽을 구독하여 실시간으로 메시지를 수신할 수 있다. MQTT 브로커(Broker)는 메시지의 중개자 역할을 하여, 발행자가 오프라인 상태인 구독자에게도 메시지를 전달할 수 있도록 QoS(Quality of Service) 수준에 따라 메시지를 보관한다.

다음은 MQTT가 모바일 애플리케이션에 적합한 이유를 정리한 표이다.

이러한 특성으로 인해 MQTT는 사물인터넷(IoT) 기기와 모바일 앱을 연결하는 브릿지 역할을 하기도 한다. 사용자는 스마트폰 앱을 통해 원격지의 IoT 장치 상태를 모니터링하거나 제어 명령을 발행할 수 있다.

MQTT의 발행/구독 모델과 낮은 지연 시간, 효율적인 메시지 배달 특성은 실시간으로 데이터를 생성, 전송, 소비해야 하는 다양한 스트리밍 시나리오에 적합한 프로토콜로 자리 잡았다. 센서 네트워크나 사물인터넷 이상으로, 빠르게 변화하는 데이터의 흐름을 관리하는 데 널리 활용된다.

주요 적용 분야로는 실시간 위치 추적 시스템이 있다. 차량, 배송 물품, 모바일 장치 등 이동체의 GPS 좌표 데이터가 토픽을 통해 지속적으로 발행되고, 관제 센터나 모니터링 애플리케이션이 해당 토픽을 구독하여 지도 상에 실시간으로 위치를 표시한다. QoS 수준을 조정하여 네트워크 상태에 따라 데이터의 신뢰성과 실시간성을 균형 있게 설정할 수 있다. 또한 주식 시세, 암호화폐 가격, 스포츠 경기 실황 점수와 같은 금융 및 엔터테인먼트 분야의 실시간 피드 전송에도 적극적으로 사용된다. 수많은 클라이언트가 동일한 시장 데이터 토픽을 구독하며, 새로운 데이터가 발행되는 즉시 전달받을 수 있다.

아래 표는 MQTT 기반 실시간 데이터 스트리밍의 주요 유형과 특징을 정리한 것이다.

이러한 스트리밍 활용은 MQTT 5.0에서 도입된 공유 구독(Shared Subscriptions) 기능으로 더욱 강화되었다. 이 기능을 통해 고가용성과 부하 분산이 필요한 스트리밍 서비스에서, 여러 구독자 클라이언트가 하나의 토픽을 공유하여 메시지 처리 부하를 분산시킬 수 있다. 결과적으로 MQTT는 단순한 장치 제어를 넘어서, 시간에 민감한 데이터의 효율적인 스트리밍 인프라의 핵심 프로토콜로 역할을 수행한다.

MQTT 브로커는 클라이언트의 연결을 허용하기 전에 인증을 요구할 수 있다. 가장 일반적인 방식은 사용자 이름과 비밀번호를 이용한 인증이다. 클라이언트는 CONNECT 패킷에 이 자격 증명을 포함하여 전송하고, 브로커는 이를 검증하여 연결을 승인하거나 거부한다. 일부 구현체에서는 클라이언트 인증서를 사용한 X.509 인증과 같은 더 강력한 방법도 지원한다.

인증 이후에는 권한 부여, 즉 특정 작업에 대한 접근 제어가 이루어진다. 대표적인 권한 부여 메커니즘은 ACL이다. ACL 규칙은 클라이언트 ID나 사용자 이름을 기준으로 특정 토픽에 대한 구독, 발행, 또는 두 가지 모두를 허용하거나 금지한다. 예를 들어, 특정 클라이언트가 "sensor/temperature" 토픽에는 데이터를 발행만 할 수 있고, "actuator/light" 토픽에는 구독만 할 수 있도록 세밀하게 제어할 수 있다.

권한 부여는 시스템의 보안과 데이터 무결성을 유지하는 데 필수적이다. 잘못 구성된 ACL은 권한 없는 클라이언트가 중요한 토픽에 메시지를 발행하거나 기밀 데이터를 구독하는 것을 허용할 수 있다. 따라서 프로덕션 환경에서는 반드시 인증과 함께 엄격한 권한 부여 정책을 구성하고 정기적으로 검토해야 한다.

MQTT는 기본적으로 평문 통신을 사용하므로, 전송 중인 데이터의 기밀성과 무결성을 보장하기 위해 TLS/SSL 암호화를 적용하는 것이 필수적이다. TLS/SSL은 MQTT 브로커와 MQTT 클라이언트 간의 통신 채널을 암호화하여, 메시지 내용이 제3자에 의해 도청되거나 변조되는 것을 방지한다. 일반적으로 표준 MQTT 포트(1883) 대신 암호화된 포트(8883)를 사용하여 연결을 수립한다.

암호화 구현 방식은 주로 두 가지로 나뉜다. 첫째는 전송 계층 보안을 통해 전체 연결을 암호화하는 방식이다. 이 경우 모든 MQTT 패킷이 암호화되어 전송되며, 클라이언트 인증서를 사용한 강력한 클라이언트 인증도 가능하다. 둘째는 웹소켓을 통한 MQTT 연결에 TLS를 적용하는 방식으로, 웹 브라우저 기반 클라이언트에서 주로 사용된다.

TLS/SSL을 구성할 때는 강력한 암호화 제품군을 선택하고, 유효한 인증서를 사용해야 한다. 자체 서명된 인증서는 개발 및 테스트 환경에서는 사용될 수 있으나, 프로덕션 환경에서는 공인된 인증 기관에서 발급받은 인증서를 사용하는 것이 보안상 안전하다. 이를 통해 중간자 공격을 방지하고 통신 상대방의 신원을 확인할 수 있다.