AI Gateway는 무엇을 통제해야 하나 — 엔터프라이즈 도입 기준과 구현 경로

AI 제품 하나라면 모델 SDK에 API 키를 넣고 사용량 로그를 붙여도 된다. 제품 수가 늘면 얘기가 달라진다. 같은 코드가 여러 저장소에 생기고 팀마다 키 보관 방식이 달라진다. 비용 태그 이름도, 프롬프트와 응답을 기록하는 범위도 제각각이다. 보안팀이 차단 규칙을 내놓을 때마다 모든 제품을 다시 배포한다.

AI 게이트웨이가 필요한 때는 특정 모델을 쓰기 시작한 날이 아니다. 조직이 모델 호출을 하나의 운영 대상으로 다뤄야 하는 순간이다. 공급자 API 앞에 프록시 하나를 두는 데서 끝나지 않는다. 신원, 정책, 비용, 라우팅, 감사 증적이 같은 집행 경로를 지나야 전사 제어 계층이 된다.

직접 호출이 전사 운영에서 무너지는 이유

직접 호출은 빠른 실험에 적합하다. 전사 운영에서는 횡단 기능이 제품 수만큼 복제된다.

키를 중앙에 넣어도 키 문제가 끝나지는 않는다. 애플리케이션이 게이트웨이를 거치지 않고 공급자를 직접 부르면 공격자와 내부 사용자 모두 정책을 우회한다. IAM, 네트워크 외부 통신, 공급자 조직 정책을 묶어 직접 경로를 닫아야 한다. Bedrock 자격증명 유출과 LLMjacking 대응에서 다룬 단기 자격증명과 모델·리전 제한도 이 경계에 놓인다.

고객사 A에서는 프로젝트보다 키가 먼저 늘었다

고객사 A는 사내 AX 프로젝트에서 OpenAI, Google Gemini, Anthropic의 공개 LLM API를 함께 사용한다. 초기에는 각 프로젝트가 필요한 공급자의 키를 따로 발급받았다. AX 프로젝트가 늘자 새 키를 만들고 소유자를 기록했다. 종료된 프로젝트의 키를 회수하고 비용을 나누는 관리 방식도 한계에 닿았다. 어느 키가 운영 중인지 확인하는 일과 모델을 호출하는 일의 속도가 더는 맞지 않았다.

이 고객사는 LiteLLM 기반 AI 게이트웨이를 구성해 AX 프로젝트의 모델 호출을 하나의 경로로 통합하고 있다. 목표는 공급자 SDK를 하나로 바꾸는 데 그치지 않는다. 애플리케이션에서는 공급자 키를 걷어낸다. 프로젝트마다 별도의 가상 키나 워크로드 자격 증명을 발급하고 모델 허용 목록, 사용 한도, 로그 필드를 같은 정책으로 운영한다.

기존 키를 게이트웨이 뒤로 옮기는 것만으로는 통합이 끝나지 않는다. 현재 키와 호출 주체를 먼저 목록화한다. 애플리케이션을 가상 키로 전환한 뒤 네트워크와 공급자 정책으로 직접 호출을 거부한다. 이 마지막 단계가 빠지면 새 게이트웨이 옆에 예전 키 경로가 그대로 남는다.

엔터프라이즈 요구사항은 여섯 가지 계약으로 쓴다

제품 기능 목록을 그대로 RFP에 옮기면 후보마다 체크 표시가 비슷해진다. 기능 이름 대신 통제가 실패했을 때의 동작과 남아야 할 증거를 계약으로 적는 편이 낫다.

NIST의 생성형 AI 프로필은 조직 콘텐츠에 접근하는 제3자를 목록화하라고 권고한다. 승인 공급자와 오픈소스·상용 구성요소도 지속해서 평가한다.¹ 게이트웨이는 이 공급망을 한곳에서 집행하고 기록하는 수단이다. 다만 NIST가 요구하는 책임 체계까지 제품이 대신 만들지는 않는다.

OWASP의 2025 LLM 위험 목록도 같은 경계를 드러낸다. 게이트웨이의 속도 제한과 토큰 상한은 무제한 소비를 줄인다. PII 검사와 로그 정책은 민감 정보 노출을 낮춘다. 프롬프트 주입, 부적절한 출력 처리, 과도한 에이전트 권한은 애플리케이션의 데이터 권한과 도구 설계까지 함께 고쳐야 한다.²

비용 상한은 실시간 제동 장치다

게이트웨이가 계산하는 비용은 대개 모델명과 입출력 토큰 수에 단가표를 적용한 추정치다. 공급자 청구는 예약 처리량, 캐시 토큰, 배치 할인, 리전, 계약 단가까지 반영한다. 실시간 상한은 과사용을 끊는 자동 차단 장치다. 재무 마감에는 공급자 청구 데이터와 대사한다.

참고 링크의 LiteLLM 실측에서는 $0.5 상한을 둔 키가 $0.607을 사용한 뒤 차단됐다. 요청 접수 시점의 누적액으로 판단해 실행 중인 요청분만큼 초과했다.³ Claude Apps Gateway의 Spend Limits도 정가 기준 추정치이며 청구서가 아니라고 명시한다. 조직은 허용 가능한 초과 폭, 갱신 주기, 동시 요청 처리, 공급자 청구와의 오차까지 정해야 한다.⁴

비용 귀속 단위도 미리 정한다. 사용자만 기록하면 백그라운드 작업을 설명하지 못한다. API 키만 기록해도 한 키를 공유하는 여러 기능을 나누지 못한다. 최소한 조직, 부서, 프로젝트, 환경, 애플리케이션, 사용자 또는 워크로드, 모델, 사용자 요청을 연결해야 비용 가시화와 비용 배부가 성립한다.

Bedrock 키 탈취는 게이트웨이의 실패 시험이다

Bedrock 자격증명 유출과 LLMjacking 대응에서 다룬 사고는 탈취된 AWS 자격증명이 InvokeModel 권한을 가진 데서 시작했다. 공격자는 새 리소스를 만들지 않고 모델 API만 호출해 비용을 피해 계정으로 넘겼다. AI 게이트웨이는 이 공격을 자동으로 없애지 않는다. 탈취된 키가 Bedrock을 직접 호출할 수 있다면 공격 트래픽은 게이트웨이의 인증, 예산, 로그를 모두 우회한다.

게이트웨이가 폭발 반경을 줄이려면 호출 경로부터 바꿔야 한다.

게이트웨이 실행 환경의 IAM 역할은 그만큼 가치가 높은 표적이 된다. 이 역할에는 필요한 모델·리전·동작만 허용하고 개발·스테이징·운영 환경의 자격증명을 분리한다. 게이트웨이 자체가 침해됐을 때를 가정해 비밀 정보 조회, 정책 변경, 호출 실행 권한도 한 주체에 몰지 않는다. 출시 전에는 게이트웨이를 거치지 않은 Bedrock 호출이 거부되는지, 가상 키 하나를 폐기해도 다른 프로젝트가 계속 동작하는지 시험한다.

관찰성은 원문 수집량이 아니라 추적 가능성으로 평가한다

여러 AI 제품이 각자 관찰성과 과금을 구현하면 같은 요청 수도 뜻이 달라진다. 한 제품은 사용자 요청을 세고 다른 제품은 재시도와 대체 모델 전환을 각각 센다. 게이트웨이에서는 사용자 관점의 요청과 실제 공급자 호출 시도를 분리한다. 그래야 성공률, 비용, 대체 전환 비율을 한 흐름 안에서 해석한다.

OpenTelemetry의 GenAI 의미 규약은 작업, 공급자, 요청·응답 모델, 입출력 토큰 같은 공통 속성을 정의한다. 프롬프트, 응답, 도구 인자는 민감하고 큰 데이터라 기본 수집 대상에서 빠진다.⁵ 운영 기본값은 지표만 수집하는 방식이다. 원문은 승인된 용도와 제한된 보존 기간에만 별도 승인 후 수집하는 편이 안전하다.

의미 기반 캐시는 비용 기능인 동시에 데이터 격리 기능이다. 테넌트, 권한, 모델, 시스템 프롬프트와 정책 버전을 캐시 키에서 빼면 다른 사용자나 이전 정책의 응답이 재사용된다. 민감한 질의, 시점에 따라 답이 변하는 질의, 도구 실행 결과는 캐시 제외 조건부터 정한다.

Claude 전용 관문과 엔터프라이즈 AI 게이트웨이는 범위가 다르다

Claude Apps Gateway는 나쁜 제품이 아니라 범위가 선명한 제품이다. Claude Code와 Claude Desktop을 사내에 배포하고 OIDC 로그인, 관리형 설정, 사용자·그룹별 사용 상한, OTLP 텔레메트리를 강제하려는 조직에 맞는다. Bedrock을 상위 공급자로 두면 공급자 자격증명을 개발자 단말에 배포하지 않아도 된다.⁴

이 접근을 전사 AI 게이트웨이의 기준으로 삼으면 범위가 좁아진다. Claude 중심 클라이언트 정책이 핵심이라 여러 제품의 OpenAI 호환 API, 다양한 모델 공급자, 중앙 프롬프트·가드레일 운영, 범용 서비스 워크로드를 모두 포괄하지 않는다. 개발자가 별도 AWS 자격증명을 보유하면 Bedrock 직접 호출도 가능하다. 게이트웨이만 배치해서는 우회를 막지 못한다.

MCP 게이트웨이도 다른 경계다. AI 게이트웨이는 모델 추론 호출을 통제하고 MCP 게이트웨이는 도구 탐색, 도구 권한 부여, 프로토콜 라우팅을 맡는다. 에이전트 시스템의 요건에 따라 둘을 함께 둔다. MCP와 AgentCore의 상태·권한 경계를 같은 제품 이름으로 뭉개지 않는 이유다.

네 가지 도입 경로를 같은 질문으로 비교한다

AWS의 Multi-Provider Generative AI Gateway Guidance는 LiteLLM 앞에 CloudFront·WAF·ALB를 둔다. RDS·Redis·Secrets Manager·S3도 결합한다. Bedrock과 외부 공급자를 같은 OpenAI 계열 인터페이스로 묶는 참조 구현이다.⁶ AWS 리소스를 쓴다는 사실보다 진입 계층, 무상태 데이터 평면, 정책 저장소, 비밀 저장소, 증적 저장소를 분리한 구조를 참고할 만하다.

Portkey를 검토할 때 확인할 것

Portkey의 배포 모델을 한 문장으로 단정하기는 어렵다. 공식 엔터프라이즈 문서는 Portkey 관리형 SaaS, 고객 VPC에 데이터 평면을 두는 하이브리드, 모든 구성요소를 내부에 두는 완전 분리형 배포를 구분한다.⁷

하이브리드에서는 프롬프트와 응답을 처리하는 게이트웨이를 고객 환경에 둔다. 로그 저장소는 고객 환경 또는 Portkey Cloud 중에서 고른다. 관리 UI와 설정을 가진 제어 평면은 Portkey가 운영하며 데이터 평면은 정책·키·공급자 설정을 주기적으로 동기화한다. 엄격한 “외부 통신 없음”이 요구사항이면 완전 분리형이 검토 대상이다. 공급자 키 역시 Portkey에 값을 저장하는 대신 AWS Secrets Manager, Azure Key Vault, HashiCorp Vault의 참조 값만 제어 평면에 두는 구성을 지원한다.⁸

Portkey를 다른 후보와 같은 선상에서 검토하려면 네 가지를 확인한다.

• 모델 공급자와 AI 제품이 여러 개이고 팀별 비용·정책을 하나의 UI와 API에서 운영하는가.
• 자체 게이트웨이 엔진보다 SSO, RBAC, 감사, 프롬프트·설정 버전, 가드레일 운영면을 빨리 확보하는 일이 중요한가.
• SaaS, 하이브리드, 완전 분리형 가운데 보안 요구에 맞는 배포 모델을 상용 계약으로 고를 수 있는가.
• 게이트웨이를 공통 플랫폼으로 운영할 책임자가 있는가.

제어 평면을 내부에서 소유하고 정책 엔진을 깊게 바꾸려는 조직에는 LiteLLM 기반 자체 구축이 더 자연스럽다. 다만 플랫폼 팀이 DB·캐시·관측 데이터·업그레이드를 감당해야 한다. 실제 범위가 Claude Code 사내 배포뿐이라면 Claude Apps Gateway가 더 작고 정확한 해답이다.

Portkey를 후보로 검토한다면 데모 화면보다 여섯 항목을 계약서와 시험 결과에 남긴다.

1. 배포 모델별 프롬프트, 응답, 추적 정보, 집계 지표, 설정, 비밀 참조 값의 저장 위치와 외부 통신
2. 제어 평면·캐시·로그 저장소 장애 때 기능별 허용·차단 원칙과 마지막 정상 설정의 유효 기간
3. SSO, 조직·워크스페이스 RBAC, 감사 로그, 예산·가드레일의 라이선스 범위
4. 공급자 단가 갱신, 맞춤 단가, 청구 대사, 처리 중인 요청의 예산 초과 처리
5. 설정·프롬프트·로그의 내보내기 형식, 다른 게이트웨이로 옮길 때의 API 호환성과 종료 절차
6. 이미지 출처, CVE 대응, 업그레이드·롤백, 지원 시간과 SLA

도입은 관찰, 집행, 기본 경로 순서로 진행한다

첫 단계에서는 공급자 호출과 키를 모두 목록화한다. 제품명보다 책임자, 환경, 데이터 등급, 공급자, 모델, 인증 방식, 월 사용량, 기존 로그·가드레일을 기록한다. NIST가 권고하는 승인 공급자와 제3자 목록도 이때 만든다.

다음에는 게이트웨이를 관찰 모드로 넣는다. 직접 호출과 결과를 비교하면서 사용자·워크로드 귀속, 사용자 요청과 공급자 호출 시도, 비용 추정 오차, 추가 지연을 측정한다. 원문 로그를 켜지 않고도 운영 질문에 답이 나오는지 먼저 본다.

집행 단계에서는 신원과 비밀부터 옮긴다. 공급자 원본 키를 앱에서 제거하고 단기 접근과 테넌트 정책을 적용한다. 예산과 가드레일은 경고 전용으로 두고 오탐과 초과 폭을 측정한 뒤 차단으로 바꾼다. 대체 모델 전환은 응답이 나온다는 이유만으로 켜지 않는다. 대체 모델이 품질 회귀 평가를 통과했을 때만 허용한다.

마지막으로 네트워크와 IAM에서 직접 공급자 호출을 닫고 게이트웨이를 기본 경로로 만든다. 이때 아래 실패 시험을 통과한다.

이 순서는 AI PoC 운영 전환의 여섯 게이트에서 다룬 관찰 가능성, 비용 한도, 롤백 증거를 공통 플랫폼에 적용한다.

필요한 것은 한 통로가 아니라 한 책임 체계다

엔터프라이즈 AI 게이트웨이의 목표는 모든 AI 트래픽을 예쁜 대시보드에 모으는 일이 아니다. 누가 어떤 정책으로 어느 모델을 썼고 얼마를 발생시켰는지, 실패하면 무엇을 차단하고 어디로 전환했는지 설명해야 한다.

LiteLLM 기반 자체 구축, Portkey Enterprise, Claude Apps Gateway는 서로 다른 답이다. 데이터 주권, 제어 평면 소유권, 공급자 다양성, 운영 역량, 배포 속도에 따라 선택도 달라진다. 어느 제품을 골라도 직접 호출 우회, 비용 대사, 로그 정보 보호, 캐시 격리, 장애 허용·차단 원칙을 검증하지 않으면 중앙화는 새로운 단일 장애점으로 남는다.

AI 게이트웨이의 신원·네트워크·고가용성 구조는 클라우드 & 인프라에서, 모델 정책·가드레일·평가와 부서별 운영 모델은 AX 컨설팅에서 함께 설계한다.

참고 자료