플러스프로젝트 배경
Gemini 단일 엔드포인트, virtual key별 일·월 예산, Redis 호출 제한, 키 발급·폐기 등 OpenAI 호환 S2S 게이트웨이 운영 흐름을 먼저 정리하고, 프록시부터 정책 저장소·운영 도구까지 사전 구현했습니다. 예산 소진 키 차단, 정상 키 독립 호출, 초당·분당 제한, 키 폐기, Redis 장애 차단 등 대표 운영 시나리오를 실제 컨테이너에서 미리 검증해둔 덕분에, 30일 안에 고객 클라
프로젝트 성과
차단된 키의 provider 호출 0건
일·월 예산을 소진한 요청을 provider 앞에서 HTTP 429로 멈춰, 한도 초과 뒤 비용이 더 발생하지 않도록 확인했습니다.
키 4개의 예산·속도 정책 독립 확인
월 예산, 일 예산, 정상 호출, 분당 제한을 서로 다른 키에 적용해 한 키의 차단이 다른 서비스 호출을 막지 않게 구성했습니다.
초당 2회·분당 2회 제한 각각 판정
Redis 초당 카운터와 LiteLLM 분당 정책을 분리해 호출 폭주와 누적 과다 사용을 서로 다른 시간 창에서 통제합니다.
5개 컨테이너를 한 번에 배포
앱·프록시·DB·Redis·provider를 Compose 한 묶음으로 기동하고 모두 healthy인 상태에서 공개 정책 요청까지 확인했습니다.
운영자·개발자 2개 관점으로 결과 확인
운영자는 전체 차단 원인을, 서비스 개발자는 자기 키의 예산과 요청 결과를 확인해 장애 원인 파악 시간을 줄입니다.
핵심 기능
OpenAI 호환 단일 S2S 엔드포인트
서비스별 연동 방식을 흩뜨리지 않기 위해 LiteLLM 한 주소로 모으고, 설정 변경만으로 Gemini 외 모델을 추가할 수 있게 했습니다.
진행 단계
정책·네트워크 경계 설계
2026.07.
단일 프록시, virtual key, 일·월 예산 창, RPS·RPM, DB·Redis, 고객 VPC 입력 경계를 아키텍처와 요구사항으로 확정했습니다.
프로젝트 상세
여러 서비스가 공유하는 LLM 호출을 하나의 OpenAI 호환 엔드포인트로 모으고, virtual key마다 일일·월간 예산과 초당·분당 호출량을 독립적으로 통제하는 게이트웨이를 구축했습니다. [키별 예산을 분리하는 정책 경로] LiteLLM이 요청 인증과 모델 라우팅을 맡고 PostgreSQL이 virtual key와 예산 창을 저장합니다. 한 키의 월 예산을 0으로 설정해 HTTP 429로 차단되는
