diff --git a/FEEDBACK.md b/FEEDBACK.md
new file mode 100644
index 0000000..9ccaed5
--- /dev/null
+++ b/FEEDBACK.md
@@ -0,0 +1,238 @@
+# FEEDBACK.md — 문서 전반에 대한 구체적 비평
+
+> 칭찬 없음. 개선이 필요한 지점만 기록.
+> 대상: BACKGROUND.md, CLAUDE.md, IMPLEMENTATION.md, 참고/SGS/README.md
+
+---
+
+## 1. BACKGROUND.md — 연구 배경
+
+### 1.1. 1.3절 학원 관리 서비스 예시는 부적절
+
+「AI Agent의 동작 위치」를 설명하다가 갑자기 「학원 관리 서비스」 구체 사례(hermes + ollama + supabase)가 등장한다. 이 예시는 연구자의 개인 경험(anecdotal evidence)일 뿐이며, 학술 연구 배경 문서의 톤과 거리가 멀다. 더 큰 문제는 이 예시가 「AI Agent가 외부 서비스와 통신한다」는 일반적 진술을 뒷받침하기에는 지나치게 특수하다는 점이다.
+
+→ 삭제하거나, AI Agent의 일반적 아키텍처 다이어그램(Agent → Tool → External Service)으로 대체.
+
+### 1.2. 2.2절 제목과 내용이 불일치
+
+제목: 「사람과 달리, 오래 일할수록 성능이 저하되는 AI Agent」
+
+하지만 내용은 전혀 그렇지 않다. 「컨텍스트 한계로 성능이 저하된다」는 것이 핵심인데, 「사람과 달리」라는 비교는 사실과 다르다. 사람도 오래 일하면 피로 누적으로 성능이 저하된다. 오히려 AI Agent는 「사람처럼」 오래 일할수록 성능이 저하되며, 그 원인이 컨텍스트 한계라는 점이 강조되어야 한다.
+
+→ 제목을 「컨텍스트 메모리 한계에 따른 AI Agent 성능 저하 문제」로 변경하고, 사람과의 비교는 빼는 것이 낫다.
+
+### 1.3. 3절 결론이 너무 빈약
+
+세 가지 추세를 정리한 후 「모두 다음으로 수렴한다」며 인용문 하나를 던지고 끝난다. 이 문서가 「연구 수행 배경」이라면, 이 추세들이 왜 「이 특정 연구(gRPC over QUIC)」로 이어지는지에 대한 논리적 연결 고리를 제공해야 한다.
+
+예: 세 가지 추세 → 통신 건수·빈도·규모 증가 → 기존 HTTP/2(TCP) 기반 gRPC의 한계 → QUIC이 해결하는 지점 → 본 연구의 필요성
+
+현재는 이 연결이 독자에게 맡겨져 있다.
+
+### 1.4. Timeliness argument 부재
+
+「왜 지금 이 연구인가」에 대한 설명이 없다. QUIC은 이미 HTTP/3 표준(RFC 9000, 2021)으로 채택된 지 오래다. gRPC over QUIC에 대한 논의와 실험(quic-go 커뮤니티, Microsoft MsQuic 등)도 이미 존재한다. 「시장/기술 환경의 어떤 변화가 이 연구를 지금 필요하게 만들었는가」에 대한 논리가 BACKGROUND.md에 없으면, 이 연구는 단순히 「QUIC이 나왔으니 적용해보자」 수준으로 보일 위험이 있다.
+
+---
+
+## 2. CLAUDE.md — 연구 방향·정책
+
+### 2.1. 선행 연구(SGS)와의 논리적 연결이 불완전
+
+1.4절에서 선행 연구가 제안한 세 가지 향후 연구(HTTP/3 기반 gRPC, 스트리밍 패턴, LLM 라우팅)를 언급한 후 「본 프로젝트는 이 중 HTTP/3 기반 gRPC의 도입을 실현하고」라고 한다.
+
+그런데 왜 이 세 가지 중 HTTP/3인가? 왜 스트리밍 패턴이나 LLM 라우팅은 제외되었는가? 「P0 vs P2」 우선순위로 나중에 암시되긴 하지만, 이 문서의 서술 순서(1.4 → 2.1)에서는 선택의 근거가 전혀 드러나지 않는다.
+
+→ 1.4에서 세 가지 중 HTTP/3을 선택한 이유를 최소 한 문장으로 명시.
+
+### 2.2. 제안 ② gRPC 엣지 게이트웨이의 novelty가 불분명
+
+2.2절의 게이트웨이는 「프로토콜 변환 + 정적 룰 기반 서비스 라우팅」을 수행한다. 그런데 이 두 기능은 이미 존재하는 개념이다. 프로토콜 변환 게이트웨이는 IoT 분야에서 수년간 사용되어 왔고, 정적 라우팅 테이블은 더 말할 것도 없다.
+
+「gRPC-QUIC 모듈을 사용해 백엔드와 통신한다」는 것이 게이트웨이의 핵심 novelty라면, 이는 결국 제안 ①의 통신 모듈을 게이트웨이에 적용한 것일 뿐, 게이트웨이 아키텍처 자체의 독창성은 아니다.
+
+→ 게이트웨이 제안의 독창성이 무엇인지(단순한 구현인지, 특정 아키텍처 패턴인지, 아니면 gRPC-QUIC 통합 자체인지)를 명확히 해야 한다. 현재 서술로는 「게이트웨이를 만들었다」는 사실만 전달될 뿐, 연구 기여로 인정받기 어렵다.
+
+### 2.3. 3.1절 P0 목표의 현실성
+
+P0 목표가 세 개다:
+1. gRPC over QUIC 통신 모듈 구현
+2. gRPC 엣지 게이트웨이 설계·구현
+3. 4-way(gRPC/HTTP3 vs gRPC/HTTP2 vs REST/HTTP2 vs REST/HTTP1.1) 정량 성능 비교
+
+이 중 1번(통신 모듈)이 병목이다. quic-go 위에 gRPC 전송 계층을 custom 구현하는 것은 난이도가 높고, 예상치 못한 문제(quic-go의 API 변경, gRPC transport interface와의 정합성, net.Conn 호환성 등)가 발생할 가능성이 크다. 3번(4-way 비교)도 4가지 전송 방식 각각에 대한 서버/클라이언트 구현과 동일 시나리오 보장이 필요하므로 결코 가볍지 않다.
+
+만약 1번에서 지연이 발생하면 2번(게이트웨이)과 3번(비교)이 함께 밀린다. 리스크 완화 계획(예: 3번에서 QUIC 구현이 늦어질 경우 HTTP/2까지만 먼저 측정)이 명시되어야 한다.
+
+→ P0 세 개를 모두 완료하는 데 필요한 예상 기간과, 각각의 dependency/리스크를 ADR 또는 별도 섹션으로 문서화.
+
+### 2.4. 5.1 비교 대상 시스템의 처리 위치 불일치
+
+| 시스템 | 처리 위치 |
+|--------|----------|
+| REST-Cloud | 클라우드 |
+| REST-Edge | 엣지 → 클라우드 |
+| gRPC-H2 | 엣지 → 클라우드 |
+| gRPC-H3 | 엣지 → 클라우드 |
+
+REST-Cloud만 「클라우드」로 되어 있다. REST-Cloud는 원시 데이터를 클라우드로 전송하는 베이스라인이고, 나머지는 엣지에서 1차 처리 후 클라우드로 전달하는 방식이라는 것은 이해하지만, 표만 보면 정의가 일관되지 않아 혼란을 준다.
+
+→ 「클라우드」를 「엣지 → 클라우드 (원시 데이터)」로 통일하거나, 비고란에 차이를 명시.
+
+### 2.5. 5.2 CPU/Memory 측정 방법이 부실
+
+「Go pprof + runtime.ReadMemStats」라고 되어 있지만:
+- pprof는 특정 시점의 snapshot(sampling)이라 전체 부하 패턴을 대표하지 않음
+- 여러 시스템(gRPC-H3, gRPC-H3-GW 등) 간 공정한 비교를 위한 측정 조건(부하 수준, 측정 시간, warm-up 여부)이 명시되지 않음
+- 게이트웨이 아키텍처는 서버 프로세스가 2개(gateway + backend)이므로 단일 서버와의 자원 비교가 공정하지 않음
+
+→ 측정 방법, 조건, 게이트웨이의 경우 자원 측정 단위(프로세스별? 합계?)를 명시.
+
+### 2.6. 6.4절 측정 인터셉터 자체의 overhead에 대한 논의 부재
+
+인터셉터로 latency를 측정하는 것은 좋은 접근이지만, 인터셉터 자체가 latency에 미치는 영향에 대한 논의가 없다. 인터셉터에서 time.Now() 호출 + 미터링 로직이 추가되면 측정값에 bias가 생긴다. 이 bias가 모든 비교군에 동일하게 적용된다면 상대 비교는 유효하지만, 절대값 해석 시 주의가 필요하다.
+
+→ 「측정 도구가 측정에 미치는 영향」(observer effect)에 대한 최소한의 고려를 문서에 포함.
+
+### 2.7. 5.3 Lossy 조건이 너무 약함
+
+Lossy 조건이 「50ms latency + 1% packet loss」인데, 이 정도 손실률에서는 TCP의 rapid recovery로도 대부분 복구된다. QUIC의 HoL blocking 장점이 유의미하게 드러나려면 최소 3~5% 손실률에서 테스트해야 한다.
+
+1%에서 QUIC과 HTTP/2의 차이가 통계적으로 유의미할지 불확실하다.
+
+→ 1%, 3%, 5% 세 가지 손실률 조건을 추가. 또는 Lossy-High 조건(100ms, 5%)을 P1으로라도 정의.
+
+### 2.8. AI Agent RPC 시나리오의 페이로드 크기 (1~8KB)
+
+이 페이로드 범위에서는 Protobuf vs JSON의 직렬화 차이가 latency에 큰 영향을 미치지 않을 가능성이 높다. 수 KB 수준에서는 직렬화 시간(마이크로초 단위)보다 연결 수립 비용과 네트워크 RTT가 지배적이다.
+
+즉, 이 시나리오에서 gRPC-H3의 장점은 「Protobuf가 빨라서」가 아니라 「QUIC의 0-RTT로 연결 수립이 빨라서」일 것이다. 그렇다면 Connection Overhead와 0-RTT Resumption이 주요 KPI인 것은 타당하지만, Payload Size는 이 시나리오에서 별 의미가 없다.
+
+→ Payload Size를 AI Agent RPC 시나리오의 주요 KPI에서 제외하고, 대신 Connection Overhead에 집중하는 것이 더 정확.
+
+---
+
+## 3. IMPLEMENTATION.md — 구현 세부 사항
+
+### 3.1. 가장 큰 기술 리스크: quic-go + gRPC transport interface 호환성
+
+이 프로젝트의 핵심 난제는 quic-go의 Stream을 gRPC의 transport layer에서 사용할 수 있게 만드는 것이다. transport.go의 Listener/Dialer 인터페이스는 net.Conn을 반환하도록 정의되어 있다.
+
+문제: quic-go의 `quic.Stream` 인터페이스는 `net.Conn`의 다음 메서드들이 제한되거나 다르게 동작한다:
+- `SetDeadline()`, `SetReadDeadline()`, `SetWriteDeadline()` — quic-go Stream은 deadline 설정 방식이 다름
+- `LocalAddr()`, `RemoteAddr()` — quic-go의 Connection 단위로 가져와야 함
+- `Close()` — quic-go Stream의 Close는 half-close 의미를 가짐 (gRPC 예상과 다를 수 있음)
+
+이 문제들을 해결하지 못하면 transport 인터페이스가 quic-go에서 정상 작동하지 않으며, 프로젝트 전체가 좌초된다.
+
+→ 이 리스크를 문서 최상단에 명시하고, 실패 시 대비책(fallback: HTTP/2만으로라도 게이트웨이 검증)을 포함해야 함. 현재 구현 문서에는 이에 대한 언급이 전혀 없음.
+
+### 3.2. MQTT/CoAP 어댑터의 설계가 불명확
+
+`internal/gateway/mqtt_adapter.go`, `coap_adapter.go`가 파일 목록에 있지만, 구체적인 변환 설계가 없다.
+
+- 「MQTT → Protobuf」 변환이 정확히 무엇을 의미하는가?
+  - MQTT message payload를 Protobuf message로 역직렬화?
+  - MQTT topic 구조를 gRPC service/method에 매핑?
+  - MQTT connection 자체를 gRPC streaming session으로 변환?
+
+이 설계가 명확하지 않으면 게이트웨이 구현의 범위를 특정할 수 없고, 구현 중 방향을 잃을 위험이 있다.
+
+→ 각 어댑터의 변환 전략을 간략하게라도 protocol_adapter.go의 인터페이스 정의와 함께 문서화.
+
+### 3.3. route_table.go — 정적 라우팅의 구체적 형식 부재
+
+「정적 룰 기반 라우팅」이라고만 되어 있고, 라우팅 룰의 형식, 저장 방식, 로딩 방식이 전혀 정의되지 않았다. YAML 파일? 코드 내 map 구조체? DB 테이블?
+
+예를 들어, ROI 경량 분석은 엣지로, 정밀 분석은 클라우드로 라우팅하는 규칙을 어떻게 표현할 것인가? 이 규칙의 변경이 런타임에 가능한가, 재시작이 필요한가?
+
+→ 라우팅 룰의 데이터 모델(입력 조건 → 대상 서비스)과 설정 방식을 문서에 추가.
+
+### 3.4. golangci-lint 설정 파일 부재
+
+Makefile에 `make lint` 타겟이 있지만(`golangci-lint 실행`), 프로젝트에 `.golangci-lint.yaml`이 없다. 기본 설정으로 lint를 돌리면 Go 표준 라이브러리 이슈부터 각종 경고까지 너무 많은 내용이 출력되어 실질적으로 lint를 사용하기 어렵다.
+
+→ `.golangci-lint.yaml`을 프로젝트 루트에 포함시키고, 이 연구에 필요한 lint 규칙(예: errcheck, govet, staticcheck 등)을 명시.
+
+### 3.5. 벤치마크 실행 방식의 이중성
+
+Go testing.B(benchmarks/scenarios/)와 cmd/benchmark-runner가 병존하는 구조다. testing.B는 동일 프로세스 내에서의 벤치마크에 적합하고, cmd/benchmark-runner는 분산 환경(여러 머신/컨테이너)에서의 end-to-end 측정에 적합하다.
+
+그런데 이 둘의 역할 분담이 명확하지 않다:
+- testing.B로는 RPS나 P50/P99 latency를 어떻게 측정하는가? (testing.B는 초당 연산 수는 알려주지만, latency 분포는 직접 구현해야 함)
+- cmd/benchmark-runner는 어느 시나리오를 담당하는가?
+- Docker Compose 환경에서 benchmark-runner는 어디서(호스트/컨테이너) 실행되는가?
+
+→ 두 벤치마크 방식의 역할 분담과 각각의 측정 가능 지표를 IMPLEMENTATION.md에 명시.
+
+### 3.6. 6.3 멀티 에이전트 충돌 방지 — 수동 프로세스에 의존
+
+「go.mod/go.sum 변경 시 다른 에이전트에 즉시 알린다」는 자동화된 메커니즘 없이 수동 커뮤니케이션에 의존한다. 실제 멀티 에이전트 작업에서는 이 알림이 누락되어 go.sum conflict가 발생할 가능성이 높다.
+
+→ go.mod 변경이 감지되면 자동으로 lock을 걸거나, proto 변경 시 필드 번호 충돌을 검사하는 스크립트를 scripts/에 추가하는 것이 더 현실적.
+
+---
+
+## 4. 공통/구조적 문제
+
+### 4.1. 용어의 일관성
+
+- BACKGROUND.md: 「AI Agent」 중심으로 배경 설명
+- 참고/SGS: IoT(스마트팜 해충 탐지) 시나리오
+- CLAUDE.md: 「AI Agent + IoT」 두 시나리오를 동일 스택으로 처리
+
+이 두 시나리오가 동일한 gRPC-QUIC 스택으로 커버 가능하다는 주장의 근거가 문서 어디에도 없다. AI Agent RPC(수 KB, Unary, burst)와 IoT 데이터 전송(수 MB, Streaming)은 페이로드 크기, 패턴, 품질 요구사항이 완전히 다르다. QUIC의 장점(0-RTT, HoL blocking 해소, 연결 마이그레이션)이 이 두 시나리오에 동일하게 적용된다는 논리가 필요하다.
+
+### 4.2. Novelty claim의 취약함
+
+gRPC over QUIC을 구현하는 것 자체는 새로운 연구가 아니다. 이미:
+- quic-go 커뮤니티에서 gRPC + QUIC 조합에 대한 논의와 PoC 존재
+- Microsoft의 MsQuic 라이브러리와 gRPC의 호환성 실험
+- Caddy, Envoy 등에서 HTTP/3 지원
+
+「무엇이 이 연구를 독창적으로 만드는가?」라는 질문에 현재 문서들은 명확히 답하지 못한다. AIoT 환경이라는 specific domain에서의 실증(empirical validation)이라고 한다면, 그 점을 전면에 내세우고 「domain-specific empirical study」임을 명시해야 한다.
+
+### 4.3. 통계적 유의성에 대한 고려 부재
+
+5.2절 KPI에 「P50/P95/P99 Latency」가 포함되어 있지만, 각 측정값의 통계적 유의성(신뢰 구간, 표본 수, 분산 분석)에 대한 계획이 전혀 없다.
+
+5.4절 시나리오 정의에 「동시성: 디바이스 수 ~ 동시 N개」라고 되어 있지만, N이 얼마인지, 충분한 표본 수를 확보할 수 있는지에 대한 논의가 없다.
+
+「count=5」(5회 반복)는 평균과 분산을 계산하기에 충분한가? 5회는 너무 적다. 특히 Lossy 환경에서는 variance가 크므로 최소 20~30회 반복이 필요하다.
+
+→ 각 실험의 반복 횟수, 신뢰 구간 계산 방식, 이상치(outlier) 처리 정책을 실험 계획에 포함.
+
+### 4.4. 위험 관리 부재
+
+프로젝트 전반에 걸쳐 위험 식별과 대비책이 전혀 없다. 최소한 다음 위험은 문서화되어야 한다:
+
+| 위험 | 영향 | 가능성 | 대비책 |
+|------|------|--------|--------|
+| quic-go와 gRPC transport interface 불호환 | 프로젝트 전체 지연 또는 실패 | 중간 | HTTP/2만으로 게이트웨이 검증 후 QUIC은 별도 실험으로 분리 |
+| Docker 환경에서 tc(traffic control) 미작동 | 네트워크 조건 시뮬레이션 불가 | 낮음 | 호스트 레벨 tc 사용 또는 네트워크 네임스페이스 분리 |
+| MQTT/CoAP 어댑터 구현 범위 과다 | 게이트웨이 일정 지연 | 중간 | P1으로 격하 또는 단일 프로토콜(MQTT만)부터 검증 |
+| Go 버전업에 따른 quic-go 호환성 이슈 | 빌드 실패 | 낮음 | go.mod에 quic-go 버전 고정 |
+
+### 4.5. 문서 간 중복
+
+BACKGROUND.md 2.1~2.3과 CLAUDE.md 1.1~1.3이 거의 동일한 내용을 반복한다. 배경 문서는 「더 깊이 있는 설명」을, CLAUDE.md는 「요약과 연결」을 담당해야 하는데, 현재는 거의 복사 수준으로 내용이 겹친다.
+
+→ CLAUDE.md 1절의 각 항목은 2-3문장 요약으로 줄이고, 자세한 내용은 BACKGROUND.md를 참조하도록 변경.
+
+---
+
+## 5. 요약 — 가장 시급한 5가지 과제
+
+1. **quic-go + gRPC transport interface 호환성 검증** — (3.1) 프로젝트 성패가 달린 리스크. 구현 전에 PoC로 먼저 검증하고, 실패 시 대비책을 문서화할 것.
+
+2. **Novelty 재정의** — (4.2) 「단순 QUIC 적용 구현」이 아니라 「AIoT 도메인에서의 실증 연구(empirical study)」임을 문서에서 명확히 하고, 선행 연구와의 차별성을 강화할 것.
+
+3. **게이트웨이 아키텍처의 기여 재검토** — (2.2) 프로토콜 변환 + 정적 라우팅만으로는 연구 기여로 인정받기 어려움. 게이트웨이의 구체적인 설계 결정이나 gRPC-QUIC 통합의 이점을 더 명확히 해야 함.
+
+4. **실험 설계 강화** — (4.3, 2.7) Lossy 조건 다양화, 통계적 유의성 확보(반복 횟수 증가), AI Agent 시나리오 KPI 재조정.
+
+5. **위험 관리 문서화** — (4.4) 최소 3~4개의 주요 위험과 대비책을 CLAUDE.md나 별도 문서에 명시. 특히 QuIC-gRPC 호환성 위험은 반드시 포함.
+
+---
+
+> 본 피드백은 문서의 개선을 돕기 위한 것입니다. 긍정적 평가는 생략되었습니다.