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

3.8 KiB

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에 범용 프록시 추가:

@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