lab/grpc_performance_comparison
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects 1 Releases Wiki Activity
Files
main
grpc_performance_comparison/assets/202060508-seminar/PPT.md
T
Hermes Agent 91527fd56d docs: 260508 세미나를 위한 프롬프트 추가
2026-05-07 04:42:50 +00:00

9.8 KiB
Raw Permalink Blame History

PPT.md — 발표자료(슬라이드) 작성을 위한 프롬프트

아래 프롬프트를 **발표자료 제작 도구(Canva, PowerPoint, Google Slides, Gamma 등)**에 입력하여 슬라이드를 생성하라. 배경 문서: BACKGROUND.md — 연구 배경 및 필요성 보조 문서: CLAUDE.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의 구체적 성능 수치는 아직 확보되지 않았으므로, "결과는 본 연구에서 재현·확장 예정"으로 표기
Reference in New Issue View Git Blame Copy Permalink