23 KiB
연구 계획서 (Research Planning)
제목 (잠정): 엣지 AIoT 환경에서 A2A/gRPC 이중 계층 기반 멀티 에이전트 통신 인터페이스 설계 및 검증
버전: 0.1 (2026-06-07) 상태: 초안
1. 연구 제목 및 키워드
한국어 제목
엣지 AIoT 환경에서 A2A/gRPC 이중 계층 기반 멀티 에이전트 통신 인터페이스 설계 및 검증
영문 제목 (잠정)
Design and Validation of a Dual-Layer Multi-Agent Communication Interface Based on A2A/gRPC for Edge AIoT Environments
핵심 키워드
| 범주 | 키워드 |
|---|---|
| 시스템 구조 | Multi-Agent System (MAS), Edge AIoT, 3-tier 분산 아키텍처, Edge Gateway |
| 통신 프로토콜 | gRPC, QUIC, MQTT v5, CoAP, A2A (Agent-to-Agent), MCP (Model Context Protocol) |
| 보안/신원 | SPIFFE/SPIRE, TPM, Secure Element, Hardware Attestation, mTLS |
| 관측성 | OpenTelemetry, W3C traceparent, Distributed Tracing |
| 응용 도메인 | Smart Factory, Smart Building, V2X, Connected Healthcare |
| 경량화/직렬화 | Protocol Buffers, CBOR, MessagePack, gRPC-Lite |
2. 연구 동기 및 비전
2.1 현재 세계의 문제
현재 엣지 AIoT 분야에서 멀티 에이전트 시스템(MAS)을 실제 배포할 때 세 가지 근본적인 긴장이 공존한다.
첫째, 물리적 이질성과 단일 프로토콜의 부조화. AutoGen, CrewAI, LangGraph 같은 LLM 에이전트 프레임워크는 실제 배포 시 Cloud(T1) ↔ Edge Gateway(T2) ↔ Field IoT/Robot/Sensor(T3)의 3-tier 물리 분산 위에 얹힌다. T1은 TB급 RAM과 GPU를 갖춘 데이터센터 서버이고, T3는 수십 KB RAM을 가진 MCU(Cortex-M)이다. 이 이질적인 두 끝을 REST 하나나 MQTT 하나로 연결하려는 시도는 필연적으로 한쪽 tier에서 과부하 혹은 동작 불능을 일으킨다.
둘째, 에이전트 시맨틱 계층과 전송 계층의 혼재. Google A2A 프로토콜[33]과 Anthropic MCP[9]는 에이전트 간 조율을 위한 상위 시맨틱 계층(Agent Communication Language의 현대적 구현)이다. 그러나 이들은 하위 전송 계층의 선택을 명시하지 않는다. 결과적으로 "A2A over REST over TCP"처럼 전송 계층이 에이전트 시맨틱 계층의 병목이 되는 구조가 현장에서 반복된다.
셋째, 보안 경계의 물리적 취약성. T3 현장 디바이스는 공장 바닥, 도로변 RSU, 병원 병상 옆에 물리적으로 노출되어 있다. 단순한 IP/MAC 주소나 공유 API 키로는 디바이스 신원을 보장할 수 없다. 그러나 현존하는 MAS 프레임워크 대부분은 디바이스 수준의 하드웨어 attestation을 통신 설계에 통합하지 않는다.
2.2 해결하고자 하는 세계
본 연구가 그리는 목표 상태는 다음과 같다:
- A2A/MCP 에이전트 조율 계층과 gRPC/QUIC 전송 계층이 명확히 분리되고, 그 경계에서 서로를 강화한다.
- T2 엣지 게이트웨이가 프로토콜 변환, Resume Token 기반 단절 내성, 하드웨어 attestation 중계, 분산 트레이싱 fan-out을 일원화하여 처리한다.
- 개발자는
.proto파일 하나를 작성하면 T1(Python/Go), T2(C++/Rust), T3(C nanopb)용 타입 안전 SDK를 자동으로 얻는다. - 현장 디바이스 교체 없이 TPM/SE 하드웨어 attestation이 SPIFFE/SPIRE SVID로 체인 연결되어, T1의 Istio 서비스 메시까지 신원이 전파된다.
2.3 5년 후 목표 (2031)
2031년 기준, 본 연구에서 제안하는 2-tier 프로토콜 아키텍처 + A2A/gRPC 이중 계층이 다음 형태로 실현되는 것을 목표로 한다:
- 스마트 팩토리, 스마트 빌딩, V2X, 헬스케어 4개 영역에서 실제 배포 사례 확보
- 관련 표준(IETF, ETSI, OMA) 기고 1건 이상
- 오픈소스 레퍼런스 구현체(T2 게이트웨이 + gRPC 인터셉터 라이브러리) 커뮤니티 운영
- 엣지 AIoT MAS 통신 설계에 관한 피인용 지수 상위 연구로 자리매김
3. 연구 목표 (Research Objectives)
RO-1. 엣지 AIoT 3-tier 통신 요구사항의 체계적 도출과 정량화
기존 문헌(FINAL_REPORT §3~4)에서 도출된 4대 사용 사례(스마트 팩토리, 스마트 빌딩, V2X, 헬스케어)의 통신 특성을 계층별·경로별로 정량 분류한다. 특히 지연, 처리량, 단절 빈도, 페이로드 크기, 에너지 소비의 5개 차원에서 tier 간 격차를 측정 가능한 수치로 표현한다.
성공 기준: 각 tier 쌍(T1↔T2, T2↔T3)에 대해 5개 차원의 요구 범위가 명시된 참조 테이블 완성
RO-2. A2A/MCP 시맨틱 계층과 gRPC 전송 계층의 이중 계층 인터페이스 설계
A2A 프로토콜[33,45]을 상위 에이전트 조율 계층으로, gRPC(HTTP/2 또는 QUIC)를 하위 전송 계층으로 사용하는 명시적 계층 분리 아키텍처를 설계한다. 두 계층이 상호 작용하는 접합점(Binding Point)에서 메시지 매핑, 컨텍스트 전파, 에러 코드 변환 방식을 명세한다.
성공 기준: A2A Task 생명주기 ↔ gRPC 스트리밍 모드 매핑 명세서(인터페이스 계약 문서) 완성
RO-3. T2 엣지 게이트웨이의 다기능 통합 설계 및 구현
프로토콜 변환(MQTT/CoAP↔gRPC), Resume Token 기반 단절 내성, SPIFFE/SPIRE 기반 디바이스 attestation 중계, OpenTelemetry trace fan-out을 단일 T2 게이트웨이 컴포넌트에서 처리하는 설계와 프로토타입 구현을 수행한다.
성공 기준: T3 디바이스 100개 동시 연결 환경에서 T2 게이트웨이의 프로토콜 변환 지연 < 5ms (p99)
RO-4. 이중 계층 아키텍처의 실험적 검증
제안 아키텍처를 실험 환경(테스트베드 또는 에뮬레이션)에서 구현하고, 기존 단일 프로토콜(REST+JSON, MQTT-only) 대비 지연, 처리량, 핸드오버 복구 시간, 에너지 소비 면에서 우월성을 실험으로 입증한다. 4대 사용 사례 시나리오 각각에 대한 KPI 달성 여부를 검증한다.
성공 기준: 4개 시나리오 모두에서 제안 아키텍처가 베이스라인 대비 지연 30% 이상 개선 또는 단절 복구 시간 50% 이상 단축
RO-5. 보안 및 신원 관리의 엔드투엔드 검증
T3 디바이스의 TPM/SE 기반 하드웨어 attestation이 SPIFFE/SPIRE SVID 체인으로 T1 클라우드 메시까지 전파되는 과정의 무결성을 검증한다. 비인가 디바이스, 인증서 만료, attestation 실패 시나리오에서 시스템이 올바르게 거부하는지 확인한다.
성공 기준: 비인가 디바이스의 T2 게이트웨이 접근 시 전송 계층 이전 단계에서 100% 차단 확인
4. 연구 범위 (Scope)
4.1 In-scope (연구 범위 내)
| 범주 | 포함 항목 |
|---|---|
| 아키텍처 설계 | A2A/MCP 계층과 gRPC 전송 계층의 인터페이스 설계; T2 게이트웨이 컴포넌트 설계; 3-tier 프로토콜 매트릭스 |
| 프로토콜 | gRPC(HTTP/2, HTTP/3-over-QUIC), MQTT v5, CoAP RFC 7252, A2A, MCP; CBOR/MessagePack 직렬화 비교 |
| 보안/신원 | SPIFFE/SPIRE SVID 발급 흐름; TPM 2.0 / Secure Element attestation 연동; mTLS 체인 |
| 관측성 | OpenTelemetry SDK 통합; W3C traceparent 멀티 홉 전파; T2를 trace fan-out 지점으로 활용 |
| 단절 내성 | Resume Token 메커니즘; QUIC connection migration; gRPC Retry Policy |
| 사용 사례 검증 | 스마트 팩토리, 스마트 빌딩/에너지, V2X, 헬스케어 4개 시나리오 |
| 구현/실험 | T2 게이트웨이 프로토타입(Go 또는 Rust); 에뮬레이션 테스트베드; 성능 벤치마크 |
4.2 Out-of-scope (연구 범위 외)
| 범주 | 제외 이유 |
|---|---|
| LLM 모델 자체의 추론 성능 | 전송/통신 계층 연구; 모델 개선은 별도 연구 영역 |
| T3 디바이스 하드웨어 설계 | 기존 상용 MCU/센서 활용을 전제 |
| 사용 사례별 도메인 AI 알고리즘 | 예측 정비 알고리즘, V2X 경로 계획 등은 통신 인터페이스 연구의 종속 변수가 아님 |
| 클라우드 내부 서비스 메시 최적화 | T1 내부 Istio 튜닝은 참조 아키텍처 수준으로만 다룸 |
| 상용 V2X PKI 인프라 구축 | V2X 사례에서 PKI는 기존 ETSI ITS PKI를 전제 |
| 실규모 현장 배포(production deployment) | Phase 4 이후 후속 연구로 분리 |
| WebSocket / HTTP/1.1 기반 통신 | 기술적 열위가 기존 문헌에서 확립됨; 비교군으로만 활용 |
5. 연구 방법론
본 연구는 설계 과학(Design Science Research) 방법론을 기반으로 세 단계(설계 → 구현 → 실험 검증)를 순환한다.
5.1 1단계: 요구사항 분석 및 아키텍처 설계
[문헌 조사]
A2A 프로토콜 명세, gRPC 문서, QUIC RFC 9000, SPIFFE/SPIRE 백서,
MQTT v5, CoAP RFC 7252, OpenTelemetry 명세,
선행 사례: Tedeschini[29], Bosse[31], Minelli[32], Ghosh[34]
↓
[4대 사용 사례 통신 요구사항 정량화]
KPI 테이블 작성 (지연, 처리량, 단절 빈도, 페이로드 크기, 에너지)
tier 쌍별 요구 격차 분석
↓
[이중 계층 인터페이스 아키텍처 설계]
계층 1: A2A/MCP 시맨틱 계층 (Task/Message/Artifact 타입 매핑)
계층 2: gRPC 전송 계층 (Unary/Streaming 모드 선택 기준)
T2 게이트웨이 6대 책임 명세 (변환·정규화·버퍼링·Resume·Attestation·Metrics)
↓
[보안·신원 아키텍처 설계]
SPIFFE ID 네임스페이스 설계 (T1/T2/T3 tier별)
TPM/SE attestation → SPIRE Agent 연동 흐름
mTLS 체인 전파 명세
5.2 2단계: 프로토타입 구현
구현 컴포넌트
| 컴포넌트 | 언어/런타임 | tier |
|---|---|---|
| T1 클라우드 에이전트 (A2A 서버) | Python (FastAPI + grpcio) | T1 |
| T2 게이트웨이 (변환·Resume·Attestation) | Go (grpc-go + paho-mqtt) | T2 |
| T3 경량 에이전트 (MQTT 클라이언트) | C (nanopb + Paho-C) | T3 |
| SPIRE Server/Agent | Go (공식 SPIRE 릴리즈) | T1/T2/T3 |
| OpenTelemetry Collector | YAML 설정 | T1 |
| 테스트베드 에뮬레이터 | Python (Docker Compose + tc netem) | 인프라 |
핵심 구현 모듈
- A2A-gRPC Binding Layer: A2A Task 생성/업데이트 이벤트를 gRPC Bidi Streaming으로 전달하는 인터셉터
- MQTT-gRPC Protocol Bridge: T3 MQTT topic → T2 gRPC method 동적 라우팅 테이블
- Resume Token Manager: 스트림 오프셋 추적, 재연결 시 이어받기 로직
- Attestation Proxy: T3 TPM Quote → SPIRE Agent verify → SVID 발급 체인
- Trace Fan-out Interceptor: traceparent를 T3 MQTT 페이로드에 임베드/추출
5.3 3단계: 실험 검증
실험 환경 구성
[에뮬레이션 테스트베드]
T1: 1 × x86 서버 (16 vCPU, 32GB RAM, Docker k3s)
T2: 2 × Jetson Orin (또는 Docker 에뮬레이션)
T3: 100 × MQTT 클라이언트 에뮬레이터 (python-paho + tc netem 지연/손실 주입)
[네트워크 조건 에뮬레이션]
T1↔T2: 광역 무선 (50ms RTT, 1% 패킷 손실)
T2↔T3: 불안정 IoT (200ms RTT, 5% 손실, 핸드오버 시뮬레이션)
측정 지표
| 지표 | 단위 | 목표값 |
|---|---|---|
| T1↔T2 RPC 지연 (Unary, p99) | ms | < 100ms (50ms RTT 환경) |
| T2 게이트웨이 프로토콜 변환 지연 (p99) | ms | < 5ms |
| 핸드오버 후 스트림 복구 시간 | ms | < 500ms |
| T3 100 노드 동시 fan-in 처리량 | msg/s | > 5,000 msg/s |
| Resume Token 재접속 손실 메시지 수 | 개 | 0 |
| 비인가 디바이스 접근 차단율 | % | 100% |
비교 대상 (베이스라인)
- REST+JSON over HTTP/1.1 (단일 프로토콜)
- MQTT-only (T1-T3 직접 연결, 중간 변환 없음)
- gRPC-only (T3 경량화 없이 전 tier 동일 gRPC 스택)
6. 기대 기여 (Contributions)
6.1 학문적 기여
| 기여 | 내용 |
|---|---|
| C1. 이중 계층 인터페이스 모델 | A2A 시맨틱 계층과 gRPC 전송 계층의 명시적 분리 및 접합점(Binding Point) 정형화. 기존 연구[34]의 MCP+A2A 통합 논의를 3-tier 물리 분산 환경으로 확장 |
| C2. 엣지 AIoT 통신 요구사항 분류 체계 | 지연·처리량·단절 빈도·페이로드·에너지 5차원 분류 프레임워크. 4대 사용 사례를 포괄하는 최초의 체계적 분류 |
| C3. T2 게이트웨이 다기능 통합 설계 패턴 | Resume Token + Attestation Proxy + Trace Fan-out을 단일 컴포넌트에서 처리하는 아키텍처 패턴. 설계 과학 관점에서 재사용 가능한 패턴으로 공식화 |
| C4. QUIC 기반 에이전트 통신 핸드오버 검증 | gRPC over QUIC의 connection migration이 멀티 에이전트 협업(V2X 시나리오)에서 제공하는 핸드오버 투명성을 Simpson[84] 연구 기반으로 실험 검증 |
| C5. CBOR/MessagePack vs Protobuf 비교 | T3 극경량 환경에서 CBOR RFC 8949[92], MessagePack[93] 대비 Protobuf의 직렬화 성능 비교 실험 데이터 제공 |
6.2 산업적 기여
| 기여 | 적용 영역 |
|---|---|
| 오픈소스 T2 게이트웨이 레퍼런스 구현 | 스마트 팩토리, 스마트 빌딩 시스템 통합 업체 |
| 프로토콜 선택 의사결정 가이드 | IoT 플랫폼 아키텍트 (tier별 프로토콜 선택 기준 체크리스트) |
| SPIFFE/SPIRE 기반 IoT 신원 관리 패턴 | 헬스케어, 자동화 제조 영역의 규제 준수(IEC 62443, HIPAA) |
| 엣지 AIoT MAS 성능 벤치마크 기준점 | 신규 에지 컴퓨팅 플랫폼 평가 기준 제공 |
7. 연구 로드맵
Phase 1: 기반 연구 및 설계 (2026년 Q3, 3개월)
목표: 요구사항 정량화 완료 + 이중 계층 아키텍처 설계 문서 완성
| 주차 | 활동 | 산출물 |
|---|---|---|
| 1–2주 | 핵심 문헌 심층 리뷰 (A2A[33,45], Ghosh[34], Simpson[84], Tedeschini[29]) | 문헌 요약 노트 |
| 3–4주 | 4대 사용 사례 통신 KPI 정량 테이블 작성 | 요구사항 명세서 v1 |
| 5–6주 | A2A-gRPC Binding Point 명세 + T2 게이트웨이 컴포넌트 설계 | 아키텍처 설계서 v1 |
| 7–8주 | SPIFFE/SPIRE T3 attestation 흐름 설계 + Proto 스키마 초안 | 보안 설계서 v1 |
| 9–12주 | 설계 리뷰 + 논문 초안 §1~3 (서론, 배경, 아키텍처) 작성 | 논문 초안 v0.3 |
마일스톤 M1: 아키텍처 설계서 완성 및 내부 리뷰
Phase 2: 프로토타입 구현 (2026년 Q4, 3개월)
목표: T1-T2-T3 전체 스택 프로토타입 동작 확인
| 주차 | 활동 | 산출물 |
|---|---|---|
| 1–2주 | .proto 스키마 확정 + Buf Schema Registry 설정 |
proto 파일 + BSR 레포 |
| 3–4주 | T2 MQTT-gRPC 브릿지 구현 (Go) | gateway v0.1 |
| 5–6주 | Resume Token Manager 구현 + 단절 재접속 테스트 | gateway v0.2 |
| 7–8주 | SPIRE Agent T3 attestation 연동 구현 | attestation-proxy v0.1 |
| 9–10주 | OpenTelemetry trace fan-out 인터셉터 구현 | otel-interceptor v0.1 |
| 11–12주 | T1 A2A 서버 + T3 MQTT 에뮬레이터 연동 end-to-end 테스트 | 통합 데모 |
마일스톤 M2: T1-T2-T3 e2e 흐름 동작 확인 데모
Phase 3: 실험 검증 (2027년 Q1, 3개월)
목표: 제안 아키텍처의 정량 우월성 실험 입증
| 주차 | 활동 | 산출물 |
|---|---|---|
| 1–2주 | 에뮬레이션 테스트베드 구성 (tc netem, 100 T3 노드) | 테스트베드 환경 문서 |
| 3–5주 | 베이스라인 3종 vs 제안 아키텍처 지연/처리량 벤치마크 | 벤치마크 결과 데이터 |
| 6–7주 | 핸드오버 시나리오 (V2X) 실험: QUIC connection migration | 핸드오버 실험 결과 |
| 8–9주 | 보안 실험: 비인가 디바이스 차단, 인증서 만료 복구 | 보안 실험 결과 |
| 10주 | CBOR/MessagePack vs Protobuf T3 직렬화 비교 | 직렬화 비교 데이터 |
| 11–12주 | 실험 데이터 분석 + 논문 §4~5 (실험, 결과) 작성 | 논문 초안 v0.7 |
마일스톤 M3: 실험 결과 데이터 완성 + 논문 초안 v0.7
Phase 4: 논문 완성 및 제출 (2027년 Q2, 3개월)
목표: 학술지/학회 제출 완성
| 주차 | 활동 | 산출물 |
|---|---|---|
| 1–3주 | 논문 §6 (토론, 한계, 향후 연구) 작성 + 전체 퇴고 | 논문 초안 v0.9 |
| 4–5주 | 동료 리뷰 (내부) + 피드백 반영 | 논문 초안 v1.0 |
| 6주 | 투고 대상 학술지/학회 선정 및 포맷 맞춤 | 제출 준비 완료 |
| 7–8주 | 제출 + 오픈소스 레포 공개 (게이트웨이 구현체) | 논문 제출, GitHub 공개 |
| 9–12주 | 리뷰 대응 (리비전) + 최종 게재 확정 | 게재 확정 |
마일스톤 M4: 논문 제출 완료 + 오픈소스 공개
전체 일정 요약
2026 Q3 2026 Q4 2027 Q1 2027 Q2
│─────────────│─────────────│─────────────│─────────────│
│ Phase 1 │ Phase 2 │ Phase 3 │ Phase 4 │
│ 설계 │ 구현 │ 실험 │ 논문 완성 │
│ M1 │ M2 │ M3 │ M4 │
8. 핵심 참고문헌 매핑
| 참고문헌 | 저자/출처 | 연구 기여 영역 | 연구 내 활용 위치 |
|---|---|---|---|
| [4] gRPC Docs | gRPC Authors, 2024 | gRPC 프로토콜 상세 (HTTP/2, 스트리밍, 백프레셔, Health Check) | §5 아키텍처 설계, §5.2 구현 |
| [5] QUIC RFC 9000 | Iyengar & Thomson, 2021 | QUIC connection migration, 0-RTT, HOLB-free 멀티플렉싱 | §5.1 T1↔T2 전송 설계, V2X 실험 |
| [6] SPIFFE/SPIRE | SPIFFE 재단 | Zero-Trust 워크로드 신원, SVID 발급, attestation 플러그인 아키텍처 | §5.3 보안 설계, RO-5 |
| [8] OpenTelemetry | CNCF, 2024 | W3C traceparent 전파, gRPC 계측, OTel Collector 파이프라인 | §5.3 관측성 설계 |
| [11] MQTT v5 | Banks & Gupta, 2019 | MQTT Shared Subscription, Message Expiry, User Property (T3↔T2 경량 통신) | §6.2 T2↔T3 설계, T3 구현 |
| [12] CoAP RFC 7252 | Shelby et al., 2014 | Confirmable Message, Observe 옵션 (극저전력 T3 디바이스) | §6.2 저전력 T3 설계 |
| [29] Tedeschini | Tedeschini et al. | MARL 협력 위치추정, 분산 에이전트 협업 실험 방법론 | Phase 3 실험 설계 참조 |
| [31] Bosse | Bosse | 자원 제약 환경 모바일 에이전트, 경량 에이전트 런타임 패턴 | T3 에이전트 설계 (RO-3) |
| [32] Minelli | Minelli | CoMix 에이전트 조율, 분산 에이전트 합의 프로토콜 | A2A 계층 설계 참조 |
| [33] Google A2A | Google, 2024 | A2A 프로토콜 명세 (Task, Message, Artifact, Streaming 이벤트) | 핵심: §4 A2A 계층 설계, RO-2 |
| [34] Ghosh | Ghosh, 2024 | MCP+A2A 통합 엔지니어링 MAS 구현 사례 | A2A-gRPC Binding 설계 참조 |
| [45] A2A vs MCP | 미상/커뮤니티 | A2A/MCP 역할 차이 분석 (에이전트 조율 vs 도구 호출) | 계층 분리 근거 확립 |
| [84] Simpson et al. | Simpson et al. | QUIC vs TCP 핸드오버 성능 실측 비교 | Phase 3 V2X 핸드오버 실험 근거 |
| [92] CBOR RFC 8949 | Bormann & Hoffman | CBOR 이진 직렬화 명세 | Phase 3 직렬화 비교 실험 |
| [93] MessagePack | Furuhashi | MessagePack 직렬화 (CBOR 대안) | Phase 3 직렬화 비교 실험 |
| [99] Holochain DHT | Holochain Comm. | DHT 기반 IoT 보안, P2P 신원 관리 (SPIFFE 보완 관점) | RO-5 보안 설계 심화 |
9. 연구 가설 (Hypotheses)
가설은 모두 실험적으로 반증 가능한(falsifiable) 형태로 명세한다.
H1. 이중 계층 아키텍처의 지연 우월성
가설: A2A 시맨틱 계층 + gRPC 전송 계층의 이중 계층 구조는, 동일한 3-tier 엣지 AIoT 환경에서 REST+JSON 단일 프로토콜 대비 T1↔T2 RPC 왕복 지연을 p99 기준 30% 이상 단축한다.
검증 방법:
- 독립 변수: 통신 아키텍처 (이중 계층 vs REST+JSON)
- 종속 변수: T1↔T2 Unary RPC 왕복 지연 (p50, p95, p99)
- 조건: 50ms RTT, 1% 패킷 손실 에뮬레이션, 동시 에이전트 50개
- 귀무 가설 H0: 두 아키텍처 간 지연 차이 없음 (유의수준 α=0.05)
예상 근거: Protobuf의 JSON 대비 50~80% 페이로드 절감[4] + HTTP/2 멀티플렉싱의 HOLB 제거 효과[4]
H2. Resume Token 기반 단절 복구의 무손실성
가설: T2 게이트웨이의 Resume Token 메커니즘을 적용하면, T2↔T3 연결이 임의 시점에 단절 후 재접속하는 환경에서 스트리밍 중 전달되지 않은 메시지의 재전달률은 99.9% 이상이며, 이는 Resume Token 미적용 시의 단순 재연결 대비 유의미하게 높다.
검증 방법:
- 독립 변수: Resume Token 적용 여부
- 종속 변수: 단절 이후 복구 메시지 수 / 전체 단절 구간 메시지 수 (재전달률)
- 조건: T3 노드 단절 주기 무작위(평균 30초), 스트리밍 지속 시간 10분, 반복 50회
- 귀무 가설 H0: 두 조건 간 재전달률 차이 없음 (유의수준 α=0.05)
예상 근거: Resume Token이 마지막 전송 오프셋을 서버에 보존하여 재연결 시 이어받기 가능[FINAL_REPORT §7.3]
H3. QUIC 기반 핸드오버 투명성
가설: gRPC over QUIC(HTTP/3)를 사용하는 T1↔T2 통신은, TCP 기반 gRPC 대비 모바일 핸드오버(IP 주소 변경) 시나리오에서 에이전트 태스크 중단 시간이 50% 이상 단축된다.
검증 방법:
- 독립 변수: 전송 계층 (QUIC vs TCP)
- 종속 변수: 핸드오버 발생 시점부터 에이전트 태스크 재개까지 소요 시간 (ms)
- 조건: IP 주소 변경을 tc netem으로 에뮬레이션, Bidi Streaming 활성 상태, 반복 100회
- 귀무 가설 H0: QUIC와 TCP 간 태스크 중단 시간 차이 없음 (유의수준 α=0.05)
예상 근거: QUIC connection migration은 IP 변경에도 Connection ID 기반으로 세션을 유지하여 TCP의 재연결 과정을 생략[Simpson et al., 84; QUIC RFC 9000, 5]
부록: 관련 기존 연구 위치 지정
본 연구의 차별점
| 선행 연구 유형 | 주요 한계 | 본 연구의 차별점 |
|---|---|---|
| LLM 에이전트 프레임워크 (AutoGen, CrewAI) | 통신 계층을 HTTP/REST에 위임, 3-tier 분산 미고려 | 명시적 계층 분리 + tier 최적 프로토콜 매핑 |
| IoT 통신 프로토콜 비교 연구 | 에이전트 시맨틱 계층 부재, 단순 성능 비교 | A2A/MCP 계층 통합 설계 |
| A2A/MCP 명세 문서 [33,45] | 하위 전송 계층 선택 미명시 | gRPC 전송 계층과의 구체적 Binding 설계 |
| 엣지 컴퓨팅 보안 연구 | 에이전트 조율과 보안 분리 설계 | SPIFFE/SPIRE를 에이전트 통신 계층에 직접 통합 |
| gRPC 엣지 배포 연구 | 에이전트 시맨틱 계층 없이 gRPC만 다룸 | A2A + gRPC 이중 계층의 공동 설계 |
작성일: 2026-06-07 | 다음 리뷰 예정: Phase 1 M1 완료 시