본문으로 건너뛰기
고급

에이전트 런타임: 아이솔레이트 vs 컨테이너

진지하게 만드는 모든 에이전트는 어딘가에서 실제로 뭔가를 해야 합니다: 파일을 읽고, 셸 명령을 실행하고, 패키지를 설치하고, 방금 작성한 스크립트를 실행하죠. 2025년 대부분의 기간 동안 모두가 선택한 답은 "컨테이너를 줘라"였습니다 — Docker 이미지, 아니면 더 나은 온디맨드로 부팅되는 Firecracker 마이크로VM 말이죠. 그 답은 통합니다. 다만 액션당 비용이 비싸고 시작이 느리며, 규모가 커져서 모든 사용자의 모든 에이전트에게 각자의 환경을 주려고 하는 순간 통하지 않게 됩니다.

2026년 8월 3일, Cloudflare는 @cloudflare/computer라는 얼리 프리뷰 패키지를 출시하며 기본값이 잘못됐다고 주장했습니다. 이 회사의 주장은, 에이전트가 실제로 시간을 쓰는 일 — ls, cat, sed, git status, npm install, 작은 셸 스크립트, 아주 작은 JS 변환 — 을 보면 V8 아이솔레이트가 단일 자릿수 밀리초 안에 훨씬 저렴한 비용으로 그 작업을 수행하며, 작업이 진정으로 요구할 때에만 전체 리눅스 컨테이너를 띄우면 된다는 것입니다. 그들의 표현으로는, 컨테이너는 "에이전트 작업의 10% 미만"을 처리해야 합니다.

이 페이지는 Cloudflare 광고가 아닙니다. 90/10 프레이밍은 벤치마크가 아니라 베팅입니다. 하지만 이는 2026년의 모든 에이전트 인프라 벤더 사이에서 벌어지고 있는 실제 변화의 가장 뾰족한 사례이고, 그 트레이드오프를 이해하는 것은 이제 에이전트 제품을 만드는 누구에게든 기본 요건이 되었습니다.

What you'll learn
  • 세 가지 실제 격리 프리미티브(V8 아이솔레이트, 컨테이너, Firecracker 마이크로VM)와 각각이 시작 시간, 메모리, 폭발 반경 측면에서 실제로 얼마나 드는지
  • @cloudflare/computer의 90/10 가설, 그리고 왜 그 설계가 아이솔레이트 런타임과 이스케이프-해치 컨테이너를 짝지어 놓았는지
  • Cloudflare Sandboxes(2026년 4월 13일 GA)와 @cloudflare/computer(2026년 8월 3일 프리뷰)가 어떻게 다른지 — 같은 회사, 다른 제품
  • 진영 구도: Firecracker 기반 E2B, gVisor 기반 Modal, 컨테이너 기반 Daytona/E2B/Cloudflare — 누가 무엇에 왜 베팅하는가
  • 구체적 결정 프레임워크: 언제 에이전트에 마이크로VM이 필요한지, 언제 컨테이너로 충분한지, 언제 아이솔레이트가 정답인지

실제로 여러분이 가진 세 가지 프리미티브​

잠시 마케팅 이름은 무시합시다. 오늘날 시장에 나온 모든 에이전트 샌드박스 밑에는 세 가지 격리 기술 중 하나가 있으며, 각각은 매우 다른 비용 곡선을 가집니다.

Guided walkthrough1 of 3
  1. 단일 V8 프로세스 내부의 JavaScript 실행 컨텍스트입니다. 시작 시간은 낮은 단일 자릿수 밀리초, 메모리 오버헤드는 수십 킬로바이트, 하나의 프로세스에서 수천 개가 공존할 수 있습니다. Cloudflare Workers, Deno Deploy, Vercel Edge가 사용합니다. 임의의 리눅스 바이너리는 실행할 수 없습니다 — 코드는 아이솔레이트에서 도달할 수 있는 JavaScript(또는 WASM)여야 합니다. 격리는 언어-런타임 수준입니다: 같은 프로세스 내의 아이솔레이트 간에는 커널 경계가 없습니다.

옆에 붙어 있는 두 기술도 꽤 자주 등장하니 이름을 붙일 만합니다:

  • gVisor(Google Cloud Run과 Modal이 사용)는 Go로 작성된 유저스페이스 커널로, 컨테이너의 syscall을 가로채 안전하게 재구현합니다. 시작은 컨테이너만큼 빠르고, 격리는 벌거벗은 컨테이너보다 강하지만 하이퍼바이저만큼 강하지는 않습니다. Modal은 2024년에 자기네 스택 전체를 여기에 걸었습니다.
  • WASM 샌드박스(Fastly Compute, WasmEdge)는 아이솔레이트와 비슷한 모양이지만 JavaScript가 아닌 컴파일된 WebAssembly를 위한 것입니다. 비용 프로파일은 V8 아이솔레이트와 같으며 언어 생태계가 다릅니다.

경험칙: 아이솔레이트 → 컨테이너 → gVisor → 마이크로VM은 더 강한 격리와 더 높은 시작 비용의 사다리입니다. 모든 에이전트 런타임은 한 단을 고르거나 — 그리고 이것이 Cloudflare의 새로운 수인데 — 두 단을 짝지어 런타임에 라우팅합니다.

90/10 가설​

에이전트가 세션 안에서 하는 일을 봅시다. 전형적인 코딩 에이전트의 한 턴은 대략 이런 식입니다: ls, 파일 두 개 cat, 포매터 실행, 파일 하나 편집, git diff, git commit. 그 어떤 것도 새 리눅스 커널이 필요하지 않습니다. 파이썬조차 필요하지 않죠. 대부분은 작은 가상 파일시스템에서 바이트-인-바이트-아웃입니다.

이제 나머지 10%를 봅시다: 전체 테스트 스위트 실행, npm install, 비디오 트랜스코딩, 헤드리스 크롬 부팅. 그 작업은 진정으로 리눅스 유저랜드가 필요합니다. 진짜 커널의 혜택을 받죠. 그게 비싸도 괜찮습니다 — 심지어 좋습니다 — 왜냐하면 드물게 일어나니까요.

Cloudflare의 논지는, 모든 에이전트를 마이크로VM에 배치하면 cat과 grep인 90%의 작업에 대해서도 마이크로VM 가격을 지불한다는 것입니다. @cloudflare/computer로 그들이 내건 베팅은 똑똑한 런타임이 다음과 같이 해야 한다는 것입니다:

  1. 기본은 아이솔레이트로. 셸 명령은 bash 모양의 아이솔레이트("just-bash"가 Dynamic Worker 내부에서 실행)에서 돌고, JavaScript 모듈은 구조화된 I/O를 가진 신선한 아이솔레이트에서 돕니다.
  2. 작업이 진정으로 요구하는 순간 컨테이너로 넘어갑니다 — 임의 바이너리, 네이티브 의존성, 지속적 CPU.
  3. 워크스페이스 상태를 한 곳에 유지합니다 — 양쪽 세계에서 읽기/쓰기 가능한 SQLite 기반 가상 파일시스템 — 그래서 작업이 아이솔레이트와 컨테이너 사이를 오갈 때 파일을 다시 업로드하거나 컨텍스트를 잃지 않습니다.

디스패치는 자동적이어야 한다는 게 발표문의 표현입니다("프론티어 모델들은 올바른 결정을 내리는 데 매우 능숙합니다"), 아이솔레이트 쪽은 just-bash와 Dynamic Workers가, 컨테이너 쪽은 computerd라는 작은 데몬이 처리해 워크스페이스를 FUSE 마운트하고 변경사항을 capnweb RPC로 다시 동기화합니다. 여러분 코드에서는 단일 Workspace 객체를 만지고, 특정 exec가 실제로 어디서 실행됐는지는 구현 세부사항입니다.

기대야 할 주장은 구체적인 디스패치 로직 — 이건 진화할 것 — 이 아니라 구조적 논점입니다: 에이전트 전체에 대해 하나의 격리 프리미티브를 고르면 한 축에서 과다 지불하게 됩니다. 라우팅하는 런타임은 저렴해도 안전한 곳에서는 저렴하고, 강력함이 필요한 곳에서는 강력합니다.

반대 베팅: 처음부터 끝까지 마이크로VM​

모두가 동의하지는 않습니다. 2026년의 진영은 에이전트가 실제로 얼마나 많은 격리가 필요한지에 대해 실제 이견을 가집니다.

  • E2B는 자기네 제품 전체를 Firecracker 마이크로VM 위에 지었습니다 — AWS Lambda가 쓰는 그 기술 — 그리고 웜 리전 샌드박스에 대해 200ms 이하의 시작을, 최대 24시간의 세션을, 계정당 수천 개의 동시 VM을 공표합니다. 그들의 세일즈 포인트는 정확히 Cloudflare의 반대입니다: 모든 세션에 진짜 커널을 주라, 왜냐하면 에이전트가 뭘 시도할지 모르고, 리눅스 VM 경계가 보안 리뷰에 증명해 보일 수 있는 유일한 격리이기 때문입니다.
  • Vercel Sandboxes도 Vercel 관리 풀을 통해 Firecracker 위에서 돌아갑니다.
  • Modal은 gVisor에 걸었습니다: 컨테이너만큼 빠른 시작, syscall 가로채기 격리. 하이퍼바이저보다 약하지만 벌거벗은 컨테이너보다 강하고, Firecracker보다 저렴합니다.
  • Daytona와 전통적 개발 컨테이너 플랫폼들은 에이전트에게 진짜 컨테이너를 건네줍니다. 에이전트 워크로드가 인간 개발자 워크로드에 충분히 가까워서 같은 프리미티브가 맞는다는 이론입니다.

이 이견은 무시할 수 없습니다. Cloudflare는 의도적으로 에이전트 셸의 대부분을 공유 V8 프로세스에서 돌립니다 — V8 제로데이를 가진 결심한 공격자가 넘을 수 있는 경계죠. E2B와 Vercel은 에이전트가 작성하는 어떤 코드든 기본적으로 신뢰할 수 없는 것으로 취급해야 한다고 주장하며, 이는 마이크로VM을 강제합니다.

두 입장 모두 방어할 만합니다. 올바른 선택은 에이전트가 실행할 코드를 누가 소유하느냐에 달려 있습니다. 에이전트가 여러분 자신의 리뷰된 코드를 여러분 자신의 데이터에 대해 실행한다면, Cloudflare의 아이솔레이트-우선 베팅은 같은 실용적 안전성에 대해 엄청나게 저렴합니다. 에이전트가 오픈 PR, GitHub 이슈, 최종 사용자 프롬프트에서 나온 코드 — 신뢰할 수 없는 어떤 것 — 를 실행한다면, 아마 그것과 다른 모든 것 사이에 커널 경계를 원할 테고, 마이크로VM 비용을 지불해야 합니다.

Cloudflare의 두 제품, 나란히​

이번 달 단연 가장 흔한 혼동은 Cloudflare의 두 에이전트 인프라 제품 사이입니다. 넉 달 간격으로 출시되었고, 같은 브랜드 아래에 있으며, 관련되었지만 다른 문제를 해결합니다.

Cloudflare Sandboxes@cloudflare/computer
상태GA(2026년 4월 13일)얼리 프리뷰(2026년 8월 3일)
격리명명된 세션당 컨테이너기본은 아이솔레이트, 필요시 컨테이너
파일시스템네이티브 컨테이너 FS, inotify로 감시, R2에 스냅샷SQLite 기반 가상 FS, 컨테이너에 FUSE 마운트
시작콜드 클론-앤-인스톨 약 30초, 스냅샷 복원 약 2초(15배 빠름)아이솔레이트: 단일 자릿수 ms, 컨테이너: 초 단위
최적 용도오래 실행되는 개발-서버 스타일 세션, 파이썬 상태를 유지하는 코드 인터프리터짧고 급격하며 대부분 셸인 에이전트 턴, 가끔의 무거운 작업
가격활성 CPU 사이클(실행 중일 때만 과금)아직 미공개

멘탈 모델: Sandboxes는 하나의 에이전트에 하나의 완전한 컴퓨터를 준다, Computer는 하나의 에이전트에 각 액션에 대해 올바른 컴퓨트를 고르는 라우팅 레이어를 준다. 공존할 수 있습니다 — Computer의 컨테이너 백엔드는 후드 아래에서 Sandboxes 스타일 인프라를 사용할 수 있고 실제로 사용합니다 — 하지만 같은 제품은 아닙니다.

각 프리미티브가 정답일 때​

좋아하는 걸 고르지 말고, 여러분 에이전트 작업의 실제 모양을 사용하세요.

Guided walkthrough1 of 5
  1. 신뢰할 수 있는 운영자, 신뢰할 수 있는 데이터, 대부분 제한된 셸 작업. 아이솔레이트-우선(Cloudflare Computer 또는 Workers 위에 손수 만든 것) 혹은 gVisor(Modal)가 잘 맞습니다. 시작 시간과 작업당 비용의 절감은 에이전트 규모에서 빠르게 누적됩니다 — 에이전트가 시간당 수천 개를 돌릴 때는 모든 `ls`가 중요합니다.

최소한의 @cloudflare/computer 예제​

구체적으로 아이솔레이트-우선 워크스페이스는 이렇게 생겼습니다. 객체 하나를 받고, 특정 exec가 어디서 실행되는지는 말하지 않습니다.

워크스페이스를 만들고 셸 명령을 실행

import { Workspace } from "@cloudflare/computer";

const ws = new Workspace();

// Isolate-backed by default: fast, cheap.
await ws.write("hello.txt", "hi\n");
const out = await ws.runtime.exec("cat hello.txt && ls -la");

console.log(out.stdout);

아이솔레이트가 부족할 때 전체 리눅스 컨테이너를 강제

// npm install needs a real userland — pick the container backend explicitly.
await ws.runtime.exec("npm install lodash", { backend: "container" });

실제 어딘가에 연결하기 전에 발표와 변경 로그를 읽으세요 — 정확한 백엔드 이름, 라우팅 기본값, 인증 모델은 모두 패키지가 프리뷰를 벗어나기 전에 바뀔 수 있습니다.

이 모든 것에 관해 사람들을 정말로 놀라게 하는 것​

세 가지가 에이전트 런타임 위에서 처음 뭔가를 만들 때 팀들을 확실히 방심하게 만듭니다.

  • 샌드박스의 첫 명령까지의 시간이 짧은 에이전트를 지배합니다. 여러분 에이전트의 턴이 "셸 명령 하나 실행"이라면, 200ms의 마이크로VM 시작과 5ms의 명령은 40배 오버헤드입니다. 사용자당 하루에 수천 턴을 곱하면 런타임 청구서가 모델보다 앞서는 가장 큰 라인 아이템이 됩니다.
  • 상태 이식성은 순수한 속도보다 값어치가 있습니다. Cloudflare Sandboxes의 2초 스냅샷 복원과 @cloudflare/computer의 단일-워크스페이스-멀티-백엔드 모델은 같은 논리를 이깁니다: 상태를 다시 짓는 것보다 상태를 옮기는 것이 저렴합니다.
  • 격리는 기술적 질문이 아니라 법적 질문입니다. 올바른 프리미티브는 여러분의 컴플라이언스 표면이 무엇을 받아들이느냐에 달려 있습니다. 마이크로VM은 감사관에게 아이솔레이트보다 방어하기 쉽습니다. 아이솔레이트가 여러분 워크로드에 진정으로 더 안전한 경우에도 말이죠.

AILmanac의 관련 읽을거리​

Check yourself

0/5
  1. Cloudflare가 명시한 설계 목표상, @cloudflare/computer에서 에이전트 작업의 어느 정도 비율이 전체 컨테이너 백엔드를 필요로 해야 합니까?
  2. E2B는 각 샌드박스에 어떤 격리 기술을 사용합니까?
  3. Cloudflare Sandboxes가 2026년 4월 13일 GA로 갔을 때, 그들은 한 특정 작업에서 대략 15배 스피드업을 보여줬습니다. 어떤 것이었습니까?
  4. 오픈 사용자 제출 코드(예: GitHub 이슈나 사용자 프롬프트에서 나온)를 실행하는 에이전트에 가장 잘 맞는 짝은?
  5. @cloudflare/computer에서 아이솔레이트 exec와 컨테이너 exec 사이에 워크스페이스 상태가 어떻게 일관되게 유지됩니까?

출처 및 참고자료​