Cloudflare OS 공개, 에이전트 샌드박스와 역량 기반 권한

Cloudflare 가 2026년 8월 5일 Agents Week 일정에 맞춰 Cloudflare OS 를 오픈소스로 공개했습니다. 이름은 OS 지만 커널을 새로 만든 물건은 아닙니다. AI 에이전트가 짜낸 코드를 샌드박스 안에서 돌리고, 외부 서비스 접근은 별도 권한 계층을 거치게 만든 워크스페이스입니다. 저장소는 cloudflare/cloudflare-os 이고 라이선스는 Apache-2.0 이며, 여기서는 구성 요소가 어떻게 나뉘어 있는지와 지금 어느 단계인지를 확인된 범위 안에서 정리합니다.

Gadget, Gatekeeper, Workshop Backend 로 나뉜 구조

Cloudflare 블로그의 발표문과 저장소 README 를 같이 놓고 보면 시스템은 세 덩어리로 나뉩니다.

• Gadget: 에이전트가 만들어 낸 앱의 사설 인스턴스
• Gatekeeper: 외부 서비스 앞에 놓이는 서비스별 Worker
• Workshop Backend: README 가 직접 "our kernel" 이라고 부르는 패키지

Gadget 은 문서 하나에 앱 인스턴스 하나가 붙는 모델입니다. README 의 예시를 옮기면, 슬라이드 덱을 만들 때 클라우드 어딘가의 SaaS 를 호출하지 않습니다. 시스템이 사용자 전용 사설 슬라이드 덱 인스턴스를 새로 띄웁니다. 각 Gadget 의 서버 코드는 필요할 때 Dynamic Worker 로 로드되고 Durable Object Facet 으로 인스턴스화되는데, 그 조합 덕분에 앱마다 자기 SQLite 데이터베이스와 가벼운 V8 아이솔레이트를 갖게 됩니다. 앱 하나당 서버나 컨테이너를 따로 세우는 방식이 아니라는 점이 이 구조의 전제입니다. 발표문에 따르면 Dynamic Worker 와 Facet 은 이 프로젝트를 위해 Workers 런타임에 추가된 기능입니다.

Gatekeeper 는 Cloudflare OS 와 외부 서비스 사이에 앉는 Worker 입니다. 해당 서비스의 API 와 리소스, 그 위에서 수행 가능한 동작을 알고 있습니다. OAuth 를 처리하고 자격증명을 보관하고 정책을 적용하며, 무엇을 읽었는지 기록하고 외부에 보이는 부수 효과를 중개합니다. README 는 이걸 "supercharged MCP servers" 라고 표현합니다. Workshop Backend 쪽은 사용자를 프로그램과 장치에 연결하면서 샌드박싱과 접근 제어를 구현한다는 점에서 실제 OS 커널이 맡는 역할과 겹칩니다. 이름을 OS 로 붙인 근거가 이 패키지에 있는 셈입니다.

내 코드가 이 안에서 할 수 있는 것과 못 하는 것

여기에 올려 둔 코드에는 세 가지 제약이 걸립니다.

• 서버 코드는 global outbound networking 이 꺼져 있습니다. 임의의 주소로 요청을 보낼 수 없고, 외부로 나가는 통신은 Gatekeeper 를 거치는 길만 남습니다.
• 클라이언트 코드는 브라우저의 샌드박스 프레임 안에서 돕니다. UI 쪽에서 실행되는 코드는 워크스페이스의 다른 부분을 건드리지 못합니다.
• 앱마다 SQLite 데이터베이스가 따로 붙습니다. 앱 사이에 데이터를 옮기려면 중개 계층을 한 번 더 거쳐야 합니다.

대신 사용자가 앱 코드를 직접 고쳐도 남에게 영향이 가지 않습니다. 공유 SaaS 인스턴스에서는 취약점 하나가 그 인스턴스를 쓰는 모두에게 번지지만, 사용자마다 사본이 따로 뜨면 사고 반경이 그 사본 안에서 끝납니다. 인증서 하나가 만료되면서 클러스터의 Pod 가 통째로 안 뜨던 상황처럼 공유 자원 한 곳이 전체를 멈추는 구조와는 반대 방향입니다.

에이전트에 무엇을 허용하고 무엇을 막게 되는가

안에서 도는 모든 에이전트와 앱은 아무것에도 접근할 수 없는 상태에서 시작합니다. 허용은 바인딩을 건네는 방식으로 합니다. 리소스는 타입이 붙은 바인딩으로 코드에 들어가고, 발표문에 나오는 예시는 const issues = await env.PROJECT.listIssues() 같은 모양입니다. 코드로 넘어가는 건 env.PROJECT 라는 참조뿐이고, 실제 자격증명은 에이전트와 생성된 코드로부터 분리된 채로 남습니다.

막는 쪽에는 승인 게이트가 있습니다. 발표문은 pull request 를 병합하기 전에 승인을 요구하도록 Gatekeeper 를 구성할 수 있다고 적고 있습니다. 승인 대기가 곧 정지로 이어지지 않도록, 승인이 필요한 동작은 결과를 로컬에서 시뮬레이션해 두고 에이전트가 다음 작업을 계속 쌓게 합니다. 읽은 것도 남습니다. 에이전트가 관찰한 리소스가 기록되어 작업에 따라다니고, 결과물을 다른 사람과 공유할 때 Gatekeeper 가 그 사람의 접근 권한을 확인합니다.

허용 범위를 넓히는 대가는 설정 시간입니다. 서비스마다 OAuth 클라이언트 자격증명을 따로 발급받아야 하기 때문입니다. 자격증명을 애플리케이션 코드에서 떼어 내 별도 계층이 쥐게 하는 발상 자체는 EKS 위의 Vault 를 Raft 백엔드로 운영하며 정리한 장애 복구 기록에서 다룬 시크릿 관리와 같은 문제를 풀지만, Gatekeeper 는 시크릿 보관에서 멈추지 않고 그 시크릿으로 수행되는 동작 단위까지 정책을 걸고 기록을 남깁니다.

로컬에서 돌려 보기와 배포에 필요한 것

pnpm 을 설치한 뒤 pnpm run-local 을 실행하고 http://localhost:8787 을 열면 동작을 바로 볼 수 있습니다. README 는 이 경로가 프로덕션용이 아니라 제품이 뭘 하는지 빠르게 확인하는 방법이라고 못 박아 둡니다. 자기 Cloudflare 계정에 올리려면 os.cloudflare.app/deploy 의 배포 플로를 쓰고, 커스텀 Gatekeeper 를 붙이거나 코드를 손봐야 하면 cloudflare-os-starter 저장소를 씁니다. 이쪽 저장소도 Apache-2.0 입니다.

starter 저장소의 README 가 요구하는 준비물은 이렇습니다.

• Node.js 24 와 pnpm 11
• wrangler login 을 마친 Cloudflare 계정
• 계정에서 쓸 수 있어야 하는 Workers, KV, R2, Browser Rendering, Dynamic Worker Loaders
• deployment.jsonc 에 채워 넣을 계정 ID, Worker 이름, 호스트명, Access audience, 관리자 이메일

순서는 서브모듈 초기화와 의존성 설치를 마친 뒤 pnpm check 로 검증하고 pnpm deploy 로 올리는 흐름입니다. 배포가 끝나면 /admin 에서 브랜딩을 포함한 설정을 재배포 없이 바꿀 수 있다고 적혀 있습니다.

실제로 손이 많이 가는 부분은 Gatekeeper 설정 쪽입니다. README 는 상당수 Gatekeeper 가 서드파티 서비스에 연결되려면 별도 설정을 필요로 하고, 서비스마다 OAuth 클라이언트 자격증명을 따로 발급받아야 한다고 밝히고 있습니다. GitHub, Google, Slack 이 각각 별개의 등록 대상입니다. 붙이려는 서비스가 많을수록 초기 세팅 시간이 늘어난다고 보면 됩니다. 반대로 연결할 곳이 하나뿐이라면 이 전체를 세우기보다 작은 앱을 직접 하나 짜는 편이 빠를 수도 있습니다.

early access 라는 자체 진단과 Sandstorm 계보

README 는 현재 상태를 숨기지 않습니다. 프로젝트가 heavy development 상태이고, 2026년 8월 릴리스 기준으로 Cloudflare OS v2 는 쓸 만하지만 거친 부분이 많다고 적혀 있습니다. 알고 있고 고치는 중이라는 문장이 뒤따릅니다. v2 는 v1 에서 배운 것을 새 토대 위에 다시 올린 재작성판이고, 서버 환경의 workerd 위에 직접 배포하는 문서는 아직 준비 중이라고 나옵니다. 사내 도구로 곧장 세워 두기보다는 구조를 보고 판단할 재료로 다루는 편이 지금 단계에 맞습니다.

출처를 구분해 둘 부분이 하나 있습니다. Cloudflare 블로그 발표문에는 Sandstorm.io 나 Kenton Varda 에 대한 언급이 없습니다. 이 프로젝트를 Sandstorm 의 재작업으로 설명하는 이야기는 Kenton Varda 본인의 X 게시물에서 나옵니다. 그 글은 이번 릴리스를 10년 전 자신의 스타트업이던 Sandstorm.io 를 이번에는 Cloudflare Workers 위에 다시 만든 것이라고 설명합니다. 회사 공식 발표문의 서술과 개인 계정의 서술은 무게가 다릅니다.

계보를 알고 보면 설계 의도가 조금 더 읽힙니다. 문서마다 앱 인스턴스를 따로 두는 방식과 자격증명 대신 능력을 건네는 방식은 10년 전에도 있던 아이디어입니다. 당시 자리를 잡지 못한 원인을 무엇으로 볼지는 사람마다 다르겠지만, 앱 인스턴스를 문서 단위로 뿌릴 만큼 실행 환경이 가벼워진 시점이 그때는 아니었다는 점만은 분명합니다. 지금은 V8 아이솔레이트 위에서 그게 가능해졌고, 배포한 앱을 유지보수할 개발자가 필요하다는 또 다른 걸림돌도 에이전트가 코드를 직접 고치는 방식으로 다르게 풀리는 중입니다.

지금 이 구조를 참고할 조건

에이전트가 만든 코드를 사용자별 사본으로 띄우고 외부 접근을 한 계층에 모을 수 있는 팀이면 이 구조를 참고할 가치가 있습니다. 서버 코드가 외부 주소를 직접 호출해야 하는 워크로드라면 outbound networking 이 꺼진 Dynamic Worker 전제와 어긋나므로, 그 호출을 Gatekeeper 로 옮기는 재설계가 먼저입니다.

남는 변수는 단계입니다. v2 는 README 스스로 early access 로 진단하는 단계라, 프로덕션 투입은 아직 이릅니다.

저장소를 받아 Gatekeeper 가 자격증명을 쥐는 지점부터 읽어 보세요.