Cloudflare Dynamic Workers: AI Agent 샌드박스가 컨테이너보다 100배 빠른 이유

당신의 AI Agent가 방금 데이터 분석 코드를 생성했고 이제 실행하려는 순간, 컨테이너 시작에 3초가 걸리고 메모리는 200MB를 차지하며 사용자 요청은 이미 타임아웃됩니다. 이것은 예외적인 문제가 아니라 업계 전반에서 컨테이너로 AI 코드를 실행할 때 마주치는 흔한 병목입니다.

Cloudflare가 2026년 3월 출시한 Dynamic Workers는 V8 Isolates로 이 시작 시간을 몇 밀리초까지 줄이고 메모리 사용량을 몇 MB 수준으로 압축했습니다. 성능은 100배 향상됩니다. 그 뒤에는 완전히 다른 격리 철학이 있습니다.

쉽게 말해 Dynamic Workers는 단순히 “더 빠른 컨테이너”가 아니라 “요청마다 하나의 샌드박스”라는 모델을 기술적으로 가능할 뿐 아니라 경제적으로도 가능하게 만든 방식입니다. 이 글에서는 V8 Isolates와 전통적인 컨테이너의 본질적 차이를 깊이 분석하고, Dynamic Workers 실전 코드 예시를 제공하며, 기술 선택 결정을 돕겠습니다. AI Agent용 샌드박스 방식을 고르고 있다면 이 글이 비용과 성능의 계산을 분명하게 해 줄 것입니다.

컨테이너가 AI Agent의 성능 병목이 된 이유

이 작업은 예전에는 어떻게 했을까요? 컨테이너가 주류 방식이었습니다. Kubernetes가 Pod를 띄우고, 이미지를 내려받고, 환경을 준비합니다. 프로세스는 성숙하지만 무겁습니다. AI Agent 시나리오에는 한 가지 특징이 있습니다. 코드 실행이 순간적이라는 점입니다. 데이터 분석 스크립트를 몇 초만 돌리면 끝나는 경우가 많은데, 컨테이너 시작에만 3초 이상 걸린다면 어딘가 맞지 않습니다.

2026년 Zhihu의 AI Agent Sandbox 연구 보고서에 따르면 Docker 컨테이너 시작은 대략 500ms입니다. 하지만 이것은 말 그대로 “시작”일 뿐입니다. 이미지 풀, 네트워크 설정, 의존성 초기화까지 더하면 실제 사용 가능한 상태가 되기까지 보통 3초를 넘습니다. 메모리는 어떨까요? 수십 MB에서 시작하고, 복잡한 환경은 200MB를 넘기도 합니다.

“예열 풀을 쓰면 되지 않나?”라고 생각할 수 있습니다. 미리 컨테이너 몇 개를 띄워 두고 요청을 기다리게 하는 방식입니다. 맞습니다. 이것이 실제로 주류 방식입니다. 하지만 문제가 따라옵니다.

첫째는 비용입니다. 예열 풀은 요청이 있든 없든 일정 수의 컨테이너를 항상 온라인으로 유지해야 합니다. 예열 컨테이너 100개가 있고 각각 200MB 메모리를 사용한다면 메모리 비용만으로도 부담이 큽니다. 여기에 컨테이너 재사용의 보안 위험도 고려해야 합니다. 이전 요청의 데이터가 메모리에 남을 수 있습니다.

둘째는 복잡성입니다. 예열 풀은 컨테이너 생명주기, 헬스 체크, 자동 스케일링을 관리해야 합니다. 이 인프라 자체가 이미 만만치 않습니다. 저도 이전 프로젝트에서 Kubernetes 예열 풀을 써 본 적이 있는데, 유지보수 비용이 비즈니스 코드보다 더 컸습니다.

셋째는 시나리오 불일치입니다. AI Agent의 코드 실행은 대개 일회성입니다. 사용자가 CSV를 업로드하고, AI가 분석 코드를 생성하며, 실행 후 바로 폐기합니다. 각 요청에는 독립적인 격리 환경이 필요하지만, 예열 풀의 컨테이너 재사용은 바로 이 격리를 깨뜨립니다.

한 가지 상황을 떠올려 봅시다. 사용자 A의 AI Agent가 코드를 실행해 민감한 데이터를 처리했습니다. 컨테이너는 예열 풀로 돌아가고, 사용자 B의 요청이 들어와 같은 컨테이너를 받습니다. 정리 메커니즘이 있더라도 잔여 데이터 위험은 항상 남습니다. 이것은 이론상의 문제가 아닙니다. 2025년에는 컨테이너 잔여 데이터 때문에 데이터 유출이 발생한 보고도 있었습니다.

따라서 AI Agent 시나리오에서 컨테이너 방식의 모순은 분명합니다. 시작이 느리고, 메모리가 비싸며, 예열 풀에는 보안 위험이 있고, 유지보수가 복잡합니다. 컨테이너가 나쁘다는 뜻은 아닙니다. 다만 컨테이너의 설계 철학이 AI Agent의 실행 모델과 맞지 않는다는 뜻입니다.

V8 Isolates는 어떻게 시작 시간을 밀리초 단위로 줄일까

V8 Isolates란 무엇일까요? V8은 Chrome의 JavaScript 엔진으로, JS 코드를 머신 코드로 컴파일해 실행합니다. Isolate는 V8의 격리 단위입니다. 독립적인 실행 환경이며 자체 메모리 힙, 컴파일 캐시, 전역 객체를 가집니다.

핵심은 Isolate가 호스트 운영체제의 커널을 호출하지 않는다는 점입니다.

컨테이너는 어떻게 동작할까요? 하나의 프로세스를 시작하고 호스트 커널의 시스템 호출(syscall)을 사용합니다. 격리는 커널 레벨의 namespace와 cgroup에 의존합니다. 문제는 이 “격리”가 엄밀히 말하면 유사 격리라는 점입니다. 컨테이너와 호스트는 같은 커널을 공유합니다. syscall은 같은 커널 경로를 지나갑니다.

V8 Isolates는 완전히 다릅니다. JavaScript 코드는 Isolate 안에서 실행되며 syscall을 만들지 않습니다. 모든 작업은 프로세스 내부에서 끝납니다. 메모리 할당, 가비지 컬렉션, 컴파일과 실행이 모두 그렇습니다. 즉 격리 경계가 커널 레벨이 아니라 프로세스 내부에 있습니다.

Tencent News의 2026년 보도는 구체적인 수치를 제시했습니다. V8 Isolates의 시작 시간은 몇 밀리초이고 메모리 사용량은 몇 MB입니다. 컨테이너와 비교하면 시작은 100배 빠르고 메모리 효율은 10-100배 높습니다.

기술 선택을 쉽게 할 수 있도록 격리 기술 비교표를 보겠습니다.

격리 기술	보안 수준	시작 속도	메모리 사용량	syscall 대상
Docker 컨테이너	⭐⭐	~500ms	수십 MB	호스트 커널 공유
gVisor	⭐⭐⭐⭐	~100ms	높음	사용자 공간 커널에서 가로채기
Firecracker microVM	⭐⭐⭐⭐⭐	~150ms	~1GB	독립 가상 커널
V8 Isolates	⭐⭐⭐	몇 ms	몇 MB	애초에 호출하지 않음

이 표가 보여 주는 핵심은 보안 수준과 시작 속도는 trade-off 관계라는 점입니다. Firecracker는 가장 안전하지만(독립 가상 커널), 시작이 가장 느리고 메모리 비용도 가장 큽니다. V8 Isolates는 가장 빠르고 저렴하지만 보안 수준은 중간입니다.

왜 V8 Isolates의 보안 수준은 세 개의 별일까요? 격리 경계가 프로세스 내부에 있기 때문입니다. 한 Isolate가 뚫리면 이론적으로 같은 프로세스 안의 다른 Isolate에 영향을 줄 수 있습니다. 컨테이너보다 안전합니다. 컨테이너는 커널을 공유하지만 최소한 namespace 격리가 있기 때문입니다. 그러나 독립 커널을 가진 microVM보다는 약합니다.

하지만 Cloudflare의 Dynamic Workers는 여러 보안 메커니즘을 추가해 이 “세 개의 별” 수준을 실제 운영 환경에서 받아들일 수 있는 수준으로 끌어올렸습니다. 뒤에서 다섯 겹 방어를 자세히 설명하겠습니다.

다시 말해 V8 Isolates의 핵심 장점은 “더 안전하다”가 아니라 “더 저렴하다”입니다. 요청마다 독립 샌드박스를 시작하고, 사용 후 폐기합니다. 컨테이너 세계에서는 사치에 가깝지만 Isolate 세계에서는 표준 방식입니다.

Dynamic Workers API: load()와 get()의 설계 철학

Dynamic Workers는 두 가지 API 모드를 제공합니다. 설계 철학은 명확합니다. 하나는 순간 실행용이고, 다른 하나는 긴 생명주기용입니다.

load(): 일회성 실행, 사용 후 폐기

load() 모드는 단일 실행 시나리오에 적합합니다. AI가 생성한 코드가 들어오면 Isolate를 시작하고, 실행하고, 폐기합니다. 전체 과정은 밀리초 단위로 끝납니다.

// load() 모드: 일회성 실행
import { DynamicWorkerLoader } from 'cloudflare:sandbox-sdk';

const loader = new DynamicWorkerLoader();

// 코드 로드, 리소스 바인딩, 제한 설정
const dynamicWorker = await loader.load({
  code: aiGeneratedCode,  // AI가 생성한 코드 문자열
  bindings: {
    db: env.DB,           // D1 데이터베이스 바인딩
    kv: env.KV,           // KV 스토리지 바인딩
  },
  limits: {
    cpuMs: 100,           // CPU 시간 제한: 100밀리초
    memoryMB: 128,        // 메모리 제한: 128MB
  }
});

// 코드 실행 후 결과 획득
const result = await dynamicWorker.execute();

// 실행 완료 후 Isolate는 자동으로 폐기됨
console.log(result);

핵심 파라미터는 다음과 같습니다.

• code: 실행할 코드 문자열이며 AI가 동적으로 생성할 수 있습니다.
• bindings: 데이터베이스, 스토리지, API 같은 외부 리소스 바인딩입니다.
• limits: 리소스 남용을 막기 위한 실행 제한입니다.

load()가 적합한 시나리오는 다음과 같습니다.

• 단일 데이터 분석: 사용자가 CSV를 업로드하고 AI가 분석 코드를 생성한 뒤 한 번 실행하고 폐기합니다.
• 임시 코드 실행: AI가 생성한 변환 스크립트나 검증 로직을 실행합니다.
• 사용자 요청 단위 격리: 요청마다 독립적인 샌드박스를 사용해 잔여 데이터 위험이 없습니다.

get(): 캐시 예열, 긴 생명주기 시나리오

get() 모드는 예열된 상태가 필요한 시나리오에 적합합니다. Isolate를 만든 뒤 메모리에 유지하고, 이후 호출에서는 바로 재사용합니다.

// get() 모드: 캐시 예열
const cachedWorker = await loader.get({
  id: 'persistent-analyzer',  // 캐시 위치를 찾기 위한 고정 식별자
  code: analysisCode,         // 미리 로드할 코드
  bindings: {
    vectorize: env.VECTORIZE, // 벡터 데이터베이스 바인딩
  }
});

// 여러 번 호출하며 예열 상태 유지
const result1 = await cachedWorker.execute({ input: data1 });
const result2 = await cachedWorker.execute({ input: data2 });
const result3 = await cachedWorker.execute({ input: data3 });

// 수동 폐기는 필요 없고 Cloudflare가 생명주기를 자동 관리함

get()이 적합한 시나리오는 다음과 같습니다.

• 배치 처리: 같은 분석 로직으로 여러 데이터 세트를 처리합니다.
• 장기 실행 Agent: 상태 유지가 필요한 분석 작업입니다.
• 예열로 지연 시간 단축: 최초 실행 지연을 줄입니다.

두 모드의 본질적 차이는 이렇습니다. load()는 “방을 하루만 빌리고 나가는 것”이고, get()은 “방을 장기 예약하는 것”입니다. 전자는 순간 실행에, 후자는 지속 실행에 적합합니다.

Cloudflare 공식 Sandbox SDK의 AI Code Executor 튜토리얼에는 더 완전한 예제가 있습니다. 이 글을 읽은 뒤 실습으로 이어 가는 것을 권장합니다.

Dynamic Workers의 다섯 겹 보안 방어

앞에서 말했듯 V8 Isolates의 기본 보안 수준은 세 개의 별에 가깝습니다. 하지만 Cloudflare는 Dynamic Workers 위에 여러 겹의 방어를 더해 실제 보안 수준을 프로덕션에서 사용할 수 있는 수준으로 높였습니다.

InfoQ의 2026년 4월 분석 보고서는 이 다섯 겹 방어를 자세히 해부했습니다.

1층: V8 보안 패치 자동 배포

V8 엔진 자체에도 보안 취약점은 있습니다. 복잡한 소프트웨어라면 피할 수 없는 일입니다. Chrome 팀이 취약점을 발견하고 패치를 발표하면 Cloudflare는 몇 시간 안에 전 세계 모든 노드로 배포합니다.

전통적인 방식과 비교해 보겠습니다. 컨테이너 환경의 보안 패치는 호스트 시스템에 의존하고, 업데이트 주기는 몇 주에서 몇 달까지 걸릴 수 있습니다. V8 패치의 대응 속도는 “시간 단위”이지 “주 단위”가 아닙니다.

2층: 동적 위험 Tenant Cordoning

특정 Dynamic Worker가 비정상 행동을 보이면, 예를 들어 메모리가 급증하거나 CPU 사용량이 치솟으면, Cloudflare는 이를 “고위험”으로 표시하고 전용 격리 노드로 옮깁니다.

이를 tenant cordoning이라고 부릅니다. 위험 tenant를 따로 격리해 다른 정상 Worker에 영향을 주지 않게 하는 방식입니다.

3층: MPK 하드웨어 보호

MPK(Memory Protection Keys)는 Intel 하드웨어 레벨의 메모리 격리 메커니즘입니다. 각 Isolate는 독립적인 메모리 접근 권한을 가지며, 하드웨어 레벨에서 경계 밖 접근을 막습니다.

이는 물리 레벨의 보호라서 소프트웨어 격리보다 뚫기 어렵습니다.

4층: 코드 스캔

실행 전에 먼저 스캔합니다. 무한 루프, 메모리 폭탄, 민감한 API 호출 같은 악성 패턴은 자동으로 차단됩니다.

이 방어층은 AI가 생성한 악성 코드를 겨냥합니다. Prompt injection이 AI로 하여금 위험한 코드를 생성하게 할 수 있는데, 코드 스캔은 실행 전에 이를 막을 수 있습니다.

5층: 네트워크 격리

Dynamic Worker는 기본적으로 외부 네트워크 접근을 완전히 차단합니다. 외부 API에 접근해야 할 때는 Cloudflare의 egress proxy를 거치며, 자격 증명 주입 메커니즘으로 Worker가 승인된 API에만 접근하도록 보장합니다.

간단한 보안 아키텍처 다이어그램은 다음과 같습니다.

AI가 생성한 코드
     |
     v
┌─────────────────────────────────────┐
│ Dynamic Worker (V8 Isolate)         │
│ ┌─────────────────────────────────┐ │
│ │ 1층: 코드 스캔                   │ │
│ ├─────────────────────────────────┤ │
│ │ 2층: V8 보안 패치               │ │
│ ├─────────────────────────────────┤ │
│ │ 3층: tenant cordoning           │ │
│ ├─────────────────────────────────┤ │
│ │ 4층: MPK 하드웨어 보호          │ │
│ └─────────────────────────────────┘ │
│         |                           │
│         v                           │
│  Cap'n Web RPC 브리지               │
│         |                           │
│         v                           │
│  5층: egress proxy 자격 증명 주입   │
└─────────────────────────────────────┘

이 다층 방어는 V8 Isolates의 “세 개의 별” 보안 수준을 프로덕션 환경에서 신뢰할 수 있게 만듭니다. 절대적으로 안전하다는 뜻은 아닙니다. 어떤 시스템도 절대 안전하지 않습니다. 다만 “받아들일 수 있는 위험 수준”에 도달했다는 뜻입니다.

Dynamic Workers 가격: 요청마다 샌드박스 하나가 가능한 이유

“요청마다 샌드박스 하나”는 사치처럼 들립니다. 하지만 Dynamic Workers의 비용 모델에서는 현실적으로 가능합니다.

먼저 Cloudflare의 가격 구조를 보겠습니다. Beta 기간에는 무료이고, 정식 가격은 다음과 같습니다.

• $0.002 per unique Worker loaded per day: 하루에 독립 Worker 하나당 0.002달러
• 표준 CPU 시간 요금 추가: $0.02 per million CPU milliseconds
• invocation 요금 추가: $0.50 per million requests

VentureBeat의 2026년 4월 보도는 비교 수치를 제시했습니다. E2B(Firecracker microVM 방식)는 요청당 비용이 $0.01+인 반면 Dynamic Workers는 $0.002면 됩니다.

구체적인 비용 비교를 보겠습니다.

방식	요청당 비용	월 비용(100만 요청)	복잡성	유지보수 비용
컨테이너 예열 풀	$0.02+	$2000+	높음	높음(풀 유지 필요)
E2B microVM	$0.01+	$1000+	중간	낮음
Dynamic Workers	$0.002	$200	낮음	없음

계산해 봅시다. 매일 100만 요청이 있고, 각 요청이 서로 다른 코드(unique Worker)를 실행한다고 가정합니다.

컨테이너 예열 풀 방식:

• 컨테이너 100개 예열, 각 200MB 메모리: 월 $500 메모리 비용
• 예열 풀 인프라 유지: 최소 월 $1500 인건비
• 총비용: $2000+이며 보안 위험도 남습니다.

E2B 방식:

• 요청당 $0.01: 100만 요청 = 월 $10000(정확히는 E2B에 대량 할인 있음)
• 실제 월 비용은 대략 $1000+ 수준이지만 시작 지연은 150ms입니다.

Dynamic Workers 방식:

• unique Worker 비용: 100만 * $0.002 = 월 $2000(이 계산도 정확하지 않습니다. 이것은 매일 unique 기준입니다)
• 올바른 계산: 매일 1000개의 unique Worker라고 하면 $0.002 * 1000 * 30 = 월 $60
• invocation과 CPU 시간을 더하면 월 비용은 약 $200 수준입니다.

핵심 통찰은 Dynamic Workers의 가격이 “요청 횟수”가 아니라 “unique Worker” 기준이라는 점입니다. AI Agent가 실행하는 코드가 템플릿화되어 있다면, 예를 들어 고정된 분석 스크립트라면, unique Worker 수는 요청 수보다 훨씬 적고 비용은 더 낮아집니다.

그래서 “요청마다 샌드박스 하나”가 경제적으로 가능합니다.

• 시작이 빠릅니다(밀리초 단위). 예열 풀이 필요 없습니다.
• 메모리를 적게 씁니다(몇 MB). 큰 메모리 예약이 필요 없습니다.
• 요청 수가 아니라 unique Worker 기준으로 과금됩니다.

전통적인 방식의 아픈 지점과 비교해 보겠습니다.

• 예열 풀은 유지보수가 복잡하고 인건비가 높습니다.
• 컨테이너 재사용에는 보안 위험이 있어 추가 정리 메커니즘이 필요합니다.
• 3초 지연은 사용자 경험을 해칩니다.

Dynamic Workers는 이 세 문제를 해결하면서 비용도 더 낮춥니다. 이제 계산이 분명해졌나요?

Dynamic Workers vs E2B vs gVisor: 무엇을 선택할까

Dynamic Workers의 장점을 많이 이야기했지만, 만능은 아닙니다. 시나리오마다 적합한 방식이 다릅니다.

전체 비교는 다음과 같습니다.

차원	Dynamic Workers	E2B (Firecracker)	gVisor	Docker
시작 속도	⭐⭐⭐⭐⭐ (몇 ms)	⭐⭐⭐⭐ (~150ms)	⭐⭐⭐⭐ (~100ms)	⭐⭐⭐ (~500ms)
보안 수준	⭐⭐⭐ (중간)	⭐⭐⭐⭐⭐ (최고)	⭐⭐⭐⭐ (높음)	⭐⭐ (낮음)
비용 효율	⭐⭐⭐⭐⭐	⭐⭐⭐	⭐⭐⭐⭐	⭐⭐⭐
언어 지원	JS/TS only	Any	Any	Any
상태 지속성	없음(DO와 결합 필요)	있음	없음	있음
유지보수 복잡도	낮음	낮음	중간	높음

언제 Dynamic Workers를 선택할까?

적합한 시나리오:

• AI Agent가 JavaScript 또는 TypeScript를 사용합니다.
• 고빈도 순간 실행이며 요청마다 독립 격리가 필요합니다.
• 비용에 민감하고 예열 풀 인프라를 유지하고 싶지 않습니다.
• 이미 Cloudflare 기술 스택(Workers, KV, D1)을 사용하고 있습니다.

적합하지 않은 시나리오:

• AI Agent가 Python, Rust, Go 코드를 실행해야 합니다.
• 최고 수준의 보안이 필요합니다. 예를 들어 금융 데이터를 처리하는 경우입니다.
• 지속 상태가 필요합니다. 이 경우 Durable Objects를 추가로 구성해야 합니다.

언제 E2B를 선택할까?

E2B는 Firecracker microVM을 사용하며 보안 수준이 가장 높고 시작 시간은 150ms입니다.

적합한 시나리오:

• Python 코드 실행이 필요합니다. 데이터 분석이나 머신러닝이 대표적입니다.
• 최고 수준의 보안이 필요합니다.
• 150ms 시작 지연을 받아들일 수 있습니다.
• 민감한 데이터(금융, 의료)를 처리합니다.

언제 gVisor를 선택할까?

gVisor는 Google이 개발한 사용자 공간 커널이며 컨테이너 호환성이 좋습니다.

적합한 시나리오:

• 컨테이너 호환성이 필요합니다. 기존 Docker 이미지가 있는 경우입니다.
• 보안과 성능의 균형이 필요합니다.
• 기술 스택을 바꾸고 싶지는 않고 보안 수준만 높이고 싶습니다.

언제 Docker를 계속 쓸까?

솔직히 말해 많은 시나리오에서는 Docker로 충분합니다.

적합한 시나리오:

• 요청마다 독립 격리가 필요하지 않습니다.
• 장시간 실행되는 서비스입니다. 순간 실행이 아닙니다.
• 이미 성숙한 컨테이너 인프라가 있습니다.
• 언어가 JS/TS가 아닙니다.

기술 선택은 “누가 최고인가”가 아니라 “무엇이 가장 적합한가”의 문제입니다. Dynamic Workers는 특정 시나리오, 즉 JS/TS AI Agent, 고빈도 순간 실행, 비용 민감 프로젝트에서 분명한 장점이 있지만 모든 것을 대체하는 만능 해법은 아닙니다.

Cloudflare Agent 생태계: 샌드박스에서 지속 상태까지

Dynamic Workers는 고립된 제품이 아니라 Cloudflare Agent 생태계의 일부입니다.

2026년 4월 Cloudflare는 장기 실행 Agent를 위한 프레임워크 오케스트레이션인 Project Think를 발표했습니다. Dynamic Workers와 Durable Objects를 결합하면 완전한 Agent 기술 스택이 만들어집니다.

3계층 아키텍처

Project Think (Think 기본 클래스 - Agent 오케스트레이션)
     |
     +-- Agent Memory (SQL 데이터베이스 - 지속 상태)
     |
     +-- Sub-agents (하위 Agent 조정)
     |
     +-- Dynamic Workers (샌드박스 실행)
     |     |
     |     +-- Durable Objects Facets (샌드박스별 독립 SQLite)
     |
     +-- Tools (API 호출 - egress proxy 자격 증명 주입)

Durable Objects Facets

Durable Objects Facets는 2026년 4월 출시된 새 기능입니다. 각 Dynamic Worker는 독립적인 SQLite 데이터베이스를 가질 수 있고, 상태는 샌드박스가 폐기되어도 사라지지 않습니다.

이것은 Dynamic Workers의 한 가지 약점을 해결합니다. 샌드박스는 실행이 끝나면 폐기되므로 상태를 유지할 수 없습니다. Facets는 각 샌드박스에 자기만의 “노트북”을 제공해 실행 후에도 이전 기록을 조회할 수 있게 합니다.

Project Think

Project Think는 Agent 프레임워크이며 Think 기본 클래스를 제공합니다. Think 기본 클래스를 상속해 하위 Agent 조정, 상태 관리, 도구 호출을 포함한 자체 Agent 로직을 구현할 수 있습니다.

공식 블로그의 예시는 데이터 분석 Agent입니다. Dynamic Workers로 분석 코드를 실행하고, Durable Objects Facets에 과거 결과를 저장하며, Project Think로 여러 하위 Agent를 조정합니다.

Agents SDK

Cloudflare는 Dynamic Workers, Durable Objects, Project Think 통합을 감싼 Agents SDK도 제공합니다. SDK를 사용하면 완전한 AI Agent를 빠르게 만들 수 있습니다.

// Agents SDK 예시
import { Agent } from 'cloudflare:agents-sdk';

class DataAnalysisAgent extends Agent {
  async analyze(data: string) {
    // Dynamic Workers로 분석 코드 실행
    const worker = await this.sandbox.load({
      code: this.generateAnalysisCode(data),
      bindings: { db: this.memory }
    });

    const result = await worker.execute();

    // 결과를 Facets에 저장
    await this.memory.save(result);

    return result;
  }
}

이 생태계는 Dynamic Workers를 “단순한 샌드박스”에서 “Agent 기술 스택의 일부”로 끌어올립니다. AI Agent에 상태 지속성, 하위 Agent 조정, 도구 호출이 필요하다면 Cloudflare의 완성형 조합이 여러 서비스를 이어 붙이는 것보다 더 간결합니다.

결론

Dynamic Workers가 모든 샌드박스 방식을 대체하려는 것은 아닙니다. 특정 시나리오에서 100배 성능 향상을 제공하는 선택지입니다.

핵심 가치는 “요청마다 하나의 샌드박스”를 기술적으로 가능하게 할 뿐 아니라 경제적으로도 가능하게 만든다는 점입니다.

AI Agent가 JavaScript 또는 TypeScript를 사용하고, 각 사용자 요청에 독립 격리 환경을 제공해야 하며, 비용에도 민감하다면 Dynamic Workers는 현재 가장 적합한 방식입니다.

다음 단계는 다음과 같습니다.

• Cloudflare Dynamic Workers 공식 문서를 확인합니다.
• Sandbox SDK의 AI Code Executor 튜토리얼로 첫 샌드박스 환경을 만들어 봅니다.
• Durable Objects Facets와 결합해 상태 지속성을 구현합니다.
• Agent가 장기 실행과 조정을 필요로 한다면 Project Think 프레임워크를 살펴봅니다.

결국 기술 선택의 핵심은 계산을 분명히 하는 것입니다. 시작 속도, 메모리 비용, 보안 수준, 유지보수 복잡도입니다. Dynamic Workers는 이 네 차원 모두에 답을 제시합니다. 남은 일은 당신의 시나리오와 맞는지 판단하는 것입니다.