Cloudflare Computer, Isolate와 Container 전반에 걸쳐 에이전트 컴퓨터를 분리하다

Cloudflare는 2026년 8월 3일 Cloudflare Computer를 오픈소스 프리뷰로 출시했다. 이 도구는 세 가지 실행 백엔드 전반에서 에이전트에 하나의 지속 가능한 워크스페이스를 제공한다. 충돌 지점은 바로 이 설계 안에 있다. 개발자는 가벼운 Workers isolate로 단순 작업을 처리하고 더 무거운 작업에는 Linux container를 배정할 수 있지만, 이 프로젝트는 명시적으로 프로덕션 준비가 되지 않은 상태다.

이 구분이 중요한 이유는 에이전트 인프라가 완전하고 격리된 머신을 향해 발전해 왔기 때문이다. Cloudflare Computer는 다른 가정을 시험한다. 에이전트에는 컴퓨터의 기능이 필요하지만, 모든 작업이 동일한 컴퓨터 런타임을 필요로 하지는 않는다. 각 명령을 실행하는 환경과 별개로 파일을 지속할 수 있다.

이러한 결과는 sandbox, container 또는 microVM을 에이전트 세션의 기본 단위로 취급하는 공급업체에 압박을 가한다. 또한 개발자가 언제 전용 container가 필요한지 기존 Cloudflare Sandbox SDK가 정당화해야 하는 과제를 던진다. 이 프리뷰는 완성된 제품이라기보다 에이전트 컴퓨팅을 어떻게 분할해야 하는지에 관한 공개적인 주장에 가깝다.

Cloudflare Computer는 파일과 실행을 분리한다

핵심 변화는 아키텍처에 있다. 에이전트의 워크스페이스는 더 이상 하나의 실행 중인 container에 속하지 않는다.

프로젝트의 오픈소스 저장소에 따르면, Cloudflare Computer는 권위 있는 가상 파일시스템을 Durable Object 안에 저장한다. Durable Object는 비공개 영구 스토리지와 단일 조정 지점을 갖춘 상태 유지형 Cloudflare 구성요소다.

이 파일시스템 상태는 SQLite가 보관한다. 실행은 workspace.runtime이라는 공통 인터페이스를 통해 다른 곳에서 이루어진다. 서로 다른 백엔드가 명령을 수행하더라도 에이전트는 동일한 파일을 읽고 수정할 수 있다.

프리뷰에는 세 가지 백엔드가 포함된다. container 백엔드는 실제 바이너리, 패키지 관리자, 네트워크 액세스를 갖춘 완전한 Linux 사용자 공간을 제공한다. Worker shell 백엔드는 Dynamic Worker 내부에서 just-bash를 통해 shell과 유사한 명령을 실행한다. 세 번째 백엔드는 새로운 Dynamic Workers 안에서 JavaScript 모듈을 평가한다.

개발자는 하나의 워크스페이스에 둘 이상의 백엔드를 등록할 수 있다. 각 백엔드는 안정적인 식별자를 받으며, workspace.runtime.exec()는 공통 진입점이 된다. 호출자는 백엔드를 직접 선택할 수 있고, 에이전트 프레임워크는 개발자가 제공한 설명을 바탕으로 선택할 수 있다.

이 구조는 파일시스템을 세션의 안정적인 중심으로 바꾼다. 컴퓨팅은 교체 가능해진다. 가벼운 명령은 isolate에서 실행할 수 있고, 패키지 설치나 네이티브 빌드는 별도의 논리적 워크스페이스를 만들지 않고 Linux로 옮길 수 있다.

Cloudflare는 이 패키지를 플러그형 실행 기능을 갖춘 영구적인 SQLite 기반 가상 파일시스템이라고 설명한다. 패키지 문서는 워크스페이스당 약 10 GB 제한을 설명한다. 스토리지는 Durable Object의 제한을 공유한다.

이 패키지는 실행 백엔드 없이도 작동한다. 애플리케이션은 지속 가능한 파일시스템만 사용하다가 워크플로에 실행이 필요해질 때 이를 추가할 수 있다. 이는 스토리지 모델이 sandbox를 보조하는 기능 이상임을 의미한다.

공개 API는 익숙한 Node.js 파일시스템 작업과 닮아 있다. 파일 읽기, 쓰기, 나열, 제거, 검색 기능을 포함한다. 문자열은 기본적으로 UTF-8을 사용하며, 바이너리 데이터는 바이트 배열이나 스트림으로 이동할 수 있다.

container 액세스에는 별도 계층이 필요하다. computerd라는 daemon이 sandbox 내부에서 실행되며, 지속 가능한 워크스페이스를 FUSE mount로 노출한다. FUSE는 사용자 공간 프로세스가 일반 파일시스템 인터페이스를 통해 파일을 제공하도록 한다.

이 daemon은 RPC 채널을 통해 권위 있는 Durable Object와 변경 사항을 동기화한다. 이로써 Linux 도구에는 일반적인 디렉터리를 제공하면서도 SQLite는 container 외부에 진실의 원천으로 유지된다.

isolate 백엔드는 더 짧은 경로를 택한다. 파일시스템 작업이 Workers RPC를 통해 동일한 Durable Object를 호출하므로 두 번째 저장소를 유지할 필요가 없다. 또한 container 작업 뒤에 필요한 동기화 단계도 피할 수 있다.

이것이 이번 발표를 또 하나의 코드 실행 서비스 이상으로 만드는 요소다. Cloudflare Computer는 익숙한 컴퓨터를 지속 가능한 파일, 선택 가능한 실행, 동기화, 배포 도우미로 분해한다. 기본 인프라는 명령마다 바뀔 수 있지만 에이전트는 여전히 하나의 워크스페이스를 본다.

에이전트가 더 이상 하나의 런타임에 맞지 않는 이유

에이전트 워크로드는 작은 파일 작업과 간헐적인 시스템 수준 작업을 섞어 수행하므로, 하나의 고정 실행 환경은 비효율적인 기본값이 된다.

코딩 에이전트는 거의 균일한 하나의 작업만 수행하지 않는다. 구성 파일을 살펴보고, 저장소를 검색하고, 여러 줄을 수정하고, 테스트를 실행하고, 의존성을 설치하고, 이미지를 만들고, 아티팩트를 배포할 수 있다. 이러한 작업은 서로 다른 런타임 요구사항을 가진다.

파일을 읽는 데 완전한 Linux container는 필요하지 않다. 텍스트를 파싱하거나 통제된 JavaScript 모듈을 평가하는 작업도 마찬가지다. 반면 네이티브 컴파일, 패키지 설치, 운영체제 도구는 대체로 필요하다.

기존 원격 sandbox는 이러한 요구를 하나로 묶는다. sandbox는 하나의 환경 안에서 파일시스템, shell, 프로세스, 네트워크 액세스를 제공한다. 이 모델은 이해하기 쉽지만, 지속성과 실행을 같은 수명 주기에 묶는다.

Cloudflare의 이전 Sandbox SDK도 이러한 모델을 상당 부분 따른다. 이 회사는 처음으로 command 및 파일시스템 환경을 선보인 지 9개월 후인 2026년 4월 13일 Sandboxes를 정식 출시했다.

정식 출시 시점에 각 Sandbox는 터미널, 백그라운드 프로세스, 파일 감시, 라이브 프리뷰 URL, egress 제어, 스냅샷을 갖춘 개발 환경이 됐다. Cloudflare는 표준 계정이 동시에 15,000개의 lite 인스턴스, 6,000개의 basic 인스턴스, 1,000개 이상의 대형 인스턴스를 실행할 수 있다고 밝혔다.

회사는 Sandboxes의 과금 방식도 활성 CPU 기준으로 전환해 유휴 대기 시간이 유료 CPU 시간을 소모하지 않도록 했다. 이 변화는 장기 실행 에이전트 세션의 비용 하나를 해결했다. 하지만 container를 시작하는 것과 가벼운 isolate에서 코드를 실행하는 것 사이의 아키텍처 차이를 없애지는 못했다.

Cloudflare Computer는 이 차이를 라우팅 결정으로 바꾼다. 백엔드는 지연 연결되므로 작업이 처음 도달할 때 초기화된다. 워크플로는 파일과 isolate로 시작한 뒤, 명령이 실제로 필요로 할 때만 Linux를 사용할 수 있다.

이 전략은 에이전트 워크로드에 여러 컴퓨팅 규모가 필요하다는 Cloudflare의 광범위한 입장을 반영한다. Agents Week 회고에서는 일부 에이전트에 완전한 운영체제가 필요하지만, 대부분의 작업에는 밀리초 단위로 시작하는 더 가벼운 환경이 필요하다고 주장했다.

Cloudflare Computer는 이 주장을 구체적인 프로그래밍 모델로 제시한다. 개발자에게 관련 없는 서비스 사이에서 파일을 수동으로 옮기라고 요구하지 않는다. 실행 경계가 바뀌어도 워크스페이스가 연속성을 제공한다.

프레임워크 작성자에게 이러한 연속성은 중요하다. 에이전트는 read, write, edit, ls, exec라는 표준 도구를 받을 수 있다. 이 패키지는 AI SDK 애플리케이션용 adapter를 제공하며, 개발자는 각 백엔드가 처리할 수 있는 작업을 설명한다.

그런 다음 모델은 빠른 텍스트 작업을 isolate로 보내고 무거운 명령은 container로 보낼 수 있다. 이는 백엔드 선택을 에이전트의 도구 정책 일부로 만든다. 동시에 설명이 불명확하거나 모델이 잘못 선택할 경우 새로운 장애 요인도 만들어낸다.

이 설계는 자주 멈추는 에이전트에 특히 적합하다. 모델 추론, 인간 승인, 네트워크 요청, 외부 API 호출은 유휴 공백을 만든다. 모든 공백 동안 완전한 환경을 활성 상태로 유지하면 편리할 수는 있지만, 에이전트의 작업을 보존하는 유일한 방식은 아니다.

지속 가능한 파일시스템은 세션 상태를 지우지 않고도 실행 계층을 사라지게 할 수 있다. 다음 작업은 다른 백엔드를 통해 같은 파일을 다시 열 수 있다. 하나의 머신이 전체 세션을 소유하지 않더라도 에이전트 관점에서는 컴퓨터와 유사하다.

이 추상화는 container 우선 공급업체에 압박을 가하지만, 이들의 가장 강력한 주장을 없애지는 않는다. 완전하게 격리된 환경은 예측 가능한 도구, 익숙한 디버깅, 일관된 보안 경계를 제공한다. 세션을 여러 런타임으로 분리하면 조정과 동기화 문제가 더해진다.

Cloudflare의 제품 경계에도 압박을 가한다. 개발자는 Sandbox SDK, Cloudflare Computer, Dynamic Workers 또는 이들의 조합이 필요한지 이해해야 한다. 프리뷰 패키지는 중복 영역을 탐색할 수 있지만, 프로덕션 플랫폼은 결국 단순한 답을 제공해야 한다.

유력한 답은 워크로드에 따라 달라진다는 것이다. Cloudflare Computer는 작은 작업을 많이 수행하고 가끔 Linux가 필요한 에이전트에 유리하다. 거의 모든 단계가 네이티브 도구, 광범위한 로컬 의존성 또는 높은 처리량의 디스크 액세스에 의존할 때는 container가 더 명확한 선택으로 남는다.

이것이 진정한 핵심 질문이다. 이 프리뷰는 개발자가 프로비저닝해야 할 단위가 머신인지, 아니면 서로 다른 머신을 빌릴 수 있는 워크스페이스인지 묻는다.

Cloudflare Computer가 하나의 워크스페이스를 세 가지 백엔드에 걸쳐 라우팅하는 방식

Cloudflare Computer는 런타임 선택을 명시적으로 만들어 유연성을 얻지만, 각 백엔드는 서로 다른 기능과 동기화 특성을 지닌다.

Worker shell 백엔드는 익숙한 명령을 위한 가장 가벼운 경로다. 운영체제 프로세스를 생성하지 않고 실행하도록 설계된 Bash 유사 환경의 TypeScript 구현체인 just-bash를 사용한다.

이 백엔드는 지속 가능한 워크스페이스를 대상으로 텍스트 중심 shell 작업을 처리할 수 있다. Docker나 Cloudflare Container가 필요하지 않다. 파일 작업은 Durable Object로 돌아가므로 권위 있는 상태가 한곳에 유지된다.

Worker JavaScript 백엔드는 shell 명령 대신 ECMAScript 모듈을 처리한다. 각 실행은 새로운 Dynamic Worker 안에서 수행되며 구조화된 입력을 받거나 구조화된 결과를 반환할 수 있다. 워크스페이스 기반 파일 액세스와 구성된 라이브러리를 지원한다.

Cloudflare는 Git 및 Cloudflare Artifacts용 신뢰할 수 있는 모듈도 제공한다. Git 작업은 가상 파일시스템을 직접 대상으로 isomorphic-git 클라이언트를 통해 실행할 수 있다. container나 일반적인 Git 바이너리가 필요하지 않다.

container 백엔드는 isolate가 처리할 수 없는 작업을 담당한다. Linux, 네이티브 바이너리, Node.js, npm, 네트워킹 및 기타 운영체제 기능을 제공한다. 워크스페이스는 computerd FUSE mount를 통해 그 안에 나타난다.

이 백엔드는 가장 어려운 데이터 문제를 만든다. Cloudflare는 SQLite 기반 상태를 container 안에 투영하고, 일반 도구가 이를 수정하도록 허용한 다음, 그 변경 사항을 이후에 동기화해야 한다. 이 패키지는 등록된 각 백엔드에 대해 독립적인 동기화 cursor를 유지한다.

명령이 성공했지만 명령 이후 pull이 실패하면 실행 결과는 보류 중인 동기화 상태를 보고할 수 있다. 애플리케이션은 제한된 지수 백오프를 사용해 재시도를 구성할 수 있다. 다만 라이브러리는 Durable Object의 alarm 스케줄링을 직접 관리하지 않는다.

이 세부 사항은 여전히 얼마나 많은 책임이 개발자에게 남아 있는지를 보여준다. 사용자는 하나의 워크스페이스를 보지만, 애플리케이션은 백엔드 등록, 재시도 스케줄링, 실행 수명 주기, 해결되지 않은 동기화를 처리해야 한다.

이 설계는 자원 해제에도 엄격한 관리가 필요하다. RPC 계층은 원격 stub을 자동으로 수집하지 않는다. 워크스페이스나 실행 handle을 반복적으로 획득하는 장기 세션은 애플리케이션이 각 handle을 해제하지 않으면 이를 누적할 수 있다.

Cloudflare는 그러한 유출을 탐지하기 위한 디버깅 지원을 문서화하고 있다. 다만 이는 프리뷰 단계의 인프라이며, 보이지 않는 플랫폼 서비스가 아니다. 이를 실험하는 개발자는 내부 작동 방식을 이해해야 한다.

파일 게시 기능은 또 다른 경계를 도입한다. 이 패키지는 워크스페이스 파일을 R2에 업로드하고 사전 서명된 링크를 반환할 수 있다. 또한 세션을 코드 및 빌드 결과물을 위한 Git 호환 스토리지 서비스인 Cloudflare Artifacts에 연결할 수도 있다.

포함된 튜토리얼 중 하나는 의도된 역할 분담을 보여준다. 에이전트가 워크스페이스에 Markdown 레시피 카드를 작성한 뒤, 컨테이너 내부에서 pandoc를 사용해 PDF를 만든다. 스토리지는 내구성을 유지하고, Linux 도구가 형식 변환을 처리한다.

또 다른 예제는 이미지 생성을 Workers AI로 보내고, 결과를 워크스페이스에 기록한 뒤 공유 가능한 자산으로 반환한다. 비교 인터페이스는 동일한 작업을 컨테이너 런타임과 Worker 런타임에서 나란히 실행한다.

이러한 예제는 더 폭넓은 에이전트 패턴을 가리킨다. 워크스페이스는 공유 작업대가 되고, 서로 다른 런타임은 전문 도구처럼 작동한다. 에이전트는 모든 백엔드를 각각 별도의 컴퓨터로 취급할 필요가 없다.

이 메커니즘은 지식 집약적인 개발도 지원할 수 있다. 엔지니어링 팀은 작업 파일, 생성된 보고서, 테스트 결과를 워크스페이스에 보관한 다음, 내구성이 필요한 결과물을 검색 가능한 지식 베이스로 복사할 수 있다. 런타임은 일시적이지만, 유용한 작업은 에이전트 세션을 넘어 접근할 수 있게 된다.

그러나 이 추상화에는 한계가 있다. 컨테이너 측 파일 시스템은 메모리에 유지되며, Cloudflare는 전체 모노레포가 아닌 에이전트 규모의 워크스페이스를 권장한다. 약 10 GB의 상한은 문서와 소규모 프로젝트에는 상당하지만, 이 서비스를 개발 디스크의 범용 대체재로 만들지는 않는다.

Worker 백엔드 역시 실험적 Cloudflare 기능과 Worker Loader 바인딩을 요구한다. 패키지 자체에는 nodejs_compat 호환성 플래그가 필요하다. 이러한 요구 사항은 프리뷰 상태를 더욱 분명히 한다.

이 Cloudflare Computer 분석에서 가장 중요한 요점은 isolate가 컨테이너를 대체한다는 것이 아니다. 그렇지 않다. 이 메커니즘은 애플리케이션이 컨테이너의 시작 시간, 기능, 동기화 비용을 감수할 가치가 있는 시점을 결정할 수 있게 한다.

그 선택은 애플리케이션 계층에서 이루어질 수도 있고 에이전트 프레임워크를 통해 이루어질 수도 있다. 모델은 백엔드 설명을 보고 대상 위치를 선택할 수 있다. 따라서 개발자에게는 자연어 힌트뿐 아니라 정책 제어가 필요하다.

프로덕션 시스템은 각 백엔드가 접근할 수 있는 명령, 파일, 네트워크, 자격 증명을 제한할 가능성이 높다. 또한 특정 명령이 왜 특정 런타임으로 전달됐는지 보여 주는 신뢰할 수 있는 기록도 필요하다. 현재 리포지토리는 관측성 훅을 제공하지만, 전체 거버넌스 문제를 해결하지는 않는다.

Cloudflare Computer는 작업이 자연스럽게 분할될 때 가장 설득력 있다. isolate에서 검색과 편집을 하고, Linux에서 컴파일한 뒤, 아티팩트 서비스를 통해 게시하는 방식이다. 모든 작업에 컨테이너가 필요하거나 작업이 대용량 파일을 반복적으로 옮겨야 할 때는 그 이점이 덜 분명해진다.

프리뷰 경고와 벤치마크가 제안의 매력을 복잡하게 만든다

리포지토리는 명시적인 프로덕션 경고와 대규모 순차 파일 작업에서 큰 불이익을 보여 주는 벤치마크를 포함해, 이례적으로 직접적인 한계를 제시한다.

Cloudflare는 이 패키지가 실험, 탐색, 프로토타입에 적합하다고 말한다. API는 불안정하고 설계가 변경될 수 있으며, 패키지는 프로덕션 사용에 적합하지 않다고도 밝힌다.

이 경고는 오늘날 Cloudflare Computer가 무엇인지에 대한 모든 주장의 기준이 되어야 한다. 리포지토리에는 작동하는 패키지, 예제, 수백 건의 커밋이 있지만, 설계 문서 일부는 미래 지향적이다. Cloudflare는 독자에게 해당 사양을 현재 코드의 설명이 아니라 의도로 받아들이라고 안내한다.

성능은 가장 명확한 트레이드오프다. 회사는 가상 CPU 하나, 6 GiB 메모리, 12 GB 디스크를 갖춘 표준 컨테이너에서 computerd를 벤치마크했다. FUSE 워크스페이스를 메모리 내 파일 시스템 및 컨테이너의 ext4 디스크와 비교했다.

결과는 메타데이터 비중이 큰 여러 작업에서 가상 파일 시스템에 유리하다. 파일 1,000개를 삭제하는 데 ext4 시간의 약 3분의 2가 걸렸다. 중첩 디렉터리 트리 생성에는 약 4분의 3이 걸렸다. 해당 트리를 찾는 작업도 약 4분의 3이 걸렸다.

100개 파일을 포함한 Git 초기화 및 커밋은 computerd에서 459.2밀리초가 걸렸고, ext4에서는 635.4밀리초가 걸렸다. 약 1 MB 리포지토리의 얕은 클론은 549.1밀리초가 걸렸으며, 디스크에서는 576.2밀리초였다.

대규모 순차 작업에서는 반대 결과가 나왔다. 64 MiB 파일을 쓰는 데 computerd는 230.6밀리초가 걸린 반면 ext4는 16.8밀리초였다. 같은 용량을 복사하는 데는 1,037.2밀리초가 걸렸고, ext4에서는 39.8밀리초였다.

순수한 64 MiB 읽기는 디스크 기준선보다 약 30배 느렸다. 순수 복사는 41배 이상 느렸다. 이러한 격차는 아카이브, 의존성 트리, 미디어, 모델 파일, 데이터 처리 워크로드에서 중요하다.

Cloudflare의 파일 시스템 벤치마크는 속도 저하의 배경 메커니즘을 설명한다. 쓰기 경로는 512 KiB 청크를 콘텐츠 주소 지정 blob 스토어에 해싱한다. 이는 중복 제거와 변경된 청크만 동기화하는 기능을 지원하지만, 원시 처리량 작업에 추가 작업을 더한다.

Cloudflare의 Sandbox SDK를 완전히 설치한 테스트는 비용을 더 구체적으로 보여 줬다. 이 테스트는 854개 패키지와 36,675개 파일을 포함했다. 설치에는 FUSE 워크스페이스에서 124.7초, ext4에서 63.9초, 메모리에서는 34.3초가 걸렸다.

Cloudflare는 ext4를 더 현실적인 범용 사용 기준선으로 규정한다. 그 기준선과 비교하면 FUSE 설치는 약 두 배 오래 걸렸다. 의존성이 많은 JavaScript 프로젝트를 구축하는 개발자는 이 차이를 체감할 것이다.

이 벤치마크가 설계를 무효화하는 것은 아니다. 많은 에이전트 작업은 지속적인 순차 I/O보다는 메타데이터, 소규모 편집, 검색, 점진적 변경을 포함한다. 대신 결과는 백엔드 라우팅이 중요한 지점을 정의한다.

합리적인 워크플로는 소스 파일을 영속 워크스페이스에 유지하면서 대용량 아카이브의 반복적 압축 해제는 피할 수 있다. 의존성을 다른 곳에 캐시하거나 동기화 오버헤드보다 가치가 큰 작업을 선택할 수도 있다. Cloudflare는 아직 최선의 프로덕션 패턴을 확립하지 않았다.

보안은 두 번째 불확실성을 제시한다. 리포지토리는 실행 표면과 스토리지 동작을 설명하지만, 세 백엔드 모두 동일한 격리를 제공한다고 주장하지는 않는다. JavaScript isolate, TypeScript로 구현된 셸, Linux 컨테이너는 근본적으로 서로 다른 실행 환경이다.

Worker 셸은 완전한 운영체제가 아니기 때문에 부분적으로 속도 이점을 얻는다. 이는 호환성을 제한하지만, 명령이 수행할 수 있는 작업의 범위도 좁힐 수 있다. 컨테이너는 더 폭넓은 기능을 제공하므로 네트워크 접근, 패키지, 자격 증명에 대한 더 강력한 통제가 필요하다.

이러한 환경 간 이동은 정책 공백을 만들 수 있다. 한 백엔드에서 거부된 명령이 다른 백엔드에서는 실행될 수 있다. 작업에 필요하지 않은 경우에도 에이전트는 더 큰 기능을 약속하는 설명 때문에 Linux를 선택할 수 있다.

패키지에는 워크스페이스 연결, 동기화, 실행, 파일 시스템 작업을 위한 observer 훅이 포함된다. 이 훅은 Cloudflare tracing 또는 다른 기록기로 데이터를 공급할 수 있다. 유용한 기반이지만, 프로덕션 사용자는 권한 부여 규칙과 감사 가능한 백엔드 선택 정책이 필요하다.

영속성은 그 자체의 보안 문제를 낳는다. 파일은 Durable Object 재시작 후에도 살아남으며, 이는 장기 작업을 수행하는 에이전트에 필요한 기능이다. 영속 워크스페이스는 민감한 프롬프트, 소스 코드, 생성된 자격 증명, 다운로드 데이터도 의도보다 오래 보존할 수 있다.

애플리케이션에는 위험 수준에 맞는 삭제 정책과 테넌트 분리가 필요하다. 읽기 전용 R2 마운트는 참조 데이터 보호에 도움이 되지만, 데이터 보존이나 외부 접근에 관한 모든 질문에 답하지는 않는다.

GitHub 반응은 프로덕션 증거가 아니라 도입 신호를 제공한다. 리포지토리는 8월 6일 기준 약 3,100개의 스타와 141개의 포크를 표시했다. 이 수치는 특히 GitHub Trending에서의 위치를 감안할 때, 발표 후 개발자들의 호기심을 보여 준다.

이는 신뢰성, 보안, 지속적 사용을 입증하지는 않는다. 매력적인 아키텍처를 둘러싸고 스타는 빠르게 쌓일 수 있다. 진정한 검증은 몇 주간 실행되고, 부분 실패에서 복구하며, 런타임 변경 전반에 걸쳐 파일을 일관되게 보존하는 워크로드에서 나올 것이다.

Cloudflare의 투명성은 여기서 도움이 된다. 불리한 I/O 수치를 공개하면 개발자는 실험을 위한 더 나은 근거를 얻는다. 명시적인 경고는 Trending 순위가 일반 가용성 출시로 오해되는 것도 막는다.

신중한 결론은 명확하다. Cloudflare Computer는 에이전트 상태와 실행을 분리하는 신뢰할 만한 메커니즘을 제공하지만, 이 프리뷰는 추가 조정 비용이 프로덕션에서 전용 샌드박스보다 낫다는 점을 아직 증명하지 못했다.

GitHub 급증 이후 개발자가 주시해야 할 점

다음 단계는 세 가지 신호에 달려 있다. API 안정화, 실제 워크로드 증거, 그리고 백엔드 선택을 위한 강제 가능한 정책이다.

첫 번째 신호는 버전이 관리되는 프로덕션 지향 릴리스다. Cloudflare Computer는 현재 불안정한 API와 실험적 백엔드 요구 사항을 제시한다. 안정적인 인터페이스로의 전환은 Cloudflare가 Computer, Sandbox SDK, Dynamic Workers, Durable Objects 간 소유권 경계를 해결했음을 보여 줄 것이다.

이 릴리스는 복구 동작을 명확히 해야 한다. 개발자에게는 컨테이너 명령이 완료됐지만 동기화가 실패할 때 예측 가능한 결과가 필요하다. 또한 동시 접근, 정리, 스토리지 한도, 장기 실행 RPC 세션에 대한 보장도 필요하다.

Cloudflare가 마이그레이션 지침을 포함한 안정적 릴리스를 공개한다면 아키텍처적 주장은 더 강해진다. API가 계속 바뀌거나 패키지가 실험 단계에 머문다면 팀들은 이 리포지토리를 계속 설계 연구로 취급할 것이다.

두 번째 신호는 완전한 에이전트 워크로드의 증거다. 마이크로벤치마크는 이미 FUSE가 잘 수행하는 영역과 어려움을 겪는 영역을 보여 준다. 더 어려운 질문은 isolate와 컨테이너 간 명령 라우팅이 전체 작업 시간, 신뢰성, 리소스 사용을 개선하는지 여부다.

유용한 평가는 동일한 코딩, 리서치, 데이터 분석 에이전트를 비교할 것이다. 시작 지연, 실행 시간, 동기화 실패, 전송된 스토리지 양, 성공적인 작업 완료를 측정해야 한다. 원시 파일 시스템 벤치마크만으로는 이러한 복합 효과를 포착할 수 없다.

리포지토리의 예제는 출발점이며, 특히 동일 작업에서 런타임을 비교하는 인터페이스가 그렇다. 독립적인 테스트는 더 큰 리포지토리, 반복적인 패키지 설치, 병렬 에이전트, 중단 후 재개되는 세션을 추가해야 한다.

혼합 런타임 워크플로가 더 적은 컨테이너를 호출하면서도 안정적으로 완료된다면 Cloudflare의 메커니즘은 지지를 얻는다. 동기화와 라우팅이 그 절감 효과를 지워 버린다면 영속 샌드박스가 더 단순한 선택으로 남는다.

세 번째 신호는 백엔드 정책이다. 오늘날 애플리케이션은 사용 가능한 백엔드를 설명하고 에이전트가 하나를 선택하도록 할 수 있다. 프로덕션 구매자는 어떤 백엔드가 각 파일, 네트워크, 시크릿, 명령에 접근할 수 있는지 관리하는 결정론적 제어를 원할 것이다.

Cloudflare는 이미 관련 인프라를 갖추고 있다. Sandbox 플랫폼에는 프로그래밍 가능한 아웃바운드 제어가 포함되고, Durable Objects는 비공개 영속 상태를 제공한다. Cloudflare Computer는 개발자가 이해하고 추론할 수 있는 정책 모델로 이러한 요소를 결합해야 한다.

성숙한 구현은 권한 상승을 가시화해야 한다. 에이전트가 Worker 셸에서 Linux로 이동할 때 애플리케이션은 그 이유, 새로 제공된 기능, 그리고 경계를 넘은 데이터를 알아야 한다.

이 질문은 Cloudflare를 넘어선다. LangChain, Daytona, Ona, Modal 등 다른 플랫폼들도 microVM, 컨테이너, 영속성, 개발자 도구를 서로 다르게 조합한 에이전트 환경을 추구하고 있다. 이들의 경쟁은 단순한 실행 속도가 아니라 에이전트 컴퓨터의 정의를 둘러싼 경쟁이다.

일부 제공업체는 신뢰할 수 없는 에이전트 코드에는 하드웨어 수준의 격리와 완전한 머신 경계가 필요하다고 주장한다. 반면 Cloudflare Computer는 분해에 초점을 맞추며, 워크스페이스가 Linux가 필요해질 때까지는 더 가벼운 실행 환경을 사용하도록 한다. 격리 요구 수준은 작업에 따라 달라지므로, 이 두 접근법은 공존할 수 있다.

엔터프라이즈 코딩 에이전트는 재현 가능한 도구 체인과 엄격한 테넌트 경계를 갖춘 전용 환경을 여전히 선호할 수 있다. 대량의 문서를 처리하는 에이전트는 내구성 있는 파일과 가벼운 명령 환경에서 더 큰 이점을 얻을 수 있다. 대규모 입력을 다루는 데이터 에이전트는 FUSE 설계의 처리량 한계를 드러낼 수 있다.

따라서 개발자는 이 개념을 도입하기 전에 자신의 작업 구성을 검증해야 한다. 실제로 네이티브 바이너리가 필요한 단계가 얼마나 되는지 세어야 한다. 워크스페이스를 통해 이동하는 데이터의 양을 측정해야 한다. 동기화 실패를 의도적으로 발생시키고 복구가 정상적으로 이뤄지는지 확인해야 한다.

또한 매력적인 에이전트 경험과 충분한 보안 설계를 구분해야 한다. “하나의 워크스페이스”는 유용한 인터페이스이지만, 모든 실행 경로가 동일한 신뢰 경계를 가진다는 뜻은 아니다. 런타임 승격은 권한 승격과 동일한 수준의 면밀한 검토가 필요하다.

Cloudflare Computer가 중요한 이유는 이러한 설계 선택을 명시적으로 드러내기 때문이다. 이는 개발자에게 파일을 내구성 있는 상태로, 실행을 선택 가능한 서비스로, 그리고 겉으로 보이는 컴퓨터를 각 작업에 맞춰 조립되는 추상화로 다루도록 요구한다.

이 프리뷰가 크게 바뀌더라도 이러한 관점은 에이전트 인프라에 영향을 미칠 것이다. 에이전트가 나중에 파일을 필요로 한다는 이유만으로 하나의 컨테이너나 microVM을 계속 유지하는 방식에 대한 대안을 제시한다.

GitHub에서의 급증은 이 아이디어에 대한 관심을 확인해 준다. 하지만 개발자들이 하나의 머신이 주는 운영 단순성을 선호할지, 아니면 하나의 워크스페이스를 공유하는 여러 런타임이 약속하는 효율성을 선호할지는 아직 결론 나지 않았다.

향후 몇 달간은 스타 수보다 리포지토리를 지켜봐야 한다. 안정적인 API, 엔드투엔드 벤치마크, 엄격한 백엔드 정책이 Cloudflare Computer가 프로덕션 인프라가 될지, 아니면 매력적인 프리뷰로 남을지를 결정할 것이다.

cloudflare computer preview를 평가하는 팀은 범위를 제한한 워크로드로 시작하고, 모든 런타임 전환을 문서화하며, 영속 상태를 신뢰하기 전에 복구를 검증해야 한다. 어떤 작업이 실제로 Linux를 필요로 하며, 어떤 작업은 파일과 작은 실행 표면만 있으면 되는가? 추적 기록과 실패 테스트를 통해 이 질문에 답하면 하이브리드 모델이 에이전트에 적합한지 알 수 있다. 또한 기존 샌드박스가 보안을 확보하고 운영하기 더 쉬운 지점도 드러날 것이다. 더 큰 교훈은 이미 유용하다. 에이전트의 컴퓨터가 반드시 영구적으로 실행되는 하나의 머신일 필요는 없다. 그러나 이를 서비스로 분할하면 복잡성은 라우팅, 동기화, 정책으로 이전된다. 이러한 메커니즘을 구현 세부 사항이 아니라 핵심 인프라로 다뤄야 한다.