배경: 왜 두 제품이 하나가 되는가
Cloudflare에는 처음부터 두 개의 AI 제품이 있었습니다. 하나는 AI Gateway — 어떤 모델 제공자든 프록시로 감싸서 관측성, 로깅, 접근 제어, 보안을 붙여주는 제품. 다른 하나는 Workers AI — Cloudflare가 직접 관리하는 GPU 인프라에서 모델을 호스팅하고 추론 API를 제공하는 서비스입니다.
아키텍처는 달랐지만 사용자 입장에서는 목적이 같았어요. "모델에 안전하게 연결해주는 컨트롤 플레인"이 필요했던 거죠. 그래서 Cloudflare는 두 제품을 하나의 경로로 합치겠다고 선언했습니다. Workers AI를 포함한 어떤 제공자에 연결하든, 관측성·과금·보안·로깅을 단일 컨트롤 플레인에서 관리하는 그림입니다.
이 글은 단순한 제품 발표가 아니라, AI 인프라 추상화 계층이 어디로 진화하는지를 보여주는 신호라서 트렌드 관점에서 짚어볼 만합니다. 근거자료는 Cloudflare 공식 블로그에서 확인할 수 있어요.
핵심 변화 1: 바인딩과 API의 통합
가장 먼저 체감되는 변화는 엔트리포인트 통합입니다. 이제 Workers 바인딩(env.AI)과 REST API(/ai/)가 동일한 경로로 AI Gateway와 Workers AI를 호출합니다. "AI Gateway 바인딩"과 "Workers AI 바인딩"이 따로 존재하지 않는다는 뜻이죠.
특히 실무에서 반가운 부분은 default 게이트웨이입니다. 게이트웨이를 미리 만들지 않아도, gateway.id에 'default'를 넘기면 첫 인증 요청 시 자동으로 생성됩니다.
// Workers AI를 AI Gateway 경유로 호출하는 바인딩 예시
export default {
async fetch(request, env) {
const response = await env.AI.run(
'@cf/zai-org/glm-5.2',
{
messages: [
{ role: 'user', content: '프랑스의 수도는 어디인가요?' },
],
},
{
gateway: {
id: 'default', // 내장 게이트웨이 사용 (자동 생성)
},
}
);
return new Response(JSON.stringify(response), {
headers: { 'Content-Type': 'application/json' },
});
},
};
REST API도 마찬가지입니다. cf-aig-gateway-id 헤더에 default를 넣기만 하면 됩니다.
curl "https://api.cloudflare.com/client/v4/accounts/{account_id}/ai/run/@cf/zai-org/glm-5.2" \
-H "Authorization: Bearer {api_token}" \
-H "Content-Type: application/json" \
-H "cf-aig-gateway-id: default" \
-d '{
"messages": [{"role": "user", "content": "프랑스의 수도는 어디인가요?"}]
}'
이 통합의 실무적 의미는 명확합니다. "어느 제품부터 써야 하지?"라는 의사결정 비용이 사라진다는 것. 처음부터 관측성과 로깅이 붙은 상태로 시작할 수 있으니까요.
핵심 변화 2: 통합 과금과 모델 우선 라우팅
자동 관측성
이제 Workers AI 사용자는 게이트웨이를 별도로 만들 필요 없이 **모든 요청에 대한 로깅, 토큰 카운트, 비용 귀속(cost attribution)**을 자동으로 얻습니다. 대시보드에서 지연 시간 분석, 에러율, 실제 프롬프트/응답 페이로드까지 확인 가능하죠. 모델 동작을 디버깅하거나 AI 출력을 감사해야 하는 팀에게는 "눈 감고 비행"하던 상황에서의 큰 업그레이드입니다.
AI Gateway 크레딧으로 Workers AI 결제
지금까지 AI Gateway 크레딧은 OpenAI, Anthropic 같은 외부 제공자에만 쓸 수 있었습니다. 이번 업데이트로 Workers AI 사용분에도 동일한 크레딧 지갑을 쓸 수 있게 되었습니다. 하나의 지갑에 크레딧을 충전하고, OpenAI·Anthropic·Workers AI 어디에든 배분해서 쓰는 그림입니다. 통합 과금 경로를 쓰면 Workers AI의 레이트 리밋이 상향되는 인센티브도 붙습니다.
예고된 기능: 모델 우선 라우팅과 스마트 라우팅
| 구분 | 기존 (Provider-first) | 신규 (Model-first) |
|---|---|---|
| 사고 단위 | "어느 제공자를 호출하지?" | "어떤 모델이 필요한가?" |
| 장애 대응 | 앱 레벨 재시도/폴백 직접 구현 | 게이트웨이가 자동 failover |
| 부하 분산 | 수동 | 제공자 간 자동 로드밸런싱 |
| 설정 부담 | 제공자별 관리 | 모델명만 지정하면 끝 |
예를 들어 kimi-k2.7-code 모델을 요청하면, Workers AI에 여유가 있으면 관리형 인프라 혜택을, 없으면 다른 제공자로 투명하게 로드밸런싱됩니다. 여기에 더해 스마트 라우팅은 프롬프트를 분류기로 읽어서 (코딩/리서치/요약/일반 Q&A) 작업 유형과 복잡도를 판단한 뒤 최적 모델을 자동 선택하는 단계까지 예고되어 있습니다.
# 모델 우선 라우팅 (파일럿 예정) 예시
curl -X POST "https://api.cloudflare.com/client/v4/accounts/{account_id}/ai/v1/chat/completions" \
-H "Authorization: Bearer {api_token}" \
-H "cf-aig-gateway-id: my-gateway" \
-H "Content-Type: application/json" \
-d '{
"model": "kimi-k2.7-code",
"messages": [{"role": "user", "content": "이 함수를 리뷰해줘"}]
}'
인프라 추상화가 점점 위로 올라오는 흐름은 Azure Multicloud Interconnect가 보여준 멀티클라우드 연결 전략과도 궤를 같이합니다. 결국 "어디에 있느냐"보다 "어떻게 안전하게 연결하느냐"가 경쟁력이 되는 시대입니다.
주의사항과 실무 적용 포인트
1. default 게이트웨이의 함정
편리하지만, 모든 요청이 하나의 게이트웨이로 몰리면 프로젝트별 비용 분리가 어려워집니다. 애플리케이션 단위로 트래픽을 나눠야 한다면 처음부터 명명된 게이트웨이를 만드는 편이 낫습니다. "일단 default로 시작 → 나중에 분리"는 로그 히스토리가 섞이는 대가를 치를 수 있어요.
2. 모델 우선 라우팅은 아직 파일럿
failover와 로드밸런싱은 매력적이지만, 출력 일관성이 중요한 워크로드(예: 정형화된 JSON 응답 파싱)에서는 제공자가 바뀌면서 미세한 출력 차이가 발생할 수 있습니다. ZDR(Zero Data Retention) 같은 컴플라이언스 요구사항도 제공자별로 확인이 필요합니다.
3. 한국 개발 생태계 맥락
국내에서는 여전히 특정 벤더(예: 국산 LLM 또는 사내 프라이빗 모델)를 고정해서 쓰는 경우가 많습니다. 모델 우선 라우팅의 진짜 가치는 "여러 제공자를 넘나드는 환경"에서 나오므로, 단일 제공자만 쓰는 팀에는 당장의 이득이 크지 않을 수 있습니다. 다만 관측성 자동화와 통합 과금은 벤더와 무관하게 즉시 이득이 있는 기능이니, 이 부분부터 도입해보는 걸 추천합니다.
다음 단계 학습 방향
- 이미 Workers AI를 쓴다면: 기존 호출에
gateway: { id: 'default' }만 추가해서 로깅/토큰 추적을 바로 켜보세요. - AI Gateway를 쓴다면: 크레딧 지갑에 Workers AI를 얹어 통합 과금과 상향된 레이트 리밋을 실험해보세요.
- 아키텍처 관점이라면: 산탄데르의 플랫폼 엔지니어링 사례처럼 "개발자 경험을 추상화 계층으로 흡수"하는 패턴이 AI 인프라에서도 반복되고 있다는 점을 눈여겨볼 만합니다.
결국 이번 통합의 본질은 "모델을 부르는 일"에서 "모델을 부르는 방식을 관리하는 일"로 무게중심이 이동한다는 것입니다. 애플리케이션 코드는 그대로 두고, 라우팅·과금·관측성은 플랫폼에 위임하는 그림 — 이 방향이 앞으로 몇 년간 AI 백엔드 설계의 기본값이 될 가능성이 높습니다.