docs: Gateway API 프록시 아키텍처 고민 문서 작성

- Gateway 역할 재정의 필요성
- 중앙집중 vs 직접연결 트레이드오프
- Slack 사례에서 얻은 통찰
- JWT_SECRET_KEY 관리 문제
- 단기/장기 해결 방향 제시

ideas/250818_Gateway_API프록시_아키텍처_고민.md

@@ -0,0 +1,136 @@
+# Gateway API 프록시 아키텍처 고민
+
+**날짜**: 2025-08-18  
+**작성자**: happybell80 & Claude  
+**관련**: robeing-gateway, frontend-customer, rb10508_micro
+
+## 현재 문제 상황
+
+### Frontend의 기대사항
+- Gateway를 통해 모든 API 접근 (`/api/config`, `/api/history`, `/api/chat`)
+- 하나의 진입점으로 통일된 인터페이스
+
+### Gateway의 실제 구현
+- `/api/chat` 하나만 프록시
+- 나머지 API는 404 에러
+- 원래 "라우팅 전용"으로 설계됨
+
+### 로빙 서비스의 구조
+- 여러 로빙 존재 (rb8001, rb10508_micro, rb10408...)
+- 각 로빙이 완전한 백엔드 API 제공
+- Frontend는 어느 로빙을 사용해야 할지 모름
+
+## 아키텍처 선택지
+
+### 1. Gateway가 모든 API 프록시 (중앙집중형)
+```
+Frontend → Gateway → 적절한 로빙
+         모든 API 요청
+```
+
+**장점:**
+- Frontend는 Gateway만 알면 됨
+- 중앙 JWT 검증
+- 사용자별 라우팅 자동화
+
+**단점:**
+- Gateway 병목 현상
+- 모든 API마다 프록시 코드 필요
+- 레이턴시 증가
+
+### 2. 초기 핸드셰이크 후 직접 연결 (하이브리드)
+```
+Frontend → Gateway/api/robing/info (초기)
+        → 직접 로빙 연결 (이후)
+```
+
+**장점:**
+- 성능 최적화
+- Gateway 부하 감소
+- 로빙 서비스 독립성
+
+**단점:**
+- 각 로빙에 JWT 검증 필요
+- Frontend 복잡도 증가
+- 보안 로직 중복
+
+### 3. Slack 방식 (직접 연결)
+```
+Slack → 로빙 (직접, 토큰 기반)
+Web → Gateway → 로빙 (라우팅 필요)
+```
+
+**현재 Slack이 증명한 것:**
+- Gateway 없이도 잘 작동
+- 토큰 기반 직접 인증
+- 특정 로빙과 1:1 매핑
+
+## 핵심 통찰
+
+### Gateway의 진짜 역할
+- **Slack**: 이미 어느 로빙인지 알고 있음 → Gateway 불필요
+- **Web Frontend**: 어느 로빙인지 모름 → Gateway 필요
+- **API Client**: 토큰으로 특정 로빙 지정 → Gateway 불필요
+
+### 설계 원칙 재정의
+1. Gateway는 "라우팅 정보를 모르는" 클라이언트를 위한 것
+2. 토큰/키 기반 클라이언트는 직접 연결이 효율적
+3. 과도한 중앙화는 피해야 함
+
+## JWT_SECRET_KEY 관리 문제
+
+### 현재 상황
+- 각 서비스가 개별 `.env` 파일에 동일한 키 복사
+- 수동 동기화에 의존
+- 체계적인 시크릿 관리 부재
+
+### 개선 방향
+- 단기: 현재 방식 유지 (프로젝트 규모 적합)
+- 중기: 공유 환경변수 파일
+- 장기: HashiCorp Vault 같은 중앙 시크릿 관리
+
+## 결론 및 제안
+
+### 단기 해결책 (즉시 적용)
+Gateway에 범용 프록시 추가:
+```python
+@app.api_route("/api/{path:path}", methods=["GET", "POST"])
+async def universal_proxy(path: str, request: Request, 
+                         x_user_id: str = Depends(get_verified_user)):
+    # 모든 API 요청을 적절한 로빙으로 전달
+```
+
+### 장기 방향 (아키텍처 개선)
+1. **Phase 1**: Gateway가 모든 API 프록시 (현재)
+2. **Phase 2**: 로빙들이 JWT 검증 구현
+3. **Phase 3**: 초기 핸드셰이크 후 직접 연결
+
+### 의사결정 기준
+- **보안 vs 성능**: 현재는 보안 우선
+- **단순성 vs 최적화**: 단순한 구조 선택
+- **중앙화 vs 분산**: 점진적 분산화
+
+## 교훈
+
+1. **설계 의도와 실제 사용의 괴리**
+   - Gateway는 "채팅 라우터"로 설계
+   - Frontend는 "API 프록시"로 기대
+
+2. **Slack이 주는 시사점**
+   - 직접 연결도 충분히 실용적
+   - Gateway는 필수가 아닌 선택
+
+3. **진화하는 아키텍처**
+   - 처음부터 완벽할 필요 없음
+   - 점진적 개선이 현실적
+
+## 액션 아이템
+
+- [ ] Gateway 범용 프록시 구현 여부 결정
+- [ ] 각 로빙 JWT 검증 추가 계획 수립
+- [ ] 시크릿 관리 체계 개선 방안 검토
+
+## 참고 자료
+- 250809_happybell80_robing-gateway구현.md
+- 250818_happybell80_GatewayJWT인증구현.md
+- 250818_happybell80_대화히스토리구현.md