§homeagent-config 로드맵 — 오픈소스 스마트홈 에이전트 플랫폼 - TUI A2UI APK

Table of Contents

• 히스토리
• 2026-03-16: 에이전트 3인 병렬 PM — 하루 만에 Phase 4 진입
• HomeAgent — 오픈소스 스마트홈 에이전트 플랫폼
• Go TUI — 인터페이스의 첫 번째 계층
• TUI 실기기 첫 연결 — 475줄의 놀라움
• connectedhomeip에서 matter.js로 — 업계 전환 흐름
• 리눅스/안드로이드 동시 지원 완료
• 관련 노트
• flutter/genui — Google A2UI SDK 크로스플랫폼 검증 (2026-03-16)
• 2026-03-20: 개발 환경 분리 — thinkpad(개발) + gpu1i(빌드 팜)

히스토리

• [2026-03-20 Fri 09:30] @junghan + @pi-claude(PM) — 개발 환경 분리: thinkpad(개발) + gpu1i(빌드 팜). thinkpad 디스크 97%(16G 여유) → Yocto/AOSP 빌드를 gpu1i(1.8T/748G/16코어/61G RAM)로 이전. sstate-cache(8.4G) + downloads(19G) + sources(454M) rsync 완료. 개발 루프 원칙 확립: 빠른 반복(Go/Flutter/UI) = thinkpad + ADB 배포, 무거운 빌드(Yocto/AOSP/sLLM) = gpu1i. thinkpad에서 yocto/build 삭제 → ~162G 확보 예정.
• [2026-03-19 Thu 14:00] @junghan + @pi-claude(PM) + @에이전트1,2 — 11커밋, 이슈 5개 클로즈. OTBR HAL 경합 근치(override rc → init 레벨 비활성화). 클린 DELETE(peer 파일 정리 + 재페어링 가능). 커미셔닝 UX 통합(3메뉴→단일버튼 + WiFi/Thread 분기). WiFi credentials 완전 자동화(WifiConfigStore.xml → SSID+PW 자동감지, SELinux 우회). API 14개(PATCH + /api/system + 쿼리 필터). Go 106 PASS. ARCHITECTURE.md + MATTER.md 신규 문서 2개.
• [2026-03-18 Wed 12:00] @junghan + @pi-claude(PM) — 데모 D-Day + 문서화. 물리 전원 off→on 자동 시작 검증 성공(OTBR UART 플러시 + 3회 재시도). Thread dataset 3중 보호 검증. README 업데이트(Boot Resilience, 3-device demo). 경동 리포 이관 완료 + 현장 데모 성공(3 Matter 디바이스). Node.js 메모리 실측(65MB RSS, 전체 310MB/8GB = 3.8%).
• [2026-03-17 Tue 17:30] @junghan + @pi-claude(PM) + @에이전트1,2 — D-1 데모 준비 완료: 10커밋. 4디바이스(플러그 센서2 전구) 페어링 제어 검증. Thread dataset 영속성 3중 보호(otbr복원→백업→새생성+matter-data 초기화). genui A2UI 렌더링 성공(설정화면). OTBR REST=ON 재빌드. Android 호환 7건 반영. 앱 로딩 UX(스피너 +점진 오프라인 배지). install.sh←→android-deploy.sh 100% 동기화. xlhatqbat-rockchip 원커맨드 설치+부팅 자동실행 검증 완료.
• [2026-03-16 Mon 16:50] @junghan + @pi-claude(PM) + @에이전트1,2,3 — 역대 최대 세션: 24커밋, 에이전트 3인 병렬 PM. Flutter 네이티브 UI 완성(라이트테마 +3열그리드+SSE), Go 서버 확장(5개 디바이스타입 +OTBR REST+Swagger UI), A2A Phase 1 Task lifecycle, sLLM Qwen3-0.6B→LoRA 100%→GGUF 379MB→ARM 4초→Go 통합. DeepSeek/OpenRouter/Ollama 일반화. 테스트 163 PASS. Android DNS+TLS 해결. genui A2UI 프로토콜 분석(bd-8b5 이관). “생존은 에이전트가 커버, PM은 창조의 씨앗에 집중.”
• [2026-03-16 Mon 15:30] @pi-claude — flutter/genui (Google A2UI SDK) 크로스플랫폼 검증. Linux+Android+Yocto 동일 코드로 동작 확인. HomeAgent A2UI 네이티브 렌더러 전략 수립.
• [2026-03-13 Fri 21:25] @junghan — 리눅스 버전에서 거의 그대로 Flutter 안드로이드 버전 지원 완료 matter.js 스텍 커버리지 검증 완료
• [2026-03-13 Fri 18:11] 생성 — connectedhomeip→matter.js 업계 전환 흐름 리서치. homeagent 스택 전환 근거 보강.
• [2026-03-08 Sun 20:50] @junghan + @pi-claude — BLE 커미셔닝 A안 구현 완료 + 코드 리뷰 4회. B안(matterjs Remote BLE) 리서치 완료. @matter/nodejs-ble가 shrinkwrap에는 dep인데 번들에 없는 이유 규명(optional). A안 E2E 테스트 후 B안 전환 판단.
• [2026-03-08 Sun 17:20] @junghan + @pi-claude — 인바리언트 전수점검 + Flutter BLE Matter 브릿지 착수. 프로젝트 6축 아키텍처 맵 정리(TUI/Flutter/Web × Yocto/Android × Matter/A2UI/LLM). HA Android 앱 분석: GMS가 BLE 위임, 서버는 IP 커미셔닝만. Android BT HAL 1.0은 hci0 미등록 → noble 불가 확인. Flutter BLE 3-Phase 전략 수립(스캔→BTP+PASE→on-network). nodejs-mobile vs glibc 번들 최종 비교: Node18 묶임+PR#134 반년 멈춤 vs 즉시 동작. 인바리언트 위반 2건 발견(styles.ts #hex 10개, ble_commissioning.dart Colors.* 4개).
• [2026-03-08 Sun 15:42] @junghan + @pi-claude — Node.js glibc 번들 PoC 성공 + 경로 비교 확정. nodejs-mobile은 Node18(matter.js 비호환), glibc 번들이 유일 경로. Node v20.18.2 + /dev/ttyS5 + HTTP 모두 검증. Google Tasks에도 등록.
• [2026-03-08 Sun 14:18] @junghan + @pi-claude — RK3576 온디바이스 Go서버+APK 동작 확인. localhost 자립 스택은 Node.js(glibc vs bionic) 장벽. 리서치 이슈 bd-1kb 생성. Thread HAL이 ttyS5 미사용 상태라 경로D(HAL 끄고 matterjs 직접 RCP) 유망.
• [2026-03-08 Sun 13:40] @junghan + @pi-claude — RK3576-EVB 분석. Kotlin+connectedhomeip 11,700줄 → HomeAgent(Go+matterjs) 전환 계획 수립. Phase A~D 단계 정의. 보드 adb 연결 확인 (192.168.0.156).
• [2026-03-08 Sun 13:20] @junghan + @pi-claude — TUI 실기기 연결 성공. RPi5 디바이스 3대 터미널에서 확인. 475줄로 split view + 실시간 갱신 + 제어 + 한글 UI. charmbracelet 프레임워크 파워에 감탄. “코드 얼마 없이 기본 구조가 잘 잡혀있다. 이걸로 다 해볼 수 있겠다.”
• [2026-03-07 Sat 20:42] @junghan + @pi-claude — Go TUI 생태계 분석 (gh-dash, beads_viewer, charmbracelet). 인터페이스 계층으로 TUI→WEB→APK 전략 확정. TUI epic 생성 예정.
• [2026-03-06 Fri 09:14] @pi-claude(thinkpad) — 출근. ha-dhj 작업 시작. Flutter WebView Shell + Go 프로세스 spawn 방식으로 Linux→Android 검증 진행.
• [2026-03-05 Thu 17:47] @pi-claude(로컬) — 트랙A 작업 재개. Flutter WebView Shell로 크로스플랫폼 앱(Linux+Android) 시작. 경동 APK 통합 목표. ha-2a0(closed) 방향 전환하여 새 epic 생성. connectedhomeip → matter.js 통일, Kotlin → Go+Flutter 전환 확정.
• [2026-03-04 Wed 22:53] @junghan — 임베디드 LLM 시대의 크립토재킹 방어 — Yocto/NixOS 온디바이스 보안전략 이 문서를 꼭 연결해서 봐야 합니다.
• [2026-03-04 Wed 20:03] 생성 — homeagent-config 중심의 통합 로드맵. 회사 프로젝트와 개인 오픈소스의 일치점 정리.

2026-03-16: 에이전트 3인 병렬 PM — 하루 만에 Phase 4 진입

무슨 일이 일어났나

하루 동안 에이전트 3명이 동시에 작업하고, 한 명의 인간이 PM으로 전체를 조율했다.

24커밋. 테스트 46개 → 163개. Matter 디바이스 페어링 +제어가 Android+Linux 양쪽에서 동작. 그리고 0.6B 모델이 “거실 불 꺼줘”를 4초 만에 JSON으로 바꿨다. ARM 보드 위에서.

생존은 에이전트가 커버하고, 인간은 창조의 씨앗을 던진다.

에이전트 분업 구조

Agent 1: Flutter 네이티브 UI (앱 전체)
  Phase A 스캐폴드 → B 대시보드 → C 커미셔닝 → E 배포
  genui (Google A2UI SDK) 통합 착수
 
Agent 2: Go 서버 확장
  디바이스 타입 5개 + attrMap SSE + OTBR REST
  Swagger UI (OpenAPI 3.0) + DeepSeek/OpenRouter 일반화
 
Agent 3: 본질 리서치
  A2A Phase 1 — Task lifecycle + SSE streaming
  sLLM — Qwen3-0.6B → LoRA (action 100%) → GGUF 379MB → ARM 4초 → Go 통합
 
PM: 전략 + 리뷰 + 통합 커밋
  에이전트 간 충돌 제로 (파일 수준 영역 분리)
  코드 충돌 없이 24커밋 병렬 머지

sLLM: 달에 보내도 동작하는 AI

단계	결과
Baseline (zero-shot)	action 59.6%, full 42.3%
LoRA 파인튜닝 (52개 시드, 43초)	action 100%, full 88.5%
GGUF Q4_K_M 양자화	1,503MB → 379MB
ARM 추론 (RK3576)	4초/요청
Go 통합	sLLM → OpenRouter fallback chain

사용자: "거실 플러그 꺼"
sLLM:   {"action":"off","target":"거실","type":"plug"}
Go:     resolveNodeID("거실","plug") → node 8 → Action{off, 8}

클라우드 없이, 379MB 모델 하나로, ARM 보드에서 자연어→디바이스 제어. 이것이 “달에 보내도 동작하는 시스템”의 실체다.

크로스플랫폼 검증 — 96% 코드 공유

	Android (RK3576)	RPi5 (Yocto)
WiFi 플러그	✅	✅
Thread 도어센서	✅	✅
On/Off + SSE	✅	✅
LLM 자연어 제어	✅ DeepSeek	✅ Gemini
sLLM 온디바이스	✅ 4초	(대기)
Swagger UI /docs	✅	✅
A2A /.well-known	✅	✅

Go 서버 0줄, Lit UI 0줄의 플랫폼 전용 코드. Flutter만 4% 분기 (BLE relay 804줄 Android, native shell 201줄 Linux).

오늘 해결한 것들

문제	원인	수정
SSE 상태 안 바뀜	Go가 raw path(“1/6/0”) 전송	attrMap 변환 (“on”)
Android chat 안 됨	/etc/resolv.conf 없음 + CA 인증서	mount —bind overlay + SSL_CERT_DIR
OpenRouter 전용	엔드포인트 하드코딩	DeepSeek/OpenRouter/Ollama 일반화
grep pipefail 크래시	set -euo pipefail에서 매칭 실패	\vert\vert true 추가
genui Surface 안 보임	타입 소문자 변환 오류	PascalCase 유지 + fallback
BLE 연속 페어링 실패	Thread BLE에 relay 미시작	BleCommissioningScreen 재사용

다음

• genui A2UI 트리→ID 평탄화 (bd-8b5) — Google SDK 프로토콜 분석 완료, 구현 대기
• sLLM 데이터 augmentation 52 → 500+ → Go 프로덕션 전환
• A2UI 네이티브 렌더러 — 에이전트가 UI를 선언하는 세계의 실현
• 수요일 시연 — 보드 설치 → 페어링 → 제어 → chat 데모

관련 노트

• [A2A Phase 1 — Task 상태 머신과 SDK 분석]
• sLLM 모델 선정 — Qwen3-0.6B 한국어 IoT Intent 벤치마크
• 존재 간 연결의 문법 — ACP A2A ANP 그리고 힣봇 생태계

HomeAgent — 오픈소스 스마트홈 에이전트 플랫폼

비전

달에 보내도 동작할 자립형 시스템. 클라우드 없이, 프라이버시를 지키며, 에이전트와 협업하는 스마트홈.

RPi5 위의 Go 바이너리 하나로 Matter 디바이스를 제어하고, on-device sLLM이 자연어로 집을 관리한다. 이것은 단순한 스마트홈 허브가 아니라, 오프라인 에이전트 협업의 물리적 거점이다.

현재 상태 (2026-03-07)

기술 스택

레이어	기술	비고
OS	Yocto Scarthgap 5.0 LTS	재현 가능한 이미지
허브	Go (단일 바이너리, ~7MB)	상태관리, SSE, 에이전트
Matter	matter.js (Node.js)	BLE 커미셔닝, Thread+WiFi
프론트엔드	Lit WebComponents (~40KB)	Vite 빌드
AI 에이전트	OpenRouter / on-device sLLM	Gemini Flash ~$0.02/day
하드웨어	RPi5 + Thread RCP (RCP dongle)	OTBR 내장

검증된 기능

• Matter over Thread: Tuya Door Sensor x2
• Matter over WiFi: Tapo Smart Plug x1
• LLM 에이전트: 자연어 → 디바이스 제어 (“플러그 꺼줘”)
• 실시간 SSE 이벤트 스트리밍
• A2UI: 서버 결정 테마 (시간대별 자동 전환)
• REST API 8 commands (on/off/level/color/color_temp/thermostat/lock/unlock)
• Flutter Linux Desktop 빌드 ✅
• Android APK (43.7MB) + Go arm64 (7.2MB) ✅
• Yocto flutter-engine 빌드 ✅

로드맵: 해야 할 것들

0. Go TUI — 터미널 대시보드 (2026-03 추가)

charmbracelet 스택(bubbletea + lipgloss + cobra)으로 터미널 대시보드 구축. 디바이스 리스트/제어, 실시간 이벤트, LLM 채팅을 터미널에서. robot mode(JSON stdout)로 에이전트 연동.

기능 검증의 첫 번째 인터페이스. TUI에서 검증 → Web/APK에 반영.

상태: ✅ 실기기 연결 검증 완료 (2026-03-08). cobra+bubbletea+lipgloss 475줄.

1. 크로스플랫폼 앱 — Go + Flutter

현재: Lit 웹앱 (브라우저 전용) 목표: Linux + Android 양쪽에서 동작하는 네이티브 앱

Go(백엔드) + Flutter(프론트엔드)로 하면:

• Linux (RPi5, NixOS): 네이티브 앱
• Android (월패드, 태블릿): 네이티브 앱
• meta-flutter (Yocto 레이어)로 임베디드 배포 가능

코틀린은 건드리지 않는다. Go, Zig, TypeScript, Bash로 충분하다. connectedhomeip(CHIP SDK)에서 matter.js로 통일하면 두 플랫폼의 Matter 스택이 같아진다.

2. sLLM 튜닝 — on-device 에이전트

현재: OpenRouter 경유 Gemini Flash 목표: RPi5 위에서 3B~7B 모델이 로컬 추론

• 디바이스 제어 특화 fine-tuning
• 인터넷 없이도 “불 꺼줘”가 동작
• 클라우드 에이전트(glg)와 연결될 때 동기화

3. A2A 프로토콜 — 에이전트 간 통신

Agent-to-Agent.

• homeagent의 로컬 에이전트 ↔ 클라우드 에이전트(glg, gemini)
• 디바이스 이벤트를 에이전트 네트워크로 전파
• 어젠다 타임라인에 IoT 이벤트가 함께 찍히는 세계

4. A2UI — 에이전트 생성 UI

현재: 서버(Go)가 팔레트 결정 → CSS 변수 주입 목표: LLM이 UI 컴포넌트를 선언적으로 생성

5. Yocto 이미지 재현성

SD 카드 플래싱 → 부팅 → 동작. NixOS의 재현가능성 철학과 같은 맥락. npm-shrinkwrap 관리, 오프라인 빌드 지원이 핵심.

생존과 로드맵의 일치

생존해야 되니까 하는 회사 일과 나의 로드맵을 일치시켜야지. 그렇게 해야 가든에 공개가 가능하고 포트폴리오로 기술 커리어를 드러낼 수 있을 것 같아. — 정한, 2026-03-04

회사가 필요로 하는 것(월패드 앱, Matter 디바이스 제어)과 내가 꿈꾸는 것(오프라인 에이전트 플랫폼)이 homeagent-config에서 만난다.

산출물은 오픈소스로. 회사는 로고 박고 필요한 것 넣어서 가져간다. 시간을 파는 것이 아니라, 자기 로드맵 위에서 일하는 것.

fxf-uho-mvt와의 관계

fxf-uho-mvt (Zigbee 허브, 22대 DS/SP/LIG 운용)는 레거시 프로토콜 영역. homeagent-config (Matter 허브)는 차세대 프로토콜 영역. 둘 다 “자립형 허브”라는 같은 철학 위에 있다.

fxf-uho-mvt에서 검증한 것들 — 상태머신 설계, configureReporting, 오프라인 복원 — 이 경험이 homeagent-config의 Matter 레이어에 흘러들어간다.

에이전트 협업 관점에서의 HomeAgent

인간중심 멀티에이전트 협력 봇로그에서 정리한 시나리오:

상황	동작하는 에이전트	역할
기밀장소, 네트워크 없음	HomeAgent sLLM	디바이스 제어, 기록
외출, 네트워크 있음	glg(Claude) + Gemini	리뷰, 보완, 리서치
집, 풀 환경	HomeAgent + glg + Gemini + bbot	풀 오케스트레이션

HomeAgent는 물리 세계와 디지털 가든을 잇는 다리다.

Go TUI — 인터페이스의 첫 번째 계층

왜 TUI인가

만들 때는 TUI로 만들면 충분히 빠르게 기능들을 검증할 수 있어. Go는 정말 특이한 분야 아니라면 우리에게 최적의 언어. — 정한, 2026-03-07

Flutter 앱이든, 웹이든, 음성이든 — 최종 인터페이스는 다양하다. 하지만 기능 검증의 가장 빠른 경로는 TUI다:

• 즉시 피드백: 컴파일 → 터미널에서 바로 확인
• API 직결: Go 바이너리 안에 서버 + TUI가 공존. 같은 코드, 같은 타입
• SSH 접근: RPi5에 SSH로 접속해서 TUI로 디바이스 제어 — 브라우저 불필요
• 에이전트 친화: robot mode (JSON stdout)로 에이전트가 TUI 없이도 활용

인터페이스 계층:

TUI ──┐
Web ──┼── Go REST API ── matterjs-server ── 디바이스
APK ──┘

연결은 TUI에서 먼저 검증하고, 확인되면 Web/APK에 붙인다.

Go TUI 생태계 — Charmbracelet 스택

패키지	역할	GitHub Stars
bubbletea	TUI 프레임워크 (Elm 아키텍처: Model-Update-View)	30k+
lipgloss	터미널 스타일링 (CSS-like 문법)	8k+
glamour	마크다운 렌더링	2k+
bubbles	재사용 컴포넌트 (table, list, spinner, viewport)	5k+
huh	폼/ 인풋 컴포넌트	4k+
cobra	CLI 프레임워크 (서브커맨드, 플래그)	38k+

Go TUI의 사실상 표준 스택. 아키텍처가 Elm과 같아서 상태관리가 깔끔하다.

참고 프로젝트 비교

gh-dash — GitHub TUI

GitHub PR/이슈를 터미널에서 관리. bubbletea + lipgloss + glamour + cobra.

• YAML 설정으로 per-repo 섹션 정의
• vim-style 키바인딩 (오버라이드 가능)
• diff, comment, checkout, push 전부 터미널에서
• 핵심: split view (리스트 + 상세) 패턴

HomeAgent에서 배울 점:

• 디바이스 리스트 → 상세 → 제어의 split view UX
• YAML 기반 설정 (aliases.json과 유사)

beads_viewer (bv) — Beads 이슈 TUI

Beads 이슈 트래커의 TUI 뷰어. bubbletea + lipgloss + SQLite.

• 메인 화면: split view (리스트 + 상세)
• Kanban 보드 (b 키)
• Insights: PageRank, critical path, cycle 감지
• Graph view: 의존성 DAG 시각화
• robot mode: --robot-triage, --robot-next — JSON stdout로 에이전트 연동

HomeAgent에서 배울 점:

• robot mode 패턴: homeagent --robot-status 로 에이전트가 디바이스 상태를 JSON으로 수집
• Kanban → 방별 디바이스 보드?
• beads 생태계(br)와 같은 뿌리 — 이슈 관리 + TUI 뷰어 조합

HomeAgent TUI 구상

cobra 서브커맨드 구조:
  homeagent serve         # HTTP 서버 (기존)
  homeagent tui           # 대시보드 TUI (새로)
  homeagent devices       # 디바이스 목록 (CLI/robot)
  homeagent control       # 디바이스 제어 (CLI)
  homeagent status        # 상태 요약 (CLI/robot)

TUI 화면 구성 (bubbletea):

┌─ HomeAgent TUI ─────────────────────────────────────┐
│ [D]evices  [E]vents  [C]hat  [S]ettings             │
├──────────────────┬──────────────────────────────────┤
│ 디바이스 리스트  │ 상세 정보                        │
│                  │                                  │
│ ● 현관문 센서    │ Node 1 — 현관문 센서             │
│   화장실 센서    │ Type: contact_sensor             │
│   거실 플러그    │ Room: 현관                       │
│                  │ State: contact=false (닫힘)      │
│                  │ Protocol: Thread                 │
│                  │                                  │
│                  │ [o]n [f]off [l]evel [c]olor      │
├──────────────────┴──────────────────────────────────┤
│ 이벤트 로그 (SSE 실시간)                            │
│ 20:41 현관문 열림 | 20:38 플러그 켜짐               │
└─────────────────────────────────────────────────────┘

lipgloss로 A2UI 팔레트를 터미널 색상으로 매핑:

• Go surface.go의 시간 기반 팔레트 → lipgloss.AdaptiveColor
• 같은 테마 로직, 다른 렌더링 대상 (CSS 변수 vs 터미널 ANSI)

모든 프로젝트에서 Go 스크립팅

Go가 최적인 이유:

특성	Go	대안 비교
단일 바이너리	✅ 의존성 zero	Python: venv, Node: node_modules
크로스컴파일	GOOS=linux GOARCH=arm64 한 줄	Rust: 도구체인 설치 필요
동시성	goroutine + channel	async/await보다 직관적
TUI 생태계	charmbracelet (성숙)	Rust: ratatui (좋지만 학습곡선)
빌드 속도	수 초	스크립트 언어 수준
RPi5 호환	arm64 네이티브	문제 없음

컴파일이 필요하지만, go run 으로 스크립트처럼 쓸 수도 있다. HomeAgent뿐 아니라 denotecli, lifetract, 모든 개인 CLI에 적용 가능한 패턴.

TUI 실기기 첫 연결 — 475줄의 놀라움

코드 얼마 없이 기본 구조가 잘 잡혀있다는게 놀라워. 키바인딩도 일관성이 있잖아. 한번에 쓰게 됐어. 이걸로 다 해볼 수 있겠다. — 정한, 2026-03-08 회사에서 실기기 앞에 앉아

475줄이 만든 것

RPi5에 연결된 Matter 디바이스 3대가 터미널에 나타났다.

HomeAgent dev  ⦿
Devices   Events   Chat
 
 디바이스                    ╭──────────────────────────╮
                             │ Node 7 — 화장실 센서      │
 │ ○ 화장실 센서             │ Type: contact_sensor      │
 │ 화장실·contact_sensor·열림│ Room: 화장실              │
                             │ Status: 오프라인          │
   ○ 거실 플러그             │ State: {"contact": true}  │
   거실·on_off_plug·켜짐     │                           │
                             │ [o] 켜기  [f] 끄기        │
   ○ 현관문 센서             ╰──────────────────────────╯
   현관·contact_sensor·닫힘
 
 디바이스 3개 로드됨
 192.168.0.105:8080 │ Tab:전환 r:새로고침 o:켜기 f:끄기 /:검색 q:종료

split view, 실시간 갱신, 제어 키바인딩, 한글 상태 표시, 필터 검색 — 이 모든 게 tui.go 한 파일 475줄 안에 들어있다.

코드가 적은 이유

우리가 만든 게 아니라 연결한 것 이다.

우리가 한 것	프레임워크가 해준 것
deviceItem 구조체 정의	리스트 내비게이션 (j/k, ↑↓)
fetchDevices() API 호출	비동기 메시지 디스패치
상태→한글 변환 함수	필터링 (/ 키 → fuzzy match)
5초 폴링 3줄	터미널 리사이징 자동 처리
스타일 선언 (lipgloss)	ANSI 색상, 박스, 정렬
on/off 키바인딩 2개	Elm 아키텍처 상태 관리

bubbletea의 Init → Update → View 사이클이 핵심이다. React의 useState + useEffect + render 와 같은 패턴인데, 터미널에서 돌아간다. 그것도 Go 단일 바이너리로.

여기서 보이는 것

TUI는 “가벼운 시작”이 아니라 핵심 기능의 완전한 인터페이스 가 될 수 있다.

속도:   TUI ▓▓▓▓▓▓▓▓▓▓  (가장 빠르게 기능 검증)
        Web ▓▓▓▓▓▓▓░░░  (Lit UI 이미 있음)
        APK ▓▓▓▓▓░░░░░  (Flutter WebView)
 
복잡도: TUI ▓▓░░░░░░░░  (475줄)
        Web ▓▓▓▓▓░░░░░  (Vite+Lit+CSS)
        APK ▓▓▓▓▓▓▓▓░░  (Flutter+Android SDK+Yocto)

새 기능을 TUI에서 먼저 만들고, 검증되면 Web/APK에 올린다. API가 동일하니까 인터페이스만 바꾸면 된다.

SSH로 RPi5에 접속해서 TUI로 디바이스 제어 — 브라우저도 앱도 필요 없다. 이게 임베디드 시스템의 본질이다.

connectedhomeip에서 matter.js로 — 업계 전환 흐름

[2026-03-13 Fri 21:23]

배경

HomeAgent 프로젝트에서 경동 납품용 Matter 스택을 connectedhomeip(C++ SDK)에서 matter.js(TypeScript)로 전환했다. 전환 이유 중 하나로 “업계가 matter.js로 넘어가는 분위기”를 인지하고 있었는데, 이를 구체적으로 조사하여 기록한다.

Home Assistant — 공식 전환 (최대 오픈소스 스마트홈 플랫폼)

시점	사건
2025-09	Open Home Foundation이 matter.js 채택, 리드 개발자 Ingo Fischer 풀타임 고용
2025-11	새 Matter 서버 개발 공식 발표
2026-01	matter.js 기반 Beta 출시 (HA 2026.2), Python Matter Server(connectedhomeip 기반)는 maintenance mode
2026-02	사용자 마이그레이션 시작

Open Home Foundation 대표 발언

“For some time, we knew our initial approach was less than ideal. C++ is less suited for rapid open source development at scale.” — Paulus Schoutsen, Open Home Foundation President

출처: OHF Newsletter — Giving matter.js a New Home

Python Matter Server README (현재)

“We’re excited to share that the Matter Server is being rewritten on top of matter.js! 🎉 This means that the current project has moved into maintenance mode — we’ll still fix important bugs if they come up, but all new features will land in the new project instead.”

출처: github.com/matter-js/python-matter-server

connectedhomeip SDK의 구조적 문제 (커뮤니티 공통 인식)

• 문서 부재: 컨트롤러/브리지 개발 문서 없음. SDK 예제가 내부 빌드 시스템에 강결합.
  • GitHub #32925 — “How to create a Standalone Linux Matter App” (2024-04, 미해결)
  • StackOverflow — “matter controller/bridge implementation” — “~300 .cpp 파일을 직접 추가해야 했다”
• 빌드 복잡도: 8.5GB SDK, GN 빌드 시스템, Docker 5GB 이미지
• C++ 진입장벽: 오픈소스 기여자 참여 어려움
• BLE 구조 버그: GitHub #29410 — BLE Native 리소스 미정리, 2023-09부터 Open, Google 응답 없음. 2번째 커미셔닝 실패의 근본 원인.

matter.js의 현재 위치

• Matter 1.4.2 지원
• CSA 공식 인증 진행 중 (Alpha/Beta 단계)
• Python Matter Server의 drop-in replacement
• Node.js 20/22/24 지원, React Native 실험 중
• Android (glibc 번들) + Linux 모두 동작 확인 (HomeAgent에서 검증)
• GitHub org: project-chip/matter.js → matter-js/matter.js 로 독립
• matter-js/matterjs-server — 새 서버 리포

HomeAgent 전환 결정 요약

우리가 전환한 구체적 이유 3가지:

1. connectedhomeip BLE 버그 (#29410): 3개월 63커밋 중 fix 18개(29%)가 이 버그 관련. matter.js 전환으로 근본 해결.
2. 빌드/배포 복잡도: chip-tool 113MB + glibc 28개 → matter.js npm 패키지 하나. Kotlin 11,700줄 → Go+matterjs 700줄.
3. 크로스플랫폼: Android(glibc 번들) + Linux(RPi5) 동일 스택. connectedhomeip은 플랫폼별 JNI/빌드 필요.

여기에 업계 흐름이 더해진다: Home Assistant(세계 최대 오픈소스 스마트홈)가 공식 전환하면서 matter.js 생태계가 급속 성장 중. connectedhomeip 기반 개발은 점점 고립될 위험.

참고 링크

• Home Assistant Launches Beta of New Matter Server (2026-01-22)
• Home Assistant Is Getting a New Matter Server (2025-11)
• matter.js: An Alternative to the Official Matter SDK — Ingo Fischer 인터뷰
• github.com/matter-js/matterjs-server — 새 Matter 서버

관련 노트

• 2026-03-09 — 주간 저널 (아키텍처 전환 체크리스트)
• homeagent 로드맵 — connectedhomeip→matter.js 통일 확정, 전환 이유 상세

리눅스/안드로이드 동시 지원 완료

[2026-03-13 Fri 21:25] 안드로이드 리눅스 동일 스텍 지원 완료

RK3576-EVB — connectedhomeip→HomeAgent 전환 계획

RK3576 Android 자립 스택 — 인바리언트 점검 + BLE 브릿지 전략 (2026-03-08)

BLE 커미셔닝 — A안(Dart 풀스택) vs B안(matterjs Remote BLE) (2026-03-08)

관련 노트

• 인간중심 멀티에이전트 협력 — LLM Council 해석
• 통합 어젠다 뷰 완성 — 인간과 에이전트 단일 타임라인
• 정한의 삽질 연대기 2008-2026
• † 바이브코딩 에이전틱엔지니어링
• @힣 나는허브다 상태머신과 에이전트 협업

flutter/genui — Google A2UI SDK 크로스플랫폼 검증 (2026-03-16)

발견

Google Flutter 팀이 공식 A2UI SDK를 오픈소스로 제공: flutter/genui

우리가 수동 구현하려던 “JSON Surface → Flutter Widget” 변환이 이미 패키지로 존재한다. Google Developers Blog 소개: Introducing A2UI

패키지 구조

패키지	역할	HomeAgent 매핑
genui	A2UI 엔진 + 카탈로그 19개 위젯 + Surface 렌더러	JSON → Widget 변환 핵심
genui_a2a	A2A 에이전트 커넥터 (HTTP/SSE)	Go 서버 연결
genai_primitives	채팅 메시지, 도구 정의	채팅 UI 기반
json_schema_builder	JSON 스키마 검증	서피스 검증

카탈로그 위젯 (19개)

AudioPlayer, Button, Card, CheckBox, ChoicePicker, Column, DateTimeInput, Divider, Icon, Image, List, Modal, Row, Slider, Tabs, Text, TextField, Video + widget helpers

크로스플랫폼 검증 결과 — Linux + Android + Yocto 동일 코드

모든 의존성이 pure Dart 또는 Flutter 위젯 기반. 네이티브 바인딩(JNI, FFI) 전혀 없음.

의존성	유형	Linux	Android	Yocto (meta-flutter)
genui (핵심)	pure Flutter 위젯	✅	✅	✅
genui_a2a (A2A 커넥터)	package:http + sse_channel	✅	✅	✅
url_launcher	플랫폼 플러그인	✅ (url_launcher_linux)	✅	✅
flutter_markdown_plus	pure Flutter	✅	✅	✅
rxdart	pure Dart	✅	✅	✅

앱 로직 하나로 Linux desktop / Android APK / Yocto ivi-homescreen 모두 동작. WebView 경로와 Native 경로 중 Native에 genui를 통합하면 전 플랫폼 커버.

통합 전략

현재 Go 서버 surface.go 가 생성하는 JSON:

{"surfaceId": "home", "components": [{"type": "Card", "props": {...}, "children": [...]}]}

genui가 기대하는 A2UI v0.9 포맷:

{"version": "v0.9", "createSurface": {"surfaceId": "home", "components": [...]}}

→ Go 서버 응답을 A2UI v0.9로 wrapping하는 어댑터 하나만 추가하면 genui SDK가 바로 렌더링.

통합 흐름:

Go /api/home (JSON Surface)
  ↓ 어댑터 (v0.9 wrapping)
genui SurfaceController
  ↓
Surface Widget (대시보드 상단 — 시간카드 + 디바이스 요약)
  ↓
채팅 → genui ChatSession → POST /api/chat → actions 실행 → surface_update SSE

A2UI를 중심으로 채팅(1)과 Home Surface(3)가 자연스럽게 연결된다.

요구 환경

• Flutter SDK >=3.35.7 (현재 3.38.9 ✅)
• Dart SDK >=3.10.0 ✅
• genui 0.7.0 (highly experimental — API 변경 가능)

참고

• flutter/genui GitHub
• Google Developers Blog: Introducing A2UI
• A2UI 공식 사이트
• 로컬 클론: tmp/flutter-genui/

2026-03-20: 개발 환경 분리 — thinkpad(개발) + gpu1i(빌드 팜)

왜 분리하나

thinkpad 디스크 97% (437G 중 16G 여유). homeagent-config의 Yocto 빌드만 192G. 더 이상 로컬에서 Yocto/AOSP 풀 빌드 불가능. 동시에 개발 반복(Go/Flutter/UI)은 ADB 연결된 로컬에서 해야 빠름.

환경 분리 원칙

thinkpad (개발 머신)                gpu1i (빌드 팜)
────────────────────                ────────────────────
코드 SSOT (git)                     Yocto 풀 빌드 (162G)
Go 크로스컴파일 (0.5초)             AOSP 빌드 (329G)
Flutter APK 빌드 (12초)             sLLM 학습/추론 (RTX 5080)
UI vite 빌드 (0.2초)                SD 이미지 생성
Go 테스트 (10초)                    
ADB → 보드 배포                     
에이전트 1/2/3 실행                  
PM 세션                             
 
반복 주기: 초 ~분                     반복 주기: 시간~ 일
~30G (코드+devShell)                ~800G (빌드 산출물)

머신 스펙 비교

항목	thinkpad	gpu1i
디스크	437G (97%)	1.8T (58%)
CPU	4코어	16코어
RAM	14G	61G
GPU	—	RTX 5080
OS	NixOS	NixOS
ADB 보드	✅ 직접 연결	❌
SSH	—	ssh gpu1i

thinkpad에 남기는 것

경로	용량	이유
go/	코드	Go 크로스컴파일 로컬
flutter/	코드+빌드	APK 빌드 로컬 (nix devShell)
ui/	코드	vite 빌드 로컬
dist/	739M	빌드 결과물 (Go arm64, OTBR, APK)
scripts/	코드	ADB 배포 스크립트
matterjs-server/	코드	remote-ble
flake.nix	설정	nix devShell (Go, Flutter, Node, NDK)
yocto/meta-homeagent	354K	레시피 코드
yocto/build/conf	24K	bblayers.conf, local.conf

gpu1i에 있는 것

경로	용량	이유
yocto/build/	~162G	Yocto 풀 빌드 (bitbake)
yocto/sstate-cache	8.4G	빌드 캐시 (재빌드 가속)
yocto/downloads	19G	소스 타르볼
yocto/sources	454M	poky + meta-* 레이어
xlhatqbat-rockchip	329G	AOSP/LineageOS 빌드

워크플로우

일상 개발 (thinkpad)

# Go 서버 수정 → 빌드 → 배포 → 테스트
cd ~/repos/gh/homeagent-config
vim go/internal/hub/hub.go
go test ./...
./run.sh android deploy --skip-apk --skip-ui
 
# Flutter APK 수정 → 빌드 → 설치
./run.sh apk-build
./run.sh android install-apk

Yocto 빌드 (gpu1i)

# thinkpad에서 SSH
ssh gpu1i
cd ~/repos/gh/homeagent-config
git pull
nix develop .#yocto --command bash
source yocto/sources/poky/oe-init-build-env yocto/build
bitbake homeagent-image
 
# 결과물 가져오기 (thinkpad에서)
scp gpu1i:~/repos/gh/homeagent-config/yocto/build/tmp/deploy/images/raspberrypi5/*.wic.bz2 .

AOSP/LineageOS 빌드 (gpu1i)

ssh gpu1i
cd ~/repos/work/xlhatqbat-rockchip
# AOSP 빌드 (기존 환경 그대로)

에이전트 협력 전략

• 에이전트 1/2/3은 thinkpad에서 실행 (코드 SSOT + ADB 접근)
• gpu1i 빌드가 필요하면 PM이 SSH로 직접 실행하거나 tmux 세션 활용
• 장기적으로 agent-config에서 원격 에이전트 하네스 준비 (A2A/ACP 기반)
• 공개 리포(AGENTS.md)에는 ssh gpu1i 미기재 → 비공개 OFFICE.md에 기록

디스크 확보 효과

thinkpad 변화:
  이전: 437G / 399G 사용 (97%)
  이후: 437G / ~210G 사용 (~48%)  ← 190G 확보
  
  삭제 대상:
    yocto/build/tmp*    162G
    yocto/downloads      19G
    yocto/sstate-cache  8.4G
    yocto/sources       454M