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 로 붙인 근거가 이 패키지에 있는 셈입니다.

샌드박스 격리가 에이전트 맥락에서 달라지는 지점

에이전트가 코드를 쓰고 그 코드를 곧바로 실행하는 환경에서는, 리뷰를 통과한 코드와 통과하지 않은 코드의 경계가 흐려집니다. 사람이 매번 읽고 승인하기에는 생성량이 많습니다. 그렇다고 실행을 막아 두면 도구로서 쓸모가 없어집니다. 그래서 설계가 격리 단위를 잘게 쪼개는 쪽으로 기울게 됩니다.

Cloudflare OS 의 답은 실행 단위를 문서 수준까지 내리는 것입니다. 공유 SaaS 인스턴스에서는 취약점 하나가 그 인스턴스를 쓰는 모두에게 번지지만, 사용자마다 사본이 따로 뜨면 사고 반경이 그 사본 안에서 끝납니다. 사용자가 앱 코드를 직접 고쳐도 남에게 영향이 가지 않는다는 성질도 여기서 나옵니다. 격리 단위가 잘게 쪼개지면 장애도 잘게 쪼개집니다. 인증서 하나가 만료되면서 클러스터의 Pod 가 통째로 안 뜨던 상황처럼 공유 자원 한 곳이 전체를 멈추는 구조와는 반대 방향입니다.

서버 코드에서 global outbound networking 을 꺼 둔 설정도 같은 맥락입니다. 생성된 코드가 임의의 주소로 요청을 보낼 수 없으면, 데이터를 밖으로 빼내는 경로가 기본값에서 사라집니다. 외부로 나가는 통신은 Gatekeeper 를 거치는 길만 남습니다. 클라이언트 코드를 브라우저의 샌드박스 프레임 안에서 돌리는 것도 같은 이유입니다. UI 쪽에서 실행되는 코드가 워크스페이스의 다른 부분을 건드리지 못하게 막아 두는 겁니다.

이 방식이 공짜는 아닙니다. 인스턴스가 늘어나면 상태가 흩어지고, 앱 사이에 데이터를 옮기려면 결국 중개 계층을 한 번 더 거쳐야 합니다. 공유가 편한 구조를 포기하고 격리를 산 선택이라고 보는 편이 정확합니다.

자격증명 대신 능력을 건네는 역량 기반 권한

발표문의 문장 하나가 이 설계의 출발점을 요약합니다. 안에서 도는 모든 에이전트와 앱은 아무것에도 접근할 수 없는 상태에서 시작한다는 것입니다. 리소스는 타입이 붙은 바인딩 형태로 코드에 건네지고, 발표문에 나오는 예시는 const issues = await env.PROJECT.listIssues() 같은 모양입니다. 여기서 env.PROJECT 는 특정 정책 아래 특정 리소스를 쓸 수 있는 권한을 나타내는 capability 이고, 실제 자격증명은 에이전트와 생성된 코드로부터 분리된 채로 남습니다.

전통적인 접근 제어는 주체에게 신원을 주고 리소스마다 목록을 붙이는 쪽입니다. 코드가 이름만 알면 일단 시도는 할 수 있고, 통과 여부는 그때그때 판정됩니다. 역량 기반 모델은 반대로 갑니다. 참조를 손에 쥐고 있지 않으면 이름을 알아도 호출할 방법이 없습니다. 권한이 코드 밖의 정책 테이블이 아니라 코드가 받은 인자 안에 들어 있는 셈입니다.

이 차이가 에이전트에서 커지는 이유는 판단 주체가 확률적이기 때문입니다. 모델은 잘못된 지시를 받아들일 수 있고, 읽어 들인 문서에 섞여 있던 문장을 명령으로 오해할 수도 있습니다. 신원 기반 모델에서는 그 오해가 곧바로 접근 시도로 이어지지만, 역량 기반 모델에서는 건네받지 않은 능력을 행사할 방법 자체가 없습니다. 다만 이 해석은 모델 구조가 주는 일반적인 성질이고, Cloudflare 발표문이 프롬프트 인젝션을 지목하며 설명한 대목은 아닙니다.

자격증명을 애플리케이션 코드에서 떼어 내 별도 계층이 쥐게 하는 발상 자체는 낯설지 않습니다. EKS 위의 Vault 를 Raft 백엔드로 운영하며 정리한 장애 복구 기록에서 다룬 시크릿 관리도 결국 같은 문제를 풉니다. 차이는 Gatekeeper 가 시크릿 보관에서 멈추지 않고, 그 시크릿으로 수행되는 동작 단위까지 정책을 걸고 기록을 남긴다는 점입니다.

사람 승인도 이 계층에 붙습니다. 발표문은 pull request 를 병합하기 전에 승인을 요구하도록 Gatekeeper 를 구성할 수 있다고 적고 있습니다. 승인 대기가 곧 정지로 이어지지 않도록, 승인이 필요한 동작은 결과를 로컬에서 시뮬레이션해 두고 에이전트가 다음 작업을 계속 쌓게 합니다. 읽은 것도 남습니다. 에이전트가 관찰한 리소스가 기록되어 작업에 따라다니고, 결과물을 다른 사람과 공유할 때 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 가 early access 이고 거친 부분이 많다는 진술은 README 에서 나왔으니, 프로덕션 판단 전에 cloudflare/cloudflare-os README 가 같은 문장을 유지하고 있는지 확인해야 합니다.

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