AI API 게이트웨이

앱과 여러 LLM 공급자 사이에 두는 단일 진입점이다. 앱은 주소 하나로만 요청을 보내고, 라우팅·폴백·캐싱·비용 통제는 게이트웨이가 한곳에서 처리한다. 모델을 두 개 이상 쓰거나 여러 팀이 LLM API를 나눠 쓰기 시작할 때 필요해진다.

앱은 주소 하나만 바꾸면 된다

대부분의 게이트웨이는 OpenAI API와 같은 형식의 엔드포인트를 연다. 기존 코드에서 SDK의 base URL과 API 키만 게이트웨이 것으로 바꾸면 된다. 그러면 호출 코드를 고치지 않고도 Claude나 Gemini 같은 다른 공급자 모델을 같은 방식으로 부를 수 있다.

오픈소스 LiteLLM Proxy라면 설정 파일 config.yaml의 model_list에 쓸 모델과 공급자 키를 적고 프록시를 띄운다. 그다음 팀이나 서비스마다 가상 키를 발급해 예산을 걸어 둔다. 이렇게 하면 실제 공급자 키는 게이트웨이 안에만 남는다. Kong은 기존 API 게이트웨이에 AI 전용 플러그인을 얹는 방식이라, 이미 Kong을 쓰는 조직이 붙이기 쉽다.

폴백부터 켜고 캐싱은 신중하게

처음 도입한다면 폴백과 사용량 로그부터 켜는 게 효과가 가장 확실하다. 주 모델이 오류나 시간 초과를 내면 다른 공급자의 비슷한 급 모델로 넘기도록 지정해 둔다. 그러면 장애가 나도 사용자 눈에 덜 띈다.

시맨틱 캐싱은 뜻이 비슷한 질문에 예전 답을 돌려준다. 사람이나 시점에 따라 답이 달라야 하는 서비스에서는 엉뚱한 응답이 나갈 수 있으니, 반복 질문이 많은 경로에만 좁게 켠다.

일반 API 게이트웨이와 다른 점

모델 하나만 쓰면 굳이 필요 없다

공급자도 서비스도 하나뿐이라면 게이트웨이는 관리할 구성 요소만 늘린다. 요청이 한 단계를 더 거치므로 지연이 조금 늘고, 게이트웨이가 멈추면 모든 LLM 호출이 함께 멈춘다. 또 공통 형식으로 맞추다 보면 특정 공급자의 새 기능을 바로 못 쓸 수 있다. 꼭 필요한 기능을 지원하는지 먼저 확인한다.

사내 공용 창구와 장애 대비용으로 주로 둔다

가장 흔한 쓰임은 여러 팀이 함께 쓰는 사내 LLM 창구다. 공급자 키는 게이트웨이에만 두고, 팀마다 가상 키와 예산을 나눠 준다. 그다음으로 많은 쓰임은 고객용 서비스의 장애 대비다.