IoT 기술과 스마트 공간이 새로운 기술 혁명을 시작할 것으로 기대되지만, 수십억 개의 IoT 장치가 상호 통합되지 않은 상태로 존재하여 업계의 발목을 잡고 있습니다. IoT 장치가 직면한 문제점과 솔루션은 무엇이며 엔지니어는 어떻게 해야 할까요?
IoT의 최대 약점: 파편화
현재 전 세계에 있는 IoT 장치는 총 140억 개가 넘을 것으로 추정되는데, 실로 놀라운 수치입니다. 2024년에는 무려 200억 개에 달할 것으로 예측됩니다. 전 세계에서 장치 수를 파악하는 것도 어렵지만 생산되는 데이터 양도 엄청납니다. IoT 기술의 발전과 생성되는 데이터의 양으로 인해 AI, 머신 러닝 등과 같은 산업이 가속화하고 대규모로 확장함에 따라 이제 AI는 일상 생활에서 보편화되고 있습니다.
시장에 나와 있는 많은 IoT 장치와 수많은 스마트 홈 옵션에도 불구하고 가정에서 사용되는 대부분의 IoT 장치는 스마트와 거리가 멉니다. 실제로 가정에서 사용되는 대부분의 IoT 장치는 단순히 인터넷에 연결된다는 이유로 IoT 장치로 분류되지만, 다른 시스템과 데이터를 공유하지도, 실시간에 이벤트에 지능적으로 대응하지도 못하여 전혀 스마트하지 않습니다. 게다가 대부분의 가정에서는 기본적으로 스마트 기술을 통합하지 않아 대부분 무능합니다.
IoT 홈 통합을 어렵게 만드는 다양한 요소가 있지만 단연코 가장 큰 원인은 파편화입니다.
IoT 파편화란?
IoT 산업에는 파편화로 직면한 문제를 완벽하게 설명하는 한 가지 농담이 있습니다. 간단히 말해서 엔지니어가 14개의 IoT 표준이 있다는 것을 인식하고 모두가 사용할 수 있는 단일 표준을 만들기로 결정하지만, 그 결과 15개의 표준이 존재하게 됩니다.
안타깝게도 이 농담은 현실을 정확히 반영하며, IoT 장치를 설계 및 제조하는 수백 또는 수천 개 IoT 기업과 엔지니어의 실상을 그대로 보여 줍니다. 이러한 기업은 대부분 가장 적합하다고 생각하는 자체 표준을 만들며, 맞춤형 프레임워크 내에서 작동하는 전체 솔루션 에코시스템을 구축하는 경우도 있습니다. 이는 한 제조업체의 IoT 솔루션만 이용하는 고객에게는 유용할 수도 있지만, 스마트 공간의 통합을 저해하는 수많은 문제를 야기합니다.
이러한 문제가 제기하는 첫 번째 과제는 다양한 제조업체의 장치를 결합하는 복합 IoT 솔루션을 구축하는 일이 어렵다는 것입니다. 예를 들어 스마트 홈에는 스마트 초인종, 스마트 전력 소켓, 스마트 조명, 스마트 온도 조절장치 등 다양한 스마트 장치가 필요합니다. 이러한 모든 장치가 시장에 나와 있지만 모든 장치를 공급하는 단일 제조업체나 공통 프로토콜을 지원하는 다른 제조업체를 찾는 것은 거의 불가능합니다.
IoT 파편화로 인한 두 번째 과제는 스마트 홈을 위한 소프트웨어 지원이 부족하다는 것입니다. 각 제조업체가 자체 표준을 만드는 것처럼 장치를 제어하고 데이터를 읽는 데 사용되는 자체 소프트웨어 플랫폼을 구축하는 경우도 있지만, 다른 제조업체에서 사용하도록 API를 노출하는 일은 거의 없습니다. 따라서 IoT 장치의 소프트웨어 측면도 파편화되어 다른 개발자로부터 차단될 수 있습니다.
마지막으로 단일 제조업체의 IoT 솔루션만 이용하는 고객은 브랜드의 덫에 갇힐 수 있으며, 최악의 경우 해당 브랜드의 모든 결정을 맹목적으로 따라야 할 수 있습니다. 예를 들어 Hive는 보안 카메라, 누수 탐지기 등 다양한 HomeShield 제품의 지원을 중단한다고 최근에 발표했습니다. 이러한 장치에 대한 업데이트 및 서비스가 중단될 경우 고객은 온전히 작동하는 IoT 장치를 제거하고 폐기하는 수 밖에 없습니다.
Matter란?
IoT 장치가 직면한 다양한 문제를 인식하여, 이에 대응하고자 대규모 기술 기업으로 구성된 단체가 새로운 IoT 프로토콜인 Matter를 개발했습니다. Matter의 출시도 여전히 새로운 표준을 만든다는 이전의 농담을 따르지만, Google, Meta 등 많은 주요 기술 기업에서 이 플랫폼을 지원함에 따라, 순전히 관련 기술 기업의 규모로 인해 제조업체들이 해당 표준에 대한 참여를 강요받게 됩니다.
본질적으로 Matter는 제조업체에서 인증 비용만 지급하면 무료로 인가되는 홈 자동화를 위한 독점 표준입니다. 인증 비용에도 불구하고 Matter는 완전히 공개되는 오픈 소스로서, 사용자가 코드를 확인하고 편집 및 버그 수정을 제안할 수 있습니다. 인증을 받지 않을 경우 어떤 불이익을 받을지 명확하지 않지만, 제품에 Matter 이름과 로고가 표시되지 않을 수 있습니다. 즉, 제품이 Matter와 호환될 수는 있더라도 해당 사실을 광고할 수 없습니다.
2019년에 Matter 프로젝트가 시작된 이래 IKEA, Amazon, Google, Apple, Zigbee Alliance를 비롯한 수많은 제조업체와 기업이 공개 지원을 발표했습니다. 하지만 이 프로토콜은 2022년 10월에 공식적으로 발표된 만큼 아직 주류가 되거나 폭넓은 커뮤니티에서 채택되고 있지 않습니다. 또한 현재 버전의 Matter는 조명 제품, 메인 스위치, 온도 조절장치, 도어락, 난방 시스템, 환기, 보안 센서, TV, 블라인드 등 일반 가정용 장치를 지원합니다. 2024년 3월에 발표될 예정인 다음 버전에서는 로봇 진공청소기, CO 센서, 연기 알람, 에너지 관리, Wi-Fi, 카메라, 기타 주요 가정용 기기를 포함하도록 지원 장치 목록을 확장할 계획입니다.
Matter의 대안이 있는가?
현재로서는 Matter와 동일한 수준의 지원을 제공하는 IoT 표준은 없지만, 엔지니어가 체계적으로 연동되는 장치를 만드는 데 도움이 되는 다른 표준이 없는 것은 아닙니다.
대부분의 웹 서버에서 기본적으로 지원하는 REST 및 HTTP는 IoT 통신 부문에서 훨씬 인기 있는 방법입니다. 즉, IoT 장치가 PHP 또는 Node.js로 코딩된 표준 웹 서버로 데이터 패킷을 전송할 수 있다는 것을 의미하며, 이러한 프로토콜은 웹사이트를 구동하는 데 사용되는 데이터베이스를 IoT 데이터를 저장하는 데에도 사용할 수 있으므로 데이터를 쉽게 확인할 수 있다는 추가적인 이점이 있습니다. 따라서 이론적으로 전체 IoT 솔루션이 단일 웹 서버에 통합될 수 있습니다.
HTTP 및 REST의 대안은 웹 소켓을 사용하는 것입니다. PHP, HTML, JavaScript는 모두 웹 소켓을 지원하므로 IoT 장치에 중요한 선택지가 되지만, HTTP 및 REST가 단일 패킷 메시지인 경우 완료 후 연결이 닫히므로 웹 소켓을 열린 상태로 둘 수 있으므로 대량의 데이터를 스트리밍하는 데 유용합니다.
마지막으로 MQTT는 전 세계에서 수백만 대의 장치에서 사용되는 다른 인기 있는 프로토콜입니다. 석유 및 가스 산업용으로 처음에 개발된 MQTT는 전체 장치 네트워크에서 특정 변수를 게시 및 구독할 수 있습니다. 또한 MQTT는 경량적 특성으로 인해 저에너지 및 로우엔드 마이크로컨트롤러에 적합합니다. 또한 프로토콜이 간소하여 MQTT를 맞춤식으로 손쉽게 구현할 수 있으며, 온라인에 채택 가능한 많은 예제가 나와 있습니다.
엔지니어는 어떻게 해야 하는가?
HTTP 및 MQTT에서는 모두 설계자가 API를 노출하여 적어도 다른 제조업체에서 장치와 인터페이스 가능한 선택지를 제공할 수 있습니다. 또한 서로 다른 두 표준을 연결하는 브리지 소프트웨어를 구축할 수 있습니다. 브리지 소프트웨어는 제품이 다른 제조업체와 연동하도록 도와주는 역할만 합니다.
이외에도 Matter 자체는 역사가 짧고 설명서가 매우 세부적이고 복잡하며 Matter가 모든 IoT 제품에 가장 적합한 솔루션은 아니므로 엔지니어가 정확히 어떻게 해야 하는지는 말하기 어렵습니다. 물론 새로운 표준을 만드는 것은 전혀 도움이 되지 않는다는 것이 명백히 입증되었으므로, 엔지니어는 가능하면 새로운 표준을 만드는 것을 피해야 합니다.
한 가지 가능한 솔루션은 엔지니어가 현장에서 쉽게 변경할 수 있는 오픈 소스 디자인에 주력하는 것입니다. 예를 들어 무선 업데이트를 지원하는 Linux 시스템에서 IoT 장치를 만든다면 이론적으로 미래에 Matter가 프로토콜로 확립되었을 때 Matter를 지원하도록 업데이트할 수 있습니다.
다른 솔루션은 엔지니어가 HTTP, REST와 같은 주류 솔루션을 고수하고 API를 공개하여 Matter가 제품을 어느 정도 지원할 수 있기를 바라는 것입니다. 실제로 IoT 장치와 Matter 서버 사이에 웹 인터페이스를 만들어 둘 사이의 메시지를 해석할 수 있습니다.
하지만 Matter가 존재한다고 해서 사용해야 한다는 것은 아닙니다. 디자인에 꼭 필요하지 않을 경우 단순히 지원을 위해 Matter를 통합하는 것은 득보다 실이 더 클 수 있습니다. 알려지지 않은 버그가 Matter에 퍼져 있을 경우 특히 그렇습니다.
