Booil Jung

MQTT 프로토콜

MQTT(Message Queuing Telemetry Transport) 프로토콜은 1999년, IBM의 앤디 스탠퍼드 클락(Andy Stanford-Clark)과 당시 아르컴 컨트롤 시스템즈(Arcom Control Systems, 현 시러스 링크) 소속의 알렌 니퍼(Arlen Nipper)에 의해 처음 개발되었다.1 이 프로토콜의 탄생 배경에는 매우 구체적이고 현실적인 산업 현장의 요구가 있었다. 당시 이들은 위성을 통해 광범위하게 펼쳐진 석유 및 가스 파이프라인을 원격으로 모니터링해야 하는 과제에 직면했다.2 이러한 환경은 네트워크 대역폭이 극도로 제한적이고, 통신 비용이 높으며, 연결이 불안정하고, 현장 장비는 배터리와 같은 제한된 전력으로 구동되어야 하는 극한의 조건을 내포하고 있었다. 즉, 최소한의 대역폭과 최소한의 배터리 소모를 지원하면서도 신뢰성 있는 데이터 전송이 가능한 새로운 통신 규약이 절실히 필요했던 것이다.2

이러한 배경 속에서 MQTT는 ‘작은 코드 공간(small code footprint)’과 제한된 네트워크 대역폭 환경에 최적화된 경량 메시징 프로토콜로 설계되었다.1 초기 명칭인 ‘Message Queuing Telemetry Transport’는 당시 IBM의 메시지 큐 제품군인 ‘MQSeries’(현 WebSphere MQ)에서 그 기원을 찾을 수 있다.1 이는 프로토콜의 초기 단계에서 IBM의 기술적 영향이 있었음을 시사하지만, 현재 MQTT는 더 이상 특정 제품군의 약어가 아닌, 프로토콜 자체를 지칭하는 공식적인 이름으로 통용된다.2

MQTT의 발전 과정에서 중요한 전환점은 2010년, IBM이 MQTT 버전 3.1을 모든 사용자가 자유롭게 구현할 수 있는 개방형 무료 프로토콜로 공개한 것이다.2 이 결정은 MQTT가 특정 기업의 소유물을 넘어, 전 세계 개발자 커뮤니티와 산업계가 함께 발전시키는 공개 표준으로 나아가는 발판이 되었다. 이후 프로토콜의 체계적인 유지보수와 발전을 위해 2013년, 구조화된 정보 표준의 발전을 위한 기구인 OASIS(Organization for the Advancement of Structured Information Standards)에 표준으로 제출되었고, 이는 MQTT가 공식적인 국제 표준으로 자리매김하는 계기가 되었다.1 2019년에는 현대적인 IoT 환경의 복잡한 요구사항을 반영하여 공유 구독, 세션 만료, 이유 코드 등 다양한 기능이 대폭 개선된 MQTT 버전 5.0이 발표되면서 프로토콜의 기능성과 확장성은 한 단계 더 도약하였다.2

MQTT의 가장 근본적인 설계 철학은 발행-구독(Publish-Subscribe) 모델에 있다. 이는 전통적인 클라이언트-서버(Client-Server) 구조의 요청-응답(Request-Response) 모델과는 근본적으로 다른 통신 패러다임을 제시한다.2 요청-응답 모델에서는 클라이언트가 서버의 특정 주소(Endpoint)를 명확히 알고 직접 연결하여 데이터를 요청하고 응답을 기다린다. 이는 클라이언트와 서버 간의 강한 결합(tight coupling)을 전제로 하며, 한쪽의 장애가 다른 쪽에 직접적인 영향을 미치는 구조적 한계를 지닌다.

반면, MQTT의 발행-구독 모델은 ‘메시지 브로커(Message Broker)’라는 제3의 중개자를 통신 아키텍처의 중심에 둔다.2 이 모델에서 메시지를 보내는 주체인 ‘발행자(Publisher)’와 메시지를 받는 주체인 ‘구독자(Subscriber)’는 서로의 존재를 전혀 알지 못한다. 발행자는 특정 주제(Topic)에 대한 메시지를 브로커에게 보내는 것으로 자신의 임무를 다하며, 구독자는 자신이 관심 있는 주제를 브로커에게 등록해 놓음으로써 해당 주제에 대한 메시지를 수신한다. 모든 메시지 흐름은 브로커가 전적으로 중개한다.5

이러한 중개 구조는 시스템 구성요소 간의 세 가지 핵심적인 ‘분리(Decoupling)’를 가능하게 하며, 이는 MQTT 기반 시스템의 유연성, 확장성, 그리고 회복탄력성(Resilience)의 근간을 이룬다.2

이 세 가지 분리 원칙은 단순히 기술적 특징을 넘어선다. 이는 시스템 아키텍처에 본질적인 회복탄력성을 부여하는 철학적 기반이 된다. 강하게 결합된 시스템에서는 하나의 구성요소의 장애가 연쇄적으로 다른 구성요소의 장애를 유발할 수 있다. 예를 들어, HTTP 기반 시스템에서 서버가 다운되면 클라이언트는 직접적으로 오류를 처리하고 재시도 로직을 수행해야 한다. 그러나 MQTT 기반 시스템에서는 발행자가 오프라인이 되어도 구독자는 단순히 새로운 데이터를 받지 못할 뿐 시스템 자체가 중단되지는 않는다. 반대로 구독 애플리케이션에 장애가 발생하더라도 발행자는 아무런 영향을 받지 않고 계속해서 데이터를 브로커로 전송할 수 있다. 이 구조에서 브로커는 각 구성요소의 가용성 문제나 연결 상태 변화에 대한 ‘충격 흡수 장치(shock absorber)’ 역할을 수행한다. 결과적으로, MQTT는 메시지를 전송하는 단순한 프로토콜을 넘어, 본질적으로 견고하고 확장 가능하며 장애에 유연하게 대처할 수 있는 분산 시스템을 구축하기 위한 강력한 아키텍처 패턴을 제공한다.

MQTT 프로토콜의 아키텍처는 세 가지 핵심적인 역할로 구성된다: 발행자(Publisher), 구독자(Subscriber), 그리고 브로커(Broker). 이들의 상호작용은 발행-구독 모델의 근간을 이룬다.

MQTT 클라이언트와 브로커 간의 모든 상호작용은 신뢰성 있는 양방향 연결을 제공하는 TCP/IP 프로토콜 위에서 이루어진다.1 통신을 시작하기 위해 클라이언트는 먼저 브로커와의 TCP 연결을 수립한 후, MQTT 프로토콜 레벨의 연결 설정을 위한 핸드셰이크(handshake) 과정을 거친다.

  1. CONNECT 패킷 전송: 클라이언트는 브로커에게 CONNECT 메시지를 전송하여 MQTT 세션의 시작을 요청한다.6 이 패킷은 단순한 연결 요청 이상의 의미를 가지며, 세션의 동작 방식을 결정하는 중요한 파라미터들을 포함한다.
    • Client ID: 각 클라이언트를 고유하게 식별하는 문자열이다. 영구 세션을 사용하기 위해서는 이 ID가 반드시 고정되어야 한다.
    • Clean Start (MQTT v5) / Clean Session (MQTT v3.1.1): 이 플래그가 true이면, 클라이언트는 새로운 세션을 시작하며 브로커는 이전 세션 정보를 모두 폐기한다. false이면, 브로커는 동일한 Client ID를 가진 이전 세션이 존재할 경우 이를 재개하려고 시도한다.
    • Keep Alive: 클라이언트와 브로커가 연결이 유지되고 있음을 확인하기 위한 시간 간격(초 단위)이다. 이 시간 내에 아무런 메시지 교환이 없으면 클라이언트는 PINGREQ 패킷을 보내고, 브로커는 PINGRESP로 응답하여 연결 상태를 확인한다.
    • Username / Password: 클라이언트 인증을 위한 자격 증명 정보를 포함할 수 있다.
    • Last Will and Testament (LWT): 클라이언트가 비정상적으로 연결이 끊어졌을 때 브로커가 발행할 유언 메시지(토픽, 페이로드, QoS, Retain 플래그)를 지정한다.
  2. CONNACK 패킷 수신: 브로커는 클라이언트의 CONNECT 요청을 처리한 후, 그 결과를 CONNACK (Connection Acknowledgement) 메시지로 응답한다.6
    • Session Present Flag: CONNACK 패킷에는 클라이언트가 요청한 세션(Clean Start=false)이 브로커에 존재하여 재개되었는지 여부를 나타내는 플래그가 포함된다. 이를 통해 클라이언트는 이전 구독을 다시 할 필요가 있는지 판단할 수 있다.
    • Return Code / Reason Code: 연결 요청의 성공 또는 실패 여부를 나타내는 코드를 포함한다. MQTT v3.1.1에서는 단순한 반환 코드를 사용했지만, MQTT v5.0에서는 ‘잘못된 프로토콜 버전’, ‘인증 실패’ 등 구체적인 실패 원인을 알려주는 이유 코드(Reason Code)를 사용하여 진단과 디버깅을 용이하게 한다.

이 CONNECT-CONNACK 핸드셰이크 과정이 성공적으로 완료되어야만, 클라이언트는 메시지를 발행하거나 토픽을 구독하는 등의 후속 MQTT 작업을 수행할 수 있다.

MQTT에서 토픽은 메시지를 분류하고 라우팅하는 핵심적인 메커니즘이다. 이는 단순한 문자열 레이블을 넘어, 시스템 전체의 데이터 흐름을 구조화하는 역할을 수행한다. 토픽은 슬래시(/) 문자를 구분자로 사용하여 파일 시스템의 디렉터리 경로와 유사한 계층적 구조(hierarchical structure)를 가진다.5 예를 들어, 특정 건물의 특정 층에 있는 특정 방의 온도 센서 데이터는 building_A/floor_3/room_301/temperature와 같은 토픽으로 표현될 수 있다.

이러한 계층적 네임스페이스는 다음과 같은 중요한 설계상의 이점을 제공한다.

이처럼 MQTT의 토픽 네임스페이스는 단순한 주소 지정 체계를 넘어, 시스템 전체의 데이터 스키마(schema) 역할을 암묵적으로 수행한다. 데이터베이스 설계에서 스키마가 데이터의 구조와 관계를 정의하듯이, MQTT 시스템에서는 잘 설계된 토픽 네임스페이스가 데이터의 논리적, 물리적 계층을 정의하고 데이터의 발견 가능성(discoverability)과 관리 용이성을 결정한다. 따라서 대규모 MQTT 시스템을 설계할 때 토픽 네임스페이스를 어떻게 구조화할 것인가는 초기에 신중하게 결정해야 할 가장 중요한 아키텍처적 결정 중 하나이다. 잘 설계된 네임스페이스는 그 자체로 시스템을 설명하는 문서가 되며, 시스템의 확장성과 유지보수성을 크게 향상시킨다. 반면, 일관성 없는 토픽 구조는 구독의 모호성을 유발하고, 비효율적인 와일드카드 사용으로 인한 브로커의 성능 저하, 그리고 복잡한 접근 제어 규칙을 초래할 수 있다.

MQTT의 강력함은 와일드카드를 이용한 유연한 구독 기능에서 두드러진다. 구독자는 특정 토픽을 명시적으로 구독하는 것 외에도, 두 종류의 와일드카드 문자를 사용하여 여러 토픽을 포괄하는 패턴을 구독할 수 있다. 단, 와일드카드는 구독(SUBSCRIBE) 시에만 사용 가능하며, 발행(PUBLISH) 시 토픽 이름에는 사용할 수 없다.10

와일드카드를 활용한 구독 전략은 시스템의 효율성과 확장성을 크게 향상시킨다. 예를 들어, 새로운 센서가 usa/ca/sandiego/temperature라는 토픽으로 데이터를 발행하기 시작했을 때, usa/ca/+/temperature를 구독하고 있는 기존의 애플리케이션은 아무런 변경 없이 새로운 센서의 데이터를 즉시 수신할 수 있다. 이는 새로운 데이터 소스를 시스템에 동적으로 추가하고 통합하는 과정을 매우 단순하게 만들어준다.

MQTT는 네트워크의 신뢰도와 메시지의 중요성에 따라 전송 품질을 선택할 수 있도록 세 단계의 서비스 품질(Quality of Service, QoS) 레벨을 정의한다. 이는 불안정한 네트워크 환경에서도 데이터의 신뢰성을 보장하기 위한 핵심적인 메커니즘이다.8

QoS 0은 “최대 한 번” 전송을 의미하며, “쏘고 잊어버리기(Fire and Forget)” 방식으로 동작한다.1

QoS 1은 “최소 한 번” 전송을 보장하며, 가장 널리 사용되는 서비스 레벨이다.17

QoS 2는 “정확히 한 번” 전송을 보장하는 가장 높은 신뢰도 수준의 서비스이다.1

메시지가 구독자에게 최종적으로 전달될 때 적용되는 QoS 레벨은 발행자가 설정한 QoS와 구독자가 구독 시 요청한 QoS 중 더 낮은 값으로 결정된다는 점을 이해하는 것이 중요하다.17 예를 들어, 발행자가 중요한 경보를 QoS 2로 발행했더라도, 실시간 대시보드 역할을 하는 구독자가 성능을 위해 QoS 0으로 구독했다면 브로커는 해당 구독자에게 메시지를 QoS 0으로 전달한다. 반면, 모든 경보를 기록해야 하는 다른 구독자가 QoS 1로 구독했다면, 브로커는 이 구독자에게는 QoS 1로 메시지를 전달한다.

이러한 QoS 하향 조정(downgrading) 메커니즘은 MQTT의 분리(decoupling) 철학을 강화하는 강력한 기능이다. 이는 데이터 생산자의 신뢰성 요구사항과 데이터 소비자의 신뢰성 요구사항을 분리시킨다. 발행자는 데이터의 고유한 중요도에 따라 QoS를 결정하고, 각 소비자는 자신의 애플리케이션 로직과 성능 요구사항에 맞춰 최적의 신뢰도 수준을 독립적으로 선택할 수 있다. 이로 인해 단일 데이터 소스가 다양한 신뢰도 요구를 가진 여러 애플리케이션에 동시에 서비스를 제공할 수 있게 되어, 시스템 전체의 유연성과 효율성이 극대화된다.

MQTT는 단순히 메시지를 전달하는 것을 넘어, 클라이언트의 상태를 관리하고 불안정한 네트워크 환경에서도 데이터의 연속성을 보장하기 위한 정교한 메커니즘을 제공한다.

LWT(Last Will and Testament, 유언)는 클라이언트의 비정상적인 연결 종료를 감지하고 다른 시스템 구성원들에게 이를 알리는 강력한 기능이다.26

Retained Message(보관 메시지)는 특정 토픽의 가장 최근 상태 값을 브로커에 저장하여, 새로운 구독자가 즉시 해당 상태를 알 수 있도록 하는 기능이다.29

LWT와 Retained Message를 함께 사용하면 매우 효율적이고 견고한 상태 관리 패턴을 구축할 수 있다. 앞선 LWT 예시에서 유언 메시지("offline")와 정상 상태 메시지("online")를 모두 RETAIN 플래그를 켜서 발행하도록 구성하는 것이 핵심이다.26 장치가 연결될 때

devices/123/status 토픽에 "online"이라는 보관 메시지를 남기고, 비정상 종료 시 브로커가 "offline"이라는 보관 메시지를 남기도록 LWT를 설정한다. 이렇게 하면 언제 어떤 애플리케이션이 devices/123/status 토픽을 구독하더라도, 항상 해당 장치의 가장 최신 온라인/오프라인 상태를 즉시 전달받을 수 있다.29

이 패턴은 장치의 상태 정보를 브로커 자체에 외부화(externalize)하는 효과를 가져온다. 즉, 브로커가 장치 상태에 대한 ‘단일 진실 공급원(Single Source of Truth)’ 역할을 하게 된다. 이는 상태 모니터링 로직을 장치의 운영 로직과 완벽하게 분리하는 강력한 아키텍처 패턴이다. 애플리케이션은 더 이상 장치가 온라인 상태인지 확인하기 위해 복잡한 핑퐁(ping-pong)이나 타임아웃 로직을 구현할 필요가 없다. 단순히 상태 토픽을 구독하고 브로커가 제공하는 현재 상태 정보를 신뢰하기만 하면 된다. 이는 애플리케이션 개발을 크게 단순화하고 시스템 전반의 상황 인지 능력을 향상시킨다.

영구 세션은 클라이언트가 오프라인 상태일 때도 구독 정보와 중요 메시지를 보존하여 통신의 연속성을 보장하는 핵심 기능이다.

이 세 가지 기능(LWT, Retained Message, Persistent Session)은 MQTT가 단순한 메시지 전송 프로토콜을 넘어, 상태를 인지하고 관리하며, 불안정한 환경에서도 신뢰성을 유지하는 정교한 통신 프레임워크임을 보여주는 핵심 요소들이다

2019년에 발표된 MQTT 버전 5.0은 이전 버전인 v3.1.1의 성공을 기반으로, 대규모 IoT 시스템의 복잡성과 현대적인 애플리케이션의 요구사항을 해결하기 위한 중요한 기능들을 대거 도입했다. 이는 단순한 업데이트를 넘어, 프로토콜의 표현력과 견고함을 한 차원 높인 진화로 평가받는다.35

MQTT v3.1.1의 영구 세션(Clean Session=false)은 강력한 기능이었지만, 한 가지 중요한 단점을 가지고 있었다. 클라이언트가 영원히 돌아오지 않을 경우, 해당 세션 정보와 큐에 쌓인 메시지들이 브로커에 무기한으로 남아 시스템 자원을 점유하는 문제가 있었다.35

MQTT v5.0은 Session Expiry Interval이라는 새로운 속성을 도입하여 이 문제를 해결했다.38

이 기능은 브로커가 불필요한 세션 데이터를 영구적으로 보관하는 것을 방지하여 리소스 관리를 효율화하고, 시스템의 안정성을 높이는 데 크게 기여한다.35

MQTT v3.1.1의 또 다른 한계는 오류 처리의 모호성이었다. 예를 들어, 클라이언트의 연결 요청이 거부될 경우, CONNACK 패킷은 ‘수락되지 않음’이라는 포괄적인 반환 코드만을 제공할 뿐, 그 구체적인 원인(예: 잘못된 프로토콜 버전, 인증 실패, 서버 사용 불가 등)을 알려주지 않았다. 이로 인해 개발자는 문제의 원인을 파악하고 디버깅하는 데 어려움을 겪었다.

MQTT v5.0은 거의 모든 응답 패킷(CONNACK, PUBACK, SUBACK, UNSUBACK, DISCONNECT 등)에 Reason Code 필드를 추가하여 이 문제를 해결했다.37

이러한 개선 사항은 MQTT 기반 시스템의 디버깅 용이성과 운영 안정성을 크게 향상시켰다. 개발자는 더 이상 로그 파일을 뒤지거나 추측에 의존하지 않고도, 프로토콜 수준에서 제공되는 명확한 피드백을 통해 문제 상황에 신속하고 정확하게 대응할 수 있게 되었다.35

표 1: MQTT 버전별 핵심 기능 비교 (v3.1.1 vs v5.0)

기능 분류 세부 기능 MQTT v3.1.1 MQTT v5.0 주요 변경점 및 의의
세션 관리 세션 지속성 Clean Session 플래그 (boolean) Clean Start 플래그 + Session Expiry Interval (integer) 영구 세션의 유효 기간을 지정하여 브로커의 리소스 관리를 최적화하고, 좀비 세션 문제를 해결함.35
오류 처리 피드백 메커니즘 제한된 반환 코드 (예: CONNACK) 모든 ACK 패킷에 Reason Code 도입, DISCONNECT 패킷에 이유 코드 추가 연결 실패, 발행/구독 거부 등의 원인을 명확하게 전달하여 디버깅 및 오류 처리 로직을 크게 개선함.37
메시지 속성 메타데이터 없음 (페이로드에 포함해야 함) User Properties (사용자 정의 키-값 쌍) 페이로드를 파싱하지 않고도 메시지 라우팅, 필터링 등 고급 로직 구현이 가능해져 시스템 간 상호운용성 증대.35
  메시지 만료 없음 Message Expiry Interval 더 이상 유효하지 않은 메시지(예: 시한성 명령)가 오프라인 클라이언트에게 전달되는 것을 방지하여 데이터의 적시성 보장.4
  페이로드 정보 없음 Payload Format Indicator, Content Type 페이로드가 바이너리인지 UTF-8 텍스트인지, 그리고 어떤 형식(예: application/json)인지 명시하여 수신 측의 처리 로직을 단순화함.39
구독 옵션 공유 구독 없음 (일부 브로커에서 비표준 지원) 표준 기능으로 도입 ($share/...) 여러 구독자가 하나의 구독을 공유하며 메시지를 분산 처리(로드 밸런싱)할 수 있어, 백엔드 시스템의 확장성을 프로토콜 수준에서 지원함.35
  로컬 발행 방지 없음 No Local 구독 옵션 클라이언트가 자신이 발행한 메시지를 다시 수신하지 않도록 설정 가능. 불필요한 루프백(loopback) 트래픽을 방지함.40
통신 패턴 요청-응답 없음 (애플리케이션 수준에서 구현) Response Topic, Correlation Data 속성 지원 요청-응답 패턴을 프로토콜 수준에서 공식적으로 지원하여, RPC(Remote Procedure Call)와 같은 상호작용 구현을 용이하게 함.4
성능 최적화 토픽 이름 매번 전체 토픽 이름 전송 Topic Alias 긴 토픽 이름을 짧은 정수 별칭으로 대체하여 전송함으로써, 네트워크 대역폭 사용량을 크게 절감함.4
  흐름 제어 없음 Receive Maximum, Maximum Packet Size 클라이언트와 브로커가 한 번에 처리할 수 있는 미확인 QoS 1/2 메시지 수와 최대 패킷 크기를 서로에게 알려, 과부하를 방지하고 안정적인 통신을 유지함.4

전통적인 MQTT 구독 모델에서는 특정 토픽을 구독하는 모든 클라이언트가 해당 토픽에 발행된 모든 메시지의 복사본을 수신한다. 이는 정보 방송에는 유용하지만, 여러 백엔드 애플리케이션이 동일한 데이터 스트림을 병렬로 처리해야 하는 시나리오에서는 비효율적이다. 모든 애플리케이션이 동일한 메시지를 중복으로 처리하게 되기 때문이다.

MQTT v5.0은 이 문제를 해결하기 위해 ‘공유 구독’을 표준 기능으로 도입했다.35

MQTT v3.1.1에서는 메시지의 페이로드(payload) 외에 추가적인 정보를 전달할 표준화된 방법이 없었다. 모든 메타데이터는 페이로드 내부에 포함되어야 했고, 이는 수신 측에서 페이로드를 파싱해야만 해당 정보를 얻을 수 있음을 의미했다.

MQTT v5.0의 ‘사용자 속성’은 이 한계를 극복한다. 이는 HTTP 헤더와 매우 유사한 개념으로, 거의 모든 종류의 MQTT 패킷(CONNECT, PUBLISH, SUBSCRIBE 등)에 사용자 정의 키-값(key-value) 쌍 형태의 메타데이터를 추가할 수 있도록 허용한다.4

사용자 속성은 MQTT 프로토콜의 유연성과 확장성을 크게 향상시켜, 다양한 시스템 간의 상호운용성을 높이는 중요한 역할을 한다.

MQTT는 본질적으로 비동기적인 발행-구독 프로토콜이지만, 실제 애플리케이션에서는 동기적인 요청-응답 패턴이 필요한 경우가 많다. MQTT v5.0은 이를 프로토콜 수준에서 지원하기 위해 두 가지 새로운 속성을 도입했다.

이 메커니즘은 MQTT를 통해 원격 프로시저 호출(RPC)과 같은 상호작용을 표준화되고 안정적인 방식으로 구현할 수 있게 해준다.4

MQTT v5.0에 도입된 이러한 새로운 기능들(공유 구독, 사용자 속성, 이유 코드 등)은 MQTT를 단순한 원격 측정 데이터 전송 프로토콜에서 복잡한 대규모 엔터프라이즈 통합을 위한 정교한 메시징 프레임워크로 변모시켰다. v3.1.1에서는 애플리케이션 수준에서 복잡하게 구현해야 했던 부하 분산, 메타데이터 전달, 명확한 오류 처리와 같은 공통적인 메시징 패턴과 운영상의 문제들이 이제 프로토콜 자체에 내장되었다. 이는 서로 다른 시스템 간의 상호운용성을 크게 향상시키고, 개발자가 비즈니스 로직에 더 집중할 수 있도록 하여, 결과적으로 더 빠르고 안정적인 IoT 시스템 통합을 가능하게 한다.

MQTT는 사물 인터넷(IoT) 통신 프로토콜 생태계에서 독보적인 위치를 차지하고 있지만, 유일한 선택지는 아니다. 특정 사용 사례와 요구사항에 따라 다른 프로토콜이 더 적합할 수 있다. MQTT의 기술적 특성과 위상을 명확히 이해하기 위해, 주요 통신 프로토콜인 HTTP, CoAP, AMQP와의 비교 분석을 수행한다.

MQTT와 HTTP는 웹 및 IoT 환경에서 가장 널리 언급되는 프로토콜이지만, 그 설계 철학과 동작 방식은 근본적으로 다르다.

CoAP(Constrained Application Protocol)는 MQTT와 마찬가지로 자원이 극도로 제한된(constrained) 장치와 네트워크를 위해 설계된 프로토콜이지만, 다른 기술적 접근 방식을 취한다.

AMQP(Advanced Message Queuing Protocol)는 주로 엔터프라이즈 환경의 안정적인 비동기 메시징을 위해 설계된 프로토콜로, MQTT와는 지향하는 목표와 복잡성에서 큰 차이를 보인다.

이러한 비교 분석을 통해, 각 프로토콜이 모든 시나리오에 적합한 만능 해결책이 아님을 알 수 있다. 이들은 복잡성, 신뢰성, 오버헤드라는 다차원적인 스펙트럼 위에 각자의 위치를 점하고 있다. 가장 경량화된 CoAP부터, IoT의 표준으로 자리 잡은 MQTT, 웹의 표준인 HTTP, 그리고 엔터프라이즈 메시징의 강자인 AMQP에 이르기까지, 각 프로토콜은 고유한 강점과 약점을 가진다. 성공적인 시스템 아키텍트는 특정 사용 사례의 제약 조건(장치 성능, 네트워크 상태)과 요구사항(데이터 중요도, 시스템 복잡도)을 종합적으로 평가하여, 이 스펙트럼 위에서 가장 적절한 프로토콜 또는 프로토콜의 조합을 선택해야 한다. 때로는 엣지에서는 CoAP를, 클라우드 연동에는 MQTT를, 그리고 백엔드 시스템 간의 연동에는 AMQP를 사용하는 하이브리드 아키텍처가 최적의 해답이 될 수 있다.

표 2: 주요 IoT 프로토콜 비교 (MQTT vs. HTTP vs. CoAP vs. AMQP)

비교 기준 MQTT HTTP CoAP AMQP
기본 전송 프로토콜 TCP TCP UDP TCP
통신 모델 발행/구독 (Publish/Subscribe) 요청/응답 (Request/Response) 요청/응답 (Request/Response) 교환기-큐 기반 (Exchange-Queue)
헤더 오버헤드 매우 낮음 (최소 2바이트) 높음 (텍스트 기반, 수십~수백 바이트) 매우 낮음 (최소 4바이트) 중간~높음 (바이너리, 8바이트 이상)
신뢰성 보장 3단계 QoS (0, 1, 2) TCP 신뢰성, 애플리케이션 재시도 확인/비확인 메시지 (QoS 0, 1 유사) 확인, 트랜잭션, 영속성 등
상태 관리 상태 기반 (영구 세션, LWT) 무상태 (Stateless) 상태 기반 (Observe) 상태 기반 (큐, 영속성)
주요 사용 사례 IoT/IIoT, M2M, 모바일 메시징 웹 서비스, REST API 자원 제약이 극심한 센서 네트워크 엔터프라이즈 메시징, 금융 시스템
장점 경량, 저전력, 양방향, 높은 확장성 범용성, 성숙한 생태계, 개발 용이성 극도의 경량성, 저전력, 멀티캐스트 강력한 라우팅, 높은 신뢰성, 풍부한 기능
단점 단순한 라우팅, 트랜잭션 미지원 높은 오버헤드, 폴링 방식, 실시간성 부족 신뢰성/순서 보장 자체 구현 필요 복잡성, 높은 오버헤드, 리소스 요구량

MQTT를 실제 시스템에 성공적으로 배포하고 운영하기 위해서는 프로토콜의 보안 메커니즘을 깊이 이해하고, 대규모 트래픽을 처리하기 위한 시스템 수준의 최적화를 수행하는 것이 필수적이다.

IoT 시스템은 수많은 디바이스가 외부 네트워크에 연결되므로 보안은 가장 중요한 고려사항 중 하나이다. MQTT는 다층적인 보안 아키텍처를 구축할 수 있는 메커니즘을 제공한다.

MQTT 통신의 가장 기본적인 보안 계층은 전송 데이터 자체를 암호화하는 것이다.

전송 계층의 암호화가 안전한 통로를 확보하는 것이라면, 애플리케이션 계층의 인증과 인가는 그 통로를 이용할 자격이 있는지를 판단하고, 자격이 있는 사용자가 할 수 있는 일을 제한하는 역할을 한다.

MQTT 프로토콜 자체는 비교적 단순하고 안전하게 설계되었지만, 실제 상용 및 오픈소스 브로커 구현체에서는 다양한 보안 취약점(CVE, Common Vulnerabilities and Exposures)이 발견되어 왔다. 이러한 취약점을 분석해 보면, 대부분이 프로토콜 명세 자체의 결함이라기보다는 개발자가 명세를 구현하는 과정에서 발생한 프로그래밍 오류에 기인한다는 것을 알 수 있다.

결론적으로, MQTT 시스템의 보안은 프로토콜 명세를 지키는 것만으로는 충분하지 않다. 시스템의 보안 수준은 결국 사용된 브로커 소프트웨어 코드의 품질에 크게 좌우된다. 따라서 아키텍처 설계 단계에서의 보안 고려(TLS, 인증/인가)와 함께, 운영 단계에서의 지속적인 보안 관리(취약점 스캐닝, 패치 관리)가 동등하게 중요하다.

수백만 개의 디바이스가 동시에 연결되고 초당 수십만 건의 메시지를 처리해야 하는 대규모 IoT 시스템에서 단일 MQTT 브로커는 명백한 한계를 가진다. 이는 단일 장애점(Single Point of Failure, SPOF)이 될 뿐만 아니라, CPU, 메모리, 네트워크 대역폭 등 물리적 자원의 한계로 인해 성능 병목 현상을 유발한다. 따라서 실제 운영 환경에서는 여러 브로커 인스턴스를 묶어 클러스터(cluster)를 구성함으로써 확장성(Scalability)과 고가용성(High Availability)을 확보해야 한다.74

MQTT 브로커 클러스터링은 여러 브로커 노드가 협력하여 하나의 논리적인 브로커 서비스처럼 동작하게 하는 기술이다. 클러스터링 아키텍처는 크게 두 가지 방식으로 나눌 수 있다.

수백만 개의 동시 MQTT 연결을 안정적으로 처리하기 위해서는 브로커 소프트웨어의 성능뿐만 아니라, 그 기반이 되는 운영체제와 네트워크 스택의 성능을 극한까지 끌어올리는 튜닝 작업이 반드시 필요하다. 특히 Linux 환경에서 다음과 같은 커널 파라미터 튜닝이 일반적으로 수행된다.

이러한 시스템 수준의 튜닝은 MQTT 브로커가 하드웨어의 성능을 최대한 활용하여 대규모 트래픽을 안정적으로 처리할 수 있도록 하는 기반을 마련한다.

표 3: 오픈소스 MQTT 브로커 성능 벤치마크 요약

벤치마크 시나리오 성능 지표 EMQX (v4.4.16) Mosquitto (v2.0.15) 분석
Point-to-Point 메시지 처리율 (msg/s) 50,000 37,000 EMQX가 더 높은 처리율을 보이며, 대규모 1:1 통신에 강점을 나타냄.92
(50k 발행자, 50k 구독자) 평균 지연 시간 (ms) 1.58 353.82 Mosquitto는 높은 부하에서 지연 시간이 급격히 증가하여 성능 저하가 발생함.92
  평균 CPU 사용률 (%) 80% 6% EMQX는 더 많은 CPU 자원을 활용하여 높은 처리량을 달성하는 반면, Mosquitto는 자원 사용량이 낮지만 성능 한계에 부딪힘.92
Fan-out 메시지 처리율 (msg/s) 250,000 82,000 1:N 방송 시나리오에서 EMQX의 다중 코어 아키텍처가 압도적인 성능을 보임.92
(5 발행자, 1000 구독자/발행자) 평균 지연 시간 (ms) 1.99 12,240.83 Mosquitto는 Fan-out 부하가 증가하면 심각한 지연 시간 문제를 겪음.92
Shared Subscription 메시지 처리율 (msg/s) 50,000 40,000 (sub) 공유 구독을 통한 부하 분산 시나리오에서도 EMQX가 더 나은 성능을 유지함.92
(50k 발행자, 500 구독자 그룹) 평균 지연 시간 (ms) 1.47 12,723.07 Mosquitto는 높은 부하의 공유 구독 처리 시 지연 시간 문제가 발생함.92
Concurrent Connections 최대 동시 연결 수 1,000,000 1,000,000 두 브로커 모두 대규모 연결 수립이 가능하나, 자원 사용량에서 차이를 보임.92
(1M 연결, 5k cps) 평균 연결 지연 (ms) 2.4 5.74 EMQX가 더 빠른 연결 수립 속도를 보임.92
  안정화 시 메모리 (GB) 8.68 1.0 Mosquitto는 단일 스레드 아키텍처로 인해 메모리 사용량이 현저히 낮아, 자원이 제한된 환경에 유리함.92
아키텍처 및 확장성 클러스터링 내장 (Masterless) 미지원 (상용 버전에서 지원) EMQX는 오픈소스 버전에서 수평적 확장을 위한 클러스터링을 기본 지원하지만, Mosquitto는 단일 노드 운영에 초점을 맞춤.93

주: 위 벤치마크는 EMQ에서 수행한 결과이며, 특정 하드웨어 및 테스트 조건 하에서의 성능을 나타낸다. Mosquitto는 영속성(persistence)을 비활성화한 상태로 테스트되었다.92 실제 환경에서는 워크로드 특성과 구성에 따라 성능이 달라질 수 있다.

MQTT는 이론적 우수성을 넘어, 다양한 산업 현장에서 실질적인 가치를 창출하며 사실상의 표준(de facto standard)으로 자리매김하고 있다. 또한, 기술 생태계의 변화에 발맞춰 끊임없이 진화하며 그 적용 범위를 넓혀가고 있다.

산업용 사물 인터넷(Industrial Internet of Things, IIoT) 환경, 특히 스마트 팩토리에서는 수많은 종류의 장비(PLC, 센서, 로봇 등)와 상위 시스템(SCADA, MES, ERP) 간의 원활한 데이터 교환이 필수적이다. 하지만 MQTT 프로토콜 자체는 메시지 페이로드의 형식이나 토픽 네임스페이스의 구조를 강제하지 않기 때문에, 각기 다른 제조사의 장비나 시스템이 서로 다른 데이터 형식을 사용하게 되면 상호운용성(interoperability) 문제가 발생할 수 있다.95

이러한 문제를 해결하기 위해 이클립스 재단(Eclipse Foundation)의 Tahu 프로젝트를 통해 ‘Sparkplug’라는 명세가 등장했다.97 Sparkplug는 MQTT를 기반으로 IIoT 환경에 필요한 추가적인 규칙을 정의한 오픈소스 명세이다.

이처럼 MQTT와 Sparkplug B의 결합은 전통적인 SCADA 시스템을 현대화하고, OT(운영 기술)와 IT(정보기술)의 데이터를 완벽하게 통합하여 진정한 의미의 데이터 기반 스마트 팩토리를 구현하는 핵심 기술로 인정받고 있다.109

MQTT의 특성은 IIoT뿐만 아니라, 대규모의 이동성 객체와 도시 인프라를 연결하는 데에도 매우 적합하다.

MQTT는 현재의 성공에 안주하지 않고, 변화하는 기술 환경에 맞춰 지속적으로 진화하고 있다.

MQTT는 TCP/IP 네트워크를 전제로 하지만, 모든 IoT 디바이스가 TCP/IP 스택을 지원하는 것은 아니다. 특히 Zigbee, Bluetooth LE, LoRaWAN과 같은 저전력 단거리 무선 기술을 사용하는 센서 네트워크에서는 TCP/IP의 오버헤드가 부담스러울 수 있다.

TCP는 신뢰성 있는 전송을 보장하지만, 헤드 오브 라인 블로킹(Head-of-Line Blocking) 문제와 긴 연결 설정 시간(3-way handshake)이라는 고질적인 한계를 가지고 있다. 특히 네트워크 환경이 수시로 바뀌는 모바일 환경에서는 이러한 단점이 더욱 부각된다.

인공지능(AI), 특히 거대 언어 모델(LLM)의 발전은 IoT와 결합하여 AIoT(Artificial Intelligence of Things)라는 새로운 패러다임을 열고 있다. 이제는 단순히 데이터를 수집하고 제어하는 것을 넘어, AI가 실시간 데이터를 이해하고 자율적으로 판단하며 시스템과 상호작용하는 시대가 오고 있다.

이처럼 MQTT는 단순한 데이터 전송 수단을 넘어, 산업 표준(Sparkplug B), 비-IP 네트워크(MQTT-SN), 차세대 전송 기술(QUIC), 그리고 인공지능(MCP)과 결합하며 그 생태계를 확장하고 있다. 이는 MQTT가 단순한 프로토콜이 아니라, 현대 분산 시스템을 위한 근본적이고 다목적인 ‘서비스 버스(Service Bus)’로 진화하고 있음을 보여준다. MQTT의 핵심인 발행-구독 모델은 그 자체로 매우 근본적이고 유연하여, 다양한 영역의 특정 문제(산업 상호운용성, AI 통합 등)를 해결하기 위한 새로운 프로토콜과 명세들이 MQTT를 기반으로 구축되고 있다. MQTT는 ‘사물들의 TCP/IP’와 같은 역할을 하며, 더 높은 수준의 전문화된 통신 패턴이 구축될 수 있는 안정적이고 신뢰할 수 있는 기반이 되어가고 있다.

MQTT는 지난 20여 년의 세월 동안, 특정 산업의 요구를 해결하기 위해 탄생한 경량 원격 측정 프로토콜에서 시작하여, 오늘날 사물 인터넷(IoT)과 산업용 사물 인터넷(IIoT)을 아우르는 가장 지배적인 메시징 프로토콜이자 사실상의 표준(de facto standard)으로 확고히 자리매김했다. 이러한 성공의 핵심 동력은 기술적 정교함 이전에, ‘경량성’과 ‘효율성’이라는 명확한 목표, 그리고 ‘발행-구독’ 모델이 제공하는 강력하고 우아한 ‘분리(Decoupling)’의 설계 철학에 있다. 시공간적, 동기적 분리는 시스템 구성요소 간의 의존성을 제거함으로써 본질적으로 높은 확장성, 유연성, 그리고 회복탄력성을 갖춘 아키텍처를 가능하게 했다.

MQTT v5.0의 등장은 프로토콜이 단순한 데이터 전달자의 역할을 넘어, 대규모 엔터프라이즈 시스템의 복잡한 운영 요구사항을 수용할 수 있는 성숙한 메시징 프레임워크로 진화했음을 명확히 보여준다. 이유 코드, 세션 및 메시지 만료, 공유 구독, 사용자 속성과 같은 정교한 기능들은 시스템의 안정성, 디버깅 용이성, 그리고 상호운용성을 프로토콜 수준에서 보장하며, 개발자들이 더 높은 수준의 비즈니스 로직에 집중할 수 있는 토대를 마련해주었다.

그러나 MQTT의 성공적인 대규모 배포는 프로토콜 자체의 기능만으로 보장되지 않는다. 본 고찰에서 분석한 바와 같이, 견고한 보안 아키텍처의 구축은 필수적이다. TLS/SSL을 통한 전송 계층 암호화, 인증서 기반의 강력한 인증, 그리고 최소 권한 원칙에 입각한 세분화된 ACL 인가 정책은 다층적 방어 체계의 핵심이다. 또한, 수백만 동시 연결을 지원하기 위한 브로커 클러스터링 아키텍처(Active-Active/Passive)의 이해와 Linux 커널 및 네트워크 스택에 대한 깊이 있는 튜닝은 이론을 현실로 만드는 운영 기술의 정수라 할 수 있다.

미래를 향한 MQTT의 여정은 더욱 역동적이다. Sparkplug B 명세를 통해 IIoT 데이터의 의미론적 상호운용성을 확보하고, MQTT-SN을 통해 비-IP 기반의 저전력 센서 네트워크까지 그 영역을 확장하고 있다. 더 나아가, QUIC과 같은 차세대 전송 프로토콜을 수용하여 모바일 및 불안정한 네트워크 환경에서의 성능을 극대화하고, MCP와 같은 AI 시대의 프로토콜과 결합하여 단순한 데이터 파이프라인을 넘어 지능형 에이전트가 상호작용하는 지능형 서비스 버스로의 진화를 꾀하고 있다.

결론적으로, MQTT의 현재적 가치는 검증된 신뢰성과 효율성에 있으며, 그 미래적 가치는 끊임없이 확장되는 생태계와 변화하는 기술 패러다임을 수용하는 놀라운 적응성에 있다. MQTT는 앞으로도 다가올 초연결 시대의 수많은 디바이스와 시스템을 잇는 보이지 않는 신경망으로서, 그 중요성과 영향력을 더욱 확대해 나갈 것으로 전망된다.

  1. MQTT - 위키백과, 우리 모두의 백과사전, 8월 4, 2025에 액세스, https://ko.wikipedia.org/wiki/MQTT
  2. [Protocol]MQTT 기초 이론 (이 글 하나만 보면 됨) - Yonduroid - 티스토리, 8월 4, 2025에 액세스, https://dev-yangkj.tistory.com/7
  3. MQTT 설치 및 실행 가이드 - 경북대학교, 8월 4, 2025에 액세스, https://iot.knu.ac.kr/home/tech/CPL-TR-16-02-MQTT.pdf
  4. Azure Event Grid의 MQTT 브로커 기능 개요 - Microsoft Learn, 8월 4, 2025에 액세스, https://learn.microsoft.com/ko-kr/azure/event-grid/mqtt-overview
  5. (1) MQTT 란? - 시작은 미약하였으나 , 그 끝은 창대하리라 - 티스토리, 8월 4, 2025에 액세스, https://put-idea.tistory.com/35
  6. MQTT란 무엇인가요? - MQTT 프로토콜 설명 - AWS, 8월 4, 2025에 액세스, https://aws.amazon.com/ko/what-is/mqtt/
  7. 12 MQTT - Jeongchul Kim - 티스토리, 8월 4, 2025에 액세스, https://jeongchul.tistory.com/296
  8. MQTT 개념 및 특징 - 공대베짱이, 8월 4, 2025에 액세스, https://dejavuhyo.github.io/posts/mqtt-concept/
  9. IoT 환경에서 MQTT통신의 자원소모를 줄이기 위한 Publisher 송신 주기조절 방법.pdf - CHOSUN - 조선대학교, 8월 4, 2025에 액세스, https://oak.chosun.ac.kr/bitstream/2020.oak/16558/2/IoT%20%ED%99%98%EA%B2%BD%EC%97%90%EC%84%9C%20MQTT%ED%86%B5%EC%8B%A0%EC%9D%98%20%EC%9E%90%EC%9B%90%EC%86%8C%EB%AA%A8%EB%A5%BC%20%EC%A4%84%EC%9D%B4%EA%B8%B0%20%EC%9C%84%ED%95%9C%20Publisher%20%EC%86%A1%EC%8B%A0%20%EC%A3%BC%EA%B8%B0%EC%A1%B0%EC%A0%88%20%EB%B0%A9%EB%B2%95.pdf
  10. 와일드카드 - IBM, 8월 4, 2025에 액세스, https://www.ibm.com/docs/ko/SSWMAJ_2.0.0/com.ibm.ism.doc/Overview/ov00032.html?view=kc
  11. MQTT 주제 - AWS IoT Core, 8월 4, 2025에 액세스, https://docs.aws.amazon.com/ko_kr/iot/latest/developerguide/topics.html
  12. MQTT 실전 응용하기 - WildCard, 8월 4, 2025에 액세스, https://medium.com/@jspark141515/mqtt-%EC%8B%A4%EC%A0%84-%EC%9D%91%EC%9A%A9%ED%95%98%EA%B8%B0-wildcard-9643877262f2
  13. MQTT(Message Queueing Telemetry Transport) - 정보 보관소 - 티스토리, 8월 4, 2025에 액세스, https://blaxsior-repository.tistory.com/280
  14. MQTT 개념 (2) - wishlee Log - 티스토리, 8월 4, 2025에 액세스, https://wishlee0204.tistory.com/24
  15. [MQTT] MQTT의 개념 - 히진쓰의 서버사이드 기술 블로그, 8월 4, 2025에 액세스, https://khj93.tistory.com/entry/MQTT-MQTT%EC%9D%98-%EA%B0%9C%EB%85%90
  16. MQTT Protocol - All about IoT - HummingLab, 8월 4, 2025에 액세스, https://blog.humminglab.io/posts/mqtt-protocol/
  17. MQTT 클라이언트가 제공하는 서비스 품질 (QoS) - IBM, 8월 4, 2025에 액세스, https://www.ibm.com/docs/ko/ibm-mq/9.2.x?topic=concepts-qualities-service-provided-by-mqtt-client
  18. QoS 레벨 3: 사물인터넷에서 MQTT 프로토콜의 동기식 통신 메카니즘, 8월 4, 2025에 액세스, http://www.tkiee.org/kiee/XmlViewer/f404797
  19. MQTT QoS: Understanding Quality of Service - AssetWolf, 8월 4, 2025에 액세스, https://assetwolf.com/learn/mqtt-qos-understanding-quality-of-service
  20. mqtt-v5.0.html - MQTT Version 5.0 - OASIS Open, 8월 4, 2025에 액세스, https://docs.oasis-open.org/mqtt/mqtt/v5.0/mqtt-v5.0.html
  21. What is MQTT Quality of Service (QoS) 0,1, & 2? – MQTT Essentials: Part 6 - HiveMQ, 8월 4, 2025에 액세스, https://www.hivemq.com/blog/mqtt-essentials-part-6-mqtt-quality-of-service-levels/
  22. MQTT에 대하여 - 로봇스토리, 8월 4, 2025에 액세스, https://www.robotstory.co.kr/raspberry/?vid=37
  23. MQTT QoS Levels Explained with Example QoS 0 , 1, & 2 - Bevywise, 8월 4, 2025에 액세스, https://www.bevywise.com/blog/mqtt-qos-level-use/
  24. MQTT QoS 0, 1, 2 Explained: A Quickstart Guide EMQ - EMQX, 8월 4, 2025에 액세스, https://www.emqx.com/en/blog/introduction-to-mqtt-qos
  25. MQTT man page - Eclipse Mosquitto, 8월 4, 2025에 액세스, https://mosquitto.org/man/mqtt-7.html
  26. What is MQTT Last Will and Testament (LWT)? – MQTT Essentials …, 8월 4, 2025에 액세스, https://www.hivemq.com/blog/mqtt-essentials-part-9-last-will-and-testament/
  27. MQTT - AWS IoT Core, 8월 4, 2025에 액세스, https://docs.aws.amazon.com/ko_kr/iot/latest/developerguide/mqtt.html
  28. Generic MQTT Integration Guide (Last Will and Testament) - Documentation - Litmus, 8월 4, 2025에 액세스, https://docs.litmus.io/litmusedge/how-to-guides/integration-guides/generic-mqtt-tcp-lwt
  29. Retained Messages MQTT Broker - ThingsBoard, 8월 4, 2025에 액세스, https://thingsboard.io/docs/mqtt-broker/user-guide/retained-messages/
  30. What are Retained Messages in MQTT? – MQTT Essentials: Part 8, 8월 4, 2025에 액세스, https://www.hivemq.com/blog/mqtt-essentials-part-8-retained-messages/
  31. MQTT Retained Messages in the Unified Namespace (UNS) - i-flow, 8월 4, 2025에 액세스, https://i-flow.io/en/ressources/mqtt-retained-messages-in-the-unified-namespace-uns/
  32. MQTT Last Will and Testament - Lonely Binary, 8월 4, 2025에 액세스, https://lonelybinary.com/blogs/learn/mqtt-last-will-and-testament
  33. Understanding Persistent Sessions and Clean Sessions – MQTT Essentials: Part 7, 8월 4, 2025에 액세스, https://www.hivemq.com/blog/mqtt-essentials-part-7-persistent-session-queuing-messages/
  34. MQTT - The Standard for IoT Messaging, 8월 4, 2025에 액세스, https://mqtt.org/
  35. MQTT 5.0: 7 New Features and a Migration Checklist EMQ - EMQX, 8월 4, 2025에 액세스, https://www.emqx.com/en/blog/introduction-to-mqtt-5
  36. MQTT v5.0 versus v3.1.1 - wolfSSL, 8월 4, 2025에 액세스, https://www.wolfssl.com/mqtt-v5-0-versus-v3-1-1/
  37. Seven Reasons to Upgrade to it from MQTT 3.1.1 – MQTT 5 Essentials Part 3 - HiveMQ, 8월 4, 2025에 액세스, https://www.hivemq.com/blog/mqtt5-essentials-part3-upgrade-to-mqtt5-now/
  38. MQTT 5.0 Packets Explained: Coreflux MQTT v5.0, 8월 4, 2025에 액세스, https://www.coreflux.org/confidential-coreflux/mqtt-5-0-packets-explained
  39. Explore New Features of MQTT 5.0: Usage Examples Based on MQTTX CLI, 8월 4, 2025에 액세스, https://emqx.medium.com/explore-new-features-of-mqtt-5-0-usage-examples-based-on-mqttx-cli-a15055f210be
  40. Introduction to MQTT 5 and comparison with version 3.1 - Bevywise, 8월 4, 2025에 액세스, https://www.bevywise.com/blog/introduction-to-mqtt-5/
  41. User Properties - MQTT 5.0 New Features - DEV Community, 8월 4, 2025에 액세스, https://dev.to/emqx/user-properties-mqtt-50-new-features-2dnp
  42. MQTT v5 - New Features, Pros & Cons, Challenges - MobiDev, 8월 4, 2025에 액세스, https://mobidev.biz/blog/mqtt-5-protocol-features-iot-development
  43. MQTT Shared Subscriptions – MQTT 5 Essentials Part 7 - HiveMQ, 8월 4, 2025에 액세스, https://www.hivemq.com/blog/mqtt5-essentials-part7-shared-subscriptions/
  44. MQTT 3.1 vs MQTT 5: Should you upgrade? by Jayraj Roshan - IoTIFY, 8월 4, 2025에 액세스, https://blog.iotify.io/mqtt-3-1-vs-mqtt-5-should-you-upgrade-e891d71ae2c2
  45. MQTT Shared Subscriptions: Practical Guidelines and Use Cases MQTT 5 Features EMQ, 8월 4, 2025에 액세스, https://www.emqx.com/en/blog/introduction-to-mqtt5-protocol-shared-subscription
  46. MQTT Vs. HTTP for IoT - HiveMQ, 8월 4, 2025에 액세스, https://www.hivemq.com/blog/mqtt-vs-http-protocols-in-iot-iiot/
  47. Difference between MQTT and HTTP protocols - GeeksforGeeks, 8월 4, 2025에 액세스, https://www.geeksforgeeks.org/computer-networks/difference-between-mqtt-and-http-protocols/
  48. MQTT vs HTTP for IoT: Detailed Protocol Comparison - IoT For All, 8월 4, 2025에 액세스, https://www.iotforall.com/mqtt-vs-http-for-iot-detailed-protocol-comparison
  49. MQTT vs HTTP: Ultimate IoT Protocol Comparison Guide EMQ - EMQX, 8월 4, 2025에 액세스, https://www.emqx.com/en/blog/mqtt-vs-http
  50. MQTT vs HTTP request - General - Node-RED Forum, 8월 4, 2025에 액세스, https://discourse.nodered.org/t/mqtt-vs-http-request/98075
  51. CoAP vs MQTT: Which Protocol is Better for IoT? - Sirin Software, 8월 4, 2025에 액세스, https://sirinsoftware.com/blog/iot-protocols-mqtt-coap-xmpp-soap-upnp
  52. MQTT Vs CoAP for IoT - HiveMQ, 8월 4, 2025에 액세스, https://www.hivemq.com/blog/mqtt-vs-coap-for-iot/
  53. MQTT vs AMQP for IoT - HiveMQ, 8월 4, 2025에 액세스, https://www.hivemq.com/blog/mqtt-vs-amqp-for-iot/
  54. AMQP vs MQTT: Messaging protocols compared - CloudAMQP, 8월 4, 2025에 액세스, https://www.cloudamqp.com/blog/amqp-vs-mqtt.html
  55. A Comparison AMQP and MQTT - OASIS, 8월 4, 2025에 액세스, https://groups.oasis-open.org/HigherLogic/System/DownloadDocumentFile.ashx?DocumentFileKey=145346e2-5488-42dc-9aa0-ce9769e71ac9&forceDialog=0
  56. MQTT vs AMQP Svix Resources, 8월 4, 2025에 액세스, https://www.svix.com/resources/faq/mqtt-vs-amqp/
  57. MQTT vs AMQP: A Comparative Study on Performance - Wallarm, 8월 4, 2025에 액세스, https://lab.wallarm.com/what/mqtt-vs-amqp/
  58. MQTT vs AMQP for IoT Communications: Head to Head EMQ - EMQX, 8월 4, 2025에 액세스, https://www.emqx.com/en/blog/mqtt-vs-amqp-for-iot-communications
  59. MQTT vs Other IoT Messaging Protocols: Comparison & Use Cases - WebbyLab, 8월 4, 2025에 액세스, https://webbylab.com/blog/mqtt-vs-other-iot-messaging-protocols/
  60. Understanding IoT Connectivity: MQTT vs. AMQP - Back4App Blog, 8월 4, 2025에 액세스, https://blog.back4app.com/mqtt-vs-amqp/
  61. TLS/SSL - MQTT Security Fundamentals - HiveMQ, 8월 4, 2025에 액세스, https://www.hivemq.com/blog/mqtt-security-fundamentals-tls-ssl/
  62. What is MQTT? Definition of IoT Messaging Protocol - AWS, 8월 4, 2025에 액세스, https://aws.amazon.com/what-is/mqtt/
  63. Securing MQTT: Best Practices for a Robust IoT Ecosystem - Cirrus Link, 8월 4, 2025에 액세스, https://cirrus-link.com/securing-mqtt-best-practices-for-a-robust-iot-ecosystem/
  64. MQTT Protocol Explained: The Complete Guide Cedalo, 8월 4, 2025에 액세스, https://cedalo.com/blog/complete-mqtt-protocol-guide/
  65. Securing MQTT Systems - MQTT Security Fundamentals - HiveMQ, 8월 4, 2025에 액세스, https://www.hivemq.com/blog/mqtt-security-fundamentals-securing-mqtt-systems/
  66. Configure MQTT broker authentication - Azure IoT Operations Microsoft Learn, 8월 4, 2025에 액세스, https://learn.microsoft.com/en-us/azure/iot-operations/manage-mqtt-broker/howto-configure-authentication
  67. MQTT security - av - AirVantage Documentation - Sierra Wireless, 8월 4, 2025에 액세스, https://doc.airvantage.net/av/reference/hardware/protocols/mqtt-security/
  68. Security MQTT Broker - ThingsBoard, 8월 4, 2025에 액세스, https://thingsboard.io/docs/mqtt-broker/security/
  69. mosquitto.conf man page, 8월 4, 2025에 액세스, https://mosquitto.org/man/mosquitto-conf-5.html
  70. MQTT Security Best Practices & Implementation Guide - Bevywise, 8월 4, 2025에 액세스, https://www.bevywise.com/blog/mqtt-security-best-practices/
  71. Preventing MQTT Vulnerabilities Using IoT-Enabled Intrusion …, 8월 4, 2025에 액세스, https://pmc.ncbi.nlm.nih.gov/articles/PMC8779830/
  72. Search Results - CVE, 8월 4, 2025에 액세스, https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=mqtt
  73. MQTT-VET: Exploring MQTT Protocol Vulnerabilities Proceedings of the 13th Latin-American Symposium on Dependable and Secure Computing, 8월 4, 2025에 액세스, https://sol.sbc.org.br/index.php/ladc_estendido/article/view/34305/34096
  74. Exploring the Basics of MQTT Broker Clustering: An Introduction IoT For All, 8월 4, 2025에 액세스, https://www.iotforall.com/exploring-the-basics-of-mqtt-broker-clustering-an-introduction
  75. MQTT Broker: How It Works, Popular Options, and Quickstart EMQ - EMQX, 8월 4, 2025에 액세스, https://www.emqx.com/en/blog/the-ultimate-guide-to-mqtt-broker-comparison
  76. 16.2. Active-Passive Messaging Clusters - Red Hat Documentation, 8월 4, 2025에 액세스, https://docs.redhat.com/en/documentation/red_hat_enterprise_mrg/3/html/messaging_programming_reference/active-passive_messaging_clusters
  77. High Availability MQTT Cluster for Windows, Ubuntu, AWS, Azure - Bevywise, 8월 4, 2025에 액세스, https://www.bevywise.com/blog/high-availability-mqtt-cluster/
  78. Elevating MQTT Broker Availability and Inter-Broker Communication IoT For All, 8월 4, 2025에 액세스, https://www.iotforall.com/elevating-mqtt-broker-availability-with-inter-broker-communicator
  79. MQTT High Availability and Mosquitto Clustering Cedalo, 8월 4, 2025에 액세스, https://cedalo.com/mqtt-broker-pro-mosquitto/high-availability/
  80. Active-Active Vs. Active-Passive High-Availability Clustering JSCAPE, 8월 4, 2025에 액세스, https://www.jscape.com/blog/active-active-vs-active-passive-high-availability-cluster
  81. Raft Vs Gossip Protocol - Medium, 8월 4, 2025에 액세스, https://medium.com/@dhanyakrishnan8109/raft-vs-gossip-protocol-2c109fcd00f2
  82. High Availability Apache BifroMQ (Incubating) - Open source MQTT Broker, 8월 4, 2025에 액세스, https://bifromq.apache.org/docs/cluster/high_availability/
  83. High Availability BifroMQ.io - Multi-tenancy MQTT Broker, 8월 4, 2025에 액세스, https://bifromq.io/docs/operations/high_availability/
  84. comqtt/cluster/README.md at main - GitHub, 8월 4, 2025에 액세스, https://github.com/wind-c/comqtt/blob/main/cluster/README.md
  85. Re: [mosquitto-dev] Mosquitto increasing maximum connection limit - Eclipse, 8월 4, 2025에 액세스, https://www.eclipse.org/lists/mosquitto-dev/msg01411.html
  86. Tuning Guide - Erlang MQTT Broker 1.0 documentation, 8월 4, 2025에 액세스, https://emqtt.io/docs/v1/tune.html
  87. Tuning Guide - EMQ X Enterprise Documentation, 8월 4, 2025에 액세스, https://ee-doc-en.readthedocs.io/zh/latest/tune.html
  88. High Volume Incoming Connections. Linux Kernel Tuning for High… - Level Up Coding, 8월 4, 2025에 액세스, https://levelup.gitconnected.com/linux-kernel-tuning-for-high-performance-networking-high-volume-incoming-connections-196e863d458a
  89. Tuning Guide - Erlang MQTT Broker 1.0 documentation, 8월 4, 2025에 액세스, https://emqtt.io/docs/tune.html
  90. On MQTT Scalability in the Internet of Things: Issues, Solutions, and Future Directions, 8월 4, 2025에 액세스, https://www.researchgate.net/publication/371863086_On_MQTT_Scalability_in_the_Internet_of_Things_Issues_Solutions_and_Future_Directions
  91. Optimizing Web Servers for High Throughput and Low Latency - NGINX Community Blog, 8월 4, 2025에 액세스, https://blog.nginx.org/blog/optimizing-web-servers-for-high-throughput-and-low-latency
  92. blog/en/202304/open-mqtt-benchmarking-comparison-emqx-vs-mosquitto.md at main, 8월 4, 2025에 액세스, https://github.com/emqx/blog/blob/main/en/202304/open-mqtt-benchmarking-comparison-emqx-vs-mosquitto.md
  93. HiveMQ vs. Mosquitto: An MQTT Broker Comparison, 8월 4, 2025에 액세스, https://www.hivemq.com/blog/hivemq-vs-mosquitto-an-mqtt-broker-comparison/
  94. Comparison of Open Source MQTT Brokers 2024 EMQ - EMQX, 8월 4, 2025에 액세스, https://www.emqx.com/en/blog/a-comprehensive-comparison-of-open-source-mqtt-brokers-in-2023
  95. Industrial-Strength MQTT Sparkplug B - Elastel, 8월 4, 2025에 액세스, https://www.elastel.com/solution/mqtt-sparkplug-b/
  96. IOT Architecture with MQTT Sparkplug(B) - ISA Interchange, 8월 4, 2025에 액세스, https://blog.isa.org/iot-architecture-with-mqtt-sparkplugb
  97. Sparkplug B EMQX Docs, 8월 4, 2025에 액세스, https://docs.emqx.com/en/emqx/latest/data-integration/sparkplug.html
  98. The Sparkplug Specification The Eclipse Foundation, 8월 4, 2025에 액세스, https://sparkplug.eclipse.org/specification/
  99. Understanding MQTT Sparkplug Topic Namespace in IIoT Architectures - HiveMQ, 8월 4, 2025에 액세스, https://www.hivemq.com/blog/understanding-mqtt-topic-namespace-iiot/
  100. Enhancing IIoT Interoperability through MQTT Message Standardization with Sparkplug and OPCRouter by ca Medium, 8월 4, 2025에 액세스, https://akpolatcem.medium.com/enhancing-iiot-interoperability-through-mqtt-message-standardization-with-sparkplug-7a5827078d93
  101. What is Sparkplug B (Pros and Cons, in simple words) - i-flow, 8월 4, 2025에 액세스, https://i-flow.io/en/ressources/what-is-sparkplug-b-pros-and-cons-of-the-standard/
  102. Sparkplug B Specification(Spec) support - the Tempus Cloud Documentation, 8월 4, 2025에 액세스, https://tempus.readthedocs.io/en/latest/api/sparkplug.html
  103. MQTT Sparkplug Specification - Inductive Automation, 8월 4, 2025에 액세스, https://inductiveautomation.com/resources/video/mqtt-sparkplug-specification
  104. Unified Namespace: How Sparkplug B Revolutionized Modern Manufacturing, 8월 4, 2025에 액세스, https://corsosystems.com/posts/unified-namespace-how-sparkplug-b-revolutionized-modern-manufacturing
  105. How unified namespace drives efficiency, quality in manufacturing - Control Engineering, 8월 4, 2025에 액세스, https://www.controleng.com/how-unified-namespace-drives-efficiency-quality-in-manufacturing/
  106. Semantic Data Structuring with MQTT Sparkplug and Unified Namespace - HiveMQ, 8월 4, 2025에 액세스, https://www.hivemq.com/blog/semantic-data-structuring-mqtt-sparkplug-unified-namespace-uns-smart-manufacturing/
  107. What is Unified Namespace (UNS) and Why Does it Matter? - HiveMQ, 8월 4, 2025에 액세스, https://www.hivemq.com/blog/what-is-unified-namespace-uns-iiot-industry-40/
  108. Unified Namespace: What is UNS? (Examples and Tips) - Clarify, 8월 4, 2025에 액세스, https://www.clarify.io/learn/unified-namespace-uns
  109. A Comparison of OPC UA and MQTT Sparkplug - HiveMQ, 8월 4, 2025에 액세스, https://www.hivemq.com/resources/iiot-protocols-opc-ua-mqtt-sparkplug-comparison/
  110. MQTT - Invented for SCADA, Adopted by IT, Solving Digital Transformation Today, 8월 4, 2025에 액세스, https://inductiveautomation.com/resources/icc/2021/mqtt-invented-for-scada-adopted-by-it-solving-digital-transformation-today
  111. MQTT in Manufacturing Applications: Connecting the Factory Floor to the Enterprise - shoplogix, 8월 4, 2025에 액세스, https://shoplogix.com/mqtt-in-manufacturing-applications/
  112. Why MQTT Is Essential for Building Connected Cars - IoT For All, 8월 4, 2025에 액세스, https://www.iotforall.com/why-mqtt-essential-connected-cars
  113. Building New Connected Car Features on the Back of a Robust Connectivity Platform, 8월 4, 2025에 액세스, https://www.hivemq.com/blog/build-new-connected-car-features-on-connectivity-platform-with-mqtt/
  114. MQTT in Connected Cars: Key Benefits and Real-World Applications EMQ - EMQX, 8월 4, 2025에 액세스, https://www.emqx.com/en/blog/mqtt-for-internet-of-vehicles
  115. Driving Innovation: Rimac’s Connected Cars Leverage HiveMQ’s MQTT for Automotive Excellence, 8월 4, 2025에 액세스, https://www.hivemq.com/case-studies/rimac/
  116. How Reply Built a Connected Vehicle Platform with AWS IoT and Amazon Alexa, 8월 4, 2025에 액세스, https://aws.amazon.com/blogs/apn/how-reply-built-a-connected-vehicle-platform-with-aws-iot-and-amazon-alexa/
  117. MQTT-Powered Smart Cities Optimize Your City - HiveMQ, 8월 4, 2025에 액세스, https://www.hivemq.com/solutions/smart-cities/
  118. A Review of Emerging Technologies for IoT-Based Smart Cities - PMC - PubMed Central, 8월 4, 2025에 액세스, https://pmc.ncbi.nlm.nih.gov/articles/PMC9740315/
  119. Security Analysis of the MQTT-SN Protocol for the Internet of Things - MDPI, 8월 4, 2025에 액세스, https://www.mdpi.com/2076-3417/12/21/10991
  120. MQTT Specification, 8월 4, 2025에 액세스, https://mqtt.org/mqtt-specification/
  121. MQTT - Wikipedia, 8월 4, 2025에 액세스, https://en.wikipedia.org/wiki/MQTT
  122. Introduction to MQTT-SN (MQTT for Sensor Networks) - Steve’s Internet Guide, 8월 4, 2025에 액세스, http://www.steves-internet-guide.com/mqtt-sn/
  123. Differences between MQTT and MQTT-SN - Internet of Things for Architects [Book], 8월 4, 2025에 액세스, https://www.oreilly.com/library/view/internet-of-things/9781788470599/881de410-96e1-4771-b506-cd7450faadc3.xhtml
  124. When MQTT-SN should be used? How is it different from MQTT? - Stack Overflow, 8월 4, 2025에 액세스, https://stackoverflow.com/questions/27560549/when-mqtt-sn-should-be-used-how-is-it-different-from-mqtt
  125. MQTT-SN: The Smart Choice for IIoT - HiveMQ, 8월 4, 2025에 액세스, https://www.hivemq.com/blog/mqtt-sn-smart-choice-for-iiot/
  126. Exploring MQTT-SN: A Comprehensive Guide EMQ - EMQX, 8월 4, 2025에 액세스, https://www.emqx.com/en/blog/connecting-mqtt-sn-devices-using-emqx
  127. 1월 1, 1970에 액세스, https://mqtt.org/new/wp-content/uploads/2009/06/MQTT-SN_spec_v1.2.pdf
  128. MQTT-SN (MQTT For Sensor Networks) - High Voltages, 8월 4, 2025에 액세스, https://highvoltages.co/iot-internet-of-things/mqtt/mqtt-sn/
  129. MQTT-SN architecture and topology - Internet of Things for Architects [Book] - O’Reilly Media, 8월 4, 2025에 액세스, https://www.oreilly.com/library/view/internet-of-things/9781788470599/7080abaf-f3f4-4d67-afe6-54baa7af0b00.xhtml
  130. MQTT over QUIC: Next-Generation IoT Standard Protocol EMQ - EMQX, 8월 4, 2025에 액세스, https://www.emqx.com/en/blog/mqtt-over-quic
  131. MQTT Over QUIC: The Next-Generation IoT Standard Protocol, 8월 4, 2025에 액세스, https://www.iotforall.com/mqtt-over-quic-next-generation-iot-standard-protocol
  132. MQTT Trends for 2025 and Beyond: Powering the Future of AI and IoT - EMQ Technologies, 8월 4, 2025에 액세스, https://emqx.medium.com/mqtt-trends-for-2025-and-beyond-powering-the-future-of-ai-and-iot-ec47a089702c
  133. Shaping the Future of IoT: 7 MQTT Technology Trends in 2023 EMQ, 8월 4, 2025에 액세스, https://www.emqx.com/en/blog/7-mqtt-trends-in-2023
  134. EMQ Becomes OASIS Open’s Newest Foundational Sponsor, 8월 4, 2025에 액세스, https://www.oasis-open.org/2022/02/18/emq-becomes-oasis-open-newest-foundational-sponsor/
  135. MQTT over QUIC EMQX Docs, 8월 4, 2025에 액세스, https://docs.emqx.com/en/emqx/latest/mqtt-over-quic/introduction.html
  136. Introduction - Model Context Protocol, 8월 4, 2025에 액세스, https://modelcontextprotocol.io/introduction
  137. MQTTX + MCP: Enhancing MQTT Toolbox with AI Capabilities EMQ - EMQX, 8월 4, 2025에 액세스, https://www.emqx.com/en/blog/enhancing-mqtt-toolbox-with-ai-capabilities
  138. emqx/aiot-mcp-server: AIoT Model Context Protocol Server - GitHub, 8월 4, 2025에 액세스, https://github.com/emqx/aiot-mcp-server/
  139. EMQX MCP: Manage & Control MQTT Brokers with Ease, 8월 4, 2025에 액세스, https://mcpmarket.com/server/emqx