하나의 프롬프트가 다른 프롬프트보다 100배 더 많은 비용을 발생시킬 수 있지만, 여러분의 게이트웨이는 그 차이를 구분하지 못합니다. 예를 들어, 500개 토큰(token)의 프롬프트를 포함하는 요청과 50,000개의 검색된 컨텍스트(context)를 동일한 엔드포인트(endpoint)에 밀어 넣는 요청은 요청 카운터(request counter) 입장에서는 동일해 보이지만, 토큰 측정기(token meter) 상으로는 두 자릿수(two orders of magnitude)의 차이가 납니다. Azure OpenAI 가격 페이지의 토큰당 요율은 동일하므로, 토큰이 100배 많으면 비용도 100배가 됩니다. 이것은 벤치마크가 아니라 산술적인 사실입니다.

이것이 바로 Azure에서 요청 기반 정책(request-based policies)으로 AI 비용 거버넌스(cost governance)를 수행할 때 실패하는 이유이며, Microsoft가 이 문제를 해결하기 위해 전용 티어(dedicated tier)를 막 출시한 이유입니다. Tech Community 공지에 따르면: "오늘 우리는 현재 퍼블릭 프리뷰(public preview) 단계인 Azure API Management의 AI Gateway 티어를 소개합니다. 이는 플랫폼 팀에게 목적에 맞게 설계된 경험을 제공합니다." 전용 티어의 등장은 Microsoft가 제품 구조 자체를 통해 LLM 트래픽이 단순한 또 다른 API 워크로드(workload)가 아님을 인정하고 있는 것입니다. Azure API Management의 AI 게이트웨이 스토리는 기존 티어에 덧붙여진 정책들의 번들(bundle)로 시작되었습니다. 하지만 이제는 하나의 제품이 되었습니다. 이러한 변화는 기능 목록보다 더 많은 것을 시사합니다.

Azure에서 일반 게이트웨이가 AI 비용 거버넌스를 처리하지 못하는 이유

모든 클래식 게이트웨이 제어(gateway control)는 요청 비용이 대략 균일하다고 가정합니다. 속도 제한(Rate limits), 할당량(quotas), 스로틀링 티어(throttling tiers), 호출 볼륨에 따른 비용 청구(chargeback by call volume) 등은 모두 A 팀의 요청 1,000개가 B 팀의 요청 1,000개와 거의 동일한 비용이 든다는 전제하에 작동합니다. LLM 트래픽은 이러한 가정을 파괴합니다. 요청당 토큰 수(Token counts)는 수십 배까지 차이가 날 수 있고, 모델 선택에 따라 토큰당 가격이 배로 뛰며, 스트리밍 응답(streaming responses) 방식은 요청이 수락되는 시점에 호출 비용이 얼마인지조차 알 수 없게 만듭니다.

따라서 분당 1,000개의 요청이라는 속도 제한(rate limit)은 비용 제어(cost control)가 아닙니다. 그것은 비용 제어라는 배지를 달고 있는 동시성 제어(concurrency control)일 뿐입니다. 두 팀이 동일한 요청 할당량(request quotas) 하에 있더라도, 한 팀은 다른 팀보다 몇 배나 더 많은 토큰 비용을 발생시킬 수 있으며, 여러분의 게이트웨이 원격 측정(telemetry) 데이터에는 두 팀 모두 규칙을 잘 준수하는 소비자(consumer)로 표시될 것입니다.

우회 패턴은 커뮤니티의 글과 Microsoft 자체 샘플을 통해 잘 문서화되어 있습니다. 즉, 완료 응답(completion response)에서 사용량(usage) 블록을 파싱하고, 사용자 정의 메트릭(custom metric)을 방출하며, 직접 기여도 대시보드(attribution dashboard)를 구축하는 방식입니다. 이는 데모에서는 작동합니다. 하지만 스트리밍(streaming) 방식(API 옵션에 따라 사용량이 스트림 끝에 도착하거나 아예 도착하지 않음), 서로 다른 가격을 가진 여러 모델 배포(model deployments), 그리고 리전 간 장애 조치(failover)를 추가하는 순간 무너집니다. 하나의 배포를 처리하던 사용자 정의 정책(custom policy)은 배포가 늘어나는 순간 유지보수의 부담(maintenance liability)이 됩니다.

만약 여러분의 게이트웨이가 토큰 대신 요청(requests)을 측정한다면, 그것은 거버넌스(governance)가 아니라 모니터링(monitoring)일 뿐입니다. 저는 토큰 수준의 비용 제어를 위한 엔지니어링 사례(the engineering case for token-level cost controls)에서 해당 논거를 더 길게 다룬 바 있으며, 이번 새로운 티어(tier)의 출시는 Microsoft가 그 의견에 동의했음을 의미합니다.

Azure API Management AI 게이트웨이 티어에 실제로 포함된 것과 재포장된 것

공식 발표를 재구성하여 전달하는 이들이 알려주지 않을 정직한 계보를 여기 공개합니다. 주요 헤드라인 기능 대부분은 이번 티어와 함께 처음 등장한 것이 아닙니다. Microsoft는 이미 기존 APIM 티어 내에서 생성형 AI (GenAI) 게이트웨이 정책 (gateway policies) 형태로 이를 출시했으며, 이는 Microsoft Learn의 API Management의 AI 게이트웨이 기능 문서에 기록되어 있습니다. 구체적으로는 토큰 기반 속도 제한 (rate limiting)을 위한 azure-openai-token-limit 및 모델 불가지론적 (model-agnostic) llm-token-limit 정책, 소비자별 토큰 텔레메트리 (telemetry)를 위한 emit-token-metric 정책, Redis 호환 캐시를 기반으로 하는 캐시 조회 (cache lookup) 및 저장 (store) 정책을 통한 시맨틱 캐싱 (semantic caching), 그리고 모델 배포 간 라우팅 및 장애 조치 (failover)를 위한 로드 밸런싱 (load balancing) 및 서킷 브레이커 (circuit breakers) 기능이 포함된 백엔드 풀 (backend pools) 등이 있습니다.

따라서 "Premium 티어 + GenAI 정책"과 새로운 티어 사이의 기능적 차이 (capability delta)는 마케팅에서 암시하는 것보다 작습니다. 발표 자체의 프레임워크에 따르면, 이 티어가 변화시키는 것은 운영 모델입니다. 즉, 직접 작성한 XML 정책 조각 (policy fragments), 별도로 프로비저닝된 캐시, Application Insights에서 직접 조립해야 했던 토큰 대시보드 대신, 주요 트래픽이 모델 호출인 플랫폼 팀을 위한 "목적에 맞게 구축된 경험 (purpose-built experience)"을 제공하는 것입니다.

아래 표에 대한 주의 사항: 왼쪽 열은 현재 Learn 정책 문서에서 확인할 수 있는 내용입니다. 오른쪽 열은 프리뷰 제품에 대한 발표의 포지셔닝을 반영합니다. 이를 독립적으로 테스트된 기능 목록이 아닌 Microsoft의 설명으로 취급해야 하며, 이를 기반으로 아키텍처를 설계하기 전에 반드시 프리뷰 문서를 통해 각 항목을 검증하십시오.

핵심 요점: 이 티어를 기능 체크리스트가 아닌 운영상의 차이(operational delta)를 기준으로 판단하십시오. 기능들은 대부분 이미 존재했습니다. 새로운 것은 패키징(packaging)이며, 패키징은 플랫폼 팀이 실제로 해당 기능을 일관되게 운영할 수 있는지 여부를 결정합니다.

플랫폼 팀의 권력 이동: Shadow AI 억제

강력한 입장: 모든 모델 호출을 중앙 게이트웨이를 통해 라우팅하는 것이 올바른 아키텍처입니다. 이는 여러 옵션 중 하나가 아니라, 올바른 방법입니다. 애플리케이션 팀 전반에 흩어져 있는 OpenAI 및 Azure OpenAI 키는 새로운 Shadow IT이며, 심지어 더 나쁩니다. 왜냐하면 비용은 가변적이고, 데이터 노출은 프롬프트 형태(prompt-shaped)로 발생하며, 감사(audit) 시점에

이제 문서에서 생략된 실무적인 주의사항입니다. 게이트웨이를 구축하기 훨씬 전부터 Azure OpenAI 키를 직접 임베딩해 온 애플리케이션 팀들을 만나기 전까지는 온보딩(Onboarding)이 깔끔해 보일 것입니다. 가장 먼저 닥치는 문제는 그림자 사용(shadow usage)의 발견이며, 이는 고고학 작업과 같습니다. 자격 증명 감사(credential audits), 송신(egress) 검사 등 온갖 작업이 수반됩니다. 전환(Cutover)은 원자적(atomic)으로 이루어지지 않으므로 한동안 병렬 경로를 운영해야 하며, 이는 게이트웨이를 구매한 이유인 "단일 강제 지점(single enforcement point)" 보장을 일시적으로 깨뜨립니다. 또한 중앙 게이트웨이는 새로운 병목 지점(choke point)이 됩니다. 고가용성(high availability)과 추가적인 지연 시간(latency) 홉(hop)을 위한 예산을 책정하십시오. 왜냐하면 당신은 방금 회사의 모든 AI 기능의 크리티컬 패스(critical path)에 자신을 위치시켰기 때문입니다.

핵심 요점: 게이트웨이는 오직 자신을 통과하는 트래픽만을 제어합니다. 팀들이 우회하는 것을 선택할 수 없도록, 백엔드의 키 로테이션(key rotation) 및 모델 엔드포인트로의 직접 접근을 차단하는 네트워크 제어와 함께 도입을 병행하십시오.

가격 책정 및 포지셔닝: APIM AI 게이트웨이 티어가 기존 방식의 개조(retrofitting)보다 유리한 시점

미리보기(preview) 가격에 대한 솔직한 답변은 다음과 같습니다. 이 글을 쓰는 시점에서 Azure API Management 가격 페이지에는 Classic 및 v2 티어만 나열되어 있으며, 전용 AI Gateway 티어 가격은 아직 게시되지 않았습니다. 해당 페이지에 수치가 나타나기 전까지, 해당 티어와의 모든 비용 비교는 수치적이지 않고 구조적입니다. 단위당 수치를 인용하는 사람은 누구나 추측하고 있는 것입니다.

구조적인 질문에는 여전히 실제적인 답이 있으며, 이는 요금표가 아니라 가격 모델의 형태에 달려 있습니다. 기존 방식을 개조(Retrofitting)한다는 것은 전체 API 자산 규모에 맞춘 기존 티어 비용에 Redis 호환 캐시, 관측성(observability) 배관(plumbing), 그리고 모든 AI 대상 API에 걸쳐 정책 XML을 작성하고 유지 관리하는 엔지니어링 시간을 추가로 지불함을 의미합니다. 만약 전용 티어가 발표된 플랫폼 팀의 프레임워크가 시사하는 대로 별도의 인스턴스로 배포된다면, 이는 AI 트래픽이 자체적인 용량과 별도의 청구 항목을 갖게 됨을 의미합니다.

이것이 당신에게 실제적인 의사 결정 기준을 제공합니다:

• 트래픽 구성 (Traffic mix). 만약 AI 호출이 기존 REST 자산에 비해 오차 범위 수준(rounding error)이라면, 기존 시스템을 개조(retrofit)하십시오. 기존 티어의 생성형 AI (GenAI) 정책이 이를 지원합니다. 만약 AI가 게이트웨이 트래픽에서 큰 비중을 차지하거나 빠르게 성장하고 있다면, 전용 인스턴스를 통해 그 확장성(scaling)과 장애 영향 범위(blast radius)를 격리해야 합니다.
• 운영 오버헤드 (Operational overhead). 플랫폼 팀이 이미 APIM 정책 XML에 익숙하다면, 직접 구축(DIY)하는 경로가 보기보다 비용이 적게 듭니다. 만약 그렇지 않다면, 목적에 맞게 설계된 경험(purpose-built experience)이야말로 당신이 실제로 구매하는 제품입니다.
• 격리 및 범위 (Isolation and scope). 별도의 배포는 AI 트래픽에 자체적인 장애 도메인(failure domain)과 자체적인 비용 귀속 경계(cost attribution boundary)를 제공하며, 이는 구조만으로도 비용 재청구(chargeback) 문제의 절반을 해결하는 것입니다.

단순히 예시를 위한 계산으로서, 업계 표준 입력값을 사용하면 (자신의 데이터에 맞춰 조정하십시오. 실제 값은 다를 수 있습니다): 맞춤형 토큰 측정(token-metering) 정책을 유지하는 데 한 달에 20 엔지니어링 시간을 소비하는 팀은, 해당 티어에서 설정만으로 해결해 주겠다고 약속한 작업에 풀타임 엔지니어(FTE)의 약 8분의 1을 소모하고 있는 것입니다. 숙련된 시니어 엔지니어의 비용을 기준으로 산정하면, 이 반복적인 8분의 1 FTE 비용이 대부분의 합리적인 요금표(rate-card) 차이를 압도합니다. 이는 제가 실제로 제한되지 않는 지출 한도(the spend caps that don't actually cap)에서 계속해서 강조하는 것과 같은 교훈입니다. AI 비용 제어에서 비싼 부분은 결코 SKU가 아니라, SKU의 공백을 메우기 위해 수행하는 엔지니어링 작업입니다.

미리 보기(Preview)는 미리 보기일 뿐입니다

이 티어에 예산을 할당하거나 아키텍처 확약을 하기 전에 Microsoft의 미리 보기 추가 약관(supplemental terms for previews)을 읽어보십시오. 미리 보기 기능은 변경되거나 철회될 수 있으며, SLA(서비스 수준 계약)가 제공되지 않고, 프로덕션 지원 약속은 GA(일반적으로 사용 가능) 서비스와 다릅니다. 미리 보기에서 보이는 가격, 약관 또는 지역 지원 범위가 GA까지 유지될 것이라고 가정하지 마십시오.

트래픽 구성과 조직적 범위를 결정하십시오. 기능 체크리스트만으로는 결정할 수 없습니다. 왜냐하면 대부분의 기능은 두 경로 모두에 존재하기 때문입니다.

미리 보기 주의 사항 및 첫 주 도입 플레이북

아직 하지 말아야 할 것: 프로덕션 크리티컬 (production-critical) 워크로드, 수익 경로를 차단할 수 있는 엄격한 예산 집행, 또는 전면적인 APIM 마이그레이션. 프리뷰 (Preview)는 베이스라인 (baseline)을 구축하기 위한 것이지, 의존성 (dependency)을 형성하기 위한 것이 아닙니다.

다음은 측정된 결과가 아닌 권장 사항으로서 제가 제안하는 첫 번째 단계입니다:

1. 하나의 대규모 내부 AI 워크로드 선정: 고객 대면 경로(customer-facing path)에 프리뷰 게이트웨이를 사용하는 것은 자가당착적인 장애를 초래할 수 있으므로 '내부'용이어야 합니다. 또한 토큰 변동성 (token variance)이 빠르게 나타나도록 '대규모'여야 합니다.
2. AI Gateway 티어를 통해 라우팅: 기존의 직접 경로를 폴백 (fallback)용으로 유지하십시오. 네, 이는 일시적으로 단일 집행 지점 (single-enforcement-point) 원칙을 위반합니다. 파일럿 (pilot) 단계에서는 이를 수용하십시오.
3. 2~4주 동안 소비자별 토큰 지출 측정: 팀별, 앱별, 모델 배포별로 측정하십시오. 이 기간은 측정된 결과가 아니라 사용 가능한 분포를 얻기 위한 권장 사항입니다. 노이즈가 많은 워크로드는 더 긴 시간이 필요할 수 있습니다.
4. 현재의 귀속 (attribution) 방식과 비교: 대부분의 조직에서 비교 대상은 '없음'일 것이며, 그 사실 자체가 리더십에 보고할 발견 사항이 됩니다.

한 가지 주의 사항을 더 추가하자면: 서비스가 프리뷰 상태인 동안에는 프리뷰 리전 가용성과 기능 범위가 변동될 수 있습니다. 따라서 이 블로그 포스트를 포함한 그 어떤 글이 아니라, 현재의 문서를 통해 귀하의 리전에서 배포 가능한 것이 무엇인지 확인하십시오.

핵심 요약: 지금 프리뷰를 사용하여 토큰 지출 베이스라인을 구축하십시오. 이를 수행하는 팀은 GA (General Availability) 채택을 가격 결정의 문제로 만들지만, 기다리는 팀은 이를 탐색 프로젝트로 만들게 됩니다.

더 큰 신호: Azure는 AI를 중심으로 인프라를 수직 계열화하고 있다

이번 출시를 다른 형제 서비스들과 나란히 놓고 보면 하나의 방향성이 나타납니다. 전용 개발 환경으로서의 AI Foundry, 에이전트 전용 런타임 (runtime) 및 툴링 (tooling), 그리고 10년 넘게 GA 상태였던 게이트웨이 제품의 AI 전용 티어 출시까지. Azure는 일반 목적의 서비스에 AI 기능을 덧붙여 완료했다고 말하는 대신, AI 워크로드에 일급 시민 (first-class) 인프라 대우를 제공하고 있습니다.