아무도 말하지 않는 문제: 샌드박싱(Sandboxing)은 에이전트형 AI(Agentic AI)의 조용한 병목 현상이었습니다

AI 에이전트에 관한 모든 대화는 모델에 집착합니다. 어떤 LLM이 가장 똑똑한지, 어떤 벤치마크에서 1위를 차지했는지, 어떤 회사가 방금 새로운 추론 업데이트를 출시했는지에 대해 말이죠. 그동안 에이전트가 실제로 실행되는 실행 환경(execution environment)은 거의 주목받지 못하고 있으며, 이러한 침묵은 개발자들에게 실제 비용 손실과 보안 노출이라는 대가를 치르게 하고 있습니다.

에이전트가 단순한 챗봇을 넘어 Python 실행, 셸 명령(shell commands) 생성, 라이브 URL 브라우징, 파일 읽기 및 쓰기 등의 작업을 수행하기 시작하면 문제는 급격히 심각해집니다. 그 시점에서 샌드박스(sandbox)는 있으면 좋은 기능이 아니라, 자율적인 프로세스와 여러분의 프로덕션 인프라 사이의 전체 보안 표면(security surface)이 됩니다.

현재의 솔루션들은 불쾌한 선택을 강요합니다. 컨테이너(Containers)는 빠르게 구동되고 오버헤드(overhead)가 최소화되지만, 호스트 커널(host kernel)을 공유하므로 컨테이너가 침해될 경우 커널 익스플로잇(kernel exploit) 한 번으로 전체 시스템 침해로 이어질 수 있습니다. 완전한 가상 머신(Full virtual machines)은 하이퍼바이저(hypervisor) 수준의 분리를 통해 진정한 하드웨어 격리를 제공하지만, 부팅이 느리고 수십 개의 동시 에이전트를 실행하기에는 경제적으로 가혹할 만큼 많은 메모리를 점유합니다. 단일 노드에서 50개의 동시 에이전트 샌드박스가 필요한 워크플로우는 에이전트 코드를 한 줄도 실행하기 전에 용량 계획(capacity planning)의 악몽이 됩니다.

이것이 바로 CubeSandbox가 직접 겨냥하는 격차입니다. Tencent Cloud가 RustVMM과 KVM을 기반으로 구축한 이 솔루션은 범용 가상화 도구들이 처리하도록 설계되지 않았던 멀티 에이전트 실행 워크로드(multi-agent execution workloads)를 위해 특수 제작되었습니다. CubeSandbox는 인스턴스당 5MB 미만의 메모리 오버헤드로 60밀리초(ms) 이내에 하드웨어적으로 격리된 완전한 작동 샌드박스를 구동합니다. 이러한 수치는 규모가 커질수록 엄청나게 중요해집니다. 메모리 하한선(memory floor) 자체가 단일 노드에서 현실적으로 얼마나 많은 동시 샌드박스 에이전트를 호스팅할 수 있는지를 결정하기 때문입니다.

CubeSandbox는 컨테이너 래퍼(container wrapper)나 재포장된 VM 관리자가 아닙니다. 이는 에이전트형 AI (agentic AI)를 위해 처음부터 설계된 인프라 계층 도구입니다. 즉, LLM 기반 자동화를 구축하는 개발자들에게 실제로 필요한 보안 코드 실행 환경, 격리된 Python 런타임(runtime), 그리고 에이전트 샌드박스(sandbox) 인프라를 제공합니다. 그동안 샌드박싱 병목 현상은 실재해 왔습니다. 이제 이를 해결하기 위한 경제성이 마침내 변화하고 있습니다.

내부 구조: RustVMM과 KVM이 보안을 희생하지 않고 속도를 제공하는 방법

CubeSandbox는 두 가지 기초 기술, 즉 Rust로 작성된 모듈형 가상 머신 모니터(virtual machine monitor) 라이브러리인 RustVMM과 Linux의 네이티브 하이퍼바이저(hypervisor) 인터페이스인 KVM (Kernel-based Virtual Machine) 위에서 작동합니다. 이들은 결합하여 하드웨어 수준의 격리(isolation)를 생성합니다. 각 샌드박스는 Linux 네임스페이스(namespaces)나 컨테이너 cgroups에 의해 강제되는 것이 아니라, 프로세서 자체에 의해 강제되는 고유의 가상화된 CPU 및 메모리 공간을 할당받습니다. 샌드박스 내부에서 실행되는 코드가 AI에 의해 생성되었고 잠재적으로 신뢰할 수 없는 경우, 이러한 차이는 매우 중요합니다.

QEMU와 같은 전통적인 하이퍼바이저는 수년간 축적된 복잡성을 수반합니다. 이러한 복잡성은 메모리, 시작 시간, 그리고 공격 표면(attack surface)의 비용을 발생시킵니다. RustVMM은 가상 머신 모니터를 AI 에이전트 워크로드(workload)에 실제로 필요한 요소로 축소한 다음, KVM이 하드웨어 강제를 처리하도록 합니다. 그 결과, 60밀리초(ms) 미만으로 부팅되고 인스턴스당 5MB 미만의 메모리를 소비하는 샌드박스가 탄생했습니다. 단일 저사양 서버에서도 이러한 오버헤드 프로필 덕분에 수백 개의 동시 격리 환경을 실행하는 것이 경제적으로 실행 가능해졌습니다. 이는 전체 VM 배포나 클라우드 호스팅 샌드박스 API를 사용할 때 대규모 환경에서 비용이 지나치게 높아지는 문제와 대조적입니다.

Rust 기반의 토대(foundation)는 단순히 바이너리 크기를 작게 유지하는 것 이상의 역할을 합니다. Rust의 소유권 모델(ownership model)은 버퍼 오버플로(buffer overflows), use-after-free 오류, dangling pointers 등 메모리 안전성 버그의 전체 클래스를 제거합니다. 이러한 버그들은 역사적으로 가상화 소프트웨어에서 하이퍼바이저 탈출(hypervisor escapes) 및 권한 상승(privilege escalation) 취약점의 원인이 되어 왔습니다. 개발자가 언어 모델(language models)에 의해 생성된 임의의 코드를 실행하기 위해 CubeSandbox를 배포할 때, 이러한 메모리 안전성 보장은 안전하지 않은 코드베이스 위에 적용되는 정책이 아니라 런타임(runtime)의 구조적 속성입니다.

샌드박스당 5MB 미만의 오버헤드(overhead)는 AI 에이전트 파이프라인의 인프라 계산 방식을 바꾸는 밀도(density)를 가능하게 합니다. 파일 조작, API 호출 또는 쉘 명령(shell commands)을 위해 각각 격리된 코드 실행이 필요한 병렬 에이전트들을 실행하는 머신은 더 이상 초 단위 요금을 부과하는 클라우드 샌드박스 서비스를 필요로 하지 않습니다. 경량 VM 설계는 격리(isolation)를 진정성 있게 유지하면서도 높은 동시성(high-concurrency) 워크로드를 셀프 호스팅(self-hostable)할 수 있게 합니다. 이전에는 보안 샌드박스 실행을 관리형 서비스(managed-service)라는 사치로 여겼던 개발자들은 이제 이미 보유하고 있는 하드웨어에서 실행 가능한 아키텍처를 갖게 되었습니다.

E2B 호환성 전략: 전환 장벽 낮추기

CubeSandbox는 에이전트형 AI(agentic AI) 개발자 커뮤니티의 상당수가 이미 기반으로 삼고 있는 샌드박스 API인 E2B SDK와 네이티브 호환성을 제공하며 출시됩니다. 이 단 하나의 결정이 채택의 주요 장애물인 '작동 중인 코드의 재작성'을 제거합니다. E2B의 관리형 서비스를 통해 AI 에이전트를 실행하던 개발자는 기존 SDK 호출을 셀프 호스팅된 CubeSandbox 인스턴스로 지정하기만 하면 그대로 작업을 이어갈 수 있습니다. 새로 배워야 할 추상화(abstractions)도, 리팩터링(refactor)해야 할 에이전트 로직도 없습니다.

Tencent는 이러한 호환성을 의도적으로 구축했습니다. 경쟁 표준을 출시하고 시장이 따르기를 기다리는 대신, CubeSandbox는 이미 모멘텀(momentum)을 확보한 생태계에 스스로를 삽입합니다. 이는 단순한 기술적 편의가 아니라 유통 전략(distribution strategy)입니다. 이 프로젝트는 AI 에이전트를 위한 샌드박스형 코드 실행(sandboxed code execution)의 필요성을 이미 인정하고 있지만, 대규모 운영 시 관리형 서비스(managed-service)의 가격을 지불하고 싶지 않거나 실행 환경의 제어권을 제3자에게 넘기고 싶지 않은 개발자들을 타겟으로 합니다.

실질적인 효과는 CubeSandbox가 관리형 샌드박스 서비스에 대한 즉시 교체 가능한(drop-in) 셀프 호스팅(self-hostable) 대안으로 기능한다는 점입니다. 수백 또는 수천 개의 동시 샌드박스를 실행하는 조직 — 샌드박스당 과금 방식이 빠르게 누적되는 유스케이스(use case) — 은 에이전트가 이미 의존하고 있는 SDK 인터페이스를 희생하지 않으면서도 비용 제어가 가능한 인프라로 가는 경로를 확보하게 됩니다. CubeSandbox는 단일 노드 배포를 지원하며 멀티 노드 클러스터(multi-node clusters)로 확장할 수 있으므로, 팀들이 고정된 용량 한계에 갇히지도 않습니다.

대부분의 보도가 놓치고 있는 점은 SDK 호환성이 경쟁 역학을 완전히 바꾼다는 사실입니다. 이는 CubeSandbox가 표준에 관한 논쟁에서 승리할 필요가 없음을 의미합니다. 대신 실행 비용이 더 저렴하고, 셀프 호스팅이 더 쉬우며, 프로덕션 워크로드(production workloads)를 믿고 맡길 수 있을 만큼 충분히 안전하기만 하면 됩니다. 이러한 관점에서 RustVMM과 KVM을 기반으로 구축되어 5MB 미만의 메모리 오버헤드로 60밀리초(ms) 이내에 생성되는 하드웨어 격리형 샌드박스 환경이라는 이 프로젝트의 사양(specs)은 신뢰할 수 있는 해답을 제시합니다. 안전한 AI 에이전트 실행 환경의 비용 문제로 어려움을 겪던 개발자들은 이제 이론적인 대안이 아닌 구체적인 대안을 갖게 되었습니다.

동시성(Concurrency)과 확장성(Scale): 왜 멀티 노드 스토리가 단일 노드 데모보다 더 중요한가

대부분의 샌드박스 (sandbox) 데모는 한꺼번에 수천 개를 실행하려고 시도하기 전까지는 인상적으로 보입니다. CubeSandbox는 바로 그 스트레스 테스트 (stress test)를 중심으로 설계되었습니다. 시작 단계에 있는 팀들을 위해 단일 노드 (single-node) 배포를 지원하며, 기반 설정을 재설계할 필요 없이 멀티 노드 (multi-node) 클러스터로 수평 확장 (scale horizontally)할 수 있습니다. 이러한 유연성은 프로덕션 (production) 워크로드 (workload)가 도래할 때 조용히 퇴출되는, 개발자 노트북용으로 만들어진 도구들과 CubeSandbox를 차별화하는 요소입니다.

수치들은 멀티 노드 (multi-node) 방식의 신뢰성을 뒷받침합니다. 각 샌드박스는 60ms 미만으로 실행되며 5MB 미만의 메모리 오버헤드 (memory overhead)를 소비합니다. 충분한 자원이 할당된 단일 호스트 (host)에서, 이러한 오버헤드 프로필 (overhead profile)은 유의미한 리소스 제약에 도달하기 전까지 수백 개의 동시 격리 환경 (concurrent isolated environments)을 허용합니다. 클러스터 (cluster) 전체로 확장하면 계산 방식이 극적으로 변합니다. 조직은 샌드박스당 비용이 인프라 지출의 주요 항목이 되지 않으면서도, 대규모의 동시 AI 에이전트 (AI agents) 함대를 운영할 수 있습니다.

이는 본질적으로 병렬적인 워크로드 (workloads)에 가장 중요합니다. 수십 개의 에이전트 동작을 동시에 평가해야 하는 자동화된 테스트 파이프라인 (automated testing pipelines), 하위 에이전트 (subagents)가 생성되어 개별 작업을 완료하고 종료되는 멀티 에이전트 협업 프레임워크 (multi-agent collaboration frameworks), 그리고 독립적인 에이전트들이 동시에 서로 다른 해결 경로를 탐색하는 병렬 연구 워크플로 (parallel research workflows) 등이 그 예입니다. 이 세 가지 경우 모두에서 순차적 실행 (sequential execution)은 병목 현상 (bottleneck)이며, 저렴한 수평 확장 (horizontal scale)이 그 해결책 (unlock)입니다.

이 아키텍처는 에이전트형 AI (agentic AI)가 실제 프로덕션 규모 (production scale)에서 어떻게 배포되는지에 대한 명확한 베팅을 반영합니다. 대부분의 인프라 논의에서 지배적인 사고 모델 (mental model)은 여전히 에이전트를 단일한 장기 실행 프로세스 (long-running processes)로 취급합니다. CubeSandbox의 설계는 그 반대를 가정합니다. 즉, AI 에이전트 실행의 미래는 분산 컴퓨팅 (distributed compute) 전반에 걸쳐 지속적으로 생성되고 종료되는 수명이 짧은 샌드박스 환경 (sandboxed environments)을 갖춘 대규모 병렬 (massively parallel) 구조라는 것입니다. RustVMM 및 KVM을 통한 하드웨어 격리 VM 실행 (Hardware-isolated VM execution)은 해당 모델에 필요한 보안 보장 (security guarantees)을 제공하는 한편, 낮은 메모리 점유율 (low memory footprint)과 100ms 미만의 시작 시간 (startup time)은 경제성을 유지해 줍니다. 자동화된 코드 리뷰, 병렬 데이터 추출, 대규모 테스트와 같은 진지한 에이전트 시스템을 구축하는 팀은 사후에 맞춘 것이 아니라, 처음부터 플릿 규모 (fleet-scale)를 위해 설계된 인프라가 필요합니다.

v0.4와 '더 안전한 이그레스(Safer Egress)' 신호: 보안은 여전히 진행 중인 과제

v0.4 릴리스는 "더 안전한 이그레스(Safer egress), 더 쉬운 운영(easier ops)"라는 헤드라인과 함께 출시되었습니다. 여기서 _safer(더 안전한)_라는 단어는 매우 중요한 역할을 합니다. _safe(안전한)_가 아닙니다. _solved(해결된)_도 아닙니다. _safer(더 안전한)_입니다. 보안이 타협 불가능한 프로덕션 워크로드 (production workloads)를 위해 CubeSandbox를 평가하는 모든 팀에게 이 차이는 매우 중요합니다.

이그레스 제어 (Egress control)는 AI 에이전트 샌드박싱에서 가장 어려운 미해결 과제입니다. RustVMM 및 KVM을 통한 하드웨어 격리는 침해된 에이전트가 VM 경계를 탈출하는 것을 방지하지만, 임의의 외부 네트워크 호출을 여전히 수행할 수 있는 격리된 에이전트는 완전히 다른 차원의 위협입니다. 홈으로 전화를 걸거나 (phones home), 사용자 데이터를 유출하거나, 의도하지 않은 방식으로 외부 API와 상호 작용하는 에이전트는 샌드박스를 탈출하지 않고도 피해를 입힙니다. 컨테이너는 온전하게 유지되지만, 피해는 네트워크 연결을 통해 발생합니다.

v0.4에서 CubeSandbox가 제시한 해답은 자격 증명 금고(credential vault)와 보안 프록시 계층(security proxy layer)입니다. API 키는 샌드박스 내부로 직접 들어가지 않습니다. 에이전트는 평소처럼 외부 호출을 수행하지만, 자격 증명은 프록시 계층에서 주입되어 비밀 정보(secrets)를 실행 환경 외부에 유지합니다. 또한 이 업데이트와 함께 전용 보안 프록시 가이드가 추가되었는데, 이는 이 아키텍처가 단순히 기본 설정으로 배포하는 것이 아니라 의도적인 구성(deliberate configuration)을 필요로 함을 시사합니다.

v0.4에서 보안 프록시 가이드를 작성해야 했다는 사실, 그리고 변경 로그(changelog)가 외부 송출(egress)을 각주가 아닌 주요 기능으로 다루고 있다는 점은 이전 버전의 샌드박스가 네트워크 외부 송출 제어(network egress controls) 측면에서 미흡했음을 확인시켜 줍니다. 이전 버전에서 에이전트 워크로드(agentic workloads)를 실행하던 팀들은 자신들이 완전히 고려하지 못했을 수도 있는 상당한 노출 위험을 감수하고 있었습니다.

적은 예산으로 내부 도구를 구축하는 개발자들에게는 그러한 트레이드오프(tradeoff)가 수용 가능했을지도 모릅니다. 하지만 민감한 데이터를 다루거나, 규제 대상 워크로드, 또는 멀티 테넌트(multi-tenant) 환경을 운영하는 팀에게는 이는 위험 계산(risk calculus)을 크게 변화시킵니다. CubeSandbox는 보안이 확보된 AI 에이전트 실행 환경의 비용 하한선을 상당히 낮추었습니다. 셀프 호스팅(self-hosted) 모델은 경쟁사들이 부과하는 샌드박스당 클라우드 비용을 제거합니다. 하지만 비용이 낮아졌다고 해서 모든 위협 벡터(threat vector)에 대해 프로덕션 수준의 보안이 보장된다는 의미는 아닙니다. 외부 송출 강화(Egress hardening) 작업이 활발히 진행 중이며, 팀들은 격리된 샌드박스 실행을 완전한 데이터 유출 제어(data-exfiltration control) 수단으로 간주하기 전에 현재의 보안 프록시 문서를 주의 깊게 검토해야 합니다.

오픈 소스 관점: Tencent가 이를 무료로 공개한다는 것이 실제로 의미하는 바

Tencent는 단순히 CubeSandbox를 구축한 것에 그치지 않고, TencentCloud 조직(organization) 아래 GitHub에 전체 프로젝트를 올리고 무료로 공개했습니다. 이 결정은 자선이 아닌 전략적인 것입니다.

프로덕션 등급(production-grade)의 샌드박스 인프라를 오픈 소스로 공개하는 것은 세 가지 효과를 동시에 가져옵니다. 첫째, Tencent Cloud가 AI 에이전트 툴링(tooling)에 진지하게 임하고 있다는 신호를 글로벌 개발자 커뮤니티에 보냅니다. 둘째, 평가 장벽을 완전히 제거합니다(영업 팀과 대화하기 전에도 직접 실행해 볼 수 있습니다). 셋째, 관리형 인프라(managed infrastructure)로 확장할 준비가 되었을 때 이미 시스템을 알고 있는 개발자 기반(installed base)을 구축합니다. 개발자의 신뢰는 코드의 가시성을 통해 얻어지며, RustVMM 기반의 구현체는 누구나 감사(audit)할 수 있도록 공개되어 있습니다.