Invisible Safety,

Proven by Intelligence

보이지 않는 안전을 인텔리전스로 증명하다.

기술 노트
IT 산업의 변화를 이끄는 MDS인텔리전스의
기술 인사이트를 만나보세요.
DX·AI
IoT 프로토콜 : CoAP와 MQTT
2026년 01월 13일


COAP과 MQTT는 현재 저 사양 기기를 위한 사물인터넷(IoT) 환경에서 가장 널리 사용되고 있는 통신 프로토콜입니다. 두 프로토콜은 유사한 서비스 영역을 가지는 프로토콜이어서 많은 비교 대상이 되곤 합니다. 

COAP과 MQTT는 다음과 같은 공통점을 가지고 있습니다. 

· 공개 표준

· HTTP 보다 제한된 환경에서 더 적합

· 비동기식 전송 메커니즘을 제공

· IP 위에서 동작

· 구현 범위를 가짐

· 개방형 표준 메시징 프로토콜을 지향



그럼 이제 각각 살펴보겠습니다. 


│COAP │

(Constrained Application Protocol)


CoAP는 Constrained Application Protocol 의 약자로 IETF에서 표준화한 UDP 기반의 경량화된 REST 프로토콜입니다(RFC7252). 이름에도 포함되어 있지만 CoAP는 ‘제한된 노드와 제한된 네트워크’를 위한 프로토콜입니다.

CoAP는 클라이언트-서버(or Request-Response) 모델을 기반으로 동작하며 클라이언트-서버간에 상태 정보를 전송하기 위한 모델에 적합한 One-To-One 프로토콜입니다.  UDP를 기반으로 설계되었기 때문에 클라이언트와 서버는 비 연결형 서비스로 데이터 그램을 방식을 제공합니다. UDP 위에서의 비동기적 전송이 이루어지며, TCP를 사용하지 않음으로써 발생하는 신뢰성 문제는 CoAP 내부의 재전송 및 타이머 관리 옵션으로 해결하고 있습니다. CoAP은 HTTP REST 사상에 맞추어 설계되었기에 간단한 프록시를 통해 HTTP와의 상호 운용이 쉽게 가능합니다. 

[그림 1]  CoAP & HTTP  / 출처: IETF 79차 회의 Core WG


CoAP - Content Negotiation

HTTP 사상으로 설계되었기에 CoAP 또한 컨텐트 타협(Content Negotiation)을 지원합니다. 클라이언트는 Accept 옵션을 사용 하여 선호하는 리소스 타입을 전달하고 서버는 Content-Type을 통하여 클라이언트에게 전송할 데이터의 타입을 알려줍니다. HTTP와 마찬가지로 클라이언트와 서버가 독립적으로 동작하기에 서로에게 영향을 미치지 않으면서, 새로운 타입을 추가하는 것이 가능합니다.
​
CoAP - QoS(Quality of Service)

CoAP는 요청 및 응답 메시지를 "Confirmable"또는 "Nonconfirmable"으로 구분하여 보낼 수 있습니다. Confirmable 메시지의 경우 수신 측은 ACK 메시지를 송신측에 전송해야 합니다. Nonconfirmable 메시지는 ACK를 전송할 필요가 없습니다. 

CoAP - Observe

CoAP는 리소스를 Observe 할 수 있는 기능을 제공합니다. CoAP GET 요청에서 이 Observe 플래그가 설정되면 서버는 초기 데이터가 전송 된 후에도 해당 리소스의 데이터를 클라이언트로부터 지속적으로 받을 수 있습니다. 이를 통해 서버는 클라이언트의 특정 리소스 상태의 지속적으로 모니터링 할 수 있습니다. Observe 플래그는 설정을 통해 활성화 및 비활성화가 가능합니다.

CoAP - Resource Discovery

CoAP는 리소스 검색을 위한 표준 메커니즘을 지원합니다. CoAP 클라이언트에 ‘/.well-known/core’라는 요청을 보내면 클라이언트는 응답으로 메타 데이터가 포함된 리소스 목록을 서버에 제공합니다. 참고로 이러한 메시지 형태는 Link Format이라 명명하고 있으며, 해당 메시지의 Media Type은 ‘application/link-format’입니다.

​CoAP - Security

CoAP는 UDP를 기반으로 동작하므로, SSL/TLS를 사용한 보안을 제공 할 수 없습니다. 대신 CoAP는 DTLS(Datagram Transport Layer Security)를 통한 보안을 제공합니다. DTLS는 TLS와 동일한 레벨의 보안을 제공하지만 UDP를 통한 데이터 전송을 보장합니다. TLS/DTLS는 모두 비대칭키 암호화에 의한 핸드셰이크(handshake) 과정을 수행하면서 키 생성 및 교환을 진행한 이후 이로 인해 생성된 키를 대칭키 암호화에 이용하여 데이터를 주고받는 방식을 사용합니다. DTLS가 적용된 CoAP디바이스는 일반적으로 키 생성 및 교환을 위하여 RSA 또는 ECC 암호화 알고리즘을 지원합니다. 또 이로 인해 생성된 키를 활용하여 이루어지는 데이터 전달 시의 암호화 알고리즘으로 AES를 지원합니다.

│MQTT │

(Message Queuing Telemetry Transport)

MQTT(Message Queuing Telemetry Transport)는 다수의 클라이언트 연결 및 원격 검침(telemetry)에 적합한 ISO 표준 Publish/Subscribe 메시징 프로토콜(ISO/IEC PRF 20922) 입니다. 
MQTT는 브로커(Broker)가 중재하는 One to Many, Many to Many 통신에 적합한 프로토콜입니다. 클라이언트는 브로커에 메시지를 발행하거나 브로커를 구독하여 메시지를 받을 수 있습니다. 
메시지는 토픽(Topic)으로 구분되며 브로커는 해당 토픽을 구독하는 클라이언트에게 메시지를 전송합니다. 클라이언트들은 다수의 토픽을 한번에 구독할 수도 있습니다. MQTT 브로커는 각종 디바이스에서 보내주는 메시지를 수집하여 필요한 디바이스들에게 전송해주는 중간 서버 역할을 담당합니다.

이해를 돕기 위해 간단한 형태의 MQTT 네트워크를 보여 드리겠습니다.

​

[그림 2]  MQTT Network  / 출처: MQTT and CoAP, IoT Protocols

위 그림에서 A, B, C 3개의 클라이언트는 모두 브로커와의 TCP로 연결되어 있으며, 클라이언트 B와 C는 ‘temperature’ 라는 토픽을 구독하고 있습니다. 클라이언트 A가 ‘temperature’ 토픽으로 값을 발행하면 브로커는 해당 토픽을 구독하는 B, C 에게 해당 값을 전달합니다. MQTT는 이러한 One to Many, Many to Many 형태의 모델에 적합한 프로토콜입니다.


MQTT - Topic Matching

MQTT에서의 토픽은 ‘/’을 사용하여 계층적으로 구성됩니다.(eg. kitchen/oven/temperature) 클라이언트는 토픽을 구독할 때 Wildcard인 ‘+’, ‘#’을 사용하여 다수의 토픽을 한번에 구독할 수 있습니다. ‘+’는 단일 디렉토리와 매칭되고, ‘#’은 여러 디렉토리와 매칭할 때 사용합니다.

kitchen/+/temperature  =  kitchen/foo/temperature

kitchen/+/temperature  ≠  kitchen/foo/bar/temperature

kitchen/#  =  kitchen/fridge/compressor/valve1/temperature


MQTT - QoS(Quality of Service)

MQTT는 신뢰성 있는 메시징을 위하여 아래와 같은 3가지의 QoS 옵션을 제공합니다.

    · Fire and forget(Level 0): 메시지는 최대 한번 전달됩니다. 전송 확인이 없기에 유실 가능성이 있습니다.

    · Delivered at least once(Level 1): 메시지는 최소 한번 이상 전송되게 됩니다. 전송확인을 하지만 중복 전달될 가능이 있습니다.

    · Delivered exactly once(Level 2): 정확히 1번의 전달을 보장합니다. 다만 종단간 전송 지연 가능성이 있습니다.

레벨이 높아지면 품질은 향상되지만 처리 속도 등의 성능 저하가 발생할 수 있습니다. 따라서 서비스의 특성에 맞는 선택이 필요합니다.


MQTT - LWT(Last Will and Testament)

MQTT의 모든 클라이언트는 브로커와의 연결이 끊겼을 때 특정 토픽으로 지정된 메시지를 보낼 수 있습니다. 이를 LWT(Last will and testament)라고 합니다. Message가 등록되면 브로커는 해당 클라이언트의 연결이 끊기면 지정된 토픽으로 지정된 메시지를 자동으로 전송합니다.


MQTT - Security

MQTT는 브로커와의 연결에 있어 Username/Password를 통한 사용자 인증을 제공합니다. 하지만 해당 값은 암호화되지 않은 Plaintext입니다. 좀더 안정적인 보안이 필요하다면 SSL/TLS를 이용한 암호화 채널을 적용할 수 있습니다.


│CoAP와 MQTT의 비교 │

[그림 3]  MQTT & CoAP  / 출처: COAP vs MQTT


CoAP와 MQTT는 모두 IoT 환경에 적합한 프로토콜이지만 통신 모델에서의 근본적인 차이점이 있습니다. 

MQTT는 중앙 브로커를 통해 여러 클라이언트간에 메시지를 전달하기 위한 Publish-Subscribe, Many-To-Many 통신을 위한 프로토콜입니다. 클라이언트는 메시지를 발행하고 브로커는 메시지를 어디에 라우팅하고 복사할 것인지 결정하게 함으로써 생산자로 소비자를 분리시켰습니다. MQTT는 라이브 데이터를 위한 커뮤니케이션 버스에 가장 적합합니다.

CoAP는 주로 클라이언트와 서버간에 상태 정보를 전송하기 위한 모델에 적합한 Request-Response, One-To-One 통신 프로토콜입니다. 디바이스 별 리소스의 상태를 지속적으로 모니터링 하는 서비스에 가장 적합합니다. 또한 CoAP의 경우에는 REST 기반의 서비스 발견 기능을 제공하기에 신규 기능의 클라이언트 연결 시 추가적인 작업을 최소화 시킬 수 있는 장점도 있습니다.

이처럼 CoAP와 MQTT는 특성이 다르기에 도입하여 서비스를 운영할 때 얻을 수 있는 이점 또한 다릅니다. IoT 서비스 개발 시에는 이러한 특성을 고려하여 시장 환경에 맞는 프로토콜을 선택하여 도입할 필요가 있습니다.

Rapid-IoT는 IoT플랫폼으로 CoAP와 MQTT를 모두 지원하고 있습니다. 디바이스 및 서비스의 특징에 따라 프로토콜을 선택하되, 프로토콜을 포함한 각 센서 및 디바이스들과의 IoT 기술은 Rapid-IoT를 담당하고 사용자들은 IoT 기술을 통한 서비스를 운영하고 있습니다.