2026년의 AI 에이전트 샌드박싱: 프리미티브, 런타임, 플랫폼 중에서 고르는 방법

https://manveerc.substack.com/p/ai-agent-sandboxing-guide

2026년에 AI 에이전트 샌드박싱이 달라진 이유

2026년의 엔지니어링 리더에게는 선택지가 너무 많습니다. 솔직히 3년 전에는 이런 상황이 없었습니다.

"컨테이너냐 VM이냐" 하는 논쟁은 이미 한참 지났습니다. 지금은 Firecracker 마이크로VM, gVisor의 사용자 공간 커널, Cloud Hypervisor, 웹어셈블리 아이솔레이트, 그리고 마이크로소프트의 LiteBox처럼 새로 등장하는 라이브러리 OS 기술까지 눈앞에 늘어서 있습니다. 좀 벅찬 게 사실입니다.

그런데 이건 벤더들이 괜히 떠드는 게 아닙니다. 이렇게 선택지가 불어난 것은 업계가 실제 문제에 내놓은 답입니다. 표준 멀티테넌트 컨테이너로는 임의의 코드를 실행하는 AI 에이전트를 안전하게 담아 둘 수 없습니다.

한번 생각해 보세요. 에이전트가 스스로 파이썬 스크립트를 작성하고, 패키지를 설치하고, 파일 디스크립터를 조작할 수 있다면, 표준 도커 컨테이너가 커널을 공유하며 노출하는 표면은 그대로 위험 요소가 됩니다. AWS, Azure, GCP를 비롯한 주요 클라우드 제공업체는 모두 조용히 자기네 컨트롤 플레인을 runc에서 하드웨어로 강제하는 격리 쪽으로 옮겼습니다.

이 글에서는 2026년의 샌드박스 생태계를 구조적으로 정리합니다. 도구를 하나하나 떼어 놓고 비교하지 않고, 아키텍처의 계층을 나눠서 설명합니다. "EC2 위의 도커"로는 감당이 안 되는 단계에 이른 시리즈 A 이상 기업의 엔지니어링 리더이면서, 엔지니어링 예산을 태우지 않고도 레드팀 감사를 버텨 낼 보안 태세가 필요하다면 계속 읽어 보세요.

핵심 요약: 2026년의 AI 에이전트 샌드박싱

2026년 2월 현재, 결론은 분명합니다. 신뢰할 수 없는 AI 에이전트 코드를 실행하는 데 커널을 공유하는 컨테이너 격리(도커/runc)로는 더 이상 부족합니다. LLM이 생성한 코드나 사용자가 제출한 코드는 적대적이라고 보고 다뤄야 합니다. 커널을 공유하면 피해 범위만 넓어집니다.

시장은 세 계층으로 갈렸습니다.

프리미티브(Firecracker / gVisor / LiteBox): 통제권을 최대한 쥐기 위해 직접 서버 플릿과 스케줄러를 운영할 각오가 된 팀에게 가장 좋습니다.
임베더블 런타임(E2B, microsandbox**):** 코드 실행 기능을 빠르게 붙이고 싶을 때 가장 좋습니다. 관리형 API(E2B)나 직접 호스팅(microsandbox)을 고를 수 있습니다.
관리형 플랫폼(Daytona, Modal, Northflank): 데이터를 많이 다루는 워크로드나 GPU 접근, 운영 부담 없는 확장이 필요할 때 가장 좋습니다. 다만 격리 수준과 가격, 종속성은 제품마다 다르게 절충되어 있습니다.
하이브리드(Google Agent Sandbox): 이미 쿠버네티스를 쓰고 있고, 새 벤더에 의존하지 않으면서 웜 풀까지 갖춘 오픈소스 샌드박싱을 원하는 팀에게 가장 좋습니다.

통제권과 커스터마이징을 최대한 확보해 컴플라이언스를 맞춰야 한다면 1계층을 고르세요. 강한 격리를 유지하면서 일회성 코드 실행까지 가장 빨리 도달하고 싶다면 2계층을 고르세요. GPU나 데이터 근처에서의 실행, 운영 부담 없는 확장이 필요하다면 3계층을 고르되, 벤더 종속과 언어 제약, BYOC 지원 여부를 꼼꼼히 따져 보세요.

격리의 스펙트럼: 샌드박스 보안의 다섯 단계

도구를 고르기 전에 2026년에 쓸 수 있는 격리 다섯 단계를 이해해야 합니다. 한 단계씩 올라갈 때마다 성능 오버헤드를 내주고 더 강한 보안 경계를 얻습니다.

1단계: 컨테이너(Docker, Podman) 프로세스가 호스트 커널을 공유하고, 리눅스 네임스페이스와 cgroup으로 나뉩니다. 빠르고 가볍지만, 컨테이너 하나에서 커널 취약점이 터지면 나머지 전부가 위험해집니다. 신뢰할 수 있는 사내 작성 코드에는 충분합니다. 하지만 LLM이 생성한 것이라면 무엇에도 충분하지 않습니다.

2단계: 사용자 공간 커널(gVisor) 사용자 공간 애플리케이션이 시스템 콜을 가로채 다시 구현하므로, 샌드박스 안의 프로그램은 실제 커널과 한 번도 대화하지 않습니다. 컨테이너보다 강하고 전체 VM보다는 오버헤드가 적습니다. 구글(GKE의 Agent Sandbox)과 Modal이 씁니다. 절충점은 이렇습니다. 모든 시스템 콜이 완벽하게 에뮬레이션되지는 않아서 일부 리눅스 소프트웨어에서 호환성 문제가 생길 수 있습니다.

3단계: 마이크로VM(Firecracker, Kata Containers, libkrun) 워크로드마다 하드웨어 가상화(KVM) 위에서 돌아가는 자기 커널을 갖습니다. VM 하나 안에서 커널 익스플로잇이 성공해도 호스트나 다른 VM까지 닿을 수 없습니다. 신뢰할 수 없는 코드에는 현재 이 방식이 가장 확실한 기준입니다. Firecracker는 약 125밀리초에 부팅하고 메모리 오버헤드는 약 5MB입니다. AWS Lambda와 E2B, Vercel Sandbox를 구동합니다.

4단계: 라이브러리 OS(마이크로소프트 LiteBox) 시스템 콜 수백 개를 걸러 내는 대신, 애플리케이션이 통제된 프리미티브 몇 개만 노출하는 최소 OS 라이브러리에 직접 링크됩니다. 이론상 격리 계층이 가장 얇고 공격 표면도 가장 작습니다. 2026년 2월 기준으로는 실험 단계입니다. SDK도 없고 프로덕션 사용 사례도 없습니다.

5단계: 기밀 컴퓨팅(AMD SEV-SNP, Intel TDX, OP-TEE) 하드웨어가 메모리를 암호화해 격리합니다. 호스트 OS와 하이퍼바이저조차 샌드박스의 데이터를 읽을 수 없습니다. 이 비교에서 기밀 컴퓨팅 러너(SEV-SNP)를 갖춘 오픈소스 도구는 현재 LiteBox뿐입니다. 개인정보나 금융 데이터, 의료 기록을 다루는 규제 산업에 해당하는 이야기입니다.

하이퍼스케일러가 보내는 신호는 애매하지 않습니다. AWS는 Lambda를 위해 Firecracker를 만들었습니다. 구글은 검색과 Gmail을 위해 gVisor를 만들었습니다. Azure는 일회성 에이전트 샌드박스에 Hyper-V를 씁니다. 이들 모두 자기가 가진 가장 강한 격리 프리미티브를 꺼내 AI 쪽으로 겨눴습니다. 컨테이너를 꺼낸 곳은 하나도 없었습니다.

AI 에이전트 샌드박싱 방식을 고르는 방법: 네 가지 질문

Firecracker나 Modal을 들여다보기 전에, 자기 워크로드가 어디에 놓이는지부터 파악해야 합니다. "맞는" 도구는 신뢰와 지연 시간, 데이터, 컴플라이언스라는 제약 조건에 따라 완전히 달라집니다.

실행하려는 에이전트 코드를 얼마나 못 믿는가?

2026년의 보안은 예/아니오로 갈리지 않습니다. 정도의 문제입니다.

사내 로직: 우리 엔지니어가 직접 쓰고 CI/CD를 통과한 코드를 돌리는 경우라면, 표준 컨테이너(1계층이나 3계층)로도 대개 괜찮습니다.
LLM이 생성한 코드: 에이전트가 수학 문제를 풀거나 데이터 서식을 맞추려고 파이썬 코드를 만들어 내는 경우라면 위험이 확 올라갑니다. 자원이 사고로 고갈되거나 로직 폭탄이 심어지는 것을 막으려면 gVisor나 마이크로VM 같은 강한 격리가 필요합니다.
사용자가 올린 바이너리나 악성 에이전트: 사용자나 자율 에이전트가 임의의 바이너리를 실행하거나 검증되지 않은 PyPI 패키지를 설치하도록 허용하는 경우라면, 그 코드는 적대적이라고 가정하세요. 쓸 수 있는 가장 엄격한 격리, 즉 마이크로VM(Firecracker)을 통한 하드웨어 가상화나 외부와 완전히 끊어 둔 프리미티브가 필요합니다.

위험이 클수록 피해 범위를 통제하기 위해 스택의 더 아래쪽에서 직접 만들어야 할 수 있습니다.

에이전트 세션이 얼마나 오래 돌아야 하는가?

한 번에 끝나는 작업(추론·스크립트): 차트를 그리거나 추론을 한 번 돌리는 짧은 스크립트라면 콜드 스타트 시간이 가장 중요한 지표입니다. 1초 이내에 스냅샷을 복원할 수 있어야 합니다.
오래 돌아가는 작업(에이전트): 상태를 유지하고 몇 분씩 "생각"하거나 사용자 입력을 기다리는 에이전트라면 과금 모델이 결정적으로 중요해집니다. "초당" 요금을 비싸게 받는 런타임에서는 유휴 시간이 있는 세션의 비용이 금방 불어납니다. 지속 시간 측면에서는 관리형 플랫폼이 대체로 더 나은 경제성을 보여 줍니다. 프리미티브 위에 웜 풀을 직접 만들려면 낭비되는 비용을 피하기 위해 복잡한 오토스케일링 로직을 짜야 합니다.

데이터 중력 문제가 있는가?

팀들이 늘 놓치는 항목입니다.

작은 데이터 페이로드: JSON 몇 킬로바이트를 보내고 텍스트를 받아 오는 정도라면 임베더블 런타임(2계층)이 아주 잘 맞습니다.
큰 컨텍스트나 모델 가중치: 20GB 모델 가중치를 올리거나 5GB CSV를 처리한다면 데이터 중력(data gravity) 문제를 안고 있는 것입니다. 요청마다 기가바이트 단위 데이터를 원격 샌드박스 API로 옮기면 지연이 크게 늘고 이그레스 비용이 감당하기 어려워집니다. 이럴 때는 연산이 데이터 쪽으로 옮겨 가는 플랫폼(3계층)이나, 스토리지와 같은 위치에 둔 자체 1계층 구성이 필요합니다.

어떤 컴플라이언스와 보안 요건이 있는가?

엔터프라이즈에서 나오는 질문: 포춘 500 기업에 판매하려는 상황인가요? SOC 2 Type II나 ISO 27001 인증이 당장 필요한가요? 직접 쌓아 올린 "프리미티브" 스택에서 그 인증을 받으려면 엔지니어링 작업 12개월에서 18개월과 전담 보안 인력이 듭니다.
감사 가능성과 데이터 통제: 시스템 콜 하나하나에 대한 세밀한 감사 로그가 필요한가요? 코드가 프랑크푸르트에서만 실행된다고 보장하는 엄격한 데이터 소재지 통제가 필요한가요? 관리형 플랫폼은 보통 이런 것들을 기본 상품으로 제공합니다. 직접 만든 Firecracker 플릿에서 같은 수준의 가시성을 확보하려면, 격리를 깨지 않으면서 VM 경계를 통과할 수 있는 관측 파이프라인을 따로 만들어야 합니다.

AI 에이전트 샌드박싱의 세 계층 스택(프리미티브, 런타임, 플랫폼)

Firecracker와 Modal을 직접 비교하는 일은 그만두세요. 둘은 서로 다른 문제를 푸는 다른 범주입니다. 2026년의 생태계는 추상화 수준에 따라 위계를 이룹니다.

1계층: 프리미티브("원재료"). 직접 보유한 서버나 EC2 베어메탈 인스턴스 위에서 돌리는 오픈소스 가상화 기술입니다. 스스로 클라우드 제공업체가 되는 셈입니다.
- 예: AWS Firecracker(마이크로VM), gVisor(사용자 공간 커널), Cloud Hypervisor, 그리고 새로 나온 마이크로소프트 LiteBox(라이브러리 OS).
2계층: 임베더블 런타임("API"). 프리미티브를 간단한 SDK로 감싸 주는 미들웨어 서비스입니다. 인프라를 직접 관리하지 않고 코드 실행이 필요한 팀을 위한, 서비스형 샌드박싱입니다.
- 예: E2B, 코드 인터프리터 전용 API, microsandbox.
3계층: 관리형 플랫폼("클라우드"). 처음부터 끝까지 갖춰진 서버리스 연산 환경입니다. 프리미티브와 오케스트레이션, 스케줄링, 확장을 모두 대신 처리합니다. 여기서 샌드박스는 기능 하나가 아니라 환경 자체입니다.
- 예: Modal, Northflank, Daytona.

AI 에이전트 샌드박싱 아키텍처의 세 계층을 나타낸 피라미드 도식. 맨 위는 플랫폼(로직에 집중), 가운데는 런타임(통합에 집중), 맨 아래는 프리미티브(통제에 집중).

1계층(프리미티브): 이점과 절충, 그리고 숨은 비용

1계층의 이점: 격리를 최대한 통제할 수 있다

1계층은 인프라 회사와 아주 큰 기업이 사는 곳입니다. 이 길을 간다면 AWS Firecracker나 gVisor, 아니면 실험적인 마이크로소프트 LiteBox 위에 쌓아 올리게 됩니다.

여기서 얻는 것은 무엇일까요? 완전한 통제권입니다. 게스트 커널 버전을 직접 정합니다. 네트워크 구성을 바이트 단위까지 통제합니다. 자기 워크로드 패턴에 맞춰 자원을 초과 할당해 가능한 한 높은 밀도까지 뽑아낼 수 있습니다.

AWS Lambda의 경쟁 제품이나 특정 산업에 특화된 클라우드를 만드는 팀에게는 이 계층만이 현실적인 선택입니다.

1계층의 절충: 플랫폼을 직접 만들고 운영해야 한다

그런데 짚어 둘 게 있습니다. Firecracker를 "쓴다"는 말은 사실 어폐가 있습니다. Firecracker는 그냥 "쓰는" 게 아닙니다. 감싸고, 오케스트레이션하고, 디버깅해야 합니다.

프리미티브를 큰 규모로 운영하는 현실에는 제품 로드맵을 쉽게 망가뜨릴 만한 엔지니어링 비용이 숨어 있습니다.

이미지 관리: 동시 폭주로 레지스트리가 무너지지 않게 하기

샌드박싱에서 가장 어려운 문제는 가상화가 아닙니다. 데이터를 옮기는 일입니다.

AI 에이전트를 1초 이내에 시작하려면 마이크로VM 안에서 docker pull을 돌릴 수 없습니다. 정교한 블록 단위 캐싱 전략이 필요합니다.

에이전트 1,000개가 동시에 시작하는 이른바 동시 폭주(thundering herd) 상황에서, 레지스트리가 5GB 컨테이너 이미지를 노드 1,000개에 전달하게 하면 네트워크가 뒤집어집니다. SOCI(Seekable OCI)나 eStargz 같은 지연 로딩 기술이 필요합니다.

연구 결과를 보면 SOCI는 표준 시작 시간에 맞출 수 있지만, 최적화되지 않은 지연 로딩은 오히려 시작 성능을 떨어뜨립니다. Airflow의 시작 시간이 5초에서 25초로 늘어난 사례가 그런 경우입니다. 마이크로VM에 데이터를 먹여 줄, 처리량 높은 전역 콘텐츠 주소 기반 스토리지 계층을 만드는 일은 샌드박스 자체에 맞먹는 분산 시스템 과제입니다.

네트워킹: TAP/TUN과 CNI 오버헤드, 시작 지연

네트워킹은 마이크로VM 프로젝트를 조용히 죽입니다.

도커는 성숙한 CNI 플러그인을 제공하지만, Firecracker는 다릅니다. 호스트에서 TAP 인터페이스와 IP 테이블, 라우팅을 직접 관리해야 합니다.

최근 연구(IMC '24)를 보면 동시성이 높을 때, 대략 400개를 병렬로 시작하는 지점에서 CNI 플러그인과 가상 스위치를 세팅하는 일이 주된 병목이 됩니다. 이 오버헤드 때문에 시작 지연이 최대 263%까지 늘어나 125밀리초짜리 VM 부팅이 몇 초씩 걸리는 지연으로 바뀝니다.

그리고 "jailer"로 제약된 환경 안에서 네트워킹을 디버깅하는 일은요? 어렵기로 악명이 높습니다. 표준 관측 도구는 VM 경계를 통과하지 못하는 경우가 많습니다.

웜 풀: 콜드 스타트를 줄이는 대가로 치르는 유휴 비용

팀들은 콜드 스타트를 줄이려고 미리 부팅해 둔 VM을 "웜 풀"로 유지하곤 합니다. 여기서 복잡한 경제 문제가 생깁니다.

VM 500개를 켜 두고 100개만 쓰고 있다면? 유휴 연산에 돈을 태우는 것입니다.

요청이 들어오기 전에 VM을 띄우되 너무 많이 띄우지는 않는 예측형 오토스케일러를 만드는 일은 진지한 데이터 과학 과제입니다. GPU 연산 비용이 여전히 높은 2026년에는, 웜 풀을 비효율적으로 운영해서 생기는 낭비가 관리형 플랫폼이 붙이는 마진을 넘어서기 쉽습니다.

2026년의 LiteBox: 무엇이고 언제 쓰나

2026년 2월 현재 마이크로소프트는 Rust로 만든 라이브러리 OS인 LiteBox를 내놓았습니다. 매력적인 중간 지점을 제시합니다. VM보다 가벼우면서, 호스트에 노출되는 인터페이스는 컨테이너보다 훨씬 좁습니다.

AMD SEV-SNP(기밀 컴퓨팅)를 쓴다는 점은 기대할 만하지만, LiteBox는 아직 실험 단계입니다. 몇 년에 걸쳐 AWS Lambda를 단단하게 다져 온 Firecracker와 달리 LiteBox에는 프로덕션 생태계가 없습니다. 지금 회사의 보안을 LiteBox에 걸면 최신 기술을 앞서 쓰는 만큼의 위험을 함께 안게 됩니다.

Google Agent Sandbox: 쿠버네티스에 녹아든 중간 지점

구글의 Agent Sandbox는 1계층과 2계층에 걸쳐 있어서 따로 언급할 만합니다. KubeCon NA 2025에서 쿠버네티스 SIG Apps 산하 CNCF 프로젝트로 공개되었고, 직접 운영하는 쿠버네티스 클러스터에서 격리되고 상태를 유지하는 샌드박스 파드를 선언적 API로 관리하게 해 주는 오픈소스 컨트롤러입니다.

흥미로운 지점은 이렇습니다.

격리 백엔드가 두 가지. gVisor(기본값)와 Kata Containers를 모두 지원해서, 워크로드별로 격리 강도를 고를 수 있습니다.
웜 풀 사전 프로비저닝. SandboxWarmPool CRD가 미리 부팅한 파드를 유지해 콜드 스타트 지연을 1초 이내로 줄입니다. 앞에서 이야기한 웜 풀 문제를, 오토스케일링 로직을 직접 만들지 않고도 해결해 줍니다.
쿠버네티스에 맞춘 추상화. SandboxTemplate이 환경의 청사진을 정의합니다. SandboxClaim을 통해 LangChain이나 구글 ADK 같은 프레임워크가 실행 환경을 선언적으로 요청할 수 있습니다. 코드형 인프라가 아니라 YAML형 인프라인 셈입니다.
벤더 종속 없음. GKE뿐 아니라 어떤 쿠버네티스 클러스터에서도 돌아갑니다. 다만 GKE는 관리형 gVisor 통합과 더 빠른 재개를 위한 파드 스냅샷을 제공합니다.

절충점은 이렇습니다. 쿠버네티스 클러스터는 여전히 직접 운영해야 합니다. 3계층 플랫폼처럼 운영 부담이 없는 방식은 아닙니다. 하지만 이미 쿠버네티스에서 돌아가고 있고 새 벤더 의존을 늘리지 않으면서 에이전트 샌드박싱이 필요한 팀이라면, Agent Sandbox가 앞 절들에서 설명한 직접 오케스트레이션 작업을 거의 다 없애 주면서 개방형 인프라에 머무를 수 있게 해 줍니다.

이미 GKE를 쓰고 있다면, 관리형 플랫폼을 보기 전에 이것부터 검토해야 합니다.

2계층(임베더블 런타임): API로 제공되는 샌드박싱

"API로 제공되는 샌드박싱"이란

2계층 솔루션은 격리 프리미티브를 개발자가 쓰기 편한 인터페이스로 감쌉니다. E2B는 관리형 API로 "샌드박싱의 Stripe" 같은 접근을 취하고, microsandbox는 같은 마이크로VM 격리 등급을 직접 호스팅하는 런타임으로 제공합니다. 둘 다 Firecracker 관리, TAP 인터페이스, 루트 파일시스템처럼 1계층의 복잡한 부분을 깔끔한 SDK로 추상화합니다.

이 계층은 "코드 인터프리터" 기능을 빠르게 붙여야 하는 SaaS 팀에 가장 잘 맞습니다. 몇 달이 아니라 며칠 단위의 이야기입니다.

microsandbox: 직접 호스팅하는 대안

모든 팀이 코드를 제3자 API로 보내고 싶어 하지는 않습니다. microsandbox는 E2B와 다른 길을 갑니다. 직접 호스팅하는 오픈소스 런타임이고, libkrun(라이브러리 기반 KVM 가상화 도구)으로 마이크로VM 격리를 제공합니다. 샌드박스마다 전용 커널을 받으므로 시스템 콜을 가로채는 수준이 아니라 하드웨어 수준으로 격리되며, 시작 시간은 200밀리초 이내입니다.

E2B와의 결정적인 차이는 microsandbox가 전부 자기 인프라에서 돌아간다는 점입니다. SaaS에 의존하지 않고, 데이터가 네트워크를 떠나지 않습니다. 그래서 데이터 소재지 요건이 엄격한 팀이나, 클라우드 샌드박스 API를 아예 쓸 수 없는 에어갭 환경에서는 이 선택이 더 강합니다.

절충점은 예상 그대로입니다. 운영은 직접 떠맡습니다. microsandbox는 격리 프리미티브와 그것을 관리할 서버를 주지만, 확장과 모니터링, 이미지 관리는 각자 처리해야 합니다. "직접 호스팅하는 E2B"라고 생각하면 됩니다. 보안 등급은 같은 마이크로VM이고, 운영 모델만 다릅니다.

2026년 초 기준으로 microsandbox는 깃허브 스타 약 4,700개를 받았고 Apache 2.0 라이선스로 배포됩니다. 직접 호스팅해야 하는 팀에게는 이 계층에서 가장 성숙한 오픈소스 선택지입니다.

네 가지 질문으로 본 2계층(보안, 지속 시간, 데이터 중력, GPU)

신뢰할 수 없는 코드: 2계층이 가장 잘하는 부분입니다. 벤더들이 LLM이 생성한 코드를 실행할 목적으로 이 런타임들을 만들었습니다. E2B는 Firecracker를, microsandbox는 libkrun을 씁니다. 둘 다 샌드박스마다 전용 커널을 두어 하드웨어 수준으로 격리합니다.
세션 길이: 이 계층은 한 번에 끝나는 단기 작업에 최적화되어 있습니다. 에이전트가 데이터셋을 시각화하는 파이썬 스크립트를 돌리고 바로 종료하는 식이라면 비용 효율이 좋습니다. 하지만 몇 분에서 몇 시간씩 유지되는 장시간 에이전트라면, 이 계층에서 흔한 초당 과금 모델 때문에 비용이 빠르게 쌓여 순수 연산 비용을 넘어서는 일이 잦습니다.
데이터 중력: 이 계층에서 데이터 이동은 가장 큰 아키텍처 제약이지만, 관리형 런타임과 직접 호스팅 런타임에 다르게 작용합니다. E2B 같은 관리형 API에서는 JSON이나 스프레드시트, 짧은 스크립트처럼 작은 페이로드가 네트워크를 오가는 정도라 오버헤드가 무시할 만합니다. E2B는 볼륨 마운트와 영속 스토리지를 지원해서 중간 규모 데이터셋까지 다룰 수 있습니다. microsandbox는 네트워크를 한 번 타는 과정 자체를 건너뜁니다. 자기 인프라에서 돌아가니 샌드박스가 정의상 데이터와 같은 위치에서 실행되어, 이그레스 비용과 전송 지연이 사라집니다. 갈림길은 이 지점입니다. 실행 한 번마다 기가바이트 단위 파일을 일상적으로 옮기게 되면, 즉 큰 모델 가중치나 영상 처리, 데이터셋 조인 같은 작업이라면, 관리형 API에서는 볼륨 마운트로도 I/O 부담을 온전히 가릴 수 없습니다. 그 규모에 이르면 microsandbox로 직접 호스팅하거나, 연산과 스토리지가 내부 네트워크를 공유하는 3계층으로 옮기거나, 데이터와 같은 위치에 1계층을 직접 구성해야 합니다.
GPU 접근: 2계층 런타임의 GPU 지원은 아직 성숙해 가는 중입니다. E2B는 현재 CPU 워크로드에 집중하고 있습니다. 에이전트가 GPU 추론이나 파인튜닝을 해야 한다면 이건 실제로 비어 있는 부분이라, 3계층 플랫폼이나 GPU 패스스루를 갖춘 자체 1계층 구성으로 밀려갈 수 있습니다.

3계층(관리형 플랫폼): 에이전트를 위한 서버리스 샌드박싱

관리형 플랫폼이 연산과 데이터, 격리를 한데 묶는 이유

관리형 플랫폼은 "서버리스 클라우드" 방식을 취합니다. 플랫폼이 곧 샌드박스입니다.

별도의 샌드박스 서비스에 API를 호출하지 않습니다. 워크로드 전체가 기본적으로 격리된 환경 안에서 돌아갑니다. 이렇게 묶으면 코드와 데이터, 연산 사이에서 생기는 마찰이 해결됩니다.

눈에 띄는 관리형 플랫폼은 세 곳이고, 각각 아키텍처를 다르게 걸었습니다.

Modal은 파이썬 머신러닝 워크로드에 맞춰 최적화한 gVisor(사용자 공간 커널 격리)를 씁니다. 강점은 GPU를 기본으로 지원한다는 점(T4부터 H200까지), 0에서부터 서버리스로 오토스케일링한다는 점, 파이썬 SDK로 인프라를 코드로 정의한다는 점입니다. 한계는 격리가 gVisor뿐이어서 더 높은 보안이 필요할 때 마이크로VM을 선택할 수 없다는 점, 파이썬 중심이라 다른 언어 지원이 제한적이라는 점, BYOC나 온프레미스 배포가 없다는 점, 이미지를 SDK로 정의하는 방식이라 이전할 때 마찰이 생긴다는 점입니다.

Northflank는 Kata Containers(마이크로VM)와 gVisor를 함께 쓰면서 워크로드별로 격리 수준을 고릅니다. 강점은 세 곳 중 격리가 가장 강하다는 점(Kata를 통한 전용 커널), BYOC 배포를 지원한다는 점(AWS, GCP, Azure, 베어메탈), 세션 지속 시간에 제한이 없다는 점, GPU를 지원하면서 요금이 모두 포함되어 있다는 점, OCI 호환이라 독자 이미지 형식이 없다는 점입니다. 한계는 플랫폼이 더 포괄적인 만큼 순수 샌드박스 API보다 처음 설정이 까다롭다는 점, 파이썬에 특화된 개발 경험은 Modal보다 약하다는 점입니다.

Daytona는 기본적으로 도커 컨테이너를 쓰고, 더 강한 격리가 필요하면 Kata Containers를 선택할 수 있습니다. 강점은 시장에서 콜드 스타트가 가장 빠르다는 점(90밀리초 이내), 도커와 그대로 호환된다는 점, LSP를 지원하는 상태 유지 샌드박스를 제공한다는 점, 컴퓨터를 조작하는 에이전트를 위한 데스크톱 환경을 준다는 점입니다. 한계는 기본 도커 격리가 세 곳 중 가장 약하다는 점입니다. 마이크로VM 수준의 보안을 원하면 Kata를 명시적으로 켜야 합니다. 플랫폼도 더 젊습니다(2025년 초에 AI 샌드박스로 방향을 틀었습니다).

네 가지 질문으로 본 3계층(보안, 데이터 중력, GPU, 컴플라이언스)

신뢰할 수 없는 코드: 플랫폼은 기본으로 격리를 제공하지만 보호 수준은 제각각입니다. Modal은 사용자 공간에서 시스템 콜을 가로채는 gVisor를 씁니다. 컨테이너보다 강하지만 전용 커널과 같다고 볼 수는 없습니다. Northflank는 가장 엄격한 격리가 필요한 워크로드를 위해 Kata Containers(전용 커널을 갖춘 완전한 마이크로VM)를 제공합니다. Daytona는 도커 컨테이너를 기본으로 쓰는데, Kata를 직접 설정하지 않으면 정말로 적대적인 코드에는 부족할 수 있습니다. 위협 모델에 커널 익스플로잇이 들어 있다면, 그저 "샌드박싱"이 되는지가 아니라 마이크로VM 수준의 격리를 제공하는지 물어야 합니다.
데이터 중력: 3계층 플랫폼은 대체로 연산과 스토리지를 고속 내부 네트워크에 같이 두어 데이터 중력을 해결하고, 2계층 API에서 생기는 업로드·다운로드 부담을 피합니다. Modal과 Northflank 모두 볼륨 마운트와 캐시된 데이터셋을 지원합니다. 다만 데이터 소재지는 서로 다릅니다. Northflank는 데이터가 자기 VPC 안에 머문다고 보장하는 BYOC 배포를 제공하고, Modal은 자체 관리형 인프라에서 돌아갑니다. 데이터가 물리적으로 어디에 있어야 하는지를 규제가 정하고 있다면, BYOC 지원이 결정적인 요소가 됩니다.
필요할 때 쓰는 GPU: 멀티테넌트 추론의 스케줄링과 격리 GPU 접근은 3계층에서 가장 뚜렷한 차별점이지만 지원 범위는 다릅니다. Modal은 가장 폭넓은 GPU 선택지(T4부터 H200까지)를 초당 과금으로 제공하지만, GPU와 CPU, RAM에 요금이 따로 붙는 것을 감안하면 총비용이 쌓입니다. Northflank는 요금이 모두 포함된 방식으로 GPU를 지원해서, 지속적으로 돌리는 워크로드라면 상당히 저렴할 수 있습니다. Daytona는 현재 GPU를 지원하지 않습니다. 연구 결과를 보면 MIG 같은 엄격한 하드웨어 분할 없이 GPU를 여러 테넌트가 함께 쓰면 지연이 55%에서 145%까지 나빠질 수 있습니다. 관리형 플랫폼은 이 스케줄링의 복잡함을 대신 처리하면서 "소프트"나 "하드" GPU 격리를 제공하고, 드라이버와 CUDA 버전, 하드웨어 추상화까지 맡아 줍니다. 코드에서 GPU를 요청하면(예: gpu="A100") 플랫폼이 물리 프로비저닝과 격리를 처리합니다.
컴플라이언스: 엔터프라이즈용 컴플라이언스 기능은 플랫폼마다 크게 다릅니다. 관리형 플랫폼을 쓰면 프리미티브 위에 직접 쌓는 것보다 통제 항목을 대체로 빨리 물려받을 수 있지만, 세부 사항이 중요합니다. Northflank의 BYOC 모델에서는 데이터를 자기 클라우드 계정에 그대로 둘 수 있어서 데이터 소재지 요건을 맞추기가 수월합니다. Modal은 관리형 인프라만 제공하므로 데이터가 그쪽 서버에서 돌아갑니다. Daytona는 직접 호스팅하는 선택지를 제공합니다. 벤더별 SOC 2 인증 상태와 감사 로그의 세밀함, 네트워크 격리 역량을 각자의 컴플라이언스 요건에 비춰 평가하세요.

비교: 프리미티브, 런타임, 관리형 플랫폼

AI 샌드박싱의 세 계층인 프리미티브(1계층), 런타임(2계층), 관리형 플랫폼(3계층)을 정리한 비교표. 격리 선택지, 프로덕션까지 걸리는 시간, 비용, GPU 지원, 컴플라이언스에 드는 노력 같은 기준을 Firecracker, E2B, Modal 등의 예와 함께 다룬다.

눈여겨볼 하이브리드: Google Agent Sandbox. 웜 풀과 함께 gVisor와 Kata를 지원하는 쿠버네티스 기반 컨트롤러입니다. 자기 클러스터에서 돌아갑니다. 오픈소스(CNCF)입니다. 이미 쿠버네티스를 쓰는 팀에게 가장 좋습니다.

AI 에이전트 샌드박싱의 다음 국면(2026~2027)

2026년 후반과 2027년을 보면, 세 가지 흐름이 이 스택을 다시 짜게 될 것입니다.

흐름: 라이브러리 OS 샌드박스(LiteBox)

마이크로소프트가 LiteBox로 들어온 것은 라이브러리 운영체제로 향하는 움직임에 힘을 실어 줍니다. 애플리케이션 코드에 꼭 필요한 최소 커널 구성 요소만 묶어 넣는 방식으로("North/South" 인터페이스 패러다임을 사용해), 라이브러리 OS는 프로세스만큼 낮은 오버헤드에 VM만큼의 격리를 약속합니다.

지금은 아직 실험 단계입니다. 하지만 2~3년 안에 성능과 보안 사이의 절충 지점을 다시 정의하면서, 보안이 중요한 워크로드에서 컨테이너를 대체할 가능성이 있습니다.

흐름: 데몬 없이 임베드하는 샌드박싱(BoxLite)

다음 개척지는 서버 프로세스가 전혀 없는 샌드박싱입니다. BoxLite(마이크로소프트의 LiteBox와는 별개입니다) 같은 프로젝트는 마이크로VM 격리를 라이브러리 형태로 애플리케이션에 바로 심는 방향을 탐색하고 있습니다. 데몬도, 데몬 소켓도, 백그라운드 프로세스도 없습니다. microsandbox가 직접 배포하는 서버라면, BoxLite는 가져다 임포트하는 라이브러리를 지향합니다.

PostgreSQL(서버)과 SQLite(라이브러리)의 차이를 떠올리면 됩니다. BoxLite는 SQLite 모델을 샌드박싱에 적용한 것입니다. 함수 한 번 호출하면 애플리케이션 프로세스 안에서 격리된 OCI 컨테이너가 올라옵니다. 클라우드에 의존하지 않고 개발자 머신이나 엣지 기기에서 에이전트를 돌리는 "로컬 우선" AI 에이전트 흐름에 맞는 방식입니다.

아직 초기 단계지만(v0.5.10, 컨트리뷰터 14명, 깃허브 스타 약 1,000개), 샌드박싱을 서비스가 아니라 임베드된 라이브러리로 보는 이 아키텍처 방향은 가벼운 에이전트 프레임워크가 격리를 다루는 방식을 다시 짤 수도 있습니다.

흐름: MCP로 프로토콜 계층에서 권한을 다루기

보안이 스택 위쪽으로 올라오고 있습니다. 커널 수준 격리는 "이 코드가 샌드박스를 빠져나갈 수 있나?"에 답하지만, "이 에이전트가 애초에 HTTP 요청을 보내도 되는가?"에는 답하지 않습니다. 이 상위 질문에는 모델 자체를 둘러싼 행동 게이팅과 입력 검증, 런타임 모니터링이 필요합니다.

**모델 컨텍스트 프로토콜(MCP)**은 에이전트의 능력을 추론하는 대신 선언하게 만들어, 프로토콜 계층에서 권한을 강제할 길을 열어 줍니다.

작동 방식은 이렇습니다. MCP 서버는 web_search, filesystem_read, database_query처럼 각각 범위가 정해진 도구 목록을 매니페스트로 노출합니다. MCP를 이해하는 샌드박스 런타임은 그 매니페스트에서 보안 정책을 바로 끌어낼 수 있습니다. web_search를 쓸 권한이 있는 에이전트는 443 포트로 나가는 HTTPS를 얻습니다. filesystem_read만 가진 에이전트는 네트워크 접근을 아예 얻지 못합니다. 파일시스템 마운트는 그 도구가 선언한 경로로 좁혀집니다. 샌드박스의 방화벽 규칙과 마운트 지점이, 엔지니어가 한 번 써 두고 잊어버리는 정적 설정이 아니라 에이전트의 도구 권한에서 따라 나오는 값이 되는 것입니다.

오늘 이걸 하는 프로덕션 샌드박스는 없습니다. 하지만 필요한 요소들은 모여들고 있습니다. MCP는 에이전트 프레임워크 전반으로 빠르게 채택되고 있고(LangChain, CrewAI, 구글 ADK 모두 지원합니다), 샌드박스 런타임은 이런 정책을 프로그래밍으로 강제하는 데 필요한 네트워크·파일시스템 제어를 이미 노출하고 있습니다. 빠진 조각은 MCP 도구 매니페스트를 부팅 시점에 샌드박스 보안 정책으로 번역해 주는 접착 계층입니다. 첫 통합은 2026년 후반에 나올 것으로 봅니다.

결론: 우리 AI 에이전트에 맞는 샌드박스 계층 고르기

2026년의 샌드박스 지형에서 중요한 것은 가상화 기술을 고르는 일이 아닙니다. 어느 추상화 수준에 설 것인지를 고르는 일입니다. 엔지니어링 리더십에게 이를 가르는 질문은 이것입니다. 우리는 어디서 가치를 만드는가?

핵심 사업이 인프라를 판매하는 것이라면, 즉 다음 Vercel이나 특정 산업에 특화된 클라우드를 만드는 중이라면, 프리미티브(1계층) 위에 쌓아야 합니다. Firecracker 플릿을 관리하는 운영상의 고통이 곧 경쟁 우위가 되어 줍니다.

기존 제품 안에 코드 실행을 기능으로 붙여야 한다면, 임베더블 런타임(2계층)이 강한 격리를 유지하고 구조는 거의 바꾸지 않으면서 며칠 만에 그 지점까지 데려다줍니다.

핵심 사업이 AI 애플리케이션이나 에이전트, 데이터 파이프라인을 만드는 것이라면, 관리형 플랫폼(3계층)이 통제권을 내주고 속도를 가져다줍니다. 다만 "관리형"이라고 다 같은 게 아닙니다. 자기 워크로드에 맞춰 격리 강도(gVisor냐 마이크로VM이냐)와 배포 모델(관리형이냐 BYOC냐), 언어 제약, 세션 경제성을 먼저 평가한 뒤에 결정하세요.

2026년에 하지 말아야 할 결정이 하나 있습니다. 신뢰할 수 없는 AI 생성 코드를 커널 공유 컨테이너 안에서 돌리면서 별일 없기를 바라는 것입니다. 클라우드 제공업체들이 이미 그것으로는 부족하다고 알려 줬습니다. 그 말을 들으세요.

자주 묻는 질문(FAQ)

신뢰할 수 없는 AI 에이전트 코드를 돌리는 데 도커(runc)로 충분히 안전한가요?

적대적인 코드나 사용자가 제출한 코드에는 커널을 공유하는 컨테이너로 충분한 격리를 얻지 못하는 것이 보통입니다. 마이크로VM(예: Firecracker)이나 단단하게 다져진 사용자 공간 커널(예: gVisor)처럼 더 강한 경계를 쓰거나, 멀티테넌트 격리를 기본으로 제공하는 관리형 플랫폼에서 돌리세요. 이런 샌드박싱 프리미티브는 제가 프롬프트 인젝션에 대한 심층 방어 아키텍처에서 1계층이라고 부르는 것의 토대를 이룹니다. 거기서 권한 경계는 첫 번째 방어선이지만, 유일한 방어선은 아닙니다.

샌드박싱 관점에서 Firecracker와 gVisor는 어떻게 다른가요?

Firecracker는 하드웨어 가상화(마이크로VM)로 더 강하게 격리하지만, 대개 운영 복잡도가 더 늘어납니다. gVisor는 사용자 공간 커널로 시스템 콜을 가로채 표준 컨테이너보다 격리를 개선하며, 통합은 보통 더 쉽지만 성능과 호환성 쪽 절충이 달라집니다.

프리미티브와 임베더블 런타임, 관리형 플랫폼 중 무엇을 언제 골라야 하나요?

통제권을 최대한 확보해야 하고 스케줄러와 이미지, 네트워킹, 컴플라이언스를 포함한 서버 플릿을 직접 운영할 수 있다면 프리미티브를 고르세요. 코드 실행을 빨리 붙여야 하고 페이로드가 작다면 임베더블 런타임을 고르세요. GPU와 데이터 근처에서의 실행이 필요하고 운영은 최소로 하고 싶다면 관리형 플랫폼을 고르세요.

"데이터 중력"이란 무엇이고 샌드박싱에서 왜 중요한가요?

데이터 중력은 큰 데이터셋이나 모델 가중치를 코드가 돌아가는 곳으로 옮기는 데 드는 비용과 지연입니다. 실행마다 기가바이트 단위를 일상적으로 옮기고 있다면 API 방식 샌드박스는 느려지고 비싸집니다. 플랫폼이나 데이터와 같은 위치에 둔 프리미티브는 연산을 데이터 근처에서 돌려 전송량을 줄여 줍니다.

임베더블 샌드박스 API(2계층)가 장시간 돌아가는 에이전트에 적합한가요?

벤더들은 보통 수명이 짧고 한 번에 끝나는 실행에 맞춰 최적화합니다. 유휴 상태로 있거나 몇 분에서 몇 시간씩 돌아가는 에이전트라면, 초당 과금과 세션 관리 때문에 플랫폼이나 직접 운영하는 서버 플릿보다 비싸질 수 있습니다.

AI 에이전트에 GPU 격리가 필요한가요? 그건 어떻게 처리되나요?

여러 테넌트가 GPU를 함께 쓰면 "시끄러운 이웃" 효과 때문에 지연을 예측하기 어려워지고 보안 문제도 생길 수 있습니다. 관리형 플랫폼은 보통 GPU 스케줄링과 격리를 대신 처리해 주지만(예: MIG나 분할 전략), 직접 만드는 방식에서는 상당한 엔지니어링 노력이 듭니다.

Firecracker(1계층) 위에 쌓으면 어떤 운영 작업을 떠맡게 되나요?

이미지 배포와 캐싱, 네트워킹(TAP/TUN, 라우팅), 오케스트레이션, 웜 풀, 오토스케일링, 관측, 장애 대응을 모두 직접 맡습니다. 격리 프리미티브는 프로덕션 샌드박스 플릿을 운영하는 일의 한 부분일 뿐입니다.

LiteBox는 무엇이고 2026년에 프로덕션에 쓸 수 있나요?

LiteBox는 컨테이너보다 호스트 인터페이스를 줄이는 라이브러리 OS 방식입니다. 앞에서 설명한 대로 실전에서 검증된 마이크로VM 방식과 비교하면 아직 실험 단계이므로, 최신 기술에 따르는 불안정을 감당할 수 있는 경우가 아니라면 도입에 더 큰 위험이 따릅니다.

샌드박스 계층을 고를 때 컴플라이언스(SOC 2, ISO 27001)는 어떻게 생각해야 하나요?

프리미티브 위에 컴플라이언스를 쌓으려면 보통 상당한 시간과 전담 보안 엔지니어링이 필요합니다. 관리형 플랫폼을 쓰면 감사 로그와 네트워크 경계, 소재지 선택 같은 통제 항목을 더 빨리 물려받을 수 있는데, 이는 벤더의 역량과 각자의 요건에 따라 달라집니다.

요즘 샌드박스에서 콜드 스타트는 어느 정도를 기대할 수 있나요?

요즘 방식은 스냅샷과 캐싱으로 1초 이내에 시작할 수 있는 경우가 많습니다. 다만 실제 지연은 격리 프리미티브 하나보다 이미지 배포와 네트워킹 설정, 웜 풀 전략에 더 크게 좌우되곤 합니다.