[MLOps] AI Gateway란? 토큰·비용·모델·거버넌스를 통제하는 AI Core 아키텍처
AI PLATFORM · AI GATEWAY · CONTROL PLANE · FINOPS
AI Platform의 심장, AI Core
모델 앞에 왜 ‘AI Gateway’가 필요한가
올해 초부터 회사의 AI Platform이 Agentic Platform으로 진화하는 움직임이 있었다.
외국계(미국) 회사 특성상 본사 기술 흐름을 빠르게 습득하고 한국 실무 환경에 맞게 적용해야 하는 입장에서, 이번 Agentic Platform의 핵심인 AI Core layer (AI Gateway)는 꼭 짚고 넘어가야 할 주제였다.
사내에 LLM 하나를 붙일 때는 애플리케이션이 모델 API를 직접 호출해도 된다.
그런데 Use Case가 3개, 10개, 50개로 늘어나면 이야기가 달라진다.
각 팀이 서로 다른 API Key를 들고 다니고, 비싼 모델을 마음대로 호출하고, 누가 하루에 몇 토큰을 썼는지 모르고, 모델 버전이 바뀔 때마다 애플리케이션 코드를 고치고, 사고가 나면 어느 요청이 어떤 모델을 거쳤는지 추적조차 되지 않는다. 이때 필요한 것이 AI Gateway를 중심으로 한 AI Core다.
먼저 용어부터: AI Core, AI Gateway, Control Plane은 같은 말이 아니다
이 영역은 아직 업계 용어가 완전히 표준화되지 않았다. 회사마다 AI Core, GenAI Platform, Model Gateway, LLM Gateway, AI Gateway, Model Access Layer, AI Control Plane을 조금씩 다르게 부른다. 그래서 이름보다 책임을 분리해서 보는 편이 정확하다.
| 영역 | 역할 | 대표 기능 |
|---|---|---|
| AI Core | 기업 공용 AI 기능 집합 | Gateway + Model Catalog + Governance + FinOps + Observability + Safety |
| AI Gateway | 실시간 요청이 통과하는 정책 집행점 | Auth, quota, routing, cache, guardrail, logging |
| Control Plane | 정책과 자산을 관리 | Model lifecycle, budget, approval, policy version, access |
| Data Plane | 실제 inference 요청 처리 | Token counting, route, invoke, retry, stream, meter |
왜 기존 API Gateway만으로는 부족할까
일반 REST API에서는 대개 요청 한 건의 비용 차이가 크지 않다. LLM은 다르다. 요청 수가 아니라 입력 토큰·출력 토큰·캐시 읽기/쓰기·모델 종류·추론 방식이 비용과 용량을 결정한다. 같은 1 request라도 500-token 요청과 100K-context 요청은 비용과 backend 부하가 전혀 다르다. 여기에 streaming, tool calling, reasoning, multimodal input, provider별 quota가 붙는다. AI Gateway는 단순 HTTP proxy보다 모델의 의미를 이해해야 한다.
AI Gateway의 8가지 핵심 책임
1. Model Abstraction — 애플리케이션에서 Provider를 지운다
애플리케이션 코드에 Azure endpoint, Bedrock model ARN, Vertex project와 provider API key가 들어가기 시작하면 platform이 아니라 provider coupling이 된다. Gateway의 첫 역할은 애플리케이션이 논리적 모델 이름만 알도록 만드는 것이다.
POST /v1/chat/completions
{
"model": "enterprise-general",
"messages": [
{"role": "user", "content": "실손보험 보상 기준을 설명해줘"}
]
}enterprise-general은 오늘은 Azure 모델을 가리키고 내일은 Bedrock이나 사내 vLLM endpoint를 가리킬 수 있다. 모델 교체가 애플리케이션 배포가 아니라 Control Plane configuration change가 된다.
2. Token Governance — 호출 횟수가 아니라 AI 자원을 배분한다
AI Platform에서 토큰은 Kubernetes의 CPU/memory request처럼 공유 자원 단위다. 한 앱이 전체 TPM quota를 소진하면 다른 서비스가 throttling될 수 있다. 따라서 사용자·팀·앱별 TPM, 일/월 quota, 요청별 input/output 제한, concurrency, 월 비용 budget을 별도 dimension으로 다뤄야 한다.
<!-- Azure API Management 개념 예시 -->
<llm-token-limit
counter-key="@(context.Request.Headers.GetValueOrDefault("x-team-id"))"
tokens-per-minute="250000"
estimate-prompt-tokens="true"
remaining-tokens-variable-name="remainingTokens" />Microsoft는 Azure API Management AI Gateway에서 TPM/기간별 token quota를 consumer key별로 적용할 수 있고 prompt token을 backend 전에 추정할 수 있다. Google Apigee도 PromptTokenLimit과 LLMTokenQuota를 제공한다.
3. Cost Attribution — 누가 돈을 썼는지 알아야 거버넌스가 시작된다
기업 AI 비용 관리에서 필요한 것은 “이번 달 AI 비용이 얼마인가?”만이 아니다. 어떤 팀·애플리케이션·기능·사용자가 어떤 모델을 얼마나 썼는가를 알아야 한다. Cloud invoice는 재무 정산용이고 Gateway usage ledger는 운영·FinOps 의사결정용이다.
usage_context = {
"team": "customer-platform",
"application": "policy-assistant",
"feature": "rag-answer",
"environment": "prod",
"cost_center": "CC-AI-101",
"user_hash": "sha256:..."
}Amazon Bedrock은 Application Inference Profile로 애플리케이션·워크로드별 비용을 Cost Explorer/CUR에 귀속하고, per-prompt token 상세는 model invocation logs와 request metadata tagging으로 보도록 안내한다. Gateway가 여러 사용자를 대신 호출하면 backend에는 Gateway의 IAM identity만 보일 수 있으므로 user attribution을 별도로 전달해야 한다는 점도 공식 문서에서 다룬다.
4. Intelligent Routing — 모든 질문에 가장 비싼 모델을 쓸 필요는 없다
Routing은 단순 load balancing을 넘는다. 업무 중요도, 데이터 민감도, Model Risk 승인 상태, context length, latency SLO, 비용을 함께 본다.
def route(req):
if req.data_classification in {"CONFIDENTIAL", "PII"}:
return "approved-private-large"
if req.task in {"classification", "intent"}:
return "fast-small"
if req.reasoning_required:
return "reasoning-large"
return "enterprise-general"5. Resiliency — Provider 장애를 애플리케이션이 알 필요 없게 만든다
LLM backend는 TPM/RPM throttling, provisioned capacity 고갈, region 장애를 겪을 수 있다. Retry, circuit breaker, backend health, fallback은 각 앱의 공통 복붙 코드가 아니라 platform policy여야 한다.
Approved Model A
Secondary Region
Approved Model B
기능 제한/Queue
6. Safety / Guardrail — 모델 앞뒤의 공통 보안 검문소
PII detection, prompt injection, harmful content check를 애플리케이션마다 별도로 구현하면 정책이 갈라진다. Gateway에서 공통 baseline을 적용하면 모든 AI 트래픽에 최소 통제선을 강제할 수 있다. Azure API Management는 LLM Content Safety 정책으로 inbound/outbound 검사를 할 수 있고, Google Apigee는 Model Armor 연동으로 prompt injection, jailbreak, sensitive data, malicious URL 등을 검사할 수 있다.
7. Semantic Cache — AI Gateway에서만 가능한 특이한 캐시
일반 API cache는 key가 같아야 하지만 semantic cache는 prompt embedding이 충분히 비슷하면 이전 completion을 재사용한다. Azure API Management와 Google Apigee 모두 이 패턴을 제공한다. 비용과 latency를 줄일 수 있지만 개인화된 금융 응답에는 특별한 주의가 필요하다.
8. Observability — status code만 봐서는 LLM을 운영할 수 없다
Gateway는 provider가 달라도 같은 telemetry schema로 요청을 관찰하게 해준다. 최소한 logical model, physical provider/model, input/output/cache token, latency, TTFT, guardrail 결과, routing reason, fallback 여부, estimated cost를 남겨야 한다.
{
"application": "customer-assistant",
"logical_model": "enterprise-general",
"provider": "azure",
"physical_model": "model-x-2026-08",
"region": "korea-central",
"input_tokens": 1832,
"output_tokens": 427,
"ttft_ms": 710,
"latency_ms": 2360,
"guardrail_result": "pass",
"routing_reason": "default",
"estimated_cost": 0.0217
}Prompt 원문 전체는 기본 운영 로그와 분리하는 편이 좋다. 개인정보와 영업비밀이 들어올 수 있기 때문에 원문 logging은 별도 승인, 마스킹, 암호화, 보존기간이 필요하다.
Control Plane에서는 무엇을 관리해야 하나
Gateway의 runtime 기능만 잘 만들면 절반이다. 실제 플랫폼 운영에서는 “누가 어떤 모델과 정책을 어떤 조건에서 쓸 수 있는가”를 관리해야 한다.
{
"logical_name": "enterprise-general",
"provider": "azure",
"deployment": "prod-general-v5",
"model_version": "2026-08-15",
"regions": ["korea-central"],
"approved_data_classes": ["PUBLIC", "INTERNAL"],
"approved_use_cases": ["RAG_QA", "SUMMARY"],
"model_risk_status": "APPROVED",
"risk_expiry": "2027-02-28",
"max_context": 128000,
"fallback": ["enterprise-general-secondary"]
}이 정도 metadata가 있어야 routing engine이 “기술적으로 호출 가능한가?”가 아니라 “이 데이터와 use case에서 호출해도 되는가?”를 판단할 수 있다.
FinOps: AI Gateway가 비용 플랫폼이 되는 이유
하나의 shared LLM endpoint를 여러 애플리케이션이 쓰면 cloud invoice만으로는 업무별 비용을 알기 어렵다. Gateway에서 usage metadata를 남겨야 팀·앱·기능별 showback/chargeback이 가능해진다.
| Showback | Chargeback | |
|---|---|---|
| 의미 | “당신 팀이 이만큼 썼습니다” | 실제 비용센터에 청구 |
| 초기 플랫폼 | 먼저 권장 | 비용모델 안정 후 |
초기에는 hard budget보다 showback dashboard로 팀별 token, 모델별 비용, cost/request를 보여주는 것이 adoption과 최적화에 더 유용할 수 있다. 이후 budget alert → soft limit → hard limit로 성숙시키는 편이 현실적이다.
- Cost / Successful Answer — 성공한 업무 결과당 비용
- Token / Request — context inflation 감지
- Cache Hit Rate — cache 효과
- Cost by Feature — RAG, Agent planning, summary 등 기능별 비용
- Fallback Rate — primary capacity/안정성 문제
- Budget Burn Rate — 월말 예상 소진 속도
금융권에서 AI Gateway가 특히 중요한 이유
금융권에서 Gateway의 핵심 가치는 cost saving보다 통제의 일관성이다. 모델 사용팀이 늘어날수록 보안·Model Risk·Responsible AI·감사 요구사항을 애플리케이션별로 구현해서는 유지할 수 없다.
- 누가 호출했는가?
- 어떤 업무 목적인가?
- 어떤 모델과 버전을 사용했는가?
- 어느 region/provider로 전달됐는가?
- 어떤 policy version이 적용됐는가?
- Guardrail 결과는 무엇인가?
- 얼마의 token과 비용이 발생했는가?
- Fallback이 발생했다면 왜인가?
Secretless Architecture가 기본이 되어야 한다
애플리케이션마다 provider API key를 배포하는 대신 애플리케이션은 Gateway에 조직 identity로 인증하고, Gateway는 backend provider에 Managed Identity, IAM Role, Service Account 같은 workload identity로 인증하는 구조가 이상적이다. Provider credential 회수·회전·권한 변경이 중앙화된다.
제품으로 보면 누가 이 영역을 하고 있나
| 제품/패턴 | 강점 | 비용/Token | Governance/Safety | Multi-provider |
|---|---|---|---|---|
| Azure API Management AI Gateway | Enterprise API governance와 AI 정책 결합 | Token limit/metrics | Content Safety, JWT, policy | 지원. 전용 AI Gateway tier는 preview |
| Amazon Bedrock Native | AWS IAM/Cost/Guardrail 깊은 통합 | AIP, Projects, invocation metadata | Guardrails/IAM | Bedrock catalog 안 |
| Google Apigee AI Gateway | API Product/Quota와 AI 정책 결합 | PromptTokenLimit, LLMTokenQuota | Model Armor, OAuth/MCP | 정책 기반 routing |
| LiteLLM Proxy | 빠른 multi-provider abstraction | Spend/budget tracking | Virtual keys/guardrail hooks | 매우 강함 |
| Custom Gateway | 내부 규제/정책 완전 맞춤 | 직접 ledger 구현 | 가장 자유로움 | 직접 구현 |
Microsoft는 2026년 API Management에 별도 AI Gateway tier를 public preview로 확장해 Azure OpenAI뿐 아니라 AWS Bedrock, Google Vertex, OpenAI, Anthropic, custom endpoint와 MCP tool까지 하나의 governed endpoint 아래 관리하는 방향을 보여준다. 다만 전용 tier는 현재 preview이므로 금융 production에서는 기존 GA APIM AI policy와 preview 기능을 구분해서 판단해야 한다.
Google Apigee도 token quota, dynamic model routing, semantic caching, Model Armor, MCP security로 확장 중이다. 전통 API Gateway가 request governance에서 AI consumption governance로 이동하는 흐름이다.
직접 설계한다면 AI Core는 이렇게 나뉜다
AI Core
├── Runtime Data Plane
│ ├── AI Gateway
│ │ ├── Authentication / Authorization
│ │ ├── Model Router
│ │ ├── Token Rate Limit / Quota
│ │ ├── Guardrail
│ │ ├── Retry / Circuit Breaker / Fallback
│ │ ├── Semantic / Prompt Cache
│ │ └── Streaming Proxy
│ └── Provider Adapters
│ ├── Azure / Foundry
│ ├── Bedrock
│ ├── Vertex
│ └── vLLM / On-prem
├── Control Plane
│ ├── Model Catalog & Registry
│ ├── Model Risk / Approval Registry
│ ├── Policy Registry
│ ├── Team / App Entitlement
│ ├── Budget / Quota Config
│ └── Prompt / Tool / Agent Catalog
├── Observability & FinOps
│ ├── Usage Ledger
│ ├── Token / Cost Dashboard
│ ├── Trace / Audit
│ ├── Quality / Error Metrics
│ └── Anomaly Detection
└── Security
├── Private Networking
├── Workload Identity
├── Secrets / KMS
├── DLP / PII
└── SIEM IntegrationGateway가 새로운 Single Point of Failure가 되는 문제
모든 AI 트래픽을 Gateway로 모으면 통제는 좋아지지만 Gateway 장애가 모든 AI 서비스로 전파될 수 있다. 따라서 Multi-zone 구성, last-known-good policy, runtime/control plane 분리, 비동기 telemetry, Guardrail fail-open/fail-close 정책이 필요하다.
Agentic AI가 오면 Gateway의 역할은 더 커진다
Chatbot 시대에는 Model API 앞을 통제하면 됐다. Agent는 LLM뿐 아니라 MCP server, OpenAPI tool, internal API를 호출한다. 앞으로 AI Gateway는 Model Gateway + Tool Gateway로 확장된다. “어떤 모델을 써도 되는가?”와 함께 “어떤 Tool을 누구 권한으로 실행해도 되는가?”를 정책으로 강제해야 한다.
실무에서 흔히 실패하는 AI Gateway 설계 7가지
- 모든 Provider 기능을 억지로 하나의 최소공배수 API로 만든다. — provider 고유 reasoning/tool 기능을 잃는다.
- Prompt 원문을 무조건 전부 로그한다. — 새로운 민감정보 저장소가 된다.
- Token quota만 있고 비용 attribution이 없다. — 누가 왜 썼는지 모르면 최적화할 수 없다.
- Routing을 가격만으로 결정한다. — Risk approval과 data residency가 비용보다 먼저다.
- Telemetry backend를 synchronous path에 둔다. — observability 장애가 inference 장애로 번진다.
- Developer self-service가 없다. — 결국 shadow API key가 생긴다.
- Control Plane과 Data Plane을 섞는다. — 관리 UI/정책 DB 장애가 inference를 막는다.
금융권 AI Platform의 현실적인 성숙도 로드맵
| 단계 | 구성 | 핵심 목표 |
|---|---|---|
| Stage 1 | Gateway + SSO/MI + Logging | 모든 AI 호출을 한 경계로 모으기 |
| Stage 2 | Token quota + Usage ledger + Dashboard | 비용과 용량 가시성 확보 |
| Stage 3 | Model catalog + Risk approval + Guardrail | 거버넌스를 코드/정책으로 강제 |
| Stage 4 | Multi-model routing + cache + fallback | 비용·성능·회복탄력성 최적화 |
| Stage 5 | Agent/Tool Gateway + FinOps automation | Agent 행동까지 중앙 통제 |
모델을 안전하고, 예측 가능한 비용으로, 여러 팀이 재사용할 수 있는 기업 공용 자산으로 바꾸는 것이다. AI Gateway는 그 목적을 런타임에서 강제하는 가장 중요한 경계다.
공식 문서 / 더 읽어볼 자료
- Microsoft — AI Gateway capabilities in Azure API Management
- Microsoft Architecture Center — Gateway Offloading for LLM APIs
- Microsoft — LLM Content Safety Policy
- Microsoft — Semantic Caching
- Microsoft — AI Gateway tier (Preview)
- AWS — Track usage and costs in Amazon Bedrock
- AWS — Application Inference Profiles
- AWS — Bedrock Inference Profiles
- Google Cloud — Apigee AI Gateway Capabilities
- Google Cloud — LLMTokenQuota
- Google Cloud — Model Armor
- LiteLLM — LLM Gateway / Proxy