사물인터넷(IoT, Internet of Things) 활용 사례를 개발하는데 있어 실시간 커뮤니케이션 기술는 필수적인 요소다. 스마트폰이 거실의 전등과 커뮤니케이션 하는 상황을 상상한다면 이해하기 쉬울 것이다. 우리는 당연히 스마트폰의 스크린을 탭하는 그 순간 전등이 켜질 것이라 기대하고 있다.
실시간 커뮤니케이션 테크놀로지 개발을 설명할 때 빠지지 않고 언급되는 주제가 인스턴트 메시지다. 지금까지의 인스턴트 메신저들은 누구나 쉽게 이용할 수 있는 인터넷 연결형 실시간 커뮤니케이션 클라이언트들이었다. AOL IM, ICQ, 재버(Jabber) 등이 1990년대 실시간 커뮤니케이션을 지원한 인스턴트 메신저 클라이언트의 좋은 예다.
요즘에는 IoT 기기들 간 커뮤니케이션을 위한 프로토콜 개발이 이목을 집중시키고 있다. 이를 위해 인스턴트 메시징 솔루션을 만들면서 배웠던 교훈들을 다시 살펴보기도 한다.
참고로 오늘날 IoT 기기들에 쓰이는 주요 실시간 프로토콜들은 XMPP, CoAP, MQTT의 3가지다. 특히 XMPP의 경우 오픈 인스턴트 메신저 프로토콜인 재버로 처음 시작된 것이기도 하다.
XMPP
XMPP(eXtensible Messaging and Presence Protocol)는 2인 이상의 참여자 간에 구조적 데이터를 거의 실시간에 가깝게 교환할 수 있게 해주는 XML 기반 TCP 커뮤니케이션 프로토콜이다.
XMPP의 기능들 중에는 대화 참여자 정보를 보여주는 것과 연락처 리스트 관리 기능이 있다. 두 기능 모두 인스턴트 메시징을 위해 제작된 것이었지만 IoT에도 적용할 수 있다.
XML 재단과 XMPP자체의 열려 있는 성질 때문에 XMPP는 퍼블리TL/섭스크라이브 (publish/subscribe) 시스템에도 사용되고 있다. XMPP가 IoT 애플리케이션과 찰떡 궁합인 또 하나의 이유다.
IoT 커뮤니케이션 프로토콜로 XMPP를 사용하는 것에는 여러 가지 큰 장점이 있다. 우선 XMPP의 분산화된 성격이 큰 장점이다. XMPP의 작동 방식은 이메일과 비슷하다. CoAP나 MQTT처럼 하나의 중앙 서버나 브로커에 의지하기보다는 여러 트랜스퍼 에이전트(transfer agents)에 걸쳐 작동하는 것이 특징이다.
이메일과 마찬가지로 누구나 자신의 XMPP 서버를 운영할 수 있어 기기 제조업체나 API 오퍼레이터가 자신만의 기기 네트워크를 형성하고 관리할 수 있다. 또한 누구나 서버를 운영할 수 있기 때문에 보안이 요구되는 경우 내장 TLS 암호화를 사용해 회사 인트라넷에서 안전한 인증 프로토콜을 이용해 고립시킬 수 있다.
물론 XMPP에는 단점도 있다. 가장 큰 단점은 바로 엔드-투-엔드 암호화가 안 된다는 것이다. 물론 암호화가 굳이 필요하지 않은 경우도 있지만, 대부분 IoT 기기들은 암호화를 필요로 한다. 엔드-투-엔드 암호화가 안 된다는 것은 IoT 기기에 있어서는 큰 단점이 아닐 수 없다.
또 다른 단점은 QoS(Quality of Service)의 부재다. 메시지가 제대로 전달 되었는지 확실히 하는 것은 인스턴트 메시지를 보낼 때도 중요하지만 IoT에서는 더더욱 중요하다. 예를 들어 아침에 깨워달라는 메시지가 알람 시스템에 제대로 전달되지 않는다면 고대하던 휴가를 망쳐버릴 수도 있다.
CoAP
CoAP(Constrained Application Protocol)는 리소스 제약이 있는 기기들이 인터넷 상에서 TCP 대신 UDP를 사용해 커뮤니케이션 할 수 있도록 개발됐다. 개발자들은 전통적인 방식의 REST 기반 API를 사용하는 여느 기기와 마찬가지로 CoAP 기기를 다룰 수 있다. CoAP는 특히 인터넷을 통해 컨트롤 해야 하는 저출력 센서 및 기기와 커뮤니케이션 하는데 유용하다.
CoAP는 단순한 리퀘스트/리스펀스 프로토콜로(REST와 매우 비슷하다) 전통적인 클라이언트/서버 모델을 따르고 있다. 클라이언트는 GET, PUT, POST, DELETE 요청을 할 수 있다. CoAP 패킷은 비트필드(bitfields)를 이용해 메모리 효율을 극대화 하고 데이터 패킷을 온-디바이스로 트랜스포트 할 수 있을 정도로 작게 유지하기 위해 스트링~인티저(strings to integers) 매핑을 광범위하게 사용한다.
매우 작은 패킷 사이즈 외에 CoAP의 또 다른 장점은 바로 UDP의 사용이다. 데이터 그램을 사용하기 때문에 SMS같은 패킷 기반 테크놀로지보다 성능이 뛰어나다.
모든 CoAP 메시지는 ‘확인 가능’ 또는 ‘확인 불가능’으로 표시될 수 있어 애플리케이션 레벨의 QoS로 행동할 수 있다. SSL/TLS 암호화가 UDP에서는 불가능 하지만 CoAP는 TLS의 TCP버전과 비슷한 DTLS(Datagram Transport Layer Security)를 사용한다.
디폴트 암호화 레벨은 3,072-비트 RSA 키와 동등하다. 그럼에도 불구하고 CoAP는 10KB 정도의 아주 작은 램이 장착된 마이크로 컨트롤러에서 작동하도록 설계됐다.
CoAP의 단점 중 하나는 원-투-원 프로토콜이라는 점이다. 그룹 브로드캐스트를 가능하게 한 확장을 이용할 수도 있지만 브로드캐스트 기능은 원-투-원 프로토콜에 내재적인 것이 아니다. 게다가 더 큰 단점은 퍼블리시-섭스크라이브 메시지 큐의 부재다.
MQTT
MQTT(Message Queue Telemetry Transport)는 퍼블리시/섭스크라이브 메시징 프로토콜로, CoAP와 마찬가지로 자원 제약이 있는 기기를 타깃으로 개발됐다. MQTT는 메모리 및 전력 이용을 효율화하기 위한 가벼운 패킷 구조를 채택하고 있으며, 여기에 연결된 기기는 MQTT 브로커 상에 호스팅 되는 토픽에 인용된다. 어떠한 기기나 서비스가 데이터를 토픽에 발행하면, 여기에 인용된 모든 기기들은 자동적으로 갱신된 정보를 획득하게 된다.
MQTT의 주된 장점으로는 퍼블리쉬/섭스크라이브 메시지 큐(message queue)와 다-대-다 송출 기능이 이야기된다. MQTT 브로커에 수명이 긴 방출 TCP 연결을 이용하고 제한된 대역폭의 메시지를 전후방으로 전송함으로써 MQTT는 간결함과 직관성을 보장한다.
하지만 이처럼 항시 연결을 유지하는 구조는 기기의 휴식 시간을 제한한다는 단점을 지니기도 하는데, MQTT는 기기의 대부분이 휴식하는 시점에도 다른 MQTT 프로토콜인 MQTT-S(TCP가 아닌 UDP와 동작한다)를 활용함으로써 이러한 문제를 방지한다.
사물인터넷의 ABC
MQTT의 또 다른 단점은 베이스 프로토콜의 암호화 부재다. MQTT는 가벼운 프로토콜로 제작되었고 여기에 암호화를 더하게 되면 커넥션에 엄청난 오버헤드를 더하게 될 것이다. 때문에 커스텀 보안을 애플리케이션 레벨에서 더할 수는 있지만 그러려면 꽤 성가신 작업이 될 수도 있다.
기저 프로토콜에 대한 이해는 IoT 기술의 장점을 십분 누리고자 하는 개발자들에게는 매우 중요하다. IoT에 대한 관심이 높아질수록 기기간의 효율적 커뮤니케이션을 위해 필요한 것이 무엇인지 더 많은 이들이 궁금해 할 것이다.
또한, 기기와의 상호작용뿐 아니라 기기를 컨트롤 할 수 있는 API를 제작하는 이들에게 있어 실시간 커뮤니케이션은 필수다. 처음에는 인터넷을 통해 커뮤니케이션 할 수 있도록 개발되었던 것이 시간이 지나며 훨씬 더 다재다능한 무언가로 변해가고 있는 것이다.
개발자들은 언제나 가능한 모든 선택권을 열어두는 습관을 가져야 한다. 이용 가능한 프로토콜 유형과 그들 각각의 장단점을 이해하는 것은 좋은 상품을 개발하는데 반드시 필요한 노력이다.
또한 자신의 테크놀로지 프로필에 실시간 커뮤니케이션 역량을 더하는 것 역시 개발 과정을 개선하는데 많은 도움을 줄 것임을 기억하자. 아직 시장에 실시간 커뮤니케이션을 지원하는 백 엔드 서비스는 그리 많지 않은 것이 현실이다.
IoT 플랫폼 개발에 파이어베이스(Firebase)나 소켓.io(Socket.io)m 빌트.io(Built.io)를 이용한다면 개발 시간을 큰 폭으로 절감하는 것이 가능하다. 그러나 이들 역시 모든 상황의 만능 열쇠는 아님을 잊지 말자. 처한 상황에 가장 적합한 옵션을 찾는 것은 언제까지나 자신의 몫이다.
* Kurt Collins는 인포월드닷컴 뉴 테크 포럼에 기고하는 전문 기고가다. 뉴 테크 포럼에서는 부상 중인 엔터프라이즈 기술에 대한 소개와 논의를 다룬다. dl-ciokorea@foundryco.com
