이 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시간의 세션을 지원하며 유휴 시간 관리를 위한 Pause/Autoresume 기능을 문서화하고 있습니다. 기능 비교는 Novita Sandbox: E2B Pro의 비용 효율적인 대안, 완벽한 호환성을 참조하세요.
세션을 일시 중지하고 다시 시작할 수 있나요?
일부 플랫폼은 일시 중지 및 재개를 지원하며, 세션이 디스크에 보류되었다가 동일한 상태에서 다시 시작될 수 있습니다. 이는 단계 사이에 LLM 응답을 기다리는 에이전트, 비용이 많이 드는 워크로드에 대한 속도 제한, 시간이 지남에 따라 여러 사용자 상호 작용에 걸친 세션에 유용합니다. 확인해야 할 주요 사항은 다음과 같습니다. 일시 중지된 세션이 얼마나 오래 보류 상태로 유지될 수 있는지, 일시 중지 중에 보류된 네트워크 연결에 어떤 일이 발생하는지, 세션 시작 시 주입된 자격 증명이 재개 후에도 유효한지 또는 새로 고쳐야 하는지 여부입니다.
샌드박스 상태를 스냅샷으로 저장하고 재사용할 수 있나요?
템플릿과 스냅샷은 관련되어 있지만 구별됩니다. 템플릿은 새 세션이 시작되는 사전 구축된 기준 환경(런타임, 도구, 승인된 패키지)입니다. 스냅샷은 실행 중인 세션의 현재 상태를 캡처하여 향후 세션의 시작점으로 사용합니다. 템플릿은 세션당 시작 오버헤드를 줄이고 모든 에이전트가 일관되고 관리되는 기준에서 시작하도록 보장합니다. 스냅샷은 부분 작업을 보존하거나 반복 작업을 웜 스타트하는 데 유용합니다. 둘 다 거버넌스가 필요합니다. 누가 생성할 수 있는지, 누가 읽을 수 있는지, 어떤 테넌트에 속하는지, 버전 관리 방법은 무엇인지 등입니다.
패키지 설치 및 런타임 종속성
에이전트가 런타임에 패키지를 설치할 수 있나요?
대부분의 샌드박스 환경은 많은 에이전트 워크로드에 필요하기 때문에 기본적으로 런타임 패키지 설치(pip install, npm install, apt-get 등)를 허용합니다. 문제는 설치가 허용되는지 여부가 아니라 각 설치가 관리되는지 여부입니다. 관리되지 않는 패키지 설치는 샌드박스에서 가장 위험한 작업 중 하나입니다. 런타임에 외부 코드를 실행 환경으로 가져오고, 임의 명령을 실행하는 설치 후 스크립트를 포함할 수 있으며, 공급망 위험을 초래할 수 있습니다.
런타임 패키지 설치를 관리하는 정책은 무엇인가요?
프로덕션 패키지 정책에는 일반적으로 레지스트리 허용 목록(승인된 패키지 레지스트리 또는 미러에서만 가져오기), 풀-스루 캐시(실행 전에 들어오는 항목 검사), 설치 로깅(모든 설치에 대해 패키지 이름, 버전, 소스 및 결과 기록), 선택적 오프라인 모드(종속성을 템플릿에 미리 베이크하고 재현성이 중요한 평가 파이프라인에 대해 런타임 설치를 허용하지 않음)의 조합이 포함됩니다. 올바른 정책은 워크로드에 따라 다릅니다. 개발자가 코드를 디버깅하는 데 도움을 주는 코딩 에이전트는 유연한 패키지 접근이 필요할 수 있습니다. 자동화된 평가 파이프라인은 고정된 환경에서 실행되어야 합니다. 실제 구현 예는 샌드박스 Python 및 제어된 패키지 접근으로 AI 데이터 분석가 구축을 참조하세요.
시크릿 및 자격 증명 처리
샌드박스에서 시크릿과 자격 증명은 어떻게 처리되나요?
시크릿은 좁게 주입되어야 합니다. 즉, 특정 작업에 필요한 자격 증명만 해당 세션 기간 동안 주입되어야 합니다. 일반적인 안티패턴은 모든 API 키가 포함된 광범위한 환경 파일을 모든 세션에 마운트하는 것입니다. 이렇게 하면 손상된 세션이 해당 파일의 모든 자격 증명에 접근할 수 있습니다. 작업 범위로 제한된 단기 토큰을 선호하고, 하드코딩보다는 주입 메커니즘(환경 변수 또는 마운트된 파일)을 선호하세요. 가장 민감한 자격 증명의 경우 명시적으로 승인된 프로세스에만 값을 제공하는 런타임 시크릿 API는 모든 프로세스에서 사용 가능한 플랫 환경 변수보다 더 강력한 격리를 제공합니다.
모델이 샌드박스에 주입된 환경 변수를 볼 수 있나요?
예, 환경 변수가 모델 코드가 실행되는 프로세스에 주입된 경우 그렇습니다. 환경 변수는 기본적으로 동일한 세션의 모든 프로세스에 표시됩니다. 모델이 컨텍스트 창에서 직접 읽을 수는 없지만, 샌드박스 내에서 실행되는 생성된 코드는 os.environ, process.env 또는 이와 동등한 것으로 읽을 수 있습니다. 그렇기 때문에 좁은 범위가 중요합니다. 작업에 필요한 자격 증명만 주입하고, 유출된 자격 증명의 유용한 시간을 제한하기 위해 단기 토큰을 선호하세요. 수정(sanitization)은 애플리케이션 책임입니다. 시크릿이 오류 메시지나 인쇄 문에 나타날 수 있는 경우 기본적으로 전체 stdout을 기록하지 마세요.
세션이 종료되면 시크릿은 어떻게 되나요?
환경 변수와 마운트된 시크릿 파일은 세션 종료의 일부로 정리되어야 합니다. 플랫폼이 세션 간에 상태를 보존하는 경우(스냅샷, 영구 볼륨), 파일 시스템에 기록되었거나 자격 증명 제공자가 캐시한 자격 증명도 정리되거나 교체되는지 확인하세요. 재개 가능한 스냅샷의 오래된 자격 증명은 위험합니다. 세션 종료 후 스냅샷은 원래 세션 기간 동안만 유효했던 토큰을 보유해서는 안 됩니다.
감사 로그 및 관찰 가능성
샌드박스에서 어떤 이벤트가 기록되나요?
유용한 샌드박스 감사 기록에는 세션 생성 및 종료(세션 ID, 테넌트, 템플릿 버전, 리소스 할당, 기간), 실행 이벤트(실행된 코드 또는 명령 범주, 시작/종료 시간, 종료 상태), 패키지 설치(이름, 버전, 소스, 결과), 아웃바운드 네트워크 연결(도메인, IP, 포트), 특정 경로에서 읽거나 쓴 파일, 정리 결과가 포함됩니다. 목표는 감사 로그를 두 번째 시크릿 저장소로 만들지 않고 사후에 에이전트 동작을 재구성 가능하게 만드는 것입니다. 원시 고객 파일, 전체 명령 출력 및 전체 프롬프트는 일반적으로 감사 로그에 포함되어서는 안 됩니다. 단, 보존 및 접근 제어가 해당 데이터를 위해 특별히 설계된 경우는 예외입니다.
감사 로그에 누가 접근할 수 있나요?
감사 로그에 대한 접근 제어는 운영자와 관련 테넌트로 범위가 지정되어야 합니다. 멀티 테넌트 플랫폼에서 한 테넌트의 감사 기록은 다른 테넌트에게 표시되지 않아야 합니다. 규정 준수에 민감한 배포의 경우 감사 추적은 변조 방지(tamper-evident)여야 하며, 필요한 기간 동안 보존되어야 하고, 요청 시 승인된 검토자(보안 팀, 규정 준수 책임자)가 접근할 수 있어야 합니다. 샌드박스 제공자에게 기본 로그 보존 기간, 자체 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/s에 책정되어 있습니다. (출처: 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 배포를 지원하여 가장 일반적인 엔터프라이즈 데이터 상주 및 네트워크 격리 요구 사항을 해결합니다. 아키텍처 결정을 내리기 전에 제품 문서에서 현재 규정 준수 인증 및 사용 가능한 구성 옵션을 확인하세요.
