# 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/robeing/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_robeing-gateway구현.md
- 250818_happybell80_GatewayJWT인증구현.md
- 250818_happybell80_대화히스토리구현.md