Google Cloud API Gateway 모델 라우팅 Public Preview: LLM 프록시를 줄이는 새 선택지

요약: Google Cloud API Gateway가 AI 모델 라우팅을 Public Preview로 제공하기 시작했다. OpenAI 호환 요청을 받아 Gemini, Claude, OpenAI OSS-GPT 등으로 동적으로 라우팅하는 방식이다. 자체 LLM 프록시를 운영하던 팀은 게이트웨이 계층을 다시 검토할 만하다.

무엇이 공개됐나

Google Developers Blog에 따르면 Google Cloud API Gateway는 OpenAPI 3.x 명세 안에서 가상 모델명과 실제 백엔드를 매핑하는 모델 라우팅 기능을 Public Preview로 제공한다. 애플리케이션은 표준 OpenAI 호환 요청을 보내고, Gateway가 요청을 받아 대상 모델의 네이티브 스키마로 변환한 뒤 Vertex AI의 Gemini, Anthropic Claude, OpenAI OSS-GPT 같은 백엔드로 전달한다.

개발팀 입장에서 눈에 띄는 부분은 두 가지다. 첫째, 라우팅 규칙을 애플리케이션 코드 밖으로 뺄 수 있다. 둘째, 기존 API Gateway 기능인 인증, rate limit, 토큰 추적, 서버리스 ingress 패턴과 LLM 라우팅을 한 계층에서 묶을 수 있다.

그동안 많은 팀은 자체 프록시 서버를 만들었다. 이유는 단순했다. 모델 제공사마다 엔드포인트, 인증, 요청 형식, 응답 형식, 에러 코드가 달랐기 때문이다. 하지만 프록시는 곧 운영 대상이 된다. 라우팅 로직, 장애 처리, 로그 마스킹, 비용 집계, 모델별 스키마 변화 대응까지 직접 챙겨야 한다. Gateway 기반 모델 라우팅은 이 부담을 줄이는 방향이다.

왜 LLM 라우팅이 제품 기능이 되었나

초기 AI 제품은 모델 하나를 정해 붙이는 경우가 많았다. 지금은 다르다. 같은 서비스 안에서도 작업 성격이 나뉜다. 빠른 요약, 고정 형식 추출, 긴 문맥 추론, 코드 수정, 이미지 이해, 보안 검토가 모두 다른 비용과 품질 기준을 가진다.

그래서 모델 라우팅은 점점 필수 계층이 되고 있다. 예를 들어 고객 문의 자동 분류는 저렴하고 빠른 모델로 충분할 수 있다. 법무 문서 초안 검토는 더 강한 모델과 긴 컨텍스트가 필요하다. 코드 에이전트는 계획 단계와 구현 단계에 다른 모델을 쓸 수 있다. 장애 상황에서는 응답 지연을 줄이기 위해 빠른 모델로 폴백해야 할 수도 있다.

문제는 이 로직이 애플리케이션 코드 안에 들어가면 빠르게 지저분해진다는 점이다. if 문으로 모델명을 바꾸기 시작하면 인증, 재시도, 관측성, 장애 대응도 같이 흩어진다. 모델 라우팅을 Gateway 계층으로 올리면 제품 코드는 “어떤 가상 모델을 호출할 것인가”에 집중하고, 운영 정책은 명세와 인프라에서 관리할 수 있다.

실제 구성에서 주의할 제약

Google 예시는 OpenAPI 3.x의 x-google-api-management 확장 블록으로 backend와 router를 정의한다. 가상 모델명은 실제 backend와 targetModel에 매핑된다. 애플리케이션은 /v1/chat/gemini-claude 같은 Gateway endpoint로 요청을 보내고, 요청 body의 model 값에 따라 실제 모델이 선택된다.

다만 중요한 제약이 있다. 한 router에서 참조하는 backend는 같은 host를 공유해야 한다. 예시는 aiplatform.googleapis.com 위에서 Gemini, Anthropic, OSS-GPT를 라우팅한다. 즉 임의의 외부 호스트를 마음대로 섞는 범용 멀티클라우드 프록시라기보다, Vertex AI에 올라온 모델들을 공통 Gateway로 다루는 구조에 가깝다.

또한 스키마 변환이 있다고 해서 모든 차이가 사라지는 것은 아니다. 모델마다 tool calling 동작, system instruction 처리, 토큰 한도, 안전 필터, 스트리밍 응답, 에러 메시지 형태가 다르다. Gateway는 입구를 통일하지만 품질 차이를 통일하지는 않는다. 따라서 운영팀은 라우팅 규칙과 함께 모델별 평가 기준을 따로 가져가야 한다.

자체 프록시와 Gateway 방식 비교

자체 프록시는 유연하다. 원하는 provider를 모두 붙이고, 내부 정책을 마음대로 구현하고, 실험 기능도 빠르게 넣을 수 있다. 대신 운영 비용이 생긴다. 특히 보안팀이 붙으면 로그에 프롬프트와 개인정보가 어떻게 남는지, API key가 어디에 저장되는지, 고객별 rate limit이 어떻게 적용되는지 계속 검토해야 한다.

Gateway 방식은 표준화가 장점이다. 인프라팀이 이미 쓰는 배포, 인증, 모니터링, 정책 관리 흐름 안으로 LLM ingress를 넣을 수 있다. 모델 라우팅을 OpenAPI 명세로 관리하면 코드 리뷰와 변경 이력도 명확해진다. 단점은 provider 선택과 세부 동작이 플랫폼 제약을 받는다는 점이다.

실무적으로는 둘 중 하나만 고를 필요가 없다. 초기에는 Gateway로 단순 라우팅, 인증, rate limit을 처리하고, 더 복잡한 실험은 내부 orchestration 서비스에서 처리할 수 있다. 중요한 것은 라우팅 책임을 분리하는 것이다. 제품 코드, 프롬프트 코드, 인프라 정책이 한 파일에 섞이면 나중에 비용 최적화가 어려워진다.

도입 전에 점검할 질문

첫 번째 질문은 “우리에게 모델 라우팅이 정말 필요한가”다. 호출량이 적고 모델도 하나라면 Gateway 라우팅은 과할 수 있다. 하지만 고객별 모델 정책, 지역별 데이터 처리, 비용 기반 폴백, 작업 유형별 모델 분리 중 하나라도 필요하면 검토 가치가 있다.

두 번째 질문은 “평가 데이터가 있는가”다. 라우팅은 평가 없이는 위험하다. 저렴한 모델로 돌렸을 때 실제 품질이 얼마나 떨어지는지, 어떤 입력에서 실패하는지 알아야 한다. 라우팅 규칙은 감으로 만들면 안 된다.

세 번째 질문은 “관측성이 충분한가”다. 적어도 가상 모델명, 실제 backend, latency, token usage, error code, fallback 여부, 사용자 작업 유형은 로그에 남아야 한다. 그래야 장애가 났을 때 모델 문제인지 Gateway 문제인지 애플리케이션 문제인지 구분할 수 있다.

실행 체크리스트

• AI 호출 경로를 모두 나열하고 모델명이 코드에 하드코딩된 곳을 찾는다.
• 작업 유형별로 필요한 품질, 지연 시간, 비용 한계를 정한다.
• OpenAPI 명세에서 가상 모델명과 실제 backend 매핑을 관리할 수 있는지 검토한다.
• Gateway 로그에 실제 모델, latency, 토큰, 에러, fallback 여부가 남는지 확인한다.
• 모델별 테스트셋을 만들고 라우팅 전후 품질 차이를 측정한다.
• 자체 프록시가 이미 있다면 인증, rate limit, 관측성 중 Gateway로 넘길 수 있는 책임을 분리한다.
• Public Preview 기능이므로 프로덕션 핵심 경로에는 롤백 계획을 반드시 둔다.

이 업데이트는 “Google도 OpenAI 호환 API를 지원한다” 정도의 이야기가 아니다. AI 제품의 모델 선택 로직이 애플리케이션 내부 구현에서 인프라 정책으로 이동하고 있다는 신호다.