안녕하세요, 주식회사 TIMEWELL의 하마모토 류타입니다.
2026년 8월 5일, Cloudflare가 Cloudflare OS를 공개했습니다. 사내에서 쓰던 AI 에이전트 기반을, 그대로 오픈소스로 내놓았다는 발표입니다1.
솔직히 쓰면, 처음 읽었을 때는 경계심이 앞섰습니다. 저희도 ZEROCK에서 비슷한 영역을 하고 있어서, 당사자로서 읽게 되기 때문입니다. 그 위에서 결론부터 말하면, 설계 사상은 빌릴 가치가 있습니다. 다만 「오픈소스이니 벤더에 묶이지 않는다」는 설명을 그대로 받으면 위험한 지점이 있습니다.
차례대로 보겠습니다.
무엇이 공개되었는가
사실부터 잡습니다.
Cloudflare OS는 공식적으로 「회사의 누구나 앱을 만들고, 업무를 자동화하고, 사내 시스템에 안전하게 접근할 수 있게 하는 오픈소스 플랫폼」으로 설명됩니다2. 이름에 「OS」가 들어가지만, Linux나 Windows 같은 의미의 OS는 아닙니다. AI 에이전트가 돌아가는 토대라는 뜻입니다.
중요한 것은, 이것이 실제로 쓰이고 있는 것이라는 점입니다. 동사는 2026년 5월에 전 직원에게 첫 버전을 제공했고, 수천 명이, 엔지니어가 아닌 직종을 포함해, 매일 쓰고 있다고 합니다. 용도는 문서와 슬라이드 작성, 반복 작업의 자동화, 사내 데이터를 다루는 작은 앱 개발입니다2.
사내에서 굴리고 나서 내놓았다는 순서는 평가할 만하다고 봅니다. 만들어서 낸 것이 아니라, 쓰고 나서 낸 것입니다.
현재는 GitHub 저장소로 공개되어 있고, 가까운 시일 안에 Cloudflare 대시보드를 통한 매니지드 제공도 예정되어 있습니다. 도입 파트너로 Presidio와 Happy Cog의 이름이 올라 있습니다1.
왜 오픈소스로 공개했는가
당사자들의 말을 봅니다. 공동창업자 겸 CEO Matthew Prince의 코멘트입니다.
We built this because nothing else did what we needed. Now any company can start from where it took us years to get.1
필요한 것이 달리 없어서 만들었다. 이제 어떤 기업이든, 우리가 몇 년에 걸쳐 도달한 지점에서 시작할 수 있다.
보도자료에서는 조금 더 踏み込은 설명도 있습니다.
organizations own what they build on it. A company's processes, context, and internal system connections don't get locked into a vendor's closed product.1
그 위에 만든 것은 조직이 소유한다. 기업의 프로세스, 맥락, 사내 시스템 연결이 벤더의 닫힌 제품에 고정되지 않는다.
그리고 모델에 대해.
Through Cloudflare AI Gateway, organizations can use any AI model provider, and they're not locked into one vendor.1
공식 블로그에서도 「Cloudflare OS는 어떤 모델과도 쓸 수 있다」고 하며, 모든 요청이 AI Gateway를 통과하는 설계입니다. 「모든 작업이 가장 비싼 모델을 필요로 하는 것은 아니다」라는 한 줄도 있고, 용도에 따라 모델을 고를 수 있다는 점이 이점으로 거론됩니다2.
즉 그들의 주장은 명확합니다. AI의 기반은 조직마다 달라야 하고, 닫힌 제품에 올리면 자사 업무가 벤더의 형태에 맞춰진다. 그래서 연다.
동사는 설계의 의도도 이렇게 적고 있습니다.
Cloudflare OS is designed so you can customize the interface, add internal Gatekeepers, and build organization-specific features without changing the core product.2
핵심을 고쳐 쓰지 않고, 조직 고유의 기능을 더할 수 있는 형태로 만들었다는 것입니다. 「Yours should reflect your organization（당신의 환경은 당신의 조직을 반영해야 한다）」라는 한 줄도 있습니다2.
가장 배울 것은 설계다
여기가 본론입니다. 사상으로서 가장 가치가 있는 것은 공개의 이유가 아니라 설계입니다. 세 가지를 듭니다.
첫째. 에이전트는 권한 제로에서 시작한다.
Cloudflare OS에서는 모든 에이전트와 앱이 접근 권한이 없는 상태에서 시작됩니다3. 무엇을 읽으려면, 명시적으로 허가된 경로를 통과해야 합니다.
이것은 이전에 쓴 테넌트 분리 이야기와 같은 구조입니다. 기본값이 닫혀 있는가, 기본값이 열려 있는가. 새 에이전트를 더했을 때, 아무도 아무것도 설정하지 않으면 그것은 아무것도 할 수 없다. 이 한 점의 설계 차이가, 오래 운영한 뒤의 결과를 가릅니다. 같은 실패의 형태는 테넌트 분리는 왜 「나중에」 무너지는가에 썼습니다.
둘째. Gatekeeper가 자격 증명을 쥐고, 에이전트에게는 넘기지 않는다.
Gatekeeper는 외부 API 앞에 두는 서비스 전용 층입니다. 역할은 이렇게 되어 있습니다3.
- OAuth 인증을 Gatekeeper 쪽에서 완결하고, 자격 증명을 보유한다
- 정책을 적용한다
- 읽기를 기록한다
GitHub를 예로 들면, 단일 저장소로만 스코프를 좁힌다, 풀 리퀘스트 승인을 필수로 한다 같은 제어를 여기서 구현합니다3.
저는 이 설계가 상당히 좋다고 생각합니다. 에이전트에게 인증 토큰을 넘겨 버리면, 그 에이전트가 무엇을 하든 막을 수 없습니다. 토큰을 쥐여 주지 않고, 행위마다 앞에서 판단한다. GlassWorm처럼 개발자 단말에서 인증 정보가 도난당하는 공격을 생각하면, 애초에 에이전트 손에 토큰이 없다는 설계의 가치는 알기 쉬울 것입니다. 관련 공격의 실례는 보이지 않는 코드가 실행된다에 썼습니다.
셋째. 읽은 것을 전부 기록하고, 그것으로 쓰기를 묶는다.
여기가 가장 독특합니다. 공식 블로그의 표현을 가져옵니다.
Cloudflare OS records every resource agents observe. These observations remain attached to the agent and its work.2
에이전트가 관측한 모든 리소스를 기록한다. 그 기록은 에이전트와 그 산출물에 묶인 채로 남는다.
그리고 이 기록이 나중에 효력을 냅니다. 다른 사람이 그 산출물을 열 때, 플랫폼은 먼저 원데이터에 대한 접근 권한을 확인합니다3. 더 나아가, 기밀 데이터를 읽은 에이전트가 특정 목적지에 쓰거나, 공동 편집자를 초대하는 것을 차단한다는 쓰임도 있습니다3.
권한이 산출물을 경유해 새는 것을 막는다는 발상입니다.
이것은 실무에서 자주 열리는 구멍입니다. 권한이 있는 사람이 AI에게 기밀 자료를 읽히고, 요약을 만들고, 권한이 없는 사람에게 공유한다. 원데이터는 지켜지는데, 요약을 통해 내용이 흘러나간다. 접근 제어를 입구에만 두면 이것은 막히지 않습니다. 읽은 것을 기록하고 출구 쪽도 묶는 것은, 결이 맞는 해법이라고 봅니다.
다만 「오픈소스 = 벤더 비종속」은 아닙니다
여기는 차분히 보는 편이 좋습니다.
공개된 구성 요소를 늘어놓습니다2.
| 요소 | 역할 |
|---|---|
| Agent Workspace | 맥락과 스킬을 가진 작업 공간 |
| Gatekeepers | 리소스 접근을 제어하는 서비스 전용 Worker |
| Dynamic Workers | 앱 서버 코드의 실행 환경 |
| Durable Object Facets | 앱의 영속 상태 관리 |
굵게 한 두 가지는 Cloudflare 고유의 실행 기반입니다. Workers도 Durable Objects도, 동사의 플랫폼 위에서만 돌아갑니다. 그리고 모델 배분은 Cloudflare AI Gateway를 통과합니다.
즉, 소스는 읽을 수 있고 고칠 수도 있지만, 돌리는 장소는 사실상 Cloudflare입니다.
이것은 비판이 아닙니다. 말이 되는 전략입니다. 핵심을 열어 채택의 문턱을 낮추고, 실행 기반으로 수익을 얻는다. 「몇 년에 걸쳐 도달한 지점에서 시작할 수 있다」는 말과 「가까운 시일 안에 매니지드 제공 예정」이라는 고지를 나란히 놓으면, 의도는 솔직하게 읽힙니다. 성실한 방식이라고 생각합니다.
다만, 받는 쪽은 말을 나누어 평가해야 합니다.
「벤더의 닫힌 제품에 고정되지 않는다」는 주장은, 모델 제공자에 관해서는 맞습니다. AI Gateway를 거치면 어떤 모델이든 쓸 수 있습니다. OpenAI에도, Anthropic에도, Grok에도 묶이지 않습니다.
한편, 실행 기반에 관해서는 고정됩니다. 모델의 의존을 벗는 대신, 플랫폼의 의존이 들어옵니다. 의존이 사라진 것이 아니라, 층이 이동한 것이 정확한 표현입니다.
이 구조는 다른 영역에서도 같은 형태로 나타납니다. 측위, 에너지, 통신까지 포함한 의존의 이야기는 준천정위성 7호기와 일본의 의존 구조에 정리했습니다. 의존 그 자체가 나쁜 것이 아니라, 어디에 의존하고 있는지를 자각하지 못하는 것이 문제라는 점은 공통입니다.
한국 기업에는 또 하나의 논점이 있습니다. 데이터의 소재지입니다. 계약서에 「데이터는 국내에 둘 것」이라고 적혀 있는 안건에서는, 실행 기반이 어느 리전에서 도는지가 기능보다 먼저 먹힙니다. 오픈소스라는 사실은 이 물음에 답해 주지 않습니다.
사상만 빌릴 것인가, 소프트웨어까지 쓸 것인가
질문의 핵심에 답합니다. 양쪽 모두 정답이 될 수 있지만, 판단 축은 분명합니다.
사상은 오늘부터 빌려야 합니다. 조건은 없습니다.
구체적으로는, 다음 세 가지를 자사 AI 활용의 설계에 넣습니다.
- 에이전트는 권한 제로에서 시작한다. 필요한 권한을 명시적으로 더하는 형태로 한다
- 자격 증명을 에이전트에게 쥐여 주지 않는다. 앞에 판단하는 층을 두고, 행위마다 허가한다
- 읽은 것을 기록하고, 그것으로 출구를 묶는다. 입구의 접근 제어만으로 끝내지 않는다
이 가운데 세 번째가 많은 조직에서 빠져 있습니다. AI에게 무엇을 읽혔는지의 기록이 없으면, 산출물을 경유한 유출을 막을 수단이 없습니다. 우선 로그를 남기는 데서 시작해도 됩니다.
소프트웨어 자체는 조건부입니다. 저는 이렇게 정리하고 있습니다.
쓸 가치가 높은 경우. 이미 Cloudflare를 주된 기반으로 쓰고 있다. 혹은 사내용 실험, 소규모 자동화부터 시작하고 싶다. 이 경우 몇 년분의 설계를 공짜로 받는 것은 큽니다. 직접 만드는 것보다 빠르고, 게다가 실운용이 된 설계입니다.
신중히 봐야 하는 경우. 데이터 소재지에 계약상 제약이 있다. 기존의 클라우드 기반이 따로 있고, 그쪽으로 모아 두고 있다. 이 경우 핵심을 채택하면 실행 기반째 옮기게 됩니다. 부분적으로 가져오더라도, Workers와 Durable Objects에 의존하지 않는 부분이 어디까지인지를 먼저 확인할 필요가 있습니다.
그리고 어느 쪽이든, 읽을 가치는 있습니다. Apache 계열 라이선스로 공개된 실운용의 기반은, 그 자체로 좋은 설계 자료입니다1. 채택하지 않기로 한 경우에도, Gatekeeper의 입도나 관측 로그의 들고 있는 방식만 읽어도 자사 설계는 좋아집니다.
당사가 ZEROCK을 일본 국내 AWS 서버에서 운용하고, 누가 어떤 지식에 닿을 수 있는지를 통제하는 것도, 다루는 문제는 같습니다. 에이전트에게 무엇을 읽히고, 그 결과를 누구에게 넘기는가. 이 물음에 답하는 장치를 제품 안쪽에 갖고 있고 싶기 때문입니다.
공개된 것은 사상인가, 제품인가
정리합니다.
2026년 8월 5일, Cloudflare가 Cloudflare OS를 공개했습니다. 사내에서 2026년 5월부터 수천 명이 일상적으로 쓰던 것을, 그대로 내놓은 형태입니다. 설계의 요점은 권한 제로에서 시작하는 에이전트, 자격 증명을 쥐고 읽기를 기록하는 Gatekeeper, 그리고 에이전트가 관측한 모든 것을 기록하고 그것으로 쓰기 대상과 공유 대상을 묶는 관측 로그.
오픈소스화의 이유로 동사가 드는 것은, 기업의 프로세스와 사내 시스템 연결이 벤더의 닫힌 제품에 고정되지 않는다는 것, 그리고 AI Gateway를 통해 어떤 모델 제공자도 쓸 수 있다는 것입니다.
다만 실행 기반은 Cloudflare Workers와 Durable Objects에 의존합니다. 모델의 의존은 벗겨지지만, 플랫폼의 의존은 들어옵니다. 「오픈소스이니 자유롭다」가 아니라, 어느 층의 자유를 얻고, 어느 층의 의존을 받아들일 것인가라는 거래로 보는 것이 정확합니다.
제 답은, 사상은 전부 빌리고, 소프트웨어는 조건에 따른다입니다.
그리고 마지막으로 하나. 이번 공개에서 가장 무거운 것은 코드가 아니라 「쓰고 나서 내놓았다」는 사실이라고 생각합니다. 수천 명이 매일 쓰고, 공유 시의 권한 추적에서 넘어졌던 경험을 거쳐, 관측 로그라는 해법에 닿아 있습니다3. 설계는 운용의 실패에서만 나옵니다. 그 실패의 양만큼, 읽을 가치가 있습니다.
사내 지식을 AI에 맡길 때의 설계를 구체적으로 상의하고 싶은 분은, ZEROCK의 생각이 참고가 될 수 있습니다. 개별 상담은 여기로 연락 주십시오.
Footnotes
-
Cloudflare 보도자료 「Cloudflare OS Is the First AI Workspace Built Around How Companies Actually Work」（2026년 8월 5일）. 공동창업자 겸 CEO Matthew Prince의 코멘트 「We built this because nothing else did what we needed. Now any company can start from where it took us years to get.」, 「organizations own what they build on it. A company's processes, context, and internal system connections don't get locked into a vendor's closed product.」, 「Through Cloudflare AI Gateway, organizations can use any AI model provider, and they're not locked into one vendor.」, 현재 오픈소스 저장소로 이용 가능하며 Cloudflare 대시보드를 통한 매니지드 제공이 예정되어 있다는 점, 도입 파트너로 Presidio 및 Happy Cog가 거론된 점은 모두 동 자료에 의한다. 공개 저장소는 https://github.com/cloudflare/cloudflare-os . https://www.cloudflare.com/press/press-releases/2026/cloudflare-os-is-the-first-ai-workspace-built-around-how-companies-actually-work/ ／ 보도에서는 Apache 2.0 라이선스로 전한다. https://siliconangle.com/2026/08/05/cloudflare-launches-cloudflare-os-open-source-ai-agentic-workspace-enterprise/ ↩ ↩2 ↩3 ↩4 ↩5 ↩6
-
Cloudflare 공식 블로그 「Cloudflare OS: an open platform for agents, apps, and work」（2026년 8월 5일）. Cloudflare OS의 정의 「an open-source platform that lets everyone in your company build apps, automate work, and safely access internal systems」, 2026년 5월에 전 직원에게 첫 버전을 제공하고 수천 명이 매일 이용하고 있다는 점（문서와 슬라이드 작성, 반복 작업 자동화, 작은 앱 개발）, 구성 요소（Agent Workspace, Gatekeepers, Dynamic Workers, Durable Object Facets）, 「Cloudflare OS records every resource agents observe. These observations remain attached to the agent and its work.」, 「Cloudflare OS can be used with any model.」 및 모든 요청이 AI Gateway를 통과한다는 점, 「Not every task needs the most expensive model」, 「Cloudflare OS is designed so you can customize the interface, add internal Gatekeepers, and build organization-specific features without changing the core product.」, 「Yours should reflect your organization.」는 모두 동 블로그에 의한다. https://blog.cloudflare.com/cloudflare-os/ ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7
-
Cloudflare OS의 거버넌스 장치에 관한 보도. Cloudflare OS 안의 모든 에이전트와 애플리케이션이 접근 권한이 없는 상태에서 시작한다는 점, Gatekeeper가 외부 API 앞에 두는 서비스 전용 Worker로서 OAuth 인증을 완결하고 자격 증명을 보유하며 정책을 적용하고 읽기를 기록한다는 점, GitHub의 경우 단일 저장소로의 스코프 제한이나 풀 리퀘스트 승인 요구를 구현할 수 있다는 점, 에이전트가 읽은 리소스의 기록이 에이전트와 생성물 양쪽에 부여되고 다른 인물이 산출물을 열 때 플랫폼이 기초 데이터에의 접근 권한을 먼저 확인한다는 점, 관측 로그가 기밀 데이터를 읽은 에이전트의 특정 목적지로의 쓰기나 공동 편집자 초대를 차단하는 용도로 기능한다는 점, 그리고 사내에서 워크스페이스 공유 시 권한 추적의 과제가 생겼던 경위는 모두 동 기사에 의한다. https://www.helpnetsecurity.com/2026/08/06/cloudflare-os-open-source/ ↩ ↩2 ↩3 ↩4 ↩5 ↩6
