IoT 시대를 준비하는 경량 디바이스의 과제

Non-IP 기기인 경량 디바이스는 IoT(Internet of Things) 기기로 활용되고 있다. 하지만 인터넷 연결을 위해 게이트웨이를 거치는 과정과 최초 설계 당시 설정해둔 컨셉의 한계로, IoT 환경에서 효율적이고 안전하게 활용하기에 몇 가지 문제가 지적되고 있다. 이 글에서는 해당 문제에 대해 살펴보고 해결 방안을 모색해본다.​

IoT란, 말 그대로 ‘기기(Thing)들이 인터넷에 연결되는 것’을 의미한다. 인터넷에 연결되는 방식을 기준으로 IoT 기기는 다음과 같이 3가지로 분류할 수 있다.

[그림 1] 인터넷 연결 방식을 기준으로 분류한 IoT 기기

1) IP 기기: 일반적으로 Wi-Fi/이더넷 기술을 이용하여 인터넷에 바로 연결 가능한 기기

2) 마스터(Master)에 부속된 슬레이브(Slave) 기기: 마스터와 슬레이브 간에 물리적인 라인으로 연결된 구조를 갖는 기기. 마스터 기기는 RS485 시리얼 통신을 통해 슬레이브에 명령을 전달받는데, 이 구조에서 기기는 독립된 개체라기보다는 마스터에 속한 리소스로 간주

3) Non-IP 기기: IP 프로토콜 스택을 가지고 있지 않아 인터넷에 바로 연결이 불가능하여 게이트웨이를 거쳐 인터넷에 연결되는 기기. 주로 zigbee나 블루투스를 활용해서 게이트웨이에 연결되고, 게이트웨이가 Wi-Fi/이더넷 기술을 이용해서 인터넷에 연결되는 형태

3가지 분류 중 이슈가 되는 것은 Non-IP 기기다. 과거에는 시장의 요구가 저비용 측면에 무게 중심이 있었다. 따라서 낮은 칩셋 사양을 선택하여 비용을 줄이는 대신, 상대적으로 가벼운 무선 연결성(Connectivity) 기술을 사용한 Non-IP 기기가 등장했다. 이런 기기들은 IP 기반이 아니므로 인터넷에 연결되려면 게이트웨이를 필요로 하며, 이로 인해 네트워크 복잡도가 높아진다는 단점이 있다. 또한 기기와 게이트웨이 간 통신 프로토콜이 수십 가지에 이르기 때문에 서로 다른 네트워크를 사용하는 기기간에 통합적인 연동이 어렵다는 문제도 있다. 

이러한 연결성의 복잡성 문제를 해결하려면 Non-IP 기기를 IP 기기화하면 된다. 즉, Non-IP 기기에 IP 프로토콜 스택을 탑재하는 것이다. 하지만 Non-IP 기기 가운데 ‘경량 디바이스’의 경우에는 IP 프로토콜 스택을 탑재하는데 있어서 저비용, 저출력, 칩셋 성능, 저전력, 배터리 지속 시간 등 고려해야 할 요소가 많다. 이는 IoT 확산을 위해 반드시 해결해야 할 중요한 과제다. 이를 위해 LR_WPAN 활용, 구글 스레드(Google Thread) 및 ARM mbed RTOS 등장 등 다양한 시도들로 적절한 타협점을 찾아가고 있다.

LR_WPAN(802.15.4)

802.15.4 radio 대역은 ‘LR_WPAN(저속 개인무선사설 네트워크)’로 불린다. 주로 저속의 데이터를 주고 받는 센서 네트워크의 물리적 계층(physical layer)으로 활용되고 있다.

저속이라서 그 중요성이 간과될 수 있지만, 사실 IoT에 최적화된 무선 기술이 바로 802.15.4이다. 센서 노드는 간단한 센싱과 짧은 데이터 전송만을 필요로 하므로 빠른 전송 대역을 요구하지 않는다. 오히려 전송 속도가 빨라지게 되면 그 속도를 처리하기 위해서 기기의 클럭이 높아지고, 그로 인해 소모 전력도 높아져서 배터리 지속 시간이 짧아지는 문제가 있다. 전원 연결 없이 배터리만 장착하여 무선으로 통신하는 기기에서 배터리 지속 시간은 가장 큰 화두다.

[그림 2] LR_WPAN PHY/MAC 계층 구조

구글 스레드

현재 센서 네트워크에서 802.15.4의 상위단 프로토콜로 Zigbee를 널리 사용하고 있다. 하지만 Zigbee는 IP 기반이 아니기 때문에 IoT 시대에 맞지 않는다는 것이 결정적 문제다. 이러한 배경 하에 구글 네스트는 2014년, zigbee의 대항마로 스레드를 출범시켰다. 등장한지 얼마 되지 않았지만 빠르게 성장하고 있다.

스레드는 zigbee와 유사하지만 IPv6를 기반으로 하고 있다는 것이 차이점이다. [그림 3]에서 볼 수 있듯이 구글이 새로운 규격을 정의한 것이 아니라 기존에 있던 프로토콜을 차용했을 뿐이다. 대신 LP_WPAN 네트워크 구성과 이에 대한 IP 할당 정책, 커미션 정책을 정의했고 관련 기기의 역할을 명확히 기술하여 제조사의 참여를 이끌어 냈다. ‘border router’, ‘leader’, ‘router’ 등이 스레드에서 정의한 기기다.

[그림 3] IoT를 위한 구글 스레드 스택(*출처: http://threadgroup.org)

[그림 4] 구글 스레드 네트워크 구조(*출처: http://threadgroup.org)

ARM mbed

ARM사는 센서 칩으로 많이 활용되는 Cortex-M 칩셋을 겨냥해 운영체제 ‘mbed’를 내놓았다. 기존에 펌웨어가 차지했던 자리를 RTOS로 대체하겠다는 의지가 읽힌다. 간단한 센싱과 데이터 전송만을 생각한다면 굳이 운영체제가 필요한지 의문을 품을 수 있다. 추가적인 명분이 필요한데 두 가지를 꼽자면, 보안과 기기 관리다. mbed OS는 IP 프로토콜 스택 뿐만 아니라 보안 라이브러리, 기기 관리 에이전트를 통합 내장하기 때문에 거부할 수 없는 매력이 있다.

최근 발표된 ARM Cortex-M23과 Cortex-M33 칩셋은 모바일 칩셋에서 사용하는 TrustZone 기술을 적용했으며, CryptoCell 보안 모듈을 내장하여 코드와 데이터의 변조를 방지하고 기밀을 보호해 SoC 보안을 강화하고 있다.

[그림 5] IoT를 위한 ARM mbed OS 플랫폼(*출처: http://www.mbed.com)

RESTful한 COAP 통신

경량 디바이스는 IP 프로토콜 스택 탑재 관련 문제 외에도 COAP 통신 방식과 관련하여 해결해야 할 과제가 있다. COAP는 IETF(국제 인터넷 기술위원회)에서 만든 HTTP 프로토콜의 경량화 버전으로, 소형 사물인터넷 기기 간 통신 프로토콜을 말한다. IETF는 모든 기기에 IP 프로토콜 스택을 탑재하고, 상위 전송 프로토콜로 COAP을 사용할 것을 강력히 권고하고 있다.

경량 디바이스가 COAP 프로토콜을 사용하면 연결성 문제는 해소할 수 있지만, COAP 통신을 REST 설계 철학에 근거하여 접근해야 한다는 권고 사항을 추가적으로 충족시켜야 한다.

REST 설계 철학에서, 모든 장치나 정보는 식별자(URI)를 가진 자원(resource)으로 표현한다. 자원에 대한 접근은 CRUD(Create, Read, Update, Delete)로 단순하게 정의할 수 있다. ‘두 기기가 통신한다’는 의미는 상대방 자원의 위치(URI)와 접근 방식(Method)을 지정하여 상대에게 보내면, 상대방이 그 요청에 대한 응답을 보내는 것이다.

따라서 RESTful 통신 방식의 핵심은 ‘Request URI’와 ‘Request Method’다. 그런데 Request URI를 결정하는 것은 기기 내부의 리소스 모델링이다. 리소스 모델링은 응용 프로그래머에게 맡길 수도 있지만 요즘은 리소스 스키마 정의로 공통의 규칙을 확립하여 IETF의 권고 사항을 충족시켜줄 단체들이 생기고 있다. 대표적으로 oneM2M과 OCF가 있다.

oneM2M의 핵심 참여 그룹은 TTA 등의 표준협회와 통신사업자이다. 반면에 OCF는 삼성과 인텔등 제조사들이다. 리소스 형식은 당연히 양 진영이 다르겠지만 내용적인 측면에서는 유사하다고 볼 수 있다. 한 가지 큰 차이점은, 리소스 디스커버리 방식이다. oneM2M은 서버에 모든 리소스를 등록해놓고, 서버를 통해 리소스를 접근하는 방식을 선호한다. 반면 OCF는 멀티캐스트 등의 방법을 사용하여 로컬 영역에서 다른 기기의 리소스를 발견하여, 서버 없이도 기기 간 통신이 가능하도록 했다.

[그림 6] 프로토콜 계층별 표준화 동향

COAP 통신 시 ‘인증’과 ‘인가’ 보안 체크

마지막으로 경량 디바이스에서 COAP 통신으로 기기 간 통신 시 체크해야 할 보안 요소가 두 가지 있다.

먼저 리소스를 요청한 상대가 누구인지 확인해야 한다. 그 다음 상대방이 해당 리소스를 접근할 권한이 있는지 확인한다. 전자를 ‘인증(Authentification)’이라고 하고, 후자를 ‘인가(Authorization)’라고 한다. 두 과정을 모두 통과한 후에야 자원에 대한 접근 요청을 처리하게 된다.

인증은 ‘COAP over DTLS’ 통신 프로토콜 단에서 처리가 된다. DTLS는 TLS의 데이터그램 버전으로, TLS의 핸드쉐이크 과정에는 상호 인증 절차가 있다. 이를 사용하여 인증을 수행한다.

반면 인가는 기기 내부에 ACL(Access Control List) 정책을 갖고 있어서 자원에 대한 접근 가능 여부를 판단하게 된다.

[그림 7] 경량 디바이스의 보안을 위한 인증과 인가

인증이나 인가를 적용하기 위한 선결 과제로서 기기에 키를 안전하게 배포하는 방안 및 엔드 포인트에서의 키 보호 방안 마련이 필수인데, 이에 대한 안전하면서도 편리한 운용성을 갖춘 솔루션은 아직 등장하지 않은 상태다.