LLM 게이트웨이

LLM 게이트웨이는 앱과 여러 LLM 제공자 사이에 두는 중간 프록시로, 앱은 주소 하나만 부르고 게이트웨이가 Claude·GPT·Gemini 같은 알맞은 모델로 요청을 넘긴다. 모델을 둘 이상 바꿔 가며 쓰거나 팀 단위로 키·비용·장애 대응을 한곳에서 관리할 때 쓴다.

한 주소로 받아 알맞은 모델로 넘긴다

제공자마다 API 형식이 달라 모델을 바꿀 때마다 코드를 고쳐야 하는 문제를 풀려고 나왔다. 게이트웨이는 보통 OpenAI 호환 형식 하나로 요청을 받아 각 제공자 형식으로 바꿔 보낸다. 중계하는 김에 아래 일도 함께 맡는다.

설정 파일에 모델을 적고, 앱은 주소만 바꾼다

LiteLLM을 직접 띄운다면 설정 파일(config.yaml)의 모델 목록에 쓸 모델과 제공자 키를 적고 litellm --config config.yaml로 프록시를 실행한다. 그다음 앱에서 OpenAI SDK의 base_url을 게이트웨이 주소로 바꾸면, model 값만 바꿔 Claude와 GPT를 같은 코드로 부를 수 있다.

직접 운영하기 싫다면 Portkey·Helicone 같은 서비스형 게이트웨이를 쓴다. 서버 없이 대시보드에서 비용과 지연 시간을 바로 볼 수 있다. 쿠버네티스에서 이미 Envoy나 APISIX로 트래픽을 관리하고 있다면, 그 위에 AI 게이트웨이 기능을 얹는 방법도 있다.

모델이 하나뿐이면 아직 필요 없다

단일 장애 지점과 고유 기능 누락에 주의

거쳐 가는 단계가 하나 늘어 지연 시간이 조금 늘고, 게이트웨이가 멈추면 모든 호출이 함께 멈춘다. 직접 운영한다면 이중화와 모니터링도 같이 챙겨야 한다.

제공자 고유 기능(도구 호출 세부 방식, 프롬프트 캐시, 추론 강도 옵션 등)은 공통 형식으로 옮기는 과정에서 빠지거나 다르게 동작할 수 있다. 내가 쓰는 기능이 그대로 전달되는지 먼저 시험해 본다. 서비스형을 쓰면 프롬프트가 제3자 서버를 거친다는 점도 고려한다.

팀 공용 창구와 모델 비교에 주로 쓴다

가장 흔한 건 회사나 팀의 공용 LLM 창구로 두는 방식이다. 원본 키는 게이트웨이에만 두고, 사람이나 앱마다 따로 키를 나눠 주며 예산과 사용량을 한곳에서 본다.