에이전트 샌드박스 확장을 위해 재구축된 Cloudflare Containers, 정적 배포 대신 런타임 제어 채택
회사 발표에 따르면, 에이전트 샌드박스 확장을 위해 재구축된 Cloudflare Containers는 이제 6배 이상 빠르게 시작된다. 9월 30일 공개된 이번 릴리스에는 런타임 이미지 선택, 런타임 인스턴스 크기 조정, 그리고 공개 베타 단계의 파일시스템 스냅샷도 추가됐다.
중요한 변화는 단순히 콜드 스타트가 짧아진 데 있지 않다. Cloudflare는 요청과 영속적인 애플리케이션 상태를 조정하는 상태 저장형 서버리스 구성 요소인 Durable Object로 각 샌드박스의 제어를 옮겼다. 이 결정은 Cloudflare Containers의 첫 버전을 형성했던 정적 배포 모델에 도전한다.
개발자는 이제 에이전트가 각 작업에 필요한 환경을 선택하도록 할 수 있다. 코딩 작업에는 더 큰 인스턴스와 완전한 Linux 툴체인이 필요할 수 있다. 더 작은 자동화 작업은 가벼운 환경을 사용할 수 있다. 작업이 중단되면 시스템은 파일시스템을 저장하고 컴퓨팅을 중지한 뒤 나중에 워크스페이스를 복원할 수 있다.
이는 Cloudflare를 경쟁이 치열한 에이전트 인프라 시장에 더 직접적으로 진입시킨다. E2B, Modal, Daytona, Vercel 및 하이퍼스케일 클라우드 서비스는 이미 격리된 실행을 위한 다양한 접근 방식을 제공한다. Cloudflare의 주장은 전 세계에서 주소 지정 가능한 컨트롤러, 격리된 Linux 워크스페이스, 영속 상태가 하나의 프로그래밍 가능한 단위로 작동해야 한다는 것이다.
이 아키텍처는 코딩 에이전트, 평가, 장기 실행 워크플로에 적합해 보인다. 다만 6배 빠른 시작이라는 주장은 Cloudflare가 제시한 것이고, 스냅샷은 여전히 공개 베타이며, 여러 운영상 제한도 중요하다. 진정한 시험대는 팀이 과도한 라이프사이클 복잡성을 떠안지 않고도 신뢰할 수 있는 제어를 얻는지 여부다.
에이전트 샌드박스 확장을 위해 재구축된 Cloudflare Containers, 제어 플레인을 바꾸다
Cloudflare의 핵심 변화는 샌드박스 구성을 배포 시점에서 에이전트가 작업을 시작하는 순간으로 옮긴 것이다.
이전 모델에서는 애플리케이션이 일반적으로 배포 구성에서 하나의 컨테이너 이미지와 인스턴스 유형을 선언했다. 두 설정 중 하나를 변경하면 애플리케이션 수준의 롤아웃이 발생했다. 이 방식은 예측 가능한 서비스에는 적합하지만, 에이전트는 요청마다 달라지는 워크로드를 생성한다.
코드 수정 에이전트에는 리포지토리, 컴파일러, 패키지 관리자, 브라우저, 테스트 스위트가 필요할 수 있다. 평가 워커에는 입력이 엄격히 통제된 깨끗하고 재현 가능한 환경이 필요할 수 있다. 또 다른 작업에는 메모리가 제한되고 인터넷 접속이 없는 짧은 스크립트만 필요할 수도 있다.
Cloudflare의 새로운 durable_object 스케줄링 정책을 사용하면 애플리케이션 코드가 런타임에 이러한 선택을 내릴 수 있다. 제어 Durable Object는 ctx.container.start()를 호출하고 해당 작업에 적합한 이미지, 스냅샷, 인스턴스 구성을 제공한다.
사전 정의된 크기에는 lite와 네 가지 standard 구성이 포함된다. 개발자는 플랫폼 제한 내에서 맞춤형 CPU, 메모리 및 디스크 값도 전달할 수 있다. 런타임 스케줄링 정책은 중앙에서 선택한 하나의 구성을 샌드박스별 결정으로 대체한다.
이미지 선택도 같은 모델을 따른다. 개발자는 Cloudflare의 명령줄 배포 도구인 Wrangler를 통해 이름이 지정된 이미지를 선언한다. 플랫폼은 변경 불가능한 참조를 준비하고, Durable Object는 샌드박스를 시작할 때 그중 하나를 선택한다.
이 방식은 하나의 애플리케이션이 역할마다 별도의 컨테이너 애플리케이션을 배포하지 않고도 여러 에이전트 역할을 지원할 수 있게 한다. 조정자는 가벼운 리서치 작업을 한 이미지로 보낸 뒤, 더 많은 리소스를 가진 다른 이미지에 빌드 작업을 할당할 수 있다.
Cloudflare는 Node.js가 포함된 관리형 Debian 이미지 cloudflare/debian-trixie도 도입했다. 에이전트는 이 기반에서 시작해 exec()를 통해 도구를 설치하고, 결과 워크스페이스를 스냅샷으로 보존할 수 있다.
Cloudflare의 샌드박스 발표에 따르면, 새 스케줄링 경로는 Containers를 6배 이상 빠르게 시작한다. 회사는 이전에 Durable Object와 컨테이너 런타임 사이에 존재했던 여러 조정 단계를 제거했다고 밝혔다.
이 주장은 신중하게 해석할 필요가 있다. Cloudflare는 대표적인 이미지, 리전 또는 워크로드 유형을 비교하는 독립 벤치마크를 제시하지 않았다. 컨테이너 준비 상태는 이미지 크기, 엔트리포인트 동작, 용량, 애플리케이션 수준 헬스 체크에도 좌우된다.
Cloudflare의 자체 아키텍처 문서는 콜드 스타트가 흔히 1초에서 3초 사이에 발생한다고 설명한다. 또한 시작 시간은 이미지와 초기화 작업에 따라 달라진다고 명시한다. 더 빠른 스케줄러도 이미지 내부에서 발생하는 지연까지 없앨 수는 없다.
플랫폼은 프로세스가 반드시 트래픽을 받을 준비가 되기 전에 running 속성을 노출한다. 개발자는 첫 요청을 보내기 전에 여전히 포트 준비 상태를 확인해야 한다. 에이전트의 경우 “컨테이너가 시작됨”과 “워크스페이스가 유용한 작업을 할 준비가 됨”은 서로 다른 측정값으로 남는다.
이러한 단서에도 불구하고, 런타임 구성은 제품의 운영 모델을 바꾼다. Cloudflare Containers는 더 이상 에이전트가 우연히 사용하는 배포 서비스에만 머물지 않는다. 개별 작업을 중심으로 에이전트 컨트롤러가 조립하고, 크기를 조정하고, 중지하고, 재구성할 수 있는 리소스가 된다.
더 빠른 에이전트 샌드박스가 정적 배포 모델에 가하는 압력
에이전트 워크로드는 단지 하나의 이미지를 효율적으로 실행하는 인프라가 아니라, 작업 사이에 형태를 바꿀 수 있는 인프라에 보상을 준다.
전통적인 컨테이너 플랫폼은 개발자가 배포 전에 애플리케이션의 형태를 안다고 가정한다. 팀은 이미지, 리소스 할당, 네트워킹 정책, 확장 구성을 선택한다. 이후 스케줄러는 대체로 이러한 속성을 공유하는 복제본을 만든다.
에이전트 시스템은 이 가정을 흔든다. 다음 행동은 사용자 요청, 모델의 결정, 도구 결과, 이전 작업이 남긴 상태에 따라 달라진다. 동일 제품 내에서 연속된 두 작업도 서로 다른 운영체제, 종속성, 리소스 제한, 네트워크 권한을 필요로 할 수 있다.
이러한 가변성은 정적 애플리케이션 구성을 중심으로 구축된 제공업체에 압력을 만든다. 팀은 여전히 여러 서비스를 배포하고 그 사이에 작업을 라우팅할 수 있다. 그러나 새로운 워크로드 유형마다 또 하나의 배포 단위, 롤아웃 경로, 용량 결정, 구성 드리프트 원인이 추가된다.
Cloudflare의 런타임 모델은 이 결정의 일부를 애플리케이션 코드로 옮긴다. 에이전트 컨트롤러는 작업을 검토한 후 샌드박스 이미지와 인스턴스 유형을 선택할 수 있다. 또한 샌드박스에 인터넷 액세스를 부여할지, 저장된 스냅샷에서 시작할지도 결정할 수 있다.
따라서 주요 경쟁 상대는 특정 공급업체 하나가 아니다. 애플리케이션의 모든 샌드박스를 동일하게 사전 정의된 서비스의 복제본으로 취급하는 정적 배포 모델이다.
E2B, Modal, Daytona, Vercel은 이미 각각의 추상화를 통해 이 시장에 대응하고 있다. 일부는 개발자 친화적인 샌드박스 API를 강조한다. 다른 업체들은 함수, 가상 머신, 워크스페이스 또는 더 폭넓은 클라우드 오케스트레이션을 중심으로 구축된다. Kubernetes나 Firecracker를 직접 운영하는 팀은 더 많은 제어권을 얻지만, 더 많은 인프라도 직접 책임져야 한다.
Cloudflare의 차별점은 각 컨테이너와 해당 Durable Object 사이의 관계다. Durable Object는 Linux 환경 외부에서 안정적인 ID, 애플리케이션 코드, 스토리지, 알람, 조정 기능을 제공한다. 컨테이너는 일반적인 운영체제가 필요한 도구를 위해 격리된 컴퓨팅을 제공한다.
Linux 워크스페이스가 절전 상태여도 에이전트의 의사결정 루프는 계속 활성화될 수 있다. 더 무거운 샌드박스를 계속 실행하지 않고도 사용자와 통신하고, 권한 상태를 유지하며, 모델을 호출할 수 있다. 컴파일러나 개발 서버가 필요해지면 컨트롤러가 컨테이너를 깨운다.
Cloudflare는 이 분리를 에이전트의 “두뇌”와 “손”을 분리하는 것으로 설명한다. 컨트롤러는 의도와 상태를 유지하고, 샌드박스는 실패하거나 중지되거나 교체가 필요할 수 있는 명령을 수행한다.
이 분리는 운영상 이점뿐 아니라 보안상 이점도 제공한다. Durable Object는 컨테이너 외부에 자격 증명을 보관하고 아웃바운드 요청을 중재할 수 있다. 에이전트가 승인된 서비스 호출에 필요한 모든 비밀에 직접 접근할 필요는 없다.
Cloudflare는 이전에 동적으로 생성되는 에이전트 코드에 격리된 실행 환경이 필요하다고 주장했다. 이전의 코드 샌드박스 모델은 완전한 Linux 시스템이 필요하지 않은 작업을 위한 경량 Dynamic Workers에 초점을 맞췄다.
Containers는 이 분할의 더 무거운 쪽을 담당한다. 패키지 관리자, 네이티브 바이너리, 리포지토리, 컴파일러, 터미널, 개발 서버를 지원한다. Dynamic Workers는 더 좁은 런타임에서 더 작은 코드 실행 작업을 처리할 수 있다.
이는 계층형 실행 전략을 만든다. 컨트롤러는 짧은 API 워크플로에는 경량 샌드박스를 사용하고, Linux가 필요한 작업에는 컨테이너를 할당할 수 있다. 모든 작업을 완전한 컨테이너 내부에서 처리하면 시작 시간과 리소스가 낭비되므로 런타임 선택이 중요하다.
이 압력은 샌드박스 공급업체를 넘어선다. 내부 플랫폼 팀은 프로비저닝 지연을 숨기기 위해 종종 웜 개발 환경 풀을 유지한다. 더 빠른 콜드 스타트와 재개 가능한 파일시스템은 대규모 유휴 풀을 유지해야 할 근거를 약화시킨다.
그러나 Cloudflare가 오케스트레이션을 없애는 것은 아니다. 오케스트레이션을 Durable Object와 그 애플리케이션 코드로 옮기는 것이다. 팀은 여전히 승인 규칙, 동시성 제어, 재시도 동작, 권한 부여, 정리, 관측 가능성을 설계해야 한다.
승리하는 모델은 가장 작은 격리 시작 수치를 보고하는 플랫폼이 아닐 것이다. 에이전트의 결정부터 검증된 작업 결과까지의 총 시간을 최소화하는 모델이 될 것이다.
여기에는 이미지 준비, 리포지토리 액세스, 종속성 복원, 명령 실행, 네트워크 지연, 종료 작업이 포함된다. 실패한 세션이나 유실된 작업으로 인해 발생하는 사람의 지연도 포함된다.
옵션을 비교하는 엔지니어링 팀의 경우, 관련 벤치마크는 전체 워크플로를 재현해야 한다. 합성된 빈 컨테이너 테스트로는 대규모 리포지토리, 패키지 설치, 브라우저 시작 또는 테스트 스위트를 대표할 수 없다.
이러한 평가는 팀이 유지해야 하는 설계 지식도 만들어낸다. 검색 가능한 엔지니어링 지식 베이스는 벤치마크 가정, 보안 결정, 마이그레이션 결과를 구현과 함께 보존할 수 있다.
Durable Objects가 Containers를 작업별 컴퓨팅으로 전환하다
이번 릴리스의 핵심 메커니즘은 컨테이너를 영구적인 애플리케이션 상태가 아닌 교체 가능한 컴퓨팅으로 취급하는 상태 저장형 컨트롤러다.
모든 Cloudflare Container는 Durable Object와 연결된다. 요청은 먼저 Worker에 도달한 뒤 컨테이너에 도달하기 전에 해당 객체를 거쳐 라우팅된다. Durable Object는 특정 워크스페이스를 주소 지정하고 그 ID와 연결된 상태를 보존할 수 있다.
새 API에서 개발자는 DurableObject를 직접 확장하고 this.ctx.container를 통해 연결된 컨테이너에 접근한다. 이는 Containers를 기존 샌드박스 서비스처럼 보이게 하기 위해 Cloudflare가 처음 사용했던 래퍼 클래스를 제거한다.
컨트롤러는 컨테이너를 시작하고, 명령을 실행하고, 검사하고, 종료를 모니터링하고, 프로세스 신호를 보내고, 비활성 시간 제한을 설정하고, 인스턴스를 삭제할 수 있다. 이러한 제어 기능을 Durable Object 스토리지, 알람, WebSockets, 원격 프로시저 호출과 결합할 수 있다.
버그 보고에 대응하는 코딩 에이전트를 생각해 보자. Durable Object는 세션 식별자, 승인된 리포지토리, 사용자 권한, 현재 작업 단계를 저장할 수 있다. 이어 적절한 언어 툴체인이 포함된 이미지를 선택하고 알맞은 인스턴스를 시작할 수 있다.
컨테이너는 리포지토리를 복제하고, 종속성을 설치하며, 테스트 스위트를 실행하고, 파일을 수정한다. 그 사이 Durable Object는 WebSocket을 통해 진행 상황을 전송하고 컨테이너 외부에 체크포인트를 기록할 수 있다.
컨테이너 프로세스가 종료되더라도 컨트롤러는 세션의 식별 정보와 메타데이터를 유지한다. 실패를 점검하고, 알려진 상태에서 재시작하거나, 전체 상호작용을 잃지 않은 채 문제를 보고할 수 있다.
Cloudflare는 각 컨테이너를 자체 커널과 네트워크를 갖춘 경량 가상 머신인 Firecracker microVM 내부에서 실행한다. 고객 이미지는 해당 가상 머신 안에서 Linux 컨테이너로 실행된다.
플랫폼의 container architecture에 따르면 다른 Cloudflare 워크로드는 해당 커널을 공유하지 않는다. 에이전트가 생성한 명령은 신뢰할 수 있는 사용자 데이터를 처리하는 애플리케이션 내부에서 직접 실행되어서는 안 되므로, 이런 격리는 중요하다.
배치는 계속 동적으로 이뤄진다. Cloudflare는 필요한 이미지를 사용할 수 있는 적격 용량을 선택하며, 라우팅과 시작 속도가 위치 선정에 영향을 미친다. Durable Object와 컨테이너가 같은 위치에서 실행된다는 보장은 없다.
이 단서는 지연 시간에 민감한 제어 루프에서 중요하다. 전 세계에서 접근 가능한 식별 정보가 있다고 해서 모든 작업이 사용자, 모델 제공업체 또는 샌드박스 옆에서 실행된다는 뜻은 아니다. 팀은 예상 운영 리전에 걸쳐 전체 요청 경로를 측정해야 한다.
세션 간에 용량도 이동할 수 있다. 컨테이너가 중지됐다가 나중에 재시작되면 Cloudflare는 대체 인스턴스를 다른 곳에 배치할 수 있다. 애플리케이션은 한 머신의 로컬 식별 정보를 영구적인 것으로 간주해서는 안 된다.
Durable Object는 연속성 계층이 된다. 워크스페이스를 찾고, 재구축하거나, 복원하는 데 필요한 정보를 저장한다. Linux 인스턴스는 유휴 상태가 되면 사라질 수 있는 실행 리소스가 된다.
이 아키텍처는 분기형 워크로드도 지원한다. 코디네이터는 동일하게 준비된 기준 상태에서 여러 독립적인 시도를 시작할 수 있다. 각 시도는 서로 다른 모델, 시스템 프롬프트, 스킬 세트 또는 복구 전략을 시험할 수 있다.
컨트롤러는 이러한 실행을 모니터링하고 결과를 비교하며, 선호하는 출력을 보존할 수 있다. 강화학습 시스템도 비슷한 패턴을 사용해 통제된 환경을 만들고, 결과를 평가하며, 실험 사이에 상태를 재설정할 수 있다.
런타임 인스턴스 크기 조정은 이 모델을 강화한다. 컨트롤러는 빌드에는 더 많은 리소스를 할당하고 가벼운 명령에는 리소스를 줄일 수 있다. 정적인 애플리케이션 전반의 크기 설정은 팀이 가장 큰 일반 작업에 맞춰 프로비저닝하거나 별도 배포를 유지하도록 강제한다.
하지만 프로그래밍 가능성은 책임을 애플리케이션으로 이전한다. 컨트롤러는 모델이 제한 없이 리소스를 선택하지 못하게 해야 한다. 임의의 모델 출력을 인프라 API에 전달하는 대신, 에이전트 요청을 승인된 정책에 매핑해야 한다.
같은 원칙이 이미지에도 적용된다. 런타임 선택을 허용한다고 해서 에이전트가 검토되지 않은 어떤 이미지든 실행하도록 허용한다는 뜻은 아니다. Cloudflare는 선언되고 다이제스트로 고정된 이미지 참조를 요구하며, 이는 배포의 재현성을 유지하는 데 도움이 된다.
팀은 여전히 이미지 허용 목록을 유지하고, 종속성을 스캔하며, 아웃바운드 접근을 제한하고, 게스트 환경에서 자격 증명을 분리해야 한다. 샌드박스는 노출을 줄이지만 완전한 보안 정책을 정의하지는 않는다.
운영상 Durable Object는 라이프사이클 상태의 단일 진실 공급원으로 남아야 한다. Cloudflare의 직접 API는 제어 기능을 제공하지만, 작업이 언제 복구 가능, 포기됨, 완료됨 또는 안전하게 재시도 가능한 상태가 되는지는 애플리케이션이 결정해야 한다.
이것이 더 빠른 에이전트 샌드박스의 실제 작동 방식이다. 스케줄러 개선도 중요하지만, 지속적인 변화는 어느 한 컨테이너 프로세스보다 오래 유지되는 명시적 제어 플레인이다.
파일시스템 스냅샷은 파일을 보존하지만, 실행 중인 세션은 보존하지 않는다
스냅샷은 반복적인 설정 작업을 줄여 주지만, 완전한 일시 중단 및 재개 이미지가 아니라 불변의 파일시스템 체크포인트다.
Cloudflare의 네이티브 파일시스템 스냅샷은 durable_object 스케줄링 정책을 통해 공개 베타로 제공된다. 실행 중인 컨테이너는 snapshotContainer()를 호출해 특정 시점의 쓰기 가능한 루트 파일시스템을 캡처한다.
반환된 핸들에는 식별자, 크기, 선택적 이름이 포함된다. Worker API는 스냅샷 목록을 조회하는 명령을 제공하지 않으므로, 개발자는 대개 Durable Object 스토리지에 이 핸들을 저장해야 한다.
이후 컨테이너는 저장된 핸들에서 시작할 수 있다. 따라서 원래 컴퓨팅이 중지된 뒤에도 코딩 워크스페이스를 복구할 수 있다. 복원된 파일시스템을 통해 리포지토리, 설치된 종속성, 빌드 캐시, 구성 파일 및 수정 내용이 돌아올 수 있다.
이 모델은 에이전트 인프라에서 흔히 발생하는 불일치를 해결한다. 빈 샌드박스를 시작하는 데는 몇 초가 걸릴 수 있지만, 유용한 개발 환경을 준비하는 데는 몇 분이 걸릴 수 있다. 종속성 설치를 반복하면 사용자가 실제로 체감하는 시작 측정치에서 가장 큰 비중을 차지할 수 있다.
스냅샷은 평가를 위한 안정적인 기준 상태도 제공한다. 팀은 하나의 리포지토리와 툴체인을 준비해 저장한 뒤, 동일한 체크포인트에서 여러 실험을 시작할 수 있다. 복원 후 각 샌드박스에는 독립적인 쓰기 가능 환경이 제공된다.
이는 시도 간 환경 드리프트를 줄인다. 두 모델 버전이 서로 다른 종속성 상태를 접하면 테스트 결과를 비교하기가 더 어려워진다. 공유되는 불변 체크포인트는 평가 대상 변수를 분리하는 데 도움이 된다.
이 기능은 더 긴 프로젝트도 지원한다. 사용자가 떠날 때 에이전트가 워크스페이스를 저장하고 컴퓨팅을 중지한 다음, 사용자가 돌아올 때 파일을 복원할 수 있다. 이는 파일시스템 연속성과 지속적인 리소스 사용을 분리한다.
하지만 “스냅샷”이라는 말은 Cloudflare가 현재 보존하는 것보다 더 많은 것을 암시할 수 있다. snapshot documentation에 따르면 시스템은 전체 컨테이너 파일시스템을 캡처하지만, 메모리, 실행 중인 프로세스 또는 별도로 마운트된 파일시스템은 캡처하지 않는다.
복원된 컨테이너는 엔트리포인트를 다시 실행한다. 메모리 내 빌드, 활성 디버거, 터미널 프로세스 또는 개발 서버는 중단된 정확한 명령 지점에서 재개되지 않는다. 애플리케이션이 이러한 프로세스를 재구성해야 한다.
스냅샷은 이를 생성한 이미지 버전에 종속된다. 개발자는 이를 다른 이미지로 복원할 수 없다. 기본 이미지가 변경되면 팀은 새 호환 스냅샷을 생성해야 한다.
각 스냅샷 핸들에는 암묵적인 30일 수명 기간이 있다. 복원하면 해당 기간이 갱신되지만, 현재 개발자는 다른 보존 기간을 구성할 수 없다. 이런 제한 때문에 외부 보존 계획이 없는 한 스냅샷은 무기한 아카이브에 적합하지 않다.
스냅샷은 불변이다. 복원 후 변경된 내용을 보존하려면 팀은 또 다른 스냅샷을 만들어야 한다. 따라서 애플리케이션에는 복구 가치와 스토리지, 지연 시간, 운영 복잡성 간의 균형을 맞추는 체크포인트 정책이 필요하다.
공개 베타 상태 역시 주의가 필요한 이유다. 프로덕션 팀은 중단, 동시 접근, 이미지 업데이트 및 리전 배치 변경 상황에서 스냅샷 생성과 복원을 검증해야 한다.
실패 경계도 테스트해야 한다. 컨테이너가 체크포인트 도중 중지되면, 애플리케이션에는 어떤 스냅샷이 여전히 유효한지에 대한 명확한 기록이 필요하다. 작업이 외부 시스템을 변경했다면 파일시스템을 복원해도 그 외부 작업은 되돌려지지 않는다.
이 구분은 자율 에이전트에 특히 중요하다. 롤백은 로컬 파일을 복원할 수 있지만, 풀 리퀘스트, 데이터베이스 업데이트, 이메일 또는 클라우드 리소스는 그대로 남긴다. 작업을 무작정 재시도하면 되돌릴 수 없는 작업이 중복될 수 있다.
따라서 컨트롤러에는 샌드박스 외부의 작업 원장이 필요하다. 승인된 작업, 외부 부작용 및 완료된 체크포인트를 기록해야 한다. 파일시스템만으로는 에이전트 작업의 완전한 사실을 나타낼 수 없다.
보안 팀은 스냅샷이 무엇을 보존하는지도 점검해야 한다. 리포지토리, 생성된 코드, 로그, 캐시된 패키지 및 임시 자격 증명은 모두 쓰기 가능한 파일시스템에 남을 수 있다. 스냅샷은 민감한 자료를 실행 세션보다 더 오래 보존할 수 있다.
Cloudflare는 게스트 내부의 시크릿 노출을 줄일 수 있는 아웃바운드 요청 가로채기와 외부 자격 증명 처리를 제공한다. 개발자는 도구가 토큰을 구성 파일, 셸 히스토리 또는 패키지 캐시에 복사하지 않는지도 검증해야 한다.
회사의 마이그레이션 방향은 또 다른 실무적 문제를 제기한다. 더 빠른 경로와 네이티브 스냅샷을 포함한 새 기능에는 직접적인 ctx.container 접근이 필요하다. Cloudflare는 이전 Container 및 레거시 Sandbox 클래스를 2026년 12월 31일까지 유지할 것이라고 밝혔다.
회사에 따르면 기존 배포는 그 날짜 이후에도 계속 실행되지만, 해당 클래스는 업데이트를 더 이상 받지 않는다. 새로운 기능을 원하는 팀은 라이프사이클 로직을 직접 Durable Object API로 마이그레이션해야 한다.
이는 모든 팀이 안전하게 활성화할 수 있는 플래그가 아니라, 의미 있는 아키텍처 변경이다. 직접 API는 시스템의 식별 및 조정 모델을 더 많이 노출한다. 또한 개발자에게 이전에는 기본 클래스가 숨겨 주던 동작을 명시적으로 책임지도록 요구한다.
Cloudflare는 Sandbox SDK 1.0을 슈퍼클래스가 아닌 유틸리티 모음으로 전환하고 있다. 이를 통해 팀은 편리한 헬퍼와 네이티브 라이프사이클 제어를 결합할 수 있을 것이다. 또한 Cloudflare가 SDK 래퍼가 아니라 Durable Object를 핵심 추상화로 정의하려 한다는 점도 확인한다.
다음 시험대는 신뢰성, 도입, 그리고 경쟁사의 대응이다
실제 에이전트 시스템이 새로운 제어 기능을 더 낮은 작업 지연 시간과 안정적인 복구로 전환할 때에만 이번 출시는 중요해진다.
첫 번째로 지켜볼 신호는 완전한 워크로드 전반의 프로덕션 성능이다. Cloudflare가 보고한 6배 개선은 시작 경로에 관한 것이지만, 개발자에게는 작업 디스패치부터 애플리케이션 준비 상태까지의 측정치가 필요하다.
유용한 테스트는 작고 큰 이미지, 여러 리전, 복원된 스냅샷, 새 파일시스템 및 서로 다른 인스턴스 크기를 포괄해야 한다. 또한 스케줄러 지연 시간을 이미지 초기화, 종속성 복원 및 서비스 준비 상태와 구분해야 한다.
이러한 측정에서 일관되게 더 짧은 종단 간 지연이 나타난다면 Cloudflare의 주장은 더 설득력을 얻는다. 리포지토리와 개발 서버가 워크플로에 들어오면 이득이 사라진다면, 시작 속도는 더 제한적인 장점이 된다.
두 번째 신호는 공개 베타 스냅샷이 까다로운 워크로드에 도달한 뒤의 신뢰성이다. 팀은 복원 실패율, 체크포인트 지속 시간, 스토리지 동작, 이미지 업그레이드 절차 및 중단된 세션 이후의 복구를 지켜봐야 한다.
코딩 에이전트의 성공적인 도입은 특히 많은 것을 보여 줄 수 있다. Cloudflare는 이미 Base44와 Kilo Code를 에이전트 작업을 위한 격리 환경의 사용자로 언급했다. 이전 Cloudflare 자료는 Figma Make도 신뢰할 수 없는 코드 실행을 위한 Containers 고객으로 지목했다.
이러한 고객 언급은 실제 사용 사례를 보여 주지만, 비교 가능한 성능 데이터를 제공하지는 않는다. 독립적인 엔지니어링 보고서는 출시 홍보 자료보다 더 큰 설득력을 가질 것이다.
대규모 리포지토리에서의 스냅샷 동작도 중요하다. 패키지 디렉터리와 빌드 출력은 빠르게 커질 수 있다. 팀은 반복된 체크포인트를 거치며 워크스페이스가 커질 때도 스냅샷이 빠르고 관리 가능한 상태로 유지되는지 이해해야 한다.
Cloudflare가 스냅샷 보존 제어, 목록 조회 API, 관측성 또는 버전 간 마이그레이션 도구를 확장한다면, 이는 기능이 더 폭넓은 프로덕션 사용으로 나아가고 있음을 시사할 것이다. 지속되는 제한은 장기 워크스페이스 전략을 약화시킬 것이다.
세 번째 신호는 경쟁사가 Cloudflare의 결합된 컨트롤러 및 샌드박스 모델에 어떻게 대응하는지다. 에이전트 샌드박스 시장에는 각기 다른 강점을 가진 전문 공급업체와 더 광범위한 컴퓨팅 플랫폼이 포함된다.
E2B는 에이전트를 위해 설계된 전용 클라우드 환경을 강조합니다. Modal은 샌드박스 컴퓨팅을 더 큰 서버리스 플랫폼과 연결합니다. Daytona는 개발 환경에 집중하는 반면, Vercel은 샌드박스 기능을 애플리케이션 플랫폼과 통합합니다.
하이퍼스케일 클라우드는 가상 머신, 컨테이너, ID 시스템, 오케스트레이션 서비스를 통해 팀에 광범위한 제어권을 제공합니다. 단점은 이러한 구성 요소를 지연 시간이 낮은 에이전트 제품으로 조합하는 데 상당한 엔지니어링 작업이 필요하다는 점입니다.
Cloudflare는 Durable Objects가 이러한 조립 과정을 압축할 수 있다고 보고 있습니다. ID, 상태, 통신, 정책 및 수명주기는 샌드박스 컨트롤러와 나란히 배치될 수 있습니다. Cloudflare의 글로벌 네트워크는 라우팅과 준비된 용량을 제공합니다.
경쟁사의 대응은 여러 형태로 나타날 수 있습니다. 다른 제공업체들은 더 강력한 상태 기반 조정 기능, 더 유연한 스냅샷, 더 세밀한 런타임 규모 조정 또는 더 긴밀한 자격 증명 중재 기능을 추가할 수 있습니다. Cloudflare의 시작 시간 관련 주장을 반박하는 벤치마크를 공개할 수도 있습니다.
경쟁사들이 외부 상태 기반 컨트롤러로 수렴한다면, 고객이 다른 플랫폼을 선택하더라도 Cloudflare의 아키텍처는 선견지명이 있었던 것으로 보일 것입니다. 개발자들이 더 단순한 호스팅형 샌드박스 API를 선호한다면 Durable Object 모델은 지나치게 인프라 중심적으로 느껴질 수 있습니다.
도입 여부는 애플리케이션 팀이 원하는 제어 수준에 따라 부분적으로 결정될 것입니다. 코딩 에이전트를 구축하는 스타트업은 직접적인 수명주기 프로그래밍을 중요하게 여길 수 있습니다. 코드 실행 기능 하나를 추가하는 팀은 결정해야 할 사항이 적은 의견이 반영된 서비스를 선호할 수 있습니다.
Cloudflare는 플랫폼을 차별화하는 기능을 감추지 않으면서 두 그룹 모두를 지원해야 합니다. 새로운 SDK 방향은 또 하나의 필수 추상화 대신 네이티브 API 주변의 유틸리티를 제공함으로써 그 균형을 맞추려 합니다.
보안 사고 역시 또 다른 결정적 척도가 될 것입니다. 에이전트 샌드박스는 종종 네트워크 접근 권한과 독점 코드에 가까운 위치에서 신뢰할 수 없거나 예측하기 어려운 명령을 실행합니다. 자격 증명을 유출하거나 테넌트 간 접근을 허용하는 빠른 환경은 핵심 목적을 달성하지 못할 것입니다.
Cloudflare의 Firecracker microVM 사용은 워크로드 간 커널 격리를 제공합니다. 하지만 안전한 운영은 이미지 위생, 아웃바운드 제어, 권한 부여, 시크릿 처리, 로깅 및 애플리케이션 정책에도 달려 있습니다.
팀은 이 모델을 에이전트가 생성한 코드를 신뢰해도 된다는 허가가 아니라 다층적 격리로 다뤄야 합니다. Durable Object는 정책 집행 지점이 될 수 있지만, 개발자는 해당 정책을 구현하고 테스트해야 합니다.
이번 출시는 에이전트 제품 아키텍처에 관한 더 넓은 질문도 제기합니다. 에이전트는 워크스페이스 외부에 존재하며 이를 교체 가능한 도구로 취급해야 할까요, 아니면 에이전트가 자신의 컴퓨터 내부에서 실행되어야 할까요?
Cloudflare는 두 패턴을 모두 지원합니다. 에이전트를 Durable Object에서 실행하면 컴퓨팅이 유휴 상태일 때도 통신과 상태를 유지할 수 있습니다. 컨테이너 내부에서 실행하면 익숙한 Linux 프로세스 모델을 제공하고, 객체는 외부에서 이를 감독합니다.
첫 번째 패턴은 두뇌와 손의 경계를 명확히 합니다. 두 번째 패턴은 로컬 파일과 프로세스를 기대하는 기존 에이전트 런타임을 단순화할 수 있습니다. 실제 도입은 개발자들이 어떤 모델을 더 쉽게 운영할 수 있다고 느끼는지 보여줄 것입니다.
에이전트 샌드박스 확장에 맞춰 재구축된 Cloudflare Containers는 콜드 스타트 개선 이상의 의미를 가집니다. 이는 런타임 선택, 파일시스템 연속성 및 수명주기 정책을 영속 상태로 제어되는 애플리케이션 수준의 결정으로 전환합니다.
이러한 변화는 정적 배포와 단순한 샌드박스 API에 압박을 가합니다. 동시에 개발자에게 미묘한 실패를 만들 수 있는 더 많은 방식을 제공합니다. 런타임 유연성에는 엄격한 정책, 영속적인 작업 기록, 그리고 빈 프로세스가 아닌 유용한 준비 상태를 측정하는 벤치마크가 필요합니다.
이번 출시를 평가하는 팀은 실제 워크로드 하나로 시작해야 합니다. 새로 시작하는 경우, 복원 후 시작, 종속성 준비 상태, 장애 복구 및 전체 작업 완료 시간을 측정하십시오. 그런 다음 컨테이너가 손실되더라도 컨트롤러가 외부 작업을 반복하지 않고 살아남는지 테스트해야 합니다.
향후 몇 달은 Cloudflare의 공개 베타 스냅샷이 계속 신뢰할 수 있는지, 고객이 독립적인 지연 시간 결과를 공개하는지, 경쟁사들이 유사한 상태 기반 제어 기능을 도입하는지를 보여줄 것입니다. 이러한 신호는 이 아키텍처가 장기 실행 에이전트의 일반적인 기반이 될지, 아니면 점점 혼잡해지는 시장에서 또 다른 특수한 선택지로 남을지를 결정할 것입니다.
