Cloudflare AI 개발 플랫폼: 수직 통합의 범위와 도입 판단 기준

Cloudflare AI 개발 플랫폼은 Workers AI의 모델과 외부 제공사의 모델을 함께 쓰면서, 개발 도구·모델 호출·에이전트 실행과 상태 관리·애플리케이션 배포를 한 흐름으로 잇는 구성입니다. 이 글에서 말하는 '수직 통합'은 Cloudflare가 내건 공식 전략 이름이 아니에요. 제품들이 어떻게 맞물리는지 설명하려고 가져온 분석 관점입니다.

처음 살펴본다면 모델을 호출하는 곳과 애플리케이션이 실행되는 곳을 따로 떼어 보기를 권합니다. 외부 모델을 고르더라도 요청 관리와 에이전트 실행은 Cloudflare 쪽에 모을 수 있어서, 둘을 한 덩어리로 보면 플랫폼의 범위를 잘못 짚기 쉽거든요. Cloudflare AI 공식 문서도 직접 호스팅하는 모델과 외부 모델 연결을 나란히 다루고 있습니다.

모델 실행, 에이전트 실행, 개발 도구는 각각 무엇을 맡나

가장 헷갈리는 지점은 Workers AI와 AI Gateway입니다. Workers AI는 Cloudflare가 호스팅하는 모델을 서버리스 GPU 환경에서 돌리는 추론 서비스예요. 반면 AI Gateway는 외부 모델 제공사로 나가는 요청을 관찰하면서 캐싱, 속도 제한, 재시도, 대체 모델 연결을 관리합니다. 하나는 모델을 실행하고 다른 하나는 호출 경로를 관리한다고 나눠 두면 정리가 됩니다.

모델이 응답한 뒤에도 에이전트가 일을 이어가려면 그걸 받쳐 줄 실행 기반이 있어야 합니다. 상태 유지는 Durable Objects가, 오래 이어지는 작업 흐름은 Workflows가 맡아요. Agents SDK는 이 기반 위에서 에이전트를 구현하도록 돕는 도구입니다.

개발 단계까지 범위가 넓어졌다는 신호는 VoidZero 합류와 Vite+에서 볼 수 있습니다. 2026년 6월 VoidZero와 팀 구성원이 Cloudflare에 합류했고, 9월에는 빌드·테스트·코드 검사·포맷팅·작업 캐싱을 하나로 묶은 Vite+ 1.0이 발표됐어요. Cloudflare Vite 플러그인은 로컬 개발에서도 Workers의 기반 런타임인 workerd를 씁니다. 코딩 에이전트는 빌드와 테스트 결과를 보고 코드를 다시 고치기 때문에, 모델 응답 속도만 보고 전체 작업 시간을 가늠하기는 어렵습니다.

그래서 개발 도구를 통합하는 흐름은, 이렇게 고치고 검증하는 반복 과정까지 플랫폼 범위 안으로 들이려는 움직임으로 읽을 수 있습니다.

VibeSDK로 보는 생성·미리보기·배포 흐름

VibeSDK는 자체 AI 코딩 플랫폼을 만들 수 있게 공개된 구현입니다. 사내용 앱 생성 도구나 고객용 앱 빌더를 구상하는 팀이라면, Cloudflare 제품들이 실제로 어떻게 연결되는지 확인하는 출발점으로 삼기 좋아요.

2025년 출시 당시 구성은 이랬습니다. AI Gateway로 여러 모델 제공사를 연결하고, Sandbox SDK로 개발 서버와 미리보기를 띄우고, 생성된 애플리케이션은 Workers for Platforms로 배포하는 방식이었어요. 코드 생성에서 실행, 확인, 배포까지 한 줄로 이어지는 흐름입니다.

그 뒤 VibeSDK 저장소의 README에는 다른 구성이 등장합니다. Think가 모델과 도구의 반복 실행을 관리하고, Durable Object가 프로젝트 작업 공간을 제공하는 구조예요. 미리보기는 Dynamic Workers, 앱별 SQLite 저장소는 Durable Object Facets, Git 이력과 복원 지점은 Cloudflare Artifacts로 설명돼 있습니다.

여기서 많이들 헷갈립니다. 출시 당시의 Sandbox 중심 구성과 지금 README의 구성을 섞어 읽으면 어떤 제품에 의존하는지가 흐려지니, 도입하려는 버전의 구성을 기준으로 판단하세요.

도입 전에 의존성과 기능 상태부터 확인하기

검토를 시작하면 모델 목록부터 펼쳐 보기 쉬운데, 그보다 상태·데이터·실행 코드가 어떤 서비스에 기대는지를 먼저 보는 편이 낫습니다. 모델 연결을 바꾸는 일과 프로젝트 상태나 실행 환경을 다른 기반으로 옮기는 일은 검토할 대상 자체가 다르기 때문이에요. AI Gateway의 연결 설정, Durable Objects에 저장되는 데이터, 장시간 작업의 처리 방식, 미리보기와 배포 코드의 의존성을 한꺼번에 놓고 살펴보세요.

오픈소스로 공개됐다는 것과 애플리케이션을 옮길 수 있다는 것도 별개의 이야기입니다. VibeSDK의 소스를 읽거나 프로젝트를 내보낼 수 있더라도, 연결된 서비스의 기능을 다른 환경에서 어떻게 구현할지는 여전히 숙제로 남아요. Vite 생태계가 제공사 중립을 방침으로 내세운다 해도, 그것만으로 개별 앱을 옮기는 난도를 가늠하기는 어렵습니다.

마지막으로 버전과 기능 상태를 챙겨야 합니다. README에 고정 커밋이 없으면 구성이 언제 바뀌었는지 특정하기 어려우니, 도입할 버전의 커밋과 문서를 함께 기록해 두세요. 2026년 9월 발표에서 Bundled Dev는 실험 단계였고, Void의 오픈소스·자체 호스팅 버전은 향후 계획으로 제시됐어요. 실제로 쓰기 전에 제공 여부를 확인해야 하는 이유입니다.

비용과 성능은 모델 호출량, 실행 시간, 저장소 조건을 맞춘 상태에서 비교해야 도입 판단의 근거가 됩니다.