docs: 260508 세미나를 위한 프롬프트 추가

2026-05-07 04:42:50 +00:00
parent cb53f6c912
commit 91527fd56d
5 changed files with 1024 additions and 1 deletions
@@ -31,7 +31,18 @@ AI Agent 시대의 도래
 ## 1. AI Agent 시대의 통신 환경 변화
-### 1.1. AI Agent란 무엇인가
+### 1.1. AIoT란 무엇인가
 본 연구에서 **AIoT(Artificial Intelligence of Things)**란 AI Agent(LLM 기반 지능형 에이전트)와 IoT(사물인터넷) 디바이스가 **동일한 엣지-클라우드 인프라에서 공존하며 상호작용하는 환경**을 의미한다.
 기존 IoT는 센서 데이터 수집·전송이 주목적이었다면, AIoT는 **AI Agent가 IoT 데이터를 실시간으로 분석·의사결정·실행**하는 단계로의 진화를 뜻한다. 예를 들어, 스마트팜에서 카메라 센서가 수집한 이미지를 AI Agent가 분석하여 해충 발견 시 살충제 분사 명령을 내리는 것이 AIoT의 전형적인 시나리오다.
 AIoT 환경의 핵심 특징은:
 - **이기종 트래픽의 공존** — 수 KB의 Agent 간 RPC 호출과 수 MB의 IoT 이미지 데이터가 같은 네트워크를 공유
 - **엣지-클라우드 분산 처리** — 지연에 민감한 작업은 엣지에서, 정밀 분석은 클라우드에서 수행
 - **단대단(end-to-end) 응답성 요구** — 센서 데이터 수집 → AI 분석 → 액추에이터 제어까지의 전체 지연이 시스템 품질을 결정
 ### 1.2. AI Agent란 무엇인가
 AI Agent는 기존의 AI 모델(LLM 등)이 단독으로 수행할 수 없었던 **실질적인 작업 실행**을 가능하게 하는 시스템이다. 구체적으로:
@@ -202,6 +213,8 @@ QUIC/HTTP/3 표준(RFC 9000)이 2021년에 발표되었고, 현재 주요 기술
 2. 엣지 기반 처리(ROI 탐지 후 필요한 데이터만 전달)가 **고지연 환경에서 특히 효과적**
 3. gRPC + 엣지 처리 조합이 최상의 성능을 보임
 > **참고**: 선행 연구의 구체적 성능 수치(응답 시간 감소율, 데이터 절감률 등)는 본 연구의 Phase 1(실제 서버 구현)에서 동일 조건으로 재현·확장하여 측정할 예정이다. 현재 Phase 0(데모 UI)의 시뮬레이션 값은 발표 시연용 mock 데이터로, 실측 결과는 아니다.
 **선행 연구가 제안한 향후 연구 방향**:
 1. **HTTP/3(QUIC) 기반 gRPC 도입** ← 본 연구의 주요 방향
 2. 다양한 스트리밍 패턴 비교 (Unary / Server / Client / Bidi)
@@ -0,0 +1,298 @@
 # 연구 수행 배경
 > 본 문서는 AIoT gRPC 고성능 통신 모듈 연구가 시작된 **구조적 배경**을 정리한다.
 > 발표 자료(슬라이드) 추출이 가능하도록 논리적 흐름을 구성하였다.
 >
 > 본 프로젝트의 구체적 제안과 실행 계획은 [`CLAUDE.md`](CLAUDE.md)를, 선행 IoT 연구 결과는 [`참고/SGS/README.md`](참고/SGS/README.md)를 참조한다.
 ---
 ## 0. 연구의 전체 흐름
 ```
 AI Agent 시대의 도래
    │
    ├─ AI Agent 수 증가
    ├─ 서브에이전트/외부 서비스 통신 증가
    └─ 24/7 가동 → 동시간 통신 폭증
    │
    ▼
 통신 인프라에 대한 요구 증가
    │
    ├─ gRPC(HTTP/2)가 기존 REST보다 우수함은 확인됨 (선행 연구)
    ├─ 그러나 TCP 기반 HTTP/2는 근본적 한계 존재
    └─ QUIC(HTTP/3)이 이 한계를 해결할 차세대 전송 프로토콜로 부상
    │
    ▼
 본 연구: gRPC over QUIC 통신 모듈을 AIoT 환경에서 실증
 ```
 ---
 ## 1. AI Agent 시대의 통신 환경 변화
 ### 1.1. AIoT란 무엇인가
 본 연구에서 **AIoT(Artificial Intelligence of Things)**란 AI Agent(LLM 기반 지능형 에이전트)와 IoT(사물인터넷) 디바이스가 **동일한 엣지-클라우드 인프라에서 공존하며 상호작용하는 환경**을 의미한다.
 기존 IoT는 센서 데이터 수집·전송이 주목적이었다면, AIoT는 **AI Agent가 IoT 데이터를 실시간으로 분석·의사결정·실행**하는 단계로의 진화를 뜻한다. 예를 들어, 스마트팜에서 카메라 센서가 수집한 이미지를 AI Agent가 분석하여 해충 발견 시 살충제 분사 명령을 내리는 것이 AIoT의 전형적인 시나리오다.
 AIoT 환경의 핵심 특징은:
 - **이기종 트래픽의 공존** — 수 KB의 Agent 간 RPC 호출과 수 MB의 IoT 이미지 데이터가 같은 네트워크를 공유
 - **엣지-클라우드 분산 처리** — 지연에 민감한 작업은 엣지에서, 정밀 분석은 클라우드에서 수행
 - **단대단(end-to-end) 응답성 요구** — 센서 데이터 수집 → AI 분석 → 액추에이터 제어까지의 전체 지연이 시스템 품질을 결정
 ### 1.2. AI Agent란 무엇인가
 AI Agent는 기존의 AI 모델(LLM 등)이 단독으로 수행할 수 없었던 **실질적인 작업 실행**을 가능하게 하는 시스템이다. 구체적으로:
 - **파일 접근** — 로컬 파일 시스템에서 문서를 읽고 쓰고 편집
 - **프로그램 실행** — 코드 실행, 데이터베이스 쿼리, 시스템 명령어 실행
 - **외부 API 호출** — 웹 검색, 이메일 전송, SaaS 서비스 연동
 즉, AI Agent는 **"생각하는 AI"에서 "행동하는 AI"로의 전환**을 실현하는 핵심 기술이다.
 ### 1.2. AI Agent의 통신 구조
 AI Agent가 작업을 수행하기 위해 거치는 통신 패턴은 다음과 같다:
 ```
 사용자 질의
    │
    ▼
 ┌─────────────────────┐
 │   Main Agent        │ ←── LLM (추론 엔진)
 │   (의사결정·계획)    │
 └────────┬────────────┘
         │
    ┌────┴────┬────┬──────┐
    ▼         ▼    ▼      ▼
 서브에이전트  RAG  도구   IoT
 (전문작업)  (DB)  (API) (센서)
 ```
 - 메인 에이전트는 작업을 분석하고, 필요에 따라 **서브에이전트(sub-agent)**, **외부 데이터베이스(RAG)**, **외부 도구(API)** 를 호출한다.
 - 각 호출은 **네트워크를 통한 RPC(Remote Procedure Call)** 이며, 이 통신의 속도가 전체 응답 시간을 결정한다.
 - AI Agent가 설치된 환경(로컬/엣지)과 AI 모델이 호스팅된 위치(클라우드)가 분리되어 있으므로, 통신은 로컬뿐 아니라 원격으로도 발생한다.
 ### 1.3. AI Agent가 만드는 트래픽 폭증
 한 개의 AI Agent가 단독으로 동작할 때는 통신 부하가 크지 않다. 그러나 다음과 같은 요인이 트래픽을 폭증시킨다:
 | 요인 | 설명 |
 |------|------|
 | **Agent 수 증가** | 하나의 태스크에 여러 Agent가 팀으로 동작 → Agent 수 = 통신 건수 |
 | **서브에이전트 체인** | 작업이 복잡할수록 서브에이전트 호출 체인이 길어짐 |
 | **외부 서비스 의존** | RAG 조회, 도구 호출, 데이터베이스读写 등 모든 단계에서 통신 발생 |
 | **연속 실행** | 사람이 쉬는 동안에도 Agent는 24시간 작업 → 동시간 트래픽 누적 |
 결과적으로 **하나의 엣지 노드에서 발생하는 IPC/네트워크 통신 건수는 기존 대비 크게 증가**할 것으로 예상된다. (정확한 증가율은 AI Agent의 작업 복잡도와 서브에이전트 체인 깊이에 의존하므로, 본 연구에서 측정할 예정이다.)
 ---
 ## 2. 트래픽 폭증을 가속하는 세 가지 구조적 요인
 ### 2.1. 보안 격리에 따른 프로세스 폭증
 AI Agent는 파일 접근, 프로그램 실행, 외부 API 호출 등 **강력한 권한**을 보유한다. 이 권한은 그 자체로 보안 위협이며, 다음과 같은 공격 표면(attack surface)을 만든다:
 - 프롬프트 인젝션을 통한 악의적 명령 실행
 - 파일 시스템 접근을 통한 데이터 유출
 - API 키 등 민감 정보의 외부 유출
 이를 완화하기 위해 **각 AI Agent를 독립된 가상화 공간(컨테이너/VM)에 격리**하는 것이 표준 보안 관행이 되고 있다. 격리는 보안에는 효과적이지만, 결과적으로 같은 물리 노드 안에서도 Agent 간 통신이 네트워크 스택을 거쳐야 함을 의미한다.
 | 요소 | 영향 |
 |------|-------|
 | 컨테이너/VM 격리 | 프로세스 간 통신(IPC)이 네트워크 통신으로 전환 |
 | 에이전트당 1컨테이너 | 한 노드에서 수십~수백 개 컨테이너 실행 |
 | 컨테이너 간 통신 | 모두 gRPC/HTTP 기반 네트워크 호출 |
 즉, **보안을 위한 격리가 오히려 통신 건수를 폭증시키는 역설**이 발생한다.
 ### 2.2. 컨텍스트 메모리 한계와 서브에이전트 아키텍처
 AI Agent(특히 LLM 기반)는 **일정 수준 이상의 작업이 누적되면 컨텍스트(메모리) 한계로 성능이 저하**되는 근본적 한계를 가진다. 컨텍스트가 길어질수록 추론 품질이 떨어지고, 지연 시간이 증가하며, 토큰 비용이 선형으로 증가한다.
 이를 해결하기 위한 표준 패턴:
 - **컨텍스트 압축** — 중요 정보만 추출하여 컨텍스트 길이 관리
 - **서브에이전트 분리** — 특정 작업 전용 보조 Agent가 Main Agent의 부하 분산
 - **외부 데이터베이스 + RAG** — 필요할 때만 관련 데이터를 조회하여 메모리 부담 완화
 이 패턴이 의미하는 바: **Agent가 일을 더 오래, 더 복잡하게 할수록 외부 서비스와의 통신이 더 빈번해진다.** 그리고 이 통신의 속도가 전체 시스템의 응답성을 좌우한다. 즉, AI Agent의 **지능**은 LLM이 결정하지만, AI Agent의 **속도**는 통신 인프라가 결정한다.
 ### 2.3. 24/7 AI 서비스와 동시 트래픽 급증
 AI 서비스는 사람과 달리 24시간 중단 없이 운영된다.
 - 사용자가 쉬는 밤 시간에도 AI Agent는 작업을 수행한다 (백업, 데이터 정리, 배치 처리 등)
 - 복잡한 작업을 의뢰하는 사용자가 늘어날수록 AI Agent의 가동 시간이 길어진다
 - 결과적으로 **동시간에 인터넷을 사용하는 AI Agent의 수가 급증**한다
 이는 통신 인프라에 다음과 같은 요구를 만든다:
 - **높은 RPS(초당 요청 수)** — 수백~수천 개의 Agent가 동시에 RPC 호출
 - **짧은 연결 수립 시간** — 빈번한 단발성 호출에서는 연결 수립 비용이 지배적
 - **불안정 네트워크 내성** — 무선/모바일/엣지 환경에서의 패킷 손실에 강건해야 함
 ---
 ## 3. 기존 통신 기술의 한계와 QUIC의 등장
 ### 3.1. gRPC: 현재까지의 최선의 선택
 왜 하필 gRPC인가? AI Agent 간 또는 Agent-서비스 간 통신에는 NATS, RabbitMQ, WebSocket, ZeroMQ 등 다양한 선택지가 존재한다. 그러나 본 연구는 다음과 같은 이유로 gRPC를 선택했다:
 - **선행 연구(SGS) 검증 완료**: gRPC(Protobuf + HTTP/2)가 REST(JSON)보다 응답 시간과 데이터 전송량에서 우수함을 실험적으로 확인함
 - **AI Agent 통신 패턴과의 정합성**: AI Agent 호출은 Request-Response 패턴(Unary RPC)이 지배적이며, gRPC는 이 패턴에 최적화되어 있음
 - **ProtoBuf 기반 엄격한 인터페이스 계약**: 서비스 간 인터페이스를 IDL로 명확히 정의할 수 있어, 다수 Agent가 협업하는 환경에서 인터페이스 불일치를 방지함
 - **양방향 스트리밍 기본 지원**: IoT 디바이스의 연속적인 데이터 스트림 처리에도 하나의 프로토콜 스택으로 대응 가능
 물론 gRPC가 모든 시나리오에 최적이라는 의미는 아니다. 게시-구독(Pub/Sub) 패턴이 지배적인 경우 NATS나 RabbitMQ가 더 적합할 수 있다. 본 연구는 **Request-Response 기반의 AI Agent 통신과 IoT 데이터 전달을 하나의 통신 스택으로 통합**하는 시나리오에 초점을 맞추며, 이 경우 gRPC가 가장 적합한 선택이다.
 본 연구의 선행 연구(참고/SGS)는 스마트팜 해충 탐지 시나리오에서 다음을 실험적으로 확인했다:
 - **gRPC(Protobuf + HTTP/2)는 REST(JSON + HTTP/2)보다 응답 시간과 데이터 전송량 모두에서 우수**
 - **엣지 기반 처리**(ROI 탐지 후 필요한 데이터만 클라우드로 전달)가 클라우드 중심 처리 대비 고지연 환경에서 특히 효과적
 그러나 gRPC도 근본적으로 HTTP/2 위에서 동작하며, HTTP/2는 **TCP를 전송 계층으로 사용**한다. TCP는 1970년대에 설계된 프로토콜로, 현대 AIoT 환경에서 다음과 같은 한계를 가진다.
 ### 3.2. TCP(HTTP/2)의 근본적 한계
 | 문제 | 설명 | AIoT 환경에서의 영향 |
 |------|------|---------------------|
 | **연결 수립 비용** | TCP(1-RTT) + TLS(1-2 RTT) = 최소 2-3 RTT 필요 | 격리된 Agent 간 빈번한 단발성 RPC에서 latency 증가 |
 | **HoL(Head-of-Line) Blocking** | 한 TCP 스트림의 패킷 손실이 같은 연결의 모든 스트림을 지연시킴 | 무선 환경, 다중 동시 RPC에서 성능 저하 |
 | **연결 고정(Connection Pinning)** | 클라이언트 IP/포트 변경 시 연결 단절 및 재수립 필요 | 모바일 IoT, NAT rebinding 환경에서 취약 |
 이 중 **HoL Blocking 문제는 HTTP/2에서 특히 심각**하다. HTTP/2는 하나의 TCP 연결에 여러 스트림을 멀티플렉싱하지만, TCP 레벨에서는 모든 스트림이 하나의 바이트 스트림을 공유하므로 패킷 손실 시 모든 스트림이 영향을 받는다.
 ### 3.3. QUIC(HTTP/3): 차세대 전송 프로토콜
 QUIC(Quick UDP Internet Connections)은 Google이 설계하고 IETF에서 표준화(RFC 9000, 2021)한 **UDP 기반 전송 프로토콜**이다. HTTP/3의 전송 계층으로 채택되었다.
 | QUIC의 특성 | TCP 대비 개선점 | AIoT에서의 효용 |
 |------------|----------------|-----------------|
 | **0-RTT 연결 수립** | TLS 1.3 키 자료를 캐싱하여 두 번째 연결부터 0-RTT | 격리된 Agent 간 빈번한 RPC의 latency 대폭 감소 |
 | **스트림 독립성** | 각 스트림이 독립적인 흐름 제어 → 패킷 손실이 다른 스트림에 영향 없음 | 무선 IoT, 다중 동시 RPC에서 성능 유지 |
 | **연결 마이그레이션** | Connection ID 기반으로 IP 변경에도 연결 유지 | 모바일 IoT, 네트워크 전환 환경에 강건 |
 | **내장 암호화** | TLS 1.3이 프로토콜에 통합, 모든 패킷 암호화 | 추가 설정 없이 보안 통신 |
 **가장 중요한 차이점**: QUIC은 **UDP 위에서 자체적인 혼잡 제어, 흐름 제어, 손실 복구를 구현**하여 TCP의 HoL Blocking 문제를 근본적으로 해결한다.
 ### 3.4. 왜 지금 이 연구인가 (Timeliness)
 QUIC/HTTP/3 표준(RFC 9000)이 2021년에 발표되었고, 현재 주요 기술 스택에서의 적용이 가속화되고 있다:
 | 영역 | 현황 |
 |------|------|
 | **웹 서버** | Nginx, Caddy, Envoy — HTTP/3 지원 이미 완료 |
 | **CDN** | Cloudflare, Akamai — QUIC 기반 전송 제공 |
 | **브라우저** | Chrome, Firefox, Safari — HTTP/3 기본 지원 |
 | **gRPC** | 공식 gRPC 코어 팀에서 gRPC over QUIC 실험 중이나 아직 stable 미도달 |
 즉, 인프라 레벨에서는 HTTP/3 도입이 활발하지만, **gRPC 통신 계층에서 QUIC을 활용하는 연구와 실증은 아직 초기 단계**에 있다.
 - gRPC over QUIC에 대한 PoC는 quic-go, MsQuic 커뮤니티에서 존재하나, **AIoT 환경 특화 실증(evaluation)** 은 부재
 - **AI Agent 통신 패턴**이라는 새로운 워크로드에 대한 QUIC 적용 연구는 거의 없음
 본 연구는 이 격차(gap)를 메우기 위해, **gRPC over QUIC 통신 모듈을 AIoT 환경에서 실증**하는 것을 목표로 한다.
 ---
 ## 4. 기반이 되는 선행 연구
 ### 4.1. 스마트팜 해충 탐지 기반 gRPC vs REST 비교 (참고/SGS)
 스마트팜 해충 탐지 시나리오에서 **gRPC(HTTP/2) vs REST(HTTP/2)** 비교 실험을 수행했다.
 **실험 구성**:
 - 엣지 컨트롤러(N150) → 1차 ROI 탐지(AMD Ryzen AI 9) → 정밀 분석(GCP)
 - 세 가지 시스템 비교: Cloud 기반 REST, Edge 기반 REST, Edge 기반 gRPC
 **핵심 발견**:
 1. gRPC(Protobuf)는 REST(JSON)보다 **응답 시간과 데이터 전송량 모두에서 우수**
 2. 엣지 기반 처리(ROI 탐지 후 필요한 데이터만 전달)가 **고지연 환경에서 특히 효과적**
 3. gRPC + 엣지 처리 조합이 최상의 성능을 보임
 > **참고**: 선행 연구의 구체적 성능 수치(응답 시간 감소율, 데이터 절감률 등)는 본 연구의 Phase 1(실제 서버 구현)에서 동일 조건으로 재현·확장하여 측정할 예정이다. 현재 Phase 0(데모 UI)의 시뮬레이션 값은 발표 시연용 mock 데이터로, 실측 결과는 아니다.
 **선행 연구가 제안한 향후 연구 방향**:
 1. **HTTP/3(QUIC) 기반 gRPC 도입** ← 본 연구의 주요 방향
 2. 다양한 스트리밍 패턴 비교 (Unary / Server / Client / Bidi)
 3. LLM 기반 동적 작업 라우팅 (본 연구의 범위 밖, 정적 룰 기반으로 한정)
 ### 4.2. 선행 연구 대비 본 연구의 차별성
 | 비교 항목 | 선행 연구 (SGS) | 본 연구 |
 |-----------|----------------|---------|
 | 전송 계층 | HTTP/2 (TCP) | **HTTP/3 (QUIC) 추가 및 비교** |
 | 시나리오 | 스마트팜 단일 시나리오 | IoT + **AI Agent RPC 패턴** 이중 시나리오 |
 | 게이트웨이 | 개념적 제시 | **gRPC-QUIC 기반 구현·정량 검증** |
 | 평가 지표 | 응답 시간, 데이터 전송량 | + **0-RTT 효과, HoL Blocking 내성, 연결 마이그레이션** |
 | 비교 시스템 수 | 3개 (REST-Cloud, REST-Edge, gRPC-H2-Edge) | **6개** (4-way 전송 비교 + 스트리밍 + 게이트웨이) |
 ---
 ## 5. 본 연구가 다루는 문제로의 수렴
 ### 5.1. AIoT 환경에서 요구되는 통신의 특성
 앞서 살펴본 세 가지 추세(보안 격리, 서브에이전트 아키텍처, 24/7 서비스)와 기존 기술의 한계(TCP의 HoL Blocking, 연결 수립 비용)는 다음 요구사항으로 수렴한다:
 ```
 필요 조건
    │
    ├─ ① 많은 수의 연결을 빠르게 수립 (0-RTT)
    ├─ ② 패킷 손실 환경에서도 성능 유지 (HoL Blocking 해소)
    ├─ ③ 네트워크 전환 환경에서도 연결 유지 (Migration)
    └─ ④ 다양한 트래픽 패턴 수용 (수 KB RPC ~ 수 MB 스트리밍)
 ```
 ### 5.2. 본 연구의 두 가지 트래픽 대상
 본 연구는 다음 두 가지 트래픽 종류를 대상으로 하며, **모두 동일한 gRPC-QUIC 통신 스택으로 처리**한다.
 | 종류 | 특성 | 페이로드 패턴 | 대표 예시 |
 |------|------|-------------|----------|
 | **AI Agent ↔ 외부 서비스/Agent** | 짧고 빈번한 RPC, 컨테이너 격리 환경 | 수 KB, Unary 위주 | 서브에이전트 호출, RAG 조회, 도구 호출 |
 | **IoT Device ↔ Edge ↔ Cloud** | 다양한 응용 프로토콜(MQTT/CoAP), 엣지 단계적 처리 | 수 KB ~ 수 MB, 스트리밍 가능 | 해충 탐지 ROI 전달, 센서 데이터 적재 |
 ### 5.3. 연구 목표 요약
 본 연구는 다음을 목표로 한다:
 1. **gRPC over HTTP/3 (QUIC) 통신 모듈 구현** — Go 기반 서버/클라이언트
 2. **gRPC 엣지 게이트웨이** — 프로토콜 변환(MQTT/CoAP ↔ Protobuf) + 서비스 라우팅
 3. **6가지 시스템 간 정량 성능 비교** — gRPC-H3 vs gRPC-H2 vs REST-H2 vs REST-H1.1 등
 4. **두 시나리오(IoT, AI Agent)에서 각각 실증**
 **성공 기준**: 본 연구는 위 6가지 시스템 간 P50/P95/P99 latency, throughput(RPS), 연결 수립 비용(Connection Overhead), HoL Blocking 내성을 정량 측정하여 QUIC(HTTP/3) 기반 gRPC가 TCP(HTTP/2) 기반 gRPC 및 REST API 대비 유의미한 성능 개선을 제공하는지 검증한다. 각 측정값은 최소 30회 반복 후 95% 신뢰 구간을 함께 제시한다.
 구체적인 제안 기법과 평가 시나리오는 [`CLAUDE.md`](CLAUDE.md)에서, 구현 세부 사항은 [`IMPLEMENTATION.md`](IMPLEMENTATION.md)에서 다룬다.
 ---
 > **핵심 메시지**: AI Agent 시대가 요구하는 고빈도·저지연·고신뢰 통신을 위해, TCP 기반 HTTP/2의 한계를 QUIC(HTTP/3)으로 극복하는 gRPC 통신 모듈을 설계·구현하고, AIoT 환경에서 실증한다.
 ---
 ## 부록 A. 추후 보강 예정 항목
 본 문서는 세미나 발표를 위한 1차 개선을 완료한 상태다. 아래 항목은 시간 관계상 다음 기회에 보강할 예정이다.
 ### A.1. 정량적 데이터 근거
 - AI Agent 환경에서의 실제 통신 빈도와 규모에 대한 기존 연구 인용 또는 추정치
 - 기존 마이크로서비스 환경과 AI Agent 환경의 IPC/네트워크 통신량 비교 수치
 - 각 통신 프로토콜(TCP/QUIC/gRPC/REST)별 benchmark data 인용
 ### A.2. AI Agent 트래픽 특성 구체화
 - AI Agent 하나가 초당 발생시키는 RPC 수의 추정치
 - 서브에이전트 체인에서 허용 가능한 end-to-end latency 범위
 - TCP/HTTP/2가 위 요구사항을 충족하지 못한다는 수치적 증거 (기존 연구 인용 또는 본 연구에서 측정)
 ### A.3. AI Agent + IoT 두 시나리오 연결 논리 강화
 - 두 트래픽을 하나의 통신 스택으로 통합하는 것의 이점 명시 (운영 단순화, tech stack 일원화, 게이트웨이 변환 비용 제거 등)
 - 동일 gRPC-QUIC 스택이 두 시나리오를 모두 최적화할 수 있는 이유에 대한 논리적 설명
 - "범위가 너무 넓다"는 비판에 대한 대비 논리
@@ -0,0 +1,374 @@
 # AIoT gRPC 고성능 통신 모듈 — 연구 프로젝트
 > **언어**: Go | **프로토콜**: gRPC over HTTP/3 (QUIC) + Protocol Buffers v3
 > **목적**: AI Agent 및 AIoT 환경에서 고성능·경량 서비스 간 통신을 위한 **gRPC-QUIC 통신 모듈**과 이를 활용하는 **엣지 게이트웨이** 설계·구현·실증
 > **연구의 성격**: 새로운 프로토콜의 발명이 아니라, **AIoT 도메인 워크로드(AI Agent RPC + IoT 데이터 전송)에 gRPC over QUIC을 적용한 domain-specific empirical study**. AIoT 워크로드 특성에 따른 효과 측정이 부재한 격차(gap)를 메우는 것이 목적이다.
 ---
 ## 0. 문서 지침 (먼저 읽을 것)
 본 저장소의 문서는 **역할별로 분리**되어 있다. 작업을 시작하기 전에 자신의 작업 종류에 맞는 문서를 함께 참조한다.
 | 문서 | 역할 | 언제 참조하는가 |
 |------|------|----------------|
 | **`CLAUDE.md`** (본 파일) | 연구 방향·동기·목표·평가 지표·코드 정책·위험 관리 | 모든 작업 시작 시 |
 | **`IMPLEMENTATION.md`** | 디렉터리 구조, 네이밍, 워크플로우, 코드 패턴, Makefile, 멀티 에이전트 작업 분담 | 코드를 작성·수정·실행할 때 |
 | `BACKGROUND.md` | 연구 시작의 구조적 배경 (AI Agent 시대의 통신 인프라 변화) — 발표 자료 추출 가능 형태 | 연구 동기를 깊이 이해하거나 슬라이드로 추출할 때 |
 | `참고/SGS/README.md` | 선행 연구 (스마트팜 해충 탐지, gRPC vs REST/HTTP-2) | 연구 차별성·시나리오 설계 시 |
 | `FEEDBACK.md` | 외부 리뷰어의 비평 (긍정 평가 생략, 개선 지점만) | 큰 설계 변경 전 또는 보강 항목을 찾을 때 |
 | `docs/decisions/` | 설계 결정 기록 (ADR) | 중요한 설계 변경 전후 |
 | `docs/open-questions.md` | 미해결 탐색 주제 | 새 실험을 기획할 때 |
 > **원칙**: `CLAUDE.md`는 *연구 방향과 정책*만 다룬다. 디렉터리 경로, 명령어, 코드 샘플, 파일 단위 작업 분담 등 **구현 세부 사항은 모두 `IMPLEMENTATION.md`에** 둔다. 연구 배경의 자세한 서술은 모두 `BACKGROUND.md`에 두고, 본 문서는 *요약·정책·평가 계획*에 집중한다.
 ---
 ## 1. 연구 배경 및 동기 (요약)
 > 본 절은 핵심 요약만 다룬다. 추세·기술 한계·QUIC 개요의 자세한 서술은 [`BACKGROUND.md`](BACKGROUND.md)를 참조한다. (FEEDBACK §4.5에 따라 중복을 제거했다.)
 ### 1.1. 세 가지 구조적 추세 (한 줄 요약)
 | 추세 | 핵심 함의 |
 |------|---------|
 | **보안 격리** | 컨테이너/VM 격리로 같은 노드 내 통신도 네트워크 스택 경유 → 통신 건수 폭증 |
 | **서브에이전트 + RAG** | 컨텍스트 한계 극복을 위한 외부 서비스 통신 빈도 증가 → 통신 속도가 응답성을 좌우 |
 | **24/7 가동** | 사람이 쉬는 시간에도 동작하는 Agent로 동시간 트래픽 누적 → 동시성 폭증 |
 → 자세한 분석은 [`BACKGROUND.md`](BACKGROUND.md) §1, §2.
 ### 1.2. 기존 통신 기술의 한계 (한 줄 요약)
 - gRPC(HTTP/2) > REST는 선행 연구로 검증됨 ([`참고/SGS`](참고/SGS/README.md))
 - 그러나 HTTP/2 기반 gRPC는 **TCP의 근본적 한계**(연결 수립 비용, HoL Blocking, 연결 고정)를 그대로 상속
 - QUIC(HTTP/3)은 위 세 한계를 모두 해결하는 차세대 전송 계층
 → 자세한 분석은 [`BACKGROUND.md`](BACKGROUND.md) §3.
 ### 1.3. 선행 연구의 향후 과제 중 본 연구의 위치 — 왜 HTTP/3을 선택했는가
 [`참고/SGS`](참고/SGS/README.md)는 향후 연구로 다음 세 가지를 제시했다.
 1. **HTTP/3(QUIC) 기반 gRPC 도입** ← 본 연구의 주제
 2. 다양한 스트리밍 패턴 비교 (Unary / Server / Client / Bidi)
 3. LLM 기반 동적 작업 라우팅
 본 연구가 (1)을 우선 선택한 근거(FEEDBACK §2.1 반영):
 - **(2) 스트리밍 패턴**은 응용 계층의 표현 변화로, **전송 계층의 병목(연결 수립 비용·HoL Blocking)을 해결하지 못한다**. 같은 TCP 위에서 호출 모양만 바꾸는 셈이다.
 - **(3) LLM 라우팅**은 라우팅 의사결정의 지능화에 관한 것으로, **통신 채널의 효율 자체를 개선하지 않는다**. 라우팅이 똑똑해져도 채널이 느리면 응답성에 한계가 있다.
 - **(1) HTTP/3 도입**은 §1.1의 세 추세(보안 격리·빈번한 RPC·동시성)가 모두 만나는 **전송 계층을 직접 개선**하는 가장 영향력 있는 단일 변경이며, AIoT 도메인에서 실증이 부재하다.
 따라서 (1)을 우선 다루고, (2) 스트리밍 패턴은 본 연구의 P2 항목으로 부분 포함하며, (3) LLM 라우팅은 명시적 비목표(§3.2)로 제외한다.
 ### 1.4. 본 연구가 다루는 트래픽 두 종류
 | 종류 | 특성 | 페이로드 | 대표 예시 |
 |------|------|---------|----------|
 | **AI Agent ↔ 외부 서비스/Agent** | 짧고 빈번한 RPC, 컨테이너 격리 환경 | 1–8 KB, Unary 위주 | 서브에이전트 호출, RAG 조회, 도구 호출 |
 | **IoT Device ↔ Edge ↔ Cloud** | 다양한 응용 프로토콜(MQTT/CoAP), 엣지 단계적 처리 | 64 KB ~ 2 MB, 스트리밍 가능 | 해충 탐지 ROI 전달, 센서 데이터 적재 |
 **두 시나리오를 동일한 gRPC-QUIC 스택으로 다루는 근거** (FEEDBACK §4.1 반영):
 | QUIC 특성 | AI Agent 시나리오에서의 효용 | IoT 시나리오에서의 효용 |
 |-----------|---------------------------|----------------------|
 | 0-RTT 연결 수립 | 격리 에이전트 간 빈번한 단발성 RPC 가속 | 디바이스 reconnect 시 latency 감소 |
 | 스트림 독립성 (HoL Blocking 해소) | 다중 동시 RPC의 안정성 | 무선/모바일 IoT 패킷 손실 환경 강건 |
 | 연결 마이그레이션 | 컨테이너 재배치 시 일부 시나리오에서 유효 | 모바일 IoT, NAT rebinding |
 | Protobuf 표현 (gRPC 공통) | 호출 인터페이스 IDL 일관성 | 페이로드 절감 (특히 큰 메시지) |
 두 시나리오는 페이로드 크기와 패턴은 다르지만 **연결 빈도가 높고 패킷 손실에 노출되며 다양한 네트워크 조건에서 동작해야 한다**는 공통점을 가지며, QUIC의 핵심 이점이 두 시나리오 모두에 작용한다. 단, **각 시나리오에서 지배적인 KPI는 다르므로**(§5.4 참조) 단일 KPI로 두 시나리오를 평가하지 않는다.
 ---
 ## 2. 제안 기법
 본 연구의 기여는 **AIoT 도메인에서의 실증(domain-specific empirical study)**이다. gRPC over QUIC의 발명은 본 연구의 기여가 아니다 — 이미 quic-go 커뮤니티의 PoC, MsQuic 등에서 시도되고 있다(FEEDBACK §4.2 반영).
 ### 2.1. 제안 ① — AIoT 환경에서의 gRPC-QUIC 실증
 **기여의 성격**: 새로운 프로토콜의 발명이 아니라, **AIoT 도메인의 실제 워크로드에 gRPC over QUIC을 적용하고, 통제된 네트워크 조건에서 정량 비교**를 수행하는 empirical study다.
 **왜 이 실증이 필요한가:**
 - 기존 QUIC/HTTP-3 벤치마크는 **웹 트래픽**(브라우저-서버) 중심이며, AI Agent의 burst RPC 패턴이나 IoT 단계적 처리에 그대로 적용되지 않는다.
 - gRPC core team의 gRPC-over-QUIC도 stable에 도달하지 않았으며, **AIoT 워크로드 특성에 따른 효과 측정**이 부재하다.
 - 본 연구는 *"gRPC over QUIC이 AIoT 환경에서 얼마만큼의 개선을 가져오며, 어느 조건에서 가장 큰가?"*에 대한 정량 답을 제공한다.
 QUIC의 어떤 특성이 어떻게 작용하는지(0-RTT, HoL Blocking, 연결 마이그레이션)는 §1.4 표 참조.
 > 본 연구는 **0-RTT 측정에 필요한 TLS 1.3 설정 자체는 실험 범위에 포함**하며(self-signed 인증서 사용), 인증서 관리·인증/인가 등 프로덕션 수준의 보안 시스템은 비목표로 둔다 (§3.2).
 ### 2.2. 제안 ② — AI Agent + IoT 통합 엣지 게이트웨이
 **기여의 성격**(FEEDBACK §2.2 반영): 프로토콜 변환과 정적 라우팅 자체는 이미 존재하는 개념이다. 본 게이트웨이의 기여는 다음 두 가지에 있다.
 1. **AI Agent와 IoT를 단일 스택으로 통합** — 기존 IoT 게이트웨이는 MQTT↔HTTP 변환에 머무르고, AI Agent gateway는 별도 계열(LangGraph, MCP 등). 본 연구는 두 트래픽을 **하나의 게이트웨이가 처리하는 아키텍처**를 정의·구현·측정한다.
 2. **gRPC-QUIC 백본과의 통합 검증** — 게이트웨이가 백엔드와 gRPC-QUIC으로 통신할 때의 성능 영향(추가 hop의 latency, 자원 사용)을 정량 측정한다. 기존 게이트웨이 연구는 HTTP/2 위에서만 평가되었다.
 게이트웨이의 두 책임:
 1. **프로토콜 변환** — 외부 IoT 응용 프로토콜(MQTT, CoAP)에서 들어오는 메시지를 gRPC/Protobuf로 변환. AI Agent 측 트래픽은 이미 gRPC이므로 변환 없이 라우팅 단계로 진입.
 2. **서비스 라우팅** — 정적 룰 기반(룰 테이블) IoT 데이터의 단계적 처리 분배 및 AI Agent 호출의 백엔드 서비스 디스커버리.
 > **선행 연구의 LLM 기반 라우팅**은 본 연구의 범위 밖이다 (§3.2). 본 연구의 라우팅은 정적 룰 기반으로 한정한다.
 ### 2.3. 선행 연구(SGS) 대비 차별성
 | 비교 항목 | 선행 연구 (SGS) | 본 연구 |
 |-----------|---------------|---------|
 | 전송 계층 | HTTP/2 (TCP) | **HTTP/3 (QUIC) 추가 및 비교** |
 | 시나리오 | 스마트팜 단일 시나리오 | IoT 시나리오 + **AI Agent RPC 패턴** 이중 |
 | 게이트웨이 | 센서/엣지 인터페이스 변환기 (개념적 제시) | **AI Agent + IoT 통합 게이트웨이의 실증** |
 | 평가 지표 | 응답 시간, 데이터 전송량 | + **0-RTT 효과**, **HoL Blocking 내성**, **연결 마이그레이션**, 통계적 유의성 |
 | 비교 시스템 수 | 3개 | 6개 (4-way 전송 비교 + 스트리밍 + 게이트웨이) |
 ---
 ## 3. 프로젝트 목표 및 범위
 ### 3.1. 우선순위별 목표 (의존성 및 리스크 명시)
 FEEDBACK §2.3에 따라 각 P0 목표의 의존성과 주된 리스크를 함께 표기한다.
 | 우선순위 | 목표 | 주된 의존 / 리스크 |
 |----------|------|------------------|
 | P0 | **gRPC over QUIC 통신 모듈 구현** — Go 기반 서버/클라이언트 | quic-go ↔ gRPC transport interface 호환성 (§3.3 R-01) |
 | P0 | **gRPC 엣지 게이트웨이 설계·구현** — 프로토콜 변환 + 정적 룰 라우팅 | 통신 모듈(P0-1) 의존, MQTT/CoAP 어댑터 범위 통제 필요 (§3.3 R-03) |
 | P0 | gRPC/HTTP3 vs gRPC/HTTP2 vs REST/HTTP2 vs REST/HTTP1.1 4-way 정량 성능 비교 | P0-1 지연 시 HTTP/2까지 우선 측정, QUIC은 후속 추가 (§3.3 R-01 fallback) |
 | P1 | **IoT 시나리오 벤치마크** — 이미지/센서 데이터 (해충 탐지 ROI 단계적 처리) | gRPC 서버/클라이언트 완성 후 |
 | P1 | **AI Agent 통신 시나리오 벤치마크** — 짧고 빈번한 RPC, 다수 동시 에이전트 환경 | 동일 |
 | P2 | gRPC 스트리밍 패턴 비교 (Unary / Server-side / Client-side / Bidirectional) | Unary 측정 후 |
 | P2 | QUIC 0-RTT 재연결 성능 측정 및 연결 마이그레이션 시나리오 검증 | P0-1 완료 후 |
 > P0-1(통신 모듈)이 본 프로젝트의 핵심 병목이므로, §3.3의 위험 관리가 본 프로젝트 운영의 가장 중요한 과제다.
 ### 3.2. 비목표 (명시적 제외)
 - **프로덕션 수준 인증/인가 시스템 및 인증서 관리** *(0-RTT 측정에 필요한 TLS 1.3 설정 자체는 실험 범위에 포함, self-signed 인증서 사용)*
 - **LLM 기반 동적 작업 라우팅** *(선행 연구의 향후 과제로 제시되었으나, 본 연구는 정적 룰 기반 라우팅에 한정)*
 - 특정 하드웨어 최적화 (Raspberry Pi 등 임베디드 전용 튜닝)
 - Kubernetes 오케스트레이션 자동화
 - 프로덕션 UI/대시보드 *(데모 목적의 Terminal UI는 별도 산출물로 제공 — `src/README.md`)*
 ### 3.3. 위험 관리 (Risk Register)
 FEEDBACK §4.4 권고에 따라 도입했다. 각 위험은 발생 시 ADR로 정식 등록하고, 변경이 발생하면 본 표를 갱신한다.
 | ID | 위험 | 영향 | 가능성 | 대비책 |
 |----|------|------|--------|--------|
 | **R-01** | quic-go의 `Stream`과 gRPC transport(`net.Conn`) 인터페이스 의미 차이 — `SetDeadline`/`Close`(half-close)/`LocalAddr` 등 | 프로젝트 핵심 모듈 좌초 → P0 전체 지연 | 중간 | (a) PoC를 본 구현 전에 분리 제작하여 호환성 검증 (b) 실패 시 HTTP/2 기반 게이트웨이로 P0-2,3 우선 진행, QUIC은 별도 실험으로 분리 |
 | **R-02** | Docker 환경에서 `tc(netem)` 미작동 또는 컨테이너 격리로 인한 효과 미반영 | 네트워크 시뮬레이션 신뢰도 저하 | 낮음~중간 | 호스트 레벨 tc 적용, 또는 Linux network namespace로 노드 분리 후 적용. Phase 2(Mininet)에서는 자동 적용 |
 | **R-03** | MQTT/CoAP 어댑터 구현 범위 과다 | P0-2 일정 지연 | 중간 | MQTT만 우선 구현, CoAP은 P1으로 격하 |
 | **R-04** | Go/quic-go 버전업에 따른 API 변경 | 빌드 실패, 재작업 | 낮음 | `go.mod`에 quic-go 버전 고정, ADR로 변경 사유 기록 |
 | **R-05** | AI Agent 시나리오의 부하 발생기는 합성 부하 — 실제 LLM 호출 패턴과 차이 가능 | 결론의 일반화 약함 | 중간 | 부하 generator의 burst 파라미터(휴지·burst 크기·burst 간격)를 명시하고, 합성 부하임을 결론에 명기 |
 ---
 ## 4. 기술 스택
 | 영역 | 기술 | 비고 |
 |------|------|------|
 | **언어** | Go 1.22+ | `go.mod` 기준 |
 | **IDL** | Protocol Buffers v3 | `.proto` → Go 스텁 자동 생성 |
 | **gRPC** | `google.golang.org/grpc` | 공식 Go gRPC 라이브러리 |
 | **QUIC / HTTP/3** | `github.com/quic-go/quic-go` | Go 순수 구현 QUIC 라이브러리 (버전 고정 — R-04) |
 | **gRPC-QUIC 바인딩** | 커스텀 transport 패키지 | quic-go 위에 gRPC 전송 계층 구현 (R-01) |
 | **Protobuf 코드젠** | `protoc` + `protoc-gen-go` + `protoc-gen-go-grpc` | Makefile로 자동화 |
 | **HTTP 비교군** | Go 표준 `net/http` + `encoding/json` | REST API (HTTP/1.1, HTTP/2) |
 | **벤치마크** | Go 내장 `testing.B` + 커스텀 러너(`cmd/benchmark-runner`) | 측정 도구 (역할 분담은 IMPLEMENTATION.md) |
 | **자원 사용 측정** | `pidstat` (1초 샘플링), `pprof`(핫스팟 분석 한정) | §5.2 측정 방법 참조 |
 | **컨테이너** | Docker + Docker Compose | 실험 환경 재현성 확보 |
 | **네트워크 제어** | Linux `tc` (Phase 1), Mininet (Phase 2) | 지연/손실/대역폭 시뮬레이션 |
 > 구체적인 빌드/실행 명령은 [`IMPLEMENTATION.md`](IMPLEMENTATION.md) §3(개발 워크플로우)을 따른다.
 ---
 ## 5. 평가 시나리오 및 지표
 ### 5.1. 비교 대상 시스템
 각 시스템은 **두 시나리오 (① AI Agent RPC, ② IoT 데이터 전송)** 모두에서 동일하게 측정한다. "처리 위치"는 **데이터의 1차 처리(ROI 탐지·집계 등)가 어디서 수행되는가**를 의미한다(FEEDBACK §2.4 반영하여 정의 일관화).
 | 시스템 | 전송 프로토콜 | 직렬화 | 처리 위치 | 비고 |
 |--------|-------------|--------|-----------|------|
 | **REST-Cloud** | HTTP/1.1 (TCP) | JSON | 클라우드 (원시 데이터 직송) | 베이스라인 |
 | **REST-Edge** | HTTP/2 (TCP) | JSON | 엣지 1차 처리 → 클라우드 | 기존 방식 |
 | **gRPC-H2** | HTTP/2 (TCP) | Protobuf | 엣지 1차 처리 → 클라우드 | 선행 연구 재확인 |
 | **gRPC-H3 (제안 ①)** | HTTP/3 (QUIC) | Protobuf | 엣지 1차 처리 → 클라우드 | **본 연구 통신 모듈** |
 | **gRPC-H3-Stream** | HTTP/3 (QUIC) | Protobuf | 엣지, 스트리밍 | 스트리밍 확장 (P2) |
 | **gRPC-H3-GW (제안 ②)** | HTTP/3 (QUIC) | Protobuf | 게이트웨이 경유 → 백엔드 | **본 연구 게이트웨이 아키텍처** |
 ### 5.2. 핵심 성능 지표 (KPI) 및 측정 방법
 FEEDBACK §2.5 권고에 따라 측정 방법·조건·게이트웨이의 자원 측정 단위를 명시한다.
 | 지표 | 설명 | 측정 방법 |
 |------|------|-----------|
 | **P50 / P95 / P99 Latency** | 응답 시간 분포 | 클라이언트 측 wall-clock 타임스탬프. **warm-up 200회 후 측정 시작**. |
 | **Throughput (RPS)** | 초당 처리 요청 수 | 정상 종료된 요청 수 / 측정 구간 길이. 측정 구간은 최소 30초 또는 N≥10000 요청 |
 | **Payload Size** | 단일 요청의 직렬화된 페이로드 크기 | tcpdump 캡처에서 application payload만 합산. TLS 오버헤드 포함 여부는 별도 ADR로 결정 |
 | **CPU / Memory** | 서버 측 자원 사용률 | `pidstat -p <pid> 1`로 1초 단위 샘플링, 측정 구간 평균과 분산 보고. **게이트웨이 시나리오는 게이트웨이 + 백엔드 합계와 개별값 모두 보고**(공정 비교를 위해). pprof는 핫스팟 분석에만 사용하며 자원 비교 KPI에는 사용하지 않음 |
 | **Connection Overhead** | 연결 수립 비용 | 첫 요청 vs. 재사용 요청 latency 차이 (10회 평균) |
 | **0-RTT Resumption** | QUIC 0-RTT 재연결 효과 | 세션 캐시 적용 후 첫 요청 latency (QUIC only) |
 | **HoL Blocking 내성** | 패킷 손실이 다른 스트림에 미치는 영향 | 병렬 스트림 4개 동시 전송 중 1개 스트림 강제 손실 시 나머지 3개의 latency |
 ### 5.3. 네트워크 조건 매트릭스
 QUIC의 HoL Blocking 해소 효과를 분명히 드러내기 위해 손실 조건을 다양화했다(FEEDBACK §2.7 반영). TCP의 rapid recovery로 가려지는 1% 영역과 본격 효과가 드러나는 3–5% 영역을 모두 포함한다.
 | 조건 | 지연 | 패킷 손실 | 용도 |
 |------|------|-----------|------|
 | Ideal | 0 ms | 0 % | 베이스라인 |
 | LAN | 1 ms | 0 % | 로컬 엣지 |
 | WAN-Low | 50 ms | 0 % | 일반 클라우드 |
 | WAN-High | 200 ms | 0 % | 원거리 클라우드 |
 | **Lossy-1** | 50 ms | **1 %** | 약한 손실 (TCP rapid recovery 영역) |
 | **Lossy-3** | 50 ms | **3 %** | 중간 손실 (HoL Blocking 효과 본격화) |
 | **Lossy-5** | 100 ms | **5 %** | 강한 손실 (모바일/원거리 무선 환경) |
 ### 5.4. 시나리오 정의 및 시나리오별 KPI 가중치
 §1.4에서 분류한 두 트래픽 종류에 대해 다음 워크로드를 사용한다. **시나리오마다 지배적인 KPI가 다르므로**, 결과 해석 시 표의 "주요 KPI"를 우선 기준으로 삼는다(FEEDBACK §2.8 반영).
 | 시나리오 | 페이로드 | 호출 패턴 | 동시성 | 주요 KPI | 보조 KPI |
 |----------|----------|----------|--------|---------|---------|
 | **① AI Agent RPC** | 1–8 KB 작은 요청/응답 | Unary, 짧은 burst 반복 | 격리 에이전트 N=10/50/100 | **Connection Overhead**, **0-RTT Resumption**, P50/P95 Latency, RPS | HoL Blocking 내성 |
 | **② IoT 데이터 전송** | 64 KB ~ 2 MB | Unary + Streaming | 디바이스 N=10/50 | **Throughput**, P95/P99 Latency, **Payload Size**, **HoL Blocking 내성** (Lossy 조건) | Connection Overhead |
 > **주의**: AI Agent RPC 시나리오에서 Payload Size는 직렬화 효율(Protobuf vs JSON)이 latency를 거의 좌우하지 않는 영역(수 KB)이다(직렬화 시간이 RTT보다 두세 자릿수 작음). 따라서 보고는 하되 결론의 핵심 근거로 사용하지 않는다. 이 시나리오의 핵심 차별 요인은 **연결 수립 비용**이다.
 시나리오별 구체 워크로드 파라미터(이미지 해상도, RPS 목표, burst 크기 등)는 `docs/decisions/`의 ADR로 별도 고정한다.
 ### 5.5. 통계적 유의성 확보 계획
 FEEDBACK §4.3을 반영하여 다음 원칙을 따른다. (단순한 `count=5`는 평균/분산 추정에 부족하다는 지적을 수용.)
 | 항목 | 방침 |
 |------|------|
 | **반복 횟수** | 각 (시스템 × 네트워크 조건 × 시나리오) 조합당 최소 **30회 반복**. Lossy-3, Lossy-5는 분산이 크므로 **50회**로 증가 |
 | **Warm-up** | 측정 전 동일 시스템에 200회 호출하여 JIT/캐시/연결 초기화 효과 안정화 |
 | **신뢰 구간** | 모든 요약값에 **95% 신뢰 구간** 동반 보고. percentile은 percentile bootstrap, 평균은 Student's *t* |
 | **Outlier 처리** | Tukey's fence(Q3 + 1.5×IQR 초과)를 outlier로 표시하되 **제거하지 않음**. 보고에 outlier 비율 포함 |
 | **유의성 검정** | 두 시스템 간 차이의 유의성은 **Mann–Whitney U test**(latency 분포는 정규성 가정 어려움)로 판정, p<0.05 기준 |
 | **재현성** | 모든 측정은 ADR로 등록된 워크로드 파라미터를 사용. 측정 환경(호스트, OS, NIC, kernel 버전, tc 명령) 함께 기록 |
 ---
 ## 6. 코드 작성 정책
 본 절은 *정책*만 정의한다. 디렉터리 구조·네이밍·코드 패턴·예제 코드는 [`IMPLEMENTATION.md`](IMPLEMENTATION.md)를 따른다.
 ### 6.1. 계층 분리 (필수)
 ```
 Transport (QUIC/TCP) → Protocol (gRPC/HTTP) → Serialization (Protobuf/JSON) → Business Logic
 ```
 - 전송 계층은 **인터페이스로 추상화**하여 QUIC↔TCP를 동일 코드 경로로 교체 가능하게 한다 (벤치마크 공정성 보장)
 - 게이트웨이는 *외부 IoT 프로토콜 ↔ gRPC Protobuf 변환*과 *서비스 라우팅*만 담당한다
 - gRPC 서버 구현은 비즈니스 로직과 분리되어야 한다
 ### 6.2. 컨텍스트 전파
 모든 RPC 함수는 `context.Context`를 첫 번째 인수로 받는다. **타임아웃은 클라이언트에서 설정**하고 서버는 컨텍스트 취소를 존중한다.
 ### 6.3. 에러 처리
 gRPC 에러는 `google.golang.org/grpc/status` 패키지의 표준 코드를 사용한다.
 ### 6.4. 측정 가능성 (필수)
 **모든 신규 RPC 구현은 latency 측정이 가능해야 한다.** 인터셉터(`internal/middleware/metrics.go`)를 활용하거나, 직접 측정이 필요한 경우 명시적으로 기록한다.
 > **측정 도구의 observer effect** (FEEDBACK §2.6 반영): 인터셉터의 `time.Now()` 호출과 metric 기록은 측정값에 마이크로초 단위 bias를 추가한다. 본 연구는 모든 비교군에 *동일한 인터셉터*를 적용하므로 **상대 비교는 유효**하지만, **절대값**은 인터셉터를 비활성화한 별도 측정으로 추정 보정값을 산출하여 함께 보고한다. AI Agent 시나리오처럼 latency 자체가 작은 영역에서는 이 bias가 비례적으로 커질 수 있으므로 절대값 해석에 주의한다.
 ### 6.5. 금지 사항
 - `gen/` 디렉터리 직접 수정 금지 — `.proto` 수정 후 재생성한다
 - `panic` 사용 금지 (초기화 코드 제외)
 - 전역 변수로 설정 관리 금지 — `config` 구조체를 사용한다
 - 미사용 의존성 추가 금지 — `go mod tidy` 후 커밋
 ---
 ## 7. 연구 기록 규칙
 ### 7.1. 실험 결과
 `benchmarks/results/YYYY-MM-DD/` 디렉터리에 시나리오별 JSON 결과와 `summary.md`를 함께 저장한다.
 ```
 benchmarks/results/2026-05-07/
 ├── unary_ideal.json
 ├── unary_wan_200ms.json
 ├── streaming_wan_200ms.json
 ├── lossy3_wan_50ms.json
 └── summary.md          # 해당 날짜 실험 요약 및 주요 발견사항
 ```
 각 JSON에는 raw latency 샘플 + 95% 신뢰구간 + outlier 비율(§5.5) + 측정 환경(host, kernel, tc 명령)을 함께 기록한다.
 ### 7.2. 설계 결정 (ADR)
 `docs/decisions/NNN-{title}.md` 형식으로 기록한다.
 ```markdown
 # NNN. {제목}
 ## 상태
 Accepted / Deprecated / Superseded by NNN
 ## 맥락
 왜 이 결정이 필요했는가?
 ## 결정
 무엇을 선택했는가?
 ## 대안
 고려했지만 선택하지 않은 것과 그 이유
 ## 결과
 이 결정으로 인해 생기는 트레이드오프
 ```
 §3.3의 주요 위험은 발생 시점 또는 mitigation 결정 시 ADR로 정식 등록한다.
 ### 7.3. 오픈 질문
 `docs/open-questions.md`에 기록한다. 실험으로 답을 얻으면 해당 항목에 결과를 추가하고 닫는다.
 ### 7.4. 실패한 접근도 기록
 무엇을 시도했고, 왜 실패했으며, 무엇을 배웠는지 `docs/decisions/`에 포함한다. 실패 기록은 미래의 시간 낭비를 막는 자산이다.
 ### 7.5. 외부 피드백 반영
 [`FEEDBACK.md`](FEEDBACK.md)의 권고를 본 문서·`BACKGROUND.md`·`IMPLEMENTATION.md`에 반영할 때는, 어떤 항목을 어디에 어떻게 반영했는지 ADR 또는 본 문서의 해당 절에 *명시적으로 표기*한다 (현재 본 문서의 `(FEEDBACK §x.y 반영)` 표기 참조).
 ---
 ## 8. 참고 자료
 - **본 저장소 내부**
  - [`IMPLEMENTATION.md`](IMPLEMENTATION.md) — 구현 세부 사항 (디렉터리·네이밍·워크플로우·코드 패턴·멀티 에이전트 분담)
  - [`BACKGROUND.md`](BACKGROUND.md) — 연구 수행 배경 (발표 자료 추출 가능 형태)
  - [`참고/SGS/README.md`](참고/SGS/README.md) — 선행 연구
  - [`FEEDBACK.md`](FEEDBACK.md) — 외부 리뷰어의 비평 (긍정 평가 생략)
  - [`src/README.md`](src/README.md) — 데모 Terminal UI 빌드·실행 가이드
  - `docs/decisions/` — 설계 결정 기록 (ADR)
  - `docs/open-questions.md` — 미해결 탐색 주제
 - **외부 문서**
  - [RFC 9000 — QUIC](https://datatracker.ietf.org/doc/html/rfc9000)
  - [RFC 9114 — HTTP/3](https://datatracker.ietf.org/doc/html/rfc9114)
  - [gRPC 공식 문서](https://grpc.io/docs/)
  - [gRPC Go 빠른 시작](https://grpc.io/docs/languages/go/quickstart/)
  - [Protocol Buffers v3 언어 가이드](https://protobuf.dev/programming-guides/proto3/)
  - [google.golang.org/grpc Go pkg](https://pkg.go.dev/google.golang.org/grpc)
  - [quic-go GitHub](https://github.com/quic-go/quic-go)
 ---
 > 본 프로젝트는 연구 목적의 프로토타입입니다. 프로덕션 환경의 안정성·보안·가용성을 보장하지 않습니다.
@@ -0,0 +1,219 @@
 # PPT.md — 발표자료(슬라이드) 작성을 위한 프롬프트
 > 아래 프롬프트를 **발표자료 제작 도구(Canva, PowerPoint, Google Slides, Gamma 등)**에 입력하여 슬라이드를 생성하라.
 > 배경 문서: [`BACKGROUND.md`](BACKGROUND.md) — 연구 배경 및 필요성
 > 보조 문서: [`CLAUDE.md`](CLAUDE.md) — 제안 기법·평가 지표, [`참고/SGS/README.md`](참고/SGS/README.md) — 선행 연구
 ---
 ## 프롬프트 (아래 내용을 그대로 발표자료 도구에 입력)
 ---
 **주제**: AIoT 환경에서 gRPC over QUIC(HTTP/3) 고성능 통신 모듈 연구
 **발표 스타일**: 학술 세미나 발표. 청중은 AI/클라우드/네트워크에 대한 기본 지식을 가진 연구자·개발자. 각 슬라이드는 하나의 명확한 메시지를 전달할 것.
 **디자인**: 깔끔한 미니멀리즘. 다이어그램 중심. 텍스트는 bullet point 위주. 어두운 배경(다크 모드) 권장. 시스템별 식별 색상: REST-H2=rose, gRPC-H2=cyan, gRPC-H3=amber.
 **슬라이드 구성 (총 14장, 발표 시간 약 20~25분):**
 ---
 ### 1/14 — 표지 (Title Slide)
 - **제목**: AIoT 환경에서의 gRPC over QUIC 고성능 통신 모듈 연구
 - **부제**: AI Agent와 IoT를 위한 차세대 전송 프로토콜 실증
 - **발표자/소속/날짜**
 - 하단: "gRPC + HTTP/3 (QUIC) + Protocol Buffers v3"
 ---
 ### 2/14 — 연구 동기 (Motivation)
 - **제목**: 왜 지금 이 연구인가?
 - **핵심 메시지**: AI Agent 시대가 도래했지만, 통신 인프라는 1970년대의 TCP 위에 머물러 있다.
 - 3개의 키워드: **AI Agent 폭증**, **통신 병목**, **TCP의 한계**
 - 우측에 작은 아이콘 3개 (뇌전증 Agent, 네트워크, TCP 연결)
 ---
 ### 3/14 — AIoT 환경의 정의
 - **제목**: AIoT(Artificial Intelligence of Things)란?
 - **정의**: AI Agent(LLM 기반)와 IoT 디바이스가 동일한 엣지-클라우드 인프라에서 공존하며 상호작용하는 환경
 - **3가지 핵심 특징**:
  1. 이기종 트래픽 공존 — 수 KB RPC ~ 수 MB 이미지
  2. 엣지-클라우드 분산 처리
  3. 단대단(end-to-end) 응답성 요구
 - **예시 도식**: [센서] → [AI Agent 분석] → [액추에이터 제어]
 ---
 ### 4/14 — AI Agent의 통신 구조
 - **제목**: AI Agent는 어떻게 통신하는가?
 - **도식** (BACKGROUND.md §1.2 다이어그램 참조):
  - Main Agent ← LLM
  - 서브에이전트 / RAG(DB) / 도구(API) / IoT(센서)
 - **핵심 포인트**: "AI Agent의 **지능**은 LLM이 결정하지만, AI Agent의 **속도**는 통신 인프라가 결정한다"
 - **아이콘**: 4개의 화살표가 Main Agent에서 외부로 뻗어나가는 모양
 ---
 ### 5/14 — 트래픽 폭증의 세 가지 요인
 - **제목**: 트래픽 폭증을 가속하는 3가지 구조적 요인
 - **3열 레이아웃**:
 | ① 보안 격리 | ② 서브에이전트 아키텍처 | ③ 24/7 가동 |
 |---|---|---|
 | IPC → 네트워크 통신 전환 | 컨텍스트 한계 → 외부 호출 증가 | 동시간 Agent 수 급증 |
 | 수십~수백 컨테이너/노드 | 작업 복잡도 = 통신 체인 깊이 | RPS, 연결 비용, 내성 요구 |
 - **하단 정리**: "보안을 위한 격리가 오히려 통신 건수를 폭증시키는 역설"
 ---
 ### 6/14 — 기존 통신의 한계
 - **제목**: TCP(HTTP/2)의 근본적 한계
 - **표**:
 | 문제 | 설명 | AIoT 영향 |
 |---|---|---|
 | 연결 수립 비용 | TCP(1RTT)+TLS(1-2RTT)=2-3RTT | 빈번한 단발성 RPC에서 latency 증가 |
 | HoL Blocking | 한 스트림 패킷 손실 → 모든 스트림 지연 | 무선 환경, 다중 동시 RPC 성능 저하 |
 | 연결 고정 | IP/포트 변경 시 연결 단절 | 모바일 IoT, NAT rebinding 취약 |
 - **강조**: "HTTP/2 멀티플렉싱의 HoL Blocking 문제가 특히 심각"
 - TCP는 1970년대 설계 → 현대 AIoT 환경에 부적합
 ---
 ### 7/14 — QUIC(HTTP/3)의 등장
 - **제목**: QUIC(HTTP/3) — 차세대 전송 프로토콜
 - **왼쪽**: TCP vs QUIC 연결 수립 비교 다이어그램
  - TCP: 3-way handshake + TLS = 2-3 RTT
  - QUIC: 0-RTT (두 번째 연결부터)
 - **오른쪽 표**:
 | QUIC 특성 | 개선점 | AIoT 효용 |
 |---|---|---|
 | 0-RTT 연결 | 키 캐싱 → 재연결 0-RTT | 격리 Agent 간 RPC latency 감소 |
 | 스트림 독립성 | 각 스트림 독립 흐름 제어 | 무선 IoT, 다중 RPC 성능 유지 |
 | 연결 마이그레이션 | Connection ID 기반 | 네트워크 전환에도 연결 유지 |
 | 내장 암호화 | TLS 1.3 통합 | 보안 통신 기본 적용 |
 - **강조**: "QUIC은 UDP 위에서 HoL Blocking을 근본적으로 해결"
 ---
 ### 8/14 — Timeliness & Gap
 - **제목**: 왜 지금 이 연구인가?
 - **웹/인프라 레벨**: HTTP/3 도입 활발 (Nginx, Cloudflare, Chrome 등)
 - **gRPC 레벨**: 아직 stable 미도달, AIoT 환경 실증 부재
 - **Gap 다이어그램**:
  ```
  [웹 서버/브라우저/CDC] ← HTTP/3 이미 지원
  [gRPC over QUIC] ← PoC만 존재
  [AIoT 환경 실증] ← ★ 우리 연구 (Gap을 메움)
  ```
 - **하단**: "인프라는 준비되었지만, AIoT 워크로드에 대한 gRPC-QUIC 실증은 아직 없다"
 ---
 ### 9/14 — 기반 선행 연구 (SGS)
 - **제목**: 선행 연구 — 스마트팜 해충 탐지 기반 gRPC vs REST
 - **실험 구성**:
  - Edge Controller(N150) → ROI 탐지(AMD Ryzen AI 9) → Cloud(GCP)
  - 3-way 비교: Cloud REST / Edge REST / Edge gRPC
 - **핵심 발견**:
  1. ✅ gRPC(Protobuf) > REST(JSON) — 응답 시간·데이터 전송량 우수
  2. ✅ 엣지 처리 > 클라우드 처리 — 고지연 환경에서 특히 효과적
  3. ✅ gRPC + 엣지 조합 최상
 - **향후 연구 제안 중 본 연구의 방향**:
  → ① **HTTP/3(QUIC) 기반 gRPC** (본 연구)
  → ② 스트리밍 패턴 (P2)
  → ③ LLM 라우팅 (범위 밖)
 ---
 ### 10/14 — 선행 연구 대비 차별성
 - **제목**: 본 연구의 차별성
 - **비교 표**:
 | 항목 | 선행 연구(SGS) | 본 연구 |
 |---|---|---|
 | 전송 계층 | HTTP/2 (TCP) | **HTTP/3 (QUIC) 추가** |
 | 시나리오 | 스마트팜 단일 | **IoT + AI Agent RPC 이중** |
 | 게이트웨이 | 개념 제시 | **구현·정량 검증** |
 | 평가 지표 | 응답 시간, 전송량 | **+ 0-RTT, HoL 내성, 연결 마이그레이션** |
 | 비교 시스템 | 3개 | **6개** |
 - **강조**: 단순 QUIC 적용이 아닌, **AIoT 도메인 특화 실증 연구(domain-specific empirical study)**
 ---
 ### 11/14 — 연구 목표
 - **제목**: 연구 목표 및 범위
 - **P0 목표 3가지**:
  1. 🎯 gRPC over QUIC 통신 모듈 구현 (Go 기반)
  2. 🎯 gRPC 엣지 게이트웨이 (프로토콜 변환 + 라우팅)
  3. 🎯 6-way 정량 성능 비교
 - **두 평가 시나리오**:
  - ① AI Agent RPC (1-8KB, Unary, burst)
  - ② IoT 데이터 전송 (64KB-2MB, Streaming)
 - **성공 기준**: 30회 반복, 95% CI, P50/P95/P99, RPS, HoL 내성 정량 측정
 ---
 ### 12/14 — 평가 설계
 - **제목**: 평가 시나리오 및 KPI
 - **6개 비교 시스템**:
  REST-Cloud / REST-Edge / gRPC-H2 / **gRPC-H3 (제안①)** / gRPC-H3-Stream / **gRPC-H3-GW (제안②)**
 - **5가지 네트워크 조건**: Ideal, LAN, WAN-Low(50ms), WAN-High(200ms), Lossy(50ms+1~5%)
 - **KPI**: P50/P95/P99 Latency · RPS · Connection Overhead · 0-RTT · HoL Blocking 내성 · Payload Size
 - **통계적 유의성**: Mann-Whitney U test, Tukey outlier, 최소 30회 반복
 ---
 ### 13/14 — 현재까지 진행 상황
 - **제목**: 구현 현황 (Phase 0 — Demo UI)
 - **완료**:
  - Bubble Tea 기반 Terminal UI (3개 시스템 비교)
  - mock 시뮬레이터 (param 반응형 추세 생성)
  - 3개 시나리오 (Small-Many / Small-Medium / Large-Few)
  - 프로젝트 문서 체계 (CLAUDE.md, IMPLEMENTATION.md, ARCHITECTURE.md 등)
 - **진행 중 / 예정**:
  - Phase 1: gRPC 서버·QUIC 전송 계층 구현
  - Phase 2: 게이트웨이 + tc 네트워크 시뮬레이션
  - Phase 3~5: Mininet + 실측 벤치마크
 - **스크린샷** (가능하면): TUI 메뉴/설정/결과 화면 이미지 삽입
 ---
 ### 14/14 — 마무리 (Closing)
 - **핵심 메시지** (큰 글씨):
  > AI Agent 시대가 요구하는 고빈도·저지연·고신뢰 통신을 위해,
  > TCP 기반 HTTP/2의 한계를 QUIC(HTTP/3)으로 극복하는
  > gRPC 통신 모듈을 설계·구현하고, AIoT 환경에서 실증한다.
 - **연구의 성격**: 새로운 프로토콜의 발명이 아닌, **AIoT 도메인 특화 실증 연구**
 - **감사 인사**
 - **Q&A**
 ---
 ### 발표자 노트
 | 슬라이드 | 시간 | 핵심 전달 사항 |
 |----------|:----:|---------------|
 | 2~3 | 3분 | "AI Agent가 많아지는데 통신이 느리면 전체 시스템이 느려진다" — 문제 인식 |
 | 4~5 | 4분 | 구체적으로 왜 통신이 폭증하는지 — 세 가지 요인을 이해시킬 것 |
 | 6~7 | 4분 | TCP의 한계 → QUIC이 어떻게 해결하는지 — 기술적 이해 |
 | 8~9 | 3분 | "이미 QUIC은 인프라에 도입됐는데 gRPC에는 아직" — Gap 설명 |
 | 10~12 | 5분 | 연구의 차별성과 구체적 범위 — "무엇을, 어떻게 측정할 것인가" |
 | 13 | 2분 | 현재 어디까지 왔는지 — 신뢰감 형성 |
 | 14 | 1분 | 핵심 메시지 요약 |
 ### 주의사항
 1. 슬라이드에 텍스트를 너무 많이 넣지 말 것 — 각 슬라이드는 5~7개 bullet point 이내
 2. 표와 다이어그램을 적극 활용할 것 (특히 TCP vs QUIC 비교, 통신 구조)
 3. 시스템별 식별 색상 일관성 유지 (REST-H2=rose, gRPC-H2=cyan, gRPC-H3=amber)
 4. "AIoT" 개념은 슬라이드 3에서 정의하므로 이후 슬라이드에서 재정의 불필요
 5. 본 연구의 novelty는 "gRPC over QUIC의 발명"이 아닌 "AIoT 도메인에서의 실증"임을 반복 강조
 6. 참고/SGS/README.md의 구체적 성능 수치는 아직 확보되지 않았으므로, "결과는 본 연구에서 재현·확장 예정"으로 표기
@@ -0,0 +1,119 @@
 # gRPC를 이용한 지능형 IoT 마이크로서비스의 통신 효율성 향상
 ---
 ### 초록 (Abstract)
 사물인터넷(IoT) 기술이 발전함에 따라, 방대한 양의 데이터를 실시간으로 처리할 수 있는 지능형 서비스에 대한 요구가 빠르게 증가하고 있다. 그러나 전통적인 모놀리식 및 클라우드 중심 아키텍처는 수많은 분산 장치 간의 통신을 처리할 때 확장성, 네트워크 지연, 운영 효율성 측면에서 어려움을 겪는다. 이러한 문제들을 해결하기 위해, 본 논문은 고효율 통신을 위해 gRPC를 활용하는 지능형 IoT 서비스를 위한 새로운 마이크로서비스 아키텍처를 제안한다. 제안하는 시스템은 유연한 배포 및 관리를 위한 컨테이너화된 서비스 모듈, 사용자 친화적인 운영을 위한 중앙 집중식 대시보드, 그리고 자원 최적화를 위한 지능형 라우팅 메커니즘을 결합한다. 스마트팜 해충 탐지 시나리오에서 제안하는 gRPC 기반 접근 방식과 기존의 REST API (HTTP/2) 시스템을 비교하는 성능 평가를 수행한다. 실험 결과, 제안된 아키텍처가 응답 시간과 데이터 전송량을 크게 감소시키는 것을 보여주며, 이는 확장 가능하고 응답성이 뛰어난 지능형 IoT 시스템을 구축하는 데 있어 gRPC의 효과를 강조한다.
 **키워드**: `IoT`, `마이크로서비스`, `gRPC`, `HTTP/2`, `컨테이너 오케스트레이션`, `지능형 라우팅`
 ---
 ### 1. 서론 (Introduction)
 현대 사물인터넷(IoT) 서비스의 패러다임은 단순한 데이터 수집에서 진보된 지능형 서비스를 제공하는 것으로 변화하고 있다. 이러한 발전은 실시간 데이터 처리를 효율적으로 처리하고, 수많은 장치에 대한 확장성을 보장하며, 자원 활용을 최적화할 수 있는 아키텍처를 필요로 한다. 그러나 전통적인 중앙 집중형 클라우드 기반 아키텍처는 네트워크 지연 및 확장성 병목 현상으로 인해 이러한 요구사항을 충족시키는 데 종종 어려움을 겪는다.
 이러한 한계를 극복하기 위해 마이크로서비스 아키텍처는 유망한 해결책 중 하나이다. IoT 환경에서는 수많은 장치가 수집된 데이터를 기반으로 자율적인 작업을 수행하기 위해 상호 작용한다. 데이터 처리 및 의사결정과 같은 핵심 기능이 클라우드에만 의존할 경우, 특히 네트워크 장애 발생 시 상당한 비용 및 안전 문제를 야기할 수 있다. 마이크로서비스 아키텍처는 이러한 기능의 분산을 가능하게 하여 로컬 데이터 처리 및 저장을 지원한다. 예를 들어, AI 추론과 같이 계산 집약적인 작업은 강력한 엣지 노드에서 실행하고, 더 간단한 데이터 집계 작업은 사양이 낮은 컨트롤러에서 처리할 수 있다. 이러한 분산은 최적의 자원 할당을 가능하게 한다. 그러나 이러한 분산 서비스를 배포하고 관리하려면 상당한 기술 전문 지식이 필요하다. 따라서 사용 편의성을 보장하기 위해 중앙 집중식 관리 대시보드가 매우 중요하다.
 또한, 종종 자원이 제한된 장치로 구성된 IoT 환경에서는 통신 효율성이 가장 중요하다. CoAP 및 MQTT와 같은 프로토콜이 이러한 환경을 위해 개발되었지만, 기존 지능형 사물인터넷 서비스 시스템에 통합하는 것은 복잡할 수 있다. HTTP/1.1 또는 HTTP/2를 통한 REST API와 같은 기존 통신 방법은 텍스트 기반 데이터 형식(예: JSON)과 요청-응답 패턴으로 인해 상당한 오버헤드를 발생시키며, 이는 IoT에서 흔히 발생하는 연속적인 데이터 스트림에 비효율적이다.
 IoT 마이크로서비스에 대한 이전 연구는 주로 클라우드 또는 엣지 컴퓨팅 패러다임 내에서 아키텍처 패턴과 서비스 오케스트레이션에 중점을 두었다. 통신 프로토콜을 비교하는 연구들은 텍스트 기반 프로토콜에 비해 바이너리 프로토콜의 이점을 입증했다. 그러나 gRPC 기반 통신, 컨테이너화된 마이크로서비스, 지능형 라우팅 메커니즘을 결합한 통합 아키텍처를 제시하고, 실제적인 IoT 시나리오에서 구체적인 성능 비교를 통해 이를 검증한 연구는 거의 없다. 우리 연구는 이러한 통합 시스템을 제안하고 평가함으로써 이 격차를 메우는 것을 목표로 한다.
 본 논문은 이러한 문제들을 해결하기 위해 HTTP/2 기반 gRPC 통신 프레임워크와 컨테이너 기술을 결합한 지능형 IoT 서비스를 위한 새로운 아키텍처를 제안한다. 본 연구의 주요 기여는 다음과 같다.
 -   통신 성능과 관리 효율성을 향상시키는 IoT 마이크로서비스 아키텍처 제안
 -   작업을 효과적으로 분산하여 시스템 자원을 최적화하는 지능형 라우팅 메커니즘 설계
 -   IoT 환경에서 기존 REST API 대비 gRPC 기반 접근 방식의 우수성을 입증하는 정량적 성능 평가
 ---
 ### 2. 연구 배경 (Background Surveys)
 #### 2.1. 마이크로서비스 아키텍처 (Microservice Architecture)
 마이크로서비스 아키텍처는 애플리케이션을 느슨하게 결합되고 독립적으로 배포 가능한 서비스의 모음으로 구성한다. 각 서비스는 특정 비즈니스 기능을 담당하고 네트워크를 통해 다른 서비스와 통신한다. 이 접근 방식은 향상된 확장성, 장애 격리, 기술 이질성 등 IoT 환경에서 상당한 이점을 제공한다. Docker와 같은 기술을 사용하여 서비스를 컨테이너화함으로써 각 서비스를 종속성과 함께 패키징하여 다른 환경 간의 일관성을 보장하고 배포 및 관리를 단순화할 수 있다. 이러한 모듈성은 유연하고 복원력 있는 IoT 시스템을 구축하는 데 필수적이다.
 #### 2.2. IoT 통신 프로토콜 비교
 많은 IoT 시스템에서 HTTP 기반의 REST API가 통신의 사실상 표준이었다. 그러나 장황한 헤더와 잦은 요청 메시지 전달로 인한 높은 오버헤드가 발생한다. HTTP/2가 멀티플렉싱을 통해 Head-of-Line 블로킹과 같은 일부 문제를 해결했지만, 스트리밍 데이터에 대한 요청-응답 모델의 근본적인 비효율성은 여전히 남아있다.
 Google에서 개발한 고성능 RPC 프레임워크인 gRPC는 HTTP/2를 전송 프로토콜로 사용한다. 하지만 기존 REST API에 비해 몇 가지 주요 이점을 제공한다.
 -   **프로토콜 버퍼 (Protocol Buffers)**: gRPC는 바이너리 직렬화 형식인 프로토콜 버퍼를 사용하여 JSON보다 더 작고 처리 속도가 빠르다.
 -   **멀티플렉싱 (Multiplexing)**: 단일 TCP 연결을 통해 여러 요청과 응답을 보낼 수 있는 HTTP/2의 기능을 완전히 활용하여 지연 시간을 줄인다.
 -   **스트리밍 (Streaming)**: gRPC는 양방향 스트리밍을 기본적으로 지원하여 IoT 장치에서 들어오는 연속적인 데이터 흐름을 보다 효율적으로 처리할 수 있다.
 이러한 특징들은 gRPC를 성능이 중요한 IoT 애플리케이션에 매우 적합한 선택으로 만든다.
 ---
 ### 3. 제안 시스템 아키텍처 (Proposed System Architecture)
 #### 3.1. 제안 시스템 아키텍처
 제안하는 시스템은 크게 네 가지 핵심 요소, 즉 1) IoT 장치(센서/액추에이터), 2) 컨테이너화된 지능형 서비스 모듈, 3) gRPC 기반 통신 계층, 그리고 4) 중앙 관리 대시보드로 구성된다. 중앙 관리 대시보드는 서비스의 배포, 모니터링 및 관리를 위한 통합된 사용자 인터페이스를 제공한다. 각 지능형 서비스 모듈은 컨테이너 기술을 통해 패키징되어, 엣지 컨트롤러, 엣지 에이전트, 클라우드 서버와 같은 다양한 물리적 엔티티에 유연하게 배포될 수 있다. Edge 환경의 모든 서비스 간의 통신은 gRPC 계층을 통해 이루어져 데이터 교환의 효율성을 극대화한다.
 본 논문에서 제안하는 시스템의 설계 구조는 아래 그림과 같이 CPND(Client-Platform-Network-Device) 계층으로 구분하여 설명할 수 있으며, 본 연구는 주로 플랫폼(Platform)과 네트워크(Network) 계층에 중점을 둔다.
 ![전체 시스템 구성도](<README.assets/images/Screenshot 2025-09-25 at 8.38.06 AM.png>)
 플랫폼 계층은 클라우드 엔티티(Cloud entity), 엣지 엔티티(Edge entity), 그리고 엣지 에이전트(Edge agent)의 세 가지 주요 엔티티로 구성된다. 클라우드 엔티티는 서비스 제공자에게 서비스 배포를 위한 웹 UI, 시스템 구성요소 간 데이터 교환을 위한 API 인터페이스, 사용자 인증 및 인가를 위한 Authorization 서버, 그리고 클라우드 모듈의 상태를 점검하는 모니터링 엔진을 포함한다. 또한, 배포된 서비스 컨테이너를 관리하는 컨테이너 허브와 클라우드에서 실행되는 서비스를 총괄하는 서비스 관리 모듈로 구성된다.
 엣지 엔티티는 사물인터넷 서비스에서 발생하는 데이터를 저장하고 관리하는 역할을 수행하며, 높은 컴퓨팅 성능보다는 안정적인 저장 용량과 빠른 네트워크 성능을 확보하는 데 중점을 둔다. 이는 클라우드로부터 배포된 서비스 컨테이너를 관리하는 컨테이너 관리 모듈, 등록된 엣지 에이전트와 해당 에이전트에서 동작하는 서비스를 관리하며 작업 라우팅(Task Routing) 기능을 수행하는 엣지 에이전트 관리 모듈, 그리고 서비스 관리자를 위한 웹 인터페이스 및 gRPC 기반의 API 인터페이스로 구성된다.
 엣지 에이전트는 수집된 데이터를 실질적으로 처리하는 서비스를 실행하는 엔티티이다. 이는 엣지 엔티티로부터 제어 메시지를 수신하여 자신의 상태를 보고하고 설정을 변경하는 API 인터페이스와, 해당 에이전트에서 동작하는 서비스의 생명주기를 제어하고 관리하는 서비스 관리 모듈을 포함한다.
 네트워크 계층의 핵심은 gRPC 기반 게이트웨이로, 엣지 환경에서 생성되는 데이터와 제어 메시지의 효율적인 전송을 담당한다. 이 게이트웨이는 센서 게이트웨이와 엣지 인터페이스 변환기로 구성된다. 센서 게이트웨이는 CoAP, MQTT 등 다양한 IoT 응용 프로토콜을 지원하여 센서 및 액추에이터로부터 데이터를 수집하고 제어 메시지를 전달한다. 엣지 인터페이스 변환기는 gRPC 기반 통신을 위해 메시지를 효율적인 바이너리 형태로 변환하고 직렬화하는 기능을 수행하며, 주로 엣지 엔티티의 API 인터페이스와 통신하는 개체에서 활용된다.
 <!-- #### 3.4. 작업 라우팅 메커니즘
 자원 사용을 최적화하고 응답 시간을 개선하기 위해 작업 라우팅 메커니즘을 도입한다. 스마트팜 해충 탐지 시나리오를 통해 이를 설명한다. 프로세스는 두 단계로 나뉜다.
 1.  **관심 영역(ROI) 탐지**: 엣지 에이전트에서 실행되는 초기 경량 서비스가 들어오는 이미지를 분석하여 해충이 있을 가능성이 있는 관심 영역(ROI)을 탐지한다.
 2.  **상세 분석**: ROI가 탐지되면, 해당 이미지의 잘라낸 부분만 더 강력하고 계산 집약적인 분석 서비스(더 강력한 엣지 노드 또는 클라우드에 있을 수 있음)로 전달되어 정밀한 해충 식별을 수행한다.
 이러한 단계는 사용자가 중앙 관리 대시보드를 통해 손쉽게 정의할 수 있다. -->
 ---
 ### 4. 성능 평가 (Performance Evaluation)
 #### 4.1. 실험 환경
 테스트베드는 다음 하드웨어 및 소프트웨어로 구성되었다.
 -   **엣지 컨트롤러**: Intel N150 CPU, 32GB RAM, 4TB RAID 스토리지. 데이터 수집 담당.
 -   **엣지 에이전트 개체**: AMD Ryzen AI 9 HX CPU, 32GB RAM. 1단계 ROI 탐지 서비스 실행.
 -   **클라우드 개체**: Google Cloud Platform. 2단계 상세 분석 서비스 호스팅.
 네트워크 환경은 ASUS 라우터를 사용하여 구축되었으며, 실제 시나리오를 시뮬레이션하기 위해 Linux `tc` (트래픽 제어) 유틸리티를 사용하여 지연 시간과 같은 네트워크 조건을 제어했다.
 #### 4.2. 평가 시나리오
 동일한 '스마트팜 해충 탐지' 작업을 수행하는 세 가지 다른 시스템 구성을 평가했다.
 1.  **클라우드 기반 (HTTP/2) 데이터 처리**: 엣지 컨트롤러가 전체 원시 데이터를 표준 REST API(HTTP/2)를 사용하여 처리를 위해 클라우드 개체로 전송한다. 이 모델은 강력한 클라우드 자원을 활용하지만 네트워크 지연에 민감하다.
 2.  **엣지 기반 (HTTP/2) 데이터 처리**: 엣지 컨트롤러가 데이터를 엣지 에이전트로 보내고, 에이전트가 ROI 탐지를 수행한 후 ROI만 상세 분석을 위해 클라우드 개체로 전달한다(REST API 사용). 이는 데이터 전송을 줄이지만 로컬 처리 시간이 약간 더 길어질 수 있다.
 3.  **엣지 기반 (gRPC) 데이터 처리**: 이것이 우리가 제안하는 시스템이다. 엣지 기반 (HTTP/2) 모델과 동일한 로직을 따르지만 모든 서비스 간 통신에 gRPC를 사용한다.
 #### 4.3. 평가 지표
 다음과 같은 핵심 성능 지표를 측정했다.
 -   **응답 시간 (Response Time)**: 엣지 컨트롤러의 초기 요청부터 최종 분석 결과를 받을 때까지 경과된 총 시간.
 -   **데이터 전송량 (Data Transmission Volume)**: 단일 작업에 대해 개체 간에 전송된 총 네트워크 데이터 크기.
 #### 4.4. 결과 및 분석
 그래프로 제시될 실험 결과는 다음과 같은 경향을 보일 것으로 예상된다. 첫째, 높은 지연 시간의 네트워크 조건에서 두 엣지 기반 시스템은 순수 클라우드 기반 시스템에 비해 훨씬 낮은 응답 시간을 보여 엣지 처리의 이점을 확인할 것이다. 이상적인 네트워크 조건에서는 2단계 로직으로 인해 엣지 기반 시스템의 처리 시간이 약간 더 길 수 있지만, 그 차이는 미미할 것으로 예상된다.
 가장 중요한 것은, gRPC 기반 시스템이 응답 시간과 데이터 전송량 모두에서 HTTP/2 REST 기반 시스템을 능가할 것으로 예상된다는 점이다. 이러한 개선은 gRPC가 효율적인 바이너리 직렬화(프로토콜 버퍼)와 헤더 압축과 같은 HTTP/2 기능을 사용하여 통신 오버헤드를 줄이기 때문이다. 결과는 제안된 아키텍처가 지능형 IoT 애플리케이션에 실질적인 성능 이점을 제공함을 검증할 것이다.
 ---
 ### 5. 결론 및 향후 연구 (Conclusion and Future Work)
 본 논문에서는 지능형 IoT 서비스의 통신 효율성과 확장성을 향상시키기 위해 설계된 gRPC 기반 마이크로서비스 아키텍처를 제안했다. 컨테이너화된 모듈, 사용자 친화적인 관리 대시보드, 지능형 라우팅 메커니즘을 통합함으로써 우리 시스템은 기존 IoT 아키텍처의 주요 한계를 해결한다. 성능 평가는 우리 접근 방식의 효과를 확인했으며, gRPC와 엣지 컴퓨팅을 활용하면 기존의 클라우드 중심, REST 기반 시스템에 비해 응답 시간과 네트워크 부하가 크게 감소함을 보여주었다. 이 연구는 차세대 고성능 IoT 애플리케이션 구축을 위한 기본 기술로서 gRPC 기반 마이크로서비스의 잠재력을 강조한다.
 향후 연구는 여러 방향으로 진행될 것이다. 첫째, 특히 패킷 손실이 높은 불안정한 네트워크 환경에서 성능을 더욱 향상시키기 위해 HTTP/3 기반 gRPC의 채택을 탐색할 계획이다. 둘째, 실시간 연속 데이터 처리 작업을 더 잘 지원하기 위해 다양한 gRPC 스트리밍 패턴(클라이언트 측, 서버 측, 양방향)을 통합하도록 연구를 확장할 것이다. 마지막으로, 실시간 시스템 상태 및 서비스 요구사항에 따라 동적이고 적응적인 라우팅 결정을 내리기 위해 로컬 대규모 언어 모델(LLM)을 활용하는 더 정교한 작업 라우팅 메커니즘을 개발하는 것을 목표로 한다.