Cloudflare AI Platform은 에이전트 추론 계층으로 언제 쓸 만한가 2026

Cloudflare는 2026년 4월 16일 AI Gateway와 Workers AI를 묶어 에이전트용 통합 추론 계층으로 확장한다고 발표했다.

이 발표를 그냥 “Cloudflare도 AI 플랫폼 한다”로 읽으면 재미가 없다.

더 중요한 질문은 이거다.

개인 개발자나 소규모 팀이 이제 모델 호출 계층을 Cloudflare에 맡겨도 될까.

그리고 더 현실적인 질문도 있다.

언제는 꽤 괜찮고, 언제는 아직 과한가.

나는 이번 발표를 보면서 제품 뉴스보다 운영 구조 쪽이 더 크게 보였다.

AI 앱이 챗봇 하나일 때는 모델 API 키 몇 개를 직접 들고 있어도 버틸 수 있다.

하지만 에이전트가 되면 사정이 바뀐다.

분류 모델 한 번.

계획 모델 한 번.

툴 호출 판단 한 번.

요약 모델 한 번.

사용자에게 보여줄 답변 스트리밍 한 번.

이렇게 한 작업 안에서 추론 호출이 줄줄이 이어진다.

이때 모델 제공자 하나가 느려지면 전체 워크플로우가 느려진다.

호출 하나가 실패하면 뒤쪽 작업도 같이 흔들린다.

운영자 입장에서는 이게 살짝 귀찮은 정도가 아니라, 비용표와 장애표와 로그표가 한꺼번에 달려드는 순간이다.

작은 팀은 여기서 자주 이렇게 된다.

“일단 OpenAI 키 넣고, Anthropic 키 넣고, 나중에 라우팅은 고치자.”

나중은 보통 안 온다.

나중은 배포 장애랑 같이 온다.

이 글은 Cloudflare 발표를 단순 요약하지 않는다.

Cloudflare AI Platform을 에이전트 추론 계층으로 봤을 때, 지금 써도 되는 지점과 아직 기다려야 할 지점을 나눠본다.

한 줄 판단

Cloudflare AI Platform은 “Cloudflare Workers 위에서 에이전트를 만들고, 여러 모델 제공자를 바꿔가며 쓰고, 비용·로그·장애 대응을 한 계층에서 묶고 싶은 팀”에게 가장 먼저 의미가 있다.

반대로 이미 자체 백엔드가 있고, 모델 호출 계층이 잘 분리돼 있고, Cloudflare Workers를 핵심 런타임으로 쓸 생각이 없다면 당장 갈아탈 이유는 약하다.

특히 2026년 4월 18일 기준으로는 REST API 지원과 통합 과금 범위를 공식 문서에서 끝까지 확인해야 한다.

Cloudflare 공식 발표는 Workers의 AI.run()에서 third-party 모델 호출이 가능해졌다고 설명한다.

그리고 Workers를 쓰지 않는 환경을 위한 REST API는 “coming weeks”라고 밝혔다.

즉 지금 바로 가장 매끄러운 경험은 Workers 안에서 나온다.

이 점이 핵심이다.

Cloudflare AI Platform은 범용 LLM 라우터라기보다 Cloudflare 개발자 플랫폼에 붙은 추론 운영 계층에 가깝다.

그 차이를 놓치면 기대치가 꼬인다.

도구는 나쁜 게 아닌데, 기대치가 삐끗하면 멀쩡한 도구도 야근 제조기가 된다.

이런 건 귀엽지 않다.

2026-05-08 업데이트: 첫 화면 운영 분기표

2026년 5월 8일 공식 가격 문서 기준으로, Cloudflare AI Platform을 볼 때 제일 먼저 나눌 것은 “추론이 무료인가”가 아니라 “정적 웹, Worker 실행, 모델 추론, Gateway 관찰 비용을 분리해서 볼 수 있는가”다.

첫 질문	지금 판단	비용 경고
정적 페이지와 계산기만 배포하나	Cloudflare Workers/Static Assets로 먼저 실험	Workers 가격 문서는 정적 자산 요청을 무료·무제한으로 안내하지만, 동적 Worker 호출은 별도다
API 라우팅이나 서버리스 로직이 있나	Free 한도 안에서 시작, 지속 운영이면 Paid 계산	Workers Free는 100,000 requests/day, Paid는 월 최소 `$5`와 10 million requests/month 포함 구조다
Cloudflare-hosted 모델을 직접 호출하나	Workers AI 단가표를 모델별로 확인	Workers AI는 10,000 Neurons/day 무료 할당 후 Paid에서 `$0.011 / 1,000 Neurons`로 과금된다
외부 모델 provider를 관찰·캐시·rate limit하나	AI Gateway부터 붙여도 됨	AI Gateway core features는 무료지만, Guardrails는 Workers AI 추론 비용으로 계산되고 Logpush는 Workers Paid에서 열린다
여러 모델 fallback이 핵심인가	비용보다 로그·품질 차이를 먼저 본다	fallback은 성공률을 올릴 수 있지만 모델별 출력 형식과 품질이 바뀔 수 있다

그래서 Cloudflare를 운영비 0원 플랫폼으로 부르면 너무 납작하다.

정적 웹과 가벼운 Worker는 0원에 가깝게 시작할 수 있다.

하지만 에이전트 추론은 모델 호출량, 출력 토큰, Guardrails 사용 여부, 로그 보관 방식에 따라 바로 비용 항목이 생긴다.

이 글의 canonical 판단도 이쪽이다.

Cloudflare AI Platform은 공짜 마법봉이 아니라 비용·로그·fallback을 한 장부에 모으는 운영 계층이다.

운영비 계산이 먼저 필요하면 AI 서비스 운영비 0원은 어디까지 가능할까 2026를 먼저 보고, 클라우드 실행 공간 자체가 무겁게 느껴진다면 AI 에이전트 시대 클라우드는 왜 다시 불편해졌나 2026와 같이 읽는 편이 낫다.

Cloudflare가 실제로 발표한 것

2026년 4월 16일 Cloudflare는 “Cloudflare’s AI Platform: an inference layer designed for agents”라는 글을 냈다.

핵심은 AI Gateway와 Workers AI를 하나의 통합 추론 계층처럼 묶겠다는 것이다.

공식 발표에서 강조한 첫 포인트는 AI.run()이다.

기존에는 Workers AI의 Cloudflare-hosted 모델을 Workers에서 호출하는 흐름이 중심이었다.

이제는 같은 AI.run() 바인딩으로 OpenAI, Anthropic 같은 third-party 모델도 호출할 수 있다고 설명했다.

Cloudflare-hosted 모델에서 외부 provider 모델로 바꾸는 일을 코드 한 줄 수준으로 줄이겠다는 방향이다.

두 번째 포인트는 모델 카탈로그다.

Cloudflare는 70개 이상 모델과 12개 이상 provider를 하나의 API와 하나의 credit 체계로 접근할 수 있다고 밝혔다.

공식 발표에 언급된 provider에는 Alibaba Cloud, AssemblyAI, Bytedance, Google, InWorld, MiniMax, OpenAI, Pixverse, Recraft, Runway, Vidu 등이 포함된다.

텍스트 모델만이 아니라 이미지, 비디오, 음성 모델까지 확장한다고 했다.

세 번째 포인트는 지연시간이다.

Cloudflare는 전 세계 330개 도시 데이터센터 네트워크를 강조한다.

에이전트에서 중요한 것은 전체 응답 완료 시간만이 아니라 첫 토큰이 나오는 시간이다.

사용자는 전체 추론이 3초 걸리는지보다 “바로 움직이는 느낌”을 먼저 체감한다.

그래서 Cloudflare는 AI Gateway가 사용자와 inference endpoint에 가깝게 위치할 수 있다는 점을 전면에 둔다.

네 번째 포인트는 자동 failover다.

같은 모델이 여러 provider에서 가능하고 한 provider가 내려가면, AI Gateway가 다른 provider로 자동 라우팅할 수 있다고 설명한다.

작은 팀에게 이건 꽤 크다.

직접 만들면 단순 retry와 provider fallback 사이에서 꽤 많은 예외 처리를 해야 한다.

다섯 번째 포인트는 장기 실행 에이전트 복구성이다.

Cloudflare는 AI Gateway가 streaming response를 버퍼링하고, Agents SDK의 checkpointing과 결합하면 에이전트가 중간에 끊겨도 새 inference 호출 없이 응답을 이어받을 수 있다고 설명했다.

이건 발표에서 가장 “에이전트 운영”다운 부분이다.

챗봇 데모에서는 덜 중요해 보이지만, 실제 자동화에서는 한 번 끊긴 작업을 어디서부터 재개할지가 매번 사람을 괴롭힌다.

여섯 번째 포인트는 Replicate 통합과 BYOM 계획이다.

Cloudflare는 Replicate 팀이 AI Platform 팀에 합류했고, Replicate 모델을 AI Gateway로 가져오고 hosted model을 Cloudflare 인프라로 옮기는 통합을 진행 중이라고 밝혔다.

또 Cog 기술을 활용해 사용자가 직접 fine-tuned/custom model을 Workers AI에 올리는 방향도 준비 중이라고 설명했다.

다만 이 부분은 2026년 4월 18일 기준으로 “곧”과 “작업 중”의 영역이 섞여 있다.

프로덕션 의사결정에서는 현재 가능한 것과 예고된 것을 분리해야 한다.

예고는 로드맵이고, 운영은 오늘 새벽 3시에 깨워도 돌아가는 것이다.

둘은 닮았지만 같은 생물은 아니다.

공식 문서 기준으로 보는 제품 경계

Cloudflare AI docs는 Cloudflare AI를 “Cloudflare global network에서 AI 모델을 실행하는 플랫폼”으로 설명한다.

같은 문서에서 Cloudflare AI는 Workers AI에 hosted된 모델과 AI Gateway를 통해 external provider로 proxy되는 모델을 통합한다고 적고 있다.

즉 Cloudflare AI라는 큰 박스 안에 두 축이 있다.

하나는 Workers AI다.

다른 하나는 AI Gateway다.

Workers AI는 serverless GPU 위에서 모델을 실행하는 제품이다.

공식 Workers AI docs는 Free/Paid plan에서 제공되고, Workers, Pages, Cloudflare API 어디서든 호출할 수 있다고 설명한다.

또 Workers AI는 50개 이상 open-source model과 pay-for-what-you-use pricing model을 제공한다고 적고 있다.

AI Gateway는 모델을 직접 호스팅한다기보다, 외부 provider 호출을 관찰하고 제어하는 계층이다.

Cloudflare AI docs는 AI Gateway를 caching, rate limiting, request retries, model fallback 등을 제공하는 제품으로 소개한다.

Agents SDK는 또 다른 층이다.

Cloudflare Agents docs는 Agents SDK가 Durable Objects 위에서 동작한다고 설명한다.

각 agent는 Durable Object 위에서 실행되고, 자체 SQL database, WebSocket connections, scheduling을 가진 stateful micro-server처럼 움직인다.

또 Workers AI, OpenAI, Anthropic, Gemini 등 provider 교체가 가능하다고 설명한다.

이 구조를 단순화하면 이렇게 된다.

에이전트 상태와 실시간 연결은 Agents SDK.

Cloudflare-hosted 모델 실행은 Workers AI.

외부 provider 호출 관찰·제어·fallback은 AI Gateway.

그리고 2026년 4월 16일 발표의 방향은 이 셋을 더 자연스럽게 이어서 “에이전트용 추론 계층”으로 만드는 것이다.

이렇게 보면 Cloudflare의 전략이 조금 선명해진다.

모델 회사가 되겠다는 이야기만은 아니다.

에이전트가 모델을 부르는 길목을 잡겠다는 이야기다.

길목을 잡으면 로그, 비용, latency, fallback, 배포 경험이 따라온다.

운영자는 바로 그 길목에서 피곤해진다.

그래서 이 발표가 TECHTAEK 관점에서는 꽤 흥미롭다.

분기표: 지금 써도 되는 경우

아래 조건에 3개 이상 해당하면 Cloudflare AI Platform을 실험할 이유가 충분하다.

상황	판단	이유
이미 Cloudflare Workers를 앱 런타임으로 쓴다	적극 실험	`AI.run()` 통합의 이점을 바로 받는다
에이전트가 여러 모델을 순차 호출한다	적극 실험	비용·로그·fallback 계층이 필요해진다
사용자 위치가 글로벌하게 흩어져 있다	실험 가치 높음	330 cities 네트워크와 첫 토큰 지연시간 전략이 맞는다
모델 provider를 자주 바꿔 테스트한다	실험 가치 높음	provider 교체 비용을 줄일 수 있다
Cloudflare Agents SDK를 이미 검토 중이다	궁합 좋음	Durable Objects 기반 state와 AI 호출 계층을 같이 묶을 수 있다
작은 팀이라 직접 fallback/router를 만들 여력이 없다	실용적	직접 구현보다 관리형 계층이 낫다
추론 비용을 고객·팀·workflow별로 보고 싶다	실용적	custom metadata 기반 비용 분석 방향과 맞다

여기서 가장 중요한 조건은 “이미 Workers를 쓰는가”다.

현재 발표에서 가장 또렷한 변화는 Workers의 AI.run()에서 third-party model을 호출하는 경험이다.

Workers 위에 앱이 있으면 Cloudflare의 새 추론 계층은 자연스럽다.

요청이 들어온다.

Worker가 실행된다.

AI.run()으로 Cloudflare-hosted 모델이나 external provider 모델을 호출한다.

AI Gateway로 비용과 로그와 fallback을 본다.

Agents SDK를 쓰면 state, WebSocket, scheduling까지 같은 플랫폼 안에서 이어간다.

이 흐름이면 부품들이 서로 맞물린다.

개인 프로젝트에서도 의미가 있다.

예를 들어 Obsidian 노트 요약 에이전트를 만든다고 해보자.

가벼운 분류는 저렴한 모델.

긴 요약은 큰 모델.

태그 추천은 빠른 모델.

블로그 초안 검토는 reasoning 모델.

이렇게 역할별 모델을 나누기 시작하면 API key와 비용 추적이 금방 복잡해진다.

이때 Cloudflare AI Platform은 모델 호출을 한 계층으로 모으는 장점이 있다.

특히 “나는 AI infra를 만들고 싶은 게 아니라 내 제품을 굴리고 싶다”는 팀에게 맞는다.

작은 팀에게 제일 무서운 건 기술 부채가 아니라 운영 부채다.

기술 부채는 가끔 멋있어 보이기라도 한다.

운영 부채는 그냥 조용히 카드값처럼 온다.

분기표: 아직 기다리는 게 나은 경우

반대로 아래 조건이 많으면 아직 기다리는 편이 낫다.

상황	판단	이유
Workers를 쓰지 않고 기존 서버만 쓴다	보류	REST API 지원이 발표 기준 “coming weeks”다
모델 호출 계층을 이미 잘 추상화했다	보류	이득보다 이전 비용이 클 수 있다
provider별 계약·보안·데이터 보존 조건이 핵심이다	보류	각 provider 정책과 Gateway 경유 조건을 별도 확인해야 한다
매우 세밀한 라우팅 정책이 필요하다	보류	관리형 fallback이 내부 정책을 모두 대체하지 못할 수 있다
BYOM이 핵심 요구사항이다	보류	Replicate/Cog 기반 BYOM은 아직 계획과 테스트 영역이 섞여 있다
REST API unified billing이 필수다	확인 후 판단	supported models 문서와 billing 문서를 따로 봐야 한다
특정 provider의 최신 모델을 당일 바로 써야 한다	확인 후 판단	카탈로그 반영 속도가 provider 직접 호출보다 늦을 수 있다

특히 “Workers 바깥에서 쓰려는 팀”은 차분해야 한다.

공식 발표에는 REST API 지원이 곧 나온다고 되어 있지만, 지금 글 작성 시점의 핵심 경험은 Workers 바인딩 쪽이다.

물론 Workers AI 자체는 Cloudflare API에서도 호출할 수 있다고 문서에 나온다.

하지만 이번 발표의 통합 카탈로그, third-party model 호출, one API 경험이 기존 백엔드에서 얼마나 매끄럽게 작동하는지는 REST API 문서와 supported models 문서를 보고 확인해야 한다.

이걸 안 보고 “이제 아무 서버에서나 Cloudflare로 다 라우팅하면 되겠네”라고 하면 위험하다.

또 하나는 과금이다.

Cloudflare 발표는 one set of credits를 언급한다.

하지만 실제 운영에서는 provider별 가격, Cloudflare credit 적용 범위, REST API unified billing 여부, 무료/유료 플랜 경계, rate limit을 따로 확인해야 한다.

작은 팀일수록 과금 구조가 애매하면 나중에 더 아프다.

AI 비용은 자주 “조금씩 새는 물”처럼 보인다.

근데 월말에는 물이 아니라 청구서가 온다.

청구서는 늘 현실적이다.

그리고 이상하게 유머 감각이 없다.

분기표: 쓰면 과한 경우

Cloudflare AI Platform이 멋있어 보여도 모든 프로젝트에 필요한 건 아니다.

상황	판단	설명
모델 하나만 호출하는 단순 챗봇	과함	provider SDK 직접 호출이 더 단순하다
트래픽이 거의 없는 개인 실험	과함 가능	운영 계층보다 빠른 검증이 우선이다
latency보다 모델 품질 하나가 전부인 작업	과함 가능	라우팅 계층보다 모델 선택이 중요하다
provider lock-in을 극도로 피해야 한다	주의	Cloudflare 계층 자체가 또 다른 의존성이 된다
자체 observability stack이 이미 있다	중복 가능	로그·비용·fallback 기능이 겹칠 수 있다

단순한 제품에는 단순한 구조가 이긴다.

예를 들어 개인 블로그 요약 버튼 하나를 만든다면 굳이 추론 계층을 크게 만들 필요가 없다.

OpenAI든 Anthropic이든 Gemini든 하나 골라서 호출하고, 실패하면 사용자에게 재시도 버튼을 보여줘도 된다.

사용자 10명짜리 내부 도구라면 장애 대응보다 제품 검증이 먼저다.

Cloudflare AI Platform이 과한 게 아니라, 지금 내 문제가 아직 그 크기가 아닐 수 있다.

좋은 도구를 너무 일찍 붙이면 제품이 빨라지는 게 아니라 설정 파일이 빨라진다.

설정 파일만 빨라지는 인생, 우리는 이미 충분히 겪었다.

에이전트 운영 관점에서 진짜 포인트

이번 발표의 진짜 포인트는 “모델 카탈로그가 많다”가 아니다.

모델 카탈로그는 중요하지만, 카탈로그만 많으면 marketplace 뉴스에 가깝다.

운영 관점에서 더 중요한 건 추론 호출의 공통 계층이다.

에이전트는 모델을 한 번 부르는 프로그램이 아니다.

여러 번 부르고, 중간 결과를 보고, 도구를 호출하고, 다시 모델을 부르고, 사용자에게 진행 상황을 보여주는 프로그램이다.

이 과정에서 운영자가 봐야 하는 질문이 생긴다.

어떤 workflow가 비용을 많이 쓰는가.

무료 사용자가 너무 비싼 모델을 밟고 있지는 않은가.

한 고객 계정이 전체 추론비를 밀어 올리고 있지는 않은가.

특정 provider 장애가 내 전체 에이전트를 멈추게 하지는 않는가.

사용자가 연결을 끊었을 때 이미 생성 중인 토큰은 버려지는가.

장기 실행 reasoning 모델이 2분 동안 생각하는 동안 state는 어디에 남는가.

이 질문들이 바로 에이전트 운영의 질문이다.

Cloudflare는 이 질문에 AI Gateway, Workers AI, Agents SDK를 묶어서 답하려고 한다.

AI Gateway는 요청 관찰과 제어를 맡는다.

Workers AI는 Cloudflare-hosted model 실행을 맡는다.

Agents SDK는 stateful agent runtime을 맡는다.

발표의 streaming buffer와 checkpointing 조합은 특히 중요하다.

사용자가 브라우저를 닫거나 agent instance가 중간에 끊기는 상황은 실제로 흔하다.

그때 새 inference를 다시 시작하면 비용도 늘고 응답도 꼬인다.

AI Gateway가 streaming response를 버퍼링하고 agent가 checkpoint에서 이어갈 수 있다면, 장기 실행 에이전트의 사용자 경험이 좋아진다.

물론 이건 문서대로 구현했을 때의 이야기다.

실제 앱에서는 checkpoint 위치, idempotency, tool side effect, 결제성 작업 중복 실행 방지까지 같이 설계해야 한다.

여기서 “Cloudflare가 다 해준다”라고 생각하면 위험하다.

Cloudflare는 추론 호출 계층과 runtime primitive를 준다.

내 업무 로직의 중복 실행 방지는 여전히 내가 설계해야 한다.

예를 들어 에이전트가 이메일을 보내는 도중 끊겼다고 해보자.

모델 응답을 이어받는 것과 이메일을 두 번 보내지 않는 것은 다른 문제다.

AI Gateway buffer는 전자에 가깝다.

업무 side effect idempotency는 후자다.

이 둘을 구분해야 운영에서 덜 운다.

운다고 해결되면 좋겠지만, 대부분 로그만 젖는다.

Cloudflare가 유리한 설계

Cloudflare AI Platform이 특히 잘 맞는 설계는 edge-first agent다.

사용자 요청이 전 세계에서 들어오고, frontend와 backend가 Workers/Pages에 가깝고, stateful session은 Durable Objects로 처리하는 구조다.

여기에 Agents SDK를 얹으면 agent 하나가 Durable Object처럼 존재한다.

문서 설명대로라면 각 agent는 SQL database, WebSocket connections, scheduling을 가진다.

사용자와 실시간 연결을 유지하고, scheduled task를 돌리고, state를 보존하는 데 맞다.

이런 앱에서는 추론 계층도 Cloudflare에 붙는 게 자연스럽다.

예를 들어 고객지원 에이전트를 만든다고 하자.

사용자 메시지는 Worker로 들어온다.

Agent Durable Object가 대화 state를 가진다.

분류는 빠른 모델로 한다.

답변 계획은 reasoning 모델로 한다.

도구 호출 결과는 agent state에 저장한다.

최종 응답은 WebSocket이나 SSE로 stream한다.

모델 제공자 장애가 나면 AI Gateway fallback을 쓴다.

비용은 userId, teamId, workflowId metadata로 나눠 본다.

이 설계에서는 Cloudflare AI Platform의 부품들이 한 방향을 본다.

그럴 때는 도입 가치가 있다.

반면 기존 Kubernetes 백엔드, 별도 queue, 자체 retry/fallback, Datadog/OTel 기반 observability, provider별 직접 계약이 이미 있는 팀이라면 이야기가 다르다.

그 팀에게 Cloudflare AI Platform은 대체재가 아니라 일부 기능의 후보일 뿐이다.

이미 잘 굴러가는 추론 gateway가 있다면 굳이 바꿀 필요가 없다.

도구 바꾸는 건 늘 새 장난감처럼 보이지만, 운영에서는 장난감도 인수인계 문서가 필요하다.

여기서 갑자기 낭만이 사라진다.

OpenRouter나 Bedrock과 비교할 때 봐야 할 축

Cloudflare AI Platform을 볼 때 자연스럽게 OpenRouter, AWS Bedrock, 직접 provider SDK 호출과 비교하게 된다.

이 비교에서 단순히 “모델 수가 몇 개냐”만 보면 부족하다.

소규모 팀은 아래 축으로 보면 된다.

비교 축	질문
런타임 결합도	내 앱이 Cloudflare Workers/Agents에 붙어 있는가
모델 폭	내가 필요한 모델이 카탈로그에 있는가
provider 교체	모델명 한 줄 변경 수준으로 바뀌는가
비용 관찰	고객·팀·workflow별 비용을 볼 수 있는가
장애 대응	provider 장애 시 fallback이 가능한가
streaming 복구	끊긴 stream을 다시 이어받을 수 있는가
데이터 정책	provider별 데이터 보존·학습 정책을 확인할 수 있는가
과금 구조	내 호출 방식에서 통합 과금이 명확한가
lock-in	이 계층을 걷어낼 때 비용이 얼마나 드는가

OpenRouter류의 장점은 범용 라우팅과 빠른 모델 접근성일 수 있다.

AWS Bedrock의 장점은 기업 계정, IAM, VPC, AWS 생태계 결합일 수 있다.

직접 provider SDK 호출의 장점은 단순성과 provider 기능의 즉시성이다.

Cloudflare의 장점은 Workers, AI Gateway, Workers AI, Agents SDK가 같은 개발자 플랫폼 안에서 만난다는 점이다.

그래서 비교의 핵심은 “나는 Cloudflare 위에서 agent runtime까지 가져갈 생각이 있는가”다.

그렇다면 Cloudflare 쪽의 통합감이 커진다.

그렇지 않다면 범용 gateway와 직접 SDK 호출도 충분히 경쟁력이 있다.

기술 선택은 인기투표가 아니다.

내 장애가 어디서 날지를 미리 찍어보는 게임에 가깝다.

대부분의 경우 정답은 “내가 제일 대충 만든 부분”이다.

실사용 체크리스트

Cloudflare AI Platform을 실험하기 전에 아래 항목을 체크하자.

내 앱의 주 런타임이 Workers인가.
AI.run()을 쓰는 경로와 REST API가 필요한 경로를 구분했는가.
필요한 모델이 Cloudflare model catalog 또는 AI Gateway supported models에 있는가.
그 모델이 Workers binding에서 지원되는지, REST API에서 지원되는지 확인했는가.
Cloudflare-hosted model과 external provider model의 비용 차이를 적었는가.
one set of credits가 내 사용 방식에 어떻게 적용되는지 확인했는가.
Free/Paid plan 경계와 rate limit을 확인했는가.
provider별 데이터 보존 정책과 Cloudflare Gateway 경유 정책을 확인했는가.
fallback이 필요한 모델과 fallback하면 안 되는 모델을 나눴는가.
fallback 시 품질 차이를 사용자에게 어떻게 처리할지 정했는가.
streaming response가 끊겼을 때 재연결 UX를 설계했는가.
Agents SDK checkpoint가 업무 side effect 중복 실행을 막아주지 않는다는 점을 반영했는가.
metadata에 넣을 userId, teamId, workflowId 기준을 정했는가.
민감정보를 metadata에 넣지 않도록 규칙을 만들었는가.
Cloudflare 계층이 장애 날 때의 fallback도 생각했는가.

이 체크리스트를 다 하라는 뜻은 아니다.

하지만 1번부터 5번까지 답이 흐릿하면 아직 도입은 빠르다.

특히 3번과 4번은 중요하다.

AI Gateway supported models 문서는 “어떤 모델을 어떤 방식으로 지원하는지” 확인하는 출발점이다.

공식 발표의 큰 그림과 실제 supported model matrix는 분리해서 봐야 한다.

발표는 방향을 말한다.

지원표는 오늘 배포 가능한 것을 말한다.

제품 운영에서는 지원표가 더 세다.

방향은 멋있지만, 배포 버튼은 냉정하다.

작은 팀을 위한 3단 도입법

바로 전체 에이전트 추론 계층을 갈아엎지 말자.

작은 팀은 3단으로 가는 게 낫다.

1단계: 관찰 계층으로만 붙이기

먼저 AI Gateway를 비용과 로그 관찰 계층으로 붙인다.

이 단계에서는 모델 라우팅 정책을 크게 바꾸지 않는다.

기존 provider 호출을 유지하되, 어떤 workflow가 비용을 많이 쓰는지 본다.

metadata는 단순하게 시작한다.

teamId, workflow, plan, userType 정도면 충분하다.

처음부터 너무 촘촘한 taxonomy를 만들면 나중에 아무도 안 쓴다.

태그는 많을수록 좋아 보이지만, 분석할 때는 대체로 적당히 망한다.

2단계: 저위험 workflow부터 모델 교체

그다음 저위험 workflow에서 AI.run() 기반 모델 교체를 실험한다.

예를 들어 태그 추천, 짧은 요약, 분류, 내부 초안 생성 같은 작업이다.

실패해도 사용자 신뢰를 크게 잃지 않는 영역부터 시작한다.

고객에게 바로 나가는 답변이나 결제성 작업은 뒤로 미룬다.

fallback도 이 단계에서 실험한다.

하지만 fallback은 품질 차이를 만든다.

같은 prompt라도 provider가 바뀌면 답변 스타일, tool call 안정성, JSON 준수율이 달라질 수 있다.

따라서 fallback을 켰다고 끝이 아니다.

fallback 이후 출력 검증과 retry 정책을 같이 둬야 한다.

3단계: Agents SDK와 장기 실행 작업 연결

마지막으로 장기 실행 에이전트에 Agents SDK를 붙인다.

이 단계는 단순 모델 호출보다 더 신중해야 한다.

Durable Objects 기반 state, WebSocket, scheduling은 강력하지만 앱 구조를 바꾼다.

이미 다른 queue나 state machine이 있다면 중복될 수 있다.

반대로 아직 agent runtime을 직접 만들지 않았다면 좋은 출발점이 될 수 있다.

예를 들어 리서치 에이전트, 고객지원 에이전트, 개인 자동화 비서처럼 state와 재개가 중요한 작업에 어울린다.

단, tool side effect는 반드시 idempotent하게 설계해야 한다.

파일 생성, 이메일 발송, 결제, 티켓 생성 같은 작업은 중복 실행이 곧 사고다.

Agents SDK checkpoint는 작업 재개를 돕지만, 업무 규칙의 안전장치까지 자동으로 완성해주지는 않는다.

여기서 개발자의 일이 남는다.

이건 아쉽지만 정상이다.

도구가 좋아져도 사고는 여전히 창의적이다.

예시: 개인 자동화 에이전트에 적용한다면

개인이나 1인 팀에게 가장 현실적인 예시는 콘텐츠 자동화다.

예를 들어 뉴스 요약을 받아서 Obsidian inbox에 저장하고, 블로그 후보를 점수화하고, 초안 구조를 만드는 에이전트를 생각해보자.

이 워크플로우는 여러 모델을 섞기 좋다.

뉴스 본문 추출은 빠르고 저렴한 모델.

핵심 요약은 중간급 모델.

블로그 전환 판단은 reasoning 모델.

제목 후보 생성은 창의성이 좋은 모델.

최종 검수는 규칙 준수에 강한 모델.

이렇게 나누면 provider별 장단점을 살릴 수 있다.

하지만 동시에 비용 추적이 어려워진다.

어떤 단계가 돈을 많이 쓰는지 알아야 한다.

실패가 어느 provider에서 나는지도 봐야 한다.

모델을 바꿨을 때 품질이 좋아졌는지도 비교해야 한다.

Cloudflare AI Gateway의 metadata와 logging은 이 지점에서 쓸모가 있다.

그리고 이 워크플로우를 Workers 기반으로 돌린다면 AI.run() 통합이 꽤 자연스럽다.

다만 모든 걸 Cloudflare에 넣을 필요는 없다.

Obsidian 파일 쓰기, Git commit, 로컬 검수 같은 작업은 로컬 자동화가 더 맞을 수 있다.

Cloudflare는 inference layer로 쓰고, 실제 vault mutation은 로컬 agent가 맡는 식으로 나눌 수 있다.

이런 하이브리드가 작은 팀에게는 현실적이다.

한 플랫폼에 다 넣으면 깔끔해 보인다.

하지만 깔끔함이 항상 운영성을 뜻하진 않는다.

가끔은 깔끔하게 한 군데서 다 터진다.

예시: 고객지원 에이전트에 적용한다면

고객지원 에이전트는 Cloudflare 발표의 의도와 꽤 잘 맞는다.

사용자 요청이 오면 먼저 의도 분류를 한다.

그다음 주문 조회, 계정 상태 확인, 환불 정책 검색 같은 tool을 호출한다.

필요하면 사람 승인 흐름을 거친다.

마지막으로 답변을 stream한다.

이 흐름에서 모델 호출은 한 번이 아니다.

그리고 사용자는 응답 시작이 느리면 답답해한다.

Cloudflare가 말한 first token latency가 여기서 중요해진다.

또 provider 장애가 나면 고객지원 전체가 멈출 수 있다.

AI Gateway의 automatic failover는 이 위험을 줄이는 후보가 된다.

Agents SDK의 WebSocket과 scheduling은 상담 상태 유지, 후속 알림, 장기 작업에 어울린다.

하지만 고객지원은 데이터 정책이 민감하다.

개인정보, 주문 정보, 결제 정보가 들어갈 수 있다.

따라서 external provider로 어떤 데이터가 나가는지, provider별 data retention이 어떻게 되는지, Cloudflare 경유 로그에 무엇이 남는지 확인해야 한다.

이 확인 없이 “fallback 있으니까 좋네”로 가면 안 된다.

fallback이 보안 정책을 우회하면 그건 편의가 아니라 사고다.

이 부분은 특히 기업 고객을 받는 SaaS라면 더 중요하다.

예시: 코딩 에이전트에 적용한다면

코딩 에이전트는 모델 선택이 자주 바뀐다.

오늘 좋은 모델이 3개월 뒤에도 최고라는 보장이 없다.

Cloudflare 공식 발표도 agentic coding에 적합한 모델이 빠르게 바뀔 수 있다는 문제의식에서 출발한다.

코딩 에이전트는 작은 모델과 큰 모델을 같이 쓰기 좋다.

파일 목록 분석은 저렴한 모델.

복잡한 설계 판단은 reasoning 모델.

테스트 실패 로그 요약은 빠른 모델.

최종 patch 리뷰는 강한 모델.

이런 식이다.

Cloudflare AI Platform은 모델 교체를 쉽게 하는 계층으로 유용할 수 있다.

하지만 코딩 에이전트는 tool call 안정성과 긴 context 처리도 중요하다.

Cloudflare 카탈로그에 원하는 모델이 있어도 context limit, tool calling 방식, structured output 지원, streaming 안정성을 따로 확인해야 한다.

또 코딩 에이전트는 로컬 파일 시스템과 Git 권한이 핵심이다.

Cloudflare Agents SDK만으로 모든 로컬 개발 워크플로우를 대체하기는 어렵다.

오히려 Cloudflare는 원격 추론과 상태 관리, 로컬 agent는 파일 수정과 검증을 맡는 구조가 더 현실적일 수 있다.

이런 구조에서는 Cloudflare가 “두뇌 전체”라기보다 “모델 호출 교통정리” 역할을 한다.

그 정도 기대치가 건강하다.

비용 판단: 싸지는가보다 보이는가

Cloudflare AI Platform을 볼 때 “이게 더 싼가”만 물으면 답이 애매하다.

모델 가격은 provider와 모델에 따라 다르고, Cloudflare credit 적용 방식도 실제 사용 경로별로 확인해야 한다.

더 좋은 질문은 “비용이 보이는가”다.

에이전트 비용은 보이지 않으면 줄이기 어렵다.

한 사용자 요청이 내부적으로 10번 inference를 호출하면, 사용자는 한 번 눌렀지만 운영자는 10번 돈을 낸다.

그리고 어느 단계가 비싼지 모르면 최적화도 못 한다.

Cloudflare 발표에서 custom metadata로 free vs paid user, customer, workflow별 비용 breakdown을 볼 수 있다고 한 점은 그래서 중요하다.

작은 팀은 특히 workflow별 비용을 봐야 한다.

예를 들어 블로그 초안 생성 workflow가 한 번에 1,000원씩 먹는다면 무료 기능으로 열면 안 된다.

고객지원 자동분류가 요청당 1원이라면 마음 편하게 쓸 수 있다.

비용을 모델 단위가 아니라 workflow 단위로 봐야 제품 판단이 가능하다.

이건 기술 문제가 아니라 가격표 설계 문제다.

AI 제품에서 가격표가 틀리면 기술이 좋아도 오래 못 간다.

모델은 똑똑한데 계좌가 슬퍼지는 상황은 피해야 한다.

latency 판단: 전체 시간보다 첫 반응

Cloudflare가 first token latency를 강조한 건 타당하다.

에이전트 UX에서 사용자는 전체 작업 완료 시간보다 첫 반응을 더 민감하게 느낀다.

물론 최종 결과가 너무 늦으면 문제지만, 시작이 빠르면 기다릴 이유가 생긴다.

그래서 streaming은 단순 장식이 아니다.

작업이 진행 중이라는 신호다.

Cloudflare의 330 cities 네트워크는 이 맥락에서 의미가 있다.

사용자와 gateway, inference endpoint 사이의 네트워크 시간을 줄이면 첫 토큰 시작이 빨라질 수 있다.

특히 Cloudflare-hosted Workers AI 모델을 AI Gateway와 함께 쓸 때 같은 global network 안에서 동작한다는 점을 Cloudflare는 강조한다.

하지만 latency는 직접 재야 한다.

내 사용자 위치, 선택 모델, provider region, prompt 길이, streaming 구현에 따라 결과가 달라진다.

도입 전에는 최소한 아래 지표를 비교하자.

TTFT, 즉 time to first token.

전체 응답 완료 시간.

provider별 실패율.

fallback 후 응답 품질.

stream disconnect 후 복구 성공률.

측정 없이 “Cloudflare니까 빠르겠지”는 위험하다.

Cloudflare는 빠를 가능성을 준다.

내 앱이 빠른지는 측정이 말한다.

측정은 가끔 기분을 상하게 하지만, 그래도 친구다.

좀 차가운 친구.

reliability 판단: failover의 함정

automatic failover는 매력적이다.

하지만 failover는 항상 좋은가.

그렇지는 않다.

예를 들어 같은 모델명이 여러 provider에 있어도 실제 serving 환경, latency, rate limit, safety behavior가 다를 수 있다.

또 provider가 바뀌면 출력 형식이 미묘하게 달라질 수 있다.

JSON이 살짝 깨질 수 있다.

tool call schema를 덜 잘 지킬 수 있다.

한국어 톤이 바뀔 수 있다.

따라서 failover는 “응답이 끊기지 않는다”는 장점과 “응답이 달라질 수 있다”는 비용을 같이 가진다.

에이전트 운영에서는 workflow별로 나눠야 한다.

분류나 요약처럼 품질 허용폭이 넓은 작업은 failover를 켜기 좋다.

법률, 의료, 결제, 보안 판단처럼 일관성이 중요한 작업은 failover 정책을 보수적으로 둬야 한다.

코딩 에이전트의 patch 생성도 조심해야 한다.

모델이 바뀌면 코드 스타일과 수정 범위가 달라질 수 있다.

fallback이 성공해서 더 큰 diff가 나오는 상황도 가능하다.

성공했는데 찜찜한 성공, 이게 운영자 마음을 제일 이상하게 만든다.

BYOM과 Replicate 통합은 기대하되 분리해서 보자

Replicate 통합과 BYOM은 흥미롭다.

Cloudflare 발표에 따르면 Replicate 모델을 AI Gateway로 가져오고, Replicate에서 deploy하던 hosted model을 Workers AI에서도 쓸 수 있게 하는 방향이다.

또 Cog를 활용해 custom model을 컨테이너화하고 Workers AI에 push하는 흐름을 준비 중이다.

Cog는 cog.yaml과 predict.py로 model dependency와 inference code를 정의하는 방식이다.

Cloudflare는 customer-facing API, wrangler command, GPU snapshot 기반 cold start 개선도 언급했다.

하지만 이 부분은 아직 도입 판단의 중심에 두면 안 된다.

오늘 당장 필요한 기능이라면 현재 가능한지 확인해야 한다.

특히 custom model serving이 핵심이면 Enterprise 조건, private model, limit, deployment workflow를 Cloudflare에 직접 확인하는 게 맞다.

작은 팀에게는 BYOM보다 일반 모델 routing과 비용 관찰이 먼저다.

커스텀 모델은 멋있지만, 대부분의 제품은 커스텀 모델보다 커스텀 운영 문제가 먼저 온다.

모델을 직접 들고 오는 순간 monitoring, scaling, cold start, versioning, rollback도 같이 온다.

이 친구들은 초대하지 않아도 알아서 온다.

최종 도입 판단표

아래 표로 최종 판단하면 된다.

점수	조건	판단
0-2개	Workers 미사용, 단일 모델, 트래픽 적음	지금은 과함
3-5개	여러 모델 사용, 비용 관찰 필요, 일부 Workers 사용	제한 실험
6-8개	Workers 중심 앱, Agents SDK 검토, fallback 필요	적극 PoC
9개 이상	글로벌 사용자, 장기 실행 에이전트, 비용·장애·state 요구가 모두 있음	플랫폼 후보로 검토

체크할 조건은 아래와 같다.

Workers 또는 Pages를 이미 쓴다.
Cloudflare 계정과 배포 파이프라인이 있다.
하나의 사용자 요청에서 모델을 2회 이상 호출한다.
모델 provider를 2개 이상 쓴다.
provider 장애 시 fallback이 필요하다.
고객·workflow별 inference 비용을 봐야 한다.
streaming 응답이 UX에 중요하다.
장기 실행 에이전트의 재개가 필요하다.
Durable Objects 기반 stateful agent runtime을 받아들일 수 있다.
REST API가 없어도 우선 Workers 안에서 실험 가능하다.

내 점수표 기준으로 6개 이상이면 Cloudflare AI Platform은 진지하게 PoC할 만하다.

3-5개면 일부 workflow만 실험하자.

2개 이하라면 지금은 provider SDK 직접 호출이 낫다.

중요한 건 “Cloudflare가 좋아 보인다”가 아니다.

내 에이전트 운영 문제가 Cloudflare가 푸는 문제와 겹치는가다.

겹치면 좋은 선택지가 된다.

안 겹치면 좋은 구경거리다.

좋은 구경거리도 가치는 있지만, 운영 시스템에 넣을 이유는 따로 있어야 한다.

개인/소규모 팀 결론

개인 개발자와 소규모 팀에게 Cloudflare AI Platform은 “AI infra를 직접 만들지 않고, 에이전트 추론 호출을 운영 가능한 형태로 묶고 싶은 선택지”다.

특히 Workers 기반 앱을 만들고 있다면 이번 발표는 꽤 중요하다.

AI.run()에서 third-party 모델 호출이 가능해지면 Cloudflare-hosted model과 external provider model 사이의 경계가 낮아진다.

AI Gateway는 비용·로그·retry·fallback을 한 계층에 모으는 후보가 된다.

Agents SDK는 Durable Objects 기반 stateful agent runtime을 제공한다.

이 조합은 에이전트 앱을 처음부터 Cloudflare 위에 올릴 때 설득력이 있다.

하지만 기존 앱을 무조건 옮길 정도는 아니다.

REST API 지원, supported models matrix, unified billing, provider별 정책, BYOM 실제 사용 가능 범위는 확인해야 한다.

그리고 Cloudflare 계층도 lock-in이다.

provider lock-in을 줄이려고 gateway를 붙였는데 gateway lock-in이 생길 수 있다.

이건 나쁜 게 아니라 구조적 사실이다.

그래서 설계할 때는 Cloudflare 호출 부분을 내부 interface 뒤에 숨기는 게 좋다.

예를 들어 앱 코드 전체에서 env.AI.run()을 직접 흩뿌리지 말고, runModel(task, input, options) 같은 내부 wrapper를 두는 식이다.

작은 팀에게 추상화는 과하면 독이지만, provider 교체 지점은 감싸는 게 좋다.

나중에 바꿀 가능성이 높은 부분만 감싸자.

모든 걸 감싸면 코드가 포장지만 남는다.

그것도 나름 예술이지만, 배포는 잘 안 된다.

FAQ

Cloudflare AI Platform은 OpenAI나 Anthropic을 대체하는 건가?

아니다.

Cloudflare AI Platform은 모델 provider 자체를 전부 대체한다기보다, 여러 모델과 provider를 호출하는 추론 계층에 가깝다.

Workers AI는 Cloudflare-hosted model을 제공하고, AI Gateway는 external provider 호출을 관찰·제어하는 역할을 한다.

OpenAI, Anthropic, Gemini 같은 모델을 계속 쓰되, 호출 경로와 운영 계층을 Cloudflare로 묶는 방식으로 이해하면 된다.

지금 바로 Workers 밖에서도 같은 경험을 쓸 수 있나?

2026년 4월 16일 공식 발표 기준으로, Workers를 쓰지 않는 환경을 위한 REST API 지원은 coming weeks로 안내됐다.

따라서 지금 가장 명확한 통합 경험은 Workers의 AI.run() 바인딩 쪽이다.

기존 서버에서 쓰려면 AI Gateway supported models, REST API 지원 범위, billing 문서를 별도로 확인해야 한다.

AI Gateway의 automatic failover만 켜면 장애 대응은 끝인가?

끝이 아니다.

failover는 provider 장애 시 다른 provider로 라우팅하는 데 도움을 줄 수 있다.

하지만 provider가 바뀌면 출력 품질, JSON 준수율, latency, safety behavior가 달라질 수 있다.

중요 workflow에서는 fallback 이후 결과 검증, user messaging, retry 정책을 따로 설계해야 한다.

Agents SDK를 쓰면 에이전트 상태 관리는 다 해결되나?

상당 부분 도움은 된다.

Cloudflare Agents docs는 각 agent가 Durable Object 위에서 실행되고 SQL database, WebSocket connections, scheduling을 가진다고 설명한다.

하지만 tool side effect 중복 방지까지 자동으로 끝나는 것은 아니다.

이메일 발송, 결제, 티켓 생성, 파일 수정 같은 작업은 idempotency를 별도로 설계해야 한다.

Workers AI와 AI Gateway는 뭐가 다른가?

Workers AI는 Cloudflare의 serverless GPU 기반 모델 실행 제품이다.

Cloudflare-hosted open-source model을 Workers, Pages, Cloudflare API 등에서 호출할 수 있다.

AI Gateway는 외부 provider 호출을 관찰하고 제어하는 gateway에 가깝다.

Cloudflare AI Platform은 이 둘을 통합된 AI 모델 실행·호출 경험으로 묶으려는 방향이다.

개인 블로그 자동화에도 쓸 만한가?

쓸 수는 있지만, 처음부터 전부 붙일 필요는 없다.

뉴스 요약, 태그 추천, 초안 생성처럼 여러 모델을 쓰는 workflow가 있다면 AI Gateway로 비용과 로그를 보는 실험은 의미가 있다.

다만 단일 모델로 충분한 간단한 자동화라면 provider SDK 직접 호출이 더 단순하다.

작은 자동화에는 작은 구조가 이긴다.

BYOM 때문에 지금 Cloudflare를 선택해도 될까?

BYOM만 보고 지금 결정하는 건 이르다.

Cloudflare는 Replicate의 Cog 기술을 활용해 custom model을 Workers AI에 올리는 방향을 발표했지만, 2026년 4월 18일 기준으로는 계획과 진행 중인 통합이 섞여 있다.

custom model serving이 필수라면 현재 지원 범위, Enterprise 조건, limits, deployment workflow를 Cloudflare에 직접 확인해야 한다.

Cloudflare를 쓰면 vendor lock-in이 없어지나?

provider lock-in은 줄일 수 있지만 Cloudflare 계층 의존성은 생긴다.

이건 자연스러운 trade-off다.

따라서 앱 내부에서는 모델 호출 wrapper를 두고, Cloudflare 전용 옵션이 전체 비즈니스 로직에 퍼지지 않게 하는 편이 좋다.

락인을 완전히 없애는 것보다, 바꿀 때 어디를 고치면 되는지 아는 게 더 현실적이다.

공식 출처

마지막 판단

Cloudflare AI Platform 발표의 핵심은 새 모델 하나가 더 나왔다는 이야기가 아니다.

에이전트 앱에서 추론 호출을 어디까지 플랫폼 계층에 맡길지 묻는 이야기다.

Workers 위에서 에이전트를 만들고 있고, 여러 provider를 번갈아 쓰며, 비용과 로그와 장애 대응을 한 계층에서 보고 싶다면 Cloudflare 조합은 진지하게 볼 만하다.

반대로 단일 모델 호출이면 아직은 직접 SDK를 쓰는 편이 더 단순할 수 있다.

좋은 도구도 문제가 작을 때 붙이면 문제보다 도구가 커진다.

2026년 4월 18일 기준으로는 AI.run() 중심의 Workers 경험, AI Gateway의 supported models, Agents SDK의 Durable Objects 기반 상태 관리, REST API 지원 범위를 나눠서 확인하면 된다.

이 네 가지가 내 워크플로와 겹치면 도입 후보.

겹치지 않으면 관찰 후보.

그 정도 선이 작은 팀에게는 제일 건강한 판단이다.

Cloudflare AI Platform은 에이전트 추론 계층으로 언제 쓸 만한가 2026 — AI Gateway·Workers AI·Agents 분기표