들어가며: 두 제품이 하나가 된 이유
Cloudflare는 원래 AI Gateway와 Workers AI를 별개의 제품으로 출시했어요. AI Gateway는 외부 모델 제공자(OpenAI, Anthropic 등)로의 프록시 역할을 하면서 관측성·로깅·보안을 담당했고, Workers AI는 Cloudflare가 직접 관리하는 GPU 인프라에서 모델을 호스팅해 추론 API를 제공했죠.
그런데 시간이 지나면서 사용자들의 요구가 하나로 수렴하기 시작했어요. 아키텍처는 달라도, 결국 **"모델에 연결해서 관측성과 제어를 한 곳에서 하고 싶다"**는 목표는 같았거든요. 그래서 Cloudflare가 이번에 두 제품을 하나의 통합된 경로로 합치겠다는 계획을 발표했습니다.
💡 핵심 포인트: 이제 Workers AI를 쓰든 외부 모델을 쓰든, 단일 컨트롤 플레인에서 관측성·과금·보안·로깅을 모두 관리할 수 있게 됩니다.
이 글에서는 이번 통합의 실무적 의미와, 앞으로 예고된 모델 중심 라우팅, 스마트 라우팅까지 정리해볼게요. 근거자료는 Cloudflare 공식 블로그에서 확인하실 수 있습니다.
통합 바인딩과 API: 코드로 보는 변화
가장 먼저 체감되는 변화는 엔트리포인트가 통일된다는 점이에요. 기존에는 Workers AI 바인딩과 AI Gateway 바인딩이 개념적으로 분리되어 있었지만, 이제는 env.AI.run() 하나로 두 제품을 모두 호출할 수 있습니다.
바인딩 호출 예시
// 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', // 내장 게이트웨이를 사용하려면 'default' 지정
},
}
);
return new Response(JSON.stringify(response), {
headers: { 'Content-Type': 'application/json' },
});
},
};
REST API 호출 예시
# 통합된 /ai/ 엔드포인트로 Workers AI를 AI Gateway 경유 호출
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": "프랑스의 수도는 어디인가요?"}],
}'
핵심은 gateway: { id: 'default' } 또는 헤더 cf-aig-gateway-id: default 하나만 추가하면 된다는 거예요. 기존 코드를 거의 건드리지 않고도 관측성과 로깅을 얻게 됩니다.
자동 관측성, 통합 과금, 그리고 다가올 라우팅 혁신
1. 기본 게이트웨이 자동 생성
이번 통합의 가장 즉각적인 혜택은 AI Gateway를 미리 만들지 않아도 된다는 점이에요. default를 게이트웨이 ID로 넘기면, 첫 인증 요청 시 자동으로 생성됩니다. 이후 모든 요청은 전체 요청·응답 페이로드와 함께 로깅되고, 모델별 토큰 수와 비용 귀속이 대시보드 설정 없이 자동 추적돼요.
나중에 커스텀 캐싱 규칙이 필요하거나 애플리케이션별로 트래픽을 분리하고 싶다면, 이름 있는 게이트웨이를 만들어 파라미터 한 줄만 바꾸면 됩니다.
2. Workers AI에도 AI Gateway 크레딧 사용 가능
기존에는 AI Gateway 크레딧을 OpenAI, Anthropic 같은 외부 제공자에만 쓸 수 있었는데, 이제 Workers AI 사용분에도 적용할 수 있게 됐어요. 지갑에 크레딧을 충전해두고 OpenAI, Anthropic, Workers AI 어디에든 쓸 수 있는 통합 과금 구조입니다. 게다가 이 경로를 쓰면 Workers AI 모델의 레이트 리밋이 상향된다고 하니, 트래픽이 많은 팀이라면 체크해볼 만하죠.
3. 모델 중심 라우팅 (Coming Soon)
지금은 모델을 호출하려면 "어느 제공자가 이 모델을 호스팅하는가"를 알아야 해요. 제공자가 다운되거나 레이트 리밋에 걸리면 애플리케이션이 깨지죠. Cloudflare가 준비 중인 모델 중심 라우팅은 이걸 뒤집습니다. 모델만 지정하면 게이트웨이가 제공자 선택·페일오버·로드밸런싱을 처리해요.
# 모델만 지정하면 제공자는 게이트웨이가 알아서 선택
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": "이 함수를 리뷰해줘"}]
}'
Workers AI에 여유가 있으면 관리형 인프라의 이점을, 없으면 다른 제공자로 투명하게 로드밸런싱됩니다. ZDR(Zero Data Retention) 같은 요구사항도 존중된대요.
4. 스마트 라우팅 (Next)
더 나아가 스마트 라우팅은 모델 지정조차 필요 없습니다. Workers AI에서 돌아가는 분류기가 프롬프트를 읽고 작업 유형(코딩, 리서치, 요약, 일반 Q&A), 복잡도, 컨텍스트 중요도를 예측한 뒤, 휴리스틱 스코어러가 큐레이션된 풀에서 최적 모델을 매핑해요. 제로 설정으로 경제성과 성능을 동시에 챙기는 방향이죠.
⚠️ 주의사항과 한계
- 기본 게이트웨이는 편리하지만, 프로젝트가 커지면 반드시 명명된 게이트웨이로 분리하는 걸 권장합니다. 비용 귀속과 캐싱 정책을 세밀하게 제어해야 하니까요.
- 모델 중심/스마트 라우팅은 아직 파일럿 단계입니다. 프로덕션 의존은 GA 이후에 검토하세요.
- 제공자 간 모델 가중치가 동일하더라도 미세한 출력 차이가 있을 수 있어, 엄격한 재현성이 필요한 워크로드는 단일 제공자 고정이 안전합니다.
결론: 지금 바로 시작하는 방법
이번 통합은 "AI 인프라를 직접 관리하지 않고도 관측성과 제어를 확보한다"는 Cloudflare의 방향성을 명확히 보여줍니다. 실무적으로는 다음 순서로 접근해보세요.
- 기존 Workers AI 호출에
gateway: { id: 'default' }한 줄만 추가 → 즉시 로깅·토큰 추적·비용 귀속 확보 - 트래픽이 늘면 명명된 게이트웨이로 분리 → 앱별 캐싱·보안 정책 적용
- 통합 과금 지갑 도입 → 여러 제공자를 오가며 크레딧 관리
- 모델 중심 라우팅 GA 소식 모니터링 → 멀티 프로바이더 리질리언스 확보
🇰🇷 한국 개발 생태계에서의 적용 맥락
국내에서는 여러 LLM 제공자를 동시에 쓰는 경우가 많죠(국산 모델 + 해외 모델 병행). 이때 제공자별 과금·로깅을 각각 관리하는 게 은근한 삽질 포인트인데, 통합 컨트롤 플레인은 이런 환경에서 특히 유용합니다. 다만 국내 리전 이슈나 데이터 주권 요구가 있는 서비스라면 ZDR·리전 정책을 사전에 확인하세요.
📚 다음 단계 학습 방향
- Cloudflare Workers 바인딩 패턴과 환경 변수 관리
- AI Gateway의 캐싱·레이트 리밋 정책 문서 정독
- 멀티 프로바이더 페일오버 아키텍처 설계