히스토리
- IKEA DIRIGERA 분석 추가
- 간담회 중에 문서 생성
배경
TTA 지능형 홈 지원 사업 설명회 참석 중 작성. 스레드/매터 기반 지능형 홈 지원 사업 관련하여 현재 진행 중인 프로젝트들과 디지털 가든의 연결 고리를 정리한다.
현재 프로젝트
sks-hub-zig: Zigbee 기반 허브, Zig 상태머신 아키텍처kyungdong-rockchip: RK3588 Android 15, Matter/OpenThread 정부과제
핵심 질문
AI 시대에 임베디드 개발은 어떤 의미가 있는가? Python/웹언어로 빠르게 만드는 시대에 왜 Zig로 상태머신을 짜는가?
프로토콜 비교
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는 “무엇을 제어할 것인가” (디바이스 타입, 명령) Thread/WiFi는 “어떻게 전송할 것인가” (네트워크)
허브 vs Border Router
Zigbee에서 허브는:
- 네트워크 형성
- 디바이스 관리
- 프로토콜 변환
- 클라우드 연결
Thread에서 Border Router는:
- 메시 ↔ IP 연결만
- 네트워크는 디바이스들이 자체 형성
sks-hub-zig가 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 유지.
AI 시대 임베디드의 의미
기술적 정당화의 한계
임베디드가 필요한 “합리적” 이유들:
- 레이턴시 (로컬 처리가 빠르다)
- 프라이버시 (데이터가 디바이스에 머문다)
- 오프라인 동작 (네트워크 없어도 작동)
- 전력 효율 (배터리 디바이스)
하지만, 대부분의 스마트홈에서 RPi + Python으로 충분하다.
더 솔직한 질문
AI가 코드를 잘 짜는 시대에 “코드를 잘 짜는 것”의 가치는 하락한다.
그렇다면 남는 것은?
- 무엇을 만들 것인가 (방향)
- 왜 만드는가 (의미)
- 누구를 위한가 (연결)
임베디드 허브가 의미 있으려면
기술적 우월성이 아니라 “이것만이 할 수 있는 것”이 있어야 한다:
- 완전한 오프라인 자율성 - 인터넷 없이 동작하는 AI 홈
- 증명 가능한 프라이버시 - 코드가 단순해서 검증 가능
- 개인 주권 - 빅테크 클라우드 의존 탈피
Personal AI Gateway 가능성
[로컬 LLM] ←→ [허브] ←→ [IoT 디바이스]
│
└── 프라이버시 보장, 클라우드 없이디지털 가든의 물리적 확장
[Denote/Org-mode] ←→ [허브] ←→ [물리 환경]
│
└── 글 쓸 때 조명 변경
집중 모드 자동 활성화
컨텍스트 기반 환경 조절인생도구와의 연결
“인생도구”가 되려면 그것 하나만 있으면 충분해야 합니다. 그리고 “안심도구”가 되야 합니다.
| 인생도구 (이맥스) | 허브 (나는허브다) |
|---|---|
| 충분 + 안심 | 오프라인 자율성 + 프라이버시 |
| 모든 워크플로우 | 모든 프로토콜 |
| 긳님들이 만들어서 공개 | 오픈소스 생태계 |
| 온디바이스AI 기대 | Edge AI 연결 가능 |
메타워드 연결 지도
┌─────────────────┐
│ 인생도구 │
│ (충분 + 안심) │
└────────┬────────┘
│
┌────────┴────────┐
▼ ▼
┌───────────────┐ ┌───────────────┐
│ † 임베디드 │ │ † IoT │
│ 시스템 │ │ │
└───────┬───────┘ └───────┬───────┘
│ │
└────────┬─────────┘
▼
┌─────────────────┐
│ † 엣지 온디바이스│
│ 온프레미스 │
└────────┬────────┘
│
▼
┌─────────────────┐
│ @OpenHome │
│ Foundation │
│ 프라이버시/선택 │
│ /지속가능성 │
└────────┬────────┘
│
▼
┌─────────────────┐
│ 나는허브다 │
│ 상태머신+에이전트│
└────────┬────────┘
│
┌─────────────┴─────────────┐
▼ ▼
┌──────────┐ ┌──────────┐
│sks-hub- │ │kyungdong │
│zig │ │-rockchip │
│(Zigbee) │ │(Matter) │
└──────────┘ └──────────┘관련문서
- 나는허브다: 상태머신과 에이전트 협업
- † 임베디드시스템
- † IoT InternetofThings
- † 엣지 온디바이스 온프레미스
- @OpenHomeFoundation 지속 가능한 스마트홈 오픈소스 생태계
- @힣: 인생도구 지식관리 생각도구
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 브로커 운영 부담 없음
- 스케일: 수백만 허브 → 자체 인프라 구축 가치 있음
sks-hub-zig vs IKEA DIRIGERA
| 항목 | sks-hub-zig | 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]
sks-hub-zig (thick hub):
[AWS IoT] ─── Shadow 동기화만
│
[sks-hub-zig] ─── 완전한 상태머신, 디바이스 관리, 페어링, OTA
│
[Devices]핵심 인사이트
| IKEA | sks-hub-zig |
|---|---|
| 허브 = 브릿지 (로직 최소화) | 허브 = 두뇌 (로직 집중) |
| 클라우드 중심 상태 | 로컬 중심 (HubState) |
| 오프라인 제한적 | 오프라인 완전 동작 목표 |
| 자체 클라우드 필수 | AWS IoT로 충분 |
IKEA에서 배울 것
- Qorvo QPG6200L 칩의 Zigbee↔Thread 공존 전략
- OpenThread 1.4 REST API 호환성
- 프로토콜 전환 UX (QR코드 스캔)
유지해야 할 sks-hub-zig 강점
- 상태머신 기반 스펙 추적성
- AWS IoT 직접 연결 (MQTT)
- MCU 경량 구현
- 오프라인 완전 동작
다음 단계
- IoT 메타워드에 Thread/Matter/스마트홈 섹션 추가
- 임베디드 메타워드에 IoT/나는허브다 연결 강화
- sks-hub-zig에서 Thread 확장 로드맵 구체화
- Personal AI Gateway 개념 탐구
- OpenThread C 라이브러리 FFI 연결 검토
Comments