Cloudflare OS는 단순한 사내 챗봇이 아니라, 조직의 맥락·도구·권한·앱·워크플로를 하나의 에이전트 실행 환경으로 묶으려는 Cloudflare의 오픈소스 플랫폼이다.
한눈에 보기
- Cloudflare는 2026년 5월부터 전 직원에게 Cloudflare OS 1세대를 제공했고, 공식 블로그는 엔지니어링 외 직군을 포함한 수천 명이 문서·슬라이드 작성, 반복 업무 자동화, 데이터 시각화용 앱 제작에 매일 사용했다고 설명한다.
- 2세대는 첫 버전의 정적 결과물과 협업 시 권한 전파 문제를 다시 설계해, 에이전트 작업공간·보안/거버넌스·개인별 수정 가능한 앱을 한 플랫폼에 결합한다.
- 핵심 보안 원칙은 에이전트와 앱을 무권한으로 시작시키고, 필요한 리소스만 capability로 소개하는 것이다. 자격 증명은 격리하고 Gatekeeper가 서비스별 정책, 읽기 기록, 외부 부작용 승인, 속도 제한을 담당한다.
- 앱은 문서가 아니라 클라이언트·서버 코드, API, 영속 상태를 가진 풀스택 애플리케이션이다. Dynamic Worker, Durable Object Facet, SQLite, V8 isolate, Cap’n Web RPC를 사용한다.
- 모든 추론 요청은 Cloudflare AI Gateway를 거치며, 조직은 모델 선택·예산·속도 제한·사용자/팀/작업공간별 비용 귀속을 중앙에서 관리할 수 있다.
공식 확인 — Cloudflare가 공개한 설계
에이전트 작업공간과 결정론적 워크플로
작업공간에는 에이전트 세션, 영속 상태, 파일·산출물, 리소스 접근, 코드 실행용 격리 런타임이 함께 들어간다. 조직이 만든 용어·절차·기술(skill)을 공유 라이브러리로 제공해, 매 작업마다 모델에 같은 업무 맥락을 다시 설명하지 않도록 한다.
모든 업무를 에이전트 세션으로 처리하지 않는 점도 중요하다. 정해진 단계는 코드로 실행하고 판단이 필요한 일부에만 모델을 사용하는 대부분 결정적인 워크플로로 바꿀 수 있으며, 요청 시·예약·외부 시스템 이벤트에 따라 실행할 수 있다고 설명한다. 기존 MCP 서버는 MCP Server Portals를 통해 연결한다.
관찰한 데이터까지 따라가는 권한
Cloudflare의 문제 정의는 단순한 도구 권한보다 넓다. MCP 서버가 어떤 도구를 호출할 수 있는지는 보여주지만, 에이전트가 실제로 어떤 원본 리소스를 읽었는지는 충분히 표현하지 못한다. 에이전트가 민감한 테이블을 읽어 대시보드를 만들었다면, 원본을 볼 권한이 없는 사용자에게 대시보드가 공유되어서는 안 된다는 논리다.
Cloudflare OS는 에이전트가 관찰한 리소스를 작업과 산출물에 연결하고, 다른 사용자가 작업공간·에이전트·결과물을 열 때 해당 관찰 리소스에 대한 권한을 다시 확인한다고 설명한다. 같은 기록을 사용해 민감한 데이터를 읽은 뒤 특정 대상에 쓰기, 협업자 초대, 다른 에이전트 위임, 외부 요청을 차단하는 정책도 적용할 수 있다고 한다.
Gatekeeper와 capability 보안
Gatekeeper는 Cloudflare OS와 외부 서비스 사이에 놓이는 서비스별 Worker다. 에이전트에 GitHub 계정 전체를 넘기는 대신 단일 저장소만 제공하거나, 이슈 읽기는 허용하되 소스 코드 접근은 차단하고, 필드를 마스킹하거나 rate limit을 적용하고, PR 병합 전에 승인을 요구하는 식으로 정책을 세밀하게 구성한다.
에이전트와 생성 코드에는 작은 TypeScript API만 보이고 OAuth와 실제 자격 증명은 Gatekeeper가 관리한다. 공식 블로그는 서버 코드의 전역 외부 네트워크를 끄고, 브라우저 클라이언트도 명시적으로 제공한 capability 없이는 인터넷에 접근하지 못하게 한다고 설명한다.
GitHub README에는 한 단계 더 나아간 설계가 적혀 있다. 부작용이 있는 작업을 동기적으로 멈춰 세우는 대신 Gatekeeper가 결과를 로컬에서 시뮬레이션하고 작업을 큐에 쌓은 뒤, 사용자가 나중에 일괄 또는 개별 승인할 수 있다는 내용이다. 이 동작은 README에 적힌 프로젝트 설계이며, 이 저장소에서 실제로 실행해 독립 검증한 결과는 아니다.
Gadget과 Blueprint
Cloudflare OS에서 각 “파일”은 문서·스프레드시트 같은 고정 형식이 아니라 에이전트가 작성한 Gadget(개인 또는 팀용 앱)이 될 수 있다.
- Gadget은 클라이언트 UI와 서버 코드, API, 영속 상태를 갖는 풀스택 앱이다.
- 서버는 요청 시 Dynamic Worker로 로드되고 Durable Object Facet으로 인스턴스화되며, 별도 SQLite 상태를 가진다.
- 브라우저와 서버는 object-capability RPC인 Cap’n Web로 통신한다. 에이전트도 같은 서버 메서드를 호출할 수 있다.
- 앱 자체를 공유하면 같은 상태에서 협업하고, Blueprint를 공유하면 코드만 복제한 독립 앱을 만들 수 있다. 원본의 SQLite 데이터·대화 기록·자격 증명·연결 리소스는 복제하지 않는다.
README는 각 사용자가 SaaS의 중앙 앱을 공유하는 대신 앱의 자기 복사본을 실행하고 AI로 직접 수정할 수 있다는 점을 Cloudflare OS의 핵심 변화로 설명한다. 다만 “샌드박스가 보안 버그로 인한 유출을 막는다”는 표현은 프로젝트의 설계 주장이지, 이 노트에서 재현한 보안 보증이 아니다.
모델과 비용
Cloudflare 블로그는 어떤 모델이든 사용할 수 있고 모든 추론 요청이 AI Gateway를 통과한다고 설명한다. 조직은 업무별 모델을 지정하고, 간단한 요약에는 저렴한 모델을 사용하며, 요청을 사람·팀·작업공간에 귀속하고 예산과 속도 제한을 설정할 수 있다. README도 여러 주요 모델 제공자와 self-hosted 모델을 지원한다고 설명하지만, 제공자별 연결과 OAuth 구성은 별도 Gatekeeper 설정이 필요하다.
오픈소스 상태와 실측 메타데이터
- 공식 블로그는
cloudflare/cloudflare-os코어와cloudflare/cloudflare-os-starter예제 배포 저장소를 공개했다고 밝혔다. - 코어는 Cloudflare 계정에 배포할 수 있고, 조직별 Access 정책·AI Gateway·데이터·Gatekeeper·UI·통합 기능을 붙이는 구조다.
- README의 현재 안내는 early access이며, 2026년 8월 릴리스가 아직 거친 부분이 많다고 명시한다. 로컬 실행은
pnpm run-local으로 가능하지만 production용 방식은 아니라고 적혀 있다.workerd위에서 자체 서버에 배포하는 경로는 “coming soon”으로 설명한다. - GitHub API 실측(2026-08-06): 2,790 stars · 182 forks · 11 open issues · TypeScript · Apache-2.0. 확인한 기본 브랜치 최신 커밋은
aedcda8b3066ff666f57ae28ecef7341d6c2dee7이며, README 바이트 SHA-256은ff1ebbd4e4a04fbf0f8a1da7f7236bb1f68888741ef7acc3775d4df535bfb526이다. - 이 저장소의 로컬 빌드,
pnpm run-local, Gatekeeper OAuth 연결, Gadget 샌드박스 탈출 테스트, 권한 전파 테스트는 실행하지 않았다.
Hada 큐레이션과 커뮤니티 반응
다음은 Cloudflare의 공식 문서가 아니라 Hada News에 보존된 큐레이션·댓글 층위다.
- Cloudflare OS가 10년 전 Sandstorm.io의 아이디어를 Workers와 AI로 다시 구현한 개인용 앱 바이브 코딩 플랫폼에 가깝다는 평가가 소개됐다. Gadget별 코드·데이터 격리와 AI를 통한 기능 추가가 차별점이라는 관점이다.
- 반대로 컨테이너나 MicroVM 대비 Grain/Durable Worker 샌드박스의 실질적 이점, 에이전트 탈출 방어 수준이 아직 핵심 검증 질문으로 남는다는 우려가 있었다.
- 공급업체 종속에 대해서는 “오픈소스·자체 배포 가능”이라는 반응과, Cloudflare 전용 서비스·설정에 깊게 의존하면 이식성이 낮아진다는 반론이 함께 나왔다. README상
workerd자체 서버 배포 문서가 아직 준비 중이라는 점을 고려하면, 현재는 완전한 이식성보다 Cloudflare 생태계 최적화에 가깝다. - 사용자별 앱 복사본이 늘어날 때 스키마 변경·유지보수·퇴사자 앱의 장기 관리, HIPAA 같은 민감 데이터의 저장·공유 정책이 어떻게 운영될지도 미해결 질문으로 제기됐다.
- “OS”라는 명칭이 기술적 은유인지 마케팅 용어인지에 대한 논쟁도 있었다. README는 회사의 AI 생산성 운영체제와 AI workload를 관리하는 운영체제라는 두 가지 의미를 제시한다.
나의 판단
가장 중요한 부분은 “OS”라는 이름이 아니라 관찰 리소스 기반 권한 전파와 사용자별 실행 가능한 앱 인스턴스다. MCP 도구 목록이나 단순 RBAC만으로는 에이전트가 읽은 데이터가 이후 대시보드·파일·다른 에이전트·외부 API로 흘러가는 경로를 충분히 통제하기 어렵다. Cloudflare OS의 설계는 이 문제를 플랫폼의 공통 보안 경계로 끌어올리려 한다는 점에서 의미가 있다.
동시에 이 구조는 “앱을 쉽게 만든다”보다 “앱이 계속 늘어나는 조직의 소프트웨어 자산을 누가 관리하는가”가 더 어려운 문제다. Gadget마다 코드와 상태가 분기되면 사용자 맞춤화의 자유는 커지지만, 보안 패치·스키마 마이그레이션·감사·폐기·소유권 이전이 새 운영 체계가 된다. 따라서 Cloudflare OS는 범용 SaaS의 대체재라기보다, 조직 내부 시스템에 대한 capability 경계와 AI 생성 앱을 함께 운영하려는 팀을 위한 Cloudflare 중심의 early-access 실험으로 보는 것이 현재 가장 현실적이다.
관련 노트
- moc-ai-agents — AI 에이전트 전체 지도
- moc-cloudflare-open-source — Cloudflare 최근 오픈소스 지도
- moc-ai-agents-harness — 하네스·실행 경계·보안 설계
- 2026-04-15-cloudflare-mesh-private-agent-networking — Cloudflare의 에이전트·Workers 프라이빗 네트워킹
- 2026-04-16-cloudflare-project-think — Durable Objects 기반 장기 실행 에이전트 인프라
- 2026-04-17-cloudflare-ai-platform-inference-layer — Cloudflare AI Gateway와 추론 계층
- mcp — 도구·리소스 연결 프로토콜
출처 및 검증
- 사용자 제공 큐레이션: Hada News #32185 — readable extraction raw body SHA-256:
f534e9123dfcb8e04a952f0dd35f5cabe6efee7a446c41a96d3f36f452f21fd4 - 1차 출처: Cloudflare Blog — Cloudflare OS — readable extraction raw body SHA-256:
054e1a184721cc0acd5b34d72b3883c200d09e8a0eec3a4e8595a39824a0c335 - 구현/설계 출처: cloudflare/cloudflare-os — pinned commit
aedcda8b3066ff666f57ae28ecef7341d6c2dee7, README byte SHA-256:ff1ebbd4e4a04fbf0f8a1da7f7236bb1f68888741ef7acc3775d4df535bfb526, stored raw body SHA-256:af93a7ca30ac0d76786a58bc43aa85fce8dec51882443f30fdd6a6b447db7e2f - Hada raw에는 큐레이터 요약과 댓글을 포함한 Jina AI readable extraction을 그대로 보존했다. 공식 블로그 raw의 이미지 6개 URL은 저장 후 훅이
raw/articles/assets/임베드로 정규화했으며, 위 해시는 최종 파일에서 재계산했다. 공식 주장, README의 프로젝트 주장, Hada 커뮤니티 해석을 서로 구분했다.