이 노트에 대하여
이 노트는 지능형홈 허브 메모를 상향 조정하여, 힣이 왜 네트워크 스택을 하나의 철학으로 통합하려 하는지 정리한다. Matter·Thread·Wi-Fi·Ethernet을 중심축으로 보고, Zigbee·Z-Wave는 레거시 호환과 브리지 전략으로 재배치하며, 홈과 공장, 엣지와 온프레미스를 함께 덮는 토폴로지를 모색한다.
히스토리
- 힣의 네트워크 스택 통합 노트로 상향 조정. 홈/공장 통합 토폴로지 전략 관점 추가
- IKEA DIRIGERA 분석 추가
- 간담회 중에 문서 생성
배경
TTA 지능형 홈 지원 사업 설명회 참석 중 작성한 메모를 기반으로 시작했다. 처음에는 스레드/매터 기반 지능형 홈 지원 사업과 현재 진행 중인 프로젝트들의 연결고리를 정리하는 노트였다.
이제 이 노트는 범위를 넓혀, 힣이 홈과 공장, 엣지와 온프레미스를 관통하는 네트워크 스택 통합 전략 을 사고하는 중심 노트가 된다.
현재 프로젝트
fxf-uho-mvt: Zigbee 기반 허브, Zig 상태머신 아키텍처xlhatqbat-rockchip: RK3588 Android 15, Matter/OpenThread 정부과제matter.js: 현대적 TypeScript 코드베이스 기반 Matter 구현 추적 대상homeagent-config: 허브-에이전트 구조의 산업 확장 가능성 검토 대상
핵심 질문
나는 왜 네트워크 스택을 통합하려 하는가? 물리 계층을 하나로 줄이려는가, 아니면 상위 아키텍처와 운영 모델을 하나로 만들려는가?
현재 답은 후자에 가깝다. “하나의 스택”은 모든 무선을 하나의 라디오로 통일한다는 뜻이 아니라, 장치 모델, 보안, 프로비저닝, OTA, 관리 API, 관측성, 코드 구조를 하나의 철학으로 묶는다는 뜻이다.
프로토콜 비교
현재 전략 요약
- 중심축: Matter + Thread + Wi-Fi/Ethernet
- 보조축: Zigbee / Z-Wave는 레거시 수용과 브리지 전략
- 공장 제어: 실시간성과 안전성 때문에 별도 OT 계층 존중
Zigbee vs Thread
| 항목 | Zigbee | Thread |
|---|---|---|
| 네트워크 | 코디네이터 중심 (허브 필수) | 분산 메시 (Border Router) |
| IP 호환 | 자체 레이어 (게이트웨이 변환 필요) | IPv6 네이티브 |
| 앱 레이어 | ZCL (Zigbee Cluster Library) | 없음 (Matter와 결합) |
| 생태계 | 성숙함 (Tuya, Philips Hue) | Matter의 기본 전송 (급성장) |
Matter의 역할
Matter over Thread: [Matter 앱] → [Thread 전송] → [802.15.4 Radio]
Matter over WiFi: [Matter 앱] → [WiFi 전송] → [WiFi Radio]
Matter over Ethernet: [Matter 앱] → [IP/Ethernet] → [Wired Backbone]Matter는 “무엇을 제어할 것인가”를 정의하는 공통 언어다. 즉 디바이스 타입, 속성, 명령, 상호운용 모델을 통일하는 계층이다. Thread/WiFi/Ethernet은 “어떻게 전송할 것인가”를 담당한다.
이 구분이 중요하다. 힣이 원하는 통합은 전송방식 단일화보다 공통 장치모델과 운영 모델의 단일화 에 더 가깝다.
Z-Wave의 위치
- sub-GHz의 장점이 있어 2.4GHz 혼잡 회피에는 유리하다.
- 하지만 지역별 주파수 SKU 문제와 IP-first 아키텍처와의 거리 때문에 중심축으로 삼기에는 제약이 있다.
- 따라서 현재 판단은 “공장에 들어가려면 Z-Wave가 필수”가 아니라, 필요 시 레거시 또는 특수 커버리지 용도로 수용하는 편이 맞다.
허브 vs Border Router
Zigbee에서 허브는:
- 네트워크 형성
- 디바이스 관리
- 프로토콜 변환
- 클라우드 연결
Thread에서 Border Router는:
- 메시 ↔ IP 연결만
- 네트워크는 디바이스들이 자체 형성
fxf-uho-mvt가 Thread 지원 시: Border Router + Matter Commissioner 역할
나는허브다 철학
상태머신 핵심
┌─────────────────────────────────────────────────────────┐
│ HubState │
│ "나는 허브다. 100ms마다 내 상태를 점검한다." │
├─────────────────────────────────────────────────────────┤
│ - connection_state │
│ - registration_state │
│ - pairing_mode │
│ - zigbee_devices: [] │
│ - *_enter_ms: 상태 진입 시각 │
└─────────────────────────────────────────────────────────┘
│
│ Event (외부 입력)
▼
┌─────────────────┐
│ transition() │ ← 순수 함수, 부작용 없음
└─────────────────┘
│
▼
(next_state, actions[])왜 Zig인가
- 명시적 메모리 제어 - 숨겨진 할당 없음
- C FFI 친화적 - 레거시 SDK 통합
- comptime - 런타임 비용 제거
- error union - 누락 없는 에러 처리
프로토콜 확장 가능성
현재: HubState ──┬── WiFi Layer (IO)
├── Zigbee Layer (IO) ← Coordinator 역할
└── AWS IoT Layer (IO)
Thread 추가:
HubState ──┬── WiFi Layer (IO)
├── Zigbee Layer (IO)
├── Thread Layer (IO) ← Border Router 역할
└── AWS IoT Layer (IO)상태머신 아키텍처가 확장 기반이 됨. IO 레이어만 교체 /추가하면 프로토콜 독립적 CORE/HUB 유지.
네트워크 토폴로지 전략
왜 통합하려 하는가
- 스택 수를 줄여 개발/운영 부담을 줄이기 위해
- 코드베이스를 현대적으로 정리된 라이브러리 위주로 수렴시키기 위해
- 홈과 공장, 생활공간과 산업공간을 하나의 세계관으로 다루기 위해
- Wi-Fi/Ethernet/Thread를 IP 중심으로 엮고 싶기 위해
권장 토폴로지 초안
공통 백본
- Fiber/Ethernet backbone
- 건물 공장 생활공간을 연결하는 유선 중심 백본
- Border Router, 게이트웨이, 서버, 관제 노드는 이 위에 둔다
공통 서비스 계층
- 장치 식별
- PKI / 인증
- OTA
- event/message bus
- 관측성/모니터링
- 디지털트윈 또는 장치 모델 계층
액세스 계층
- 홈 오피스 생활공간: Thread + Wi-Fi + Ethernet
- 공장: 유선 OT 우선, 환경 센서는 필요 시 Thread 또는 별도 sub-GHz 계열 검토
- 레거시: Zigbee/Z-Wave는 브리지로 수용
현재 결론
물리 계층 하나로 세상을 통일하는 것보다, 상위 아키텍처와 운영 모델을 하나의 철학으로 통일하는 것이 현실적이다.
따라서 힣의 현재 전략은 다음 문장으로 요약된다.
Matter를 공통 장치모델/상호운용 계층으로 삼고, 저전력 메시망은 Thread, 고대역 /백본은 Wi-Fi/Ethernet, Zigbee/Z-Wave는 브리지로 수용하며, 공장 제어는 별도 OT 계층을 존중한다.
AI 시대 임베디드의 의미
기술적 정당화의 한계
임베디드가 필요한 “합리적” 이유들:
- 레이턴시 (로컬 처리가 빠르다)
- 프라이버시 (데이터가 디바이스에 머문다)
- 오프라인 동작 (네트워크 없어도 작동)
- 전력 효율 (배터리 디바이스)
하지만, 대부분의 스마트홈에서 RPi + Python으로 충분하다.
더 솔직한 질문
AI가 코드를 잘 짜는 시대에 “코드를 잘 짜는 것”의 가치는 하락한다.
그렇다면 남는 것은?
- 무엇을 만들 것인가 (방향)
- 왜 만드는가 (의미)
- 누구를 위한가 (연결)
임베디드 허브가 의미 있으려면
기술적 우월성이 아니라 “이것만이 할 수 있는 것”이 있어야 한다:
- 완전한 오프라인 자율성 - 인터넷 없이 동작하는 AI 홈
- 증명 가능한 프라이버시 - 코드가 단순해서 검증 가능
- 개인 주권 - 빅테크 클라우드 의존 탈피
Personal AI Gateway 가능성
[로컬 LLM] ←→ [허브] ←→ [IoT 디바이스]
│
└── 프라이버시 보장, 클라우드 없이디지털 가든의 물리적 확장
[Denote/Org-mode] ←→ [허브] ←→ [물리 환경]
│
└── 글 쓸 때 조명 변경
집중 모드 자동 활성화
컨텍스트 기반 환경 조절인생도구와의 연결
“인생도구”가 되려면 그것 하나만 있으면 충분해야 합니다. 그리고 “안심도구”가 되야 합니다.
| 인생도구 (이맥스) | 허브 (나는허브다) |
|---|---|
| 충분 + 안심 | 오프라인 자율성 + 프라이버시 |
| 모든 워크플로우 | 모든 프로토콜 |
| 긳님들이 만들어서 공개 | 오픈소스 생태계 |
| 온디바이스AI 기대 | Edge AI 연결 가능 |
메타워드 연결 지도
┌─────────────────┐
│ 인생도구 │
│ (충분 + 안심) │
└────────┬────────┘
│
┌────────┴────────┐
▼ ▼
┌───────────────┐ ┌───────────────┐
│ † 임베디드 │ │ † IoT │
│ 시스템 │ │ │
└───────┬───────┘ └───────┬───────┘
│ │
└────────┬─────────┘
▼
┌─────────────────┐
│ † 엣지 온디바이스│
│ 온프레미스 │
└────────┬────────┘
│
▼
┌─────────────────┐
│ @OpenHome │
│ Foundation │
│ 프라이버시/선택 │
│ /지속가능성 │
└────────┬────────┘
│
▼
┌─────────────────┐
│ 나는허브다 │
│ 상태머신+에이전트│
└────────┬────────┘
│
┌─────────────┴─────────────┐
▼ ▼
┌──────────┐ ┌──────────┐
│sks-hub- │ │xlhatqbat │
│zig │ │-rockchip │
│(Zigbee) │ │(Matter) │
└──────────┘ └──────────┘관련문서
- 나는허브다: 상태머신과 에이전트 협업
- † 임베디드시스템
- † IoT InternetofThings
- † 엣지 온디바이스 온프레미스
- @OpenHomeFoundation 지속 가능한 스마트홈 오픈소스 생태계
- @힣: 인생도구 지식관리 생각도구
- [§homeagent-config: 허브-에이전트 아키텍처]
- [matter.js 1.5.x 지원현황과 힣의 네트워크 토폴로지 전략 메모]
IKEA DIRIGERA 분석
IKEA의 Thread/Matter 전환
IKEA는 2024년부터 Zigbee에서 Thread로 전환 중. 새 제품들은 Zigbee와 Thread를 “동등한 시민”으로 취급. 공장 초기화 없이 QR코드 스캔만으로 프로토콜 전환 가능.
DIRIGERA 허브 아키텍처
- 플랫폼: STM32MP 프로세서, Linux (Yocto)
- 칩셋: Qorvo QPG6200L (Zigbee/Thread/BLE 동시 운영)
- Thread: OpenThread 1.4
- GPL 공개:
ikea-oss-distributions/DIRIGERA-hub
통신 인터페이스
| 포트 | 프로토콜 | 용도 |
|---|---|---|
| 8443 | HTTPS REST | 로컬 제어 (앱, 서드파티) |
| 8081 | OpenThread REST | Thread BR 관리 (최근 막힘) |
| 내부 | WebSocket | 앱 ↔ 허브 실시간 통신 |
MQTT를 안 쓰는 이유
IKEA DIRIGERA는 MQTT를 사용하지 않는다. REST API + WebSocket으로 충분. 자체 클라우드로 완전 통제.
- 자체 클라우드: AWS/Google 의존 없이 IKEA 인프라로 통제
- REST API: 앱 개발 단순화, MQTT 브로커 운영 부담 없음
- 스케일: 수백만 허브 → 자체 인프라 구축 가치 있음
fxf-uho-mvt vs IKEA DIRIGERA
| 항목 | fxf-uho-mvt | IKEA DIRIGERA |
|---|---|---|
| 플랫폼 | MCU (ESP32, nRF) | Linux (STM32MP) |
| 메모리 | 수십 KB | 수백 MB |
| 언어 | Zig (순수 구현) | C/C++ (GPL) |
| 아키텍처 | 상태머신 4계층 | Linux 서비스 구조 |
| 클라우드 | AWS IoT (MQTT) | IKEA Cloud (REST) |
| 로컬 API | 없음 | REST :8443 |
| 오픈소스 | 계획 중 | GPL 의무만 (로직 비공개) |
허브 로직 범위 비교
IKEA (thin hub):
[IKEA Cloud] ─── 시나리오, 음성, OTA, Shadow
│
[DIRIGERA] ─── 경량 브릿지 (Thread/Zigbee ↔ IP)
│
[Devices]
fxf-uho-mvt (thick hub):
[AWS IoT] ─── Shadow 동기화만
│
[fxf-uho-mvt] ─── 완전한 상태머신, 디바이스 관리, 페어링, OTA
│
[Devices]핵심 인사이트
| IKEA | fxf-uho-mvt |
|---|---|
| 허브 = 브릿지 (로직 최소화) | 허브 = 두뇌 (로직 집중) |
| 클라우드 중심 상태 | 로컬 중심 (HubState) |
| 오프라인 제한적 | 오프라인 완전 동작 목표 |
| 자체 클라우드 필수 | AWS IoT로 충분 |
IKEA에서 배울 것
- Qorvo QPG6200L 칩의 Zigbee↔Thread 공존 전략
- OpenThread 1.4 REST API 호환성
- 프로토콜 전환 UX (QR코드 스캔)
유지해야 할 fxf-uho-mvt 강점
- 상태머신 기반 스펙 추적성
- AWS IoT 직접 연결 (MQTT)
- MCU 경량 구현
- 오프라인 완전 동작
다음 단계
- IoT 메타워드에 Thread/Matter/ 스마트홈 섹션 추가
- 임베디드 메타워드에 IoT/나는허브다 연결 강화
- fxf-uho-mvt에서 Thread 확장 로드맵 구체화
- matter.js 추적을 통해 Matter 상위 모델과 구현 성숙도 계속 점검
- Zigbee/Z-Wave를 중심축이 아닌 브리지 전략으로 재정리
- 홈 공장 캠퍼스 단위 실제 거리·장애물·전원 조건을 넣어 토폴로지 구체화
- Personal AI Gateway 개념과 허브-에이전트 아키텍처를 네트워크 설계와 연결
- OpenThread C 라이브러리 FFI 연결 검토
Comments