cloudflare 2026년 8월 7일

Workers AI와 AI Gateway를 하나의 AI 제어 플레인으로 통합하기 (새 탭에서 열림)

observability rest-api ai-gateway load-balancing cloudflare-workers-ai model-routing unified-billing

AI Gateway와 Workers AI는 각각 모델 호출 프록시와 Cloudflare 관리형 추론 서비스로 출발했지만, 이제 하나의 통합 AI 제어 평면으로 수렴하고 있다. 사용자는 단일 바인딩과 REST API를 통해 Workers AI를 포함한 여러 모델 제공자를 호출하면서 관측성, 로깅, 보안, 비용 관리, 결제를 한곳에서 처리할 수 있다. 향후에는 제공자가 아니라 원하는 모델을 기준으로 자동 라우팅·장애 조치·부하 분산까지 수행하는 모델 우선 라우팅을 제공할 계획이다.

통합된 바인딩과 REST API

Workers AI와 AI Gateway는 별도의 호출 경로가 아니라 동일한 env.AI.run() 바인딩으로 통합된다.
gateway: { id: "default" }를 지정하면 기본 AI Gateway를 통해 Workers AI 모델을 호출할 수 있다.
REST API도 통합되어 다음과 같은 /ai/ 엔드포인트를 사용한다.
- https://api.cloudflare.com/client/v4/accounts/{account_id}/ai/run/{model}
- cf-aig-gateway-id: default 헤더로 기본 게이트웨이를 지정
사용자는 처음부터 Workers AI와 AI Gateway 중 어느 제품을 선택할 필요 없이 관측성과 제어 기능이 포함된 경로를 사용할 수 있다.
여러 애플리케이션을 분리하거나 애플리케이션별 정책을 적용해야 하는 경우에는 별도의 이름 있는 게이트웨이를 지정할 수 있다.

자동 관측성과 제어

AI Gateway를 사전에 생성하지 않아도 default 게이트웨이를 처음 인증 요청에 사용하면 자동으로 생성된다.
별도 대시보드 설정 없이 다음 정보가 기록된다.
- 요청 및 응답 전문
- 모델별 토큰 사용량
- 요청 비용 및 비용 귀속
- 지연 시간 분석
- 오류율
기존 Workers AI 직접 호출에 게이트웨이 옵션만 추가하면 전체 관측성을 활성화할 수 있다.
이후 캐싱 규칙을 사용자 지정하거나 애플리케이션별로 트래픽을 분리하려면 이름 있는 게이트웨이로 변경하면 된다.
프롬프트와 응답까지 확인할 수 있어 모델 동작 디버깅과 AI 출력 감사에 유용하다.

AI Gateway 크레딧과 Workers AI 통합 결제

기존에는 AI Gateway 크레딧을 OpenAI, Anthropic 등 외부 제공자에만 사용할 수 있었다.
이제 동일한 크레딧 지갑으로 다음 서비스의 사용량을 결제할 수 있다.
- OpenAI
- Anthropic
- Workers AI
- 기타 지원 모델 제공자
Workers AI에도 선불 결제가 적용된다.
AI Gateway 통합 결제를 사용하는 Workers AI 이용자에게는 더 높은 요청 한도가 제공될 수 있다.
실제 한도와 상향 요청 방법은 최신 개발자 문서를 확인해야 한다.

모델 우선 라우팅

현재는 사용자가 특정 제공자를 직접 선택해야 하므로, 해당 제공자의 장애나 속도 제한이 애플리케이션 장애로 이어질 수 있다.
향후에는 “어느 제공자를 호출할지”가 아니라 “어떤 모델이 필요한지”를 지정하는 방식으로 전환한다.
- 추론 능력이 높은 모델
- 빠른 요약 모델
- 저렴한 임베딩 모델
AI Gateway가 모델을 호스팅하는 제공자를 선택하고 다음 작업을 자동으로 처리한다.
- 제공자 선택
- 장애 조치
- 부하 분산
- 용량 부족 시 다른 제공자로의 투명한 전환
예를 들어 kimi-k2.7-code를 요청하면 Workers AI, Moonshot API 또는 동일 가중치를 제공하는 다른 검증된 제공자 중 적절한 경로가 선택될 수 있다.
원하면 특정 제공자에 고정할 수도 있다.
검증된 제공자를 사용하고 Zero Data Retention(ZDR) 같은 데이터 처리 요구사항도 반영할 예정이다.

실용적인 적용 방향

새 프로젝트라면 default 게이트웨이를 사용해 별도 설정 없이 로그, 토큰 사용량, 비용, 오류율을 확보하는 것이 권장된다. 애플리케이션이 커지면 이름 있는 게이트웨이로 분리하고 캐싱·보안·라우팅 정책을 세분화하면 된다. 장기적으로는 특정 제공자에 강하게 결합하기보다 모델 중심으로 호출 구조를 설계하는 편이 장애 대응과 비용 최적화에 유리하다.