프로덕션 에이전트를 위한 CubeSandbox vs E2B 비교

저는 Dora입니다. 최근에 저희 팀은 프로덕션에서 툴 호출을 수행하는 에이전트를 운영하고 있었습니다. 오케스트레이터는 문제없었습니다. LLM도 문제없었습니다. 병목 지점은 샌드박스 레이어였습니다 — 에이전트가 생성된 코드 조각을 실행할 때마다 200ms의 콜드 스타트 비용이 발생했고, 때로는 더 오래 걸리거나 큐가 들쭉날쭉했습니다. 세션당 약 40번의 툴 호출을 고려하면, 이는 전체 실행 시간에서 상당한 부분을 차지합니다.

그래서 저는 대안을 찾아보기 시작했습니다. 요즘 많은 사람들이 비교하는 것이 바로 CubeSandbox vs E2B입니다. 이 글은 두 프로젝트를 2주 동안 살펴보고, 하나는 직접 배포해보고, 다른 하나는 배포하지 못했던 경험(나중에 설명하겠습니다) 이후에 정리한 내용입니다.

먼저 미리 밝혀둡니다: 저는 두 프로젝트 모두와 상업적 관계가 없습니다. 둘 다 오픈 소스입니다. 아래 내용은 호스팅 vs 셀프 호스팅 간의 트레이드오프를 다루는 것이지, “좋은 편 / 나쁜 편”을 가리는 게 아닙니다.

CubeSandbox vs E2B 한눈에 보기

두 프로젝트는 거의 동일한 방식으로 동일한 문제를 해결합니다: 마이크로VM을 실행하고, 신뢰할 수 없는 코드를 실행한 후, 종료합니다. 두 프로젝트 모두 비슷한 범위의 성능 수치를 공개하고 있습니다. 실제 차이는 제품 형태에 있습니다.

CubeSandbox는 Tencent Cloud에서 2026년 4월 Apache 2.0 라이선스로 출시한 오픈 소스 샌드박스-as-a-서비스 스택입니다. RustVMM과 KVM을 기반으로 구축되었습니다. 저장소에 공개된 주요 수치: 60ms 미만의 콜드 스타트, 샌드박스당 약 5MB 메모리, 네이티브 E2B SDK 호환성(환경 변수 URL 하나만 교체). 단순한 라이브러리가 아닌 완전한 셀프 호스팅 스택으로 배포됩니다.

E2B도 오픈 소스(Apache 2.0)이며, Firecracker 마이크로VM을 기반으로 구축되었습니다. 2023년에 설립되었습니다. 사전 웜업된 스냅샷 풀을 사용하여 샌드박스 초기화 시간은 약 150–200ms입니다. Terraform 스크립트를 통한 셀프 호스팅도 가능하지만, 주요 배포 방식은 관리형 클라우드입니다 — Hobby(무료, $100 크레딧), Pro($150/월 + 사용량), Enterprise(BYOC, 온프레미스). 셀프 호스팅 사용자는 소수이며, 호스팅이 기본 방식입니다.

따라서 진짜 축은 “어느 샌드박스가 더 나은가”가 아닙니다. 다음과 같습니다:

기능	CubeSandbox	E2B
라이선스	Apache 2.0	Apache 2.0
주요 방식	셀프 호스팅	호스팅 SaaS (셀프 호스팅 가능)
기반 VMM	RustVMM + KVM	Firecracker (KVM)
공개된 콜드 스타트	`<60ms`	~150–200ms
샌드박스당 메모리	~5MB	~5MB
SDK 호환성	E2B SDK 드롭인	네이티브 E2B SDK
GPU 지원	KVM 지원 x86_64 Linux 필요; 업스트림에서 네이티브 패스스루 없음	동일한 Firecracker GPU 제약
운영 부담	클러스터를 직접 운영	E2B가 클러스터 운영 (관리형)

위 수치는 제가 실행한 벤치마크가 아닌 각 프로젝트의 저장소 및 릴리즈 노트에서 가져온 것입니다. 벤더가 공개한 수치로 방향성 참고용으로만 활용하고, 직접 테스트를 대체하지 않습니다.

호스팅 vs 셀프 호스팅 트레이드오프

이것이 실질적인 결정이며, 대부분 기술적인 문제가 아닙니다.

E2B로 호스팅을 선택하면 마이크로VM 커널, 스냅샷 풀, KVM 호스트, 오케스트레이터 페일오버에 대해 고민할 필요가 없습니다. 비용 최적화에 대해서도 생각할 필요가 없는데, 요금이 고정되어 있기 때문입니다. 제가 속했던 팀은 2주 동안 E2B Pro를 사용해봤는데 — 통합이 실제로 한 시간 정도면 충분하고, SDK가 깔끔하며, 절약되는 엔지니어링 시간이 실질적입니다.

CubeSandbox로 셀프 호스팅을 선택하면 서버를 직접 소유하게 됩니다. 비용이 “사용량 곡선에 따른 비용”이 아닌 “기본 서버 비용”이 됩니다. 데이터가 내부 경계를 벗어나지 않으므로 컴플라이언스가 쉬워집니다. 하지만 온콜 로테이션, 커널 업데이트, eBPF 정책 튜닝도 직접 관리해야 합니다. CubeSandbox는 단일 노드 및 클러스터 설정을 위한 원클릭 배포를 제공하는데 도움이 되지만, “원클릭 배포”와 “프로덕션 준비된 클러스터”는 같은 말이 아닙니다.

며칠간 여기서 멈췄는데, 정답이 팀의 구성에 따라 크게 달라지기 때문입니다. 다음 분기에 에이전트를 출시하는 4인 스타트업은 아마도 자체 마이크로VM 플리트를 운영해서는 안 됩니다. 인프라 엔지니어가 있고 컴플라이언스 제약이 있는 팀은 아마도 직접 운영해야 합니다.

호환성 및 마이그레이션 관련 사항

CubeSandbox E2B 호환성 이야기는 CubeSandbox 릴리즈에서 가장 흥미로운 기술적 주장입니다. 문서에 따르면, 기존 E2B 기반 에이전트는 환경 변수 하나만 교체하면 셀프 호스팅된 CubeSandbox 클러스터로 트래픽을 라우팅할 수 있습니다 — 코드 변경 없이. 저는 직접 프로덕션 E2B 워크로드를 마이그레이션해본 적이 없어서 지금은 이 주장을 믿고 있지만, 양쪽이 수락하는 SDK 호출을 살펴보면 검증 가능합니다. 표면적은 작습니다. 둘 다 동일한 샌드박스 생명주기를 사용합니다: 생성, 명령 실행, 코드 실행, 종료.

이 부분이 유용한 이유는: CubeSandbox가 본질적으로 E2B SDK를 위한 자체 인프라 백엔드임을 의미합니다. E2B의 호스팅 클라우드에서 개발하다가, 사용량이 정당화되면 자체 클러스터로 재연결할 수 있습니다. 양쪽 모두에 대한 락인 주장이 약해지는데 — 이것이 이 카테고리에 건전한 현상이라고 생각합니다.

CubeSandbox가 우세한 부분

제어권, 비용 구조, 인프라 소유권

관리형 샌드박스 요금이 월 청구서에 나타나기 시작할 만큼 충분한 볼륨을 처리하는 에이전트 팀에게는 CubeSandbox가 더 솔직한 선택입니다. 이미 이해하고 있는 하드웨어에 대한 비용을 지불하는 것입니다. CubeVS를 통한 eBPF 기반 이그레스 필터링은 커널 수준에서 구성할 수 있습니다. 데이터 레지던시 규칙이 “VPC를 벗어나면 안 된다”고 명시한다면, 셀프 호스팅 샌드박스와는 30초짜리 대화로 끝나고 관리형 샌드박스와는 훨씬 긴 대화가 필요합니다.

충분히 언급되지 않는 점: 셀프 호스팅 에이전트 런타임은 공짜 점심이 아닙니다. 실행당 한계 비용은 낮아지지만, 고정 비용은 올라갑니다. 손익분기점은 팀의 사용량 곡선마다 다릅니다. 결정 전에 계산해보세요. 만약 결과가 “월 $300 절약, 주당 2시간의 운영 작업 추가”라면, 그것은 이익이 아닙니다.

팀이 테스트해야 할 성능 및 밀도 주장

CubeSandbox는 60ms 미만의 콜드 스타트를 공개하고 있으며, HPCwire를 통한 Tencent Cloud 릴리즈 노트에서는 이를 “업계 평균(150ms)의 3분의 1”이라고 설명합니다. 또한 단일 물리 머신에서 2,000개 이상의 샌드박스를 실행할 수 있다고 주장합니다. 이 수치는 합성 벤치마크가 아닌 Tencent Cloud 내부의 프로덕션 워크로드에서 나온 것으로 — 합성 벤치마크보다는 낫지만, 여전히 그들의 워크로드이지 여러분의 워크로드가 아닙니다.

헤드라인 수치를 믿기 전에 테스트해야 할 것들:

실제 스냅샷 크기에서의 콜드 스타트 (5GB 템플릿은 200MB짜리와 다르게 동작합니다)
평균이 아닌 p99에서의 동시성 동작 — CubeSandbox는 50 동시 요청에서 67ms 평균 응답을 공개하는데, 이는 고무적이지만 p99와 같지 않습니다
특정 의존성이 RustVMM의 축소된 커널에서 예상치 못한 문제 없이 작동하는지 여부

여기서 제 데이터는 끝납니다. KVM이 지원되는 단일 VM에서 CubeSandbox를 배포하여 반나절 만에 샌드박스를 서비스하게 했습니다. 릴리즈에 나온 밀도 수치로는 스트레스 테스트를 해보지 못했습니다. 프로젝트가 공개된 지 3주 만에 그런 테스트를 해봤다고 말하는 사람은 아마 과장하고 있을 것입니다.

E2B가 여전히 우세한 부분

CubeSandbox vs E2B 그림의 나머지 절반: 인프라에 대해 고민하고 싶지 않다면 E2B가 이깁니다. 이 말이 무시하는 것처럼 들릴 수 있지만, 이것이 실제 결론입니다.

구체적으로:

호스팅된 E2B SDK가 더 성숙합니다. 더 많은 쿡북 예시, 더 많은 LangChain/LlamaIndex 통합, 더 긴 실적이 있습니다.
Manus, Perplexity의 코드 분석, Hugging Face의 Open R1 — 규모에 맞는 프로덕션 레퍼런스가 존재합니다. CubeSandbox는 Tencent Cloud 내부에 프로덕션 레퍼런스가 있는데, 이는 실질적이지만 외부 케이스 스터디는 아직 작성 중입니다.
E2B 문서는 데스크톱 샌드박스, Dockerfile 기반 템플릿, 파일 지속성, 24시간 세션 수명을 기본으로 다룹니다. CubeSandbox는 더 간략합니다 — README와 예시들은 핵심 생명주기를 다루지만 세부적인 내용은 부족합니다.
Firecracker 자체는 검증된 기술입니다. AWS Lambda가 이를 기반으로 실행됩니다. Firecracker 프로젝트는 2018년부터 프로덕션에서 사용되어 왔습니다. CubeSandbox의 RustVMM 기반 스택은 Tencent 내부에서는 한동안 운영되었지만, 공개적으로는 더 새로운 기술입니다.

다음 분기에 v1 에이전트 제품을 출시하는데 인프라 담당자가 없다면, E2B 호스팅 플랜이 마찰이 적은 경로입니다. 샌드박스 클러스터와 씨름하지 않아도 되는 시간은 에이전트 자체에 투자할 수 있는 시간입니다. 많은 팀에게 그것이 월 $150의 가치가 있습니다.

에이전트 팀을 위한 의사결정 프레임워크

2주간의 조사 후, 제가 실제로 사용할 프레임워크입니다. 이것이 제가 발견한 가장 유용한 AI 에이전트 샌드박스 비교 기준 중 하나입니다:

월 샌드박스 사용량 약 50k 시간 미만, 컴플라이언스 제약 없음, 인프라 팀 없음 → E2B 호스팅. 더 읽을 필요 없습니다.
그 이상의 볼륨, 엄격한 데이터 레지던시, 또는 이미 Kubernetes/마이크로VM을 운영 중 → CubeSandbox 셀프 호스팅. 경제성이 뒤집히고 운영할 역량이 있습니다.
그 중간 어딘가 → E2B 호스팅으로 시작하세요. SDK로 개발하고, 청구서가 부담되거나 컴플라이언스 문제가 생기면 SDK 호환성 덕분에 마이그레이션이 URL 하나 바꾸는 것으로 가능합니다. 이 유연성이 이번 비교에서 가장 과소평가된 특성입니다.
샌드박스 내부의 에이전트 추론을 위한 GPU 패스스루가 필요 → 두 옵션 모두 좋지 않습니다. 업스트림 Firecracker는 GPU 패스스루를 기본으로 지원하지 않고, CubeSandbox도 비슷한 제약이 있습니다. 해당 워크로드에는 gVisor나 Daytona를 살펴보세요.

제가 경계할 프레이밍: “CubeSandbox가 더 나은 기술이므로 이긴다.” 마이크로VM 샌드박스 선택은 제품 형태의 선택입니다. 공개된 사양에서 기술은 대략 동등합니다. 일상적인 비용은 운영에 관한 것입니다.

FAQ

CubeSandbox vs E2B 평가를 진행하는 동안 팀원들로부터 계속 받았던 질문들입니다.

CubeSandbox는 E2B의 드롭인 교체품인가요?

E2B SDK 표면에 대해서는, 맞습니다 — 설계상으로 그렇습니다. 이 프로젝트는 환경 변수를 교체하는 E2B 호환 런타임으로 자신을 마케팅합니다. 핵심 샌드박스 생명주기를 넘어선 기능들(Dockerfile 기반 템플릿, 데스크톱 샌드박스, 호스팅된 옵저버빌리티)에 대해서는 “아직 아닙니다”가 답입니다.

셀프 호스팅은 실제로 작업량을 얼마나 늘리나요?

KVM 지원 호스트(또는 플리트), 커널/이미지 관리, 모니터링, 스냅샷 풀 튜닝, 네트워크 이그레스 정책, 온콜이 추가됩니다. Tencent Cloud의 릴리즈는 단일 노드 및 클러스터 설정을 위한 “원클릭 배포”를 설명하지만, 이것을 프로덕션급 클러스터와 동일시하는 것은 낙관적입니다. 1–2주의 설정 기간과 누군가의 정기적인 소량의 관심이 필요합니다.

어떤 워크로드가 마이크로VM 샌드박스에서 가장 큰 혜택을 받나요?

모델이 생성한 코드를 신뢰할 수 없는 입력에 대해 규모 있게 실행하는 모든 경우입니다. 일반 Docker의 공유 커널 리스크는 컨테이너를 사용하지 말아야 하는 표준적인 논거입니다 — 모든 주요 에이전트 플랫폼이 이러한 이유로 공유 커널 격리에서 벗어났습니다. 에이전트가 신뢰할 수 있는 스크립트의 고정된 허용 목록에서만 샌드박스된 코드를 실행한다면, 마이크로VM이 전혀 필요하지 않을 수도 있습니다.

팀이 먼저 벤치마크해야 할 것은 무엇인가요?

다음 세 가지를 이 순서로: 실제 템플릿 크기에서의 p99 콜드 스타트; 셀프 호스팅의 경우 하드웨어 달러당, 호스팅의 경우 청구서 달러당 샌드박스 밀도; 버스트 부하에서의 실패 모드. 헤드라인 수치인 60ms 미만 vs 약 150ms는 실제이지만, 벤더에 유리한 조건에서의 평균을 설명합니다. 여러분의 워크로드는 어느 벤더의 것과도 일치하지 않을 것인데, 그것이 벤치마크를 해야 하는 유일한 이유입니다.

결론

CubeSandbox vs E2B 논쟁은 실제로 존재하지만 약간 잘못된 프레이밍입니다. “기술적으로 어느 샌드박스가 우월한가”의 문제가 아닙니다. 둘 다 하드웨어 수준의 격리를 사용하고, 둘 다 신뢰할 수 있는 성능 수치를 공개하며, 둘 다 Apache 2.0이고, 둘 다 동일한 SDK를 사용합니다. 결정은: 다른 사람이 인프라를 운영하기를 원하는가, 아니면 직접 운영하기를 원하는가입니다.

이는 엔지니어링 문제가 아닌 제품 문제입니다. 대부분의 팀에게 솔직한 답은 “호스팅으로 시작하고, 마이그레이션 비용을 낮게 유지하라”입니다. 두 프로젝트 간의 SDK 호환성이 이번 릴리즈에서 가장 유용한 점입니다 — 에이전트 인프라의 모든 참여자에게 락인 비용이 줄어들었음을 의미합니다.

실제 부하로 CubeSandbox를 테스트한 후 더 많은 내용을 공유하겠습니다. 두 프로젝트 모두 빠르게 업데이트되고 있어 — 이 비교는 기반 기술만큼 오래 유효하지 않을 것입니다.

이전 글: