diff --git a/docs/GRPC.md b/docs/GRPC.md
index 88685c9..e08f69d 100644
--- a/docs/GRPC.md
+++ b/docs/GRPC.md
@@ -19,7 +19,7 @@ gRPC는 HTTP/2를 기반으로 구축된 구글의 고성능 오픈소스 원격
 
 * **장점**
   * **높은 전송 효율성**: 데이터 교환 시 텍스트가 아닌 바이너리 인코딩 형식을 사용하므로 JSON에 비해 직렬화/역직렬화 속도가 매우 빠르고 크기도 가볍습니다.
-  * **일관성 있는 코드 생성 (Stub)**: 동일한 정의서로부터 다국어 API 클라이언트를 빌드하여 중복 작성 오버헤드를 획득합니다.
+  * **일관성 있는 코드 생성 (Stub)**: 동일한 정의서로부터 다국어 API 클라이언트를 빌드하여 언어별 클라이언트 코드를 중복 작성해야 하는 오버헤드를 제거합니다.
   * **하위 호환성**: 고유 필드 번호 매핑 방식을 사용하므로 스키마가 개정되어도 이전 시스템과의 통신 호환을 보장합니다.
 
 * **단점**
@@ -109,7 +109,7 @@ protoc --go_out=. --go_opt=paths=source_relative --go-grpc_out=. \
   	protoapi.UnimplementedRandomServer
   }
   ```
-  `UnimplementedRandomServer`를 임베딩하여, 향후 메서드가 새로 추가되더라도 기존 서버가 빌드 에러 없이 최소한의 호환( unimplemented 에러 응답 )을 가지게 강제합니다.
+  `UnimplementedRandomServer`를 임베딩하여, 향후 메서드가 새로 추가되더라도 기존 서버가 빌드 에러 없이 최소한의 호환(unimplemented 에러 응답)을 가지게 강제합니다.
 * **서버 기동 흐름**:
   ```go
   server := grpc.NewServer()
@@ -147,7 +147,7 @@ gRPC 서버 및 클라이언트 실습 과정에서 직면할 수 있는 대표
 ### 5.1 `listen tcp :8080: bind: address already in use`
 * **원인**: 포트 `8080`이 이미 다른 백그라운드 프로세스나 기존 기동된 서버에 의해 점유되어 충돌이 난 상태입니다.
 * **해결 방법**: 
-  - `examples/main.go` 의 `port` 변수값과 [server.go](file:///home/godopu16/PuKi/lab/canary_projects/grpccanary/examples/grpcentity/server.go)의 `port` 전역 변수값을 동시에 다른 포트(예: `:9090`)로 변경하고 재시도해야 합니다.
+  - `examples/main.go` 의 `port` 변수값과 [server.go](../examples/grpcentity/server.go)의 `port` 전역 변수값을 동시에 다른 포트(예: `:9090`)로 변경하고 재시도해야 합니다.
   - **주의**: `server.go` 내부의 `ServerRun(addr string)` 함수는 외부 진입점으로부터 인자 `addr`을 인가받지만, 실제 포트 리슨 코드에서는 이를 무시하고 패키지 전역 변수 `port = ":8080"`를 직접 읽어 처리하도록 하드코딩되어 있습니다. 따라서 정상적으로 포트를 바꾸기 위해서는 반드시 `server.go` 내부 전역 변수인 `port` 값을 수정해 주어야 포트 바인딩이 성공합니다.
 
 ---
@@ -155,7 +155,7 @@ gRPC 서버 및 클라이언트 실습 과정에서 직면할 수 있는 대표
 ## 6. 다음 단계 (Next Steps)
 
 gRPC 통신 방식을 한층 더 깊이 탐구해 보려면 다음과 같은 후속 실습을 추천합니다:
-1. **메시지 스펙 확장**: 루트 디렉토리의 [protoapi.proto](file:///home/godopu16/PuKi/lab/canary_projects/grpccanary/protoapi.proto)에 새로운 필드를 추가하거나 메서드를 정의한 뒤, Stub을 재컴파일([examples/grpcentity/README.md](file:///home/godopu16/PuKi/lab/canary_projects/grpccanary/examples/grpcentity/README.md) 컴파일 가이드 참고)해 보십시오.
+1. **메시지 스펙 확장**: 루트 디렉토리의 [protoapi.proto](../protoapi.proto)에 새로운 필드를 추가하거나 메서드를 정의한 뒤, Stub을 재컴파일([examples/grpcentity/README.md](../examples/grpcentity/README.md) 컴파일 가이드 참고)해 보십시오.
 2. **인터페이스 모듈 연계**: 생성된 gRPC 클라이언트 및 서버 stub 인터페이스를 활용하여, 향후 분산 AIoT 환경에서의 센서 데이터 수집이나 에이전트 간 제어 메시지 전송 로직을 설계해 보십시오.
 
 ---
diff --git a/docs/MANUSCRIPT.md b/docs/MANUSCRIPT.md
index b28538f..5eafe68 100644
--- a/docs/MANUSCRIPT.md
+++ b/docs/MANUSCRIPT.md
@@ -56,6 +56,8 @@ REST와 JSON은 단순하고 사람이 읽기 쉽다는 훌륭한 장점이 있
 * **바이너리 프로토콜**: 텍스트가 아닌 이진 데이터 형식을 사용하여 통신 속도가 JSON 방식에 비해 훨씬 빠르고 가볍습니다.
 * **HTTP/2 기반**: 하나의 커넥션을 다중화(Multiplexing)하여 사용하므로 네트워크 리소스 효율성이 매우 높습니다.
 
+민우가 겪은 문제는 서비스 몇 개가 통신하는 MSA 환경에서도 발생했지만, 다수의 IoT 디바이스와 지능형 에이전트가 실시간으로 데이터를 주고받는 AIoT 멀티 에이전트 환경에서는 계약 불일치와 직렬화 비용의 영향이 훨씬 크게 증폭됩니다. 본 프로젝트가 gRPC를 사전 학습 주제로 채택한 이유도 여기에 있습니다.
+
 실제 gRPC 통신의 기술적 개념 요소(장단점, 프로토콜 버퍼) 및 소스코드 구현체 컴파일과 서버/클라이언트 개발 실습에 관한 상세 내용은 다른 페이지에서 나누어 다룹니다.
 
 👉 **[3단계: gRPC 통신 구현 상세 가이드 (GRPC.md)](GRPC.md)**