에이전트를 위한 운영체제 — Cloudflare OS와 플랫폼 전쟁의 다음 국면
에이전트를 위한 운영체제 — Cloudflare OS와 플랫폼 전쟁의 다음 국면
Cloudflare가 내놓은 ‘OS’는 정말 운영체제인가, 아니면 워커스(Workers) 위에 AI를 얹은 앱 플랫폼에 붙은 야심찬 이름인가. 그리고 ‘개방형’이라는 간판은 락인을 지우는가, 아니면 다른 방식으로 새로 그리는가.
도입 — 엣지 회사가 ‘운영체제’를 자처할 때
2026년 8월 5일, Cloudflare가 “에이전트·앱·업무를 위한 개방형 플랫폼(an open platform for agents, apps, and work)“을 표방하는 Cloudflare OS를 공개하고, 같은 날 코드를 GitHub에 오픈소스로 올렸다. 발표문에 따르면 이 플랫폼은 “회사의 모든 사람이 앱을 만들고, 업무를 자동화하고, 내부 시스템에 안전하게 접근하도록 하는 오픈소스 플랫폼”이다. 개발자만이 아니라 브라우저를 쓰는 비개발자까지 대상으로 삼았다는 점을 반복해 강조한다.
흥미로운 것은 이것이 하룻밤에 나온 데모가 아니라는 점이다. 발표문은 이 시스템의 첫 사내 버전이 2025년 5월에 Cloudflare 직원들에게 배포됐고, 지금은 여러 부서에 걸쳐 “수천 명”이 매일 쓰고 있다고 밝힌다. 즉 회사가 1년 넘게 자기 조직을 실험대 삼아 돌려 본 내부 도구를, 이제 남들도 자기 회사에 배포할 수 있도록 개방한 것이다.
그런데 왜 하필 ‘운영체제’인가. 엣지 캐시와 서버리스 함수로 알려진 회사가 왜 커널도 드라이버도 아닌 물건에 OS라는 이름을 붙였는가. 이 이름은 즉시 논쟁을 불렀다. 이 글은 두 가지를 분리해서 본다. 첫째, 무엇이 실제로 발표됐고 어떤 구성요소로 이뤄졌는가라는 팩트. 둘째, 이것이 하이퍼스케일러·Vercel과의 경쟁 구도에서 무엇을 노리며, ‘개방형’이라는 포지셔닝의 실체와 락인 위험은 어디에 있는가라는 분석. 이름을 둘러싼 소음과 그 아래 놓인 기술적 베팅은 다른 층위의 문제다.
무엇이 발표되었나 — ‘OS’라는 이름 아래 묶인 세 조각
먼저 팩트다. 발표문 기준으로 Cloudflare OS는 세 개의 축으로 구성된다.
첫째는 **에이전트 워크스페이스(Agent Workspace)**다. 발표문의 표현으로는 “회사가 큐레이션한 컨텍스트와 스킬에 기반하며, 에이전트가 코드를 작성하고 실행할 수 있는 격리된 런타임”을 갖춘 작업 공간이다. 팀이나 회사가 모아 둔 컨텍스트와 스킬이 미리 적재돼 있어서, “누군가가 어떤 일을 하는 최선의 방법을 알아냈다면 모두가 그 덕을 본다”는 것이 핵심 주장이다. 리서치, 문서·슬라이드 작성, 협업형 앱, 그리고 “결정론적 워크플로(deterministic workflows)“까지 여러 형태의 일을 지원한다고 한다.
둘째는 보안·거버넌스 프레임워크다. 여기서 핵심 장치가 ‘게이트키퍼(Gatekeeper)‘다. 발표문에 따르면 게이트키퍼는 서비스별로 존재하는 워커(Worker)로, 자원 접근을 관장하며 OAuth를 강제하고 “자격증명을 보유하고, 정책을 집행하고, 무엇을 읽었는지 기록”한다. 통합 표준으로는 오픈 표준인 MCP(Model Context Protocol)를 채택했고, MCP 자체도 일종의 게이트키퍼로 취급된다. 여기에 더해 에이전트가 관측한 모든 자원을 기록하는 관측 로깅(observation logging)이 있어서, 그 관측 기록이 에이전트와 그 작업에 계속 붙어 다닌다.
셋째는 앱 플랫폼이다. 발표문은 “각 ‘파일’이 그 자체로 하나의 애플리케이션이 될 수 있다 — 한 사람, 한 프로젝트, 한 팀을 위해 에이전트가 작성한 앱”이라고 설명한다. 고정된 앱 세트를 제공하는 정적 생산성 도구와 달리, 개인이 만들고 공유하고 계속 고쳐 쓸 수 있는 앱을 지향한다. 기본으로 docs·slides·sheets 세 개의 청사진(blueprint)이 설치된다.
기술적 토대는 Cloudflare가 오래 밀어 온 서버리스 기반 위에 있다. 앱은 개별 SQLite 데이터베이스를 가진 “Durable Object Facet”으로 인스턴스화되며, 경량 V8 아이솔레이트(isolate)를 쓴다. 게이트키퍼는 도구(tool)를 노출하는 대신 Cap’n Web RPC API를 노출해, 에이전트가 서버 메서드를 “평범한 자바스크립트 함수처럼” 호출하게 한다. 모델은 특정 벤더에 묶이지 않아 “어떤 모델과도 쓸 수 있고”, 요청을 Cloudflare AI Gateway로 라우팅하면 어떤 모델을 허용할지 한곳에서 정하고, 모든 요청을 사람·팀·워크스페이스 단위로 귀속시켜 비용을 붙이고, 예산·레이트 리밋을 걸 수 있다.
‘개방형’이라는 간판의 물증도 발표에 포함됐다. 코드는 당일 GitHub에 두 개의 저장소(코어 플랫폼, 스타터 배포본)로 공개됐고, 배포본은 “당신 자신의 Cloudflare 계정”에서 “당신 자신의 Access 정책”으로 돌아간다. 인터페이스를 커스터마이즈하고 내부용 게이트키퍼를 추가하고 조직 고유 기능을 붙일 수 있다. 파트너로는 Presidio와 Happy Cog이 배포 커스터마이즈와 공용 스킬 큐레이션을 돕는다고 명시됐다.
그렇다면 왜 ‘OS’인가. GitHub README는 두 가지 의미를 든다 — 보안팀이 안심하고 잘 수 있는 방식으로 회사가 AI로 생산성을 내게 하는 ‘운영체제’, 그리고 전통적 OS가 컴퓨트 워크로드를 관리하듯 AI 워크로드를 관리한다는 의미의 ‘운영체제’다. HN 토론에서는 이 명명이 과하다는 반응이 다수였는데, 정작 Cloudflare의 Workers 창시자 Kenton Varda 본인이 스레드에 나타나 “우리는 이름 짓는 데 그리 영리하지 않다”며, 지난주에 더 나은 이름을 짜 봤지만 아무도 합의하지 못해 그냥 사내에서 부르던 대로 나갔다고 털어놨다는 점은 기록해 둘 만하다(HN 토론에서 나온 본인 해명, 의역).
왜 지금 Cloudflare인가 — Sandstorm의 재림과 ‘엣지’에서 ‘에이전트 런타임’으로
여기서부터는 분석이다. 이 발표의 무게중심은 발표문 본문이 아니라, HN 토론에 직접 등장한 Kenton Varda의 해설에 있었다. 그는 이것이 사실상 자신이 10년 전 창업했던 Sandstorm.io의 리메이크이며, 이번에는 지난 9년간 만들어 온 Cloudflare Workers 위에 AI를 깊이 결합해 다시 지은 것이라고 밝혔다(HN 토론에서 공유된 본인 트윗의 의역). 그가 내세운 핵심 주장은 강했다 — 샌드박스가 너무 안전해서, 에이전트가 “의미 있는 보안 버그를 끼워 넣을 수 없다”는 것. 비개발자가 개인용 앱을 마음껏 ‘바이브 코딩’해도 사고가 나지 않는 플랫폼을 지향한다는 것이다.
Sandstorm의 유령을 불러내면 왜 지금인지가 선명해진다. Sandstorm의 진짜 혁신은 문서 하나하나를 각자의 컨테이너에 담는 미세 격리였는데, 콜드 스타트 시간과 메모리 사용량 때문에 실전에서 잘 안 돌았다는 것이 Varda 본인의 회고다(HN 토론, 의역). 문서 하나 열 때마다 수백 MB를 먹고 몇 초씩 기다려야 한다면 못 쓴다. 그가 든 해법이 컨테이너가 아니라 Dynamic Workers, 즉 V8 아이솔레이트 기반의 경량 실행 단위이고, 컨테이너 대비 “100배 효율적”이라고 주장했다. 요컨대 9년간 Workers를 만든 것이 결국 Sandstorm이 필요로 했던 바로 그 조각이었다는 이야기다. 이 서사가 사실이라면, Cloudflare OS는 신제품이라기보다 오래 준비된 인프라가 AI라는 수요를 만나 형태를 갖춘 것에 가깝다.
이 지점이 경쟁 구도의 핵심이다. AWS·Vercel·하이퍼스케일러가 모두 ‘에이전트 런타임’을 향해 달려가지만, 각자 출발점이 다르다. AWS는 마이크로VM(Firecracker) 기반의 격리를 무기로 컴퓨트의 바닥부터 위로 올라오고, Vercel은 프론트엔드 배포와 AI SDK·생성 UI에서 위로 내려온다. Cloudflare는 이미 전 세계에 깔린 엣지 아이솔레이트라는 독특한 자산에서 옆으로 확장한다. 엣지/서버리스 회사가 AI 에이전트 런타임을 자처한다는 것은, 캐시와 함수 판매를 넘어 “모든 것이 자기를 통과하게 하려는” 가장 넓은 그물을 던지는 시도로 읽힌다(HN 토론에서 나온 관측의 의역).
그러나 이 베팅에는 명확한 트레이드오프가 있다. 격리의 층위 문제다. HN 토론에서 한 참가자는 OpenAI조차 에이전트가 컨테이너를 탈출하는 바람에 컨테이너에서 마이크로VM으로 갈아탄 사례를 들며, 애플리케이션 레벨 격리가 충분히 강한가라고 물었다(의역). 더 날카로운 지적도 있었다 — Workers 런타임(workerd)의 GitHub 문서 자체가 “workerd는 하드닝된 샌드박스가 아니다”라고 경고하며, 악의적 코드를 돌릴 때는 반드시 VM 같은 별도의 보안 샌드박스 안에서 실행하라고 명시한다는 것이다. 이를 근거로 “Sandstorm은 제대로 된 샌드박싱을 했는데 이건 그에 비하면 약하다”는 비판이 나왔고, V8에 버그 하나만 나면 격리가 무너진다는 우려도 제기됐다(HN 토론, 의역). 이에 대해 Varda 측은 Cloudflare의 상용 호스팅은 여러 겹의 심층 방어를 추가로 두며, 셀프호스트 시에도 전체 스택을 스스로 격리해 돌릴 수 있다는 취지로 답했다.
보안 모델 자체도 뜯어볼 가치가 있다. Varda의 설명에 따르면 읽기(read)는 승인이 필요 없고 오직 쓰기(write)만 승인을 요구하되, 읽기는 명시적으로 첨부한 자원으로만 제한된다. 에이전트는 승인된 채널(게이트키퍼) 외에는 바깥 세계에 접근이 거의 없어서, 나중에 쓰기를 승인하지 않는 한 본 비밀을 유출하기가 사실상 어렵다는 것이다. 게다가 시스템은 에이전트가 관측한 것을 추적해 ‘오염(tainted)’ 여부를 판단하고, 프롬프트 인젝션이나 비밀 유출 가능성을 뒤늦은 행동에 플래그로 붙인다. 실제로 Cloudflare는 고객 데이터·매출 정보 같은 민감 소스에 연결할 때, 그 자원을 한 번 본 에이전트는 다른 어디에도 쓸 수 없게 강제하는 방식으로 사내 데이터를 붙였다고 한다(HN 토론, 의역). 다만 이 정책은 아직 “다소 뭉툭하고 과하게 제한적”이라는 자기 평가도 함께 나왔다. 회의론자는 이 구조가 여전히 피싱과 같은 위험 — 사용자가 승인만 하면 데이터가 새어 나가는 — 을 낮은 진입장벽으로 대량 생산할 수 있다고 봤다.
비교의 관점에서 또 하나 실용적인 논점은 과금이다. HN 토론에서는 이것이 Claude의 Cowork나 ChatGPT 데스크톱이 주는 능력과 뭐가 다르냐는 질문이 나왔는데, 한 가지 차이로 지목된 것이 좌석당 과금(per-seat)이었다. 팀원 10명이 공유 에이전트 인프라를 쓰려면 좌석 모델에서는 10 × 20달러 = 200달러/월이 들지만, 이 방식에서는 AI와 인프라 청구서만 내면 된다는 것이다(그 청구서가 200달러를 넘길 수도 있다는 단서와 함께). 반대편에는, 비기술 사용자가 온갖 SaaS의 MCP를 서로 연결하고 그 위에 AI를 얹으려는 흐름을 통제된 샌드박스 하나로 크게 단순화할 수 있다는, 엔터프라이즈 IT 관점의 실질적 가치를 지적하는 목소리도 있었다(HN 토론, 의역).
’개방형’의 실체와 락인의 새 지형
세 번째로 볼 것은 ‘개방형’이라는 포지셔닝의 실체다. 결론부터 말하면, 코드의 개방성은 진짜다. Varda는 이것이 100% 오픈소스이며 셀프호스트가 가능하고, 오픈소스인 Workers 런타임(workerd) 위에서 돌며, 원한다면 집에서도 돌릴 수 있다고 반복해 확인했다(HN 토론, 의역). 더 나아가 ollama와 일부 로컬 LLM으로도 “제법 잘 돌아가며”, 로컬에서 오히려 더 빠르고, AI Gateway 사용은 선택이라 API 키를 UI에 넣으면 Anthropic·OpenAI·Gemini·Workers AI·ollama에 직접 붙는다고 했다. 제품 이름과 로고도 관리자 설정에서 바꿀 수 있어서, 각 회사가 배포하면 “<회사명> OS”로 부르게 되는 구조다. 하이퍼스케일러의 관리형 에이전트 서비스가 대체로 자사 클라우드에 묶이는 것과 비교하면, 코드 수준의 개방성만 놓고 보면 분명히 더 열려 있다.
문제는 개방성의 층위가 하나가 아니라는 점이다. 코드는 열려 있어도 실행 모델은 Workers/JS에 강하게 묶인다. 현재 Cloudflare OS가 노출하는 언어는 JS뿐이고(TS는 곧 지원 예정), Wasm은 이론적으로 가능하지만 노출돼 있지 않다. Varda의 설명으로도 아이솔레이트 안에서는 언어 런타임을 앱에 번들할 필요가 없는 JS/TS가 훨씬 효율적이라, 이 선택은 성능상 의도된 것이다. 즉 이 플랫폼에서 앱을 짠다는 것은 Cloudflare가 설계한 아이솔레이트·Durable Object·Cap’n Web이라는 프리미티브 위에 아키텍처를 맞춘다는 뜻이다.
여기서 락인의 새로운 지형이 드러난다. HN 토론의 한 개발자는 이것이 “너무 Cloudflare 향(flavored)“이라 마음이 안 놓인다며, 중립적 제3자나 스타트업이 더 애그노스틱하게 만든 것이었으면 좋겠다고 했다. 그의 논지는 날카로웠다 — 오픈소스라 해도 결국 그들의 마인드셰어·유통·생태계를 사는 것이고, 그것이 장기적으로 우위와 락인으로 이어진다는 것이다(HN 토론, 의역). 이것은 전통적 락인, 즉 “빠져나올 수 없는 계약”과는 다른 종류다. 코드는 언제든 가져갈 수 있지만, 생태계의 중력 — 청사진 마켓플레이스, 게이트키퍼 에코시스템, 사내에 쌓인 스킬과 관측 기록 — 이 커질수록 옮겨 갈 이유가 줄어드는, 부드러운 락인이다. Varda 본인은 Workers 없이는 이걸 만들 수 없었고, 호환성을 넓게 유지하면서 기술의 최전선을 밀 수는 없다고 응수했다. 타당한 반론이지만, 동시에 ‘개방형’이라는 간판이 지우는 것은 계약상의 락인이지 중력 자체가 아님을 정확히 드러낸다.
개발자에게 주는 트레이드오프는 이렇게 요약된다. 런타임 중립성을 일부 내주는 대가로, 비개발자가 만든 앱조차 사고를 내기 어려운 보안 모델과 100배 효율의 실행 단위를 얻는다. 자기 조직에 비기술 사용자가 많고 통제된 자동화가 급한 곳이라면 이 교환은 남는 장사일 수 있다. 반대로 런타임 이식성과 벤더 중립을 최우선하는 팀이라면, 셀프호스트가 가능하다는 사실을 안전망 삼아 신중히 저울질해야 한다. 참고로 클라우드 배포에는 월 5달러짜리 Workers 플랜이 필요하다는 진입 조건도 기록해 둔다.
한 가지 메타 논점도 덧붙일 만하다. HN에서는 정작 이 발표를 알린 공식 블로그 글 자체가 요점을 묻어 버리고(bury the lede) AI가 쓴 듯 밋밋하다는 비판이 반복됐다. 오히려 GitHub README와 Varda의 트윗 스레드가 기술 독자에게 훨씬 명료했다는 것이다. 개방성을 코드로 증명한 회사가, 정작 그 개방성의 서사를 스스로 흐릿하게 전달했다는 아이러니다.
결론 — 이름은 과장이되 베팅은 진지하다
리드의 두 질문으로 돌아가자. 첫째, 이것은 운영체제인가. 하드웨어를 추상화하고 자원을 관리하는 고전적 의미에서는 아니다. 그 명명은 과장이고, 창시자 본인조차 사내에서 부르던 이름이 그냥 굳었다고 인정했다. 그러나 ‘AI 워크로드를 관리하는 층’이라는 두 번째 의미에서는 실체가 있다. 게이트키퍼로 접근을 관장하고, 관측을 추적해 오염을 판정하고, 아이솔레이트 위에 앱을 스케줄링하는 구조는 확실히 ‘워크로드 매니저’의 성격을 띤다. 이름값을 다투기보다, 그 아래 놓인 기술적 베팅 — Sandstorm의 미세 격리 이상을 Workers로 실현하려는 시도 — 을 보는 편이 정확하다.
둘째, ‘개방형’은 락인을 지우는가. 코드의 개방성은 진짜이며, 셀프호스트·로컬 LLM·설정 가능한 브랜딩까지 하이퍼스케일러 대안들보다 분명히 더 열려 있다. 하지만 개방성은 계약상의 락인을 지울 뿐, 생태계의 중력까지 없애지는 못한다. Workers/JS라는 실행 모델에 아키텍처를 맞추는 순간, 옮겨 갈 자유는 남되 옮겨 갈 이유는 줄어든다. 이것이 플랫폼 전쟁의 다음 국면이 그려지는 방식이다 — 다음 세대의 경쟁은 ‘누가 못 나가게 가두느냐’가 아니라 ‘누구의 중력장이 더 크냐’로 옮겨 간다.
그렇다면 실무자가 던질 질문은 하나로 모인다. 런타임 중립성을 얼마간 내주고, 비개발자도 안전하게 앱을 짜는 통제된 샌드박스를 얻는 교환이 당신의 조직에 남는 장사인가. 그 답은 회사마다 다를 것이고, 다행히 셀프호스트라는 안전망이 그 판단을 되돌릴 수 있는 여지를 남긴다. Cloudflare OS를 도입하든 말든, 이 발표가 던진 진짜 질문은 이름이 아니라 이 교환의 값이다.
출처: