배경 및 맥락

많은 조직이 AI coding tool을 도입할 때 특정 모델이나 특정 IDE 확장을 먼저 고른다. 하지만 도입이 조직 단위로 커질수록 실제 병목은 모델이 아니라 접근 제어, 내부 시스템 연결, 테스트 실행, 비용 라우팅, 장기 세션 실행 같은 인프라 계층에서 드러난다. Cloudflare가 공개한 사례는 이 차이를 잘 보여준다.

이 글의 가치는 제품 홍보보다 운영 숫자에 있다. 사내 배포가 어느 정도 스케일에 도달했는지, 어떤 계층을 자체 플랫폼으로 만들었는지, 다음 단계로 무엇을 준비하는지까지 비교적 구체적으로 공개했다.

---

핵심 내용

Cloudflare는 지난 30일 기준 R&D 조직의 93%가 사내 AI coding 도구를 사용했고, 회사 전체로는 3,683명의 active users와 47.95M AI messages, 20.18M AI Gateway requests, 241.37B routed tokens를 기록했다고 밝혔다. Workers AI 사용량도 같은 기간 51.47B input tokens와 361.12M output tokens 수준이다.

중요한 점은 이 수치를 가능하게 한 기반 구조다. Cloudflare는 internal MCP servers, access layer, AI Gateway, Workers AI, Sandbox 기반 실행 환경을 묶어 사내 engineering stack을 만들었고, 다음 단계로 로컬과 동일한 도구를 쓰는 background agents를 cloud에서 on-demand로 띄우는 구조를 제시했다. 단순 챗봇 도입이 아니라 사내 agent platform을 구축한 셈이다.

---

경쟁 구도 / 비교

대부분의 기업 사례는 "AI를 도입했다"는 추상적 메시지에 그치지만, Cloudflare는 adoption과 token economics를 함께 공개하며 infra-first 접근을 강조한다. 이는 단순히 frontier model API를 사내에 열어주는 것과 다르다. 실제로는 access control, tool connectivity, execution isolation, observability까지 한꺼번에 정비해야 높은 채택률이 나온다는 점을 보여준다.

또한 background agents 계획은 IDE 안 assistant에서 cloud-resident long-running agent로의 전환을 예고한다. 이는 에이전트 도입이 개인 생산성 툴에서 조직 운영 인프라로 이동하는 전형적인 패턴이다.

---

의미

산업적으로는 AI coding adoption의 승부처가 모델 스펙이 아니라 internal platform maturity라는 사실이 더 분명해지고 있다. 특히 사내 시스템과 엮인 agent는 보안 경계, 실행 환경, 비용 라우팅까지 포함한 full stack으로 다뤄져야 한다.

실무적으로는 AI 도입 담당 조직이 특정 도구 사용 장려보다 먼저 MCP, sandbox, gateway, audit, background execution을 어떻게 구성할지 설계해야 한다. 그래야 pilot가 아니라 지속 가능한 플랫폼으로 전환된다.