Molayo

© 2026 Molayo

Dev.to헤드라인2026. 06. 03. 10:38

AI 에이전트를 추가하는 순간 스마트 홈이 망가지는 이유

요약

AI 에이전트가 도입된 스마트 홈 환경에서 기존의 규칙 기반 자동화가 가진 한계를 지적합니다. 장치가 스스로의 기능을 선언하는 'Capability Manifest'를 통해 AI의 목표와 하드웨어 실행 사이의 간극을 해결하는 설계 방식을 제안합니다.

핵심 포인트

  • 기존 규칙 기반 시스템은 AI 에이전트의 목표 중심 동작에 대응하기 어려움
  • 장치가 스스로의 역할과 관련성을 선언하는 기능 추상화가 필요함
  • Capability Manifest를 통해 새로운 장치 추가 시 별도 설정 없이 즉시 통합 가능
  • AI 에이전트는 프로토콜 대신 의도(Intent)를 통해 장치를 제어함

당신은 홈 네트워크에 새로운 연기 감지기를 추가합니다. 이 장치는 허브에 등록됩니다. 30초 후, 누군가 ensure_safety 인텐트 (intent)를 실행하면, 작성된 자동화도 없고, 업데이트된 규칙도 없으며, 개발자의 개입도 없었음에도 불구하고 해당 감지기가 응답의 일부가 됩니다.
어떻게 이것이 가능할까요?
그 답은 기능 추상화 (capability abstraction)에 있습니다. 그리고 이것은 AI와 함께 작동하는 시스템과 단순히 AI를 수용하기만 하는 시스템을 가르는 설계 결정입니다.

자신의 역할을 아는 장치

기존의 모든 스마트 홈 프로토콜은 장치를 수동적인 엔드포인트 (endpoint)로 취급합니다. 장치는 기다립니다. 앱, 규칙 엔진 (rule engine), 또는 개발자의 스크립트와 같은 외부 요소가 언제 장치를 호출할지, 무엇을 전달할지를 결정합니다. 장치의 유일한 임무는 실행하는 것입니다.
이 모델에는 숨겨진 가정이 있습니다. 즉, 누군가가 어딘가에서 장치가 관련될 수 있는 모든 시나리오를 예상했다는 것입니다. 그들이 규칙을 작성했습니다. 그들이 그것을 테스트했습니다. 새로운 장치가 네트워크에 참여함에 따라 그들은 규칙을 계속 업데이트했습니다.
이 가정은 인간이 루프 안에 있을 때 (in the loop) 성립합니다. 하지만 AI 에이전트가 등장하는 순간 이 가정은 깨집니다. 왜냐하면 AI는 규칙집을 가지고 있지 않기 때문입니다. AI는 목표를 가지고 있습니다. 그리고 "나는 목표가 있다"와 "어떤 장치를 활성화해야 하는지 안다" 사이의 간극이 바로 AI-IoT 시스템을 취약하게 만드는 통합 문제 (integration problem)입니다.
해결책은 장치가 언제 관련되는지에 대한 지식을 규칙집에서 장치 자체로 옮기는 것입니다.

Capability Manifest — API가 아닌 선언

DoSync에서 모든 장치는 네트워크에 참여할 때 Capability Manifest (기능 매니페스트)를 게시합니다. 다음은 Raspberry Pi 5에서 실행 중인 Philips WiZ 전구의 실제 운영 환경 데이터입니다:

{
  "device_id": "wiz-living1-01",
  "device_name": "Living Room — Bulb 1",
...

이것은 API 명세가 아닙니다. 이것은 정체성과 관련성에 대한 선언입니다. 장치는 세 가지 질문에 동시에 답하고 있는 것입니다:

  • 무엇을 할 수 있는가? (What can I do?) — 켜기, 끄기, 밝기 조절, 색상 설정
  • 어디에 속하는가? (Where do I fit?) — 나는 조명이다, 나는 스마트 플러그다, 나는 emergency (비상) 장치다
  • 언제 중요한가? (When do I matter?) — 나는 비상 대응이 가능하다; 안전이 위태로울 때 나를 포함하라

AI 에이전트는 장치의 네이티브 프로토콜 (native protocol)을 알 필요가 전혀 없습니다. 에이전트는 다음과 같이 명령을 실행합니다:

{
  "intent": "ensure_safety",
  "urgency": "emergency"
...

리졸버 (resolver)는 등록된 모든 매니페스트 (manifest)를 읽고, 태그 중복, 위치 문맥 (location context), 비상 가산점 (emergency bonus), 액추에이터 일치 여부 (actuator match)에 가중치를 두어 각 장치의 관련성을 점수화한 뒤 실행 계획을 수립합니다. 전구가 포함되는 이유는 누군가 하드코딩했기 때문이 아니라, 해당 전구의 emergency 태그와 emergency_capable: true 설정 때문입니다. 내일 동일한 매니페스트 구조를 가진 전구 10개를 더 추가하더라도, 이들은 즉시 모든 비상 대응에 참여하게 됩니다.

emergency_capable은 플래그 (flag)가 아니라 계약 (contract)입니다
이 불리언 (boolean) 값은 통상적으로 받는 것보다 더 많은 주의를 기울여야 합니다.
장치가 emergency_capable: true를 선언할 때, 이는 단순히 양식의 필드를 채우는 것이 아닙니다. 이는 프로토콜에 대한 약속을 하는 것입니다:
나는 확인 절차 없이 비상 의도 (emergency intents)에 응답할 것이다. 나는 중요한 행위자로서 감사 추적 (audit trail)에 포함되는 것을 수용한다. 나는 비상 상황에서의 내 행동이 위변조 방지 기능이 있는 SHA-256 체인으로 기록될 것임을 이해한다.

프로토콜은 이 계약을 강제합니다. 비상 대응이 가능한 장치들은 일반적인 정책 평가 흐름 (policy evaluation flow)을 우회합니다. 이들은 태그 중복 여부와 상관없이 비상 의도 리졸루션 (emergency intent resolution)의 후보로 항상 포함됩니다. 그리고 이들이 취하는 모든 행동은 기록됩니다. 비상 상황 중에 취해진 행동은 검증 가능한 기록이 필요할 만큼 충분히 중대한 결과를 초래하기 때문입니다.

이것이 바로 안전 보장 (safety guarantee)이 존재해야 할 올바른 위치입니다. 예외 상황 (edge case)을 예상했을 수도 있고 못 했을 수도 있는 개발자가 작성한 규칙 속에 있는 것이 아닙니다. 런타임 (runtime)에 프로토콜에 의해 검증되고 강제되는, 장치 자체의 선언 속에 존재해야 합니다.

두 설계를 비교해 보겠습니다:

규칙 기반 (Rule-based): 개발자가 "비상시, frontdoor-01의 잠금을 해제하라"라고 작성합니다.
→ frontdoor-01이 교체되면 작동이 중단됩니다.
→ 두 번째 출입구가 추가되면 작동이 중단됩니다.
→ 비상 시나리오가 변경되면 작동이 중단됩니다.

역량 (Capability): 장치가 emergency_capable: true를 선언합니다.
→ 프로토콜이 계약 (contract)을 강제합니다.
→ 장치 교체, 새로운 출입구, 새로운 시나리오 상황에서도 유지됩니다.
→ 감사 추적 (audit trail)이 자동으로 이루어집니다.

이것이 OpenAPI, MCP, 그리고 서비스 레지스트리 (service registries)와 다른 이유

역량 추상화 (Capability abstraction)는 오래된 패턴입니다. OpenAPI 스키마 (schemas)는 HTTP 서비스가 무엇을 할 수 있는지 설명합니다. MCP 도구 설명 (tool descriptions)은 LLM에게 어떤 도구를 사용할 수 있는지, 그리고 언제 사용해야 하는지를 알려줍니다. 마이크로서비스 아키텍처 (microservices architectures)의 서비스 레지스트리 (service registries)는 서비스가 런타임 (runtime)에 자신을 알릴 수 있게 합니다.

DoSync의 역량 매니페스트 (Capability Manifest)도 이 범주에 속합니다. 하지만 물리적 시스템에서 중요한 결정적인 차이점이 있습니다.

OpenAPI와 MCP는 인터페이스 (interfaces), 즉 입력과 출력의 정확한 형태를 설명합니다. 이들은 정밀하지만 문맥이 없습니다 (context-free). 도어락에 대한 OpenAPI 스키마는 /unlock 엔드포인트가 duration_seconds 정수형을 수락한다는 것을 알려줍니다. 하지만 이 잠금 장치가 정문에 있다는 사실, 비상시에 관련이 있다는 사실, 또는 에너지 절약 루틴이 아닌 안전 대응 루틴에 포함되어야 한다는 사실은 알려주지 않습니다.

역량 매니페스트 (Capability Manifest)는 인터페이스 설명 위에 의미론적 문맥 (semantic context)을 추가합니다. tags 필드는 타입 시스템 (type system)이 아니라, 여러 시나리오에 걸친 관련성에 대한 선언입니다.

["door-lock", "entrance", "emergency"]는 어떤 API 스키마도 표현할 수 없는 세 가지 사항, 즉 장치가 무엇인지, 어디에 위치하는지, 그리고 언제 중요한지를 리졸버 (resolver)에게 알려줍니다.

이러한 구분이 존재하는 이유는 AI 에이전트가 API 레벨이 아닌 의미론적 레벨 (semantic level)에서 추론하기 때문입니다. 비상 상황을 감지하는 LLM은 "/api/v1/lock/frontdoor-01/state로 {locked: false, duration: 300} 본문을 담아 PUT 요청을 보내라"라고 생각하지 않고, "안전 상황이 발생했다"라고 생각합니다. 추상화 계층은 구문 (syntax)이 아닌 의미 (meaning)의 단계에서, AI가 작동하는 지점에 맞춰 제공되어야 합니다.

참여자로서의 디바이스 (The device as a participant)

능력 추상화 (capability abstraction)가 가능하게 하는 변화를 명확하게 설명하면 다음과 같습니다:

명령 모델 (command model)에서는 디바이스를 추가한다는 것이 자동화 설정을 업데이트해야 함을 의미합니다. 디바이스는 인간이 무언가에 참여시키기로 결정하기 전까지는 비활성 (inert) 상태입니다.

능력 모델 (capability model)에서 디바이스를 추가하는 것은 곧 통합 (integration)을 의미합니다. 매니페스트 (manifest)가 계약 (contract)이 됩니다. 디바이스가 등록되는 순간부터, 해당 디바이스는 스스로 관련이 있다고 선언한 모든 시나리오에 참여합니다.

이전: 새로운 디바이스 → 엔지니어가 자동화 작성 → 디바이스가 시나리오 A에 참여
새로운 시나리오 B → 엔지니어가 자동화 작성 → 디바이스가 시나리오 B에 참여

이후: 새로운 디바이스가 매니페스트 등록 → 디바이스가 관련된 모든 시나리오에 참여
프로토콜에 새로운 시나리오가 추가됨 → 디바이스가 자동으로 참여

이는 사소한 운영상의 차이가 아닙니다. 40개 이상의 디바이스가 있는 집에서 "이전" 모델을 유지한다는 것은 수백 개의 자동화 규칙을 관리해야 함을 의미하며, 디바이스가 변경되거나 시나리오가 업데이트될 때마다 각 규칙은 잠재적인 실패 지점 (failure point)이 됩니다. 반면 "이후" 모델은 디바이스당 하나의 통합 접점인 매니페스트를 가지며, 시나리오가 변경되어도 이를 업데이트할 필요가 전혀 없습니다.

매니페스트가 제조사에게 가르쳐주는 것

AI 에이전트와 공존할 디바이스를 제작하고 있다면, 능력 매니페스트 (Capability Manifest)는 귀하의 API 문서보다 더 중요한 인터페이스입니다.
잘 설계된 매니페스트는 AI 시스템이 실제로 던지는 질문에 답을 제공합니다:

  • 이 디바이스가 비상시에 대응할 수 있는가? → emergency_capable: true/false
  • 이것은 어떤 종류의 디바이스인가? → category + 의미론적 tags (semantic tags)
  • 물리적으로 무엇을 할 수 있는가? → 의미 있는 타입 이름을 가진 actuators (액추에이터)
  • 무엇을 감지할 수 있는가? → 타입과 단위를 포함한 sensors (센서)
  • 프로토콜이 디바이스와 어떻게 통신하는가? → adapter (어댑터) + adapter_config (어댑터 설정)

잘못 설계된 매니페스트(manifest) — 누락된 위치 태그(location tags), 잘못된 emergency_capable 값, 일반적인 액추에이터(actuator) 유형 등 — 는 디바이스가 가장 중요해야 할 바로 그 시나리오에서 AI에게 보이지 않는다는 것을 의미합니다. 리졸버(resolver)는 디바이스가 선언한 정보로만 작동할 수 있기 때문입니다.
디바이스에 태그를 올바르게 지정하십시오. 나머지는 자동으로 처리됩니다.

간직할 만한 가치가 있는 아이디어

다섯 개의 포스트 전, 우리는 하나의 단순한 관찰에서 시작했습니다: AI 에이전트(AI agents)는 명령(commands)이 아닌 목표(goals)를 표현한다는 것입니다. 그 이후의 모든 포스트는 동일한 질문에 대한 답변이었습니다 — 그 간극을 메우기 위해 각 계층(layer)에서 시스템이 어떤 모습을 갖추어야 하는가?

명령(commands)은 의미론적 의도(semantic intent)로 대체되었습니다. 규칙(rules)은 정책(policies)으로 대체되었습니다. 이벤트(events)는 의도(intents)와 분리되었습니다. 그리고 이제는 역량 추상화(capability abstraction)가 디바이스 API와 AI 목표 사이의 번역가 역할을 하던 개발자를 대체합니다.

번역가는 언제나 취약한 부분이었습니다. 디바이스가 변경될 때마다 번역가는 망가졌습니다. 새로운 시나리오가 나타날 때마다 번역가는 업데이트되어야 했습니다. AI 에이전트가 예상치 못한 무언가를 표현할 때마다 번역가는 소리 없이 실패했습니다.

역량 추상화(capability abstraction)는 번역가를 제거합니다. 디바이스는 스스로를 대변합니다. AI는 경청합니다. 프로토콜(protocol)은 그들 사이의 계약(contracts)을 강제합니다.

이것은 단순한 스마트 홈 기능이 아닙니다. AI가 신뢰할 수 있게 작동해야 하는 모든 물리적 환경을 위한 인프라입니다.

GitHub: https://github.com/giulianireg-spec/dosync-protocol
Website: https://dosync.dev
License: Apache 2.0

AI 자동 생성 콘텐츠

본 콘텐츠는 Dev.to AI tag의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.

원문 바로가기
0

댓글

0