🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 요약

Cloudflare는 자체 플랫폼 위에 인증, LLM 라우팅, 추론, MCP 포털, 설정 자동화, 사용량 추적을 결합한 내부 AI 엔지니어링 스택을 구축했고, 최근 30일 동안 R&D 조직의 93%가 이를 활용했다.

📌 핵심 요약

• Cloudflare는 11개월 동안 iMARS라는 내부 전담팀과 Dev Productivity 팀을 중심으로 AI 코딩 도구가 실제 엔지니어링 업무에 유용해지도록 내부 MCP 서버, 접근 계층, AI 도구 체계를 구축했다.
• 최근 30일 기준 3,683명의 내부 사용자가 AI 코딩 도구를 적극 사용했고, 이는 회사 전체의 60%, R&D 조직의 93%에 해당한다. 같은 기간 4,795만 건의 AI 요청, 2,018만 건의 AI Gateway 요청, 2,413억 토큰의 AI Gateway 라우팅이 발생했다.
• 구성의 핵심은 Cloudflare Access를 통한 제로 트러스트 인증, AI Gateway를 통한 중앙 LLM 라우팅과 비용·보존 정책 관리, Workers AI를 통한 온플랫폼 추론, Workers와 Access 기반 MCP 포털, Dynamic Workers·Agents SDK·Sandbox SDK·Workflows 등으로 나뉜다.
• 개발자 경험은 OpenCode에서 내부 URL 하나로 로그인하면 인증, 모델 공급자, MCP 서버, 에이전트, 명령, 권한이 자동 구성되는 방식으로 단순화됐다. 사용자는 API 키나 MCP 연결을 직접 설정하지 않아도 되고, 조직 기본값은 중앙에서 배포하되 로컬 설정으로 덮어쓸 수 있다.
• Cloudflare는 단일 프록시 Worker를 중앙 제어 지점으로 두어 사용자별 익명 사용량 추적, 모델 카탈로그 관리, 권한 적용, 서버 측 API 키 주입, Zero Data Retention 설정을 확장했다. 또한 내부 MCP Server Portal은 13개의 운영 MCP 서버와 182개 이상의 도구를 하나의 OAuth와 Access 흐름으로 묶었다.

🧩 주요 포인트

1. Cloudflare는 11개월 동안 iMARS라는 내부 전담팀과 Dev Productivity 팀을 중심으로 AI 코딩 도구가 실제 엔지니어링 업무에 유용해지도록 내부 MCP 서버, 접근 계층, AI 도구 체계를 구축했다.
2. 최근 30일 기준 3,683명의 내부 사용자가 AI 코딩 도구를 적극 사용했고, 이는 회사 전체의 60%, R&D 조직의 93%에 해당한다. 같은 기간 4,795만 건의 AI 요청, 2,018만 건의 AI Gateway 요청, 2,413억 토큰의 AI Gateway 라우팅이 발생했다.
3. 구성의 핵심은 Cloudflare Access를 통한 제로 트러스트 인증, AI Gateway를 통한 중앙 LLM 라우팅과 비용·보존 정책 관리, Workers AI를 통한 온플랫폼 추론, Workers와 Access 기반 MCP 포털, Dynamic Workers·Agents SDK·Sandbox SDK·Workflows 등으로 나뉜다.
4. 개발자 경험은 OpenCode에서 내부 URL 하나로 로그인하면 인증, 모델 공급자, MCP 서버, 에이전트, 명령, 권한이 자동 구성되는 방식으로 단순화됐다. 사용자는 API 키나 MCP 연결을 직접 설정하지 않아도 되고, 조직 기본값은 중앙에서 배포하되 로컬 설정으로 덮어쓸 수 있다.
5. Cloudflare는 단일 프록시 Worker를 중앙 제어 지점으로 두어 사용자별 익명 사용량 추적, 모델 카탈로그 관리, 권한 적용, 서버 측 API 키 주입, Zero Data Retention 설정을 확장했다. 또한 내부 MCP Server Portal은 13개의 운영 MCP 서버와 182개 이상의 도구를 하나의 OAuth와 Access 흐름으로 묶었다.

🧠 상세 정리

1. 내부 AI 엔지니어링 스택 구축의 출발점

글은 Cloudflare가 자체 플랫폼 위에 내부 AI 엔지니어링 스택을 구축했다는 선언에서 시작한다. 최근 30일 동안 Cloudflare R&D 조직의 93%가 이 인프라로 구동되는 AI 코딩 도구를 사용했다는 수치를 제시하며, 이것이 단순한 실험이 아니라 조직 전반의 실제 업무 흐름이 되었음을 강조한다. 11개월 전 회사는 AI를 엔지니어링 스택에 제대로 통합하기 위해 내부 MCP 서버, 접근 계층, AI 도구를 함께 만들어야 한다고 판단했다. 이를 위해 여러 부서의 엔지니어들이 iMARS라는 전담팀으로 모였고, 이후 지속 운영은 CI/CD, 빌드 시스템, 자동화 등 내부 도구를 담당하는 Dev Productivity 팀이 맡았다.

2. 최근 30일 사용량과 개발 속도 변화

본문은 내부 도입 규모를 구체적인 수치로 보여준다. 최근 30일 동안 3,683명의 내부 사용자가 AI 코딩 도구를 적극적으로 사용했으며, 이는 약 6,100명 전체 직원 중 60%, R&D 조직에서는 93%에 해당한다. 295개 팀이 에이전트형 AI 도구와 코딩 어시스턴트를 활용했고, AI 요청은 4,795만 건, AI Gateway 월간 요청은 2,018만 건, AI Gateway를 통과한 토큰은 2,413억 개로 집계됐다. 개발자 생산성 지표로는 merge request의 4주 이동 평균이 주당 약 5,600건에서 8,700건 이상으로 상승했고, 3월 23일 주에는 10,952건에 도달해 Q4 기준선의 거의 두 배에 가까웠다고 설명한다.

3. 제품과 직접 연결된 아키텍처 구성

Cloudflare가 만든 내부 스택은 별도의 내부 전용 인프라가 아니라 회사가 실제로 출시하고 개선하는 제품들 위에 구성되어 있다. 제로 트러스트 인증은 Cloudflare Access, 중앙 LLM 라우팅과 비용 추적, BYOK, Zero Data Retention 제어는 AI Gateway가 담당한다. 온플랫폼 추론은 Workers AI가 맡고, 단일 OAuth를 제공하는 MCP Server Portal은 Workers와 Access 위에 구축됐다. 이 밖에도 AI Code Reviewer CI 통합, 에이전트 생성 코드의 샌드박스 실행, 장기 상태를 가진 에이전트 세션, 격리된 클론·빌드·테스트 환경, 다단계 워크플로, 16,000개 이상의 엔티티 지식 그래프가 각각 Workers, Dynamic Workers, Agents SDK, Sandbox SDK, Workflows, Backstage와 연결된다.

4. 플랫폼 계층의 핵심: Access와 AI Gateway

플랫폼 계층에서 가장 먼저 해결한 문제는 수천 명의 내부 사용자가 다양한 클라이언트와 역할로 AI 코딩 도구를 사용할 때 접근 제어와 가시성을 확보하는 일이었다. 모든 흐름은 Cloudflare Access에서 시작되며, Access가 인증과 제로 트러스트 정책 집행을 담당한다. 인증 이후 모든 LLM 요청은 AI Gateway를 통과하고, 이 지점에서 공급자 키 관리, 비용 추적, 데이터 보존 정책이 중앙화된다. 지난 한 달 동안 내부 요청량은 대부분 OpenAI, Anthropic, Google 같은 frontier 모델 공급자가 처리했지만, Workers AI도 130만 건, 8.84%의 요청 비중을 차지하며 점차 내부 에이전트형 엔지니어링 워크로드의 일부를 맡고 있다.

5. Workers AI의 역할과 온플랫폼 추론의 이점

Workers AI는 Cloudflare의 글로벌 네트워크에서 오픈소스 모델을 GPU로 실행하는 서버리스 AI 추론 플랫폼으로 설명된다. 본문은 frontier 모델 대비 비용 절감뿐 아니라, 추론이 Workers, Durable Objects, 스토리지와 같은 네트워크 안에서 이루어진다는 점을 중요한 장점으로 제시한다. 다른 클라우드로 요청을 왕복하지 않아도 되므로 지연 시간, 네트워크 불안정성, 추가 네트워킹 설정 부담이 줄어든다는 논리다. 최근 한 달 Workers AI 사용량은 입력 토큰 514.7억 개, 출력 토큰 3.6112억 개였고, Kimi K2.5를 활용하는 보안 에이전트 사례에서는 하루 70억 개 이상의 토큰을 처리하며 중간급 독점 모델 대비 연간 비용을 77% 낮출 수 있다고 설명한다.

6. 단일 프록시 Worker를 통한 중앙 제어

Cloudflare가 초기에 옳게 선택했다고 평가하는 설계는 모든 클라이언트가 AI Gateway에 직접 연결하지 않고 단일 프록시 Worker를 거치도록 한 것이다. 직접 연결은 초기 설정이 더 단순했겠지만, Worker를 중앙 경유지로 두면서 나중에 사용자별 귀속, 모델 카탈로그 관리, 권한 집행을 클라이언트 설정 변경 없이 추가할 수 있었다. 이 프록시 패턴은 직접 연결 방식에는 없는 제어 평면을 제공하며, 새로운 코딩 어시스턴트 도구를 추가하더라도 같은 Worker와 discovery endpoint가 처리할 수 있게 한다. 즉, 개발자 경험은 단순하게 유지하면서 운영자는 인증, 라우팅, 정책, 모델 구성을 한 곳에서 관리할 수 있는 구조를 확보한 것이다.

7. OpenCode 로그인 한 번으로 완성되는 설정 흐름

개발자가 실제로 접하는 사용 흐름은 OpenCode에서 내부 도메인으로 로그인하는 한 줄의 명령으로 시작된다. OpenCode는 well-known 경로에서 설정을 가져오고, 그 응답에는 인증 방법과 함께 공급자, MCP 서버, 에이전트, 명령, 기본 권한이 포함된다. 이후 OpenCode는 Cloudflare Access 인증 명령을 실행하고, 사용자는 회사에서 쓰는 동일한 SSO로 인증하며, cloudflared가 서명된 JWT를 반환한다. 이 JWT는 로컬에 저장되어 이후 provider 요청에 자동 첨부되고, 조직 공통 설정은 OpenCode에 병합되지만 로컬 설정이 우선하므로 사용자는 기본 모델을 바꾸거나 자신만의 에이전트와 권한을 추가할 수 있다.

8. 프록시 Worker 내부 동작과 개인정보 보호

프록시 Worker는 Hono 앱으로 구현되어 세 가지 역할을 한다. 첫째, 배포 시점에 구조화된 소스 파일에서 컴파일된 공유 설정을 제공하고, 요청 시점에는 Worker 원점 주소 같은 자리표시자를 치환해 provider 요청이 직접 공급자로 가지 않고 Worker를 통과하게 만든다. 둘째, OpenCode 요청이 들어오면 Access JWT를 검증한 뒤 authorization, cf-access-token, host 같은 헤더를 제거하고 AI Gateway용 인증 헤더와 익명 사용자 메타데이터를 추가해 전달한다. 셋째, hourly cron으로 models.dev에서 OpenAI 모델 목록을 가져와 Workers KV에 캐시하고 모든 모델에 store: false를 주입해 Zero Data Retention이 자동 적용되게 한다. 또한 사용자의 이메일은 D1과 KV를 통해 UUID로 매핑되어 AI Gateway에는 이메일이 아니라 익명 UUID만 전달된다.

9. MCP Server Portal과 도구 접근의 통합

내부 MCP Server Portal은 여러 MCP 도구를 하나의 OAuth와 Cloudflare Access 흐름으로 묶어 접근을 단순화한다. 본문에 따르면 이 포털은 Backstage, GitLab, Jira, Sentry, Elasticsearch, Prometheus, Google Workspace, 내부 Release Manager 등과 연결된 13개의 운영 MCP 서버와 182개 이상의 도구를 집계한다. 각 MCP 서버는 Agents SDK의 McpAgent, workers-oauth-provider, Cloudflare Access를 공통 기반으로 사용하며, 단일 monorepo 안에서 공유 인증 인프라, Bazel 빌드, CI/CD 파이프라인, Backstage 등록용 catalog-info.yaml을 함께 갖춘다. 새 서버를 추가하는 일도 기존 서버를 복사한 뒤 감싸는 API만 바꾸는 방식에 가깝다고 설명한다.

10. Code Mode가 제기한 맥락 창 문제

제공된 원문 마지막 부분은 MCP가 AI 에이전트를 도구와 연결하는 데 적절한 프로토콜이지만 실무적인 문제가 있다고 전환한다. 도구 정의가 많아질수록 모델이 실제 작업을 시작하기 전부터 각 도구 설명이 컨텍스트 창의 토큰을 소비한다는 점이다. 내부 포털이 여러 서버와 182개 이상의 도구를 집계하는 구조에서는 이 문제가 특히 중요해진다. 원문은 이 대목에서 Code Mode를 포털 계층과 연결해 설명하기 시작하지만, 제공된 source_body는 문장이 중간에서 끊겨 있어 구체적인 해결 방식까지는 확인할 수 없다.

🧾 핵심 주장 / 시사점

• Cloudflare의 접근은 AI 코딩 도구를 개별 개발자 설정 문제가 아니라 인증, 라우팅, 비용, 데이터 보존, 모델 카탈로그, 도구 권한을 함께 다루는 내부 플랫폼 문제로 본다는 점이 핵심이다.
• 단일 프록시 Worker를 먼저 둔 결정은 초기 구현을 약간 복잡하게 만들 수 있지만, 이후 사용자 귀속, 권한 정책, ZDR 설정, API 키 보호, 신규 도구 확장을 중앙에서 처리하게 해 장기 운영성을 크게 높였다.
• MCP 도구 수가 늘어날수록 단순히 더 많은 도구를 붙이는 것이 아니라 컨텍스트 창 비용과 사용성까지 관리해야 하며, 대규모 조직에서는 도구 통합 계층 자체가 중요한 엔지니어링 과제가 된다.

✅ 액션 아이템

• Cloudflare 사례의 Access·Gateway·Workers AI·MCP 포털 축을 따라 인증부터 추론까지 흐름을 하나의 내부 스택으로 재설계한다.
• 최근 30일 지표(3,683명·4,795만·2,018만·2,413억 토큰)를 기준선으로 채택율, 요청량, 토큰 라우팅 추세를 월별로 점검한다.
• OpenCode형 단일 로그인 자동설정 구조를 반영해 API 키 직접 등록·MCP 개별 연결 단계를 제거하고 로컬 오버라이드만 허용하도록 운영 규칙을 정한다.

❓ 열린 질문

• 단일 프록시 Worker에서 사용자별 익명 추적과 Zero Data Retention을 함께 적용할 때 개인정보 역추적 위험은 어떻게 통제되는가?
• 중앙 배포 값이 로컬 설정을 덮어쓰는 우선순위 충돌이 발생하면 모델 접근권한은 어떤 기준으로 재조정해야 하는가?
• R&D 93% 이용율과 4,795만 건의 AI 요청 규모를 감안했을 때 MCP 서버 13개와 182개 도구를 운영할 적정 가드레일은 무엇인가?