# 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의 구체적 성능 수치는 아직 확보되지 않았으므로, "결과는 본 연구에서 재현·확장 예정"으로 표기