첫 번째 LLM 기능은 하나의 서비스에서 Bedrock으로 직접 호출하는 형태로 출시된다. 열 번째 기능도 같은 방식으로 출시되는데, 열 개의 서비스에서, 열 개의 자격 증명 세트로, 열 개의 재시도 정책으로, 그리고 누가 얼마를 쓰고 있는지 한눈에 볼 수 있는 곳은 어디에도 없다. 바로 그 순간 플랫폼 팀은 LLM 게이트웨이가 필요하다는 사실을 깨닫는다. 보통은 그것을 저렴하게 만들 수 있었을 시점에서 한 분기가 지난 후에야 말이다. 게이트웨이는 모든 모델 호출이 지나가는 공용 정문이며, 각 팀이 계속해서 어설프게 재발명하는 네 가지, 즉 인증, 쿼터, 라우팅, 감사를 소유하기 위해 존재한다.

유용한 재구성은 게이트웨이가 AI 기능이 아니라는 점이다. 이미 공유되고, 사용량이 측정되고, 비용이 많이 드는 의존성 앞에 두는 것과 동일한 제어 계층일 뿐이다. 모든 서비스가 각자 데이터베이스 관리자 비밀번호를 들고 다니며 자기 마음대로 연결 제한을 정하도록 두지는 않을 것이다. 모델 접근도 다르지 않다. 다만 청구서가 더 빨리 불어나고 장애 양상이 더 시끄러울 뿐이다.

게이트웨이가 실제로 중앙화하는 것

가치는 요청을 프록시하는 데 있지 않다. 애플리케이션 코드에 있어서는 안 되는 네 가지 횡단 관심사를 소유하는 데 있다.

  • 인증. 호출자는 게이트웨이에 서비스 신원을 제시한다. 게이트웨이는 Bedrock과 통신하는 단 하나의 자격 증명을 보유한다. 어떤 애플리케이션도 장기 유효한 모델 키를 보는 일이 없고, 그 키를 회전시키는 것은 스무 곳이 아니라 한 곳만 바꾸면 되는 변경이다.
  • 쿼터. 팀별, 모델별 토큰 예산이 한곳에 존재한다. 어떤 서비스에서 폭주하는 루프가 생기더라도 자기 자신의 한도에 부딪힐 뿐, 공유된 분당 토큰 제한을 먹어치우며 다른 모두를 스로틀링하지 않는다.
  • 라우팅. 게이트웨이는 논리적 모델 이름을 구체적인 배포로 매핑한다. 어느 리전인지, 어느 프로바이더인지, 기본 모델이 스로틀될 때 어디로 폴백하는지. 애플리케이션은 특정 리전의 특정 모델 ID가 아니라 "요약기"를 요청할 뿐이다.
  • 감사. 모든 요청과 응답이 하나의 관문을 통과하므로, 비용 귀속, 프롬프트 로깅, 남용 탐지 모두 걸 수 있는 단일 이음매를 갖는다. 이것이 없으면 기능별 비용 산출은 고고학 발굴 작업이 된다.

이 중 어느 것도 모델 품질 문제가 아니라는 점에 주목하라. 이들은 의존성이 모델이라는 이유만으로 새로워 보이는 플랫폼 문제일 뿐이다.

자체 구축 대 LiteLLM 대 API Gateway

정직한 패턴은 세 가지이며, 어느 것이 옳은지는 첫날부터 위의 것들이 실제로 얼마나 필요한지에 달려 있다.

LiteLLM(또는 유사한 프록시)을 도입한다

LiteLLM 같은 오픈소스 프록시는 프로바이더 전반에 걸친 통합 API, 키별 예산, 기본적인 라우팅을 기본으로 제공한다. 앞서 말한 네 가지 관심사를 이미 알고 있는 실제 게이트웨이를 가장 빠르게 갖추는 방법이다. 대가는 모든 AI 기능의 임계 경로에 놓인 상태 저장 서비스를 이제 직접 운영하고 패치해야 하며, 라우팅과 로깅에 대한 그 프로젝트의 의견이 곧 우리의 의견이 된다는 점이다. 두 번째나 세 번째 LLM 기능을 세우는 대부분의 팀에게는 이것이 올바른 기본값이다. 제어 계층을 만드는 대신 사는 것이다.

API Gateway와 Lambda 위에 올린다

이미 AWS에 깊이 들어가 있다면, Amazon API Gateway를 작은 Lambda 인가자와 프록시 함수 앞에 두는 것으로 이미 운영 중인 기본 요소들로부터 인증, 사용 계획, 스로틀링, 접근 로그를 얻을 수 있다. 사용 계획이 키별 속도 제한을 처리하고, 인가자가 신원을 처리하며, CloudWatch가 감사 추적을 처리한다. 대가는 모델 특화 로직, 스트리밍, 토큰 카운팅, 프로바이더 폴백이 우리가 직접 작성하고 소유하는 코드가 된다는 점이다. 이 패턴은 거버넌스 요구사항이 AWS 형태이고, 새 의존성을 들이기보다 기존 플랫폼을 확장하고 싶을 때 유리하다.

맞춤형 서비스를 구축한다

직접 구축하는 것이 옳은 경우는 라우팅이나 감사 요구사항이 진짜로 특이할 때뿐이다. 복잡한 모델 선택 정책, 요청별 데이터 거주지 결정, 규제 기관을 특정 형태로 만족시켜야 하는 로깅 같은 경우다. 처음부터 구축하는 대부분의 팀은 사실 LiteLLM을 더 느리게 재구축하고 있는 것이다. 이 선택지는 마지막에, 그리고 기성 옵션이 충족할 수 없는 요구사항을 명확히 지목할 수 있을 때만 손대야 한다.

게이트웨이가 막아주는 실패 양상

게이트웨이가 없으면 실패는 극적이지 않고 서서히 온다. 자격 증명이 흩어진다. 각 팀이 자기 나름의 타임아웃과 재시도를 설정하면, 프로바이더의 작은 장애 하나가 재시도 폭풍이 되어 토큰 쿼터를 밀어붙인다. "지난달 지원 요약 기능이 얼마를 썼는가"라는 질문에 답하려면 여러 서비스의 로그를 grep해야만 하고, 아무도 제대로 답할 수 없다. 그러다 보안 검토에서 누가 어떤 데이터로 어떤 모델을 호출할 수 있는지 물으면, 정직한 답은 "잘 모르겠다"가 되고, 이 답은 출시를 멈추게 하는 답이다.

게이트웨이는 이 모든 것을 설정으로 바꾼다. 그것이 전체 요지다. 횡단 결정들을 스무 개의 코드베이스에서 빼내어 우리가 추론할 수 있는 하나의 코드베이스로 옮기는 것이다.

경계선을 제자리에 그어라

게이트웨이는 얇게 유지하라. 신원, 쿼터, 라우팅, 로깅을 처리하되 프롬프트 구성과 비즈니스 로직에는 관여하지 말아야 한다. 게이트웨이가 프롬프트를 소유하기 시작하는 순간, 그것은 네트워크 홉이 붙은 공유 라이브러리가 되고, 모든 팀이 그 릴리스 주기에 발목이 잡힌다. 오래 가는 설계는 거버넌스에 대해서는 강한 의견을 갖되 우리가 모델에 무엇을 묻는지에 대해서는 아무 의견도 갖지 않는, 지루한 프록시다.

결론

LLM 기능을 두 개 이상 출시하는 모든 플랫폼 팀은 결국 게이트웨이를 만들게 된다. 유일한 선택은 그것을 의도적으로, 작은 프록시일 때 일찍 만드느냐, 아니면 자격 증명이 흩어지고 청구서가 미스터리가 된 후 뒤늦게 우발적으로 정리 프로젝트로 만드느냐다. 가능하다면 프록시를 도입하고, AWS 네이티브라면 API Gateway를 확장하고, 명확히 지목할 수 있는 요구사항이 있을 때만 처음부터 만들어라. 게이트웨이는 AI가 일어나는 곳이 아니다. 어차피 필요했던 거버넌스가 마침내 자리를 잡는 곳이다.

이어서 읽으면 좋은 글

이런 공유 제어 계층을 운영하는 플랫폼 및 인프라 측면은 ercan.cloud의 클라우드 현장 노트에서 다루고, 허브는 ercanermis.com에 있다.