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) |
-| **QUIC/HTTP3**     | 매우 적합     | 부분적       | 낮음                        | 양방향                           | connection migration | 없음(독립)        | 무거움       |
+| **gRPC/HTTP/2**    | 매우 적합     | 부분적       | 낮음(Protobuf 이진)           | 4방향(Unary/Server/Client/Bidi) | Retry Policy(제한적)    | 강함(Proto IDL) | 무거움(수 MB) |
+| **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: 제로 트러스트 워크로드 신원