LLM 게이트웨이 패턴 — 프록시를 두는 이유

운영 중인 서비스 여러 곳에서 LLM 을 활용하고 있습니다. 문서를 요약하고, 들어온 문의를 분류하고, 사용자 질문에 답하는 데 쓰는데, 모델을 직접 띄워 돌리는 게 아니라 Azure OpenAI 와 AWS Bedrock 이 열어 둔 API 를 부릅니다. 이렇게 연동한 기능이 셋인데, 각자 자기 코드에 SDK 를 넣고 각자 키를 들고 있습니다.

SDK 하나 넣고 키만 채우면 끝이라 기능이 하나였을 때는 이게 제일 간단했고, 중간에 뭘 두면 장애 날 자리만 하나 늘어납니다. 그런데 셋이 되고 나서는 손볼 곳이 매번 세 군데입니다. 키를 한 번 갈려면 세 곳을 고쳐 배포해야 하고, 모델을 바꿔 보려 해도 세 곳이고, 재시도나 폴백처럼 똑같이 생긴 코드도 세 곳에 따로 들어가 있습니다. 어느 기능이 얼마를 쓰는지도 나눠 보기 어렵습니다.

기능마다 키를 들고 있으면 생기는 것

문서 요약  → Azure OpenAI (GPT-4)
문의 분류  → AWS Bedrock (Claude)
질문 응답  → Azure OpenAI (GPT-3.5)

키가 기능마다 흩어져 있으니 로테이션 한 번 하려면 셋을 다 건드려야 했습니다. 어느 기능이 얼마나 썼는지 알 방법도 없어 비용을 나눠 볼 수 없었고, Azure 에서 Bedrock 으로 옮기는 것도 설정 하나 바꾸는 일이 아니라 코드를 고치는 일이었습니다. rate limit 이나 fallback 로직도 기능마다 비슷한 게 중복으로 들어갔습니다.

게이트웨이 패턴

프록시 하나를 앞에 두고 세 기능이 그 단일 엔드포인트만 부릅니다.

기능이 아는 건 /chat/completions 하나뿐이고 provider 라우팅과 fallback, rate limit, 비용 추적은 프록시가 맡으니, 앞에서 흩어져 있던 문제들이 전부 한 곳으로 모입니다.

프록시로 모이는 것 — 분산·예산·캐시

모델 로드 밸런싱 — 같은 모델 이름에 여러 provider 를 매핑하면 클라이언트는 이름 하나만 요청하고 프록시가 분산합니다.

model_list:
  - model_name: gpt-4
    litellm_params:
      model: azure/gpt-4
      api_base: https://<region-a>.openai.azure.com
  - model_name: gpt-4        # 같은 이름 → 자동 분산
    litellm_params:
      model: azure/gpt-4
      api_base: https://<region-b>.openai.azure.com
  - model_name: gpt-4        # 여기도 같은 그룹
    litellm_params:
      model: bedrock/claude-3-5-sonnet

클라이언트는 model: gpt-4 만 요청하고, 프록시가 이 셋에 나눠 보냅니다. 같은 model_name 으로 올린 항목은 전부 한 분산 그룹이라 Bedrock 에도 평시 트래픽이 들어갑니다. 특정 대상만 예비로 두려면 다른 model_name 으로 올리고 router_settings.fallbacks 에 따로 걸어야 합니다.

Virtual Key — 팀별 예산 — 실제 API 키를 노출하지 않고 팀마다 가상 키를 발급합니다.

팀 A 키 → 월 $100, gpt-4·claude만
팀 B 키 → 월 $500, 모든 모델

키가 새어도 그 팀 예산 안에서만 쓰이고, 실제 provider 키는 프록시에만 있습니다.

응답 캐싱 — 같은 프롬프트의 응답을 저장해두고 같은 질문이 또 오면 provider 를 안 부르고 캐시에서 돌려주니, 비용이 줄고 응답도 그만큼 빨라집니다.

요청: "리스트 정렬하는 법?"
  → 캐시 확인 → HIT → 즉시 반환 (provider 호출 없음)
              → MISS → provider 호출 → 응답 + 캐시 저장

프록시가 한군데 있으니 캐시도 거기 하나로 끝나는데, 기능마다 붙였으면 캐시도 기능 수만큼 생겼을 자리입니다.

관리 지점 하나 — 키·비용·provider·캐싱

게이트웨이가 만드는 건 결국 관리 지점 하나라, 키를 갈 때도 비용을 팀별로 나눠 볼 때도 provider 를 바꿔 볼 때도 프록시만 보면 됩니다.

그럼 언제 두느냐는 두 가지를 물어보면 답이 나옵니다. 지금 어느 기능이 LLM 에 얼마를 쓰는지 말할 수 있는지, 그리고 API 키를 한 번 바꾸려면 몇 군데를 고쳐야 하는지입니다. 여기서 답이 막히기 시작하면 그때가 프록시를 앞에 둘 시점입니다.