CoAP: 제약된 IoT 기기를 위한 경량 REST 통신

제약된 기기에서 REST 통신을 유지하는 방법

CoAP(Constrained Application Protocol)은 메모리, 연산 능력, 전력이 제한된 IoT 기기를 대상으로 한 웹 전송 프로토콜이다. IETF가 2014년 RFC 7252로 표준화했으며, HTTP와 비슷한 REST 아키텍처를 따르되 저전력 네트워크와 작은 장치에 맞게 설계했다.

리소스는 URI로 접근하고 GET, POST, PUT, DELETE 같은 메소드를 사용한다. 다만 TCP 대신 UDP 위에서 동작하며, 패킷과 상태 관리 부담을 줄이는 쪽에 초점이 있다.

가벼운 메시지 교환을 위한 설계

CoAP의 기본 헤더는 4바이트다. 바이너리 인코딩을 사용해 패킷 크기를 줄이고, 제한된 RAM과 ROM을 가진 8비트 마이크로컨트롤러에서도 동작할 수 있도록 했다.

UDP 기반이라는 점도 핵심이다. 연결 설정(handshaking)이 필요하지 않아 오버헤드를 낮출 수 있으며, 낮은 대역폭과 전력 소비가 중요한 환경에 맞는다. 응답을 즉시 기다리지 않는 비동기 메시지 교환도 가능하므로, 클라이언트는 전송 뒤 슬립 모드로 전환할 수 있다.

HTTP와의 매핑이 가능하다는 점은 IoT 장치와 웹 시스템을 연결할 때 유용하다. 장치가 제공하는 기능을 리소스로 모델링하고 기존의 REST 접근 방식을 적용할 수 있다.

응용 계층부터 UDP까지 이어지는 구조

⤢✕

응용 계층은 REST API를 구현하고, 요청/응답 계층과 메시지 계층은 리소스 요청 및 메시지 신뢰성·중복 탐지를 담당한다. 하위에서는 UDP와 IP가 전송을 맡는다.

헤더 필드와 메시지 유형

기본 헤더에는 다음 정보가 들어간다.

Ver(2비트): 프로토콜 버전
T(2비트): 메시지 타입(CON, NON, ACK, RST)
TKL(4비트): 토큰 길이 필드
Code(8비트): 요청 메소드 또는 응답 코드
Message ID(16비트): 중복 탐지 및 메시지 매칭에 사용

⤢✕

메시지 타입은 전송 성격을 구분한다. Confirmable(CON)은 응답을 요구하는 신뢰성 있는 전송이고, Non-Confirmable(NON)은 확인응답 없이 보낼 수 있다. ACK는 CON 메시지에 대한 확인응답이며, RST는 메시지 처리가 실패했거나 수신자가 컨텍스트를 기억하지 못할 때 사용한다.

확인이 필요한 요청과 그렇지 않은 요청

CON은 서버가 처리 결과를 ACK로 돌려주는 흐름에 사용한다.

⤢✕

반면 NON은 응답이 반드시 필요하지 않은 전송에 사용한다.

⤢✕

리소스 메소드와 응답 코드

CoAP는 REST 스타일의 리소스 조작을 제공한다. GET은 리소스 표현을 요청하고, POST는 새 리소스를 만들거나 기존 리소스를 갱신한다. PUT은 리소스 생성 또는 업데이트에, DELETE는 리소스 삭제에 사용한다.

응답 코드는 성공, 클라이언트 오류, 서버 오류로 구분된다.

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 기능을 이용하면 클라이언트는 특정 리소스에 대한 관찰을 요청할 수 있다. 이후 리소스 상태가 바뀌면 서버가 클라이언트에 변경 내용을 알린다. 상태를 반복 조회하지 않고 IoT 환경의 변화를 모니터링하는 방식이다.

⤢✕

리소스 디스커버리는 /.well-known/core 경로를 통해 서버가 제공하는 리소스 목록을 찾는 표준화된 방법이다. 클라이언트는 이를 통해 서버 기능을 동적으로 파악할 수 있다.

블록 전송은 대용량 데이터를 작은 블록으로 나누어 보내는 기능이다. 제한된 버퍼 크기에 맞출 수 있고, 전송 중 오류가 나면 전체 데이터가 아니라 해당 블록만 재전송한다.

UDP 위의 보안 계층

CoAP는 UDP 위에서 동작하므로 보안이 필요할 때 DTLS(Datagram Transport Layer Security)를 사용한다. DTLS를 적용한 CoAP 프로토콜은 CoAPS라고 한다.

지원하는 보안 모드는 NoSec, PreSharedKey, RawPublicKey, Certificate다. NoSec은 보안을 사용하지 않으며, PreSharedKey는 사전 공유 키를 사용한다. RawPublicKey는 인증서 없이 공개키를 사용하고, Certificate는 X.509 인증서 기반 보안 방식이다.

센서 네트워크에서의 활용

스마트홈에서는 온도, 습도, 모션 센서가 CoAP로 저전력 데이터 전송을 수행할 수 있다. 배터리 기반 센서의 수명을 고려하면서 Observe 패턴으로 상태 변화를 모니터링하는 구성이 가능하다.

산업용 IoT에서는 공장 장비의 상태와 성능 데이터를 수집하는 데 사용할 수 있다. 제한된 네트워크에서도 통신할 수 있고, 경량 프로토콜 특성으로 기존 레거시 장비에 적용할 수 있다.

스마트 농업의 토양 습도, 일조량, 기온 센서 네트워크도 대상이다. 태양광 패널이나 배터리로 장기간 동작하는 환경에서 원격 모니터링과 제어에 활용할 수 있다. 건강 모니터링 장치와 웨어러블 디바이스에서는 제한된 배터리 환경의 건강 데이터 전송, 필요한 때에만 보내는 비동기 통신에 맞는다.

HTTP·MQTT와 선택 기준

HTTP와 비교하면 CoAP는 바이너리 인코딩과 UDP를 사용하며 4바이트 헤더를 갖는다. HTTP는 텍스트 기반이고 TCP 위에서 동작하며 더 큰 헤더를 사용한다. 따라서 자원이 제한된 환경에는 CoAP가 더 적합하다.

MQTT와는 통신 모델이 다르다. CoAP는 REST 기반의 요청/응답과 관찰 모델을 사용하고, MQTT는 토픽 기반 발행/구독 모델을 사용한다. 리소스 중심의 접근이 필요하면 CoAP를, 메시지 중심의 통신이 필요하면 MQTT를 선택할 수 있다.

구현 시 남겨둘 상태와 전송 정책

구현에서는 Message ID를 이용한 중복 메시지 탐지가 필요하다. 제한된 메모리에서는 유지할 상태 정보를 최소화해야 하며, 재전송에는 적절한 타임아웃과 지수 백오프 알고리즘을 설정한다.

보안 요구사항에 맞는 DTLS 모드를 선택하고, 그룹 통신이 필요하다면 멀티캐스트 지원도 함께 검토한다. CoAP는 저전력, 제한된 메모리, 불안정한 네트워크 환경에서 IoT 기기 간 통신과 IoT-웹 통합을 위한 선택지가 될 수 있으며, 더 많은 제약 환경 기기가 인터넷에 연결됨에 따라 중요성이 증가할 전망이다.