CoAP와 MQTT: IoT를 위한 경량 프로토콜의 모든 것

by300BW • • 2 min read
0


개요

사물인터넷(IoT)에서는 네트워크 자원이 제한된 장치들이 데이터를 주고받기 위해 특화된 경량 통신 프로토콜을 사용합니다. 그 중 대표적인 것이 CoAP(Constrained Application Protocol)과 MQTT(Message Queuing Telemetry Transport)입니다. CoAP는 저전력 센서나 임베디드 기기를 염두에 두고 IETF에서 개발한 경량 웹 전송 프로토콜이고, MQTT는 IBM이 시작하여 OASIS에서 표준화한 경량 메시지 큐잉 프로토콜로 퍼블리시/구독(pub/sub) 방식의 통신을 제공합니다 (MQTT Vs CoAP for IoT) (8 IoT Protocols and Standards Worth Exploring in 2024 | EMQ). 두 프로토콜 모두 작은 메시지 크기와 낮은 오버헤드로 신뢰성 있는 데이터 전송을 목표로 하지만, 아키텍처와 동작 방식에서 큰 차이점이 있습니다 (MQTT Vs CoAP for IoT) (MQTT vs Other IoT Messaging Protocols: Comparison & Use Cases). 본 보고서에서는 CoAP와 MQTT의 개념, 아키텍처, 메시지 구조, QoS, 보안, 장단점, 활용 사례를 A부터 Z까지 포괄적으로 설명하고, IoT 환경에서의 사용 비교와 프로토콜 선택 기준을 제시합니다.

CoAP: 콘스트레인드 애플리케이션 프로토콜

개념 및 특징

CoAP는 **“제한된 환경을 위한 응용 프로토콜”**이라는 이름 그대로, 리소스가 제한된(low-power, low-bandwidth) IoT 장치를 인터넷에 연결하기 위해 설계된 특수화된 경량 프로토콜입니다 (CoAP Protocol: Key Features, Use Cases, and Pros/Cons | EMQ). 2014년 IETF의 CoRE(Constrained RESTful Environments) 워킹그룹에 의해 RFC 7252로 표준화되었으며 (A Field Guide to CoAP — Part 1. Everything related to the Constrained… | by Jonathan Beri | Medium) ([

            RFC 7252 - The Constrained Application Protocol (CoAP)
        
    ](https://datatracker.ietf.org/doc/html/rfc7252#:~:text=Title%20The%20Constrained%20Application%20Protocol,errata%20%20%20Report%20errata)), **HTTP의 설계 철학**을 따르면서도 **멀티캐스트 지원**, **매우 낮은 오버헤드**, **단순성** 등 IoT를 위한 요구사항을 충족하도록 만들어졌습니다 ([
        
            RFC 7252 - The Constrained Application Protocol (CoAP)
        
    ](https://datatracker.ietf.org/doc/html/rfc7252#:~:text=This%20document%20specifies%20the%20Constrained,simplicity%20for%20constrained%20environments%20and)). CoAP는 **UDP를 전송 계층으로 사용하는 클라이언트/서버 프로토콜**로서, 인터넷 표준인 **REST 아키텍처**를 적용하여 **자원(Resource)** 지향의 통신 모델을 채택하고 있습니다 ([MQTT Vs CoAP for IoT](https://www.hivemq.com/blog/mqtt-vs-coap-for-iot/#:~:text=device%20state%2C%20but%20devices%20can,and%20servers%20in%20multiple%20languages)) ([CoAP Protocol: Key Features, Use Cases, and Pros/Cons | EMQ](https://www.emqx.com/en/blog/coap-protocol#:~:text=RESTful%20Architecture)). 다시 말해, CoAP에서는 온도 센서의 측정값이나 LED의 상태와 같은 데이터를 URI로 식별되는 리소스로 표현하며, **클라이언트는 서버의 URI에 대하여 GET, POST, PUT, DELETE 등의 메서드로 요청**을 보내고 **서버는 응답**을 반환하는 형식입니다 ([MQTT Vs CoAP for IoT](https://www.hivemq.com/blog/mqtt-vs-coap-for-iot/#:~:text=CoAP%20,implemented%20in%20CoAP.%20On)) ([CoAP Protocol: Key Features, Use Cases, and Pros/Cons | EMQ](https://www.emqx.com/en/blog/coap-protocol#:~:text=CoAP%20uses%20a%20RESTful%20,using%20a%20standard%2C%20uniform%20interface)). 이러한 동작은 HTTP와 유사하기 때문에 **개발자들에게 친숙**하며, CoAP 메시지는 간단한 프록시를 통해 HTTP로 **변환하여 웹과 통합**할 수도 있습니다 ([MQTT Vs CoAP for IoT](https://www.hivemq.com/blog/mqtt-vs-coap-for-iot/#:~:text=designed%20for%20the%20Internet%20of,implemented%20in%20CoAP.%20On)) ([MQTT and CoAP: Underlying Protocols for the IoT | Electronic Design](https://www.electronicdesign.com/technologies/communications/iot/article/21800998/silicon-labs-mqtt-and-coap-underlying-protocols-for-the-iot#:~:text=operating%20in%20a%20constrained%20environment,natively%20compatible%20to%20the%20Internet)).

CoAP의 핵심 특징을 정리하면 다음과 같습니다:

아키텍처와 동작 방식

CoAP는 클라이언트-서버 모델로 동작하며, 한 장치가 동시에 서버이면서 클라이언트가 될 수도 있는 유동적인 구조입니다 (MQTT Vs CoAP for IoT). 즉, 어떤 IoT 장치는 센서 데이터 자원을 제공하는 CoAP 서버로 동작하면서 다른 장치의 자원에 요청을 보내는 클라이언트 역할도 할 수 있습니다. 통신은 요청 메시지와 응답 메시지 교환으로 이루어지며, CoAP 서버는 특정 URI에 자원을 노출하고 클라이언트는 해당 URI에 메시지를 전송합니다. 예를 들어, 온도 센서가 coap://sensor1.local/temp라는 자원을 제공하면, 클라이언트는 그 URI에 GET 요청을 보내 온도 값을 조회하고, 서버는 측정값을 응답으로 보내는 식입니다.

(MQTT Vs CoAP for IoT) 장치 내 CoAP 서버와 두 개의 CoAP 클라이언트 간에 요청/응답을 주고받는 구조. CoAP에서는 디바이스 CoAP 서버가 자신의 상태를 URI 자원으로 노출하고, 클라이언트들이 해당 URI로 GET 요청을 보내면 서버가 **응답(Response)**으로 데이터를 전달합니다. 이러한 1:1 요청-응답 모델이 CoAP 통신의 기본입니다 (MQTT Vs CoAP for IoT). 또한 CoAP는 UDP상에서 동작하므로 연결 설정(handshake) 없이 바로 메시지를 주고받으며, HTTP 대비 왕복 지연이 적고 네트워크 부담이 낮습니다.

CoAP 메시지 교환 시, 메시지 타입과 ID를 통해 신뢰성 및 중복 검출을 처리합니다. CoAP에는 네 가지 메시지 타입이 있는데: Confirmable(CON), Non-confirmable(NON), Acknowledgement(ACK), **Reset(RST)**가 그것입니다 (MQTT Vs CoAP for IoT). 일반적인 요청은 보통 Confirmable로 보내며, 이 경우 수신 측은 ACK 메시지로 수신 확인을 해줍니다. 만약 응답 데이터를 바로 준비할 수 있다면 ACK와 응답을 한 번에(piggyback) 보낼 수도 있고, 시간이 걸린다면 일단 빈 ACK를 보내고 나중에 별도의 응답(CON) 메시지를 보낼 수도 있습니다. Non-confirmable 메시지는 ACK를 요구하지 않는 타입으로, 주로 중요하지 않은 정보나 주기적 메시지에 사용됩니다. 예를 들어 NON 타입의 센서 데이터 업데이트는 손실되어도 재전송하지 않으며, 이는 MQTT의 QoS 0 (최소 한 번 전달 보장 없음)과 유사한 동작입니다 (MQTT Vs CoAP for IoT). 수신 측은 메시지를 처리할 수 없을 때 Reset(RST) 메시지로 거부할 수 있고, 송신 측은 메시지 ID를 통해 중복된 메시지인지 판별하여 중복 수신 시 무시합니다 (MQTT Vs CoAP for IoT). CoAP 서버 리소스 디스커버리는 관례적으로 GET coap://[host]/.well-known/core 요청을 통해 수행되며, 서버는 지원하는 리소스들의 URI 목록을 응답으로 제공합니다 (MQTT Vs CoAP for IoT). 이와 같이 CoAP는 **HTTP의 핵심 웹 개념(리소스, 메서드)**을 재사용하면서, IoT에 필요한 경량 메시징 모델로 최적화되어 있습니다 (MQTT Vs CoAP for IoT).

메시지 구조

CoAP의 메시지 포맷은 작고 고정된 헤더와 확장 가능한 옵션 영역, 페이로드로 구성됩니다. CoAP 헤더는 단 4바이트로 되어 있는데, 내용은 다음과 같습니다:

  • 1바이트: 버전(2비트) + 타입(T, 2비트) + 토큰 길이(4비트) – 프로토콜 버전(현재 1), 메시지 타입(CON/NON/ACK/RST), 그리고 뒤따르는 토큰(Token)의 길이를 나타냅니다 (토큰은 요청과 응답 매칭에 사용되는 식별자).

  • 1바이트: 코드(Code) – 이 메시지가 요청인지 응답인지와 구체적인 메서드/응답 코드를 담습니다. 예를 들어, 0.01은 GET 요청, 0.02는 POST 요청, 2.05는 콘텐츠(Content) 응답, 4.04는 Not Found 응답을 의미합니다. (CoAP의 코드 값은 HTTP의 상태코드와 유사한 개념입니다).

  • 2바이트: 메시지 ID – 송신 측에서 각 메시지에 부여하는 식별용 ID로, ACK 매칭 및 중복 검출에 사용됩니다.

이 헤더 다음에는 가변 길이의 **토큰(Token)**이 오며 (0~8바이트, 토큰 길이는 헤더에 명시), 그 뒤로 **옵션(Option)**들이 연속해서 붙습니다 (A Field Guide to CoAP — Part 1. Everything related to the Constrained… | by Jonathan Beri | Medium). 옵션은 각종 부가 정보를 담기 위해 존재하며, 예를 들어 Uri-Path, Content-Format, Observe, Block 등의 옵션이 숫자 코드를 가지며 필요할 때 포함됩니다. CoAP 옵션은 델타 인코딩과 가변 길이 표현으로 효율적으로 압축되어 삽입됩니다. 옵션들이 끝나면, 만약 페이로드가 있을 경우 0xFF 바이트의 페이로드 마커 이후에 임의의 바이트열이 페이로드로 붙습니다.

이러한 구조 덕분에 CoAP 메시지는 필요한 정보만 담아 매우 작게 유지될 수 있습니다. 최소 오버헤드 4바이트로 시작하므로, 간단한 NON 메시지는 IP/UDP 헤더를 포함해도 수십 바이트 수준이며, RFC 7252에서는 특별한 사전 정보가 없다면 1152바이트 이하로 보내도록 권고하고 있습니다 (MQTT Vs CoAP for IoT). 물론 더 큰 데이터는 블록(Block) 옵션을 사용해 여러 개의 메시지로 분할 전송할 수 있습니다 (MQTT Vs CoAP for IoT) (MQTT vs Other IoT Messaging Protocols: Comparison & Use Cases). 이 Block-wise 전송 메커니즘을 통해 CoAP는 큰 파일이나 펌웨어 전송도 가능하지만, 일반적으로는 짧은 센서값/제어명령 위주로 활용되어 단일 패킷으로 통신하는 경우가 많습니다.

QoS와 신뢰성 보장 메커니즘

CoAP는 전송 품질(QoS) 측면에서 옵션형 신뢰성 보장을 제공합니다. 앞서 언급한 Confirmable(CON) 메시지를 통해 메시지 전달에 대한 확인과 재전송이 구현됩니다 (CoAP Protocol: Key Features, Use Cases, and Pros/Cons | EMQ). 송신 측에서 CON 메시지를 보내고 일정 시간 내 ACK 응답을 받지 못하면, 해당 메시지를 지수적으로 증가하는 간격으로 재시도하며, 일정 횟수 시도 후에도 실패하면 전송을 포기합니다 (MQTT Vs CoAP for IoT). 이러한 방식으로 CoAP는 네트워크가 손실이 있더라도 일정 수준의 신뢰성을 확보합니다 (CoAP Protocol: Key Features, Use Cases, and Pros/Cons | EMQ). 반면 Non-confirmable(NON) 메시지는 응답을 요구하지 않으므로 재전송을 하지 않고, 필요에 따라 주기적으로 같은 데이터를 보내도록 응용에서 설계할 수 있습니다 (MQTT vs Other IoT Messaging Protocols: Comparison & Use Cases). 예컨대, 온도센서가 1분마다 NON 타입으로 측정값을 보내도록 하여 몇 개 손실되더라도 최신값이 곧 도달하게 할 수 있습니다.

QoS라는 용어는 MQTT에서 세 가지 등급(QoS 0,1,2)으로 잘 알려져 있지만, CoAP에서는 CON/NON 두 가지 전송 모드로 그 개념을 제공한다고 볼 수 있습니다 (MQTT Vs CoAP for IoT). **MQTT의 QoS 0 (최소보장 없음)**에 대응되는 것이 CoAP NON, **QoS 1 (최소 1회 전달)**에 대응되는 것이 CoAP CON 메시지입니다 (MQTT Vs CoAP for IoT). (MQTT QoS 2에 해당하는 중복 없이 정확히 한 번 전달은 TCP 및 어플리케이션 레벨에서 추가 처리가 필요하여 CoAP 표준에는 직접적인 대응은 없습니다.)

CoAP의 중요한 비동기 확장으로 Observe(관찰) 옵션이 있습니다 (MQTT Vs CoAP for IoT). Observe는 클라이언트가 특정 리소스에 대해 “구독”을 하는 기능으로, **서버는 해당 리소스 상태가 변할 때마다 자동으로 알림을 보내줍니다】 (MQTT Vs CoAP for IoT). 이를 통해 마치 MQTT같이 이벤트 기반의 푸시를 구현할 수 있습니다. 예를 들어 클라이언트가 센서의 /temperature 리소스를 Observe하면, 이후 온도 변화가 생길 때마다 서버가 별도의 응답 메시지들을 지속적으로 전송하여 업데이트를 알려줍니다.

(MQTT Vs CoAP for IoT) CoAP Observe 확장을 통한 서버→클라이언트 푸시 알림 구조. 클라이언트가 서버 리소스에 Observe 요청을 보내두면, 서버는 해당 자원의 상태가 변경될 때마다 갱신된 응답을 푸시하여 통보합니다. 이렇게 CoAP도 브로커 없이 1:다 실시간 알림을 제공할 수 있지만, 이 경우에도 각 알림은 CON 또는 NON 메시지 형태로 전달되어 신뢰성 확보는 CoAP 프로토콜 수준에서 관리됩니다 (MQTT Vs CoAP for IoT).

보안 방식

IoT 환경에서 보안은 필수적이며, CoAP는 DTLS(Datagram TLS)를 통해 전송 계층 보안을 제공합니다. CoAP 자체는 UDP 상에서 동작하므로 TLS(SSL) 대신 DTLS를 적용하여 패킷을 암호화하고 무결성을 검증할 수 있습니다 (MQTT Vs CoAP for IoT) (MQTT and CoAP: Underlying Protocols for the IoT | Electronic Design). 보안이 적용된 CoAP는 흔히 CoAPS로 불리며, 기본 포트 번호 5684를 사용합니다 (비보안 CoAP는 UDP 5683 포트) (MQTT Vs CoAP for IoT). DTLS는 TLS와 거의 동일한 보안 강도를 제공하며 X.509 인증서, PSK(사전 공유 키) 등의 인증 방식을 지원합니다. 다만 TLS handshake 과정이 비교적 무겁고 지연을 유발하기 때문에, 배터리 소모를 줄이기 위해 필요 시 페이로드 암호화만 적용하는 경량화 전략도 논의됩니다 (MQTT and CoAP: Underlying Protocols for the IoT | Electronic Design).

CoAP 보안의 또 다른 방법으로는 **OSCORE(Object Security for Constrained Environments)**가 있습니다. 이는 메시지 레벨에서 암호화를 수행하는 방식으로, 중간 노드들을 거치더라도 엔드-투-엔드 보안을 보장하는 새로운 표준입니다. OSCORE는 CoAP 패킷의 중요한 부분을 COSE 객체로 암호화하여, 중간의 프록시 등을 신뢰하지 않아도 종단간 기밀성과 인증을 확보합니다. (OSCORE는 2019년에 RFC 8613으로 표준화되었습니다.)

전반적으로, CoAP는 경량 DTLS 보안 프로파일을 통해 IoT 환경에서 실용적인 보안을 제공하며, IPsec과의 연동도 옵션으로 고려되고 있습니다 ([

            RFC 7252 - The Constrained Application Protocol (CoAP)
        
    ](https://datatracker.ietf.org/doc/html/rfc7252#:~:text=no%20security%20to%20certificate,CoAP)). 개발 시에는 mbedTLS, OpenSSL의 DTLS 기능이나 **TinyDTLS** 같은 경량 구현을 사용하여 CoAP 통신을 암호화할 수 있습니다.

주요 장점

주요 단점

  • TCP의 부재로 인한 제한된 신뢰성: UDP 기반의 CoAP는 TCP처럼 순서보장, 스트림 전송을 제공하지 않으므로 큰 데이터를 전송하거나 엄밀한 메시지 순서 제어가 어렵습니다. 신뢰성은 재전송 메커니즘으로 일부 확보하지만, **엄격한 “한 번만 전달” 보장(QoS2 수준)**은 내장되어 있지 않습니다. 또한 UDP 패킷 분실 시 개별 메시지 수준에서 처리하므로, TCP처럼 자동으로 모든 데이터 스트림을 재조립해주지 않습니다. 이로 인해 대용량 데이터의 전송시 자체적으로 분할/재조립 처리를 구현해야 하고 (MQTT Vs CoAP for IoT), 패킷 손실률이 높을 경우 MQTT에 비해 성능이 떨어질 수 있습니다 (다만 IoT 센서 데이터는 작고 중요도 낮은 것들이 많아 문제되지 않는 경우도 많습니다).

  • NAT 통과 및 방화벽 문제: CoAP는 UDP를 사용하기 때문에 일반적으로 방화벽 관통이 MQTT보다 어려울 수 있습니다 (MQTT Vs CoAP for IoT). 많은 방화벽이 UDP 트래픽을 제한하거나 차단하고, NAT 환경에서도 사설망 안의 CoAP 서버에 외부에서 접근하기 까다롭습니다 (CoAP Protocol: Key Features, Use Cases, and Pros/Cons | EMQ). MQTT는 1883 포트 하나로 통신하거나 WebSocket을 사용하여 브라우저 호환을 도모할 수 있지만, CoAP는 웹과 다소 달라 HTTP 프록시를 직접 이용하지 않는 한 인터넷에서 접근이 어려울 수 있습니다. 인터넷에 직접 노출된 CoAP 서버는 UDP 특성상 IP 스푸핑을 통한 DDoS 공격에 악용될 위험도 지적됩니다 (MQTT Vs CoAP for IoT).

  • 중앙 브로커 부재로 인한 기능 부족: MQTT의 경우 브로커가 자동으로 제공하는 큐잉, 보존(retain) 메시지, 라스트 윌(LWT) 등의 부가서비스가 있지만, CoAP는 그런 중앙 노드 없이 분산 구조로 동작하므로 이러한 기능들을 응용 계층에서 직접 구현해야 합니다 (MQTT Vs CoAP for IoT). 예를 들어, MQTT 브로커는 오프라인된 노드의 구독 메시지를 보관했다가 나중에 전달해줄 수 있지만 (MQTT Vs CoAP for IoT) (MQTT Vs CoAP for IoT), CoAP는 서버가 직접 클라이언트를 기억하고 재전송해주지 않는 한 오프라인 노드에 메시지 전달 보류 같은 개념이 없습니다. 필요하다면 중간 게이트웨이나 프록시 서버를 두어 유사 브로커 역할을 하도록 아키텍처를 설계해야 합니다. 이 점은 대규모 시스템 구축 시 CoAP만으로는 불편함을 느낄 수 있는 부분입니다.

  • 상대적으로 성숙도 부족: MQTT에 비해 CoAP는 산업계 도입과 커뮤니티 지원이 적은 편입니다. MQTT는 수십년간 사용되어 온 반면 CoAP는 비교적 최근(2010년대)에 등장하여 개발 자료나 상용 플랫폼 지원이 아직 적습니다 (CoAP Protocol: Key Features, Use Cases, and Pros/Cons | EMQ). 개발자를 위한 예제나 문서도 MQTT만큼 풍부하지 않을 수 있습니다. 그러나 상황은 개선되고 있으며, 점차 CoAP도 구현체와 사용 사례가 누적되어 가고 있습니다.

활용 사례

CoAP는 주로 리소스가 제약된 IoT 장치들이 상호 통신하거나, 로컬 네트워크/메시 네트워크에서 경량 프로토콜이 필요한 경우에 활용됩니다. 대표적인 사례로는:

  • 스마트 홈 자동화: CoAP는 스마트 조명, 온도조절기, 보안 센서 등 스마트 홈 기기간 통신에 점점 활용되고 있습니다 (CoAP Protocol: Key Features, Use Cases, and Pros/Cons | EMQ). 예를 들어, 일부 스마트 전구(전등) 제어 프로토콜에서 CoAP를 사용하여 전등을 켜고 끄는 명령을 주고받습니다. 가정 내 로컬 네트워크에서 허브와 센서/액추에이터 간에 CoAP를 쓰면, Wi-Fi나 스레드(Thread)망 상에서 낮은 지연과 멀티캐스트 제어의 이점을 얻을 수 있습니다.

  • 산업용 IoT: 공장의 센서와 액추에이터처럼 실시간성과 효율이 중요한 환경에서 CoAP가 적용됩니다 (CoAP Protocol: Key Features, Use Cases, and Pros/Cons | EMQ). 예컨대 제조 설비의 온도/압력 센서들이 CoAP로 데이터를 게이트웨이에 전송하고, 게이트웨이는 이를 모아 MQTT 등으로 상위 시스템에 보낼 수 있습니다. CoAP는 로컬 영역에서 신뢰성 있고 가벼운 프로토콜로 동작하여, 산업 현장의 제어 네트워크에서 유용합니다 (CoAP Protocol: Key Features, Use Cases, and Pros/Cons | EMQ).

  • 웨어러블 및 헬스케어 디바이스: 스마트워치나 의료 센서 같은 웨어러블 기기는 배터리와 자원이 제한적입니다 (CoAP Protocol: Key Features, Use Cases, and Pros/Cons | EMQ). 이런 기기 간 통신(예: 피트니스 트래커가 폰에 데이터 동기화)에 CoAP를 사용하면 전력 소모를 줄이고 동기화 속도를 높일 수 있습니다. 병원 내 센서 네트워크나 환자 모니터링 장치들도 CoAP로 데이터를 주고받아 신뢰성 있게 모니터링하는 시범 사례들이 있습니다.

  • 에너지 관리 및 스마트 미터: 전력량 계측기, 가스/수도 스마트 미터 등 에너지 모니터링 시스템에서 CoAP가 채택되고 있습니다 (CoAP Protocol: Key Features, Use Cases, and Pros/Cons | EMQ). 이런 기기들은 저전력 광역통신(LPWAN)이나 전용망으로 연결되는데, 경량 프로토콜인 CoAP로 계측 데이터를 전송하여 실시간 요금제나 원격 검침에 활용합니다. 예를 들어 NB-IoT망에서 LwM2M (Lightweight M2M) 프로토콜을 통해 미터 데이터를 보내는데, LwM2M은 내부적으로 CoAP를 사용합니다 (8 IoT Protocols and Standards Worth Exploring in 2024 | EMQ) (8 IoT Protocols and Standards Worth Exploring in 2024 | EMQ).

  • 표준 IoT 플랫폼 및 연합체 활용: Open Connectivity Foundation(OCF)이나 Thread 그룹 등 IoT 표준 단체에서도 CoAP를 핵심 프로토콜로 사용합니다. 예를 들어 OCF의 IoTivity 프레임워크는 CoAP 기반으로 동작하며, Thread(스레드) 네트워크의 응용 계층도 CoAP 메시지를 사용합니다 (Thread vs. Matter - Zigron.com). 이처럼 CoAP는 저전력 IPv6 네트워크에서 사실상의 표준으로 많이 쓰입니다.

실제 대기업들도 CoAP를 IoT에 활용하고 있습니다. 예를 들어 **시스코(Cisco)**와 **인텔(Intel)**은 IoT 솔루션에서 CoAP 메시징을 적용한 바 있습니다 (MQTT vs Other IoT Messaging Protocols: Comparison & Use Cases). 특히 CoAP는 OMA Lightweight M2M(LwM2M) 프로토콜의 기반으로 채택되어, 전세계 통신사업자들의 NB-IoT 디바이스 원격 관리에 널리 사용되고 있습니다. 이렇듯 CoAP는 국지적인 디바이스 네트워킹 및 디바이스 관리 분야에서 중요한 역할을 하고 있습니다.

관련 주요 라이브러리, 툴 및 개발 리소스

CoAP 생태계에서는 다양한 오픈소스 구현체와 개발 툴을 활용할 수 있습니다:

주요 문서로는 IETF RFC 7252 (CoAP 사양) ([

            RFC 7252 - The Constrained Application Protocol (CoAP)
        
    ](https://datatracker.ietf.org/doc/html/rfc7252#:~:text=This%20document%20specifies%20the%20Constrained,simplicity%20for%20constrained%20environments%20and))와 **RFC 7959(Blockwise), RFC 7641(Observe)** 등을 참고해야 합니다. 또한 **에물레이터나 클라우드 연동 툴**도 있는데, 예를 들어 EMQX 등의 브로커는 **CoAP->MQTT 변환 게이트웨이**를 제공하여 CoAP 장치를 클라우드 MQTT에 연결하기도 합니다 ([8 IoT Protocols and Standards Worth Exploring in 2024 | EMQ](https://www.emqx.com/en/blog/iot-protocols-mqtt-coap-lwm2m#:~:text=mainstream%20protocols%20such%20as%20STOMP%2C,reducing%20the%20adaptation%20costs%20between)).

학습을 위해서는 CoAP 튜토리얼이나 블로그 자료도 많습니다. 예를 들어 “A Field Guide to CoAP” 시리즈는 CoAP 개념과 실습을 잘 다룹니다. IETF CoRE WG의 메일링 리스트나 Stack Overflow의 [coap] 태그에서도 많은 Q&A를 찾아볼 수 있습니다 (A Field Guide to CoAP — Part 1. Everything related to the Constrained… | by Jonathan Beri | Medium).

MQTT: 메시지 큐잉 텔레메트리 전송 프로토콜

개념 및 특징

MQTT는 경량의 Pub/Sub (발행-구독) 메시징 프로토콜로, 저대역폭, 고지연, 신뢰성 낮은 네트워크에서 원격 장치의 데이터 전송을 위해 설계되었습니다 (MQTT vs Other IoT Messaging Protocols: Comparison & Use Cases). 1999년 IBM에서 최초로 개발되었고, 2014년 OASIS 표준으로 승인되어 현재 IoT 분야의 사실상의 표준 프로토콜로 자리 잡고 있습니다. MQTT라는 명칭은 원래 "Message Queuing Telemetry Transport"의 약자였으나, OASIS 표준화 과정에서 공식적으로는 더 이상 약어의 의미를 부여하지 않고 MQTT 자체가 프로토콜 이름으로 사용됩니다 (MQTT Vs CoAP for IoT). MQTT의 가장 큰 특징은 중앙 브로커(Broker)를 통한 비동기 메시지 교환입니다. 데이터를 보내는 기기를 퍼블리셔(Publisher), 데이터를 수신하는 기기를 **구독자(Subscriber)**라고 하며, 이들이 직접 연결되는 것이 아니라 MQTT 브로커 서버를 통해 간접적으로 통신합니다 (MQTT Vs CoAP for IoT). 퍼블리셔가 브로커에 메시지를 발행하면, 브로커가 동일한 **토픽(Topic)**을 구독중인 모든 구독자에게 메시지를 전달해줍니다 (MQTT Vs CoAP for IoT). 이러한 구조 덕분에 발행자와 구독자가 서로를 몰라도(시간적/공간적으로 디커플링, decoupling) 데이터 교환이 가능하며, 일대다(one-to-many) 통신이 효율적으로 이루어집니다 (MQTT Vs CoAP for IoT).

MQTT의 핵심 특징은 다음과 같습니다:

  • 경량 & 효율적 전송: MQTT는 TCP 상에서 동작하면서도 패킷 오버헤드를 최소화하도록 고안되었습니다 (MQTT Vs CoAP for IoT). 모든 제어 메시지가 2바이트 고정 헤더로 시작하고, 추가 헤더와 페이로드도 바이너리로 구조화되어 있어 메시지 크기가 작습니다. 예를 들어 내용이 거의 없는 PINGREQ 패킷이나 PUBACK 패킷 등은 수 바이트 수준에 불과합니다. 또한 토픽 기반으로 메시지를 라우팅하기 때문에, 구독자가 없으면 브로커가 메시지를 폐기함으로써 불필요한 전송을 막습니다. 저전력 장치에서도 수 kb 수준의 MQTT 라이브러리로 통신이 가능하며, 셋업을 단순화하기 위해 연결 유지(keep-alive) 기간이나 패킷 크기 등이 튜닝 가능합니다.

  • 브로커 기반 비동기 Pub/Sub: 중앙 브로커 서버가 있기 때문에 클라이언트 간의 통신 동기화를 신경쓰지 않아도 됩니다 (MQTT and CoAP: Underlying Protocols for the IoT | Electronic Design) (MQTT and CoAP: Underlying Protocols for the IoT | Electronic Design). 퍼블리셔는 수신자가 누구든 상관없이 메시지를 브로커에 보내고, 구독자는 관심 토픽만 브로커에 알려놓으면 됩니다. 브로커는 모든 수신자들이 연결되지 않은 경우에도 메시지를 보관하거나 전달할 수 있어 시간적으로 비동기적인 통신이 가능합니다 (MQTT and CoAP: Underlying Protocols for the IoT | Electronic Design) (MQTT and CoAP: Underlying Protocols for the IoT | Electronic Design). 예를 들어 어떤 노드가 수면모드로 잠시 오프라인이어도, 브로커가 깨어날 때까지 메시지를 큐에 담아둘 수 있습니다(이 부분은 QoS 설정에 따라 다름).

  • 다양한 QoS 등급 지원: MQTT는 QoS 0, 1, 2 세 가지 전송 품질 등급을 제공하여, 응용이 메시지 전달 신뢰성을 선택할 수 있게 합니다 (MQTT Guide 2024: Beginner to Advanced | EMQ). QoS 0은 “기최한 한번” 전달로 보내기만 하고 확인하지 않는 방식, QoS 1은 “최소 한 번” 전달로 수신 측의 확인(PUBACK)을 받을 때까지 재전송하는 방식, QoS 2는 “정확히 한 번” 전달로 중복을 완전히 피하기 위한 추가 핸드셰이크(PUBREC/PUBREL/PUBCOMP 메시지 교환)를 수행합니다 (MQTT Guide 2024: Beginner to Advanced | EMQ). 이를 통해 중요하지 않은 센서 데이터부터 반드시 한번 처리돼야 하는 제어 명령까지 필요한 수준의 신뢰성을 설정할 수 있습니다.

  • 양방향 통신 및 상태 관리: MQTT는 기본적으로 메시지 지향이지만, 클라이언트와 브로커 간의 연결은 양방향입니다. 즉 하나의 TCP 연결로 **데이터 업로드(발행)**와 **명령 다운로드(구독)**를 모두 수행할 수 있어 양방향 제어가 용이합니다 (MQTT Vs CoAP for IoT). 또한 브로커는 모든 클라이언트의 연결 상태를 파악하고 있으므로, 어떤 기기가 갑자기 연결이 끊어지면 Last Will 메시지를 대신 발행하여 다른 노드들에게 알릴 수 있습니다 (MQTT Vs CoAP for IoT) (MQTT and CoAP: Underlying Protocols for the IoT | Electronic Design). 브로커는 각 클라이언트의 **세션 상태(미확인 메시지, 구독 리스트 등)**를 유지하거나 (Persistent Session), 클라이언트 재연결 시 세션을 이어받게 할 수도 있습니다. 이러한 상태 관리 덕분에 네트워크 불안정 상황에서도 논리적인 통신 관계를 지속할 수 있습니다 (MQTT and CoAP: Underlying Protocols for the IoT | Electronic Design).

  • 확장성 및 유연한 토픽: MQTT의 토픽은 계층적 문자열 경로로 구성되어 있고, +나 #와 같은 와일드카드를 사용하여 구독 범위를 지정할 수 있습니다 (MQTT and CoAP: Underlying Protocols for the IoT | Electronic Design). 예를 들어 sensor/+/temp로 구독하면 여러 센서 디바이스의 온도 주제를 한꺼번에 받을 수 있습니다. 이를 통해 낮은 프로그래밍 복잡도로 다수 토픽을 다룰 수 있어 시스템 확장이 쉽습니다. 브로커를 클러스터링하거나 브리지로 연결하여 수백만 노드까지 수용한 사례도 있으며, 경량 버전인 MQTT-SN을 이용해 **TCP 없는 환경(예: ZigBee)**에서도 MQTT 스타일 통신을 구현할 수 있습니다 (MQTT Vs CoAP for IoT).

아키텍처와 동작 방식

MQTT 아키텍처의 중심에는 **브로커(Broker)**가 있습니다. 브로커는 일종의 메시지 서버로, 모든 클라이언트와 TCP 연결을 맺고 클라이언트들 사이에서 메시지를 중계합니다. 퍼블리셔는 특정 **토픽 이름으로 메시지를 발행(PUBLISH)**하고, 브로커는 해당 토픽을 구독(SUBSCRIBE) 중인 모든 구독자에게 메시지를 전달합니다 (MQTT Vs CoAP for IoT). 이때 토픽은 사람이 읽을 수 있는 경로 형태(예: home/livingroom/temperature)로, 브로커는 토픽 문자열을 키로 내부 루팅 테이블을 관리합니다. 구독자는 관심있는 토픽을 하나 이상 구독해두고, 브로커로부터 해당 토픽들의 메시지를 비동기적으로 수신합니다.

(MQTT Vs CoAP for IoT) MQTT 브로커를 중심으로 한 Publish/Subscribe 통신 구조 다이어그램. 왼쪽의 **MQTT 클라이언트(온도 센서)**가 브로커(HiveMQ 로고)에 **토픽 "sensor/temp"로 메시지를 발행(Publish)**하면, 브로커는 우측의 구독자 클라이언트들(DB 서버 등)에 해당 토픽을 구독 중인 경우 메시지를 전달합니다. 이처럼 브로커가 모든 메시지의 허브 역할을 수행하여 다대다 통신을 간접적으로 실현합니다 (MQTT Vs CoAP for IoT) (MQTT Vs CoAP for IoT).

MQTT 클라이언트는 브로커에 연결할 때 CONNECT 패킷을 보내며, 여기에는 클라이언트 ID, 사용자 인증 정보(옵션), KeepAlive 간격 등의 정보가 포함됩니다. 브로커가 CONNACK로 연결 수락을 보내면 세션이 형성되고, 이후 클라이언트는 필요 시 SUBSCRIBE 패킷으로 토픽 구독을, PUBLISH 패킷으로 메시지 발행을 합니다 (MQTT Vs CoAP for IoT). 각각에 대해 브로커는 SUBACK, PUBACK/PUBREC 등 응답을 보내 QoS 요구사항을 처리합니다. 다수 토픽을 한 번에 구독하거나 취소(UNSUBSCRIBE)할 수도 있습니다. 통신을 마치면 DISCONNECT 패킷으로 정상 종료를 알립니다. 만약 비정상 종료(전원 끊김 등)되더라도, 앞서 언급한 Last Will 설정이 되어 있으면 브로커가 사전에 등록된 LWT 메시지를 대신 발행하여 다른 구독자들에게 해당 클라이언트의 상태를 알립니다 (MQTT and CoAP: Underlying Protocols for the IoT | Electronic Design).

MQTT 브로커는 토픽별로 구독자 리스트를 유지하고 있어, 새로운 PUBLISH가 들어올 때 어떤 클라이언트에 보내야 할지 신속히 결정합니다. 그리고 QoS 1, 2의 경우 각 메시지에 대한 **전송 상태(ACK 받았는지 등)**를 저장하여 필요한 재전송을 수행합니다. **보안 연결(SSL/TLS)**을 사용하면 브로커는 클라이언트 인증도 처리하며, ACL(Access Control List) 등을 통해 특정 클라이언트가 특정 토픽에 Publish/Subscribe 가능한지 권한 관리도 수행합니다. 요약하면, MQTT 아키텍처에서는 브로커가 많은 기능과 책임(라우팅, 저장, 인증, 상태관리)을 맡고 있고, 클라이언트들은 단순히 브로커와만 통신하면 되므로 전체 시스템이 느슨하게 결합되고 확장성이 높아집니다 (MQTT Vs CoAP for IoT).

메시지 구조

MQTT 메시지는 **제어 패킷(Control Packet)**이라고 불리며, 각 패킷은 공통 포맷의 Fixed header + Variable header + Payload 구조를 가집니다. Fixed header는 2바이트 이상으로 구성되는데:

  • 첫 바이트: 상위 4비트는 패킷 타입(CONNECT=1, CONNACK=2, PUBLISH=3, ... DISCONNECT=14 등 16종)이며, 하위 4비트는 패킷별로 정의된 플래그 비트입니다 (예: PUBLISH의 DUP, QoS, RETAIN 플래그).

  • 나머지 바이트: Remaining Length 필드로, 가변 길이 인코딩(VLI)을 사용하여 이 패킷의 남은 바이트 길이를 표시합니다 (MQTT Guide 2024: Beginner to Advanced | EMQ). 128진법 기반으로 1~4바이트까지 사용하므로, 최대 약 256MB까지 페이로드 포함 메시지 크기를 표현할 수 있습니다 (MQTT Vs CoAP for IoT).

그 다음은 패킷 종류에 따라 Variable header와 Payload가 옵니다. 예를 들어 CONNECT 패킷의 가변헤더에는 프로토콜명, 버전, 접속 플래그, KeepAlive 값 등이 있고 페이로드에는 클라이언트ID, 사용자명/암호, Will 메시지 정보 등이 있습니다 (MQTT and CoAP: Underlying Protocols for the IoT | Electronic Design). PUBLISH 패킷의 경우 가변헤더에 토픽명과 (QoS≥1일 때) 패킷 식별자 Packet ID가 있으며, 페이로드에 전달할 실제 데이터가 담깁니다. SUBSCRIBE 패킷은 가변헤더에 Packet ID, 페이로드에 구독하고자 하는 Topic 필터들과 QoS 원하는 등급이 들어있습니다. 이처럼 각 패킷마다 정해진 필드 구조가 있지만, 핵심 원리는 모든 메시지에 공통된 작은 Fixed header로 시작하여 이후 부분을 상황에 맞게 넣는 것입니다.

MQTT 토픽(Topic) 자체는 메시지 헤더에 포함되어 텍스트로 전송되므로, 토픽명이 길면 오버헤드가 될 수 있습니다. 하지만 이는 사용상의 유연함과 트레이드오프이며, 필요하면 짧은 토픽 이름을 쓰거나 MQTT-SN처럼 토픽 ID 방식을 쓰는 방안도 있습니다. MQTT v5.0에서는 기존 구조에 **속성(Properties)**라는 가변헤더 필드를 추가하여, 메시지에 사용자 지정 메타데이터를 담을 수 있게 하였습니다 (예: 내용 형식, 만료 시간 등).

정리하면, MQTT 메시지 구조는 TCP 스트림 상에서 압축되지 않은 바이너리 형태로 전송되며, 프로토콜 자체 오버헤드는 작지만 연결형 프로토콜의 장점을 활용하여 아주 큰 크기의 메시지도 하나의 논리 메시지로 처리할 수 있습니다. MQTT v3.1.1 기준으로 최대 메시지 크기는 268,435,455 바이트(약 256MB)로 정의되어 있어, 실질적으로 제약이 없습니다 (MQTT Vs CoAP for IoT). (물론 실제 환경에서는 브로커 설정이나 메모리 한계로 훨씬 작은 사이즈로 제한됩니다.)

QoS와 메시지 전달 보장

MQTT는 QoS(Quality of Service) 등급으로 각 메시지의 전달 보장 수준을 조절합니다. 앞서 개념에서 소개한 QoS 0, 1, 2에 대해 좀 더 구체적으로 살펴보면 다음과 같습니다 (MQTT Guide 2024: Beginner to Advanced | EMQ):

  • QoS 0 – At most once (최대 한 번 전달): 송신자가 메시지를 한 번 보내고 끝이며, 수신 측에서 확인 응답을 보내지 않는 모드입니다. TCP 자체의 전송에는 노력하지만, 애플리케이션 레벨에서는 손실 시 재시도하지 않으므로 메시지가 유실될 수 있습니다 (MQTT Guide 2024: Beginner to Advanced | EMQ). 가장 가벼운 모드로, 중복되지 않지만 손실될 수 있음을 의미합니다. 주기적으로 보내는 센서 데이터 등, 몇 개 빠져도 무방한 데이터에 주로 사용됩니다.

  • QoS 1 – At least once (최소 한 번 전달): 적어도 한 번은 수신되도록 보장하는 모드입니다. 퍼블리셔는 메시지를 보내고 **브로커/구독자로부터 ACK(PUBACK)**를 기다립니다. ACK를 받을 때까지 일정 간격으로 재전송하며, ACK를 받으면 메시지와 전송記録을 폐기합니다 (MQTT and CoAP: Underlying Protocols for the IoT | Electronic Design). 이 과정에서 중복 전송 가능성이 있으므로, 수신 측에서는 동일한 메시지가 두 번 오면 하나는 무시해야 합니다. MQTT 라이브러리가 자동으로 패킷 ID를 관리하여 중복인지 아닌지 식별해줍니다. QoS1은 전달은 보장하지만 중복 허용이라는 특성이 있습니다 (MQTT Guide 2024: Beginner to Advanced | EMQ).

  • QoS 2 – Exactly once (정확히 한 번 전달): 메시지 손실과 중복을 모두 방지하는 최고 수준의 QoS입니다. 양쪽 통신이 4단계 핸드셰이크를 수행하여, 한 쪽은 메시지 저장→전달→상대방 수신확인→완료확인까지 일련의 과정을 거칩니다 (MQTT and CoAP: Underlying Protocols for the IoT | Electronic Design). 구체적으로 퍼블리셔가 PUBLISH(QoS2 플래그) 전송 → 브로커가 일단 받아서 PUBREC 응답 → 퍼블리셔가 메시지를 지우고 PUBREL 보냄 → 브로커가 최종 PUBCOMP 응답. 이를 통해 양측 모두 해당 메시지 처리 완료를 합의하게 되며, 중복이나 손실 없이 한 번 딱 전달됩니다 (MQTT and CoAP: Underlying Protocols for the IoT | Electronic Design). 구현이 복잡하고 지연이 길지만, **중요 제어 명령(예: 도어락 열림 등)**에 사용될 수 있습니다.

MQTT에서 QoS는 메시지 단위로 선택가능하며, 브로커와 구독자 각각의 QoS가 있을 수 있지만, 실효 QoS는 그 중 낮은 쪽이 적용됩니다. 예컨대 퍼블리셔→브로커는 QoS2로 보내도, 구독자→브로커 구독이 QoS1이면 브로커는 QoS1 수준으로 전달합니다. 또한 브로커는 QoS1,2 메시지를 클라이언트가 오프라인일 때 저장해둘 수 있어, 나중에 재연결시 전달합니다 (MQTT Vs CoAP for IoT). 이를 메시지 큐잉 기능이라 하며, CoAP에는 없는 MQTT 고유의 장점입니다.

마지막으로, MQTT 브로커는 보관(retain) 메시지 기능도 제공합니다 (MQTT Vs CoAP for IoT) (MQTT Vs CoAP for IoT). 퍼블리셔가 어떤 메시지를 retain 플래그와 함께 보내면, 브로커는 해당 토픽의 “최신값”을 저장해둡니다. 그리고 새로운 구독자가 나중에 해당 토픽을 구독하면, 브로커는 보관해둔 최신 메시지를 즉시 한 번 보내줍니다. 이 기능은 예컨대 센서의 최종 측정값을 항상 최신으로 유지하여, 새로 연결된 모니터링 클라이언트가 즉시 현 상태를 알 수 있게 하는 등 편의성을 줍니다 (MQTT Vs CoAP for IoT) (MQTT Vs CoAP for IoT).

보안 방식

MQTT는 TCP 기반 프로토콜이므로 전송 계층에서 TLS/SSL을 사용하여 보안을 확보하는 것이 일반적입니다. MQTT 표준 자체는 보안 기능을 내장하고 있지 않지만, TLS를 적용하면 클라이언트-브로커 간 종단간 암호화와 기밀성, 무결성 보호를 실현할 수 있습니다 (MQTT vs Other IoT Messaging Protocols: Comparison & Use Cases). 대부분의 MQTT 브로커와 클라이언트 라이브러리는 TLS를 지원하며, TLS 사용 시에는 기본 포트가 8883으로 바뀝니다 (기본 1883은 평문). TLS는 RSA/ECDSA 인증서를 통한 서버 인증 및 필요한 경우 클라이언트 인증도 가능하므로, 브로커는 허가된 기기만 접속을 허용할 수 있습니다 (MQTT Guide 2024: Beginner to Advanced | EMQ). 또한 MQTT 레벨에서 사용자명/암호 인증 방법도 제공하므로, TLS 없이 간단히 ID/PW만으로 인증하는 설정도 가능합니다 (물론 이는 암호 노출 위험 때문에 TLS와 함께 사용해야 안전합니다).

MQTT 브로커는 추가적인 보안 기능으로 **접근 제어(ACL)**를 적용할 수 있습니다. 예를 들어 특정 클라이언트에게 sensors/+/temp 토픽은 publish만 가능, subscribe는 불가능 등 세밀한 권한을 줄 수 있습니다. 이는 브로커 소프트웨어 설정에 따라 다르며 MQTT 표준에 명시된 내용은 아니지만, 상용/오픈소스 브로커 구현들이 제공하는 기능입니다.

네트워크 보안 측면에서는, MQTT는 일반적으로 하나의 서버(Broker)로 트래픽이 모이기 때문에 방화벽 설정이 용이합니다. 즉 브로커가 있는 데이터센터만 보호하면 되므로, IoT 디바이스들이 각자 노출되는 CoAP보다 낫습니다. 반대로 브로커가 공격당하면 전체 시스템에 영향이 크므로, 브로커 이중화나 DMZ 구성 등 아키텍처적 보안도 중요합니다.

정리하면 MQTT는 TLS를 통한 강력한 암호화 보안을 사용하며, 추가로 인증과 권한관리를 통해 실무 IoT 서비스에서 안전하게 운영되고 있습니다 (MQTT Guide 2024: Beginner to Advanced | EMQ). 다만 TLS 핸드셰이크는 자원소모가 커서, 모든 센서에 인증서 탑재가 어려운 경우에는 사설망+MQTT로 운영하기도 합니다. MQTT 프로토콜 자체도 v5.0에서 오류 응답 코드 등을 세분화하여, 보안 실패 원인을 클라이언트에 전달할 수 있게 개선되었습니다.

주요 장점

  • 단순한 프로그래밍 모델과 유연성: MQTT의 Pub/Sub 패러다임은 발행자와 구독자가 서로 몰라도 통신할 수 있게 해주어 시스템 설계가 단순해집니다 (MQTT Vs CoAP for IoT). 새로운 센서를 추가해도 브로커에 연결하고 적절한 토픽으로 발행만 하면 되며, 기존 소비자 코드를 수정할 필요가 없습니다. 여러 클라이언트가 데이터를 공유하거나 백엔드 시스템과 연동하기도 쉬워서, IoT에서 데이터 흐름 설계에 큰 유연성을 줍니다 (MQTT Vs CoAP for IoT). 또한 토픽 설계를 통해 계층 구조를 만들 수 있어, 예컨대 건물/층/방/센서 형태로 토픽을 정의하면 필요한 범위의 데이터만 구독하기 용이합니다. 이런 유연함과 확장성 덕분에 MQTT는 소규모 홈IoT부터 대규모 산업IoT까지 폭넓게 쓰입니다.

  • 브로커의 부가 기능 활용: 중앙 브로커 구조의 이점으로, 개발자가 일일이 구현하지 않아도 여러 유용한 기능을 얻을 수 있습니다. 예를 들면, 메시지 큐잉을 통해 오프라인 디바이스에 대한 메시지 보관/재전달이 가능하고 (MQTT Vs CoAP for IoT), Retained 메시지로 최신 상태를 캐시할 수 있으며 (MQTT Vs CoAP for IoT), Last Will 메시지로 노드 장애를 자동 통보할 수 있습니다 (MQTT Vs CoAP for IoT). 이 외에도 브로커는 트래픽 모니터링, 로깅, 멀티프로토콜 게이트웨이 등 IoT 서비스 구축에 도움되는 기능들을 제공합니다. 오픈소스 브로커 (Mosquitto 등)나 상용 클라우드 브로커(AWS IoT, Azure IoT Hub 등)의 풍부한 기능을 활용하면 IoT 솔루션을 신속히 구축할 수 있습니다 (MQTT Vs CoAP for IoT).

  • 높은 신뢰성과 안정성: MQTT는 기본적으로 TCP 위에서 동작하므로 패킷 손실이나 순서 뒤바뀜을 걱정하지 않아도 되고, 추가로 QoS1, QoS2를 설정하면 메시지 전달을 엄격히 보장할 수 있습니다 (MQTT vs Other IoT Messaging Protocols: Comparison & Use Cases). 또한 클라이언트 KeepAlive 기작으로 연결 상태를 지속 점검하여 끊어짐을 감지하며, **세션 지속(persistent session)**으로 재연결 시 미발행 메시지를 이어 받을 수도 있습니다 (MQTT Guide 2024: Beginner to Advanced | EMQ) (MQTT Guide 2024: Beginner to Advanced | EMQ). 실제 적용 사례에서 MQTT는 수십만~수백만 대 규모의 디바이스 연결도 견딜 수 있음이 입증되었고, 프로토콜이 단순해 고부하에서도 매우 안정적입니다. 즉, MQTT를 사용하면 데이터 유실 최소화와 24/7 안정 운용이 비교적 수월합니다.

  • 광범위한 지원과 생태계: MQTT는 오랜 기간 사용되어 왔고 IoT 붐과 함께 더욱 각광받아, 대부분의 프로그래밍 언어와 플랫폼에 클라이언트 라이브러리가 존재합니다 (MQTT Vs CoAP for IoT). 예를 들어 Eclipse Paho 프로젝트는 C, C++, Java, Python, JavaScript 등 다수 언어의 MQTT 클라이언트를 제공하며 (Paho - The Eclipse Foundation), Arduino나 NodeMCU 같은 마이크로컨트롤러 보드에서도 사용 가능한 경량 구현이 있습니다. 또한 Eclipse Mosquitto처럼 무료 오픈소스 브로커부터 HiveMQ, EMQX 같은 상용 고성능 브로커까지 선택지가 많습니다. 클라우드 서비스들도 MQTT를 채택하여, AWS IoT, Azure IoT, Google Cloud IoT 모두 MQTT 접속을 공식 지원합니다. 이런 폭넓은 생태계는 개발자에게 학습 자료, 툴, 커뮤니티 지원을 풍부하게 제공하여 개발 난이도를 낮추고 문제 해결을 용이하게 해줍니다.

주요 단점

  • 브로커 의존 및 단일 장애점: MQTT는 브로커가 없으면 통신이 이루어지지 않기 때문에, 브로커가 **단일 장애점(SPOF)**이 될 수 있습니다. 브로커에 장애가 나면 전체 시스템이 정지하므로, 이를 회피하려면 브로커 클러스터링이나 이중화 구성 등 추가 인프라 비용이 필요합니다. 반면 CoAP는 브로커 없이도 동작하므로, 작은 규모에서는 오히려 더 간단할 수 있습니다. 또한 브로커 운영/유지가 MQTT 솔루션의 한 부분을 차지하여, 자체 서버를 두지 않고 P2P 통신만 필요한 단순한 경우에는 다소 과하다고 느껴질 수 있습니다.

  • 연결 유지에 따른 자원 소모: MQTT 클라이언트는 항상 브로커와 TCP 연결을 열어두어야 하기 때문에, 휴대폰 데이터나 배터리 사용 측면에서 부담이 될 수 있습니다. KeepAlive 패킷을 주기적으로 보내야 하고, NAT 환경에서는 연결 유지를 위해 패킷을 지속 주입해야 합니다. 디바이스가 수면모드로 자주 깨어나기 어려운 환경이라면 MQTT 연결을 유지하기 어려울 수 있습니다. (MQTT-SN 등에서는 수면 장치에 대해 오프라인 구간을 지정하는 기능 등이 있지만 MQTT 기본사양에는 없습니다 (Detailed Explanation And Comparison Of MQTT And CoAP Protocols).) 이에 반해 CoAP는 필요할 때만 메시지를 보내고 끝내므로 배터리 수명에 더 유리합니다 (Detailed Explanation And Comparison Of MQTT And CoAP Protocols).

  • HTTP 등에 비해 미흡한 요청-응답 모델: MQTT는 본질적으로 센서 데이터 수집 등 일방향 텔레메트리에 적합하게 설계되었기 때문에, 임의의 두 장치 간 쌍방향 요청/응답에는 바로 들어맞지 않을 때가 있습니다. 예를 들어 A 기기가 B 기기에게 직접 명령을 보내 결과를 받고 싶을 경우, MQTT에서는 응답을 위한 별도 토픽 체계를 설계해야 하고 응답을 기다리는 로직도 직접 관리해야 합니다. CoAP나 HTTP처럼 요청 보내고 응답 받는 패턴이 자연스럽지 않다는 뜻입니다. MQTT v5.0에서 Request-Response 패턴을 돕는 코릴레이션 데이터 등의 개선이 있었지만 (MQTT Guide 2024: Beginner to Advanced | EMQ), 여전히 RPC처럼 쓰기에는 부자연스러운 점이 있습니다. 이 때문에 RPC가 필요한 경우 MQTT보다는 CoAP/HTTP를 쓰거나, MQTT에서는 임베디드 기기보다는 게이트웨이/클라우드 간 통신에 주로 사용하는 편입니다.

  • 메시지 큐잉 지연: 브로커가 오프라인 클라이언트의 메시지를 보관해주는 것은 장점이지만, 반대로 실시간성이 떨어지는 원인도 됩니다. 네트워크가 단절되었을 때 CoAP는 어차피 전달 실패로 끝나지만, MQTT는 브로커가 성공적으로 받았으면 클라이언트가 언제 깨어나든 결국 전달하려고 시도합니다. 이때 시간이 많이 경과한 뒤 배터리 장치가 깨어나면 오래된 명령이 수행되는 등의 타이밍 이슈가 발생할 수 있습니다 (물론 MQTT 메시지에 TTL을 두어 만료시키는 등의 관리로 해결 가능). 또한 QoS2 메시지는 여러 핸드셰이크로 레이턴시가 커서 실시간 제어에 부적합한 면이 있습니다.

활용 사례

MQTT는 원격 모니터링 및 제어가 필요한 다양한 IoT 분야에서 널리 쓰이고 있습니다. 대표적인 활용 사례들을 들면:

  • 산업 자동화 및 스마트 공장: MQTT는 공장의 센서 네트워크나 생산기기 모니터링에 많이 사용됩니다 (MQTT vs Other IoT Messaging Protocols: Comparison & Use Cases). 예를 들어 PLC 컨트롤러들이 상태 데이터를 MQTT로 발행하면, 중앙 모니터링 시스템이 이를 구독하여 대시보드에 표시하거나 이상 패턴을 탐지합니다. 산업 환경은 신뢰성과 확장성이 중요하므로, QoS1/2를 활용한 MQTT 솔루션이 각광받고 있습니다. 지멘스, 보쉬 등 제조업체들도 자체 IIoT 플랫폼에 MQTT를 채택하고 있습니다 (MQTT vs Other IoT Messaging Protocols: Comparison & Use Cases) (MQTT vs Other IoT Messaging Protocols: Comparison & Use Cases).

  • 스마트 농업 및 환경 모니터링: 토양 습도 센서, 기상 관측 기기 등 분산된 센서들에서 클라우드로 데이터를 보내는 데 MQTT가 쓰입니다 (MQTT vs Other IoT Messaging Protocols: Comparison & Use Cases). 농장에서는 수십~수백 개의 노드가 있을 수 있는데, 각 노드가 셀룰러나 LoRa 게이트웨이를 통해 MQTT로 데이터를 발행하면, 중앙 서버가 받아 작물 생육 데이터를 분석합니다. **아마존(AWS)**의 IoT 서비스나 IBM 왓슨 IoT 플랫폼도 주로 MQTT를 통해 이러한 데이터를 수집합니다 (MQTT vs Other IoT Messaging Protocols: Comparison & Use Cases).

  • 차량 텔레매틱스 및 IoV: 차량의 위치, 속도, 상태 정보를 클라우드에 실시간 전송하는 데 MQTT가 활용됩니다. 자동차나 버스에 임베디드된 통신 단말이 주행 중 셀룰러 망을 통해 MQTT 브로커에 지속적으로 데이터를 발행하면, 교통 관제나 차량 관리 시스템이 이를 받아 처리합니다. MQTT의 경량성 덕분에 네트워크 품질이 변화해도 데이터 손실이 적고, QoS1로 중요한 이벤트를 보장할 수 있습니다.

  • 모바일 메신저와 실시간 애플리케이션: 흥미롭게도 MQTT는 IoT 외에 모바일 메신저 앱의 실시간 메시징에 활용된 사례도 있습니다. Facebook Messenger 초기 버전이 내부 프로토콜로 MQTT를 활용하여 스마트폰 앱과 서버 간 실시간 채팅을 구현한 바 있습니다. 이처럼 MQTT는 낮은 대기시간으로 푸시 알림을 전달하는 용도로도 쓸 수 있습니다. 다만 최근엔 웹소켓이나 전용 프로토콜로 대체되는 추세입니다.

  • 클라우드 IoT 플랫폼 연동: MQTT는 클라우드 벤더에서 IoT 디바이스를 연결하는 표준 인터페이스로 제공됩니다. AWS IoT Core, Azure IoT Hub, Google Cloud IoT Core 모두 MQTT 프로토콜로 디바이스 SDK를 제공하고, 디바이스로부터 손쉽게 데이터를 수집합니다. 예컨대 AWS Greengrass 같은 엣지 컴퓨팅 소프트웨어도 로컬에서 MQTT로 디바이스와 통신하고, 수집 데이터는 MQTT로 클라우드에 보냅니다. IBM Watson IoT, Bosch IoT Suite 등 다양한 IoT 플랫폼들이 MQTT 브로커를 내장하고 있습니다 (MQTT vs Other IoT Messaging Protocols: Comparison & Use Cases) (MQTT vs Other IoT Messaging Protocols: Comparison & Use Cases).

  • 스마트홈 및 DIY IoT: MQTT는 스마트홈 취미 개발자들에게도 인기 있는 프로토콜입니다. 오픈소스 홈 자동화 플랫폼인 Home Assistant에서는 MQTT를 통해 사용자 장치(예: DIY 센서, ESP8266 모듈)의 상태를 수집하고 제어 명령을 보냅니다. MQTT의 단순한 텍스트 토픽 구조는 사용자가 직접 트러블슈팅하기도 쉬워서, DIY IoT 환경에서 표준처럼 쓰이고 있습니다.

요약하면, MQTT는 클라우드와 엣지 간 연결, 다대다 센서 데이터 수집, 모바일 및 산업 IoT 등 광범위한 분야에서 활용되고 있으며, Amazon, Microsoft, IBM 등의 기업도 이를 핵심 IoT 기술로 채택하고 있습니다 (MQTT vs Other IoT Messaging Protocols: Comparison & Use Cases) (MQTT vs Other IoT Messaging Protocols: Comparison & Use Cases).

관련 주요 라이브러리, 툴 및 개발 리소스

MQTT는 성숙한 프로토콜인 만큼 개발을 위한 도구와 라이브러리가 풍부합니다:

  • Eclipse Paho 프로젝트 – 다양한 언어별 MQTT 클라이언트 라이브러리 모음입니다. C, C++, Java, Python, JavaScript, Go 등 대부분의 언어를 지원하여, 각 언어별로 손쉽게 MQTT를 적용할 수 있습니다 (Paho - The Eclipse Foundation). 예를 들어 Paho Python (paho-mqtt)으로 수십 줄만 코딩하면 MQTT 퍼블리셔/구독자 구현이 가능합니다.

  • Eclipse Mosquitto – 가장 널리 쓰이는 오픈소스 MQTT 브로커입니다. 경량이면서도 MQTT 3.1.1과 5.0을 지원하며, 클라이언트용 C 라이브러리와 간단한 커맨드라인 툴(mosquitto_pub/sub)을 함께 제공합니다. 학습용이나 소규모 배포에 적합하고, 브로커 성능도 뛰어나 산업용으로 쓰기도 합니다.

  • HiveMQ – 상용 엔터프라이즈 MQTT 브로커로, 고성능과 확장 기능(WebSocket 지원, 통계 대시보드 등)을 제공합니다. 최대 수백만 개 연결을 처리하도록 설계되어 산업 현장에서 쓰이며, 오픈소스 버전도 공개되어 있습니다. HiveMQ 웹사이트에는 MQTT 관련 유용한 블로그와 가이드가 많습니다.

  • EMQX – 또 다른 고성능 MQTT 브로커로, 오픈소스로 시작해 현재는 상용도 겸하는 솔루션입니다. MQTT 뿐 아니라 CoAP, LwM2M, WebSocket 등을 동시에 지원하는 멀티프로토콜 브로커이며, 분산 클러스터링 능력이 우수합니다.

  • MQTT.fx, MQTT Explorer – 데스크톱용 MQTT 클라이언트 툴로, GUI 환경에서 브로커에 연결해 토픽을 구독하고 메시지를 발행해볼 수 있습니다. 디버깅 및 테스트에 유용하며, MQTT.fx는 가벼운 Java 기반 툴, MQTT Explorer는 모던한 UI로 인기 있습니다.

  • Arduino, MBed 등 임베디드용 라이브러리 – 마이크로컨트롤러용 경량 MQTT 구현체도 많습니다. Arduino용 PubSubClient 라이브러리, mbed-os용 MQTTClient 등이 있어 작은 IoT 디바이스에서도 MQTT를 사용 가능하게 해줍니다. ESP8266/ESP32 같은 Wi-Fi 칩에는 기본 예제로 MQTT 활용이 제공될 정도입니다.

학습을 위해서는 HiveMQ MQTT Essential 블로그 시리즈나, EMQX에서 제공하는 “MQTT Guide 2024” 종합 자료 (MQTT Guide 2024: Beginner to Advanced | EMQ)를 참고하면 QoS, 보안, v5.0 새로운 기능 등을 익힐 수 있습니다. 또한 MQTT 공식 표준 문서는 OASIS에서 MQTT v3.1.1과 MQTT v5.0이 공개되어 있어 상세 구현을 확인할 수 있습니다.

커뮤니티 측면에서는 MQTT 관련 Stack Overflow, MQTT 인공위성 채팅방, 그리고 여러 깃헙 오픈소스 프로젝트를 통해 지원을 받을 수 있습니다. MQTT은 워낙 인기 있는 프로토콜이므로 문제 해결 사례도 많아 개발 난이도가 비교적 낮은 편입니다.

CoAP vs MQTT: 비교 및 선택 기준

이제 앞서 살펴본 CoAP와 MQTT의 특징을 기반으로, 두 프로토콜을 여러 측면에서 비교하고 언제 어떤 프로토콜을 선택하면 좋을지에 대해 정리하겠습니다.

기술적 비교: CoAP vs MQTT

다음 표는 CoAP와 MQTT를 여러 기술적 특성에서 비교한 것입니다:

구분 CoAP MQTT
표준화 IETF 표준 RFC 7252 (2014) ([A Field Guide to CoAP — Part 1. Everything related to the Constrained… by Jonathan Beri
통신 모델 요청/응답 (클라이언트 ↔ 서버) (MQTT Vs CoAP for IoT)RESTful (자원 지향) 발행/구독 (브로커 ↔ 클라이언트) (MQTT Vs CoAP for IoT)이벤트 기반 (토픽 지향)
네트워크 전송 UDP (IPv6 멀티캐스트 지원) (MQTT Vs CoAP for IoT)(옵션: UDP외 SMS, TCP도 가능) (MQTT Vs CoAP for IoT) TCP (인터넷 일반망 친화적)(옵션: WebSocket 등 TCP 기반)
기본 포트 5683/UDP (평문 CoAP) (MQTT Vs CoAP for IoT)5684/UDP (DTLS 보안) 1883/TCP (평문 MQTT) (MQTT Vs CoAP for IoT)8883/TCP (TLS 보안)
메시지 형식 바이너리 메시지 (4바이트 헤더 + 옵션 + 페이로드) (MQTT Vs CoAP for IoT)URI 및 메서드 코드 포함 바이너리 제어패킷 (2바이트부터 가변 길이) ([MQTT Guide 2024: Beginner to Advanced
오버헤드 최소 4바이트 헤더 (MQTT Vs CoAP for IoT)한 패킷에 대체로 수백 바이트 이하 최소 2바이트 헤더 (MQTT Vs CoAP for IoT)메시지당 추가 TCP/IP 헤더 존재
메시지 최대크기 이론상 UDP 패킷 한계 (<64KB)권장: 1,024바이트 내외 (IPv6 6LoWPAN) (MQTT Vs CoAP for IoT)대형 데이터는 Blockwise로 분할 전송 이론상 256MB까지 (Remaining Length) (MQTT Vs CoAP for IoT)실제: 브로커/클라 설정에 따름 (수 MB 수준)
QoS / 신뢰성 Confirmable (재전송으로 최소 1회 전달) (MQTT Vs CoAP for IoT)Non-confirmable (보장 없음)(중복 방지는 메시지ID로 처리) QoS0 (보장 없음) ([MQTT Guide 2024: Beginner to Advanced
통신 패턴 동기 요청-응답+ Observe로 비동기 알림 (1→다) (MQTT Vs CoAP for IoT)+ 멀티캐스트 요청 (1→다) 비동기 발행-구독 (다→다)+ Retain/Will로 상태 전달 (MQTT Vs CoAP for IoT)+ Request/Response 패턴 가능 (v5.0) ([MQTT Guide 2024: Beginner to Advanced
보안 DTLS 1.2 (UDP용 TLS) ([MQTT and CoAP: Underlying Protocols for the IoT Electronic Design](https://www.electronicdesign.com/technologies/communications/iot/article/21800998/silicon-labs-mqtt-and-coap-underlying-protocols-for-the-iot#:~:text=match%20at%20L342%20CoAP%20uses,be%E2%80%94and%20should%20be%E2%80%94augmented%20with%20DTLS))PSK, X.509 인증 등 지원 ([ 
            RFC 7252 - The Constrained Application Protocol (CoAP)
        
    ](https://datatracker.ietf.org/doc/html/rfc7252#:~:text=no%20security%20to%20certificate,CoAP))<br>OSCORE (엔드-투-엔드 객체보안) | TLS/SSL 3.0 또는 TLS 1.2/1.3<br>X.509 인증서, ID/Password 인증 ([MQTT Guide 2024: Beginner to Advanced | EMQ](https://www.emqx.com/en/mqtt-guide#:~:text=MQTT%20supports%20multiple%20security%20mechanisms%2C,users%20can%20access%20specific%20topics))<br>토픽별 ACL 권한 제어 |

| 장치 자원 요구 | 메모리 수십 KB, 8-bit MCU 구현 사례도 있음DTLS 적용 시 암호화 비용 증가 | 클라이언트: 수십 KB~수백 KB (TCP/IP 스택 포함)브로커: 서버급 자원 필요 (연결 수 따라 상이) | | 장점 요약 | 아주 경량, 멀티캐스트 지원, HTTP 유사 (REST)브로커 없어도 P2P 통신, 로컬 제어 최적저전력/저비용 네트워크에 적합 (8 IoT Protocols and Standards Worth Exploring in 2024 | EMQ) | 높은 신뢰성, 강력한 브로커 기능, 손쉬운 확장다대다 통신 용이 (토픽 기반), 풍부한 라이브러리클라우드 연계에 최적, 방화벽/NAT 친화 | | 단점 요약 | 중앙 브로커 부재 (기능 부족), UDP로 인한 NAT 문제 (CoAP Protocol: Key Features, Use Cases, and Pros/Cons | EMQ)인터넷 직접 통신 어려움, 비교적 생태계 미성숙 | 브로커 의존 (SPOF), 지속 연결로 인한 전력소모요청-응답 모델에 부적합, 프로토콜 오버헤드 (TCP handshake) |

(주: 위 표에서 MQTT 기본 포트로 5684/UDP가 표기된 것은 CoAP Secure(CoAPS)의 포트 번호입니다. MQTT의 기본 포트는 1883/TCP (평문), 8883/TCP (TLS)입니다 (MQTT Vs CoAP for IoT).)

위 표를 통해 알 수 있듯이, CoAP와 MQTT는 목적과 강점이 서로 다르게 설계되었습니다. CoAP는 경량/로컬 통신에, MQTT는 브로커를 통한 신뢰성 있는 중앙집중 통신에 최적화되어 있습니다. 구체적으로 차이점을 몇 가지 더 언급하면:

  • 통신 방식: CoAP는 클라이언트-서버 1대1 요청 응답이며 필요 시 멀티캐스트/Observe로 1대다를 지원하지만, MQTT는 애초에 다대다 브로드캐스트를 염두에 둔 발행/구독 모델입니다 (MQTT and CoAP: Underlying Protocols for the IoT | Electronic Design) (MQTT Vs CoAP for IoT). 따라서 이벤트 분배나 브로드캐스트에는 MQTT가 간편하고 강력합니다.

  • 연결 및 전송: CoAP는 **비연결형(UDP)**이라 오버헤드가 작고 지연이 낮으나, 신뢰성/순서를 스스로 관리해야 합니다. MQTT는 **연결형(TCP)**이라 전송 안정성은 높지만 연결 성립/유지 비용이 있습니다 (MQTT and CoAP: Underlying Protocols for the IoT | Electronic Design) (MQTT Vs CoAP for IoT).

  • 메시지 라우팅: CoAP는 IP 주소와 포트로 종단 식별하여 통신하고, URI로 리소스를 구분합니다. 반면 MQTT는 브로커가 종단이므로 모든 메시지가 브로커를 경유하며, 토픽 문자열로 라우팅됩니다 (MQTT Vs CoAP for IoT). 그 결과 CoAP는 네트워크 계층에서 직접 통신하지만, MQTT는 애플리케이션 계층 라우팅을 합니다.

  • 데이터 포맷: CoAP는 **HTTP-like (메서드/상태코드 + MIME 타입)**이어서 **표현형식 협상(Accept 옵션)**이나 콘텐츠 포맷 지정이 가능하고, 표준 인터넷 미디어 타입을 사용합니다. MQTT는 애초에 바이너리 페이로드만 전달하며 내용에 관여하지 않아서, 데이터 포맷은 응용에 완전 위임됩니다 (MQTT Vs CoAP for IoT). 즉 JSON이든 바이너리든 자유지만, 클라이언트끼리 미리 약속이 필요합니다. 이 부분은 CoAP가 웹 통합 용이성 측면에서 유리합니다.

  • 확장성: MQTT는 브로커를 스케일업/아웃 함으로써 많은 디바이스 지원이 비교적 수월합니다. 특히 브로커 클러스터링 기술이 발전하여 100만 단위 접속도 처리 가능합니다. CoAP는 P2P 구조이기에, 디바이스가 늘어나면 각 노드들이 관리해야 할 피어가 많아지고 통신 관계가 복잡해집니다. 대규모에서는 일반적으로 CoAP 노드들을 지역 게이트웨이에 묶고, 게이트웨이가 MQTT로 상위 전달하는 방식으로 계층화합니다 (MQTT Vs CoAP for IoT) (MQTT Vs CoAP for IoT).

  • 인터넷/웹 통합: CoAP는 HTTP와 쉽게 매핑될 수 있도록 만들어져서, CoAP-HTTP 프록시를 쓰면 IoT 디바이스를 기존 웹 서비스에 통합하기 용이합니다 (MQTT Vs CoAP for IoT). 반면 MQTT는 전통 웹과는 개념이 달라 REST API로 직접 노출하기 어렵고, 보통 브로커에 REST API 플러그인을 붙이거나 MQTT-REST 게이트웨이를 따로 둡니다. 따라서 웹애플리케이션 연계에는 CoAP 쪽이 자연스럽습니다.

  • 표준 지원 기능: MQTT 브로커들은 대체로 성능 모니터링, 관리 콘솔, 지속적 저장 등의 기능을 제공하지만, CoAP는 각 디바이스에 내장되므로 이런 중앙관리 기능은 별도로 구축해야 합니다. 대신 CoAP는 LwM2M 같은 디바이스 관리 프로토콜에 응용되어 펌웨어 업데이트, 구성관리 등에 쓰이고 있습니다.

IoT 활용 측면 비교

IoT 시나리오에서 CoAP와 MQTT의 사용 패턴을 비교하면, 서로 보완적인 역할을 하는 경우가 많습니다. CoAP는 주로 엣지(Edge) 영역에서 디바이스-디바이스 혹은 디바이스-게이트웨이 통신에 쓰이고, MQTT는 게이트웨이-클라우드 혹은 디바이스-클라우드 통신에 쓰이는 경향이 있습니다 (MQTT Vs CoAP for IoT). 예를 들어, 스마트 시티의 가로등 제어를 생각해 보면, 개별 가로등 제어기들은 근거리 무선망(예: 6LoWPAN)으로 CoAP 신호를 주고받아 그룹으로 동기 제어되고, 중앙 제어센터와는 게이트웨이가 MQTT로 통신하여 각 지역의 상태를 모읍니다.

성능 면에서 CoAP는 메시지당 오버헤드가 작아 동일 조건에서 대역폭을 덜 차지합니다. HiveMQ의 비교에 따르면, 256바이트 payload 전송 시 MQTT QoS0은 TCP 연결/구독 오버헤드를 포함하여 한 메시지에 약 388바이트 * 2 (publish+ack) = 776바이트, CoAP 비확인 메시지는 요청+응답 합쳐 약 387바이트 정도로 측정되었습니다 (MQTT Vs CoAP for IoT). 또한 연결 설정 비용도 MQTT는 처음에 ~166바이트(CONNECT/ACK), CoAP는 0입니다 (MQTT Vs CoAP for IoT). 따라서 짧은 세션 또는 소량 데이터 전송에는 CoAP가 효율적입니다 (MQTT Vs CoAP for IoT). 그러나 장기적 스트리밍에는 MQTT의 지속 연결이 유리할 수 있습니다. 또한 CoAP로 MQTT 수준의 신뢰성(예: 큰 메시지 전송이나 엄격한 순서보장)을 달성하려면 추가적인 재시도나 조각화 블록 관리 등 구현이 복잡해져 결국 오버헤드 면에서 이득이 줄어듭니다 (MQTT Vs CoAP for IoT).

지연(latency) 측면에서는, 소규모 환경에서 CoAP가 한 홉 통신이라 end-to-end 지연이 매우 낮을 수 있지만, 인터넷처럼 멀리 통신하면 MQTT(TCP)의 안정적인 전송이 재전송로스 등에 따른 재시도를 줄여 유리할 수 있습니다. 실제 벤치마크에서는 QoS0 MQTT가 매우 빠른 한편, QoS1 MQTT와 CoAP는 비슷한 수준의 평균 RTT를 보였습니다 (MQTT QoS0 평균 0.054ms, QoS1 0.81ms, CoAP 0.1145ms on local test) (MQTT Vs CoAP for IoT). 이는 CoAP가 1요청+1응답, MQTT QoS1은 2-스텝이지만 최적화로 근소한 차이를 보인 결과로 이해됩니다. 요컨대 실시간성 측면에서는 둘 다 작은 센서 데이터 용도에서 충분히 빠르지만, MQTT QoS2는 느릴 수 있고 CoAP도 손실 상황에서 지연 증가가 있을 수 있습니다.

규모 확장과 멀티홉: MQTT는 브로커 한 대로 많은 클라이언트 수용이 가능하고, 브로커 간 연동으로 지리적으로 분산된 시스템을 구성할 수 있습니다. CoAP는 멀티홉 전달 시 별도의 CoAP 프록시/라우터가 필요하거나 IPv6 라우팅에 의존해야 해서, 광범위한 WAN보다는 LAN이나 PAN 범위에 적합합니다. 따라서 WAN 구간에는 MQTT, LAN 구간에는 CoAP를 혼용하는 구조가 흔합니다 (MQTT Vs CoAP for IoT).

디바이스 전력 소비 면에서는, 깨어있지 않은 시간에는 CoAP가 유리합니다. CoAP 클라이언트는 필요할 때만 메시지를 보내고 ACK만 잠깐 기다린 후 바로 다시 절전할 수 있습니다. MQTT는 KeepAlive 주기마다 패킷을 보내야 하므로 아주 오래 수면(예: 1시간 간격) 장치에는 안 맞습니다. 이를 보완하기 위해 MQTT-SN에서는 오프라인 수면 클라이언트 기능을 넣어, 일정 시간 브로커가 메시지를 큐잉하다 깨우는 개념을 도입하기도 했습니다 (Power Evaluation of IOT Application Layer Protocols - arXiv). 그러나 일반 MQTT에는 없으므로, 배터리 구동 IoT에서는 CoAP를 고려할 만합니다 (Detailed Explanation And Comparison Of MQTT And CoAP Protocols).

인터넷 환경에서는 MQTT가 TLS, 포트 443(WebSocket) 등 다양한 방법으로 통과 가능해 방화벽/NAT 친화적입니다. CoAP는 DTLS 포트 5684가 열려있지 않으면 통신 곤란하고, 443 UDP를 통한 CoAP는 일반적이지 않습니다. CoAP over TCP (RFC 8323)도 나와있지만 거의 사용되지 않습니다. 따라서 클라우드 직접 연결을 생각하면 MQTT를 택하는 것이 무난합니다.

프로토콜 선택 기준

두 프로토콜 모두 IoT에 유용하지만, 사용 목적과 환경에 따라 적합도가 다르므로 다음과 같은 기준을 고려해야 합니다:

  • 장치 제약 조건: 디바이스의 CPU, 메모리, 전력이 극도로 제한적이라면 -> CoAP 권장. 수십 KB RAM도 어렵고 배터리 소모를 최소화해야 하는 센서에는 CoAP가 잘 맞습니다 (A Field Guide to CoAP — Part 1. Everything related to the Constrained… | by Jonathan Beri | Medium). 반대로 라즈베리파이 급 이상 충분한 리소스가 있고 OS가 돌아간다면 MQTT도 문제 없습니다.

  • 통신 패턴: 일대일 요청/응답 또는 소규모 그룹 통신 -> CoAP 적합. 다대다 브로드캐스트나 다수 데이터 수집 -> MQTT 적합. 예를 들어 원격 API 호출처럼 동작하길 원하면 CoAP/HTTP 스타일이 자연스럽고, 수백 노드의 센서 데이터를 모아야 하면 MQTT로 토픽 설계하는 게 편리합니다.

  • 네트워크 환경: 로컬 망, 전용망, 6LoWPAN/IEEE 802.15.4 등 IPv6 메쉬 -> CoAP 선호. 인터넷 WAN, 셀룰러 망, 클라우드 연동 -> MQTT 선호. CoAP는 로컬에서 UDP multicast 등 장점이 빛나지만, 인터넷에서 불특정 다수와 통신엔 장애가 많습니다 (CoAP Protocol: Key Features, Use Cases, and Pros/Cons | EMQ). MQTT는 클라우드 IoT 허브와 연동이 쉬워 엔드투엔드 인터넷 IoT에 적합합니다.

  • 브로커 설치 여부: 중앙 브로커를 운영할 수 있는 환경 -> MQTT. 브로커 두기 어려운 P2P 혹은 임시 네트워크 -> CoAP. 예컨대 두 IoT 기기를 직접 연결해 제어해야 하는데 중간 인프라 없이 해야 한다면 CoAP로 직접 통신이 낫습니다. 그러나 MQTT 브로커를 둘 수 있다면 그 편의성과 기능을 누릴 수 있습니다.

  • 데이터 크기와 빈도: 드물게 작은 메시지 전송 -> CoAP 이점. 빈번하게 지속 스트림 -> MQTT 이점. CoAP는 필요할 때만 통신하므로 비정기 이벤트에 효율적이고, MQTT는 연결 유지가 overhead이지만 지속 스트림에는 안정적입니다 (MQTT Vs CoAP for IoT). 또한 큰 파일(예: 이미지, 펌웨어)을 보내려면 MQTT는 한 번에 스트림으로 보내기 좋고, CoAP는 Blockwise로 나눠 보내야 하는 번거로움이 있습니다.

  • 안전하고 신뢰성 요구: 데이터 손실 절대 불가, 강력한 보안 요구 -> MQTT+TLS가 더 적합. MQTT QoS2와 TLS로 무장하면 금융 수준의 신뢰성을 얻을 수 있고, 인증/권한 관리도 용이합니다 (MQTT vs Other IoT Messaging Protocols: Comparison & Use Cases). CoAP도 DTLS가 있지만 UDP 기반이라 Connection-less 보안 세션 관리가 어려워 상대적으로 복잡합니다. (단, CoAP+OSCORE로 종단간 암호화가 필요한 특별한 경우 고려)

  • 기존 시스템 통합: 웹/HTTP 시스템과 연계 -> CoAP가 편리. 클라우드 IoT 플랫폼 사용 -> MQTT가 표준. 앞서 언급했듯 웹과 흡사한 CoAP는 사내 HTTP API 등에 연결하기 좋고, MQTT는 대형 IoT 클라우드들이 기본으로 지원하므로 연계가 쉽습니다.

  • 토폴로지와 인프라: 메쉬 네트워크 IoT (예: Thread, Zigbee) -> 내부 통신은 CoAP (또는 MQTT-SN) 사용 경향. 클라우드-디바이스 스타형 IoT -> MQTT. 실제로 Thread 프로토콜은 메쉬 내에서 CoAP를 쓰고, 상위로는 경량 프로토콜 변환 (예: Border router가 MQTT로 중계)하는 구조입니다. 또한 모바일 앱 ↔ IoT 기기 직접 통신에는 MQTT보다는 CoAP/HTTP를 쓰는 경우가 많습니다 (예: 스마트폰이 IoT 기기 AP 모드에 연결해서 REST API 호출).

결국 **“적재적소에 맞게 혼합 사용”**하는 것도 한 방법입니다. 예를 들어, 현장 단말들 간에는 CoAP로 빠르게 제어하면서 현장 게이트웨이가 모은 데이터는 MQTT로 클라우드에 보내는 식입니다 (MQTT Vs CoAP for IoT). 또는 장치 제어 명령은 CoAP(바로 대상에게 1:1 전달)로 하면서, 상태 모니터링 데이터는 MQTT(브로커 통해 다자 전파)로 보내는 아키텍처도 가능합니다. 심지어 MQTT-SN(Sensor Network 용 MQTT 변종)은 UDP 기반의 경량 MQTT로서, CoAP와 경쟁 혹은 보완 관계에 있습니다 (MQTT Vs CoAP for IoT). MQTT-SN은 2022년경 표준화 작업 중이며, 브로커 없이 MQTT 스타일 통신을 가능케 하여 CoAP의 영역을 일부 대체할 수도 있습니다.

결론 및 요약

CoAP와 MQTT는 IoT 환경의 다양한 요구를 충족시키기 위해 설계된 상호보완적인 프로토콜입니다. CoAP는 “IoT용 경량 HTTP”, **MQTT는 “이벤트 중심 메시지 허브”**로 요약할 수 있으며, 어느 한쪽이 절대적으로 우월하다기보다는 적용 상황에 따라 적합성이 달라집니다 (A Field Guide to CoAP — Part 1. Everything related to the Constrained… | by Jonathan Beri | Medium).

CoAP를 선택한다면, 저전력 디바이스, 로컬 통신, RESTful 접근에 강점을 살릴 수 있고, MQTT를 선택한다면 신뢰성 있는 브로커의 편의성과 대규모 분산처리, 클라우드 연동의 혜택을 누릴 수 있습니다. 만약 IoT 솔루션 전반을 설계한다면, 에지 영역에는 CoAP, 클라우드 영역에는 MQTT를 함께 활용하는 것도 바람직한 아키텍처가 될 수 있습니다 (MQTT Vs CoAP for IoT).

마지막으로, 프로토콜 선택에 정답은 없지만 **“목적에 맞는 도구를 사용한다”**는 원칙이 중요합니다 (A Field Guide to CoAP — Part 1. Everything related to the Constrained… | by Jonathan Beri | Medium). IoT 디바이스의 제약과 요구사항을 면밀히 검토하고, 앞서 논의한 차이점을 기준으로 CoAP와 MQTT 중 최적을 선택하거나 필요하면 혼용함으로써, 효율적이고 안정적인 IoT 서비스를 구현할 수 있을 것입니다.

참고 자료 및 추가 링크

4.94 / 169 rates

댓글 쓰기

다음 이전