# 연구 수행 배경

> 본 문서는 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. 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 + 엣지 처리 조합이 최상의 성능을 보임

**선행 연구가 제안한 향후 연구 방향**:
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 스택이 두 시나리오를 모두 최적화할 수 있는 이유에 대한 논리적 설명
- "범위가 너무 넓다"는 비판에 대한 대비 논리