CoAP: 제약된 IoT 장치를 위한 UDP 기반 웹 프로토콜
CoAP의 UDP 기반 전송, REST 요청 모델, 메시지 신뢰성, Observe와 DTLS 보안을 IoT 제약 환경 관점에서 정리한다.
2026-08-14 · 최초 발행 2025-08-10
제약된 장치에 맞춘 웹 통신 모델
CoAP(Constrained Application Protocol)은 제한된 메모리, CPU 성능, 전력을 가진 IoT 디바이스를 대상으로 설계된 웹 전송 프로토콜이다. IETF에서 개발해 RFC 7252로 표준화했으며, M2M(Machine-to-Machine) 통신에 맞는 효율적인 메시지 교환을 목표로 한다.
HTTP와 유사한 웹 기반 모델을 채택하므로 URI로 리소스를 식별하고 요청과 응답을 주고받는 방식이 익숙하다. 다만 연결 설정과 큰 메시지 처리에 부담을 느끼는 제약 환경에서는 더 가벼운 전송 방식이 필요하다.
CoAP은 4바이트 기본 헤더와 바이너리 인코딩을 사용한다. 8비트 마이크로컨트롤러에서도 구현할 수 있으며, 배터리로 동작하는 장치의 전력 소비를 줄이는 데도 적합하다.
UDP 위에서 요청과 응답을 연결하는 방식
CoAP은 UDP(User Datagram Protocol)를 사용하므로 연결 설정을 위한 추가 패킷 교환 없이 통신한다. 이 특성은 네트워크 대역폭을 아껴야 하는 환경에서 유용하다.
REST 계층에서는 HTTP와 유사하게 GET, POST, PUT, DELETE 메소드를 제공한다. URI 기반 리소스 접근과 콘텐츠 협상, 프록시 지원 같은 확장 기능은 옵션으로 처리한다. 요청을 기다리는 동안 다른 요청도 처리할 수 있는 논블로킹 통신 모델이며, 리소스 상태 변화는 Observer 패턴으로 전달할 수 있다.
CoAP은 다음과 같은 계층으로 구성된다.
트랜잭션 계층은 메시지 교환과 신뢰성을 맡는다. REST 계층은 메소드, 응답 코드, 리소스 URI, 옵션을 통해 애플리케이션 수준의 의미를 제공한다.
메시지 형식은 다음과 같다.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Ver| T | TKL | Code | Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Token (if any, TKL bytes) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options (if any) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 1 1 1 1 1 1 1| Payload (if any) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
메시지 타입으로 다루는 신뢰성
UDP 자체는 전송 신뢰성을 보장하지 않는다. CoAP은 트랜잭션 계층에서 Confirmable(CON), Non-confirmable(NON), Acknowledgement(ACK), Reset(RST) 메시지 타입을 사용해 이 문제를 다룬다.
- Confirmable(CON)은 ACK 응답을 요구하는 신뢰성 있는 전송이다.
- Non-confirmable(NON)은 응답을 요구하지 않는 전송이다.
- Acknowledgement(ACK)는 CON 메시지 수신을 확인한다.
- Reset(RST)은 메시지를 처리할 수 없는 상태를 알린다.
CON 메시지는 응답이 없으면 지수 백오프로 재전송하며, 최대 4회 재전송한다. 메시지 ID는 중복 감지와 요청·응답 매칭에 쓰이고, 토큰은 비동기 요청과 응답의 상관관계를 유지한다.
리소스 조작과 응답 코드
GET은 리소스 상태를 조회하고, POST는 새로운 리소스를 생성하며, PUT은 상태를 갱신하고, DELETE는 리소스를 삭제한다.
응답 코드는 HTTP와 비슷한 의미를 가진다.
2.xx는 성공을 나타낸다.2.01 Created,2.02 Deleted,2.03 Valid,2.04 Changed,2.05 Content가 여기에 속한다.4.xx는 클라이언트 오류다.4.04 Not Found,4.05 Method Not Allowed가 예다.5.xx는 서버 오류를 의미하며,5.00 Internal Server Error가 있다.
스마트홈 허브가 센서 값을 읽고 임계값을 갱신하는 교환은 다음처럼 표현할 수 있다.
옵션과 Observe로 확장하는 통신
CoAP은 부가 정보를 옵션으로 전달한다. 각 옵션은 고유 번호로 식별하며, 리소스 식별에는 Uri-Path, Uri-Query를 사용한다. Content-Format은 JSON, CBOR, XML 등의 페이로드 형식을 지정하고, Max-Age는 응답 캐싱 시간을 나타낸다. ETag는 리소스 버전을 식별하며, Observe는 상태 변화 구독에 사용한다.
Observe를 사용하면 클라이언트는 리소스 변경을 자동으로 통지받을 수 있다. 구독은 Observe 옵션 값을 0으로 설정해 시작하며, 서버는 리소스 상태가 바뀔 때 새 응답을 전송한다.
HTTP와 비교할 때 달라지는 선택 기준
| 특성 | CoAP | HTTP |
|---|---|---|
| 전송 계층 | UDP | TCP |
| 메시지 크기 | 소형(수십~수백 바이트) | 대형(수KB~수MB) |
| 헤더 크기 | 4바이트 기본 | 수백 바이트 |
| 전력 소비 | 저전력 | 상대적 고전력 |
| 신뢰성 | 애플리케이션 계층 구현 | TCP에서 보장 |
| 리소스 발견 | 내장 지원 | 추가 메커니즘 필요 |
| 푸시 알림 | Observer 패턴 | WebSocket/SSE 필요 |
CoAP은 제한된 대역폭과 전력으로 동작하는 장치에 적합하다. 반면 HTTP는 TCP가 제공하는 신뢰성을 그대로 활용하며, 큰 메시지와 일반적인 웹 통신을 다루는 데 맞는다.
DTLS를 적용한 보안 통신
UDP 기반 CoAP 통신에는 DTLS(Datagram Transport Layer Security)를 적용할 수 있다. DTLS를 사용한 보안 CoAP은 CoAPs라 하며 기본 포트는 5684다.
인증 방식으로는 사전 공유 키를 쓰는 PreSharedKey, 인증서 없이 공개키를 사용하는 RawPublicKey, X.509 인증서를 기반으로 하는 Certificate가 있다.
IoT 환경에서의 적용 범위
스마트홈에서는 온도, 습도, 모션 센서가 CoAP으로 중앙 허브와 통신할 수 있다. 배터리로 동작하는 도어·창문 센서에는 저전력 특성이 도움이 되며, Observer 패턴은 상태 변화의 실시간 알림에 사용할 수 있다.
산업용 IoT에서는 공장 장비의 상태 데이터를 모으고 다수 장치를 제어하는 데 활용할 수 있다. 제한된 대역폭에서도 경량 프로토콜로 데이터를 전송할 수 있다는 점이 핵심이다.
스마트 시티 환경에서는 공기질, 소음, 교통량 센서와 가로등, 주차 센서 같은 인프라를 연결하는 데 적용할 수 있다. 수천 개 디바이스의 효율적 통신도 고려 대상이 된다.
구현체와 테스트 도구
구현체는 사용하는 언어와 배포 환경에 따라 선택할 수 있다.
- libcoap(C)는 경량 구현으로 임베디드 시스템에 적합하다.
- Californium(Java)은 풍부한 기능을 제공하며 서버 환경에 적합하다.
- CoAPthon(Python)은 빠른 프로토타이핑에 유용하다.
- Node-coap(JavaScript)는 Node.js 환경에서 활용할 수 있다.
테스트에는 Firefox 확장 프로그램인 Copper(Cu)와 명령줄 인터페이스 테스트 도구인 CoAP CLI를 사용할 수 있다.
IoT 장치가 늘어나는 환경에서는 제약 조건을 고려한 프로토콜 선택이 필요하다. CoAP은 HTTP와의 연계성을 유지하면서도 제약된 장치의 통신 요구를 다루며, 스마트 시티·산업 자동화·헬스케어 등으로 적용 영역이 확대될 전망이다. DTLS 통합은 안전한 IoT 환경을 구성하는 기반이 된다.