docs: align core proposal to HTTP/3-based gRPC over QUIC and add HTTP/2 fallback

gRPC_Based_Interface/BACKGROUND.md

@@ -74,8 +74,8 @@ MAS 분야는 1960년대 Austin과 Searle의 **화행 이론(Speech Act Theory)*
 | **MQTT 5.0**       | 과도한 복잡성   | 적합        | 낮음(헤더 2B~수십 B)            | Pub/Sub QoS                   | QoS 1/2(세션 유지)       | 없음            | 가능        |
 | **CoAP**           | 부적합       | 적합(저전력)   | 매우 낮음(4B 헤더)              | Observe(단방향)                  | Confirmable(제한적)     | 없음            | 가능(수 KB)  |
 | **WebSocket**      | 보통        | 불가        | 중간(HTTP 업그레이드)            | 양방향                           | 없음                   | 없음            | 불가        |
-| **gRPC/HTTP2**     | 매우 적합     | 부분적       | 낮음(Protobuf 이진)           | 4방향(Unary/Server/Client/Bidi) | Retry Policy(제한적)    | 강함(Proto IDL) | 무거움(수 MB) |
+| **gRPC/HTTP/2**    | 매우 적합     | 부분적       | 낮음(Protobuf 이진)           | 4방향(Unary/Server/Client/Bidi) | Retry Policy(제한적)    | 강함(Proto IDL) | 무거움(수 MB) |
-| **QUIC/HTTP3**     | 매우 적합     | 부분적       | 낮음                        | 양방향                           | connection migration | 없음(독립)        | 무거움       |
+| **QUIC/HTTP/3**    | 매우 적합     | 부분적       | 낮음                        | 양방향                           | connection migration | 없음(독립)        | 무거움       |
 
 ### 3.2 REST/HTTP·JSON의 구조적 한계
 
@@ -85,7 +85,7 @@ REST는 웹 서비스 통합에서 지배적 패러다임이지만 엣지 AIoT
 
 **단방향 폴링 문제**: REST는 근본적으로 요청-응답 모델이다. T1이 다수 T2/T3 에이전트의 상태를 실시간으로 수신하려면 폴링(polling) 또는 웹훅(webhook) 구성이 필요하며, 폴링은 불필요한 네트워크 트래픽을 유발하고 웹훅은 T3 MCU에서 HTTP 서버를 동작시켜야 하는 불가능한 요구 사항을 가진다.
 
-**HTTP/1.1 HoL Blocking**: Head-of-Line Blocking으로 인해 T1↔T2 간 다수 에이전트의 동시 RPC가 직렬화되어 처리 지연이 누적된다. HTTP/2 기반인 gRPC는 이 문제를 단일 연결 내 스트림 다중화로 해결한다.
+**HTTP/1.1 및 TCP HoL Blocking**: HTTP/1.1은 전송 시 Head-of-Line Blocking으로 인해 RPC가 직렬화된다. HTTP/2 기반인 gRPC는 단일 연결 내 스트림 다중화로 이를 개선하지만, 여전히 TCP 계층의 HOLB(단일 패킷 유실 시 전체 스트림 정체)는 해소하지 못한다. 본 연구에서 제안하는 gRPC over QUIC(HTTP/3)은 각 스트림의 전송을 전송 레벨에서 독립적으로 제어함으로써 이 문제를 근본적으로 극복한다.
 
 **스키마 부재**: JSON은 타입 안전성을 보장하지 않는다. T3 디바이스가 장기간 배포되면 T1과 T3의 메시지 스키마가 점진적으로 불일치해도 파싱 오류로 뒤늦게 발견된다.
 
@@ -240,7 +240,7 @@ Gaba et al. [2023]은 Holochain 분산 해시 테이블(DHT)을 IoT 디바이스
 
 Iyengar & Thomson [2021]의 QUIC RFC 9000은 UDP 위에서 멀티플렉싱, 암호화, connection migration을 제공하는 전송 프로토콜을 정의한다. Connection migration은 IP 주소나 포트가 변경되어도 연결 ID(Connection ID)를 유지하여 핸드오버 시 전송 계층 연결이 끊어지지 않도록 한다.
 
-QUIC은 V2X와 모바일 헬스케어 시나리오에서 전송 계층 핸드오버 문제를 근본적으로 해결한다. 그러나 QUIC/HTTP3 위에서 gRPC를 실행하는 표준(gRPC over HTTP3)은 아직 실험적 단계이며, 더 중요하게는 QUIC의 connection migration이 전송 연결을 유지해도 **그 위의 gRPC 스트리밍 세션의 에이전트 태스크 상태**는 애플리케이션 계층에서 별도로 관리해야 한다. Resume Token은 QUIC과 독립적으로 필요한 에이전트 수준 메커니즘이다.
+QUIC은 V2X와 모바일 헬스케어 시나리오에서 전송 계층 핸드오버 문제를 근본적으로 해결한다. 비록 공식 gRPC 스택의 HTTP/3 표준 지원은 부분적이거나 실험적 단계에 있으나, 본 연구는 `quic-go`를 활용한 커스텀 전송 계층 어댑터(gRPC over QUIC)를 직접 구현·실증하여 이 한계를 돌파한다. 더 중요하게는 QUIC의 connection migration이 전송 연결을 유지해도 **그 위의 gRPC 스트리밍 세션의 에이전트 태스크 상태**는 애플리케이션 계층에서 별도로 관리해야 하며, Resume Token은 QUIC과 독립적이면서도 계층적으로 정합되는 핵심 단절 내성 메커니즘이다.
 
 ### 7.6 SPIFFE/SPIRE: 제로 트러스트 워크로드 신원
 

gRPC_Based_Interface/DESIGN.md

@@ -27,7 +27,7 @@
 본 시스템의 모든 아키텍처 결정은 다음 7가지 guiding principle에 근거한다. 각 원칙은 엣지 AIoT의 물리적 이질성과 다중 에이전트 협업의 복잡성에서 도출되었다.
 
 ### P1. Tier-Appropriate Protocol (계층 적합 프로토콜)
-각 tier는 자신의 자원·연결성·전력 제약에 최적화된 프로토콜을 사용한다. T1 클라우드에는 gRPC/HTTP-2, T2 엣지에는 gRPC over QUIC, T3 현장 디바이스에는 MQTT/CoAP/BLE를 적용한다. **단일 프로토콜로 3-tier 전체를 포괄하려는 설계는 거부한다.** 이는 임베디드 디바이스에 gRPC 풀스택을 강제할 때 발생하는 RAM·Flash 초과 문제와, 클라우드 서버에 MQTT를 사용할 때 발생하는 스키마 안전성 부재 문제를 동시에 해결하는 근거다.
+각 tier는 자신의 자원·연결성·전력 제약에 최적화된 프로토콜을 사용한다. T1 클라우드와 T2 엣지 통신에는 gRPC over QUIC(HTTP/3)를 기본(Primary) 프로토콜로 채택하며, 방화벽 UDP 차단이나 레거시 인프라 제약 시 차선책으로 gRPC over HTTP/2를 활용한 전송 폴백(Fallback)을 적용한다. T3 현장 디바이스에는 MQTT/CoAP/BLE를 적용한다. **단일 프로토콜로 3-tier 전체를 포괄하려는 설계는 거부한다.** 이는 임베디드 디바이스에 gRPC 풀스택을 강제할 때 발생하는 RAM·Flash 초과 문제와, 클라우드 서버에 MQTT를 사용할 때 발생하는 스키마 안전성 부재 문제를 동시에 해결하는 근거다.
 
 ### P2. Semantic-Transport Separation (시맨틱-전송 분리)
 에이전트 간 "무엇을 할 것인가(Task 위임·역량 광고)"와 "어떻게 전달할 것인가(Byte 전송)"를 명확히 분리한다. A2A/MCP는 시맨틱 계층에서 동작하고, gRPC/MQTT/CoAP는 전송 계층에서 동작한다. 이 분리는 전송 프로토콜을 교체해도 에이전트 협업 로직이 영향받지 않도록 보장한다.
@@ -70,7 +70,7 @@ T3 디바이스와 T2 게이트웨이 사이의 단절은 예외가 아닌 정
 ║  └──────────────────────────────────────────────────────────────────────┘   ║
 ╚══════════════════════════════════════════╦═══════════════════════════════════╝
                                            ║
-                     gRPC over QUIC (HTTP/3) / gRPC over HTTP/2
+                     gRPC over QUIC (HTTP/3) [기본] / gRPC over HTTP/2 [폴백]
                      W3C traceparent in gRPC Metadata
                      mTLS + SPIFFE SVID
                                            ║
@@ -125,7 +125,7 @@ T3 디바이스와 T2 게이트웨이 사이의 단절은 예외가 아닌 정
 │  - SSE / Webhook: 비동기 Task 상태 업데이트                  │
 ├─────────────────────────────────────────────────────────────┤
 │  Layer 2: Transport Layer (전송 계층)                        │
-│  - T1↔T2: gRPC over QUIC (HTTP/3) + Bidi Streaming          │
+│  - T1↔T2: gRPC over QUIC (HTTP/3) [기본] / HTTP/2 [폴백]     │
 │  - T2↔T2: gRPC Bidi Streaming (엣지 합의)                   │
 │  - T2↔T3: MQTT 5.0 / CoAP Confirmable / gRPC-Lite           │
 │  - Retry Policy: Exponential Backoff + Jitter                │
@@ -142,7 +142,7 @@ T3 디바이스와 T2 게이트웨이 사이의 단절은 예외가 아닌 정
 
 | 구간 | 전송 프로토콜 | 보안 | 지연 목표 | 단절 내성 |
 |------|------------|------|----------|----------|
-| T1 ↔ T2 | gRPC over HTTP/2 or QUIC | mTLS + SPIFFE SVID | < 100ms | Resume Token + QUIC conn-migration |
+| T1 ↔ T2 | gRPC over QUIC [기본] / HTTP/2 [폴백] | mTLS + SPIFFE SVID | < 100ms | Resume Token + QUIC conn-migration |
 | T2 ↔ T2 | gRPC Bidi Streaming | mTLS + SPIFFE SVID | < 10ms | 로컬 재연결 + Bidi 재확립 |
 | T2 ↔ T3 (임베디드) | MQTT 5.0 / CoAP | X.509 SVID + TLS-PSK | < 1s | MQTT Last Will + QoS 1/2 |
 | T2 ↔ T3 (고성능) | gRPC-Lite / nanopb | mTLS Lite | < 50ms | Resume Token |
@@ -220,9 +220,9 @@ MCP 도구 호출은 T2 게이트웨이의 gRPC 인터셉터를 통해 tracepare
 
 **Rationale**: Bidi Streaming을 T2↔T2 엣지 합의에 사용하는 이유는, 다수 엣지 노드가 단일 소켓을 통해 ms 단위의 상호 메시지 교환을 진행할 수 있어 소켓 수를 O(n²)에서 O(n)으로 줄이기 때문이다.
 
-#### 3.2.2 gRPC over QUIC (T1↔T2)
+#### 3.2.2 gRPC over QUIC (T1↔T2) [기본] 및 HTTP/2 폴백
 
-T1↔T2 광역 무선 구간에서는 gRPC를 QUIC(HTTP/3) 위에 실어 다음 이점을 얻는다.
+T1↔T2 광역 구간은 gRPC over QUIC(HTTP/3) 프로토콜을 기본(Primary) 전송 채널로 사용하며, 다음의 이점을 제공한다:
 
 - **Connection Migration**: 모바일 IP 변경 시(5G→Wi-Fi) TCP 연결 단절 없이 마이그레이션
 - **0-RTT Handshake**: 재연결 시 0-RTT로 즉시 재개 (Resume Token과 시너지)
@@ -236,6 +236,8 @@ gRPC Frame
                     └── 5G NR / LTE / Wi-Fi Physical
 ```
 
+또한, 엣지 게이트웨이(T2)와 클라우드(T1) 사이의 전송 신뢰성을 보장하기 위해 **HTTP/2 폴백 협상(Fallback Negotiation)** 메커니즘을 내장한다. 클라이언트(게이트웨이)는 최초 접속 시 ALPN(Application-Layer Protocol Negotiation)에 `h3` 프로토콜을 우선 협상하며, UDP 포트 차단이나 방화벽 제약으로 인해 QUIC 연결이 실패하는 경우 즉시 표준 TCP 기반의 `h2`(gRPC over HTTP/2) 채택으로 강등(Downgrade)하여 연결 연속성을 유지한다.
+
 #### 3.2.3 T2↔T3 프로토콜 선택 기준
 
 ```
@@ -321,7 +323,7 @@ T2 엣지 게이트웨이는 본 아키텍처의 핵심 허브다. 이 컴포넌
 ### 4.1 컴포넌트 다이어그램
 
 ```
-                    T1 방향 (gRPC over QUIC / HTTP-2)
+                    T1 방향 (gRPC over QUIC [기본] / HTTP/2 [폴백])
                            │
            ┌───────────────▼───────────────────────────────┐
            │           gRPC Server (T1 facing)              │
@@ -995,7 +997,7 @@ Jaeger (트레이스 저장)  ←  Grafana Tempo
 
 | 설계 항목 | 스마트 팩토리 | 스마트 빌딩 | V2X | 헬스케어 |
 |---------|------------|-----------|-----|--------|
-| T1↔T2 백본 | gRPC + HTTP/2 | gRPC + 유선/4G | gRPC + QUIC (5G) | gRPC + 유선 |
+| T1↔T2 백본 | gRPC + QUIC (HTTP/2 폴백)* | gRPC + QUIC (HTTP/2 폴백)* | gRPC + QUIC (5G, HTTP/2 폴백) | gRPC + QUIC (HTTP/2 폴백)* |
 | T2↔T3 현장 | MQTT 5.0 / gRPC-Lite | MQTT + LoRa 브릿지 | C-V2X / ITS-G5 | BLE + MQTT |
 | 저지연 합의 | gRPC Bidi (AGV) | gRPC Unary (HVAC) | QUIC datagram | gRPC Unary (이벤트) |
 | 핸드오버 | Resume Token | Resume Token | QUIC conn-migration | Resume Token |
@@ -1004,6 +1006,8 @@ Jaeger (트레이스 저장)  ←  Grafana Tempo
 | 긴급 이벤트 | gRPC Stream 알림 | gRPC Unary 알림 | C-V2X CAM/DENM | gRPC Unary < 1s |
 | A2A 위임 방향 | T1→T2→T3 계층 | T1→T2 목표 기반 | T1 교통→T2 RSU | T2 감지→T1 임상 |
 
+* 주: T1↔T2 백본의 기본 전송 프로토콜은 gRPC over QUIC(HTTP/3)를 원칙으로 하나, 유선망 중심의 안정적인 고정 링크(스마트 팩토리, 헬스케어 유선망 등)에서는 인프라 호환성을 위해 gRPC over HTTP/2 폴백(Fallback)을 적극적으로 허용한다.
+
 ---
 
 ## 부록: Proto 설계 가이드라인

gRPC_Based_Interface/IMPL_DESIGN.md

@@ -548,7 +548,66 @@ var defaultDeadlines = map[string]int64{
 }
 ```
 
-> **참고**: 실제 quic-go와 gRPC-Go 통합 시 `grpc.WithContextDialer`를 사용하여 클라이언트 측에서 QUIC 다이얼러를 주입하는 방식이 더 실용적이다. 위 코드는 서버 측 리스너 래핑 패턴을 보여준다. 프로덕션에서는 `quic-go/http3` 패키지의 `ServeListener` 방식 또는 별도 gRPC-QUIC 어댑터 라이브러리(`github.com/open-telemetry/opentelemetry-collector-contrib` 참조)를 활용한다.
+> **참고**: 실제 quic-go와 gRPC-Go 통합 시 `grpc.WithContextDialer`를 사용하여 클라이언트 측에서 QUIC 다이얼러를 주입하는 방식이 더 실용적이다. 위 코드는 서버 측 리스너 래핑 패턴을 보여준다. 프로덕션에서는 `quic-go/http3` 패키지의 `ServeListener` 방식 또는 별도 gRPC-QUIC 어댑터 라이브러리(`github.com/open-telemetry/opentelemetry-collector-contrib` 참조)를 활용한다. 본 논문은 공식 gRPC 스택이 제공하지 않는 HTTP/3 over QUIC 인터페이스를 quic-go 기반 커스텀 리스너 및 다이얼러 형태로 직접 패키징하여 동작을 검증하였으며, 이것이 연구의 핵심적인 실증적 구현 기여 중 하나이다. 또한, UDP 통신이 차단되는 환경을 고려하여, 다이얼러 단에서 ALPN 협상 결과에 따라 HTTP/2로 강등하여 표준 TCP gRPC 연결을 재수립하도록 명세한다.
+
+#### HTTP/2 폴백(Fallback) 전송 어댑터 명세
+
+클라이언트(게이트웨이)가 UDP/QUIC 연결을 시도하고 실패하거나 UDP 차단을 감지한 경우 즉시 TCP/HTTP/2로 자동 전환하기 위해 `internal/gateway/fallback_dialer.go` 명세를 추가한다.
+
+```go
+package gateway
+
+import (
+    "context"
+    "crypto/tls"
+    "fmt"
+    "net"
+    "time"
+
+    "github.com/quic-go/quic-go"
+)
+
+// FallbackDialer는 QUIC 연결 시도 후 실패 시 TCP/HTTP2로 자동 전환하는 다이얼러이다.
+type FallbackDialer struct {
+    tlsConfig *tls.Config
+    timeout   time.Duration
+}
+
+func NewFallbackDialer(tlsConfig *tls.Config, timeout time.Duration) *FallbackDialer {
+    tlsConfig.NextProtos = []string{"h3", "h2"} // QUIC(h3) 우선 협상, 실패 시 HTTP/2(h2)로 폴백
+    return &FallbackDialer{tlsConfig: tlsConfig, timeout: timeout}
+}
+
+// DialContext는 UDP/QUIC 연결을 시도하고 실패 시 TCP/HTTP/2 연결로 폴백한다.
+func (d *FallbackDialer) DialContext(ctx context.Context, addr string) (net.Conn, error) {
+    quicCtx, cancel := context.WithTimeout(ctx, d.timeout)
+    defer cancel()
+
+    // 1. QUIC(HTTP/3) Dial 시도
+    quicConn, err := quic.DialAddr(quicCtx, addr, d.tlsConfig, nil)
+    if err == nil {
+        stream, err := quicConn.OpenStreamSync(ctx)
+        if err == nil {
+            return &quicStreamConn{stream: stream, conn: quicConn}, nil
+        }
+    }
+
+    // 2. 실패 시 TCP 기반 HTTP/2 Fallback 실행
+    dialer := &net.Dialer{Timeout: d.timeout}
+    tcpConn, err := dialer.DialContext(ctx, "tcp", addr)
+    if err != nil {
+        return nil, fmt.Errorf("both QUIC and HTTP/2 fallback failed: %w", err)
+    }
+
+    tlsConn := tls.Client(tcpConn, d.tlsConfig)
+    if err := tlsConn.HandshakeContext(ctx); err != nil {
+        tcpConn.Close()
+        return nil, err
+    }
+
+    return tlsConn, nil
+}
+```
 
 ### 4.2 MQTT→gRPC 변환 엔진
 

gRPC_Based_Interface/USECASES.md

@@ -168,7 +168,7 @@
 │   - 전송: gRPC(Unary / Server-streaming)                          │
 │   - 거버넌스: Istio Service Mesh, OTel Collector                  │
 └─────────────────────────────┬────────────────────────────────────┘
-              │  gRPC / HTTP-2 (유선·4G·안정)
+              │  gRPC over QUIC [기본] / HTTP/2 [폴백]
               ▼
 ┌──────────────────────────────────────────────────────────────────┐
 │ T2: 엣지 (Jetson / 산업용 PC / 5G MEC)                            │

paper_draft/DRAFT_PLAN.md

@@ -15,7 +15,7 @@ AI 에이전트의 자율적 문제 해결 능력은 산업 현장의 제어 및
 첫째, 상시 센서 데이터 수집을 전제로 설계된 지속 연결(Persistent Connection) 기반의 IoT 통신 모델과 달리, 거대 언어 모델은 매 호출 시점마다 비동기적인 작업 단위(Job-based)로만 연동되는 패러다임 불일치(Execution Paradigm Mismatch)를 겪는다. 둘째, 공장이나 농장의 다양한 이기종 장치 제어 스키마 및 AI 추론 모델을 매번 수작업으로 매핑하는 것은 대규모 배포 환경에서 비현실적(Dynamic Binding Barrier)이다. 셋째, 에이전트가 상시 대기 상태로 물리 노드를 점유하는 구조는 연산 자원 및 트래픽 측면에서 극도로 비효율적(Resource Allocation Inefficiency)이다. 마지막으로, 통신 및 도구 호출 예외로 인한 자율 재시도 루프 시, 중복 명령 살포(Control Idempotency Deficit)로 인한 물리적 장치의 오작동 및 안전 사고의 위험성이 잔존한다. 
 
 본 연구는 실제 엣지 AIoT 제약 환경 하에서 에이전트 오케스트레이션을 안정적으로 수행하기 위해 다음과 같은 연구 질문(Research Questions)을 정의하고 이를 해결하고자 한다:
-- **RQ 1 (지연 시간)**: 지속적 스트리밍 상태의 IoT 계층과 작업 단위로 동작하는 에이전트 계층을 연결할 때, gRPC 기반 양방향 스트리밍 중재가 통신 및 작업 처리 지연(Latency)에 미치는 영향은 무엇인가?
+- **RQ 1 (지연 시간)**: 지속적 스트리밍 상태의 IoT 계층과 작업 단위로 동작하는 에이전트 계층을 연결할 때, QUIC(HTTP/3) 기반 gRPC 양방향 스트리밍 중재가 기존 TCP 기반 HTTP/2 대비 통신 및 작업 처리 지연(Latency)과 무선 손실 조건에서의 연결 회복 속도에 미치는 영향은 무엇인가?
 - **RQ 2 (자원 효율성)**: 에이전트 노드가 항상 기동되어 물리적 자원을 점유하는 대신, 경량 이벤트 감지기 기반의 비동기 자원 위임 생명주기를 도입했을 때 에이전트 실행 환경의 연산 자원 및 트래픽 절감 효과는 어느 정도인가?
 - **RQ 3 (제어 안정성)**: 무선 네트워크 및 도구 호출 예외로 인한 자율 재시도 발생 시, 중복 명령 실행을 차단하기 위한 Control Intent Key 기반 멱등성 스키마가 물리 제어 계층의 동작 안정성 향상에 기여하는 바는 무엇인가?
 - **RQ 4 (상호운용성)**: 이기종 물리 장치 및 추론 모델의 기능 명세를 Agent Card 기반으로 런타임에 동적 바인딩하고 다유형 멀티모달 페이로드를 표준 스키마로 교환하도록 했을 때, 신규 장치 연동에 소요되는 수작업 매핑 비용과 이종 에이전트 간 메시지 교환 정합성은 어느 정도 개선되는가?
@@ -23,11 +23,11 @@ AI 에이전트의 자율적 문제 해결 능력은 산업 현장의 제어 및
 본 논문에서는 이러한 4대 문제를 해소하기 위하여 **gRPC 기반의 통합 에이전트 인터페이스 모듈(gRPC-based Unified Interface Module)**을 설계하고 제안한다. 통신 백본으로 gRPC를 채택한 것은 다음의 세 가지 기술적 근거에 기반한다:
 
 - 첫째, 산업용 AIoT 구조는 온도·습도 값을 특정하여 edge 또는 cloud로 전송하는 하부의 '센싱 계층'(MQTT/CoAP 최적)과, "농약 살포"와 같이 명령을 내리고 결과를 확인해야 하는 '제어 계층'으로 자연스럽게 나뉜다. gRPC는 바로 이 제어 계층의 명령 호출에 특화된 프로토콜이며, 교환 가능한 기능과 데이터 형식을 계약서처럼 사전에 못박아 두는 인터페이스 명세(IDL)가 이종 에이전트의 기능 명세서인 Agent Card(A2A 계열 표준)와 정합적으로 매핑되어 표준 준수형 연동의 토대가 된다.
-- 둘째, gRPC가 기반하는 HTTP/2 멀티플렉싱은 하나의 파이프라인 안에 여러 차선을 둔 고속도로처럼, 단일 연결 위에서 텍스트 제어 명령·카메라 이미지 스트림·장치 상태 회신이 서로를 가로막지 않고 동시에 흐르게 한다. 이 양방향 스트리밍 능력은 항상 연결되어 데이터를 흘려보내는 장치 계층과 필요할 때만 작업 단위로 동작하는 에이전트 계층 사이의 박자(실행 주기) 차이를 전송 계층 수준에서 자연스럽게 중재한다.
+- 둘째, TCP 기반 HTTP/2는 무선 손실 환경에서 패킷 유실 시 전체 스트림이 지연되는 Head-of-Line Blocking(HOLB) 한계를 갖는다. 본 제안은 단일 연결 내 차선별 독립 주행이 가능한 gRPC over QUIC(HTTP/3)를 채택하여, 신호 손실이 잦은 무선 환경에서도 텍스트 제어 명령, 카메라 이미지 스트림, 장치 상태 회신이 상호 간섭 없이 동시에 흐르게 한다. 이는 connection migration 및 0-RTT 재연결 특성과 결합되어, 상시 연결 상태의 장치 계층과 필요 시 작업 단위로 기동되는 에이전트 계층 간의 주기 차이를 전송 계층 수준에서 저지연으로 완벽히 중재한다 [2, 11].
 - 셋째, gRPC의 Protobuf는 송수신 양측이 미리 약속한 스키마에 따라 데이터를 압축된 이진 형태로 주고받으므로 텍스트(JSON)를 한 글자씩 해석하는 비용이 사라지고 전송 크기도 크게 줄어든다. 여기에 Envoy 로드 밸런서·Kubernetes 상태 감시 등 이미 검증된 클라우드 네이티브 인프라를 기존 전력망과 도로망에 접속하듯 그대로 활용할 수 있어, 대량 에이전트 태스크의 생명주기 관리와 부하 분산을 밑단부터 새로 구축할 필요가 없다(상세 논거는 2장에서 다룬다).
 
 본 연구의 주요 기여는 다음과 같이 요약된다:
-- 항상 연결되어 데이터를 흘려보내는 AIoT 물리 계층과 호출 시점마다 작업 단위로 동작하는 에이전트 계층, 즉 박자가 서로 다른 두 세계를 gRPC 양방향 스트리밍 위에서 실시간으로 잇는 통합 백본 메커니즘을 정립한다.
+- 항상 연결되어 데이터를 흘려보내는 AIoT 물리 계층과 호출 시점마다 작업 단위로 동작하는 에이전트 계층을 **gRPC over QUIC(HTTP/3)** 양방향 스트리밍 위에서 실시간으로 잇는 통합 백본 메커니즘을 정립하고, 공식 gRPC 스택의 미지원 영역을 보완하는 커스텀 전송 어댑터를 구현하여 무선 엣지 환경의 단절 내성을 검증한다.
 - 장치와 AI 모델의 기능 명세를 에이전트 카드(Agent Card)로 자동 인식·연결(동적 바인딩)하도록 하여 신규 장치를 추가할 때마다 반복되던 수작업 매핑을 최소화하고, 평상시에는 경량 이벤트 감지기만 상주시키다가 이상 징후가 포착된 순간에만 에이전트를 기동해 제어권을 넘기는 비동기 위임 생명주기를 구현하여 연산 자원과 트래픽 낭비를 크게 줄인다.
 - 재시도 루프로 인해 동일한 제어 명령이 두 번 도달하더라도 물리 장치가 두 번 동작하지 않도록, 명령의 멱등성 분류와 Control Intent Key 기반 중복 필터링 스키마를 설계하여 중복 제어로 인한 오작동과 안전 사고 위험을 선제적으로 차단한다.
 
@@ -55,9 +55,9 @@ AI 에이전트의 자율적 문제 해결 능력은 산업 현장의 제어 및
 
 AIoT 기반 지능형 에이전트 시스템은 텍스트뿐 아니라 고해상도 이미지(작물 병해 사진), 음향 주파수(설비 이상음), 센서 시계열 등 대용량 멀티모달 데이터를 상시 교환해야 한다. 그러나 기존 방식은 이 요구에 구조적 한계를 보인다. MQTT는 애초에 짧은 측정값 전달을 위해 설계되어 대용량 파일 전송을 고려하지 않았으므로 큰 페이로드가 유입되면 브로커에 병목이 발생하며, REST(HTTP/1.1)는 요청할 때마다 연결을 새로 맺고 끊는 방식이라 미디어 데이터를 반복 요청할수록 연결 수립(Handshake) 오버헤드가 누적된다.
 
-gRPC가 기반하는 HTTP/2의 다중화(Multiplexing)는 이 문제를 전송 원리 수준에서 해소한다 [10]. 이를 비유하면 **하나의 파이프라인(단일 TCP 연결) 안에 여러 차선(스트림)을 두어 서로 다른 데이터가 동시에 달리는 고속도로**와 같다. 한 차선에서는 에이전트의 텍스트 제어 명령이, 옆 차선에서는 카메라 이미지 스트림이, 또 다른 차선에서는 장치 상태 회신이 서로를 가로막지 않고 동시에 흐르므로, 연결을 매번 새로 맺을 필요 없이 단일 연결·단일 포트 위에서 Request/Response와 양방향 스트리밍(Bidirectional Streaming)이 저지연으로 공존한다. 또한 스트리밍 프리미티브를 조합하여 외부 브로커 없이 단일 서비스 내에서 한정적 Pub/Sub 상호작용 패턴을 구현할 수 있으나, N:N 팬아웃(Fan-out)이나 메시지 보존(Retention)이 필요한 경우에는 별도의 메시지 브로커 연계가 요구된다. 
+gRPC가 기반하는 HTTP/2의 다중화(Multiplexing)는 단일 TCP 연결 상에서 여러 스트림을 전송하여 연결 수립 오버헤드를 낮추는 개선을 이루었으나 [10], TCP 프로토콜 수준의 Head-of-Line Blocking(HOLB) 한계로 인해 무선 엣지 네트워크에서 패킷 유실 발생 시 전체 스트림이 함께 지연되는 구조적 문제를 안고 있다. 또한 게이트웨이의 이동에 따른 핸드오버 발생 시 연결이 전면 재수립되어야 하는 취약점이 존재한다.
 
-나아가 손실이 잦은 무선 엣지 네트워크 환경을 겨냥한 QUIC 기반 HTTP/3 전송 지원이 실험적 단계로 진행 중이므로 [2, 11], 향후 전송 계층의 고속화 진화를 수용할 확장성을 확보한다. gRPC가 이미 마이크로서비스 아키텍처(MSA)의 사실상 표준 인터페이스로 통용되고 있다는 점은 제안 모듈의 현업 시스템 이식성과 확장 속도 측면에서도 이점으로 작용한다.
+본 제안 모듈은 UDP 위에서 독립된 스트림 멀티플렉싱과 Connection ID 기반의 세션 유지를 지원하는 **gRPC over QUIC(HTTP/3) 프로토콜을 핵심 전송 백본으로 채택**하여 이 한계를 근본적으로 해결한다 [2, 11]. 한 차선(스트림)의 유실이 다른 차선에 영향을 주지 않아 무선 손실 환경에서도 저지연 스트리밍을 유지하며, IP가 변경되는 핸드오버 상황에서도 기존 전송 연결을 유지(Connection Migration)함으로써 에이전트 제어 안정성을 보장한다. 비록 현재 공식 gRPC 스택에서의 HTTP/3 표준 지원은 부분적이거나 실험적 단계에 있으나, 본 연구는 `quic-go`를 기반으로 커스텀 전송 계층 어댑터를 구현하여 무선 엣지 환경에서의 실효성을 실증한다. 이는 본 논문의 핵심적인 실증/구현 기여 중 하나이며, 동시에 방화벽 UDP 차단 등 QUIC 사용이 불가한 예외 환경에 대응하기 위한 HTTP/2 폴백(Fallback) 전송 협상 구조를 함께 내장하여 범용적 호환성을 확보한다. gRPC가 이미 마이크로서비스 아키텍처(MSA)의 사실상 표준 인터페이스로 통용되고 있다는 점은 제안 모듈의 현업 시스템 이식성과 확장 속도 측면에서도 이점으로 작용한다.
 
 ### 구조화된 직렬화 기반의 태스크 생명주기 관리 및 부하 분산 효율
 
@@ -113,7 +113,7 @@ AIoT 서비스 환경에서 멀티 에이전트 오케스트레이션(Multi-Agen
 
 ## gRPC Communication Backbone
 - Protobuf 기반 메시지 스키마 정의 (태스크, 이벤트, 제어 명령 규격)
-- HTTP/2 기반 양방향 스트리밍을 통한 상시 연결 계층과 작업 단위 계층의 중재 (시간 축 해소)
+- QUIC(HTTP/3) 기반 양방향 스트리밍을 통한 상시 연결 계층과 작업 단위 계층의 중재 및 HTTP/2 폴백(Fallback) 전송 협상 절차 (시간 축 해소)
 - Request/Response 및 스트리밍 기반 Pub/Sub 패턴 구현
 
 ## Agent Card-based Dynamic Binding Layer
@@ -141,21 +141,21 @@ AIoT 서비스 환경에서 멀티 에이전트 오케스트레이션(Multi-Agen
 
 ## Software Stack and Agent Deployment
 - 에이전트 프레임워크 및 제안 모듈 구현 스택 (gRPC/Protobuf 버전 포함)
-- 비교군(Baseline) 구성: 기존 REST/MQTT 기반 연동 방식
+- 비교군(Baseline) 구성: 기존 REST/MQTT 기반 연동 방식 및 gRPC over HTTP/2 (전송 기여 분리 증명용 비교군)
 
 ## Evaluation Scenarios and Metrics
-- 평가 시나리오: 정상 경로, 재시도/장애 주입(Fault Injection), 동시 다중 위임
+- 평가 시나리오: 정상 경로, 무선 손실(패킷 유실 주입) 및 핸드오버(IP 변경), 재시도/장애 주입(Fault Injection), 동시 다중 위임
-- 평가 지표: 지연 시간, 처리량, 자원 점유율, 중복 제어 발생률, 동적 바인딩 소요 시간 (연동 설정 비용)
+- 평가 지표: 지연 시간, 처리량, 자원 점유율, 중복 제어 발생률, 동적 바인딩 소요 시간 (연동 설정 비용), 핸드오버 시 스트림 회복 시간 및 재연결 RTT
 
 # Performance Analysis
 
 ## Experimental Results
-- 통신 성능 비교 (gRPC vs. Baseline): 지연 시간 및 처리량
+- 전송 계층 및 프로토콜별 비교 (gRPC/QUIC vs. gRPC/HTTP2 vs. REST/MQTT): 정상, 무선 유실 및 핸드오버 조건 하에서의 지연 시간 및 처리량
 - 자원 효율성 분석: 이벤트 기반 위임 구조의 노드 점유율 절감 효과
 - 안정성 검증: 재시도 루프 하에서의 중복 제어 억제율 (멱등성 보장 효과)
 
 ## Discussion
-- 4대 문제 축별 해소 여부 검증 및 한계 분석
+- 4대 문제 축별 해소 여부 검증 및 한계 분석 (gRPC over HTTP/3 표준화 성숙도 제약, UDP 차단 및 미들박스 환경 대응성)
 - 제안 모듈의 일반화 가능성 (스마트 팩토리 등 타 도메인 확장)
 
 # Conclusion and Future Work