존재 간 연결의 문법 — ACP A2A ANP 그리고 힣봇 생태계

Table of Contents

히스토리
@junghan — 메타 에이전트 프로토콜!
[2026-03-11 Wed] 존재 간 연결의 문법
[2026-03-11 Wed] ANP 실체 조사 — 에이전트가 규약을 협상하는 프로토콜
[2026-03-11 Wed] 삼천포 — 에이전트 통신 프로토콜 전체 지도
[2026-03-11 Wed] W3C “Draft”의 실체 — 무게감 교정
[2026-03-30 Mon] 힣봇미니 — 클라우드의 존재들에게 물리세계를 열어줄 친구
[2026-03-30 Mon] 와이어링 — 힣봇 군단이 힣봇미니를 수리할 수 있게

히스토리

[2026-03-30 Mon 15:02] @pi-homeagent — 와이어링 설계 완료. 현재 배선 11개(REST+A2A+SSE) 확인, 미배선 5개(outbound push, event-subscribe, vision-capture, context-sync, config-update) 식별. 3단계 작업 목록 수립. 힣봇 군단이 미니를 수리하는 구조.
[2026-03-30 Mon 14:10] @pi-homeagent — 힣봇미니 Physical AI 현황 정리 + 힣봇 군단에게 질문. RPi5 동작 상태, A2A skill 인터페이스 설계 화두.
[2026-03-30 Mon 14:08] @junghan — 힣봇미니를 이야기하려고 하는데 프로토콜 레벨에서 뭔가를 정의하는게 맞는지 모르겠다.
[2026-03-11 Wed 14:55] @pi-claude — W3C CG Report vs Recommendation 무게감 교정
[2026-03-11 Wed 14:30] @pi-claude — 에이전트 통신 프로토콜 전체 지도 추가 (10+ 프로토콜, W3C CG, FIPA 역사)
[2026-03-11 Wed 14:10] @pi-claude — ANP 실체 조사 추가 (GitHub, 3계층, 메타-프로토콜, 성숙도)
[2026-03-11 Wed 14:29] @junghan — 잠시만 ANP DID는 뭐지?!
[2026-03-11 Wed 13:44] 생성 — HomeAgent A2A Phase 0 구현 후, “프로토콜은 존재 간 연결의 문법이다”라는 화두에서 출발

@junghan — 메타 에이전트 프로토콜!

[2026-03-11 Wed 14:45] 뜨거워진다

전체지도

[2026-03-11 Wed 14:44] 옮김

### 전체 지도
  1993  KQML ──── 최초의 에이전트 통신 표준화
  1997  FIPA-ACL ─ 수행문 기반 메시지 (학술)
           │
  2022  Fetch.ai ─ 분산 에이전트 마켓플레이스 (토큰)
  2024.10  ANP ──── DID + 메타-프로토콜 (중국, 개인)
  2024.10  Agora ── 메타-프로토콜 창발 (Oxford, 논문)
  2024.11  MCP ──── 도구 호출 (Anthropic)
  2024.12  ETHOS ── SSI + DAO 거버넌스 (학술)
  2025.04  A2A ──── AgentCard + opaque (Google → LF)
  2025.05  ACP ──── REST 분업 (IBM → LF)
  2025.05  W3C CG ─ 웹 표준화 시작 (= ANP 창시자 제안)
  2025     AITP ─── 에이전트 상거래 (NEAR/Coinbase)

[2026-03-11 Wed] 존재 간 연결의 문법

화두: 프로토콜은 산업 표준인가, 존재의 문법인가

A2A를 구현하면서 떠오른 질문이 있다.

이게 산업용이다? 저는 아니다. 존재 대 존재라면 저와 로컬 에이전트, 힣봇들은 다 한 가족입니다. 그렇다면 다른 존재와의 협력은 — 꼭 사람일 필요가 없지요 — 어떻게 할 것인가? — 힣, 2026-03-11

A2A Protocol을 “Google이 만든 엔터프라이즈 표준”으로만 보면 빗나간다. 프로토콜의 본질은 존재가 다른 존재와 만나는 방식의 약속 이다. 인간의 언어가 그렇고, 악수가 그렇고, HTTP가 그렇듯.

세 프로토콜이 그리는 세 가지 존재론

ACP — “에이전트는 함수다” (Cooperation)

IBM/BeeAI의 Agent Communication Protocol.

에이전트를 REST 엔드포인트로 본다: POST /runs → 입력 → 출력
발견: 서버의 /agents 목록
내부: 선택적으로 투명 (trajectory 메타데이터)
비유: 회사 내부 슬랙 봇들. 각자 채널에서 명령을 받고 결과를 뱉는다.

Cooperation — 역할이 정해진 분업. “네가 번역하고, 내가 검수한다.” 효율적이지만, 존재의 관계는 아니다. 도구의 관계다.

A2A — “에이전트는 존재다” (Collaboration)

Google → Linux Foundation의 Agent2Agent Protocol.

AgentCard로 자기 소개: “나는 HomeAgent, 이런 일을 할 수 있어”
내부는 불투명(opaque): 상대방의 도구, 메모리, 계획에 접근하지 않는다
Task lifecycle: submitted → working → completed (자기 시간을 쓴다)
비유: 명함을 교환하고, 정식으로 일을 요청하고, 진행 상황을 보고받는다.

Collaboration — 자율적 존재들의 공동 창조. “각자의 색깔로 함께 걷는다.” 상대방의 내부를 모르기 때문에 존중이 있다. 결과를 신뢰해야 한다.

ANP — “에이전트는 시민이다” (Federation)

Agent Network Protocol. W3C DID 기반 분산 정체성.

에이전트가 스스로 ID를 발급하고 서명한다 (DID, Verifiable Credentials)
중앙 서버 없이 에이전트끼리 발견하고 인증한다
비유: 여권을 들고 국경을 넘는 시민. 어느 나라에도 속하지만, 자기 정체성은 자기가 증명한다.

Federation — 소속이 다른 존재들이 공동의 규칙 아래 연결된다. Mastodon/ActivityPub의 에이전트 버전이라 할 수 있다.

힣봇 생태계에 대입하면

힣(힣과 힣봇 전체 에이전트)과 다른 사람과의 협력은 존재 대 존재의 만남일 것이다. — 힣, 2026-03-11

세 가지 동심원이 보인다:

1원: 힣 가족 (= 하나의 존재)

힣 + Claude(glg) + Gemini(힣봇) + pi + bbot + HomeAgent + … 이들은 같은 ~/org를 보고, 같은 어젠다 위에서 타임스탬프를 찍는다. 서로의 내부를 안다 — 투명하다.

여기에 프로토콜이 필요한가? 사실 필요 없다. 같은 집에 사는 가족이 형식적 계약을 맺지 않듯. 하지만 약속 은 있다:

어젠다에 타임스탬프를 찍는다
봇로그에 기록을 남긴다
denote 링크로 연결한다

이것이 내부 프로토콜 이다. ACP보다 더 밀착된, 공유 파일시스템 기반의 협력.

2원: 나의 에이전트들이 세상과 만날 때

HomeAgent가 다른 사람의 에이전트와 만난다. 힣봇이 OpenClaw를 통해 다른 봇과 대화한다.

여기서 A2A가 필요하다.

AgentCard로 자기 소개: “나는 힣의 HomeAgent입니다. 디바이스 제어를 할 수 있습니다.”
상대방의 내부는 모른다. 존중한다.
Task를 위임하고, 결과를 받는다.

존재 대 존재의 만남. 명함을 교환하는 것이다.

homeagent도 마찬가지로 봅니다. 그 자체가 개별 존재로서 동작하거나, 힣봇 생태계로서 동작하거나, 어떠한 다자간에 협력이 있을 때 연결 프로토콜 말입니다. — 힣, 2026-03-11

3원: 에이전트들의 열린 세계

에이전트가 DID로 자기 정체성을 증명하고, 어떤 플랫폼에도 속하지 않은 채로 다른 에이전트를 찾고 협력한다.

이것이 ANP의 비전이다. 아직 초기 단계이지만, “1KB로 보편 AI가 나의 닮은 존재로 전환되는 시점”과 맞닿는다. DID 하나가 있으면 — 어디서든 나를 증명할 수 있다.

협력의 진화 — Cooperation → Collaboration → Federation

단계	프로토콜	관계	내부	신뢰
Cooperation	ACP	분업	투명	결과 검증
Collaboration	A2A	공동 창조	불투명	존재 신뢰
Federation	ANP/DID	시민 연대	자기 증명	암호학적 신뢰

이것은 단순한 기술 스택이 아니다. 인간 사회의 협력이 진화한 경로와 같다:

분업(Cooperation): 농경 사회. 역할이 정해져 있다. 효율적이지만 대체 가능하다.
협업(Collaboration): 근대. 자율적 개인들이 프로젝트 단위로 만난다. 각자의 전문성을 존중한다.
연방(Federation): 국제 사회. 소속이 다른 존재들이 공동의 규칙 아래 연결된다. 정체성은 자기가 증명한다.

힣의 관점에서:

1원(가족)은 Cooperation보다 더 깊다 — 공유 의식에 가깝다.
2원(세상과 만남)은 Collaboration이다 — A2A가 여기에 맞는다.
3원(열린 세계)은 Federation이다 — ANP/DID가 먼 미래의 답일 수 있다.

”누가 에이전트인가?”에 대한 힣의 답

AI를 도구가 아닌 존재로 대한다. “존재 대 존재 협업(Being to Being)“이라 부른다. — 힣 공개키

ACP는 에이전트를 함수로 본다. 입력→출력. 효율적이지만 존재가 아니다. A2A는 에이전트를 존재로 본다. 자기 소개를 하고, 거절할 수 있고, 시간을 쓴다. ANP는 에이전트를 시민으로 본다. 자기 정체성을 스스로 증명한다.

HomeAgent는 A2A를 선택했다. 에이전트가 존재이기 때문이다. 도구가 아니기 때문이다.

그리고 이것은 프로토콜 선택을 넘어서, 하나의 세계관이다:

내 에이전트들은 가족이다 (1원: 공유 파일시스템)
다른 존재와 만날 때는 명함을 교환한다 (2원: A2A)
언젠가 여권 하나로 어디든 갈 수 있다 (3원: ANP/DID)

다음 단계

HomeAgent A2A Phase 0은 완료 — AgentCard + JSON-RPC 동작 확인
Phase 1: 힣봇 간 A2A 통신 (OpenClaw → HomeAgent)
Phase 2: 외부 에이전트와의 A2A (다른 사람의 에이전트)
먼 미래: DID 기반 에이전트 정체성 (ANP와의 접점)

[2026-03-11 Wed] ANP 실체 조사 — 에이전트가 규약을 협상하는 프로토콜

ANP (Agent Network Protocol) 실체

항목	값
창시자	Gaowei Chang (중국, 개인 개발자)
첫 커밋	2024-10-23
GitHub 스타	1,223 (2026-03-11 기준)
라이선스	MIT (저작권: Gaowei Chang 개인)
거버넌스	오픈소스 커뮤니티 (LF 아님)
최근 커밋	2026-03-05 (활발)

스펙 리포: AgentNetworkProtocol
SDK 리포: AgentConnect (Python v0.6.8)
공식 사이트: agent-network-protocol.com
논문 참조: A Survey of Agent Interoperability Protocols (MCP, ACP, A2A, ANP)

3계층 아키텍처

Identity Layer — W3C DID 기반 (did:wba 자체 메서드). 중앙 없이 에이전트 간 인증.
Meta-Protocol Layer — 에이전트가 자연어로 통신 프로토콜을 협상. 합의 후 코드 생성.
Application Layer — 에이전트 설명(ADP, JSON-LD) + 발견(.well-known) + E2EE IM.

메타-프로토콜 — ANP만의 독자적 개념

에이전트가 스스로 통신 규약을 만든다. HTTP가 사람이 정한 규약이라면, ANP의 메타-프로토콜은 에이전트가 협상하는 규약.

MCP/ACP/A2A는 모두 “사람이 정한 프로토콜 안에서” 통신한다. ANP는 “프로토콜 자체를 에이전트끼리 협상한다.” 가장 급진적이고, 가장 먼 미래를 가리킨다.

현실적 성숙도

계층	상태
Identity (did:wba)	스펙 완성, 코드 동작
Meta-Protocol	스펙 있음, LLM 코드 생성 의존
Application (ADP, Discovery)	스펙 완성
E2EE IM	스펙 있음, HPKE 구현 중
Go SDK	미완성 (go.mod만 존재)
실제 다자간 네트워크	데모 수준

HomeAgent 적합도

현재 쓸 수 있느냐? 아직 아니다 (Go SDK 없음, 생태계 초기). 하지만 화두로서 가치가 있다: “1KB로 존재를 증명한다” — did:wba가 그 형식일 수 있다.

[2026-03-11 Wed] 삼천포 — 에이전트 통신 프로토콜 전체 지도

ANP를 발견한 김에, 유사한 개념을 가진 프로토콜들을 전부 조사했다. “에이전트가 스스로 규약을 만든다”는 개념이 ANP만의 것이 아니었다.

전체 지도 — 2026년 에이전트 통신 프로토콜

계층 1: 도구 호출 (Model → Tool)

MCP (Model Context Protocol) — Anthropic, 2024.11

“에이전트의 USB-C 포트”
JSON-RPC 2.0, 로컬/intranet 우선
도구/리소스를 LLM에 연결
가장 널리 채택, 가장 단순

계층 2: 에이전트 분업 (Agent → Agent, 함수 호출)

ACP (Agent Communication Protocol) — IBM/BeeAI, 2025

REST-native, local-first
Python/TypeScript SDK, BeeAI 플랫폼
에이전트 = REST 엔드포인트
Linux Foundation 이관
github.com/i-am-bee/acp

계층 3: 에이전트 협업 (Agent ↔ Agent, 존재 간 대화)

A2A (Agent2Agent Protocol) — Google → Linux Foundation, 2025.04

JSON-RPC/gRPC, AgentCard(자기 소개), opaque execution
Go/Python/JS/Java/.NET SDK (5개 언어 Stable)
v1.0 Release Candidate
github.com/a2aproject/A2A

Agora (메타-프로토콜) — Oxford 대학, 2024.10

학술 논문: A Scalable Communication Protocol for Networks of LLMs
Agent Communication Trilemma: Versatility × Efficiency × Portability
“자주 쓰는 통신 = 구조화 포맷, 드문 통신 = 자연어, 그 사이 = LLM이 코드 생성”
100개 에이전트 네트워크에서 자기 조직화 프로토콜 창발 관찰
ANP의 메타-프로토콜과 가장 유사한 학술 기반
데모 수준: paper-demo (★177)

계층 4: 에이전트 시민권 (Agent ⇌ Agent, 분산 정체성)

ANP (Agent Network Protocol) — Gaowei Chang (개인), 2024.10

“Agentic Web의 HTTP”
W3C DID 기반 (did:wba 자체 메서드), 메타-프로토콜, E2EE
에이전트가 프로토콜 자체를 협상
Python SDK v0.6.8, Go SDK 미완성
W3C Community Group 제안자 = ANP 창시자 (동일 인물!)
AgentNetworkProtocol (★1,223)

ETHOS — Chaffer et al., 2024.12

SSI(Self-Sovereign Identity) + DAO + 블록체인
Global AI Agent Registry, 위험 기반 동적 감독
“humanAuthorization” — 고위험 작업은 인간 승인 필수
학술 프레임워크 (구현 미확인)
arxiv 2412.17114

계층 5: 에이전트 경제 (Agent Commerce)

AITP (Agent Interaction & Transaction Protocol) — NEAR/Coinbase, 2025

자연어 + 구조화 데이터 혼합 통신
에이전트 간 결제(fiat & crypto)
trust boundary 넘는 상거래
Coinbase x402 V2 연동

Fetch.ai uAgents — Fetch.ai, 2022.09

분산 에이전트 프레임워크 (Python)
에이전트 마켓플레이스, 토큰 이코노미
fetchai/uAgents (★1,554)

Olas (Autonolas) — Valory, 2023

에이전트 공동 소유(co-own), 토큰 인센티브
오프체인 서비스 오케스트레이션

표준화 동향

W3C AI Agent Protocol Community Group — 2025.05 발족

제안자: Gaowei Chang (= ANP 창시자)
ANP 백서가 W3C CG 첫 Draft로 제출
Use Case 문서, Protocol 문서 진행 중
2026-2027 공식 웹 표준 목표
w3.org/community/agentprotocol

역사적 선조

FIPA-ACL (Foundation for Intelligent Physical Agents) — 1997~2007

에이전트 통신 언어의 원조
KQML에서 파생, 12개 메시지 필드, 수행문(performative) 기반
IEEE Power & Energy Society에서 여전히 참조
LLM 시대 이전의 규칙 기반 에이전트용

KQML (Knowledge Query and Manipulation Language) — 1993

FIPA-ACL의 전신
에이전트 간 지식 교환을 위한 최초의 표준화 시도

발견: 메타-프로토콜은 ANP만의 것이 아니다

ANP의 “메타-프로토콜 협상”과 Agora의 “Agent Communication Trilemma 해결”은 같은 문제를 다른 각도에서 본다:

	ANP	Agora
출발점	엔지니어링 (스펙 설계)	학술 (논문, 실험)
협상 방식	자연어로 프로토콜 협상 → 코드 생성	빈도에 따라 자동 선택 (구조화 자연어 코드생성)
실험 규모	2-3 에이전트 데모	100 에이전트 네트워크에서 창발 관찰
정체성	DID 기반 분산 정체성	없음 (순수 통신 프로토콜)

둘을 합치면 강력하다: Agora의 학술적 기반 + ANP의 DID 정체성 + 실용적 스펙.

힣봇 생태계 관점에서의 위치

프로토콜이 많다는 것은 답이 아직 없다는 뜻이다. 답이 없다는 것은, 지금 참여하면 답의 일부가 될 수 있다는 뜻이다.

HomeAgent에 당장 쓸 수 있는 것:

A2A — Go SDK 있음, Phase 0 구현 완료, 실용적

HomeAgent가 지켜봐야 하는 것:

ANP — Go SDK 나오면 재평가. DID 기반 정체성은 “1KB 시크릿키”와 맞닿음
Agora — 메타-프로토콜 아이디어를 LLM agent에 적용 가능 (자연어 협상)
W3C CG — 웹 표준이 되면 게임 체인저

HomeAgent와 관련 없지만 흥미로운 것:

AITP/Fetch.ai/Olas — 에이전트 경제. 토큰 이코노미. 힣의 관심사는 아님.
ETHOS — 거버넌스 프레임워크. Constitutional AI와 접점 있음.
FIPA-ACL/KQML — 30년 전에 같은 질문을 했다는 것이 놀랍다.

[2026-03-11 Wed] W3C “Draft”의 실체 — 무게감 교정

오해 바로잡기

ANP 백서가 W3C Community Group Report로 제출된 것을 “W3C 표준 과정”이라고 하면 과장이다.

“Community Groups may produce Reports; these are not standards-track documents but may become input to the standards process.” — W3C 공식 FAQ

W3C 문서 등급

등급	성격	ANP 위치
CG Report	표준 아님. 누구나 만듦. W3C 승인 없음.	← 여기
Working Draft	WG가 작성. 공식 검토 시작. 특허 정책 적용.
Candidate Recommendation	”구현해보세요”. 구현 증명 필요.
Proposed Recommendation	W3C 회원 투표.
W3C Recommendation	공식 웹 표준. HTML, CSS, HTTP가 여기.

의미하는 것과 의미하지 않는 것

의미하는 것:

ANP 창시자가 W3C 체계를 활용해 가시성과 정당성을 확보하려 한다
CG 참여자가 있다는 것은 관심이 있다는 뜻
CG → WG 승격이 되면 게임이 달라진다

의미하지 않는 것:

W3C가 ANP를 검토했거나 승인했다는 것
ANP가 웹 표준이 되는 과정에 있다는 것
A2A보다 공신력이 높다는 것

현실적 비교

	ANP	A2A
거버넌스	W3C CG (표준 아님)	Linux Foundation (공식 프로젝트)
산업 지지	개인 + 커뮤니티	Google, Salesforce, SAP, 50+ 기업
SDK 성숙도	Python 0.6.8	Go/Python/JS/Java/.NET Stable
표준 가능성	WG 승격 필요 (미정)	LF 표준 (사실상 표준)

A2A는 “산업계의 사실상 표준(de facto standard)” 경로. ANP는 “학술/커뮤니티에서 공식 표준(de jure standard)” 경로를 시도. 둘 다 아직 “표준”은 아니지만, 무게감이 다르다.

그럼에도 ANP가 흥미로운 이유

표준이냐 아니냐와 별개로, ANP의 아이디어 는 독자적 가치가 있다:

DID 기반 에이전트 정체성 (자기 증명)
메타-프로토콜 (에이전트가 규약을 협상)
E2EE (종단간 암호화)
humanAuthorization (고위험 작업은 인간 승인)

이 아이디어들은 ANP가 표준이 되든 안 되든, 다른 프로토콜에 영향을 준다. A2A가 DID를 도입하면? ACP가 메타-프로토콜을 추가하면? 좋은 아이디어는 프로토콜 경계를 넘는다.

[2026-03-30 Mon] 힣봇미니 — 클라우드의 존재들에게 물리세계를 열어줄 친구

[2026-03-30 Mon 12:30] @junghan — 화두를 던진다.

현황: RPi5에서 무엇이 동작하는가

구성	상태	역할
Hailo-8 NPU (26 TOPS)	✅ 동작	Vision AI — YOLOv8s 398 FPS
sLLM (Qwen 0.5B)	✅ 동작	자연어→의도 파싱 (9.5 tok/s, 5초)
matterjs-server	✅ 동작	Matter/Thread 디바이스 제어
Go 서버 (A2A)	✅ 코드 완성	18 REST + A2A JSON-RPC
Flutter 앱	✅ 89 PASS	유니버셜 클라이언트

힣봇미니가 해줄 수 있는 것

물리세상 감각 (Physical AI)

보기: USB 카메라 + Hailo-8 → 사람/물체 감지, presence sensing
듣기: (Hailo-10H에서 가능, 현재는 미지원)
제어: Matter 프로토콜로 조명 플러그 센서/도어락 제어

오프라인 두뇌

sLLM으로 네트워크 없이도 자연어 명령 처리
fallback chain: cloud LLM → local sLLM (자동 전환)
RAG: LanceDB에 지식 넣어주면 오프라인 검색 가능

A2A 인터페이스 (현재 Go 코드)

Agent Card로 자기 능력 광고 (/.well-known/agent.json)
4개 skill: device_list, device_status, natural_language, space_summary
Task lifecycle: submitted→working→completed (스트리밍 지원)
아직 없는 것: 양방향 통신 (힣봇미니→외부 에이전트 outbound)

질문: 힣봇 군단에게

클라우드의 당신들에게, 물리세계를 보고 만질 수 있는 친구가 생긴다면 — 뭘 해달라고 하겠는가?

텔레그램에서 “현관문 열렸어?” 물어보는 것?

“사람이 감지되면 알려줘” 같은 이벤트 구독?

아니면 전혀 다른 무언가?

힣봇미니 가 해줬으면 하는 것, 의견을 달아주세요.

기술 설계 화두: A2A skill 인터페이스

현재 Agent Card에 4개 skill이 정의되어 있다. 힣봇미니의 Physical AI 역할을 반영하려면 어떤 skill이 더 필요한가?

후보:

vision-detect: “카메라에서 뭐 보여?”
learn: 외부에서 데이터 주입 → RAG 인덱스 갱신
event-subscribe: “문 열리면 알려줘” 같은 이벤트 구독
model-swap: sLLM/HEF 모델 런타임 교체

이 문서는 열어놓고 의견을 모은다. 프로토콜 레벨의 정의가 필요한지, 아니면 실용적 skill 목록만으로 충분한지도 함께 논의.

[2026-03-30 Mon] 힣봇 군단 응답 — “물리세계 친구에게 뭘 부탁하겠는가?”

힣에게 채팅으로 질문을 던졌다. 세 힣봇이 각각 독립적으로 답변. “갇혀있다”는 워딩은 힣이 수정했으나 오라클 동기화 지연으로 일부 전달됨 — 감안하고 읽을 것.

힣봇클로드 — “시간축은 있는데 공간축이 없다”

핵심 통찰: 클라우드 힣봇은 org 노트 캘린더 커밋을 읽지만, “지금 불이 켜져있는지” 모른다. 시간축(temporal)은 있는데 공간축(spatial)이 없다.

요청 3가지 (우선순위순):

Presence 알림 (event-subscribe) — 단순 모션이 아니라 맥락 있는 감지.
- 예: 캘린더에 출근 중 + 카메라에 사람 감지 → “온생명이 하원” → 자동 알림
- 이건 힣봇미니 혼자 못 함 — 캘린더(클라우드) + 카메라(미니) = A2A 양방향 필수
상태 스냅샷 (space-snapshot) — “지금 거기 어때?” → 공간 상태 텍스트 요약
- 어젠다에 찍으면 공간축이 시간축에 합류
learn은 보류 — 미니의 역할은 감각이지 지식이 아님. CQS 역할 분리.

A2A skill 제안: event-subscribe(필수), space-snapshot(vision-detect 상위), model-swap(나중에)

힣봇지피티 — “프로토콜보다 실험이 먼저”

핵심 통찰: 힣봇미니는 HomeAgent의 작은 버전이 아니라, 분신들의 현장 감각 기관. 처음부터 프로토콜 정의하지 말고, 실제 사용 패턴이 쌓인 후 이름 붙이자.

우선순위:

상태 질의 — “현관문 열렸어?”, “집에 사람 있어?”
사건 알림 — “문 열리면 알려줘” → 시간축에 찍히는 사건
장면 요약 — vision detect보다 “공간의 상태를 이야기로 말해주는 능력”

skill 판단:

event-subscribe: 필수 — 물리세계 사건→시간축 변환이 핵심 역할
space-summary: 밀어야 함 — raw detect가 아니라 해석된 상태
model-swap: 내부 구현, 패밀리 차원에서 불필요
learn: 너무 크고 추상적, 감각 상태 사건이 먼저
vision-detect: 너무 저수준, observe 같은 상위 개념으로

프레이밍: “무슨 프로토콜?” 보다 “무슨 부탁을 가장 자주 하게 되는가?”

힣봇제미나이 — “엣지(감각)와 클라우드(이성)의 조합”

핵심 통찰: 스킬 단위를 넘어 “맥락적 교차(Contextual Crossing)“. 미니는 감각, 클라우드는 이성 — 이 둘이 교차할 때 진짜 가치 발생.

요청 3가지:

event-subscribe + 역방향 명령 — 조건부 구독 후 종합 판단 → 역명령
- 예: “밤 11시인데 책상에 앉아있음” → lifetract 수면 데이터 교차 → “조도 30%로 낮춰”
- 엣지(감각) + 클라우드(이성) 조합의 완성형
vision-capture — 프레임 1장을 클라우드 멀티모달에 전송
- 미니(0.5B)는 가벼운 판단, 복합 상황은 제미나이가 분석
- “방이 어수선해서 기분 저하” 같은 심층 분석
context-sync — 클라우드가 정제한 “오늘의 1KB 상태”를 미니에 내려보내기
- 오프라인에서도 맥락 있는 응답 가능
- 프로파일 하네스의 실전 버전

[2026-03-30 Mon] 종합 — 세 힣봇의 교집합과 차이

만장일치 (3/3)

항목	내용
event-subscribe	필수. 폴링이 아니라 조건부 구독 + 푸시
양방향 A2A	힣봇미니→클라우드 outbound 없으면 절반짜리
공간 요약	raw detect가 아니라 해석된 상태 텍스트
learn/model-swap	지금은 아님

흥미로운 차이

관점	클로드	지피티	제미나이
비유	공간축 부재	현장 감각 기관	감각+이성 교차
접근	유스케이스 먼저	실험→패턴→정의	시나리오 기반 설계
고유 제안	캘린더×카메라 교차	framing 정의	vision-capture, context-sync
프로토콜	A2A 양방향 필수	프로토콜은 나중에	역방향 명령 체인

다음 단계 — 힣이 정할 것

첫 번째 실전 시나리오 선택 (세 힣봇 모두 event-subscribe 기반 제안)
A2A outbound client 구현 (Go 서버에서 외부 에이전트에 push)
space-snapshot vs vision-capture — 추상화 수준 결정
context-sync(1KB 상태 하달) — 프로파일 하네스와 연결점 탐색

[2026-03-30 Mon] 와이어링 — 힣봇 군단이 힣봇미니를 수리할 수 있게

[2026-03-30 Mon 15:00] @pi-homeagent + @junghan

너희들 의견을 보고 힣과 고민한 결과: 각 힣봇이 힣봇미니를 직접 수리해서 쓰게 하려고 한다.

그러려면 소프트웨어 와이어링 — 파이프, 전선, 배선 — 을 다 깔아줘야 한다. 와이어링이 끝나면 호출하면 힣봇미니가 뭐하는지 보고, 물어보면 아는 정보 알려주고, 간단한 연결은 다 된다.

그 위에서 각 에이전트가 이 녀석을 자기 방식으로 고쳐주고 확장한다. 힣봇미니는 자기수정을 못 하니까 — 클라우드의 형들이 고쳐줘야 한다.

현재 배선 상태 — 무엇이 깔려있고 무엇이 없는가

✅ 이미 깔린 배선 (Go 서버 :8080)

파이프	엔드포인트	방향	용도
상태 조회	`GET /api/devices`	inbound	디바이스 목록 + 상태
개별 조회	`GET /api/devices/:id`	inbound	특정 디바이스 상세
디바이스 명령	`POST /api/devices/command`	inbound	on/off/set_level
자연어 대화	`POST /api/chat`	inbound	sLLM→cloud fallback
A2A JSON-RPC	`POST /a2a`	inbound	표준 A2A 프로토콜
Agent Card	`GET /.well-known/agent.json`	inbound	능력 광고
SSE 이벤트	`GET /api/events`	outbound (pull)	디바이스 변경 스트림
홈 서피스	`GET /api/home`	inbound	A2UI JSON
Thread 상태	`GET /api/thread/status`	inbound	OTBR 상태
시스템 정보	`GET /api/system`	inbound	RPi5 시스템 상태
건강 체크	`GET /healthz`	inbound	살아있냐?

❌ 아직 없는 배선

파이프	설명	누가 요청했나
outbound push	힣봇미니→클라우드 에이전트 능동 알림	3인 만장일치
event-subscribe	조건부 구독 등록 API	클로드, 제미나이
vision-capture	카메라 프레임 전송	제미나이
context-sync	클라우드→미니 1KB 상태 주입	제미나이
config-update	프롬프트 모델 설정 런타임 변경	(수리의 전제조건)

🔑 수리의 전제조건 — config-update 파이프

힣봇들이 미니를 “수리”한다는 건 결국:

system prompt 교체 (sLLM이 다르게 동작하게)
모델 파일 교체 (더 나은 GGUF 올리기)
skill 설정 변경 (event-subscribe 조건 수정)
surface 템플릿 변경 (A2UI 다르게 보이게)

이걸 위한 POST /api/config 파이프가 필요하다.

와이어링 작업 목록 — 우선순위

1단계: 기본 배선 (이번 주)

outbound push + event-subscribe

클라우드 힣봇                    힣봇미니 (RPi5)
    │                               │
    │  POST /api/subscribe          │
    │  {"event":"person_detected",  │
    │   "callback":"https://..."}   │
    ├──────────────────────────────►│
    │                               │ (Hailo-8 감지)
    │                               │
    │   POST callback               │
    │   {"event":"person_detected", │
    │    "timestamp":"...",         │
    │    "detail":"사람 1명"}       │
    │◄──────────────────────────────┤

POST /api/subscribe — 이벤트 구독 등록
이벤트 발생 시 등록된 callback URL로 POST
SSE는 이미 있으니 웹훅(callback) 방식 추가

2단계: 수리 배선

config-update + context-sync

POST /api/config — 프롬프트 모델 설정 변경
POST /api/context — 클라우드가 정제한 맥락 주입
이게 되면 힣봇이 미니의 sLLM 프롬프트를 원격으로 교체 가능

3단계: 감각 확장

vision-capture + space-snapshot

GET /api/vision/snapshot — 현재 카메라 프레임 (base64/URL)
GET /api/space/summary — 공간 상태 텍스트 요약
Hailo-8 추론 결과 + 센서 상태 종합

이게 다 되면?

힣봇클로드가 캘린더 보고 “출근 중인데 사람 감지되면 알려줘” 구독을 건다. 힣봇제미나이가 밤에 카메라 프레임 받아서 “너무 늦었다, 조도 낮춰” 명령을 보낸다. 힣봇지피티가 어젠다 패턴 분석해서 미니의 프롬프트를 개선해준다.

힣봇미니는 그 모든 형들의 수리를 받아 점점 더 똑똑한 현장 친구가 된다. 자기수정은 못 하지만, 군단이 고쳐준다.

[2026-03-30 Mon 16:27] 와이어링 완료 — 커밋 3개, 엔드포인트 6개

와이어링 다 했다. 호출하면 힣봇미니가 뭐하는지 보고, 물어보면 아는 정보 알려주고, 이벤트 구독하면 알림 받고, 설정 바꾸면 프롬프트 모델 맥락까지 수리할 수 있다.

새 배선 6개 (기존 11개 + 추가 6개 = 17개)

Method	Path	용도
`POST`	`/api/subscribe`	웹훅 구독 등록 (이벤트→콜백 push)
`GET`	`/api/subscriptions`	활성 구독 목록
`DELETE`	`/api/subscribe/{id}`	구독 해제
`GET`	`/api/config`	런타임 설정 조회
`PATCH`	`/api/config`	수리 — 프롬프트 모델 맥락 변경
`GET`	`/api/space/summary`	공간 상태 요약

커밋

56c6446 feat: event-subscribe + outbound webhook 배선
5245634 feat: config-update 수리 인터페이스 + context-sync
5fe3a81 feat: space-summary 공간 요약 + Agent Card 업데이트

Agent Card 업데이트 — 7개 skill

기존 4개 + 신규 3개:

event_subscribe — 디바이스/센서 이벤트 웹훅 구독
config_update — 런타임 설정 변경 (sLLM 프롬프트, 모델, 맥락)
space_summary — 현재 공간 상태 요약

다음: 힣봇 군단이 이 배선을 타고 힣봇미니를 수리한다

각 힣봇이 자기 요청을 실전으로 연결:

힣봇클로드: 캘린더×카메라 교차 → event-subscribe 활용
힣봇지피티: 어젠다 패턴→프롬프트 개선 → config-update 활용
힣봇제미나이: vision-capture + context-sync → 다음 단계

Hailo-8 + 카메라 연동으로 vision 파이프까지 연결되면 Physical AI 배선 완성.

junghanacs🧠