기술 요약: 장치 컨텍스트 프로토콜 (DCP)

1. 문제 정의

외부 도구들을 오케스트레이션하기 위한 대규모 언어 모델 (LLM) 의 급속한 채택으로 인해 모델 컨텍스트 프로토콜 (MCP) 이 광범위하게 사용되고 있습니다. 그러나 MCP 는 메가바이트 단위의 메모리를 가진 소프트웨어 서비스를 위해 설계되었으며 WebSocket 또는 HTTP 를 통한 JSON-RPC 에 의존하므로, 리소스 제약이 있는 마이크로컨트롤러 (MCU) 가 지배적인 물리적 장치의 '롱테일'에는 적합하지 않습니다.

IoT-MCP 와 같은 기존 시도들은 메모리 발자국을 약 74KB 로 줄였지만, 여전히 가장 작은 상용 MCU(예: Cortex-M0+, ATmega 클래스) 를 배제하고 있으며, 치명적인 안전 문제를 해결하지 못했습니다. 즉, LLM 은 환각을 일으키거나 단위를 혼동하거나 프롬프트 인젝션에 취약할 수 있는 신뢰할 수 없는 호출자입니다. 현재 프로토콜들은 의도를 검증하거나, 기능을 범위화하거나, 프로토콜 계층에서 범위 검사를 강제하는 원시 연산 (primitives) 이 부족하여, 신뢰할 수 없는 LLM 으로부터의 malformed 또는 악의적인 명령에 물리적 하드웨어가 취약하게 남아 있습니다.

2. 방법론 및 아키텍처

저자들은 제약된 장치에 대한 LLM 주도 제어를 위해 특별히 설계된 컴팩트하고 안전 우선의 아키텍처인 **장치 컨텍스트 프로토콜 (DCP)**을 제안합니다. 이 아키텍처는 전통적인 보안 모델을 반전시킵니다. 즉, 장치에 복잡한 보안 로직을 내장하는 대신, DCP 는 호스트 측 Bridge에 '유일한 신뢰 경계 (sole trust boundary)'를 둡니다.

2.1 핵심 구성 요소

• Bridge(호스트 측): 게이트키퍼 역할을 하는 Python 기반 구성 요소입니다. 장치 매니페스트를 보유하고, 기능 토큰을 발급하며, 장치로 바이트가 전송되기 전에 모든 안전 검사 (기능 범위 설정, 범위/유형 검증, dry-run 평가) 를 수행합니다.
• 장치 (MCU 측): 의도를 실행하는 단순화된 펌웨어 계층입니다. 기능 토큰을 검증하거나 복잡한 스키마 검증을 수행할 필요가 없으며, 모든 들어오는 프레임이 Bridge 에 의해 사전 승인되었다고 가정합니다.
• 와이어 포맷: DCP 는 고정된 6 바이트 헤더 뒤에 CBOR 페이로드가 이어지는 컴팩트한 이진 포맷을 사용합니다. 선택적으로 16 바이트 잘라낸 HMAC-SHA256 이 공유 미디어를 위한 와이어 레벨 무결성을 제공합니다.
  • 헤더: 버전, 종류 (호출, 응답, 이벤트, 오류, dry-run), 시퀀스 번호, 의도 이름의 CRC-16 을 인코딩합니다.
  • 페이로드: 파라미터, 단위, 유형의 효율적인 인코딩을 위해 CBOR 를 사용합니다.
  • 크기: 일반적인 단일 파라미터 호출은 HMAC 없이 약 19 바이트, HMAC 포함 시 약 35 바이트인 반면, 표준 MCP JSON-RPC 메시지는 약 180 바이트입니다.

2.2 안전 원시 연산 (Safety Primitives)

DCP 는 애플리케이션 수준의 규율이 아닌 프로토콜 계층의 원시 연산으로 안전 메커니즘을 도입합니다:

1. 기능 토큰 (Capability Tokens): 특정 기능 (예: lamp.write) 과 생존 시간 (time-to-live) 에 범위가 제한된 HMAC 서명 토큰입니다. Bridge 는 모든 호출 시 이를 검증합니다.
2. 매니페스트 기반 검증 (Manifest-Driven Validation): 파라미터는 물리적 단위 (예: percent 단위의 float) 와 정의된 범위로 엄격하게 유형화됩니다. Bridge 는 전송 전에 범위 초과 또는 유형 불일치 값을 거부합니다.
3. Dry-Run: 상태 변경 없이 예측된 결과를 요청할 수 있도록 하는 특정 프레임 종류 (0x81) 입니다. 이는 되돌릴 수 없는 작업에 중요합니다.
4. 와이어 무결성: 공유 물리 미디어 (예: RS-485, 공개 MQTT) 를 위한 선택적 프레임별 HMAC 검증입니다.

3. 주요 기여

1. 프로토콜 설계: LLM 호출자를 위해 명시적으로 설계된 와이어 포맷 및 매니페스트 스키마로, 의도 수준의 명령, 유형으로서의 단위, 그리고 제약된 MCU 에서의 정적 디스패치를 위한 6 바이트 고정 헤더를 특징으로 합니다.
2. 아키텍처 패턴: 복잡한 검증을 장치에서 오프로딩하면서도 단순한 펌웨어 발자국을 유지하는 유일한 신뢰 경계로 기능하는 호스트 측 Bridge.
3. 참조 구현:
   • Python Bridge: 여러 전송 (UART, MQTT, BLE GATT, 루프백) 을 지원하며 DCP 장치를 모든 MCP 호환 호스트를 위한 MCP 도구로 래핑합니다.
   • ESP32 펌웨어: 자체 SHA-256 을 지원하여 무결성을 보장하는 Arduino 호환 C++ 라이브러리로, 기본 Arduino 런타임을 제외하고 27.6KB 플래시 및 0.6KB RAM을 측정합니다.
4. 준수 테스트 스위트: 다양한 구현 (C, Rust, Go) 간 기계적 검증을 보장하는 언어 중립적인 YAML 기반의 '골든 프레임 (golden frames)' 스위트.
5. 경험적 연구: AgentDojo 의 프롬프트 인젝션 템플릿을 포함한 6 가지 범주의 적대적 프롬프트에 대해 5 개 LLM(DeepSeek, Alibaba Qwen, Zhipu, MiniMax) 에서 675 개의 도구 호출을 사용하여 수행한 엄격한 평가.

4. 결과

경험적 연구는 다음과 같은 주요 발견을 도출했습니다:

• 안전 효과성: DCP 는 장치에 도달하기 전에 **100%**의 기능 상승 시도와 **78%**의 프롬프트 인젝션 시도를 거부했습니다. 반면, Raw MCP 와 IoT-MCP 는 이러한 시도의 **0–1%**만 거부했습니다.
• 표현력 vs 발자국: DCP 는 잘 구성된 OpenAPI 3 명세의 스키마 계층 거부 표현력과 일치하지만, 런타임 발자국은 세 자리 수 (orders of magnitude) 더 작게(OpenAPI 스택의 수십 MB 대비 27.6KB 플래시) 달성했습니다.
• 지연 시간: 동일한 ESP32-S3 하드웨어에 대한 A/B 테스트 결과, DCP 의 전체 안전 검증 (기능 + 범위 + dry-run + CBOR/COBS/CRC) 은 원시 개행 구분 JSON 와이어에 비해 측정 가능한 지연 시간 비용이 전혀 추가되지 않았습니다. 두 프로토콜 모두 왕복을 약 15.6ms(서로 5µs 이내) 에 완료했습니다.
• 메모리 효율성: DCP 레이어는 장치에 0.6KB 의 정적 RAM만 추가하는 반면, IoT-MCP 는 최대 74KB 의 메모리를 보고했습니다.

5. 중요성 및 포지셔닝

이 논문은 DCP 를 SaaS 연결로 이동 중인 엔터프라이즈 중심 MCP 와 그것이 접근할 수 없는 물리적 장치 사이의 결손된 레이어로 위치시킵니다.

• 격차 해소: DCP 는 현재 MCP 구현체들에 의해 배제되는 물리적 장치의 '롱테일'(100KB 미만의 플래시, 배터리 구동, BLE 전용) 의 특정 제약을 해결합니다.
• 와이어 수준의 안전: 런타임 가드레일이나 사후 감지에 의존하는 이전 접근법과 달리, DCP 는 안전을 와이어 포맷 및 스키마에 직접 내장하여 malformed 또는 환각된 호출이 네트워크를 통과하는 것을 방지합니다.
• 조립 가능성: DCP 는 기존 표준 (MCP, WoT, Matter) 과 조립되도록 설계되었습니다. Bridge 는 DCP 장치를 MCP 호스트에 노출할 수 있으며, 저자들은 WoT Thing Description 가져오기를 지원할 계획입니다.
• 경험적 검증: 이 논문은 실제 LLM 에 대한 경험적 적대적 테스트가 필요한 안전 명세 확장을 발견하는 가장 효과적인 방법이라고 주장하며, 이 과정이 DCP 명세 (v0.3.1) 에 문자열 패턴 및 max_length 제약 조건이 추가되는 데 직접적으로 기여했다고 밝힙니다.

저자들은 DCP 가 제약된 하드웨어에 대한 LLM 주도 제어를 위한 실현 가능하고 안전 우선의 아키텍처를 제공하여, 이전 프로토콜들이 불가능했던 장치에서 에이전트의 안전한 배포를 가능하게 한다고 결론지었습니다.