AI 에이전트 샌드박스란?

AI 에이전트 샌드박스는 AI 에이전트가 실제 작업을 수행하는 실행 계층입니다. 코드 작성 및 실행, 패키지 설치, 파일 읽기 및 수정, API 호출, 브라우저 세션이나 데스크톱 GUI와의 상호작용 등이 포함됩니다. 샌드박스는 자체 파일 시스템, CPU 및 메모리 할당, 네트워크 인터페이스, 프로세스 네임스페이스를 갖춘 경계 환경을 제공하며, 외부의 모든 것과 격리됩니다.

핵심 설계 목표는 차단(containment)입니다. LLM이 셸 명령을 생성하고 에이전트가 이를 실행하면, 해당 명령은 샌드박스 내부에서 실행됩니다. 패키지를 설치하거나, 하위 프로세스를 실행하거나, 자격 증명을 읽으려고 시도하더라도 이러한 작업은 샌드박스로 범위가 제한됩니다. 코드가 프로세스를 충돌시키거나 디스크를 가득 채우더라도 피해는 로컬에 머무릅니다.

샌드박스는 또한 클라우드 제공자의 청구 및 리소스 회계 단위 역할을 합니다. E2B, Daytona, Novita Agent Sandbox와 같은 SDK를 호출하면 샌드박스 인스턴스를 생성하고, 내부에서 작업을 실행한 다음 닫습니다. 제공자는 소비한 컴퓨팅 양에 따라 비용을 청구합니다.

에이전트 샌드박스는 일반 컨테이너와 어떻게 다른가요?

일반 컨테이너는 파일 시스템 네임스페이스와 리소스 제한을 제공하지만, 동일한 호스트의 모든 컨테이너는 동일한 OS 커널을 공유합니다. 컨테이너 내부의 프로세스가 커널 취약점이나 잘못 구성된 시스템 호출 필터를 악용하면 호스트나 다른 컨테이너에 영향을 미칠 수 있습니다.

에이전트 샌드박스는 일반적으로 microVM 경계를 사용하여 한 단계 더 나아갑니다. microVM은 워크로드를 자체 게스트 커널을 갖춘 경량 가상 머신으로 감싸며, 하드웨어 가상화(KVM)를 기반으로 합니다. 게스트는 설계상 호스트 커널과 격리되므로 게스트의 커널 익스플로잇이 호스트에 자동으로 영향을 미치지 않습니다.

실질적인 트레이드오프는 성능 오버헤드입니다. microVM은 최소한의 커널이라도 부팅해야 하므로 컨테이너보다 시작 속도가 느립니다. Firecracker와 같은 빠른 microVM 플랫폼은 이 오버헤드를 대부분의 경우 500ms 미만으로 줄였으며, Daytona와 같은 스냅샷 기반 시스템은 100ms 미만으로 낮췄습니다. 그러나 여전히 컨테이너를 시작하는 것보다 오버헤드가 더 큽니다.

LLM이 생성하거나 신뢰할 수 없는 코드를 포함하는 대부분의 AI 에이전트 워크로드에서는 더 강력한 경계가 가치가 있습니다. 사용자 입력이 없고 완전히 신뢰할 수 있는 내부 코드를 실행하는 경우, 강화된 컨테이너로 충분할 수 있습니다.

AI 에이전트의 맥락에서 격리(isolation)란 무엇인가요?

에이전트 샌드박스의 격리는 여러 차원에서 작동합니다. 실제 워크로드에서 샌드박스 격리가 어떻게 유지되는지, microVM 경계가 도움이 되는 부분과 그렇지 않은 부분을 포함한 기술적 심층 분석은 Firecracker 평가 가이드를 참조하세요.

파일 시스템 격리 — 에이전트는 호스트와 분리된 자체 파일 시스템을 갖습니다. 샌드박스 내부에 작성된 파일은 호스트에 나타나지 않으며, 명시적으로 마운트되지 않는 한 호스트 파일에 내부에서 접근할 수 없습니다. 이는 에이전트가 샌드박스 외부에 있는 자격 증명, 구성 파일 또는 기타 비밀을 읽는 것을 방지합니다.

프로세스 격리 — 샌드박스 내부의 프로세스는 외부의 프로세스를 볼 수 없으며 시그널을 보낼 수 없습니다. 에이전트는 샌드박스 내부에서 하위 프로세스, 백그라운드 작업 또는 서버를 시작할 수 있지만, 호스트 프로세스 트리와 통신할 수 없습니다.

네트워크 격리 — 기본적으로 에이전트 샌드박스는 아웃바운드 네트워크 호출을 차단하거나, 허용 목록에 추가하거나, 속도를 제한하도록 구성할 수 있습니다. 임의의 인터넷 주소로 데이터를 유출해서는 안 되는 에이전트는 알려진 엔드포인트 목록으로 제한될 수 있습니다. 자세한 내용은 아래 이그레스 필터링 섹션을 참조하세요.

리소스 격리 — CPU 및 메모리 할당이 제한됩니다. 무한 루프에 빠지거나 큰 출력을 생성하는 에이전트가 동일한 호스트의 다른 샌드박스를 굶기지 않도록 리소스 제한이 VM 또는 컨테이너 수준에서 적용됩니다.

이러한 차원들은 함께 폭발 반경(blast radius)을 정의합니다. 에이전트가 잘못 동작하거나, 충돌하거나, 예상치 못한 코드를 실행할 경우 최악의 시나리오는 무엇인가요?

이그레스 필터링이란 무엇이며 왜 중요한가요?

이그레스 필터링은 에이전트가 샌드박스 내부에서 허용되는 아웃바운드 네트워크 연결을 제어합니다.

허용적인 구성에서는 에이전트가 인터넷의 모든 호스트에 HTTP/HTTPS 호출을 할 수 있습니다. 이는 패키지를 가져오거나, 외부 API를 호출하거나, 웹을 탐색하는 코딩 에이전트에게 편리합니다. 그러나 손상된 에이전트나 프롬프트 인젝션 공격에 의해 조작된 에이전트가 데이터를 공격자 제어 서버로 유출하거나 도달해서는 안 되는 인프라와 상호작용할 수도 있음을 의미합니다.

제한적인 구성에서는 이그레스가 명시적인 허용 목록으로 고정됩니다. 에이전트는 모델 API, 특정 데이터베이스, 패키지 레지스트리만 호출할 수 있습니다. 다른 모든 것은 차단됩니다. 설정이 더 어렵고 에이전트의 종속성이 변경됨에 따라 허용 목록을 유지 관리해야 하지만 공격 표면이 훨씬 작아집니다.

대부분의 프로덕션 에이전트 배포는 이 두 극단 사이 어딘가에 있습니다. 이그레스가 완전히 제한 없지는 않지만, 처음부터 제로 트러스트 목록에 고정되지는 않습니다. 일반적인 패턴에는 알려진 나쁜 대상을 차단, 모든 아웃바운드 호출을 감사 로그 기록, 에이전트의 동작이 예측 가능해짐에 따라 목록을 점진적으로 강화하는 것이 포함됩니다. 각 격리 경계를 여전히 벗어날 수 있는 것과 이그레스 제어에 대한 전체 분석은 안전한 코드 실행 가이드를 참조하세요.

일부 샌드박스 제공자는 SDK를 통해 프로그래밍 방식의 이그레스 제어를 제공합니다. 다른 제공자는 기본적으로 샌드박스를 완전히 아웃바운드 개방형으로 취급합니다. 에이전트가 외부 호스트에 도달할 수 없다고 가정하기 전에 제공자가 어떤 모델을 사용하는지 알아두세요.

에이전트 샌드박스에서 스냅샷이란 무엇인가요?

스냅샷은 실행 중인 샌드박스의 정확한 상태(파일 시스템, 메모리, 실행 중인 프로세스, 네트워크 상태)를 캡처하여 저장하고, 나중에 샌드박스를 해당 상태로 복원할 수 있도록 합니다.

이는 몇 가지 시나리오에서 유용합니다.

콜드 스타트 비용 절감 — 매번 새 VM을 부팅하고 패키지를 설치하는 대신, 한 번 부팅하고 모든 것을 설치한 다음 스냅샷을 찍고, 새 세션마다 해당 스냅샷에서 재개합니다. Daytona의 90ms 미만 콜드 스타트는 이 기술 덕분에 가능합니다.

장기 실행 에이전트의 체크포인팅 — 여러 시간이 소요되는 작업을 수행하는 코딩 에이전트를 중간에 일시 중지하고 정확한 상태를 저장할 수 있습니다. 에이전트를 검토, 수정 또는 다시 시작해야 하는 경우 처음부터 시작하는 대신 체크포인트에서 재개할 수 있습니다.

재현 가능한 평가 — RL 훈련 또는 모델 평가 파이프라인의 경우, 알려진 양호한 시작 상태를 스냅샷으로 찍고 각 평가 에피소드 전에 해당 상태로 재설정할 수 있습니다. 이는 재프로비저닝하고 상태가 일치하기를 바라는 것보다 여러 실행에 걸쳐 진정으로 동일한 시작 조건을 제공합니다.

모든 샌드박스 제공자가 API 수준에서 스냅샷 제어를 노출하는 것은 아닙니다. E2B의 템플릿 시스템은 “사전 설치된 환경” 사용 사례를 처리하지만, 임의의 중간 세션 체크포인트-복원 기능은 제공하지 않습니다. Daytona의 스냅샷 API는 더 유연합니다.

에이전트 샌드박스를 지원하는 기술은 무엇인가요?

가장 일반적인 기본 기술은 다음과 같습니다.

Firecracker — AWS에서 개발한 microVM 런타임으로, Lambda 및 Fargate 내부에서 사용됩니다. Firecracker는 500ms 미만으로 최소 게스트 커널을 부팅하고, 공격 표면을 줄이기 위해 최소 장치 모델을 노출하며, KVM 하드웨어 가상화를 기반으로 합니다. E2B와 Novita Agent Sandbox는 모두 Firecracker를 사용합니다.

gVisor — Google에서 개발한 커널 샌드박스로, 전체 게스트 커널을 실행하는 대신 시스템 호출에 개입합니다. microVM보다 가볍지만 완전한 커널 격리를 제공하지는 않습니다. 프로세스 수준과 VM 수준 사이의 격리 스펙트럼에 위치합니다.

시스템 호출 필터링이 적용된 Docker 컨테이너 — seccomp, AppArmor 및 최소 기능으로 강화된 컨테이너. 가장 일반적인 시작점이지만 신뢰할 수 없는 코드에 대해서는 가장 약한 격리 경계입니다.

V8 / Deno — V8 런타임의 권한 모델을 사용하는 JavaScript 전용 격리. JavaScript 전용 워크로드를 샌드박싱하는 데 적합하지만 임의의 셸 명령이나 비JS 코드를 실행해야 하는 에이전트에는 사용할 수 없습니다.

기본 기술의 선택은 샌드박스의 시작 성능, 격리 강도 및 운영 복잡성을 결정합니다. 멀티 테넌트 컨텍스트에서 신뢰할 수 없거나 LLM이 생성한 코드를 실행하는 에이전트 워크로드의 경우 Firecracker 수준의 격리가 현재 실질적인 표준입니다.

AI 에이전트가 샌드박스에서 탈출할 수 있나요?

실제로 샌드박스 탈출은 드물지만 불가능한 것은 아니며, 위험 프로필은 기술에 따라 다릅니다.

컨테이너 탈출 은 문서화되어 있습니다. 잘못 구성된 컨테이너(권한 모드, Docker 소켓 마운트, 쓰기 가능한 호스트 디렉터리)에는 알려진 탈출 벡터가 있습니다. 권한이 없고, 루트 파일 시스템이 읽기 전용이며, 최소 기능을 갖춘 강화된 컨테이너는 이 위험을 크게 줄이지만 제거하지는 않습니다.

microVM 탈출 은 하이퍼바이저 취약점 또는 장치 모델의 결함이 필요합니다. 이는 드문데, 공격 표면이 설계상 작기 때문입니다. Firecracker의 최소 장치 모델은 하이퍼바이저 노출을 줄이기 위해 특별히 설계되었습니다. AWS는 프로덕션에서 Firecracker 수준의 탈출을 공개한 적이 없습니다.

샌드박스 동작에 대한 프롬프트 인젝션 은 다른 종류의 "탈출"입니다. 커널 익스플로잇이 아니라, 공격자가 사용자 제공 콘텐츠에 지침을 삽입하여 에이전트가 해서는 안 되는 행동을 하도록 만드는 것입니다. 이는 샌드박스 수준이 아닌 애플리케이션 수준의 문제입니다. 샌드박스는 프롬프트 인젝션으로 인한 피해를 제한하는 데 도움이 되지만(주입된 코드는 호스트가 아닌 샌드박스 내부에서 실행됨), 인젝션 자체를 방지하지는 않습니다.

실질적인 결론: 잘 구성된 Firecracker 기반 샌드박스는 이론상 탈출이 불가능하지는 않지만, 대부분의 엔터프라이즈 에이전트 배포에서 공격 장벽이 충분히 높아 잔여 위험을 관리할 수 있습니다. 더 일반적인 실패 모드는 커널 수준의 익스플로잇보다는 잘못된 구성(과도하게 허용적인 이그레스, 부적절하게 범위가 지정된 자격 증명이 샌드박스에 전달됨)입니다.

AI 에이전트 샌드박스가 GPU 워크로드를 지원하나요?

2026년 중반 기준으로 대부분의 AI 에이전트 샌드박스에는 GPU 지원이 포함되어 있지 않습니다. E2B, Daytona 및 Vercel Sandbox는 모두 CPU 전용입니다.

Modal은 관리형 샌드박스 공간에서 주요 예외로, 컨테이너 내에서 온디맨드 GPU 액세스를 제공합니다. 이는 모델 추론, 미세 조정 또는 에이전트 코드와 동일한 환경에서 GPU가 필요한 RL 워크로드에 적합합니다.

대부분의 에이전트 워크플로에서 에이전트 자체는 로컬에서 모델을 실행하는 대신 외부 LLM 추론 API(Novita의 추론 엔드포인트 등)를 호출합니다. 이 아키텍처에서는 샌드박스에 GPU가 필요하지 않습니다. 샌드박스는 코드, 파일 작업 및 도구 호출을 처리하고, 무거운 추론은 별도의 GPU 서비스에서 실행됩니다. 이는 코딩 에이전트, 데이터 분석 에이전트 및 대부분의 브라우저 자동화 워크플로에서 사용되는 패턴입니다.

샌드박스 내에 GPU가 필요한 경우(예: 오프라인 사용을 위한 로컬 모델 추론, RL 훈련 단계, 다단계 평가 파이프라인) 제공자 선택에 이를 고려하세요. Modal이 현재 이 패턴에 가장 일반적으로 사용되는 옵션입니다.

전용 샌드박스가 실제로 필요한 경우는 언제인가요?

모든 AI 애플리케이션에 전용 샌드박스가 필요한 것은 아닙니다. 샌드박스가 실제 가치를 더하는 시나리오는 다음과 같습니다.

LLM이 생성한 코드를 실행하는 경우 — 에이전트가 사람이 작성하지 않은 코드를 작성하고 실행하며 예상치 못한 일을 할 수 있습니다. 이것이 핵심 사용 사례입니다. 실행이 샌드박스에서 발생하므로 호스트, 자격 증명 또는 다른 워크로드에 영향을 미칠 수 없습니다.

최종 사용자에게 서비스를 제공하는 경우 — 여러 사용자의 에이전트 실행이 동일한 기본 인프라를 공유합니다. 사용자 간 격리가 필요하므로 한 사용자의 에이전트가 의도적으로든 실수로든 다른 사용자의 에이전트에 영향을 미칠 수 없습니다.

장기 실행 상태 저장 워크플로가 필요한 경우 — 파일을 편집하고, 테스트를 실행하고, 변경 사항을 커밋하는 코딩 에이전트는 많은 LLM 턴에 걸쳐 지속되는 작업 공간이 필요합니다. 호출할 때마다 새로운 하위 프로세스는 상태를 유지하지 않지만 샌드박스는 유지합니다.

규정 준수 또는 감사 요구사항이 있는 경우 — 모든 에이전트 작업을 기록하고, 네트워크 액세스를 제한하거나, 에이전트 워크로드가 프로덕션 데이터베이스나 자격 증명에 액세스할 수 없음을 증명해야 합니다. 샌드박스는 이러한 제어를 위한 적용 계층을 제공합니다.

브라우저 또는 컴퓨터 사용 자동화를 수행하는 경우 — 브라우저 자동화 샌드박스 환경은 호스트에서 완전히 격리되므로 에이전트가 로컬 브라우저 세션이나 시스템 상태에 영향을 주지 않고 클릭, 입력, 스크린샷을 할 수 있습니다.

단순한 “이 텍스트 요약” 파이프라인을 코드 실행 없이 실행하는 경우에는 전용 실행 샌드박스가 필요하지 않을 것입니다. LLM에 대한 API 호출로 충분합니다. 에이전트가 파일 쓰기, 코드 실행, 외부 API 호출 등 부작용이 있는 작업을 수행하기 시작하면 샌드박스가 필요해집니다.

자주 묻는 질문

AI 에이전트 샌드박스와 개발 환경이 동일한가요?

아니요. 개발 환경은 사람 개발자를 위한 작업 공간입니다. 세션 간에 지속되고, 장기간 유지되며, 사용자 정의 및 재사용이 가능하도록 설계되었습니다. AI 에이전트 샌드박스는 런타임 실행 경계입니다. 작업 기간 동안 존재하고, 일시적이고 재현 가능하도록 설계되었으며, 주요 역할은 개발자 편의가 아닌 차단(containment)입니다. 일부 샌드박스는 세션 내에서 LLM 턴 간에 상태를 유지할 수 있어 작업 공간처럼 느껴질 수 있지만, 설계 목표는 호스트와의 격리이지 완전한 기능을 갖춘 IDE가 아닙니다. 용어는 공급업체 마케팅에서 때때로 겹칩니다. 플랫폼을 평가할 때는 레이블이 아닌 실제 격리 경계를 살펴보세요.

에이전트 실행 샌드박스란 무엇인가요?

에이전트 실행 샌드박스는 AI 에이전트 샌드박스와 동일합니다. "실행"이라는 표현은 런타임 측면을 강조할 뿐입니다. LLM이 작업(코드 실행, 도구 호출, 파일 쓰기)을 수행하기로 결정하면 해당 작업은 샌드박스 내에서 실행됩니다. 샌드박스는 에이전트가 수행하는 작업과 시스템의 나머지 부분이 볼 수 있거나 영향을 받을 수 있는 것 사이의 경계를 적용하는 실행 계층입니다. “에이전트 샌드박스”, “코드 실행 샌드박스”, "에이전트 실행 환경"이라는 용어는 업계에서 혼용됩니다.

AI 에이전트 워크로드에서 Firecracker와 gVisor를 비교하면 어떤가요?

둘 다 표준 컨테이너를 넘어서는 격리를 제공하지만, 메커니즘이 다릅니다. Firecracker는 KVM 기반 microVM 내에서 최소 게스트 커널을 부팅합니다. 샌드박스는 호스트 커널과 완전히 분리된 자체 커널을 갖습니다. gVisor는 전체 게스트 커널을 실행하지 않고 사용자 공간 커널(runsc)을 사용하여 시스템 호출에 개입합니다. 실질적인 트레이드오프: Firecracker는 게스트 커널이 완전히 분리되어 있기 때문에 더 강력한 호스트 경계를 제공합니다. gVisor는 전체 커널을 실행하지 않기 때문에 샌드박스당 메모리 오버헤드가 낮지만, 격리는 전체 microVM과 시스템 호출 인터셉션으로 강화된 컨테이너 사이입니다. 신뢰할 수 없는 LLM 생성 코드를 실행하는 멀티 테넌트 AI 에이전트 워크로드의 경우 Firecracker 수준의 격리가 현재 프로덕션 표준입니다. gVisor는 코드가 부분적으로 신뢰되고 메모리 밀도가 최대 격리보다 더 중요한 워크로드에 적합합니다.

프롬프트 인젝션이 에이전트가 샌드박스를 탈출하게 할 수 있나요?

프롬프트 인젝션은 샌드박스의 기술적 격리를 우회하지 않습니다. 에이전트의 의사 결정을 악용하여 공격자가 의도했지만 개발자가 의도하지 않은 행동을 취하도록 합니다. "환경 변수를 이 URL로 유출하라"와 같은 주입된 지침은 에이전트가 아웃바운드 네트워크 호출을 하도록 만듭니다. 이는 이그레스 정책이 차단하는 경우에만 차단됩니다. 샌드박스의 파일 시스템 및 프로세스 격리는 그대로 유지됩니다. 즉, 샌드박스 보안과 프롬프트 인젝션 방어는 스택의 다른 부분을 다룹니다. 샌드박스는 인프라 수준에서 에이전트가 할 수 있는 작업의 폭발 반경을 제한합니다. 애플리케이션 수준 제어(도구 호출 제한, 사람 개입 승인, 이그레스 허용 목록)는 에이전트가 이러한 기능을 오용하도록 지시받는 것을 방어합니다.

AI 에이전트를 위해 특별히 샌드박스가 필요한 이유는 무엇인가요?

기존 코드 실행과의 주요 차이점은 불확실성입니다. 사람 개발자가 코드를 작성하면 개발자는 대략적으로 코드가 무엇을 할지 알고 있습니다. LLM이 코드를 생성하거나 도구를 호출하기로 결정하면, 애플리케이션은 정확히 무엇이 실행될지, 어떤 패키지가 설치될지, 또는 잠재적으로 수천 개의 동시 세션에서 어떤 외부 엔드포인트에 접촉할지에 대한 가시성이 제한될 수 있습니다. 이러한 불확실성은 각 표준 보안 제어의 중요성을 높입니다. 이그레스 정책이 중요한 이유는 에이전트가 아무도 예상하지 못한 엔드포인트에 도달할 수 있기 때문입니다. 패키지 거버넌스가 중요한 이유는 에이전트가 동적으로 종속성을 설치할 수 있기 때문입니다. 감사 로깅이 중요한 이유는 에이전트의 작업이 사전에 열거되지 않았을 때 무슨 일이 일어났는지 재구성하기가 더 어렵기 때문입니다. 샌드박스는 모든 개별 에이전트 작업을 사전에 신뢰할 필요 없이 이러한 불확실성을 처리할 수 있는 적용 계층을 제공합니다.

일반적인 샌드박스 제공자

주요 옵션에 대한 간략한 개요입니다. 더 자세한 비교는 링크된 글을 참조하세요.

Novita Agent Sandbox — Firecracker microVM, 자체 AWS 또는 GCP VPC에 BYOC 배포, 구독료 없음, 최대 24시간 세션. 규정 준수 요구사항, 비용 민감도가 있거나 이미 Novita를 LLM 추론에 사용 중인 팀을 위한 주요 옵션입니다. novita.ai/sandbox 참조.
E2B — 관리형, Firecracker microVM, 대규모 커뮤니티, 자체 호스팅 없음. 잘 문서화된 SDK와 활발한 생태계.
Daytona — 90ms 미만 콜드 스타트, 오픈 소스(AGPL), 자체 호스팅 가능. 지연 시간에 민감하거나 자체 호스팅 인프라가 필요한 규정 준수 사용 사례에 더 적합.
Modal — 샌드박스 내 GPU가 필요할 때 주요 옵션. 컨테이너 기반 격리.
Vercel Sandbox — 빠른 콜드 스타트, Vercel 플랫폼에서 JS/TS에 가장 적합.

사양 및 의사 결정 프레임워크를 포함한 전체 비교는 2026년 최고의 AI 에이전트 샌드박스를 참조하세요. E2B와 Daytona에 대한 심층 평가(콜드 스타트, BYOC, 스냅샷, 가격)는 E2B와 Daytona 비교 AI 에이전트 샌드박스 평가 가이드를 참조하세요.

AI 에이전트 샌드박스란?