Cloudflare가 에이전트·앱·업무를 위한 오픈소스 플랫폼 "Cloudflare OS"를 공개했다. 조직 내부 시스템에 연결된 에이전트 워크스페이스, 리소스 접근을 중재하는 Gatekeeper 보안 모델, Durable Object Facet 기반 앱 런타임으로 구성된다. 내부적으로 수천 명의 Cloudflare 직원이 사용하는 첫 번째 버전을 기반으로 재설계해 오픈소스로 배포한다.
핵심 포인트- 모든 앱은 Dynamic Worker(V8 isolate)로 실행되고, 각자 독립된 SQLite 데이터베이스를 가지는 Durable Object Facet으로 상태를 격리한다
- Gatekeeper는 외부 서비스와 Cloudflare OS 사이에서 OAuth 인증·정책 집행·접근 범위 제한·감사 기록을 담당하는 Worker로, 크리덴셜을 에이전트에게 직접 전달하지 않는다
- 에이전트가 읽은 모든 리소스가 관찰 로그에 기록되고, 협업자가 워크스페이스에 접근할 때 Gatekeeper가 해당 리소스에 대한 협업자 권한을 재검증한다
- Cap'n Web(Cloudflare 오픈소스 RPC)으로 브라우저 클라이언트와 서버 메서드를 직접 호출하고, 동일 메서드를 에이전트도 호출할 수 있어 앱 도구를 에이전트도 사용할 수 있다
- AI Gateway가 모든 추론 호출을 중개하며 모델 선택·비용 제어·비용 귀속·속도 제한을 중앙에서 처리한다
상세 정리- 첫 번째 버전의 한계: 개인 워크스페이스 중심이라 협업 시 한 사람의 맥락이 다른 사람에게 노출될 수 있었다. MCP 서버가 어떤 툴을 쓸 수 있는지는 알려줬지만 어떤 기저 리소스를 관찰했는지는 추적하지 않았다.
- 에이전트 기본 접근 권한 없음: Cloudflare Access로 진입 제어 후 내부에서 모든 에이전트·앱은 아무것도 접근할 수 없는 상태에서 시작한다. 허용된 리소스는 env.PROJECT처럼 타입 바인딩으로 전달된다. 크리덴셜은 에이전트 코드에서 완전히 격리된다.
- 서버 코드 격리: Dynamic Worker는 전역 아웃바운드 네트워킹이 비활성화된다. 브라우저 클라이언트 코드는 샌드박스 프레임에서 실행된다. 명시적으로 제공한 capability를 통해서만 외부 인터넷에 접근할 수 있다.
- Gatekeeper 역할: 특정 서비스별 Worker로, 전체 GitHub 계정 대신 단일 저장소 접근, 소스 코드 제외 이슈 읽기, 특정 필드 마스킹, 속도 제한, PR 머지 전 승인 요구 같은 세밀한 정책을 강제할 수 있다.
- 관찰 기반 정책: 에이전트가 민감한 데이터를 읽으면 해당 관찰이 에이전트와 그 결과물에 태그된다. 다른 사람이 워크스페이스나 앱 결과를 열려고 하면 Gatekeeper가 원본 리소스에 대한 접근 권한을 재검증한다.
- 앱 아키텍처: 앱은 클라이언트 코드(브라우저 렌더링)와 서버 코드(상태 저장)로 구성된다. 서버는 Dynamic Worker로 온디맨드 로드되고 Durable Object Facet으로 독립 SQLite를 갖는다. V8 isolate 기반이라 전용 서버 없이 앱별 격리 런타임이 가능하다.
- Cap'n Web RPC: 브라우저 클라이언트가 서버 메서드를 일반 함수처럼 호출하고, 에이전트도 동일한 메서드를 호출한다. 앱 도구를 에이전트가 자동으로 사용할 수 있게 되는 핵심 메커니즘이다.
- 앱 공유 모델: 앱 자체를 공유하면 실시간 협업(동일 상태 공유). 블루프린트를 공유하면 각자 독립 복사본 생성(코드는 공유, SQLite 데이터·크리덴셜은 미공유). 앱 수신자가 AI로 직접 수정할 수 있다.
왜 읽나Workers와 Durable Object로 다중 사용자 에이전트 앱을 격리 실행하는 아키텍처, 또는 Gatekeeper 패턴으로 내부 시스템에 안전한 에이전트 접근을 부여하는 설계에 관심 있는 엔지니어에게.
Cloudflare Blog·
당근 테크블로그·
우아한형제들·