차완기 - @6/8/2024, 10:02:00 PM 
Wikipedia - Matter logo.jpg [링크]
IoT판 갈라파고스
여태껏 IoT를 표방하던 스마트 기기들은 서로서로가 갈라파고스 그 자체였습니다.
더 이상 스위치에 롤휴지를 던지지 않기 위해, 내지는 동생을 부르지 않기 위해 스마트한 방을 꾸며봤다고 가정하죠. 원격으로 끄고 켤 수 있는 전등 스위치와 조명, 스마트 공기청정기 등이 사용될 것입니다. 그런데, 전등 스위치는 적외선 리모컨으로, 조명은 블루투스로, 공기청정기는 전용 어플리케이션으로 조작된다면 어떨까요?
물리적인 버튼을 클릭하지 않을 뿐, 번거로운 것은 마찬가지겠죠. 동생에게 시킬 명분이 사라질 뿐입니다.
적외선 IoT 스위치.... 는 제쳐두고 어떻게든 인터넷에 연결되는 사례를 살펴보죠.
.. 는 제쳐두고 어떻게든 인터넷에 연결되는 사례를 살펴보죠.
파워매니저 - AI 조명스위치 판매 페이지 중 일부 [링크]
시중에서 판매되는 스마트홈 기기들을 훓어보면 와이파이를 통해 인터넷에 연결되는 기기도 있는 한편, ZigBee니 블루투스니 하며 자기네들의 전용 게이트웨이를 구매하라는 사례가 많은 편입니다.
Internet of Things, 말 뜻 그대로 인터넷에 연결된 기기들이라면서 뭔가 사기당한 느낌이 들죠. 무선 통신이라면서요. 그냥 이걸 바로 와이파이에 연결할 수는 없을까요?
네, 불가능합니다. 이건 프로토콜의 문제입니다.
위에서 예시로 든 ZigBee는 전파(RF)를 사용하는 통신 프로토콜입니다. 똑같이 전파를 사용하는 Wi-Fi와 호환이 될 것 같지만, 서로 사용하는 언어가 달라 연결이 불가능하다고 생각하면 이해가 쉽지 않을까 싶습니다. (정확히는 기술 표준이 서로 다릅니다. IEEE 802.15.4와 802.11의 관계죠 )
)ZigBee는 저전력을 고려했다는 점과 강력한 메쉬 네트워크 지원이, Wi-Fi는 높은 전력소비를 보여주는 반면 빠른 통신속도를 자랑합니다. 모든 ZigBee맛 장치를 Wi-Fi맛으로 출시할 수 없는 이유입니다.
아무튼 다시 돌아와 다양한 스마트 디바이스에 걸쳐 각기 다른 프로토콜을 사용하다 보니, 인터넷 공유기 하나로 해결이 되지 않고 제조사마다 전용 라우터를 구매해야하는 상황이 생기기 시작합니다. 제조사의 전용 소프트웨어가 점점 늘어나는것은 덤이죠.
Apple Developer - discover [링크]
특정 브랜드의 기기만으로 생태계를 조성한다는 것은 사용자 측면에서는 편리함을, 브랜드 측면에서는 독점이라는 이점을 가져다 주기 때문에 분명히 매력적일 수 있겠지만, 스마트홈 이라는 주제가 워낙 넓다 보니 어떤 한 브랜드의 제품만으로 스마트홈을 꾸미는 것은 불가능에 가까워 보입니다.
이런 상황에서 결심을 한 것인지 아마존, 애플, 구글 등의 회사가 힘을 합쳐 Matter라는 표준을 만들었습니다.
Matter
앞서 제가 주장한 “IoT판 갈라파고스”의 문제는 대략 두 가지라 할 수 있어보입니다.
•
서로 호환이 불가능한 프로토콜의 산재
•
열악한 스마트홈 플렛폼별 호환성
플렛폼별 호환성이야 공통된 API를 만들거나 Home Assistant같은 중간다리를 만들면 쉽게 해결되겠지만, 서로 호환이 불가능한 프로토콜을 하나로 합치는건 물리적으로 불가능에 가깝습니다. (앞서 짧게 언급했듯이 ZigBee와 Wi-Fi만 보더라도 용도가 다르기 때문이죠)
프로토콜의 통합
그럼 어떻게 해야 할까요?
피라미드를 쌓으면 됩니다. 하나로 합칠 수 없는 여러 프로토콜을 테이블 위에 펼쳐두고 이걸 서로 묶어줄 무언가를 위에 붙이면 되는 것이죠.
Nordic - Matter architecture and integration [링크]
참 쉽죠?
위 사진은 현재의 Matter가 CHIP(Project Connected Home Over IP)라 불리던 시절, 꿈과 희망을 담아(?) 만든 아키텍처 피라미드입니다.
아래 빨간색으로 표시해둔 부분을 살펴보면 셀룰러(LTE같은), 이더넷, Wi-Fi, 802.15.4(a.k.a. ZigBee), BLE 등이 IPv6로 묶여있고, 가장 윗쪽에는 개명 전의 Matter인 CHIP가 위치해 있습니다.
즉, 여러 프로토콜을 IPv6로 묶어다가 Matter 표준을 구현한 것이죠.
물론 이건 Matter의 희망편일 뿐이고, 현재의 Matter는 아래와 같습니다. (v1.3 기준)
Google - What is Matter? [링크]
Wi-Fi, Ethernet, 그리고 802.15.4 위에 IP(Internet Protocol)가 붙어있는게 보이죠. 이처럼 Matter 표준은 모든 장치에게 IP 주소를 부여해 통신을 가능하게 합니다.
IEEE 802.15.4 vs ZigBee
ZigBee 프로토콜은 IEEE 802.15.4라는 표준을 통해 만들어졌습니다. 802.15.4는 저전력 통신을 위한 물리적인 부분을 정의하고 있고, ZigBee는 이를 활용해 만들어진 기능 정도로 설명하고 넘어가겠습니다. 앞으로 802.15.4를 언급하면 ZigBee를 떠올리면 되겠습니다.
그런데, 위의 다이어그램을 유심히 살펴보면 Wi-Fi나 Ethernet는 OSI 1~2계층인 물리, 데이터 링크 계층에 얌전히 있는 반면, 802.15.4는 Thread가 찰싹 달라붙어, 네트워크 계층의 IP에 파묻혀 있다는 것을 알 수 있습니다. 참고로 구석에 찌그러져 있는 Bluetooth LE는 디바이스를 보더 라우터(ZigBee의 코디네이터 같은)에 연결하는 과정에서만 사용합니다.
MICROCHIP - Thread Protocol Products [링크]
이는 802.15.4에서 IP를 지원하기 위함인데요, Thread의 아키텍처를 설명하는 위 사진을 살펴보면 ZigBee의 표준인 802.15.4 위에 6LoWPAN 등이 달라붙어 있는 것을 알 수 있습니다. 즉, Matter 표준에서의 기존 ZigBee 장치는 IP 주소를 부여받아 ping을 날릴 수 있다는 것입니다. 정말 신기하지 않나요?
종합하자면 Matter 표준을 사용하면 Wi-Fi, ZigBee 등 각각의 표준으로 산재된 프로토콜을 하나로 뭉쳐줄 수 있게 됩니다. 지금은 이정도이지만, 추후 BLE, 셀룰러 등도 지원할 예정이라 하니 Matter로 넘어갈 가치가 있겠죠.
플렛폼간 호환성
앞에서는 프로토콜의 호환에 대해 살펴봤다면, 여기서는 플렛폼간의 호환성에 대해 살펴보겠습니다.
csa Matter Specification 1.3 - Figure 5. Star network topology
Matter 표준을 지원하는 장치가 네트워크에 연결되기 위해서는 “보더 라우터”가 필요합니다. 사진에서 초록색 사각형으로 표시되는 장치인데요, Wi-Fi에 연결되는 장치는 AP와 라우터를 통해 간접적으로, Thread에 연결되는 장치는 직접적으로 연결됩니다.
보더 라우터는 대표적으로는 Apple의 HomePod이나 Google의 Nest Hub가 있는데요, 제조사별로 스마트홈의 중심이라 생각되는 기기가 보더 라우터의 기능을 겸하게 되는 방식입니다. 또한 각각의 보더 라우터들은 근처에 있다면 Thread, 멀리 있다면 Wi-Fi를 통해서 서로 연결되게 됩니다.
당연하게도 Apple Home이나 Google Home을 통해 Matter 표준으로 연결된 기기들을 제어할 수 있고, “Multiple Fabrics” 기능을 통해 다른 보더 라우터에 등록된 장치도 제어할 수 있습니다.
csa Matter Specification 1.3 - Figure 40. principle of bridging
또한 기존의 ZigBee나 Z-Wave처럼 비-Matter 기기라 하더라도 Matter Fabric에 연결해 제어할 수 있는 기능을 제공합니다.
마무리
여기까지 Matter에 대해 간략히 알아보았습니다.
사실 Arduino Nano Matter를 테스트하며, IPv6에 삽질을 당해 Thread에 IPv6가 필요한 이유를 정리하고자 하려 했던건데요, 어쩌다 보니 Matter에 대한 전반적인 내용을 설명하게 되었네요.
이번 포스팅을 통해 IPv6가 필요한 이유 하나는 확실히 알게 된 것 같습니다. 이제 다시 돌아가 Nano Matter를 핸즈업하며 알게 된 내용이 또 생기게 된다면 포스팅으로 돌아오겠습니다
