[Infra] 중앙 LLM Gateway 도입 검증 및 단계적 전환

[yoonki1207]

현재 상태

Organization-level LLM credential과 runtime permission은 nodease/mbased#58에서 구현되었다. 이 이슈는 더 이상 credential 소유권 전환을 다루지 않고 중앙 LLM Gateway의 실제 도입 여부와 전환 계약만 관리한다.

nodease/mbased#22는 Done 상태지만 현재 origin/dev의 Gateway/Workflow Engine은 provider adapter와 provider base URL을 통해 직접 호출하는 경로를 유지한다. 따라서 nodease/mbased#22의 완료 산출물, 배포 환경 또는 실제 source 반영 여부를 먼저 대조해야 한다.

목표

중앙 LLM Gateway가 필요한지 architecture decision으로 확정하고, 도입한다면 기존 direct provider adapter를 중단 없이 단계적으로 이관한다.

결정할 사항

• 중앙 proxy 도입과 현재 provider adapter 유지의 비용·복잡도 비교
• LiteLLM 등 구현체의 운영 책임, 라이선스, 업그레이드와 장애 영향
• Organization BYOK credential의 보관 주체와 proxy 전달 방식
• Chat completion, embedding, streaming, tool call 지원 범위
• usage/cost/audit/trace의 source of truth와 중복 기록 방지
• timeout, circuit breaker, provider fallback과 retry 소유 계층
• 중앙 proxy 장애 시 failover 여부와 direct-call fallback 허용 여부
• Gateway/Workflow worker 간 trust, service authentication과 network policy

구현 범위

1. 현재 LLM Gateway 중앙화 #22 산출물과 실제 dev/Helm/Compose/runtime 경로를 검증한다.
2. 도입 또는 유지 결정을 ADR로 기록한다.
3. 도입 시 feature flag와 organization 단위 canary로 전환한다.
4. provider별 capability parity와 secret 비노출을 검증한다.
5. health/readiness, metric, trace correlation과 rollback 절차를 추가한다.
6. direct-call 제거 시점과 compatibility window를 문서화한다.

완료 조건

• LLM Gateway 중앙화 #22 상태와 실제 source/deployment의 불일치가 해소된다.
• 중앙 Gateway 도입 여부와 책임 경계가 ADR에 기록된다.
• 도입 결정 시 LLM node, RAG embedding, wizard의 대표 회귀 테스트가 통과한다.
• credential 원문이 proxy log, trace, metric label 또는 error response에 남지 않는다.
• proxy 장애·timeout·stream 중단의 안전한 실패와 rollback이 검증된다.

비범위

• Organization credential RBAC 재구현
• 모델 추천/비용 최적화 정책 자체

[linear-code]

MBA-17