Cloudflare AI Platform으로 멀티 모델 인프라 구축하기: 외주 개발사가 알아야 할 3가지 (blog.cloudflare.com)

한줄 요약

Cloudflare가 12개 이상의 AI 제공사, 70개 이상의 모델을 하나의 API로 묶는 통합 인퍼런스 레이어를 공개했다.

무엇이 달라지나?

AI 애플리케이션 개발에서 단일 모델로 전부 해결하는 시대는 이미 지나갔다. 사용자 메시지 분류에는 빠르고 저렴한 모델, 복잡한 추론에는 대형 모델, 개별 태스크 실행에는 경량 모델을 각각 쓰는 구조가 현실이다. 실제로 기업들이 평균 3.5개의 모델을 여러 제공사에 걸쳐 사용한다는 조사 결과도 있다.

문제는 이 구조가 복잡성을 급격히 높인다는 점이다. 제공사마다 별도 계약, 별도 API 키, 별도 비용 청구서가 생긴다. 어느 한 제공사에 장애가 나면 직접 장애 전환 로직을 짜야 하고, 전체 AI 사용 비용을 한눈에 파악하기도 어렵다.

Cloudflare의 새 AI Platform은 이 문제를 정면으로 겨냥한다. AI Gateway와 Workers AI를 통합해 단일 엔드포인트 하나로 OpenAI, Anthropic, Google, Alibaba Cloud, ByteDance 등 12개 이상의 제공사 모델을 호출할 수 있게 됐다. Workers 환경에서는 기존 AI.run() 바인딩을 그대로 쓰면서 모델명 하나만 바꾸면 제공사를 갈아탈 수 있다. REST API 지원도 수 주 내 추가될 예정이라 Workers 외 환경에서도 동일한 카탈로그에 접근 가능해진다.

새로 추가된 모델 범위도 주목할 만하다. 텍스트 모델 중심이던 기존 카탈로그가 이미지, 비디오, 음성 모델까지 확장되면서 멀티모달 애플리케이션 구축이 단일 플랫폼 안에서 가능해졌다. Replicate 팀이 Cloudflare AI Platform 팀에 합류하면서 Replicate에서 운영하던 모델들도 AI Gateway를 통해 접근할 수 있도록 통합 작업이 진행 중이다.

실무에서 어떤 의미인가?

에이전트 워크플로에서 지연 시간 문제가 달라진다. 단순 챗봇은 사용자 프롬프트당 인퍼런스 호출이 1회지만, 에이전트는 단일 태스크를 완료하기 위해 10회 이상 호출을 연쇄적으로 실행하기도 한다. 한 제공사가 50ms를 추가하면 체인 전체로는 500ms가 쌓인다. Cloudflare는 전 세계 330개 도시에 데이터센터를 운영하고 있어 AI Gateway가 사용자와 인퍼런스 엔드포인트 양쪽에 가깝게 위치한다. Workers AI에서 호스팅하는 모델을 AI Gateway로 호출할 경우 공용 인터넷 구간이 없어 첫 토큰 도달 시간이 최소화된다.

자동 장애 전환이 코드 없이 동작한다. 같은 모델을 여러 제공사가 제공하는 경우, 하나가 다운되면 AI Gateway가 자동으로 다른 제공사로 라우팅한다. 별도 재시도 로직이나 장애 전환 코드를 작성하지 않아도 된다. 특히 장기 실행 에이전트의 경우 스트리밍 응답을 AI Gateway가 에이전트 수명과 독립적으로 버퍼링하기 때문에, 에이전트가 중단됐다 재연결해도 동일 응답을 재호출 없이 가져올 수 있다.

비용 추적이 하나의 대시보드로 통합된다. 요청에 커스텀 메타데이터를 붙이면 팀별, 사용자별, 워크플로별 AI 사용 비용을 세분화해서 볼 수 있다. 무료 사용자와 유료 사용자 간 비용 구조를 분리해서 추적하는 것도 가능하다.

파인튜닝 모델 운영도 열린다. Replicate의 Cog 기술을 활용해 자체 파인튜닝 모델을 컨테이너로 패키징한 뒤 Workers AI에 배포하는 경로가 준비 중이다. cog.yaml에 의존성을 명시하고 Python 파일로 추론 코드를 작성하면 CUDA 의존성, 가중치 로딩 같은 복잡한 패키징 과정을 Cog가 추상화해준다. 현재는 엔터프라이즈 고객 및 일부 외부 파트너와 테스트 중이며, 디자인 파트너 참여 신청을 받고 있다.

도입 전 체크포인트

이 플랫폼이 매력적으로 보이더라도 실무 도입 전에 몇 가지를 먼저 따져봐야 한다.

첫째, Workers 의존도를 얼마나 감수할 것인지 판단해야 한다. AI.run() 바인딩의 편의성은 Workers 환경을 전제로 한다. REST API가 곧 지원되지만, 기존 비Workers 아키텍처와의 통합 복잡도는 별도로 검토해야 한다.

둘째, 제공사 종속의 위치가 이동한다는 점을 인식해야 한다. 개별 모델 제공사 종속에서는 벗어나지만, Cloudflare 인프라 자체에 대한 종속이 생긴다. 이것이 리스크인지 편의인지는 팀의 전략과 스택에 따라 다르다.

셋째, 자체 모델 배포(Bring Your Own Model) 기능은 아직 정식 출시 전이다. 고객 대상 API와 wrangler 명령어 지원이 준비 중이라는 점을 감안해 타임라인을 잡아야 한다.