diff --git a/ideas/250807_서비스_재구조화_계획.md b/ideas/250807_서비스_재구조화_계획.md
index 1b2e8d9..bccab53 100644
--- a/ideas/250807_서비스_재구조화_계획.md
+++ b/ideas/250807_서비스_재구조화_계획.md
@@ -62,7 +62,8 @@
 - **역할**: 
   - API 게이트웨이 (사용자 요청 → 로빙 라우팅)
   - 인증 체크 (auth-server 연동)
-  - 사용자-로빙 매핑
+  - 사용자-로빙 매핑 (메모리 캐시)
+  - 캐시 관리: 로그인 시 추가, 로그아웃 시 제거
 
 #### robing-control (구 frontend-base 일부)
 - **위치**: 51123 서버
@@ -105,7 +106,7 @@ sequenceDiagram
     
     U->>F: 채팅 입력
     F->>G: /api/chat (user_id 포함)
-    Note over G: DB 조회: user_id → port 8001
+    Note over G: 메모리 캐시 확인<br/>없으면 DB 조회 후 캐싱
     G->>R: 프록시 (port 8001)
     R->>G: 응답
     G->>F: 응답
@@ -115,7 +116,9 @@ sequenceDiagram
 **수정된 흐름 설명:**
 1. 로그인 완료 후 Frontend는 user_id만 알면 됨
 2. 모든 API 요청에 user_id 포함 (JWT 토큰 또는 헤더)
-3. Gateway가 매번 DB 조회하여 해당 사용자의 robing_port 확인
+3. Gateway가 메모리 캐시 확인 (대부분 여기서 처리)
+   - 캐시 hit: 즉시 라우팅
+   - 캐시 miss: DB 조회 후 캐싱
 4. Gateway가 적절한 로빙으로 프록시
 5. Frontend는 로빙 포트를 전혀 알 필요 없음