AI 에이전트 샌드박스는 생성된 코드를 호스트 시스템으로부터 격리하지만, 격리가 작동하는 방식, 에이전트의 네트워크 접근 권한, 파일이 저장되는 위치, 비밀 정보 처리 방법 등 세부 사항은 구현에 따라 크게 다릅니다. 이 FAQ는 가장 일반적인 질문을 하나의 참고 자료로 통합하고 각 영역에 대한 심층 문서를 안내합니다. 샌드박스가 처음이라면 AI 에이전트 샌드박스란 무엇인가?에서 격리 모델, 이그레스, 스냅샷 생성에 대한 기초를 다지세요. 제공업체를 선택 중이라면 2026년 최고의 AI 에이전트 샌드박스 또는 E2B vs. Daytona 평가 가이드를 참조하세요.
AI 에이전트를 샌드박싱하는 이유
팀에서 AI 에이전트를 위해 전용 샌드박스를 사용하는 이유는 무엇인가요?
AI 에이전트는 기존 소프트웨어와 한 가지 중요한 점에서 다릅니다. 에이전트가 실행하는 코드는 사람이 작성하고 실행 전에 검토하는 것이 아닙니다. LLM이 명령을 생성하고, 도구를 선택하고, 패키지를 설치하고, API 호출을 동적으로 수행합니다. 이는 종종 애플리케이션 개발자가 사전에 열거하지 않은 방식으로 이루어집니다. 샌드박스는 모든 가능한 동작을 사전 승인할 필요 없이 해당 동작의 결과를 제한하는 런타임 시행 계층을 제공합니다. 샌드박스가 없으면 오작동하거나 조작된 에이전트가 호스트 시스템, 인접 워크로드 또는 외부 인프라에 영향을 줄 수 있습니다. 샌드박스를 사용하면 최악의 폭발 반경이 격리된 환경으로 제한되며, 세션 후에 폐기할 수 있습니다.
AI 에이전트 코드 실행이란 무엇인가요?
AI 에이전트 코드 실행은 LLM의 결정이 컴퓨터가 실행하는 실제 명령어가 되는 런타임 단계입니다. 에이전트가 작업을 받고 추론하며 코드나 도구 호출을 생성하면, 실행 계층이 해당 작업을 실행하고 결과를 에이전트에 반환합니다. 샌드박스는 이 실행 단계를 위한 표준 인프라 계층입니다. 즉, 에이전트가 필요한 컴퓨팅, 파일 시스템, 네트워크 환경을 제공하면서 동시에 해당 환경을 다른 모든 것과 격리 상태로 유지합니다. "모델 추론 → 실행 계층 실행 → 결과가 모델로 피드백"되는 주기는 에이전트가 작업을 완료할 때까지 반복됩니다.
샌드박싱이 컨테이너에서 에이전트를 실행하는 것과 어떻게 다른가요?
컨테이너는 파일 시스템 및 네트워크 네임스페이스 분리를 추가하지만, 동일한 호스트의 모든 컨테이너는 OS 커널을 공유합니다. 신뢰할 수 없는 입력에서 LLM이 생성한 코드를 실행하는 AI 에이전트의 경우, 공유된 취약점을 통한 커널 수준 이스케이프는 인접 워크로드에 영향을 줄 수 있습니다. 전용 AI 에이전트 샌드박스는 일반적으로 마이크로VM 경계를 추가합니다. 에이전트의 코드는 자체 게스트 커널을 갖춘 경량 가상 머신 내부에서 실행되므로, 게스트의 커널 수준 익스플로잇이 호스트에 영향을 미치지 않습니다. 실제 트레이드오프는 약간의 추가 콜드 스타트 오버헤드(일반적으로 Firecracker 기반 플랫폼의 경우 500ms 미만)입니다. 전체 비교는 격리 모델 섹션을 참조하세요.
샌드박스 격리 모델
AI 에이전트 샌드박스에서 "격리"란 무엇을 의미하나요?
격리란 에이전트의 코드, 파일, 프로세스 및 네트워크 액세스가 호스트 시스템이나 다른 테넌트에 영향을 줄 수 없는 경계가 있는 환경으로 제한됨을 의미합니다. 실제로 격리는 스펙트럼입니다. 프로세스 수준 격리는 OS 프리미티브(네임스페이스, cgroups, seccomp)를 사용하여 시스템 콜 및 리소스 액세스를 제한합니다. 컨테이너 격리는 파일 시스템 및 네트워크 네임스페이스 경계를 추가합니다. 마이크로VM 격리는 워크로드를 자체 게스트 커널을 갖춘 경량 가상 머신으로 감쌉니다. 스택의 각 단계는 경계 강도를 증가시키지만 일부 시작 오버헤드와 운영 복잡성이 발생합니다. 모든 격리 차원에 대한 포괄적인 개요는 AI 에이전트 샌드박스란 무엇인가?를 참조하세요. 자세한 평가 프레임워크는 AI 에이전트 샌드박스를 위한 Firecracker를 참조하세요.
에이전트 생성 코드를 실행하기에 Docker로 충분한가요?
컨테이너는 반복 가능한 이미지와 우수한 리소스 제어를 제공하지만, 동일한 호스트의 모든 컨테이너는 호스트 커널을 공유합니다. 커널 취약점이나 seccomp 필터를 우회하는 시스템 콜은 다른 워크로드에 영향을 줄 수 있습니다. 신뢰할 수 있거나 거의 신뢰할 수 있는 코드를 실행하는 단기, 저위험 작업의 경우 적절하게 강화된 컨테이너(권한 모드 비활성화, 최소 기능, Docker 소켓 미마운트, 가능한 읽기 전용 루트 파일 시스템)로 충분한 경우가 많습니다. 패키지를 설치하거나 하위 프로세스를 생성하거나 임의의 셸 명령을 호출할 수 있는 신뢰할 수 없는 AI 생성 코드의 경우 더 강력한 경계를 평가할 가치가 있습니다. 정답은 실제 위협 모델에 따라 다릅니다. 각 격리 수준의 확인 체크리스트는 AI 생성 코드 샌드박스: 프로덕션 앱 요구 사항을 참조하세요.
컨테이너 격리와 마이크로VM 격리의 차이점은 무엇인가요?
핵심 차이는 커널 경계입니다. 컨테이너는 호스트 커널을 공유합니다. 마이크로VM은 각각 하드웨어 가상화(KVM)를 기반으로 하는 경량 가상 머신 내에서 게스트 커널을 실행합니다. Firecracker와 같은 기술을 사용하는 마이크로VM 기반 샌드박스는 기존 VM의 전체 오버헤드 없이 VM 스타일 경계를 제공합니다. 시작 지연 시간이 빠르게 설계되었고, 장치 모델이 최소화되어 공격 표면을 줄이며, 게스트는 설계상 호스트 커널로부터 격리됩니다. 실제 의미는 게스트의 커널 익스플로잇이 자동으로 호스트나 다른 게스트에 영향을 미치지 않는 반면, 공유 커널 컨테이너 모델에서는 영향을 미칠 수 있다는 것입니다. 마이크로VM 경계가 도움이 되는 경우와 전체 문제를 해결하지 못하는 경우는 AI 에이전트 샌드박스를 위한 Firecracker를 참조하세요.
하나의 샌드박스는 에이전트, 사용자 또는 작업별로 존재하나요?
이는 플랫폼과 애플리케이션 설계 방식에 따라 다릅니다. 멀티 테넌트 앱의 가장 안전한 패턴은 에이전트 실행 또는 작업별로 하나의 격리된 샌드박스 환경을 사용하는 것입니다. 즉, 각 사용자의 세션에는 자체 프로세스 트리, 파일 시스템, 네트워크 네임스페이스 및 자격 증명 범위가 있습니다. 사용자 간 또는 관련 없는 작업 간에 샌드박스를 공유하는 것은 프로덕션 에이전트 앱에서 상태 누출의 가장 일반적인 원인입니다. 플랫폼을 평가할 때 동시 세션이 API 라우팅 수준뿐만 아니라 파일 시스템, 프로세스 및 네트워크 수준에서 격리되는지 확인하세요. 세션별 격리 체크리스트는 AI 생성 코드 샌드박스: 프로덕션 앱 요구 사항을 참조하세요.
샌드박스 이그레스 및 네트워크 정책
AI 에이전트가 샌드박스에서 아웃바운드 네트워크 호출을 할 수 있나요?
이는 샌드박스의 이그레스 정책에 따라 다릅니다. 기본적으로 많은 샌드박스가 아웃바운드 연결을 허용하므로 웹 검색, API 호출, 패키지 설치에 편리합니다. 신뢰할 수 없는 코드를 실행하는 프로덕션 워크로드의 경우 기본 개방형 이그레스는 위험합니다. 손상되거나 오작동하는 에이전트가 데이터를 유출하거나, 내부 메타데이터 서비스에 도달하거나, 임의 URL에서 예상치 못한 코드를 가져올 수 있습니다. 더 강력한 프로덕션 태세는 허용된 대상의 명시적 허용 목록을 사용한 기본 거부 이그레스입니다. 어떤 정책을 선택하든 명시적이고 기록되어야 합니다. 네트워크 제어를 평가하는 방법은 AI 에이전트 샌드박스를 위한 Firecracker를 참조하세요.
샌드박스에서 DNS는 어떻게 제어되나요?
DNS는 이그레스 정책의 일반적인 격차입니다. HTTP 대상에 대한 허용 목록이 DNS 확인을 자동으로 제한하지는 않습니다. 임의의 도메인 이름을 확인할 수 있는 에이전트는 네트워크 토폴로지를 유추하고, 내부 이름을 프로빙하거나, HTTP가 차단된 경우에도 DNS를 사이드 채널로 사용할 수 있습니다. 일관된 이그레스 정책을 위해 DNS 확인은 허용 목록을 존중하는 내부 확인자를 가리키거나 승인된 도메인으로 확인을 제한하는 방식으로 일관되게 처리되어야 합니다. 광범위한 이그레스 정책과 관련하여 DNS가 어떻게 범위가 지정되는지 샌드박스 제공업체에 확인하세요.
네트워크가 제한된 세션 중 패키지 가져오기는 어떻게 제어되나요?
패키지 설치는 네트워크 작업입니다. 이그레스가 허용 목록으로 제한된 경우, 허용 목록에는 에이전트가 합법적으로 필요로 하는 패키지 레지스트리가 포함되어야 하거나 샌드박스가 신뢰할 수 있는 네트워크 내에 풀스루 캐시를 제공해야 합니다. 풀스루 캐시는 검사 지점 역할을 하는 추가 이점이 있습니다. 가져온 패키지를 확인하고, 예기치 않은 종속성을 포착하고, 중복 이그레스를 줄일 수 있습니다. 일부 팀은 재현성이 유연성보다 중요한 워크로드에 대해 사전 구축된 샌드박스 템플릿을 사용하여 런타임 패키지 가져오기를 완전히 제거합니다. 런타임 설치를 관리하는 방법에 대한 자세한 내용은 패키지 설치 섹션을 참조하세요.
파일 액세스 및 호스트 파일 시스템
샌드박스 에이전트는 어떤 파일 액세스 권한이 있나요?
샌드박스 에이전트는 작업 공간에 명시적으로 마운트된 파일에만 액세스할 수 있어야 합니다. 코딩 에이전트의 경우 체크아웃된 리포지토리와 생성된 아티팩트를 위한 작업 디렉토리가 될 수 있습니다. 데이터 분석 에이전트의 경우 업로드된 CSV 파일과 출력 폴더가 될 수 있습니다. 에이전트는 호스트 파일 시스템, 다른 테넌트의 작업 공간, 애플리케이션 서버의 비밀 정보 또는 마운트된 경로 외부의 시스템 디렉토리에 도달할 수 없어야 합니다. 좋은 방법은 소스 자료를 읽기 전용으로 마운트하고 생성된 아티팩트를 위한 별도의 읽기-쓰기 출력 디렉토리를 제공하는 것입니다. 도구별 파일 시스템 마운트 범위를 지정하는 방법은 MCP 서버 샌드박스: 파일 시스템, 비밀, 네트워크 제어를 사용한 격리된 MCP 서버를 참조하세요.
샌드박스 내부에서 호스트 파일 시스템에 액세스할 수 있나요?
그래서는 안 됩니다. 올바르게 구성된 샌드박스(컨테이너 또는 마이크로VM)는 에이전트의 보기를 자체 게스트 파일 시스템으로 제한합니다. 샌드박스 내부에서 호스트 파일 시스템에 액세스하는 것은 예상된 동작이 아니라 구성 실패입니다. 이 경계를 위반하는 일반적인 실수로는 광범위한 디렉토리(예: 개발자의 홈 디렉토리 또는 /) 마운트, 컨테이너에서 권한 모드 사용, Docker 소켓을 샌드박스에 마운트하는 것이 있습니다. 플랫폼을 평가하거나 직접 구축할 때 마운트된 항목, 루트 파일 시스템 권한, 심볼릭 링크 이스케이프 또는 아카이브 추출 트릭이 의도된 작업 공간 외부의 경로에 도달할 수 있는지 확인하세요.
세션이 종료되면 파일은 어떻게 되나요?
임시 세션의 경우 세션이 종료될 때 작업 디렉토리와 생성된 모든 파일이 삭제됩니다. 이는 코드 완성, 평가 실행 및 재현성이 연속성보다 중요한 모든 작업에 적합한 기본값입니다. 영구 작업 공간(장기 실행 코딩 에이전트, 반복 개발 세션)의 경우 파일은 세션 내의 여러 실행 호출에서 유지될 수 있으며 플랫폼이 작업 공간 지속성 또는 스냅샷을 지원하는 경우 세션 종료 후에도 보존될 수 있습니다. 답변해야 할 주요 질문은 다음과 같습니다. 보존된 작업 공간을 소유하는 사람은 누구이며, 언제 정리되며, 한 사용자의 작업 공간이 다른 사용자에게 누출될 수 있습니까? 지속성 모델 체크리스트는 AI 생성 코드 샌드박스: 프로덕션 앱 요구 사항을 참조하세요.
세션 상태 및 지속성
샌드박스 세션은 상태를 유지합니까, 아니면 임시적입니까?
두 패턴 모두 존재하며 서로 다른 워크로드에 사용됩니다. 임시 세션은 모든 작업에 대해 깨끗한 기준선에서 시작합니다. 축적된 패키지, 파일 또는 기록이 없습니다. 추론하기 쉽고 평가 실행 또는 일회성 코드 실행에 이상적입니다. 상태 저장 세션은 여러 실행 호출에 걸쳐 파일, 설치된 패키지, 셸 기록 및 환경 상태를 보존하므로 다단계 코딩 에이전트, 대화형 데이터 분석 및 장기 실행 워크플로에 필요합니다. 대부분의 프로덕션 플랫폼은 둘 다 지원합니다. 트레이드오프는 상태 저장 세션에 명시적인 정리 정책과 더 신중한 테넌트 격리가 필요하다는 것입니다.
관리형 샌드박스에서 상태는 얼마나 오래 지속되나요?
세션 기간은 플랫폼과 요금제에 따라 다릅니다. 일부 제공업체는 기본 세션 시간 제한(일반적으로 60분~24시간)을 설정하며, 이후 세션이 종료되고 스냅샷이나 외부 저장소에 유지되지 않는 한 상태가 손실됩니다. 장기 실행 에이전트 워크플로(LLM 호출 사이에 몇 분 또는 몇 시간 동안 일시 중지될 수 있는 세션)는 상태를 보존하면서 유휴 시간에 대한 요금 청구를 피하기 위해 세션 일시 중지 및 재개 또는 자동 일시 중지를 지원하는 플랫폼이 필요합니다. 최대 세션 길이와 시간 초과가 발생할 때 진행 중인 상태에 어떤 일이 발생하는지 확인하세요. Novita Agent Sandbox는 최대 24시간 세션을 지원하며 유휴 시간 관리를 위한 일시 중지/자동 재개 기능을 문서화합니다. 기능 비교는 Novita Sandbox: E2B Pro의 비용 효율적인 대안, 완벽한 호환성을 참조하세요.
세션을 일시 중지하고 재개할 수 있나요?
일부 플랫폼은 세션을 디스크에 일시 중단하고 동일한 상태에서 나중에 다시 시작할 수 있는 일시 중지 및 재개를 지원합니다. 이는 단계 간 LLM 응답을 기다리는 에이전트, 비용이 많이 드는 워크로드의 속도 제한, 시간이 지남에 따라 여러 사용자 상호 작용에 걸쳐 있는 세션에 유용합니다. 확인할 주요 사항은 다음과 같습니다. 일시 중지된 세션이 일시 중단된 상태로 유지될 수 있는 기간, 일시 중지 중에 유지된 네트워크 연결에 어떤 일이 발생하는지, 세션 시작 시 주입된 자격 증명이 재개 후에도 유효한지 아니면 새로 고쳐야 하는지 여부입니다.
샌드박스 상태를 스냅샷으로 저장하고 재사용할 수 있나요?
템플릿과 스냅샷은 관련되어 있지만 별개입니다. 템플릿은 새로운 세션이 시작되는 사전 구축된 기준 환경(런타임, 도구, 승인된 패키지)입니다. 스냅샷은 실행 중인 세션의 현재 상태를 캡처하여 향후 세션의 시작점으로 사용합니다. 템플릿은 세션당 시작 오버헤드를 줄이고 모든 에이전트가 일관되고 관리되는 기준선에서 시작하도록 보장합니다. 스냅샷은 부분 작업을 보존하거나 반복 작업을 웜스타트하는 데 유용합니다. 둘 다 거버넌스가 필요합니다. 누가 생성할 수 있는지, 누가 읽을 수 있는지, 어떤 테넌트에 속하는지, 버전 관리 방법은 무엇인지 등입니다.
패키지 설치 및 런타임 종속성
에이전트가 런타임에 패키지를 설치할 수 있나요?
대부분의 샌드박스 환경은 기본적으로 런타임 패키지 설치(pip install, npm install, apt-get 등)를 허용합니다. 많은 에이전트 워크로드에 필요하기 때문입니다. 문제는 설치가 허용되는지 여부가 아니라 각 설치가 관리되는지 여부입니다. 관리되지 않는 패키지 설치는 샌드박스에서 가장 위험한 작업 중 하나입니다. 런타임에 외부 코드를 실행 환경으로 가져오고, 임의의 명령을 실행하는 설치 후 스크립트를 포함할 수 있으며, 공급망 위험을 초래할 수 있습니다.
런타임 패키지 설치를 관리하는 정책은 무엇인가요?
프로덕션 패키지 정책에는 일반적으로 레지스트리 허용 목록(승인된 패키지 레지스트리 또는 미러에서만 가져오기), 풀스루 캐시(실행 전에 들어오는 항목 검사), 설치 로깅(모든 설치에 대해 패키지 이름, 버전, 소스 및 결과 기록), 선택적 오프라인 모드(종속성을 템플릿에 사전 구축하고 재현성이 중요한 평가 파이프라인에 대한 런타임 설치 비활성화)의 조합이 포함됩니다. 올바른 정책은 워크로드에 따라 다릅니다. 개발자가 코드를 디버깅하는 것을 돕는 코딩 에이전트는 유연한 패키지 액세스가 필요할 수 있습니다. 자동화된 평가 파이프라인은 고정된 환경에서 실행되어야 합니다. 실제 구현 예제는 샌드박스 Python 및 제어된 패키지 액세스로 AI 데이터 분석가 구축을 참조하세요.
비밀 정보 및 자격 증명 처리
샌드박스에서 비밀 정보와 자격 증명은 어떻게 처리되나요?
비밀 정보는 좁게 주입되어야 합니다. 특정 작업에 필요한 자격 증명만 해당 세션 기간 동안 주입되어야 합니다. 일반적인 안티패턴은 모든 API 키가 포함된 광범위한 환경 파일을 모든 세션에 마운트하는 것입니다. 이는 손상된 경우 모든 세션이 해당 파일의 모든 자격 증명에 액세스할 수 있음을 의미합니다. 작업에 범위가 지정된 수명이 짧은 토큰을 선호하고, 하드코딩보다는 주입 메커니즘(환경 변수 또는 마운트된 파일)을 선호하세요. 가장 민감한 자격 증명의 경우 명시적으로 권한이 부여된 프로세스에만 값을 제공하는 런타임 비밀 API는 모든 프로세스에서 사용할 수 있는 플랫 환경 변수보다 더 강력한 격리를 제공합니다.
모델이 샌드박스에 주입된 환경 변수를 볼 수 있나요?
예, 환경 변수가 모델의 코드가 실행되는 프로세스에 주입된 경우 그렇습니다. 환경 변수는 기본적으로 동일한 세션의 모든 프로세스에 표시됩니다. 모델은 컨텍스트 창에서 직접 읽을 수 없지만 샌드박스 내에서 실행되는 생성된 코드는 os.environ, process.env 등을 사용하여 읽을 수 있습니다. 이것이 좁은 범위가 중요한 이유입니다. 작업에 필요한 자격 증명만 주입하고, 유출된 자격 증명의 유용성을 제한하기 위해 수명이 짧은 토큰을 선호하세요. 교정은 애플리케이션 책임입니다. 비밀 정보가 오류 메시지나 print 문에 나타날 수 있는 경우 기본적으로 전체 stdout을 기록하지 마세요.
세션이 종료되면 비밀 정보는 어떻게 되나요?
환경 변수와 마운트된 비밀 파일은 세션 해체의 일부로 정리되어야 합니다. 플랫폼이 세션 간에 상태를 보존하는 경우(스냅샷, 영구 볼륨) 파일 시스템에 기록되거나 자격 증명 제공자가 캐시한 자격 증명도 정리되거나 교체되는지 확인하세요. 재개 가능한 스냅샷의 만료된 자격 증명은 위험입니다. 세션 해체 후 스냅샷은 원래 세션 기간에만 유효했던 토큰을 보존해서는 안 됩니다.
감사 로그 및 관찰 가능성
샌드박스에서 어떤 이벤트가 기록되나요?
유용한 샌드박스 감사 기록에는 세션 생성 및 해체(세션 ID, 테넌트, 템플릿 버전, 리소스 할당, 기간), 실행 이벤트(실행된 코드 또는 명령 범주, 시작/종료 시간, 종료 상태), 패키지 설치(이름, 버전, 소스, 결과), 아웃바운드 네트워크 접촉(도메인, IP, 포트), 특정 경로에서 읽거나 쓴 파일, 정리 결과가 포함됩니다. 목표는 감사 로그를 두 번째 비밀 저장소로 만들지 않고 사후에 에이전트 동작을 재구성 가능하게 만드는 것입니다. 원시 고객 파일, 전체 명령 출력 및 전체 프롬프트는 일반적으로 감사 로그에 포함되어서는 안 됩니다. 단, 보존 및 액세스 제어가 해당 데이터용으로 특별히 설계된 경우는 예외입니다.
누가 감사 로그에 액세스할 수 있나요?
감사 로그에 대한 액세스 제어는 운영자와 해당되는 경우 테넌트로 범위가 지정되어야 합니다. 멀티 테넌트 플랫폼에서 한 테넌트의 감사 기록은 다른 테넌트에게 표시되어서는 안 됩니다. 규정 준수에 민감한 배포의 경우 감사 추적은 변조 방지 기능이 있어야 하며, 필요한 기간 동안 보존되고, 요청 시 승인된 검토자(보안 팀, 규정 준수 책임자)가 액세스할 수 있어야 합니다. 샌드박스 제공업체에 기본 로그 보존 기간, 로그를 자체 SIEM 또는 스토리지로 내보낼 수 있는지 여부, 로그 데이터를 보호하는 액세스 제어에 대해 문의하세요.
규정 준수 및 보안 검토
프로덕션에서 샌드박스를 사용하기 전에 어떤 규정 준수 검토가 필요한가요?
특정 요구 사항은 업계 및 관할권에 따라 다르지만 모든 프로덕션 에이전트 시스템에 대한 표준 질문은 다음과 같습니다. 샌드박스에 어떤 데이터가 입력됩니까(해당 데이터가 GDPR, HIPAA, SOC 2 또는 기타 프레임워크의 적용을 받습니까)? 샌드박스는 어디에서 호스팅되며 데이터 상주 요구 사항을 충족합니까? 격리 모델은 무엇이며 감사자에게 문서화할 수 있습니까? 자격 증명은 어떻게 관리되고 교체됩니까? 감사 추적은 어떻게 생겼습니까? 대부분의 보안 검토에서는 생성된 코드가 의도된 범위를 벗어난 프로덕션 데이터베이스, 내부 관리 표면 또는 고객 데이터에 도달할 수 있는지 여부도 질문합니다. 이는 공급업체 인증뿐만 아니라 아키텍처 제어에 관한 것입니다.
보안 팀이 AI 에이전트 샌드박스를 평가할 때 어떤 질문을 해야 하나요?
보안 검토를 위한 실용적인 평가 체크리스트:
- 격리: 경계는 프로세스, 컨테이너 또는 마이크로VM입니까? 각 에이전트 세션이 파일 시스템, 프로세스 및 네트워크 수준에서 격리됩니까?
- 이그레스: 기본 이그레스 정책은 무엇입니까? 아웃바운드 대상을 허용 목록에 추가할 수 있습니까? DNS는 어떻게 제어됩니까?
- 비밀 정보: 자격 증명은 어떻게 주입됩니까? 작업에 범위가 지정됩니까? 세션 해체 시 정리됩니까?
- 감사: 어떤 이벤트가 기록됩니까? 누가 로그에 액세스할 수 있습니까? 보존 기간은 얼마입니까?
- 데이터 상주: 샌드박스는 어디에서 호스팅됩니까? 배포를 특정 클라우드 지역 또는 계정으로 범위를 지정할 수 있습니까?
- 규정 준수 태세: 제공업체가 관련 인증(SOC 2, ISO 27001)을 보유하고 있습니까? 공동 책임 모델은 무엇입니까?
- 네트워크 도달 범위: 샌드박스가 내부 메타데이터 서비스, 비공개 API 또는 다른 테넌트의 리소스에 도달할 수 있습니까? 측면 이동은 어떻게 방지됩니까?
이를 단일 공급업체가 자동으로 충족하는 요구 사항이 아니라 평가 질문으로 구성하세요. 공급업체 문서의 보안 및 규정 준수 주장은 제품 문서와 대조하여 확인해야 하며 액면 그대로 받아들여서는 안 됩니다. 규제 또는 계약상 요구 사항이 있는 팀의 경우 프로덕션 배포 전에 보안 팀이 검토를 완료하도록 하세요.
BYOC(자체 클라우드 가져오기) 또는 VPC 배포가 필요한 경우는 언제인가요?
팀이 공유 관리 서비스보다 BYOC 또는 VPC 배포를 선택하는 주된 이유는 데이터 상주 요구 사항, 네트워크 보안 정책 또는 특정 클라우드 계정에서 데이터가 나가는 것을 금지하는 규제 제약 때문입니다. 자체 AWS 또는 GCP VPC 내에서 샌드박스를 실행하면 실행 환경이 네트워크 경계 내에 있고, 클라우드 계정의 액세스 제어가 적용되며, 샌드박스의 이그레스를 기존 네트워크 정책으로 관리할 수 있습니다. 트레이드오프는 운영 책임입니다. 인프라 관리, 패치 및 확장을 직접 담당해야 합니다. Novita Agent Sandbox는 이러한 요구 사항이 있는 팀을 위한 기능으로 AWS 또는 GCP 계정으로의 BYOC 배포를 문서화합니다. 현재 가용성 및 구성 옵션은 Novita Agent Sandbox 문서에서 확인하세요.
샌드박스 가격 책정 및 비용 요인
샌드박스 비용을 결정하는 요소는 무엇인가요?
샌드박스 비용은 일반적으로 컴퓨팅 시간(초당 또는 분당 청구되는 vCPU 및 메모리), 세션 오버헤드(일부 플랫폼의 세션당 시작 수수료), 포함된 무료 계층을 초과하는 영구 스토리지, 아웃바운드 데이터 전송(이그레스)의 조합입니다. 각 항목의 상대적 비중은 워크로드에 따라 다릅니다. 짧은 세션 코드 인터프리터는 주로 컴퓨팅 비용이 많이 듭니다. 대용량 파일을 다운로드하는 브라우저 자동화 에이전트는 상당한 이그레스를 발생시킬 수 있습니다. 영구 코딩 작업 공간은 스토리지를 축적합니다. 유휴 시간 처리는 주요 차별화 요소입니다. 자동 일시 중지 기능이 있는 플랫폼은 샌드박스가 LLM 응답을 기다리는 동안 청구를 중지하므로 대화형 워크플로의 비용을 크게 줄일 수 있습니다. 각 가격 책정 축에 대한 자세한 분석은 AI 에이전트 샌드박스 가격 모델: 세션별, 컴퓨팅, 스토리지, 이그레스를 참조하세요.
세션 시간, 컴퓨팅 및 이그레스는 비용에 어떻게 영향을 미치나요?
대부분의 워크로드에서 컴퓨팅 시간이 지배적입니다. 1 vCPU에서 10분 코딩 세션은 일반적인 요금으로 1GB 이그레스보다 비용이 더 많이 듭니다. 그러나 특정 워크로드의 경우 상호 작용이 중요합니다. 대규모 학습 데이터 세트를 다운로드하는 데이터 에이전트는 컴퓨팅 비용을 능가하는 이그레스 요금을 발생시킵니다. LLM 턴 사이에 세션을 열어 두는 브라우저 에이전트는 자동 일시 중지가 활성화되지 않은 경우 유휴 컴퓨팅을 축적합니다. 실제적인 접근 방식은 플랫폼을 결정하기 전에 각 차원을 실제 워크로드 프로필에 대해 추정하는 것입니다. Novita Agent Sandbox는 세션당 시작 수수료 없이 실제 vCPU 및 메모리 사용량을 기준으로 초당 청구합니다. 2026년 중반 기준 1 vCPU는 $0.0000098/초입니다. (출처: Novita AI 가격 페이지, 게시된 문서에서 확인. 예산 계획 전에 항상 현재 요금을 확인하세요.)
자체 호스팅 vs. 관리형 AI 에이전트 샌드박스
팀이 관리형 샌드박스 대신 자체 호스팅을 선택해야 하는 경우는 언제인가요?
자체 호스팅(종종 Firecracker 또는 이와 유사한 마이크로VM 계층에서 자체 샌드박스 인프라 실행)은 다음과 같은 경우에 적합합니다. 데이터 상주 또는 네트워크 정책 요구 사항으로 인해 타사 관리 서비스 사용이 금지된 경우, 워크로드 볼륨이 관리 서비스 비용이 자체 인프라 운영 비용을 초과할 정도로 높은 경우, 또는 팀에 기존 플랫폼 엔지니어링 역량이 있고 격리 모델, 이미지 거버넌스 및 네트워크 정책을 완전히 제어하려는 경우입니다. 자체 호스팅은 보기보다 어렵습니다. 커널, 루트 파일 시스템, 이미지, 스냅샷, 속도 제한기, 메트릭, 정리 및 멀티 테넌트 격리를 관리하는 것은 실제 작업입니다. 운영 범위가 어떻게 되는지는 AI 에이전트 샌드박스를 위한 Firecracker를 참조하세요.
관리형 샌드박스는 언제 더 적합한가요?
코딩 에이전트, 데이터 분석 도구, 브라우저 자동화 워크플로 또는 평가 파이프라인을 구축하는 대부분의 팀에게 관리형 샌드박스는 프로덕션에 더 빠른 경로입니다. 플랫폼이 인프라 프로비저닝, 보안 강화, 이미지 업데이트, 확장 및 수명 주기 관리를 처리합니다. 팀은 샌드박스 내부가 아닌 에이전트 아키텍처에 집중합니다. 비용 비교는 단순히 클라우드 컴퓨팅 요금만이 아닙니다. 격리 계층을 구축하고 유지 관리하는 엔지니어링 시간, 이를 문서화하는 규정 준수 작업, 예상치 못한 상황이 발생할 때의 사고 대응을 고려해야 합니다. 전담 플랫폼 엔지니어링 역량이 없는 팀의 경우 관리형 서비스가 일반적으로 더 빠르게 프로덕션에 도달하고 총 소유 비용을 낮게 유지합니다. 관리형 대 자체 호스팅 총 비용을 비교하는 프레임워크는 AI 에이전트 샌드박스 가격 모델을 참조하세요.
팀이 관리형 샌드박스 제공업체를 평가할 때 어떤 질문을 해야 하나요?
표제 가격을 넘어선 실용적인 평가 질문:
- 세션당 격리 모델은 무엇입니까(마이크로VM, 컨테이너, 프로세스)?
- 기본 및 구성 가능한 이그레스 정책은 무엇입니까?
- 패키지 설치 거버넌스 옵션은 무엇입니까?
- 비밀 정보는 어떻게 주입되고 정리됩니까?
- 어떤 감사 로그 데이터를 사용할 수 있으며 어떻게 액세스합니까?
- 필요한 계층에서 세션 길이 및 동시성 제한은 무엇입니까?
- 제공업체가 BYOC 또는 VPC 배포를 지원합니까?
- 일시 중지/재개 동작은 무엇이며 요금 청구에 어떤 영향을 미칩니까?
- 확장 시 시작 지연 시간은 어떻게 작동합니까(웜 풀, 스냅샷, 콜드 부트)?
신뢰할 수 없는 코드를 안전하게 실행하기
프로덕션에서 AI 생성 코드를 안전하게 실행하려면 어떻게 해야 하나요?
기본 사항은 LLM 생성 코드를 호스트에서 실행하지 않는 것입니다. 모든 실행을 파일 시스템, 프로세스 및 네트워크 격리를 제공하는 샌드박스를 통해 라우팅하세요. 그 외에도 다섯 가지 사례가 실질적인 차이를 만듭니다. (1) 이그레스 정책을 명시적으로 설정합니다. 기본 거부 및 허용 목록이 기본 개방형보다 안전합니다. (2) 비밀 정보의 범위를 좁게 지정합니다. 현재 작업에 필요한 자격 증명만 주입합니다. (3) 패키지 설치를 관리합니다. 승인된 레지스트리에서 설치를 허용하거나 재현 가능한 워크로드에 대해 사전 구축된 이미지를 사용합니다. (4) 애플리케이션 계층 로그가 아닌 커널 또는 하이퍼바이저 수준에서 로그를 기록합니다. (5) 리소스 제한(CPU, 메모리, 디스크, 벽시계 시간 제한)을 설정하여 실행이 중단된 에이전트가 인접 세션에 영향을 미치지 않도록 합니다. 전체 평가 체크리스트는 AI 샌드박스는 코드 실행에 얼마나 안전한가?를 참조하세요.
오픈 소스 AI 에이전트 샌드박스가 있나요?
네. Daytona는 AGPL 라이선스 하에 오픈 소스이며 자체 호스팅 배포를 지원합니다. E2B의 핵심 SDK는 오픈 소스이지만 관리형 런타임 인프라는 그렇지 않습니다. 처음부터 자체 샌드박스를 구축하려는 경우 가장 일반적인 접근 방식은 Firecracker(AWS 개발, Apache 2.0 라이선스)를 마이크로VM 런타임으로 사용하고 자체 이미지 관리, 오케스트레이션 및 수명 주기 제어를 결합하는 것입니다. 자체 호스팅은 관리형 서비스가 추상화하는 운영 범위(커널 관리, 루트 파일 시스템 거버넌스, 속도 제한, 스냅샷 스토리지, 정리 정책, 멀티 테넌트 격리)를 감당하는 것을 의미합니다. 해당 범위가 실제로 어떻게 보이는지는 AI 에이전트 샌드박스를 위한 Firecracker를 참조하세요.
관리형 AI 샌드박스 플랫폼이란 무엇인가요?
관리형 AI 샌드박스 플랫폼은 샌드박스 인프라를 API로 제공하는 클라우드 서비스입니다. SDK를 호출하면 샌드박스가 프로비저닝되어 준비 상태로 반환되며, 플랫폼이 기본 컴퓨팅, 네트워킹, 이미지 관리 및 수명 주기를 처리합니다. Novita Agent Sandbox, E2B 및 Daytona의 관리형 모드가 그 예입니다. 대안은 자체 호스팅으로, 샌드박스 인프라를 직접 프로비저닝하고 운영합니다. 모든 관리형 플랫폼에 대한 핵심 질문은 다음과 같습니다. 어떤 격리 모델을 사용합니까? 어떤 이그레스 정책을 구성할 수 있습니까? BYOC 또는 VPC 배포를 사용할 수 있습니까? 예상 워크로드에 대한 초당 가격은 어떻게 됩니까? 구조화된 비교는 2026년 최고의 AI 에이전트 샌드박스를 참조하세요.
엔터프라이즈용 AI 에이전트 샌드박스란 무엇인가요?
엔터프라이즈 AI 에이전트 샌드박스 요구 사항은 일반적으로 개발자 중심의 관리형 서비스가 기본적으로 제공하는 것 이상으로 확장됩니다. 일반적인 요구 사항은 다음과 같습니다. BYOC 또는 VPC 배포(샌드박스가 공유 타사 테넌트가 아닌 클라우드 계정 내에서 실행됨), SOC 2 또는 ISO 27001 인증, 구성 가능한 이그레스 정책 및 SIEM으로의 감사 로그 내보내기, 수명이 짧은 토큰을 사용한 세션 수준 자격 증명 범위 지정, 에이전트 워크로드가 실행되는 위치를 제한하는 데이터 상주 제어. Novita Agent Sandbox는 자체 AWS 또는 GCP VPC에서 BYOC 배포를 지원하므로 가장 일반적인 엔터프라이즈 데이터 상주 및 네트워크 격리 요구 사항을 해결합니다. 아키텍처 결정을 내리기 전에 제품 문서에서 현재 규정 준수 인증 및 사용 가능한 구성 옵션을 확인하세요.
