AI 에이전트 샌드박스란 무엇인가?

AI 에이전트 샌드박스란 무엇인가요?
에이전트 샌드박스는 일반 컨테이너와 어떻게 다른가요?
AI 에이전트의 맥락에서 격리(isolation)란 무엇인가요?
이그레스 필터링이란 무엇이며 왜 중요한가요?
샌드박스에서 비밀 정보와 자격 증명은 어떻게 범위가 지정되나요? {#secrets-and-credentials}
AI 에이전트 샌드박스에서 감사 로그는 어떻게 작동하나요? {#audit-logs}
샌드박스에서 스냅샷이란 무엇인가요?
에이전트 샌드박스를 구동하는 기술은 무엇인가요?
AI 에이전트가 샌드박스에서 탈출할 수 있나요?
AI 에이전트 샌드박스는 GPU 워크로드를 지원하나요?
전용 샌드박스가 실제로 필요한 때는 언제인가요?
코드 인터프리터와 에이전트 런타임의 차이점은 무엇인가요? {#code-interpreter-vs-agent-runtime}
AI 생성 코드를 안전하게 실행하려면 어떻게 해야 하나요? {#run-ai-generated-code-safely}
자주 묻는 질문
일반적인 샌드박스 제공업체
추천 문서

AI 에이전트 샌드박스는 AI 에이전트가 코드를 실행하고, 도구를 호출하며, 파일 시스템이나 브라우저와 상호작용할 수 있지만 호스트 시스템, 인접 워크로드, 또는 민감한 인프라에는 영향을 미칠 수 없도록 하는 격리된 실행 환경입니다. 샌드박스는 경계를 만듭니다: 내부에서 일어난 일은 내부에 머무르고, 외부에서 일어나는 일은 명시적으로 허용하지 않는 한 내부에서 접근할 수 없습니다. Novita Agent Sandbox는 이 패턴의 한 구현체입니다 — Firecracker 마이크로VM 격리, 자체 AWS 또는 GCP VPC에 배포하는 BYOC, 그리고 순수한 종량제 가격 모델을 제공합니다 — 하지만 여기서 설명하는 개념은 모든 샌드박스 플랫폼에 적용됩니다. 이 글에서는 해당 경계가 어떻게 작동하는지, 트레이드오프는 무엇인지, 그리고 실제로 언제 필요한지에 대한 가장 일반적인 질문에 답변합니다. 격리, 비밀 정보, 이그레스, 규정 준수 요구사항에 대한 더 자세한 Q&A는 AI 에이전트 샌드박스 FAQ를 참조하세요.

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

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

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

샌드박스는 또한 클라우드 제공업체의 과금 및 리소스 회계 단위로 사용됩니다. E2B, Daytona, 또는 Novita Agent Sandbox와 같은 SDK를 호출하면 샌드박스 인스턴스를 생성하고, 내부에서 작업을 실행한 다음, 종료하는 방식이며, 제공업체는 소비한 컴퓨팅 양에 따라 요금을 청구합니다.

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

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

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

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

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

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

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

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

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

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

리소스 격리 — CPU 및 메모리 할당이 제한됩니다. 무한 루프에 빠지거나 대량의 출력을 생성하는 에이전트가 동일한 호스트의 다른 샌드박스에 영향을 주지 않습니다. 리소스 제한이 VM 또는 컨테이너 수준에서 적용되기 때문입니다.

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

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

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

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

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

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

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

샌드박스에서 비밀 정보와 자격 증명은 어떻게 범위가 지정되나요? {#secrets-and-credentials}

샌드박스에 전달되는 비밀 정보는 해당 특정 에이전트 실행에 필요한 것만으로 범위를 지정해야 하며, 장기 자격 증명을 디스크에 쓰는 대신 환경 변수나 단기 토큰으로 전달해야 합니다. 샌드박스 경계는 폭발 반경을 제한하지만, 환경 내에서 접근할 수 있는 모든 자격 증명을 에이전트가 읽고 전달하는 것을 자동으로 방지하지는 않습니다.

핵심 원칙은 최소 권한(least privilege)입니다: 루트 클라우드 키나 광범위한 권한을 가진 서비스 계정이 아닌, 작동하는 가장 좁은 범위의 자격 증명을 전달하세요. 일반적인 패턴:

시작 시 환경 변수 — 시작 시 샌드박스 환경에 비밀 정보를 주입합니다. 에이전트의 코드에서 사용할 수 있지만 파일 시스템 스냅샷에 유지되거나 기본적으로 로그에 나타나지 않습니다. 정적 API 키보다는 단기 토큰을 선호하세요.

DNS 수준 차단 — 일부 배포 구성에서는 샌드박스 내부에서 확인할 수 있는 DNS 이름을 제한할 수 있습니다. 이는 개별 IP가 아닌 DNS 계층에서의 확인을 차단함으로써, 에이전트가 네트워크 접근 권한이 있더라도 자격 증명 유출 엔드포인트에 접촉하는 것을 방지합니다.

짧은 TTL을 가진 범위 지정 서비스 계정 — 클라우드 API를 호출하는 에이전트의 경우, 수명이 짧은 역할 전환 체인을 사용하세요. 자격 증명이 유출되더라도 공격자의 시간 창은 토큰 수명으로 제한됩니다.

호스트 자격 증명 파일 없음 — 호스트 자격 증명 파일(예: ~/.aws/credentials)을 샌드박스 파일 시스템에 마운트하지 마세요. 대신 세션별로 새로운 단기 자격 증명을 생성하세요.

샌드박스는 프로세스 수준의 경계를 제공합니다. 무엇을 샌드박스에 전달할지는 사용자의 책임입니다.

AI 에이전트 샌드박스에서 감사 로그는 어떻게 작동하나요? {#audit-logs}

에이전트 샌드박스의 감사 로그는 일반적으로 두 가지 수준을 다룹니다: 플랫폼 수준 이벤트(샌드박스 생성, 시작, 중지, 시간 초과)와 애플리케이션 수준 이벤트(실행된 명령어, 수정된 파일, 외부 API 호출)입니다. 대부분의 관리형 제공업체는 플랫폼 이벤트를 자동으로 내보내지만, 애플리케이션 수준 로깅은 사용자가 계측해야 할 책임입니다.

의미 있는 감사 범위를 위해 캡처해야 할 사항:

샌드박스 수명 주기 이벤트 — 생성 타임스탬프, 세션 지속 시간, 종료 사유(정상 종료, 시간 초과 또는 충돌). 대부분의 관리형 플랫폼은 이를 자동으로 로깅하고 API 또는 대시보드를 통해 노출합니다.

아웃바운드 네트워크 호출 — 에이전트가 접촉한 호스트와 타임스탬프. 이는 이그레스 로깅과 감사 로깅이 겹치는 부분입니다. 플랫폼이 이그레스 로깅을 지원하는 경우 활성화하고 출력을 로그 수집기로 라우팅하세요.

코드 실행 입력/출력 — 에이전트가 실행한 명령어와 받은 결과. 이는 애플리케이션 수준이며, 샌드박스 인프라 계층이 아닌 에이전트 프레임워크에서 캡처해야 합니다.

파일 시스템 변경 사항 — 작성, 삭제 또는 수정된 파일. 코딩 에이전트 및 데이터 처리 파이프라인과 관련이 있습니다. 일부 샌드박스 플랫폼은 세션 종료 시 파일 시스템 diff API를 노출합니다. 다른 플랫폼은 에이전트 코드에서 계측이 필요합니다.

규정 준수 사용 사례(SOC 2, HIPAA, 규제 산업)의 경우, 일반적으로 변조 방지 저장소의 플랫폼 수준 로그와 에이전트 프레임워크의 애플리케이션 수준 로그가 결합되어 필요합니다. 적용 범위를 가정하기 전에 제공업체가 실제로 무엇을 내보내고 무엇을 명시적으로 활성화해야 하는지 확인하세요.

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

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

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

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

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

재현 가능한 평가 — 강화 학습 훈련 또는 모델 평가 파이프라인의 경우, 알려진 양호한 시작 상태를 스냅샷으로 저장하고 각 평가 에피소드 전에 해당 상태로 재설정할 수 있습니다. 이를 통해 다시 프로비저닝하고 상태가 일치하기를 기대하는 것보다 많은 실행에서 진정으로 동일한 시작 조건을 얻을 수 있습니다.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

코드 인터프리터와 에이전트 런타임의 차이점은 무엇인가요? {#code-interpreter-vs-agent-runtime}

코드 인터프리터는 단일 코드 조각을 격리된 환경에서 실행하고 출력을 반환합니다. 기본적으로 상태 비저장(stateless)입니다: 각 실행은 깨끗하게 시작되고, 결과가 반환되며, 아무것도 유지되지 않습니다. 호출 간에 상태를 공유하지 않는 샌드박스된 Jupyter 커널이라고 생각하면 됩니다. 이는 상태가 실행 간에 필요하지 않은 데이터 분석, 수식 평가 또는 일회성 코드 실행에 적합한 도구입니다.

에이전트 런타임은 다단계 워크플로를 위해 설계된 지속적이고 상태 저장(stateful) 실행 환경입니다. 에이전트는 파일을 쓰고, 패키지를 설치하고, 백그라운드 프로세스를 실행하고, 네트워크 호출을 하고, 많은 LLM 턴에 걸쳐 작업 공간 상태를 축적할 수 있습니다 — 단계 간에 컨텍스트를 잃지 않습니다. 파일을 편집하고, 테스트를 실행하고, 오류 출력을 읽고, 반복하는 코딩 에이전트는 코드 인터프리터가 아닌 에이전트 런타임에서 작동합니다.

이 구분은 도구 설계에 중요합니다:

	코드 인터프리터	에이전트 런타임
호출 간 상태	없음 (실행마다 새로 시작)	세션 내에서 지속
파일 시스템 접근	일반적으로 호출별로 격리	지속적 작업 공간
다단계 워크플로	설계되지 않음	핵심 사용 사례
일반적인 세션 길이	초	분에서 시간
예시	Jupyter 커널, 단일 코드 셀	E2B, Daytona, Novita Agent Sandbox

실제로는 경계가 모호해집니다. E2B 및 대부분의 관리형 샌드박스 플랫폼은 코드 인터프리터처럼 동작할 수 있지만(하나의 코드 조각을 실행하고 출력 반환), 그 아래에는 전체 에이전트 런타임 인프라(지속적 파일 시스템, 프로세스 관리, 네트워크 액세스)를 제공합니다. OpenAI의 Code Interpreter와 같은 플랫폼은 상태 비저장 사용 사례에 특화되어 있으며, 에이전트 런타임이 제공하는 유연성에 대해 의도적인 트레이드오프를 합니다.

상태 요구사항이 없는 단일 작업을 위한 빠르고 격리된 실행 환경이 필요할 때는 코드 인터프리터를 선택하세요. 워크로드에 반복적인 파일 편집, 설치된 패키지 종속성, 장기 실행 프로세스 또는 중단된 지점에서 다시 시작해야 하는 모든 워크플로가 포함된 경우 에이전트 런타임을 선택하세요.

AI 생성 코드를 안전하게 실행하려면 어떻게 해야 하나요? {#run-ai-generated-code-safely}

프로덕션에서 AI 생성 코드를 안전하게 실행하려면 모든 계층에서 적절한 제어가 필요합니다 — 샌드박스는 실행 경계를 처리하지만, 사용자가 내려야 할 애플리케이션 수준의 결정도 있습니다.

신뢰할 수 없는 코드에는 컨테이너가 아닌 마이크로VM 수준 격리를 사용하세요. Firecracker 기반 샌드박스(E2B, Novita Agent Sandbox)는 LLM이 생성한 코드를 자체 커널이 있는 VM 내부에 넣습니다. 컨테이너 탈출은 문서화되어 있고 알려진 벡터가 있습니다. 마이크로VM 수준 탈출은 하이퍼바이저 취약점이 필요하며 설계상 드뭅니다. 코드가 사람이 검토하지 않은 경우 콜드 스타트 비용은 더 강력한 경계를 위해 감수할 가치가 있습니다.

이그레스를 에이전트가 실제로 필요한 것만으로 제한하세요. 데이터 분석 코드를 실행하는 에이전트는 임의의 인터넷 호스트에 도달할 필요가 없을 것입니다. 이그레스를 모델 API, 특정 패키지 레지스트리 및 작업에서 명시적으로 요구하는 외부 서비스로만 제한하세요. BYOC 배포에서는 VPC 보안 그룹 수준에서 이를 시행할 수 있습니다. 관리형 배포에서는 제공업체의 이그레스 제어를 사용할 수 있으면 사용하고, 그렇지 않으면 제한되지 않은 이그레스를 알려진 위험으로 받아들이고 로깅하세요.

범위가 지정되고 수명이 짧은 자격 증명만 전달하세요. 샌드박스에 프로덕션 데이터베이스, 루트 클라우드 키 또는 광범위한 서비스 계정에 대한 액세스 권한을 부여하지 마세요. 현재 작업에 필요한 것만 짧은 TTL의 자격 증명으로 전달하세요. 생성된 코드가 자격 증명을 읽고 유출하더라도 피해는 제한됩니다.

시간 제한과 리소스 제한을 적용하세요. 실행에 명시적인 시간 및 메모리 제한을 설정하세요. LLM이 생성한 무한 루프나 예상치 못한 대규모 출력은 세션을 무기한 소모하거나 디스크를 가득 채우지 않고 정상적으로 종료되어야 합니다.

처음부터 이그레스와 명령어 기록을 로깅하세요. 에이전트가 무엇을 했는지에 대한 기록이 없으면 예상치 못한 동작을 조사할 수 없습니다. 개발 중에도 이그레스 로깅을 일찍 활성화하세요. 실행된 명령어, 파일 쓰기 및 외부 호출에 대한 애플리케이션 수준 로깅은 사용자의 책임입니다 — 샌드박스 인프라가 이를 자동으로 수행하지는 않습니다.

어떤 구성도 위험을 완전히 제거하지는 않습니다. 목표는 알려지고 제한된 잔여 위험입니다: 에이전트가 사용자가 작성하지 않은 코드를 강력한 격리 경계 내에서, 필요한 최소 자격 증명과 네트워크 액세스 권한으로 실행하며, 예상치 못한 동작을 감지하고 진단할 수 있는 충분한 로깅을 갖추는 것입니다.

자주 묻는 질문

AI 에이전트 샌드박스는 개발 환경과 같은가요?

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

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

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

Firecracker는 AI 에이전트 워크로드에서 gVisor와 어떻게 비교되나요?

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

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

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

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

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

일반적인 샌드박스 제공업체

주요 옵션에 대한 간략한 개요이며, 더 자세한 비교는 링크된 문서를 참조하세요:

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

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