AI 에이전트를 위한 CubeSandbox란 무엇인가?

지난주 몇 개의 저녁을 CubeSandbox 레포지토리를 읽는 데 보냈다. 프로덕션에서 실행한 건 아니다 — 이 프로젝트는 4월 21일에야 공개됐고, 툴에 대한 판단은 보통 더 많은 런타임이 필요하다. 하지만 아키텍처 결정들이 에이전트 인프라에 대해 무엇을 시사하는지 적어둘 만큼 흥미롭다. 뉴스 사이클이 프레이밍을 가져가기 전에.

신뢰할 수 없는 코드를 실행하는 에이전트를 만든다면 — 코드 해석, 브라우저 자동화, RL 학습, 또는 모델이 무엇을 실행할지 결정하는 “사고 → 실행 → 피드백” 루프 — 샌드박스 인프라는 부차적인 문제가 아니다. 부하 아래에서 가장 먼저 망가지는 것이다. CubeSandbox는 그에 대한 하나의 답이다. 이 글은 그것이 무엇인지, 설계 선택이 왜 중요한지, 어떤 팀이 평가해야 하는지에 대한 것이다. 전환해야 하는지에 대한 글이 아니다.

CubeSandbox란 무엇이며 Tencent가 오픈소스로 공개한 것

핵심 아키텍처와 포지셔닝

CubeSandbox는 2026년 4월 21일 Tencent Cloud가 Apache 2.0 라이선스로 공개한 AI 에이전트용 오픈소스 샌드박스 서비스다. GitHub 레포지토리에는 풀 스택이 포함되어 있다: API 게이트웨이, 오케스트레이터, 노드별 에이전트, 네트워킹 레이어, 하이퍼바이저. SDK가 아니고, 호스팅 서비스의 래퍼도 아니다. 직접 배포하는 것이다.

README에서 직접 가져온 기술적 주장들:

완전히 서비스 가능한 샌드박스의 콜드 스타트 60ms 미만.
인스턴스당 메모리 오버헤드 5MB 미만.
96코어 서버에서 ~2,000개의 동시 샌드박스.
RustVMM + KVM을 통한 하드웨어 레벨 격리, 각 샌드박스가 자체 게스트 커널 보유.
E2B SDK 프로토콜 호환성 — 환경 변수 하나만 바꿔서 마이그레이션.

코드베이스는 대략 절반이 Rust이고, 지원 레이어에 Go와 C가 있다. 아키텍처 개요 문서는 CubeAPI(E2B 호환 REST 게이트웨이), CubeMaster(클러스터 오케스트레이터), CubeProxy(요청 라우터), Cubelet(노드별 생명주기 관리자), CubeVS(eBPF 기반 네트워크 격리), CubeHypervisor + CubeShim(가상화 레이어; CubeShim은 containerd의 Shim v2를 구현)으로 나눈다. README는 Cloud Hypervisor, Kata Containers, virtiofsd, containerd-shim-rs 업스트림을 인용한다 — 이 분야에 있는 사람이라면 놀랄 것이 없다.

실용적으로: Firecracker와 같은 아키텍처 계열의 마이크로VM 샌드박스이지만, 별도의 VMM 구현이다. Tencent의 베어메탈 테스트베드 밖에서 구현 품질이 유지되는지는 열린 질문이다. README만으로는 알 수 없다.

E2B 호환성이 중요한 이유

CubeSandbox에서 가장 흥미로운 설계 선택은 60ms 콜드 스타트가 아니다. 의도적인 E2B SDK 호환성이다.

E2B는 에이전트 코드 실행에서 사실상 기본값이 되었다. Manus가 사용한다. 모델이 생성한 코드를 실행해야 하는 LLM 앱들의 긴 꼬리가 먼저 손을 뻗는 곳이다. SDK 프로토콜 — from e2b_code_interpreter import Sandbox, URL을 지정하고 코드를 실행 — 은 이 카테고리에서 사실상의 인터페이스에 가장 가까운 것이다.

그 프로토콜을 미러링함으로써, CubeSandbox는 대부분의 “대안들”이 가진 문제를 우회한다: 개발자들이 새 SDK를 배우도록 하는 것. 마이그레이션 경로는 환경 변수 하나다. 기존 에이전트 코드는 변경되지 않는다. 이미 E2B를 기반으로 구축했다면, CubeSandbox를 테스트하는 마찰은 분기가 아니라 하루 오후 정도다.

레포를 읽으면서 이 부분에서 잠깐 멈췄다. 호환성은 CubeSandbox가 “더 낫다”는 것을 증명하기 위한 것이 아니다. 실험을 저렴하게 만들기 위한 것이다. 그것이 더 현명한 베팅이다.

에이전트 인프라에서 샌드박스가 중요한 이유

격리, 시작 시간, 동시성

샌드박스는 에이전트 시스템을 위해 동시에 세 가지를 한다. 그리고 하나를 희생하면 다른 것들이 손상된다.

격리. 모델이 코드를 생성할 때, 실행하기 전까지는 그것이 무엇을 하는지 알 수 없다. 호스트 커널을 공유하는 컨테이너로는 충분하지 않다. 게스트 커널에 권한 상승 버그가 하나 있거나, 도커 이스케이프가 하나 있으면 에이전트가 호스트 파일시스템, 호스트 자격 증명, 호스트 네트워크에 접근한다. 마이크로VM은 각 샌드박스에 자체 게스트 커널을 제공함으로써 이를 해결한다 — 네임스페이스 경계 대신 하드웨어 가상화 경계다. 이것은 AWS가 Lambda를 위해 Firecracker를 오픈소스화할 때 제기한 것과 같은 주장이다: 컨테이너는 멀티 테넌트 코드 실행을 위해 너무 얇은 벽이다.

시작 시간. “이 Python 스크립트를 실행해서 출력을 확인해야겠다”고 결정하는 에이전트는 밀리초의 벽시계 예산 안에서 그 결정을 내린다. 샌드박스가 시작되는 데 2초가 걸리면, 피드백 루프는 이미 망가진 것이다. 모델이 빨라도 제품이 느려 보인다. Firecracker는 ~125ms 부팅 시간을 달성하여 마이크로VM을 서버리스에서 실행 가능하게 만들었다. E2B의 호스팅 서비스는 사전 워밍 풀로 약 150–200ms를 보고한다. CubeSandbox는 사전 프로비저닝된 리소스 풀과 스냅샷 클로닝을 통해 60ms 미만을 주장한다. 그 수치가 유지된다면, 어떤 종류의 에이전트 루프가 실용적인지가 바뀐다. 인용하기 전에 내 하드웨어에서 직접 검증하겠다.

동시성. 사용자당 하나의 샌드박스는 쉬운 경우다. 에이전트 단계당 하나의 샌드박스, 사용자당, 수천 개의 에이전트가 동시에 실행되는 것이 어려운 경우다. 제약이 “하나가 얼마나 빨리 시작되는가”에서 “한 서버에 몇 개를 실행할 수 있는가”로 이동한다. 5MB-per-instance 수치와 96코어 머신에서 2,000+의 조합이 밀도 논거다. Python 인터프리터, 브라우저, 의존성을 실제로 로드하는 샌드박스라는 현실적인 워크로드에서도 살아남는지는 다시 열린 질문이다.

이 세 가지는 서로 당긴다. 더 강한 격리는 보통 더 무거운 VM, 더 느린 시작, 더 낮은 밀도를 의미한다. 흥미로운 마이크로VM 시스템들은 이 트레이드오프를 거부한다.

규모에서 제품 병목이 되는 이유

단일 사용자 프로토타입의 경우, 이것들은 중요하지 않다. 에이전트 뒤에 도커 컨테이너를 놓고, 보안 부채를 감수하고, 출시한다. 비용은 보이지 않다가 갑자기 보인다.

내가 실제로 목격한 세 지점에서 가시화된다:

단계별 지연. 단일 추론 추적에서 샌드박스를 20번 호출하는 에이전트는 콜드 스타트를 20번 상속한다. 200ms씩이면 사용자가 느끼는 응답 시간에 순수 인프라 지연이 4초 추가된다. 모델은 느려지지 않았다. 인프라가 느려진 것이다.

멀티 테넌트 동시성. 유료 사용자들이 동시에 에이전트를 실행하면, “사용자당 하나의 VM”은 선형적으로 확장되지 않는다. 호스팅 비용이 수익보다 빠르게 증가한다. 커널을 공유하고 격리 위험을 감수하거나, 더 나쁜 마진을 감수한다. 기반 프리미티브를 바꾸는 것 외에는 세 번째 선택지가 없다.

실험-프로덕션 격차. 한 번에 하나의 샌드박스로 로컬에서는 모든 것이 작동한다. 프로덕션에서는 스냅샷 워밍 풀이 유한한 크기를 가진다는 것, 부하 아래에서 콜드 스타트가 돌아온다는 것, 샌드박스가 서로 통신하거나 해서는 안 될 때 중요해지는 eBPF 네트워크 정책에 대해 생각하지 않았다는 것이 드러난다. 이것이 런치 포스트에서 과소평가되는 화려하지 않은 부분이다.

CubeSandbox는 하드웨어 격리, 낮은 메모리 오버헤드, 60ms 미만 시작이 동시에 달성 가능하다는 것에 베팅하고, 프로덕션 팀들이 그 세 가지 벽에 부딪히면 신경 쓸 것이라는 데 베팅한다. 성공 여부는 실행과 채택의 함수다. 둘 다 여전히 열려 있다.

CubeSandbox를 평가해야 하는 팀과 그렇지 않은 팀

진지하게 살펴볼 가치 있는 경우:

비용이나 동시성 한계에 도달해서 어쨌든 자체 호스팅을 고려하고 있는 E2B 사용 팀. 마이그레이션은 진정으로 한 줄 변경이다.
서드파티 클라우드를 배제하는 컴플라이언스 또는 데이터 레지던시 요구사항으로 내부 에이전트 플랫폼을 구축하는 인프라 팀. Apache 2.0 + 자체 호스팅이 전제 조건이다.
콜드 스타트 비용이 내부 훈련 루프에 있는 높은 샌드박스 생성률의 RL 학습 루프를 실행하는 팀. 수백만 에피소드에 곱해진 100ms 개선은 실제 비용이다.
현재 설정이 “하드닝 플래그가 있는 도커 컨테이너”이고 위협 모델이 조용히 그것을 넘어선 팀. 전환의 정직한 순간은 사고 후가 아니라 전이다.

지금은 아마 건너뛰어야 할 경우:

프로토타입과 단일 사용자 데모. 낮은 호출 볼륨에서는 마이크로VM 클러스터를 구성하는 비용이 정당화되지 않는다.
베어메탈 액세스나 KVM 지원 VM이 없는 팀. 하드웨어 요구사항은 실제적이다 — KVM이 있는 x86_64 Linux. 중첩 가상화 없는 표준 클라우드 VM은 기본적으로 자격이 되지 않지만, PVM 경로가 이를 넓힌다.
마이그레이션 비용이 런타임 절감을 초과하는 비E2B SDK에 깊이 묶인 팀. 호환성이 도움이 되지만; 전환 비용을 완전히 없애지는 않는다.

코드와 문서를 읽고 확인할 수 있는 것은 그것이 전부다. 나머지는 프로덕션 런타임이 필요하고, 나는 아직 거기에 배포하지 않았다.

FAQ

CubeSandbox는 어떤 문제를 해결하는가?

호스트 커널을 공유하지 않고, 낮은 지연, 높은 동시성으로, 격리된 환경에서 AI 생성 코드를 실행하기 위한 런타임이다. 타겟으로 하는 문제는 모든 에이전트 플랫폼이 결국 부딪히는 것이다: 컨테이너는 신뢰할 수 없는 코드에 너무 취약하고, 전통적인 VM은 너무 느리고 무거우며, 기존 마이크로VM 옵션들은 독점적이거나 운영상 복잡하다.

컨테이너만 사용하는 방식과 어떻게 다른가?

컨테이너만 사용하는 방식은 호스트 커널을 공유한다. 게스트 커널 익스플로잇이 호스트에 도달한다. CubeSandbox는 KVM 기반 하드웨어 가상화를 통해 각 샌드박스에 자체 게스트 커널을 제공한다 — 무언가 잘못될 때나 사용자가 그렇게 만들려 할 때 LLM이 내보낼 수 있는 코드에 대한 더 강한 경계. 보고된 메모리 오버헤드(인스턴스당 5MB 미만)도 역사적으로 컨테이너 옆에서 VM을 비경제적으로 만든 밀도 격차를 줄인다.

E2B 호환성이 왜 중요한가?

새 샌드박스를 시도하는 비용이 보통 시험 자체가 아니라 마이그레이션 프로젝트이기 때문이다. E2B의 SDK는 채택이 충분해서 호환성을 통해 팀들이 환경 변수 하나를 바꿔서 CubeSandbox를 테스트할 수 있다. 그것이 “다음 분기에 평가하겠다”와 “오늘 밤 실행해보겠다”의 차이다. 프로토콜 선택이 채택에서 무거운 짐을 지고 있다.

어떤 팀이 먼저 테스트해야 하는가?

비사소한 볼륨에서 이미 E2B를 사용하는 팀, 자체 호스팅을 요구하는 컴플라이언스 제약이 있는 팀, 그리고 콜드 스타트 지연이 사용자 대면 응답 시간에 나타나는 타이트한 에이전트 루프를 실행하는 팀. 더 소규모 사용자는 기다릴 수 있다 — 초기 채택은 절감보다 비용이 더 많이 든다.

결론

에이전트 아래의 인프라는 진짜 카테고리가 되고 있다. 2024년 대부분과 2025년으로 이어지면서, 샌드박싱은 부차적인 관심사였다 — 편리한 것으로 처리됐다. 이제 실제 사용자 앞에 에이전트를 배치하는 팀들은 샌드박스 선택이 요청당 지연부터 사용자당 마진까지 모든 것을 형성한다는 것을 발견하고 있다.

CubeSandbox는 기반 물리를 바꾸지 않는다. 마이크로VM은 이미 올바른 아키텍처적 답이었다; 열린 질문들은 항상 구현 품질과 채택 마찰이었다. 이 레포는 첫 번째에 대한 경쟁력 있는 수치를 주장하고, E2B의 프로토콜을 기본적으로 말함으로써 두 번째를 해결한다. 그 수치들이 Tencent의 테스트베드 밖에서 프로덕션 환경에서도 유지되는지가 앞으로 몇 달이 밝혀줄 것이다.

테스트 클러스터에 배포해서 내 워크로드에 대한 콜드 스타트 주장을 확인할 계획이다. 검증 예정. 데이터가 생기면 돌아오겠다.

이전 포스트: