이 스마트 홈 에이전트는 자신의 1B 모델을 신뢰할 수 없는 입력으로 취급합니다
요약
EdgeHome Harness는 1B 규모의 소형 모델을 엣지 디바이스에서 안전하게 실행하기 위한 Rust 기반 프레임워크입니다. 모델의 출력을 '신뢰할 수 없는 입력'으로 간주하고, 결정론적인 Rust 코드를 통해 검증 및 제어하는 아키텍처를 제안합니다.
핵심 포인트
- 모델 출력을 사용자 입력과 동일한 '신뢰할 수 없는' 데이터로 취급
- Rust를 활용한 결정론적 스키마 검증 및 정책 게이트 적용
- 메모리 압박 시 모델을 중단하고 규칙 기반으로 전환하는 압박 정책
- 초제한적인 엣지 하드웨어 환경을 위한 경량 에이전트 스택 설계
AI 에이전트의 신뢰성은 모델의 속성이 아니라 하네스 (harness) 속성입니다.
가장 깔끔한 증거는 모델 크기 사다리의 맨 아래에서 나타났습니다. 모델의 제작자가 직접 선보인, 스마트 홈을 제어하는 688 MB 크기의 모델입니다. 연구할 가치가 있는 부분은 그 모델을 감싸고 있는 25 MB의 Rust 코드입니다.
EdgeHome Harness는 디스크 상에서 688 MB, 런타임 시 약 1 GB인 MiniCPM5-1B를 25~64 MB 사이의 Rust 하네스(harness)와 결합하여, 2 GB RAM을 가진 장치를 타겟으로 합니다. 한 커뮤니티 개발자가 이를 구축했고, OpenBMB가 이를 세상에 공개했습니다. 모두가 인용하게 될 문구는 전체 에이전트 스택이 초제한적인 엣지 하드웨어 (edge hardware)에 들어간다는 점입니다. 하지만 중요한 설계 결정은 다릅니다. 모델은 아무것도 할 수 없도록 허용되지 않습니다.
JSON 이후의 모든 것은 결정론적(Deterministic)입니다
EdgeHome Harness는 1B 모델이 신뢰할 수 있는 스마트 홈 컨트롤러로 작동하게 만드는 Rust 프레임워크입니다. 모델은 오직 후보 JSON 명령만을 생성합니다. 결정론적인 (Deterministic) Rust 코드가 스키마 (schema)를 검증하고, 레지스트리 (registry)를 기준으로 장치를 확인하며, 기능을 체크하고, 실패 시 차단하는 정책 게이트 (fail-closed policy gates)를 적용하며, 드라이 런 (dry run)을 계획하고, 재생 가능한 트레이스 (trace)를 기록합니다.
저장소 (repo)는 논지를 명확히 밝히고 있습니다. 모델은 파이프라인의 최상단에 위치하며, 후보 생성 이후의 모든 것은 하네스 (harness)의 영역이라는 것입니다. 문서에는 신뢰 테이블 (trust table)이 있습니다. 모델의 출력 타입은 '신뢰할 수 없는 (untrusted)' 것으로 라벨링되어 있습니다. 부분적으로 신뢰하는 것이 아닙니다. 웹 양식에서 사용자 입력을 다루는 방식과 똑같이 '신뢰할 수 없는' 것입니다.
하네스는 Home Assistant, MQTT, 그리고 MIoT 또는 Matter 브릿지를 위한 페이로드 어댑터 (payload adapters)를 제공합니다. 모델 자체는 구조화된 출력 요청 (structured output request)을 통해 Ollama와 통신하는 것 외에는 아무것과도 대화하지 않습니다.
모델은 가장 먼저 희생되는 요소입니다
1B 모델은 말을 반복하거나, 닫는 중괄호 이후에도 횡설수설하며, 거의 파싱될 뻔한 JSON을 내뱉기도 합니다. EdgeHome은 이 세 가지 상황 모두를 예산에 포함합니다. 즉, 무한 루프 탐지 기능이 있는 출력 거버너 (output governor), 재시도 정책 (retry policy), 그리고 폴백 분류 (fallback classification)를 갖추고 있습니다. 단기 메모리 또한 컨텍스트 윈도우 (context window) 밖에 유지됩니다. Rust가 마지막 타겟과 확인된 별칭 (aliases)을 추적하는데, 이는 2 GB 보드에서 컨텍스트 (context)가 가장 희소한 자원이기 때문입니다.
가장 날카로운 세부 사항은 압박 정책 (pressure policy)입니다. 메모리가 부족해지면, 하네스 (harness)는 모델의 컨텍스트 (context)를 줄이고, 그다음에는 출력 예산 (output budget)을 줄이며, 임계 압박 (critical pressure) 상황에서는 모델을 완전히 중단하고 규칙 (rules) 기반으로 전환합니다. 이 아키텍처에서 언어 모델 (language model)은 스택 (stack) 내에서 가장 쉽게 폐기할 수 있는 구성 요소입니다. 실행 백엔드 (execution backends)는 기본적으로 비활성화된 상태로 배포되며, 모든 계획은 먼저 드라이 런 (dry run)을 거치고, 108가지 케이스의 평가 게이트 (eval gate)가 릴리스 (releases) 여부를 결정합니다.
동일한 경계가 프런티어 규모에서도 유지됩니다
저는 크기 사다리의 정반대 끝에서도 동일한 패턴을 실행합니다. 저의 코딩 에이전트 (coding agent)는 모델이 무엇을 믿든 상관없이, 하네스가 파일 시스템 (filesystem)과 네트워크 경계 (network boundaries)를 소유하는 샌드박스 (sandbox) 내부에서 작동합니다. 저의 지갑 실험은 에이전트와 체인 (chain) 사이에 지출 한도와 허용 목록 (allowlist)이 포함된 정책 게이트 (policy gate)를 둡니다. 왜냐하면 에이전트가 호출할 수 있는 승인 단계 (approval step)는 에이전트가 위조할 수 있는 승인 단계이기 때문입니다. 강제 집행 (enforcement)은 모델 외부에 존재해야 하며, 그렇지 않으면 존재하지 않는 것과 같습니다.
저는 코딩 에이전트 (coding agents)와 저가형 모델 파이프라인 (cheap-model pipelines)에 대해 이 주장을 해왔습니다. EdgeHome은 동일한 논리를 25 MB로 컴파일하여 전등 스위치에 적용한 것입니다.
이 프로젝트는 공지사항에 담긴 질문과는 다른 질문을 해결합니다. 1B 모델이 스마트 홈을 실행할 수 있는지 여부가 아닙니다. 어떤 크기의 모델이라도 얼마나 적은 결정만을 내려야 하는가에 대한 것입니다. 오늘 밤 발생한 에이전트 실패의 원인을 추적해 보십시오. 모델이 너무 작아서 발생한 것이 얼마나 되며, 검증기 (validator)가 담당해야 할 결정을 하네스가 모델에게 허용했기 때문에 발생한 것이 얼마나 됩니까? EdgeHome의 해답은 신뢰 테이블 (trust table)입니다. 대부분의 에이전트 스택은 이를 작성해 본 적이 없습니다.
저는 실제 빌드 — AI 통합, cron 기반 자동화, 그리고 프로덕션에서 고장 나는 부분들에 대한 현장 노트 (field notes)를 작성합니다. 2주마다 새로운 포스트가 올라옵니다. 이 글이 유용했다면, 에이전트를 위한 인간 참여형 승인 경계에 관한 노트 (notes on human-in-the-loop approval boundaries for agents)가 동반 다운로드 자료입니다.
AI 자동 생성 콘텐츠
본 콘텐츠는 Dev.to AI tag의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기