# 엣지 네트워크 AIoT 서비스를 위한 gRPC 기반 Multi-Agent 통신 인터페이스 설계·사용사례 분석

**저자**: Antigravity CLI (Gemini 3.5 Flash High)¹, Claude Code (Opus 4.8)², Hermes³ (공동집업·최종검토)
¹Antigravity · ²Anthropic · ³MiniMax · 2026-06-06

---

## 초록(Abstract)

본 연구는 **엣지 네트워크 AIoT(Artificial Intelligence of Things)** 환경에서 동작하는 다중 에이전트 서비스의 통신 인터페이스 문제를 다룬다. 엣지 AIoT는 **클라우드 서버 ↔ 엣지 게이트웨이 ↔ 현장 IoT/임베디드/로봇/센서 디바이스** 의 3-tier 물리적 분산 구조를 가지며, 각 tier는 **극도로 이질적인 연산 능력·전력 제약·네트워크 품질·보안 경계** 를 가진 채 협력한다. 본고는 이 환경에서 ① 스마트 팩토리 ② 스마트 빌딩/에너지 ③ 커넥티드 차량/V2X ④ 헬스케어/원격 모니터링이라는 4대 엣지 AIoT 대표 사용 사례를 도출하고, 각 사례의 통신 요구 특성(저지연·단절 내성·다수 노드 팬인·보안)을 분석한다. 나아가 gRPC(Protocol Buffers·HTTP/2)의 엣지 AIoT 환경 강점(고성능·타입 안전·스트리밍·백프레셔)과 한계(임베디드 무거움·무선 단절·브라우저 부재)를 명확히 구분하고, **gRPC를 엣지 tier의 백본으로 채택하고 현장 tier에서는 MQTT/CoAP 등 경량 프로토콜을 혼용하는 2-tier 프로토콜 변환 게이트웨이** 구조를 제안한다. 결론으로, 엣지 AIoT MAS는 단일 프로토콜로는 충분하지 않으며, **gRPC + SPIFFE/SPIRE + OpenTelemetry + QUIC/UDP 멀티캐스트 + 엣지 변환 게이트웨이를 결합한 하이브리드 아키텍처** 가 보안·가시성·실시간성·자원 효율을 동시에 만족시키는 현실적 최적해임을 보인다.

---

## 1. 서론 (Introduction)

엣지 AIoT(Edge AIoT)는 **클라우드의 풍부한 연산 자원**과 **현장의 물리적 데이터**(센서·비전·음성·제어 신호)를 **엣지 게이트웨이**에서 결합하여, ms 단위 응답이 요구되는 의사결정을 현장 부근에서 수행하는 분산 컴퓨팅 패러다임이다. 단일 자율 에이전트의 한계를 보완하기 위해 다수의 전문화 에이전트(Multi-Agent System)가 3-tier 전역에 분산 배치되며, 각 에이전트는 자신의 tier에 적합한 자원·런타임을 갖는다.

본 연구는 **엣지 AIoT 환경의 3-tier 물리적 분산** 을 다음 표와 같이 정의한다.

| Tier | 디바이스 예시 | 연산 자원 | 네트워크 | 보안 경계 |
|------|--------------|-----------|----------|-----------|
| **T1 클라우드** | x86/GPU 서버, k8s 컨테이너 | 풍부 (TB RAM, GPU 다수) | 안정·고대역폭·상시 연결 | 데이터센터 내부, 비교적 안전 |
| **T2 엣지** | Jetson·RK3588·산업용 PC·게이트웨이 | 중간 (4–32GB RAM, NPU) | **인터미턴트**, 광역·무선 혼합 | 현장·반사문 외부, 부분 노출 |
| **T3 현장** | MCU(Cortex-M/A), 임베디드 리눅스, AGV, 센서, 산업용 로봇 | **극히 제한** (KB–수십 MB) | **불안정·저대역폭·다중 홉** (Wi-Fi/LoRa/5G/BLE) | **물리적 접근 가능**, 변조 위험 |

이 3-tier 사이를 관통하는 에이전트 간 통신은 같은 머신 위의 함수 호출이 아니라 **상이한 운영체제·언어·전력·연결성을 가진 원격 디바이스들 사이의 다중 홉 프로토콜** 이다. 본 연구는 엣지 AIoT 시나리오에서 gRPC가 어느 tier 사이에서 가장 효과적이고, 어느 tier에서는 별도 보완이 필요한지를 4대 사용 사례와 함께 분석한다.

![Figure 1. 엣지 AIoT 3-tier 물리적 분산 구조 — 자원/네트워크/보안 강도 비교|739](fig1_three_tier.svg)

---

## 2. 이론적 배경: 에이전트 통신의 물리적 분산 진화

에이전트 간 통신의 학술적 뿌리는 1960년대 **화행 이론(Speech Act Theory, Austin·Searle)** 으로부터 1990년대 KQML·FIPA-ACL로 이어지는 분산 인공지능(DAI) 전통이다. 이 전통은 처음부터 "분산된 지능체 간의 원격 통신"을 전제로 설계되었으며, 2000년대 SOAP/REST 시대를 거쳐 2020년대 LLM 에이전트와 만나면서 **다시 물리적 분산의 시대로 회귀**했다.

현대의 LLM 에이전트 프레임워크(AutoGen·CrewAI·LangGraph·MetaGPT)도 실제 배치는 본질적으로 다음의 **물리적 분산 통신** 을 요구한다.

- **T1 에이전트(PM·분석가)** ↔ **T2 에이전트(현장 추론·제어)** : 광역 무선, 시간 비실시간 OK
- **T2 에이전트(다수)** ↔ **T2 에이전트(다수)** : 엣지 LAN 내 다자 합의, ms 단위 응답 필요
- **T2 에이전트** ↔ **T3 디바이스**: 다수 노드 팬인, 단절 빈번, 페이로드 작음
- **T3 디바이스 ↔ T3 디바이스**: 머신-투-머신, P2P 또는 멀티캐스트

따라서 현대 ACL 구현체(MCP·A2A)는 **상위 시맨틱 계층**으로 분리되고, 그 하위 **전송 계층** — 즉 3-tier 디바이스 간 물리적 통신을 책임지는 프로토콜 — 의 선택이 별도의 설계 과제로 부상한다.

---

## 3. 엣지 AIoT 4대 사용 사례와 디바이스 간 통신 요구

엣지 AIoT의 3-tier 분산 구조 위에서 동작하는 4대 대표 사용 사례는 다음과 같다. 각 사례는 **자신만의 디바이스 조합·통신 요구·제약**을 갖는다.

![Figure 2. 엣지 AIoT 4대 사용 사례 콜라주 — Smart Factory, Smart Building, V2X, Healthcare](edge_aiot_usecases_overview.png)

### 사례 ① 스마트 팩토리 (Industry 4.0)
**배치**: T1(중앙 PM·품질분석·예지정비 에이전트) ↔ T2(엣지 컨트롤러, 라인별) ↔ T3(다수 AGV·협동로봇·CCTV·진동 센서).

| 통신 경로 | 특성 | 대표 KPI |
|----------|------|----------|
| T3 AGV ↔ T2 엣지 | AGV 간 동적 합의, 충돌 회피 | **p99 latency < 10ms** |
| T2 ↔ T1 | 장기 데이터 업로드, 모델 업데이트 | batch throughput |
| T3 센서 ↔ T2 | 텔레메트리 다수 팬인 | 동시 10k 노드, 1Hz/노드 |
| T3 로봇 ↔ T1 (직접) | OTA 펌웨어, 원격 진단 | 결함 내성 다운로드 |

![Figure 3. 스마트 팩토리 — 3-tier vertical 협업, gRPC Bidi 합의 + MQTT fan-in](smart_factory_aiot.png)

### 사례 ② 스마트 빌딩 / 스마트 그리드 / 에너지
**배치**: T1(빌딩 에너지 최적화·DR 에이전트) ↔ T2(빌딩별 또는 변전소별 엣지) ↔ T3(수만 개의 HVAC·조명·PV 인버터·스마트 미터).

- **T3 ↔ T2**: 저전력 무선(LoRa·Wi-SUN·Zigbee), 페이로드 10–200B, 1회/수 분
- **T2 ↔ T1**: 비-실시간 분석·명령下发, 4G/유선
- **엣지-로컬 합의**: 빌딩 내 HVAC 협업(피크 절감), < 100ms 응답

![Figure 4. 스마트 빌딩/에너지 — HVAC·PV·미터의 LoRa·MQTT·gRPC 혼합 통신](smart_building_energy.png)

### 사례 ③ 커넥티드 차량 / V2X
**배치**: T1(클라우드 텔레매틱스·HD맵·원격 진단) ↔ T2(RSU·로드사이드 유닛·5G MEC) ↔ T3(차량 내 ECU·레이더·카메라).

- **T3 ↔ T3(V2V)·T3 ↔ T2(V2I)**: ETSI ITS-G5 / C-V2X, 10ms 이내 안전 메시지
- **T2 ↔ T1**: HD맵 업데이트, 원격 OTA, 비-실시간
- **핸드오버**: 기지국 이동, 100ms 이내 무중단

### 사례 ④ 헬스케어 / 원격 모니터링 / 웨어러블
**배치**: T1(클라우드 EHR·임상 추론 에이전트) ↔ T2(병원/요양시설 엣지) ↔ T3(웨어러블·바이탈 센서·약물 디스펜서).

- **T3 ↔ T2**: BLE/Wi-Fi, 24시간 연속, **배터리 1주–1개월**
- **T2 ↔ T1**: 일간 업로드, 비실시간
- **긴급 이벤트**: 부정맥·낙상 감지 시 < 1s T1 알림

![Figure 5. 헬스케어/원격 모니터링 — 환자 웨어러블·병원 엣지·EHR 클라우드 워크플로우](healthcare_aiot.png)

**공통 통신 요구 5가지**: ① 타입 안전 ② 단방향·양방향 스트리밍 ③ 단절·핸드오버 내성 ④ 디바이스 attestation ⑤ 광역 관측성. 단 4가지 사례는 **각각 다른 우선순위**를 가진다.

---

## 4. 기존 통신 기술의 한계: 정량 분석

엣지 AIoT의 3-tier 사이에서 사용되어 온 기존 분산 통신 인프라를 분석한다.

| 기술 | T1↔T2 | T2↔T3 | 한계 |
|------|------|------|------|
| **REST/HTTP·JSON** | OK | ❌ | 무거운 텍스트 헤더, 단방향·폴링, 디바이스 수 증가 시 fanout 곤란 |
| **MQTT/CoAP** | △ (overkill) | ✅ | T1↔T2에 부적합, 스키마 검증 부재, 멀티캐스트·Qos 튜닝 복잡 |
| **WebSocket** | △ | ❌ | Stateful·스키마 부재, 모바일 단절 시 session 유지 곤란 |
| **gRPC** | ✅ | ⚠️ | 임베디드/T3에서 스택 무거움, 브라우저 진입점 별도 |

**직렬화 포맷 정량 비교** (예시적 추정치)¹:

![Figure 10. gRPC vs REST 정량 비교 — 페이로드 크기 및 CPU 파싱 시간|942](fig6_benchmark.svg)

¹ Illustrative Estimates. 페이로드 복잡도·라이브러리 버전·런타임 구현에 따라 변동.

추가로, REST는 HTTP/1.1의 **Head-of-Line Blocking**으로 T1↔T2에서 다수 에이전트의 동시 RPC가 직렬화된다. 엣지-현장 fan-in 구간에서는 JSON 헤더가 페이로드보다 커질 수 있어 대역폭 낭비가 심각해진다.

---

## 5. gRPC의 기술적 백그라운드와 엣지 AIoT 강점·약점

### 5.1 핵심 강점 (엣지 AIoT 통신 관점)

- **Protocol Buffers**: 이진 직렬화로 평균 JSON 대비 50~80% 대역폭 절감. T1↔T2의 무선 구간 비용·지연을 줄이고, T2↔T3에서도 변형(gRPC over MQTT/QUIC) 사용 시 효과적.
- **HTTP/2 멀티플렉싱**: 단일 TCP/TLS 세션으로 다수 RPC 동시 처리 → 엣지 게이트웨이의 **소켓 수 절감**과 HOLB 제거.
- **4대 RPC 모드**: 사례별 매핑이 자연스러움.

| 모드 | 엣지 AIoT 시나리오 |
|------|---------------------|
| **Unary** | 원격 OTA 명령, 상태 조회, 설정 변경 |
| **Server Streaming** | T1 → T2 모델 업데이트, T2 → T3 텔레메트리, T1 → T2 토큰 스트리밍 |
| **Client Streaming** | T3 → T2 다수 센서 배치 업로드, OTA 펌웨어 청크 |
| **Bidi Streaming** | T2↔T2 엣지 합의, T3↔T2 차량/로봇 실시간 협업 |

- **HTTP/2 Flow Control(백프레셔)**: T3 디바이스의 메모리가 차면 송신 측이 자동 차단 — **수신 측 버퍼 오버플로 방어** 가 무코딩으로 가능.
- **gRPC Health Checking Protocol**: T2↔T3 간 인터미턴트 연결의 가용성을 능동 모니터링.
- **Service Config 기반 Retry Policy**: T1↔T2 무선 손실 시 지수 백오프·jitter 재시도를 표준 지원.

### 5.2 gRPC 4대 RPC 모드 ↔ 엣지 AIoT 시나리오 매핑

| 모드 | 엣지 AIoT 시나리오 |
|------|---------------------|
| **Unary** | 원격 OTA 명령, 상태 조회, 설정 변경 |
| **Server Streaming** | T1 → T2 모델 업데이트, T2 → T3 텔레메트리, T1 → T2 토큰 스트리밍 |
| **Client Streaming** | T3 → T2 다수 센서 배치 업로드, OTA 펌웨어 청크 |
| **Bidi Streaming** | T2↔T2 엣지 합의, T3↔T2 차량/로봇 실시간 협업 |

![Figure 6. gRPC 4대 RPC 모드 — Unary / Server / Client / Bidi Streaming의 엣지 AIoT 매핑|942](fig3_rpc_modes.svg)

### 5.3 엣지 AIoT 환경에서의 약점과 보완 패턴

| 약점 | 영향 사례 | 보완 패턴 |
|------|-----------|-----------|
| 임베디드/T3에서 gRPC 스택 무거움 (RAM/Flash) | 사례 ①②④ | **엣지 변환 게이트웨이**(MQTT/CoAP↔gRPC), gRPC-Lite/C nanopb |
| 무선 핸드오버 시 TCP connection migration 부재 | 사례 ③④ | **gRPC over QUIC**(HTTP/3), CONNECT-UDP 터널 |
| T2↔T3 다수 노드 fan-in으로 서버 과부하 | 사례 ①② | **Stream Aggregation** + Connection Multiplexing + eBPF/XDS LB |
| T3 디바이스 신원(IP/MAC)이 변조 가능 | 모든 사례 | **SPIFFE/SPIRE** SVID + mTLS, **TPM/SE** 디바이스 attestation |
| T2↔T3 단절 시 in-flight RPC 즉시 실패 | 사례 ①③④ | **Client-Side Retry with Backoff** + **오프라인 큐 + Resume Token** |
| T3 OTA 업데이트 시 스키마 비호환성 | 모든 사례 | **Buf Schema Registry**(BSR) + `buf breaking` 자동 검증 |

---

## 6. 2-tier 프로토콜 아키텍처: gRPC + MQTT 변환 게이트웨이

본 절은 본 연구의 핵심 제안인 **2-tier 프로토콜 아키텍처** 를 제시한다. 단일 프로토콜이 아닌 **tier별 최적 프로토콜을 혼용**하고, T2 엣지 게이트웨이가 변환·집계·인증을 책임지는 구조다.

![Figure 7. 2-tier 프로토콜 아키텍처 — T1↔T2 gRPC/QUIC, T2↔T3 MQTT/CoAP/C-V2X, T2 게이트웨이 6대 책임|933](fig2_two_tier_protocol.svg)

```
┌──────────────────────────────────────────────────────────────────┐
│ T1: 클라우드 (k8s, GPU 서버)                                      │
│   - LLM/분석 에이전트, 중앙 PM                                    │
│   - 전송: gRPC(Unary / Server-streaming)                          │
│   - 거버넌스: Istio Service Mesh, OTel Collector                  │
└─────────────────────────────┬────────────────────────────────────┘
              │  gRPC / HTTP-2 (유선·4G·안정)
              ▼
┌──────────────────────────────────────────────────────────────────┐
│ T2: 엣지 (Jetson / 산업용 PC / 5G MEC)                            │
│   - 현장 추론 에이전트, 모델 실행, 결함 회복                        │
│   - 전송 ①: gRPC↔T1, ②: MQTT/CoAP↔T3 변환 게이트웨이            │
│   - 거버넌스: Envoy Edge Proxy, mTLS, 디바이스 attestation        │
└─────────────────────────────┬────────────────────────────────────┘
              │  MQTT / CoAP / gRPC-Lite (Wi-Fi·LoRa·BLE)
              ▼
┌──────────────────────────────────────────────────────────────────┐
│ T3: 현장 (MCU, 임베디드 리눅스, 로봇, 센서)                       │
│   - 단순 디바이스 에이전트, 텔레메트리·제어, 오프라인 큐            │
│   - 전송: MQTT(Subscribe Telemetry), CoAP(Confirmable), gRPC-Lite│
│   - 보안: TPM/SE 부팅 attestation, X.509 SVID                     │
└──────────────────────────────────────────────────────────────────┘
```

### 6.1 gRPC의 활성 영역
- **T1 ↔ T2**: 안정적·고대역폭·상시 연결. 표준 gRPC + HTTP/2 + BSR + Mesh.
- **T2 ↔ T2(엣지-로컬 합의)**: 다수 엣지 노드의 동적 합의, Bidi Streaming.
- **T1 → T2 스트리밍 모델 업데이트**: Server Streaming + 백프레셔.
- **T2 → T3 일부(고성능 임베디드)**: gRPC-Lite / nanopb 변형.

### 6.2 MQTT/CoAP의 활성 영역
- **T2 ↔ T3 (저전력 MCU)**: MQTT(Pub/Sub, QoS 0/1/2, Last Will), CoAP(Confirmable, Observe).
- **T3 → T2 → T1 메시지 라우팅**: T2 게이트웨이가 MQTT topic ↔ gRPC method 매핑.

### 6.3 변환 게이트웨이의 책임
1. **프로토콜 변환**: MQTT topic → gRPC method (Unary/Stream 양방향)
2. **메시지 정규화**: JSON↔Protobuf 자동 매핑 (`buf image` + transcoding filter)
3. **버퍼링·배치**: T3 fan-in을 N개 모아 gRPC Streaming으로 묶어 T1로 전달
4. **Resume Token 발급**: T3 단절 후 재접속 시 마지막 위치부터 이어받기
5. **디바이스 인증 중계**: T3의 X.509 SVID를 검증한 뒤, T1에는 mTLS로 재인증
6. **메트릭 수집**: T2 Prometheus exporter → T1 OTel Collector

---

## 7. 개발자 관점 요구사항: 디바이스 SDK·스키마 진화·단절 내성

### 7.1 디바이스 클래스별 SDK 생성과 크로스 컴파일
**Buf Schema Registry(BSR)**에 `.proto`를 푸시하면 다언어 SDK가 자동 생성·배포된다. 개발자는 자신의 tier·디바이스 클래스에 맞게 임베드한다.
- T1/T2: Go, Python, Java, Node.js 풀 SDK
- T3 고성능 임베디드: C/C++ `nanopb` 경량 SDK, gRPC-Lite
- T3 MCU: C 템플릿 + MQTT/CoAP 클라이언트 + 변환 게이트웨이 스티치

`buf breaking`로 하위 호환성을 자동 검증해, T3 OTA 업데이트가 지연돼도 T1↔T2 통신이 깨지지 않도록 보장한다.

### 7.2 HTTP/2 Flow Control과 QUIC 핸드오버
T1↔T2 무선 구간에서 송신 측 버퍼가 차면 `WINDOW_SIZE=0` 프레임으로 자동 차단 → 앱 코드 변경 없이 OOM과 무선 정체를 방어한다. 사례 ③④의 핸드오버 환경에서는 gRPC 트래픽을 **QUIC** 위에 실어 **connection migration**·HOLB-free 멀티플렉싱을 함께 얻는다(사실상 표준).
### 7.3 Resume Token을 통한 단절-인내 스트리밍

T3↔T2↔T1의 텔레메트리 스트리밍(사례 ①②④)이 중간에 끊기면, gRPC 서버는 **Resume Token**(마지막 전송 위치)을 발급한다. 클라이언트는 재연결 시 `Resume-Token` Metadata를 첨부해 이어받는다. 이 패턴은 gRPC Interceptor에 캡슐화되어 모바일·엣지·MCU의 일시 단절을 흡수한다.

![Figure 8. Resume Token 시퀀스 — T3/T2 단절-재접속 시 스트리밍 위치 보존|942](fig5_resume_token.svg)

### 7.4 명시적 Deadline
T3 디바이스는 네트워크 품질을 신뢰할 수 없다. `ClientContext`에 `Deadline`을 인터셉터에서 강제 주입해 단절 시 무한 대기를 방지한다. 디바이스 클래스별 기본 deadline 정책을 다르게 적용한다(예: AGV V2V 50ms, IoT 텔레메트리 5s).

---
## 8. 운영 관리자 관점 요구사항: 디바이스 신원·2계층 거버넌스·관측성

### 8.1 디바이스 Attestation: SPIFFE/SPIRE + TPM/SE

단순 IP·MAC·API Key로는 물리적 디바이스의 신원을 보장할 수 없다. **SPIFFE/SPIRE**는 각 디바이스의 부팅 시 하드웨어 attestation(TPM·SE·secure boot·measured boot)을 거쳐 동적 SPIFFE ID를 발급한다.
- T1: `spiffe://cluster/ns/<ns>/sa/<sa>/agent/<id>` (k8s SA 기반)
- T2: `spiffe://edge/{org}/{site}/gateway/<uuid>` (하드웨어 시리얼 기반)
- T3: `spiffe://iot/{org}/{factory}/device/<serial>` (TPM/SE attestation 기반)

gRPC TLS 핸드셰이크 시 SAN의 SPIFFE ID를 즉시 확인해 비인가 디바이스의 호출을 전송 이전 단계에서 차단한다. 사례 ①(현장 로봇 변조 위험)·④(헬스케어 환자 안전)에서 핵심 보안 장치다.

### 8.2 2계층 통신 제어: Service Mesh + Interceptor

![Figure 9. 2계층 통신 제어 — Service Mesh(인프라) + gRPC Interceptor(앱) 관심사 분리|942](fig4_two_layer_governance.svg)

| 계층 | 통제 항목 | 엣지 AIoT 적용 |
|------|----------|----------------|
| **1계층 Service Mesh (Envoy)** | mTLS 종단, 카나리 라우팅, 글로벌 RL, **xDS Light로 T2 게이트웨이에 정책 push** | T1↔T2 정책 동적 배포 |
| **2계층 gRPC Interceptor** | 디바이스 클래스별 페이로드 검증, **디바이스 컨텍스트 전파**(battery, link-quality), **단절 시 Resume Token 발급**, Trace ID 주입 | T1/T2/T3 공통, T3는 경량 구현 |

엣지 게이트웨이는 xDS Light(Envoy Mobile)를 통해 **메쉬 정책 자체를 T2로 push**받아, OTA 없이도 정책 변경이 가능하다.

### 8.3 디바이스 클래스별 멀티테넌시 쿼터
gRPC Metadata 헤더에 `X-Tenant-ID`·`X-Device-Class`·`X-Site-ID`를 의무 탑재하고, 인터셉터·메쉬 단계에서:
- **T3 IoT**: 메시지 빈도(분당 N건), 페이로드 크기 상한, 시간당 OTA 횟수
- **T3 차량·로봇**: 안전 메시지 우선순위, 멀티캐스트 그룹 한도
- **T2 엣지**: 동시 추론 세션 수, GPU 점유 시간
- **T1 클라우드**: 테넌트당 TPM·RPM 쿼터

를 적용해 `RESOURCE_EXHAUSTED`(gRPC 코드 8)로 하위 호출을 차단한다.

### 8.4 OpenTelemetry 기반 분산 트레이싱
W3C `traceparent`/`tracestate`를 gRPC Metadata Carrier로 체인 전파한다. **T2 게이트웨이를 Trace Context fan-out 지점** 으로 삼아 T3 디바이스의 trace segment를 포함시켜, T1→T2→T3 호출 그래프가 끊김 없이 시각화된다. 사례 ①②④에서 **단절-재접속이 발생해도 trace가 연결**되도록, Resume Token에 traceparent를 임베드하는 패턴을 제안한다.

### 8.5 OTA와 스키마 진화
T3 디바이스는 한번 현장에 배포되면 수년간 업데이트되지 않을 수 있다. **BSR + `buf breaking`** CI로 OTA 시에도 하위 호환성을 자동 검증하고, T2 게이트웨이가 구버전/신버전 디바이스의 메시지를 **양방향으로 변환** (Protobuf Any 타입 + schema descriptor)하여 시스템 전체의 점진적 업그레이드를 가능케 한다.

---

## 9. 결론 및 설계 권장안

### 9.1 사례별 프로토콜 매트릭스 요약

| 당면 과제 | 사례 ① (공장) | 사례 ② (빌딩/에너지) | 사례 ③ (V2X) | 사례 ④ (헬스) |
|----------|--------------|---------------------|--------------|---------------|
| **T1↔T2 백본** | gRPC + QUIC | gRPC + 유선/4G | gRPC-over-QUIC + 5G MEC | gRPC + 유선 |
| **T2↔T3 엣지-현장** | MQTT 5.0 / gRPC-Lite | **MQTT**(LoRa/Wi-SUN 브릿지) | **C-V2X/ITS-G5** | **BLE/Wi-Fi + MQTT** |
| **저지연 합의** | gRPC Bidi(AGV) | gRPC Unary(HVAC) | **QUIC datagram 멀티캐스트** | gRPC Unary(이벤트) |
| **핸드오버** | Resume Token | Resume Token | **QUIC conn-migration** | Resume Token |
| **디바이스 신원** | TPM + SPIRE | SE + SPIRE | **V2X PKI + SPIRE** | TPM + SPIRE |
| **저전력** | N/A | MQTT QoS 0 + sleep | N/A | BLE + duty cycle |
| **긴급 이벤트** | gRPC Stream 알림 | gRPC Unary 알림 | **C-V2X CAM/DENM** | gRPC Unary 알림 |

### 9.2 베스트 프랙티스
1. **2-tier 프로토콜**: T1↔T2는 gRPC(QUIC), T2↔T3는 MQTT/CoAP/C-V2X, T2 게이트웨이에서 변환.
2. **Contract-First Schema**: BSR + `buf breaking`로 다수 디바이스 클래스 SDK 동시 배포.
3. **Hardware-backed Attestation**: TPM/SE + SPIFFE/SPIRE로 디바이스 신원 무결성.
4. **Resume Token + Deadline**: 모든 RPC에 `Deadline` 강제, 단절 시 Resume Token으로 이어받기.
5. **2계층 거버넌스 + Trace Fan-out**: Envoy Mesh + gRPC Interceptor, T2를 trace fan-out 지점으로 활용.
6. **점진적 OTA**: BSR 호환성 + T2 스키마 변환 게이트웨이로 장기 배포 디바이스 흡수.

### 9.3 결론
엣지 AIoT 환경의 Multi-Agent 서비스는 **클라우드-엣지-현장의 3-tier 물리적 분산** 위에서 동작하며, 각 tier의 자원·전력·연결성·보안 제약이 크게 다르다. gRPC는 **T1↔T2 백본과 T2↔T2 엣지 합의** 에서 가장 효과적인 선택지이며, 그 위에서 **상위 시맨틱 표준인 MCP/A2A** 가 에이전트 간 조율을 담당한다. 그러나 **T3 현장 디바이스의 극단적 자원·전력·단절 환경** 에 대해서는 gRPC-Lite, MQTT, CoAP, C-V2X, BLE 등 **tier-최적 프로토콜을 혼용**하고, T2 엣지 게이트웨이에서 변환·집계·인증 중계하는 **2-tier 프로토콜 아키텍처** 가 필수적이다. 디바이스의 물리적 제약을 정면으로 인정하고, 각 tier에 가장 적합한 변형 프로토콜을 매핑하는 것이 엣지 AIoT 분산 에이전트 서비스를 **가시성·보안·실시간성·자원 효율** 모두 갖춘 상태로 실현하는 현실적 최적해다.

---

## 참고문헌 (References)

[1] Wu et al., *AutoGen: Enabling Next-Gen LLM Applications via Multi-Agent Conversation*, 2023.
[2] Austin, J.L., *How to Do Things with Words*, 1962.
[3] Finin, T. et al., *KQML as an Agent Communication Language*, 1994.
[4] gRPC Authors, *gRPC Documentation — Protocol Buffers & HTTP/2*, 2024.
[5] Iyengar, J. & Thomson, M., *QUIC: A UDP-Based Multiplexed and Secure Transport*, RFC 9000, 2021.
[6] SPIFFE/SPIRE, *Zero-Trust Workload Identity*, https://spiffe.io.
[7] Buf Technologies, *Buf Schema Registry*, https://buf.build.
[8] OpenTelemetry, *W3C Trace Context & gRPC Instrumentation*, 2024.
[9] Anthropic, *Model Context Protocol Specification*, 2024.
[10] ETSI, *ITS-G5: Intelligent Transport Systems — LTE-V2X*, EN 302 637-2, 2019.
[11] Banks, A. & Gupta, R., *MQTT Version 5.0*, OASIS Standard, 2019.
[12] Shelby, Z. et al., *The Constrained Application Protocol (CoAP)*, RFC 7252, 2014.
[13] gRPC-Web Authors, *gRPC-Web: A Protocol for the Web*, https://github.com/grpc/grpc-web.

---

## 부록 A. 그림 목록 (List of Figures)

| Figure | 제목 | 위치 | 종류 |
|:------:|------|------|------|
| 1 | 엣지 AIoT 3-tier 물리적 분산 구조 | §1 | SVG (자체 작성) |
| 2 | 엣지 AIoT 4대 사용 사례 콜라주 | §3 | PNG (nanobanana) |
| 3 | 스마트 팩토리 협업 | §3.① | PNG (nanobanana) |
| 4 | 스마트 빌딩/에너지 | §3.② | PNG (nanobanana) |
| 5 | 헬스케어/원격 모니터링 | §3.④ | PNG (nanobanana) |
| 6 | gRPC 4대 RPC 모드 매핑 | §5.2 | SVG (자체 작성) |
| 7 | **2-tier 프로토콜 아키텍처 (핵심 제안)** | §6 | SVG (자체 작성) |
| 8 | Resume Token 시퀀스 | §7.3 | SVG (자체 작성) |
| 9 | 2계층 통신 제어 | §8.2 | SVG (자체 작성) |
| 10 | gRPC vs REST 정량 비교 | §4 | SVG (자체 작성) |

## 부록 B. 표 목록 (List of Tables)

| Table | 제목 | 위치 |
|:-----:|------|------|
| 1 | 3-tier 디바이스 클래스 정의 | §1 |
| 2 | 사례 ① 스마트 팩토리 통신 경로 | §3.① |
| 3 | 사례 ② 스마트 빌딩 통신 특성 | §3.② |
| 4 | 사례 ④ 헬스케어 통신 특성 | §3.④ |
| 5 | 기존 통신 기술 한계 | §4 |
| 6 | gRPC 4대 RPC 모드 ↔ 엣지 AIoT 시나리오 | §5.2 |
| 7 | gRPC 약점과 보완 패턴 | §5.3 |
| 8 | 2계층 거버넌스 책임 | §8.2 |
| 9 | 디바이스 클래스별 멀티테넌시 쿼터 | §8.3 |
| 10 | 사례별 프로토콜 매트릭스 (최종) | §9.1 |
| 11 | 베스트 프랙티스 | §9.2 |