프로덕션 앱에서 AI 생성 코드를 실행하려면 프로세스 수준 격리를 적용하고, 동시 세션을 지원하며, 프로그램 가능한 수명 주기 API를 제공하고, 관찰 가능한 로그와 리소스 메트릭을 제공하며, 패키지 및 네트워크 정책을 적용하고, 앱 백엔드와 깔끔하게 통합되는 샌드박스가 필요합니다. 이러한 각 차원을 체계적으로 평가하지 않고 샌드박스를 선택하는 것은 팀이 출시 후 문제에 직면하는 가장 일반적인 방법입니다. 스테이징에서 안전해 보였던 워크로드가 실제 트래픽에서 실패하거나, 테넌트 간에 상태를 유출하거나, 앱이 의도한 적이 없는 코드를 자동 실행하는 경우가 발생합니다.
이 가이드는 요구 사항 체크리스트입니다. 각 격리 수준에서 확인해야 할 사항, 프로덕션 수명 주기 API가 노출해야 하는 사항, 관찰 가능성 및 리소스 제어가 어떤 모습이어야 하는지, 그리고 백엔드 통합 패턴이 설계를 성공시키거나 실패하게 만드는 위치를 다룹니다. 관리형 샌드박스를 평가하든 자체 구축하든, 출시 전에 답을 알아야 할 질문들입니다.
샌드박스 격리: 프로세스, 컨테이너, MicroVM
격리는 스펙트럼이며, 각 수준은 성능, 이식성, 생성된 코드에 얼마나 많은 신뢰를 부여하는지에 대해 서로 다른 트레이드오프를 수반합니다.
프로세스 수준 격리 는 네임스페이스, cgroups, seccomp, AppArmor 또는 SELinux 프로필과 같은 OS 기본 요소를 사용하여 프로세스가 액세스할 수 있는 것을 제한합니다. 빠르고 별도의 VM 커널이 필요하지 않지만 모든 프로세스가 호스트 커널을 공유합니다. 커널 취약점이나 seccomp 필터를 통과하는 권한 있는 시스템 호출은 동일한 호스트의 다른 워크로드에 영향을 줄 수 있습니다. 프로세스 격리는 위험이 낮고 수명이 짧은 신뢰할 수 있는 코드 경로에 대한 합리적인 시작점이지만, syscall, 하위 프로세스 생성 또는 패키지 설치를 시도할 수 있는 신뢰할 수 없는 AI 생성 코드에는 얇은 경계입니다.
이 수준에서 확인해야 할 사항:
- 차단된 syscall은 무엇이며, 알 수 없는 syscall이 시도될 때 기본 정책은 무엇입니까?
- 네임스페이스가 작업별, 테넌트별로 범위가 지정됩니까, 아니면 작업 간에 공유됩니까?
- cgroup 제한이 작업 수준에서 적용됩니까, 아니면 호스트 수준에서만 적용됩니까?
- 샌드박스가 종료 시 모든 프로세스, 임시 파일, 소켓 및 공유 메모리를 정리합니까?
컨테이너 수준 격리 는 파일 시스템 및 네트워크 네임스페이스 경계를 추가하고 이미지 관리를 반복 가능하게 만듭니다. 컨테이너는 전체 VM보다 시작 속도가 빠르고, 구성하기 쉬우며, 오케스트레이션 계층에서 널리 지원됩니다. 트레이드오프는 컨테이너가 여전히 호스트 커널을 공유하고, 컨테이너 경계는 기본 런타임 구성만큼만 강력하다는 것입니다. 권한 있는 컨테이너, 광범위한 기능 세트, 마운트된 호스트 소켓 및 호스트 네트워크 모드는 모두 효과적인 경계를 거의 무효화합니다.
이 수준에서 확인해야 할 사항:
- 컨테이너 이미지가 최소화되어 워크로드에 실제로 필요한 런타임과 도구만 포함되어 있습니까?
- 기능이 필요한 최소 세트로 축소되었습니까?
- 컨테이너가 루트리스(rootless)입니까, 아니면 루트가 필요하며 이에 대한 제어는 무엇입니까?
- 호스트 PID 네임스페이스, 호스트 네트워크, Docker 소켓이 명시적으로 제외되었습니까?
- 마운트된 볼륨이 명시적으로 정의된 경로로 제한되고, 가능한 경우 루트 파일 시스템이 읽기 전용입니까?
MicroVM 격리 는 각 워크로드를 자체 게스트 커널, 가상 장치 및 게스트와 호스트 사이의 KVM 지원 경계를 갖춘 경량 가상 머신 내에 배치합니다. Firecracker와 같은 기술은 최소 장치 모델을 사용하여 공격 표면을 줄이면서도 대화형 사용에 충분히 빠른 시작 속도를 유지합니다. MicroVM 경계는 게스트의 커널 악용이 호스트나 다른 게스트에 자동으로 영향을 미치지 않음을 의미합니다.
이 수준에서 확인해야 할 사항:
- 각 에이전트 실행, 각 테넌트 또는 각 동시 세션에 별도의 microVM이 할당됩니까?
- API 호출부터 실행 준비까지의 시작 지연 시간은 얼마이며, 웜 풀, 스냅샷 또는 콜드 부트에서 측정됩니까?
- 게스트 이미지가 버전 제어되고, 포함된 런타임 및 도구에 대해 감사되며, 정기적으로 업데이트됩니까?
- 게스트 커널이 패닉 상태가 되거나 응답하지 않으면 호스트 수준에서 어떤 일이 발생합니까?
실용적인 결정은 위협 모델에 관한 것입니다. MicroVM 격리는 일반적으로 신뢰할 수 없는 AI 생성 코드에 사용 가능한 가장 강력한 경계이지만, 파일 시스템 정책, 이그레스 제어, 패키지 거버넌스 또는 비밀 처리 기능을 대체하지는 않습니다. 이러한 제어는 선택한 격리 계층 위에 위치해야 합니다.
동시 샌드박스 세션 관리
여러 사용자를 위해 동시에 코드를 생성하는 프로덕션 앱에는 동시성을 일급 관심사로 처리하는 샌드박스가 필요하고, 사후 대책이 아닙니다.
핵심 질문은 다음과 같습니다:
세션별 격리: 50개의 세션이 동시에 실행 중일 때 각 세션에 자체 격리된 파일 시스템, 프로세스 트리, 네트워크 네임스페이스 및 자격 증명 범위가 있습니까? 세션 간 상태 누출은 멀티 테넌트 샌드박스 앱에서 가장 해로운 장애 모드 중 하나이며, 세션이 순차적으로 실행되는 테스트에서는 종종 보이지 않습니다.
세션 제한 및 역압력: 샌드박스가 동시성 제한을 명확한 API 계약으로 표시합니까? 500개의 요청이 도착하고 플랫폼이 100개의 동시 세션을 지원하는 경우, API는 구조화된 오류를 반환하거나, 요청을 대기열에 추가하거나, 자동으로 성능을 저하시킵니까? 프로덕션 앱은 역압력, 대기열 관리 및 사용자 대상 피드백을 구현하기 위해 해당 신호가 필요합니다.
부하 시 리소스 공정성: 한 세션이 비정상적으로 높은 CPU 또는 메모리를 소비할 때, 다른 세션은 세션별 리소스 제한에 의해 보호됩니까, 아니면 하나의 시끄러운 워크로드가 전체 풀의 성능을 저하시킬 수 있습니까?
웜 풀 및 세션 시작 지연 시간: 대화형 코딩 기능은 1초 미만의 세션 시작 시간이 필요합니다. 일반적으로 주문형으로 부팅하는 대신 즉시 클레임할 수 있는 사전 초기화된 환경 풀이 필요합니다. 플랫폼이 웜 풀 가용성을 문서화하는지와 다양한 동시성 수준에서 예상되는 시작 지연 시간을 확인하십시오.
세션 재사용 대 새 환경: 일부 앱은 여러 에이전트 턴에 걸쳐 장기 실행 세션을 재사용하는 이점을 얻는 반면, 다른 앱은 각 요청에 대해 깨끗한 환경이 필요합니다. 두 패턴이 모두 지원되는지, 그리고 세션 재사용이 이전 대화의 오래된 상태를 전달하지 않는지 확인하십시오.
수명 주기 API: 생성, 실행, 종료
수명 주기 API는 애플리케이션과 샌드박스 런타임 간의 인터페이스입니다. 프로덕션 등급 API는 최소한 다음을 노출해야 합니다.
생성(Create): 지정된 리소스 제한, 환경 변수 및 마운트된 볼륨을 사용하여 선택적으로 템플릿 또는 스냅샷에서 새 샌드박스 세션을 초기화합니다. 응답에는 세션 ID와 준비 신호가 포함되어야 하며, 단순한 확인이 아닙니다.
실행(Execute): 실행할 코드 또는 명령을 제출합니다. 실행 ID를 반환하는 비동기 호출이어야 합니다. API는 작업 디렉터리 지정, 호출에 대한 환경 재정의 및 시간 제한을 지원해야 합니다.
출력 스트리밍(Stream output): 실행 완료 후 최종 결과로만이 아니라 스트림으로 stdout 및 stderr을 검색합니다. 스트리밍은 장기 실행 작업, 수 초가 걸리는 에이전트 단계, 사용자에게 점진적 진행 상황을 보여주는 모든 UX에 중요합니다.
종료(Terminate): 실행이 완료되기 전에 실행 중인 실행을 종료합니다. 샌드박스는 상위 프로세스뿐만 아니라 프로세스 트리가 정리되도록 보장해야 합니다.
정리(Cleanup): 세션을 파괴하고 파일 시스템, 메모리, 프로세스 슬롯, 네트워크 상태 및 보유된 자격 증명을 포함한 모든 관련 리소스를 해제합니다. 이 호출은 멱등적이어야 하므로 네트워크 오류 후 재시도 시 오류가 발생하지 않습니다.
파일 업로드 및 다운로드: 실행 전에 입력 파일을 샌드박스로 전송하고 실행 후 출력 아티팩트를 검색합니다. 파일 전송은 크기 제한에 의해 제한되고 쓰기 가능한 경로에 대해 정책에 의해 제어되어야 합니다.
프로덕션 사용을 위해 확인할 가치가 있는 추가 기능:
- 일시 중지 및 재개: 장기 실행 세션을 일시 중단했다가 상태 손실 없이 나중에 재개할 수 있습니까? 이는 속도 제한, 비용 제어 및 에이전트 턴 간 세션 핸드오프에 유용합니다.
- 스냅샷: 현재 세션 상태를 캡처하여 향후 세션의 시작점으로 사용할 수 있습니까? 이는 웜 풀 및 재사용 가능한 환경을 위한 핵심 메커니즘입니다.
- 시간 초과 적용: 실행 중인 코드가 벽시계 시간 초과를 초과하면 플랫폼이 이를 깔끔하게 종료하고 올바른 종료 상태를 보고합니까?
관찰 가능성: 로그, 메트릭, 추적
볼 수 없는 것은 디버깅하거나 감사할 수 없습니다. 프로덕션 샌드박스에는 내장된 관찰 가능성이 필요하며, 나중에 추가되는 것이 아닙니다.
Stdout 및 stderr 캡처: 모든 실행은 세션 ID 및 실행 ID와 연결된 캡처된 출력 레코드를 생성해야 합니다. 이는 실행 완료 후 API를 통해 액세스할 수 있어야 하며, 실시간 스트림으로만 사용 가능해서는 안 됩니다.
실행 로그: 플랫폼은 어떤 코드가 실행되었는지, 언제 시작되었는지, 언제 종료되었는지, 종료 코드는 무엇인지, 세션을 소유한 사용자 또는 테넌트는 누구인지, 사용된 템플릿 또는 스냅샷은 무엇인지를 기록해야 합니다. 이러한 레코드는 문제 발생 시 무슨 일이 일어났는지 재구성하는 데 필요한 최소한의 정보입니다.
리소스 메트릭: 프로덕션 앱은 CPU 사용량, 메모리 피크, 벽시계 시간 및 파일 시스템 쓰기에 대한 세션별 메트릭이 필요합니다. 이를 통해 용량 계획, 이상 징후 탐지 및 세션별 비용 할당이 가능합니다.
오류 추적: 샌드박스 시작, 실행 또는 정리 실패 시 오류 표면은 구조화되어야 합니다: 오류 코드, 메시지, 세션 ID 및 사용자 오류(잘못된 코드, 누락된 패키지)와 플랫폼 오류(할당량 초과, 내부 오류)를 구분하기에 충분한 컨텍스트.
감사 추적: 멀티 테넌트 앱의 경우 감사 추적은 에이전트 행동을 재구성 가능하게 만들어야 합니다: 세션 ID, 테넌트, 실행 순서, 패키지 설치, 접촉한 외부 도메인, 작성된 파일 및 정리 결과. 원시 고객 코드 및 전체 명령 출력은 기본적으로 감사 로그에 포함되지 않아야 할 수 있습니다. 보존 및 액세스 정책이 실제로 지원할 수 있는 것을 위해 설계하십시오.
피해야 할 사항: 구조화된 오류, 세션 수준 로그, 시간 초과와 OOM(메모리 부족)과 프로세스 이스케이프 시도를 구분할 방법 없이 "실행 실패"만 표시하는 샌드박스. 이렇게 하면 모든 것을 애플리케이션 계층에서 계측해야 하므로 작업이 중복되고 샌드박스가 직접 관찰할 수 있는 이벤트를 놓치게 됩니다.
CPU, 메모리 및 시간 제한
무제한 리소스 사용은 샌드박스 워크로드가 프로덕션에서 문제를 일으키는 가장 간단한 방법 중 하나입니다. 다른 세션의 성능을 저하시키거나 예상치 못한 인프라 비용을 발생시킵니다.
프로덕션 샌드박스는 호스트 수준이 아닌 세션 수준에서 제한을 적용해야 합니다.
CPU: 단일 세션이 소비할 수 있는 CPU 시간을 제한합니다. 무한 루프를 생성하는 세션은 동일한 호스트의 다른 세션 성능을 저하시켜서는 안 됩니다. 제한이 하드 캡(프로세스가 조절 또는 종료됨)인지 소프트 제한(사용 가능한 CPU를 위해 다른 프로세스와 경쟁)인지 확인하십시오.
메모리: 세션이 호스트 메모리를 소진하도록 허용하는 대신 정리 또는 종료를 트리거하는 메모리 상한을 설정합니다. 제한에 도달하면 어떻게 되는지 확인하십시오: OOM 종료, 구조화된 오류 응답 또는 자동 중단.
벽시계 시간 초과: 모든 실행 호출에는 최대 기간이 있어야 합니다. 시간 초과는 클라이언트 수준뿐만 아니라 플랫폼 수준에서도 적용 가능해야 합니다. 클라이언트가 연결을 끊으면 샌드박스는 구성된 제한에서 실행을 계속 종료해야 합니다.
디스크 사용량: 생성된 코드는 큰 출력 파일을 쓰거나, 큰 패키지를 설치하거나, 작업 디렉터리를 채울 수 있습니다. 세션 작업 디렉터리에 대한 디스크 할당량은 실행되지 않는 쓰기를 방지합니다.
프로세스 수: AI 생성 코드는 하위 프로세스, 백그라운드 작업자 또는 더 많은 프로세스를 생성하는 셸 명령을 생성할 수 있습니다. 세션 네임스페이스의 총 프로세스 수에 대한 제한은 포크 폭탄 및 실행되지 않는 하위 프로세스 트리를 방지합니다.
샌드박스 플랫폼을 평가할 때 이러한 제한이 세션별로 구성 가능한지(다른 사용자 계층 또는 작업 유형이 다른 제한을 가질 수 있도록), 샌드박스 수준에서 적용되는지, 제한에 도달하면 구조화된 API 오류가 발생하는지 또는 자동 실패인지 확인하십시오.
패키지 설치 정책
AI 생성 코드는 pip install, npm install, apt-get, Git 클론, 직접 URL 가져오기 등 패키지 설치를 자주 요청합니다. 이러한 각 작업은 런타임에 외부 코드를 샌드박스로 가져오며, 이는 샌드박스가 관리해야 하는 가장 위험도가 높은 작업 중 하나입니다.
프로덕션 패키지 정책은 다음을 포함해야 합니다.
레지스트리 허용 목록: 어떤 패키지 레지스트리가 허용됩니까? PyPI 및 npm이 기본값이지만 많은 팀이 내부 미러, 선별된 레지스트리 또는 명시적으로 승인된 소스로 제한하는 옵션을 원합니다.
설치 캐싱: 많은 세션이 동일한 인기 패키지를 설치할 때 계층 캐시 또는 풀스루 프록시는 중복 다운로드를 방지하고, 시작 지연 시간을 줄이며, 가져오는 내용을 검사할 수 있는 지점을 제공합니다.
오프라인 모드: 일부 워크로드는 패키지 설치 없이 실행되어야 합니다. 환경이 이미지 또는 템플릿에 미리 내장되어 있고, 설치 시도는 명확한 오류와 함께 실패해야 합니다. 이는 재현성이 유연성보다 더 중요한 평가 실행에 적합한 모드입니다.
해시 검증 및 잠금 파일: 패키지가 허용되면 고정된 버전과 해시 검증은 레지스트리 손상이 샌드박스 내에서 실행되는 코드를 변경할 위험을 줄입니다.
크기 제한: 패키지 및 해당 전이적 종속성은 클 수 있습니다. 세션당 총 다운로드된 공간에 대한 크기 상한은 우발적 또는 의도적 스토리지 고갈을 방지합니다.
패키지 로깅: 모든 설치 시도는 실행 감사 로그에 기록되어야 합니다: 패키지 이름, 요청된 버전, 레지스트리 소스, 성공 또는 실패. 이는 인시던트 중에 샌드박스에 입력된 내용을 재구성하는 데 필요한 데이터입니다.
샌드박스 공급업체에 물어봐야 할 질문은 "사용자가 패키지를 설치할 수 있습니까?"가 아니라 "각 설치는 어떻게 감사되며, 기본적으로 허용되는 레지스트리는 무엇이며, 민감한 워크로드에 대해 더 엄격한 정책을 구성할 수 있습니까?"입니다.
네트워크 및 이그레스 제어
네트워크 액세스는 샌드박스가 예상치 못한 대상에 도달할 수 있는 두 번째 주요 벡터입니다. 기본적으로 열린 이그레스는 개발에서 편리하지만 AI 생성 코드를 실행하는 프로덕션 앱에는 좋지 않은 기본값입니다.
기본 거부 이그레스: 가장 강력한 프로덕션 자세는 기본적으로 모든 아웃바운드 연결을 차단하고 세션이 합법적으로 필요로 하는 대상만 명시적으로 허용 목록에 추가하는 것입니다. 이는 더 많은 구성이 필요하지만 액세스 모델을 감사 가능하게 만듭니다.
허용된 대상: 코딩 에이전트의 경우 일반적인 허용 대상에는 패키지 레지스트리, 에이전트가 호출하도록 구축된 특정 공개 API 세트 및 다른 것은 포함되지 않을 수 있습니다. 데이터 분석 에이전트의 경우 목록에 특정 데이터 소스가 포함될 수 있습니다. 플랫폼이 세션별 또는 테넌트별 대상 허용 목록을 지원하는지 확인하십시오.
DNS 정책: DNS는 이그레스 정책과 일관되게 처리되어야 합니다. 임의의 HTTP 대상에 도달할 수 없는 세션은 임의의 DNS 이름을 확인하고 이를 사용하여 네트워크 토폴로지를 추론하거나 DNS 기반 채널을 통해 제어를 우회할 수 없어야 합니다.
내부 서비스 액세스: AI 생성 코드는 명시적으로 구성되지 않는 한 클라우드 메타데이터 엔드포인트(예: AWS 인스턴스 메타데이터 서비스), 내부 API, 개인 데이터베이스 또는 관리 패널에 도달할 수 없어야 합니다. 샌드박스의 기본 네트워크 정책이 잘 알려진 내부 주소 범위를 차단하는지 확인하십시오.
패키지 다운로드 이그레스: 패키지 설치는 네트워크 작업입니다. 이그레스가 제한된 경우 패키지 레지스트리 허용 목록이 이그레스 정책과 일치하는지 확인하거나 신뢰할 수 있는 네트워크 내에서 풀스루 프록시를 사용하십시오.
아웃바운드 연결 로깅: 이그레스가 허용되는 경우에도 세션이 접촉한 도메인 및 IP를 로깅하는 것은 인시던트 조사에 유용합니다. 모든 샌드박스 플랫폼이 기본적으로 이를 제공하는 것은 아닙니다. 무엇을 얻을 수 있는지 확인하십시오.
비밀 및 자격 증명 주입
AI 에이전트는 API 키, 데이터베이스 연결, OAuth 토큰, 단기 클라우드 자격 증명과 같은 자격 증명을 자주 필요로 합니다. 샌드박스가 비밀을 처리하는 방법은 보안과 운영 신뢰성 모두에 중요합니다.
좁은 범위: 각 세션은 실행 중인 특정 작업에 필요한 비밀만 수신해야 합니다. 모든 세션에 모든 자격 증명이 포함된 광범위한 환경 파일을 마운트하는 것은 운영상 편리하지만 모든 세션에서 손상되거나 오작동하는 코드가 해당 자격 증명 모두에 도달할 수 있음을 의미합니다.
단기 자격 증명: 백엔드가 지원하는 경우 세션 기간으로 범위가 지정된 TTL이 있는 단기 토큰을 선호하십시오. 이는 유출된 자격 증명이 유용한 기간을 제한합니다.
주입 메커니즘: 비밀이 환경 변수, 마운트된 파일 또는 비밀 API를 통해 주입되는지 확인하십시오. 환경 변수는 기본적으로 세션의 모든 프로세스에서 액세스할 수 있습니다. 마운트된 파일은 경로 및 권한 세트로 범위를 지정할 수 있습니다. 가장 민감한 자격 증명의 경우 명시적으로 승인된 프로세스에만 값을 제공하는 비밀 API를 고려하십시오.
수정(Redaction): 샌드박스는 stdout, stderr, 실행 로그, 오류 메시지 또는 모델에 표시되는 도구 응답을 통해 비밀을 다시 에코해서는 안 됩니다. 수정은 애플리케이션 계층의 책임이지만 구성 가능한 로그 스크러빙을 지원하는 샌드박스는 우발적 노출의 영향을 줄입니다.
정리: 세션이 종료된 후 환경 변수, 마운트된 비밀 파일 및 캐시된 자격 증명 데이터가 다음 세션에 상속되지 않도록 세션 해체의 일부로 정리되는지 확인하십시오.
임시 vs. 영구 파일 스토리지
다른 워크로드는 다른 지속성 요구 사항을 가지며, 프로덕션 샌드박스는 두 패턴을 모두 명확하게 지원해야 합니다.
임시 세션: 수명이 짧은 코드 실행의 기본값은 깨끗한 작업 디렉터리를 만들고, 코드를 실행하고, 출력을 생성하고, 파괴되는 세션입니다. 임시 세션은 추론하기 쉽습니다: 각 실행은 알려진 기준선에서 시작하고, 상태가 누적되지 않으며, 정리가 간단합니다. 평가 작업, 일회성 코드 완성 및 재현성이 연속성보다 더 중요한 모든 작업에 적합한 선택입니다.
영구 작업 공간: 장기 실행 코딩 에이전트, 반복적인 개발 워크플로 및 다중 턴 에이전트 세션은 종종 여러 실행 호출에 걸쳐 유지되는 작업 공간이 필요합니다. 한 턴에 설치된 파일, 캐시된 종속성, 작성된 코드 및 기록된 기록은 다음 턴에서 사용할 수 있어야 합니다. 영구 작업 공간은 운영하기가 더 복잡합니다: 상태가 누적되고, 템플릿에서 벗어날 수 있으며, 명시적인 수명 주기가 필요합니다. 작업 공간이 정리되는 시기, 소유자, 세션 간 보호를 위한 액세스 제어는 무엇입니까?
스냅샷 및 템플릿: 템플릿을 사용하면 알려진 양호한 기준선 환경(런타임, 도구, 종속성)을 정의하고 일관되게 세션을 시작할 수 있습니다. 스냅샷은 실행 중인 세션의 현재 상태를 캡처하여 향후 세션의 시작점으로 사용합니다. 둘 다 반복 가능한 환경과 낮은 시작 지연 시간이 필요한 팀에 유용합니다. 템플릿의 버전이 관리되고, 생성 및 업데이트 권한이 제어되며, 스냅샷이 테넌트별로 격리되는지 확인하십시오.
출력 아티팩트 내보내기: 실행 후 샌드박스에서 무엇을 내보낼 수 있습니까? 프로덕션 정책은 내보낼 수 있는 파일 경로, 적용되는 크기 제한, 애플리케이션이 수신하기 전에 아티팩트가 검토되거나 필터링되는지 여부를 정의해야 합니다.
세션 간 상태: 앱 설계가 세션 간 상태 공유를 의도하는지 여부를 명시적으로 지정하십시오. 공유 패키지 캐시, 공유 볼륨 또는 잘못 라우팅된 작업 공간을 통한 우발적 공유는 일반적인 멀티 테넌트 격리 실패입니다.
백엔드 통합: REST, WebSocket, SDK
샌드박스는 애플리케이션 백엔드에 깔끔하게 통합될 때만 유용합니다. 세 가지 주요 통합 패턴은 REST, WebSocket 및 SDK입니다.
REST: REST API는 개별 실행 요청을 제출하고 결과를 폴링하는 앱에 가장 적합한 통합 방식입니다. 수명이 짧은 작업에 잘 작동하고, 표준 HTTP 도구로 디버깅하기 쉬우며, 기존 서비스 아키텍처에 자연스럽게 맞습니다. 트레이드오프는 결과를 폴링하면 푸시 알림에 비해 대기 시간이 추가되고, 장기 실행 출력을 스트리밍하려면 SSE 또는 로그 엔드포인트 폴링이 필요하다는 것입니다.
WebSocket: WebSocket 연결은 애플리케이션과 샌드박스 간의 양방향, 저지연 통신을 지원합니다. 코드 실행 시 출력을 스트리밍하는 코딩 도우미, 명령을 보내고 실시간으로 응답을 수신해야 하는 브라우저 에이전트, 실행을 지속적으로 모니터링하는 평가 도구 등 대화형 사용 사례에 적합한 선택입니다. 트레이드오프는 운영 복잡성입니다: WebSocket 연결은 영구 상태, 재연결 처리 및 클라이언트와 서버 측 모두에서 더 복잡한 인프라가 필요합니다.
SDK: 언어 네이티브 SDK는 전송 세부 정보를 숨기고, 인증을 처리하며, 세션 관리 및 실행을 위한 유형화된 인터페이스를 제공하고, 종종 출력 스트리밍, 파일 업로드 및 템플릿 관리를 위한 도우미를 포함합니다. SDK는 대부분의 앱 개발자에게 가장 빠른 통합 경로입니다. SDK가 적극적으로 유지 관리되고, 전체 API 표면을 다루며, 애플리케이션이 조치를 취할 수 있는 구조화된 방식으로 오류를 처리하는지 확인하십시오.
애플리케이션이 소유해야 하는 통합 지점: 전송에 관계없이 애플리케이션은 권한 부여(어떤 사용자가 어떤 리소스 제한으로 세션을 생성할 수 있는지), 승인 게이트(실행 전에 인간 검토가 필요한 도구 호출 또는 코드 실행), 결과 처리(샌드박스 출력이 에이전트에 의해 표시되거나 조치되는 방식) 및 정리(사용자 흐름이 완료되거나 에이전트 턴이 종료될 때 세션 해체 트리거)를 담당합니다.
잘 설계된 샌드박스 API는 애플리케이션의 비즈니스 로직을 소유하려고 하지 않습니다. 생성, 실행, 스트리밍, 종료, 정리와 같은 기본 요소를 노출하고 애플리케이션 계층이 그 위에 올바른 제품 동작을 구축하도록 합니다.
장애 복구 및 정리
프로덕션 시스템은 실패합니다. 실패를 적절하게 처리하는 샌드박스는 리소스 누수, 오래된 상태 및 디버깅하기 어려운 인시던트를 방지합니다.
실행 시간 초과 처리: 실행 중인 실행이 시간 초과를 초과하면 플랫폼은 프로세스 트리를 깔끔하게 종료하고 구조화된 오류 응답을 반환해야 하며, 리소스를 소비하는 좀비 세션을 남겨두지 않아야 합니다. 시간 초과 후 세션에 어떤 일이 발생하는지 확인하십시오: 자동으로 정리됩니까, 아니면 명시적인 정리 호출이 필요합니까?
세션 충돌 복구: 샌드박스 호스트가 충돌하거나 세션 VM이 예기치 않게 종료되면 플랫폼은 장애를 감지하고, 세션을 종료된 것으로 표시하고, 애플리케이션이 반응할 수 있도록 API를 통해 해당 상태를 표시해야 합니다. 세션은 API 신호 없이 자동으로 사라져서는 안 됩니다.
정리 보장: cleanup 또는 terminate API 호출은 CPU 및 메모리 할당, 파일 시스템 할당량, 프로세스 슬롯, 네트워크 상태 및 자격 증명을 포함한 모든 리소스를 안정적으로 해제해야 합니다. 정리는 멱등적이어야 합니다. 동일한 세션 ID에 대해 여러 번 호출해도 오류가 반환되어서는 안 됩니다. 이는 실제로 중요합니다: 네트워크 오류 후 정리를 재시도하는 애플리케이션 코드가 중단되어서는 안 됩니다.
부분 실행 실패: 코드가 실행 중간에 실패하면(처리되지 않은 예외, 종료된 프로세스, 누락된 패키지) 샌드박스는 부분 성공(실패 전에 일부 출력이 생성됨)과 전체 실패를 구분하는 구조화된 결과를 반환해야 합니다. 부분 결과를 기반으로 구축된 애플리케이션은 불완전하거나 오해의 소지가 있는 출력을 사용자에게 제시하지 않도록 이 정보가 필요합니다.
실행되지 않는 프로세스 처리: 생성된 코드가 기본 실행에서 살아남는 백그라운드 프로세스를 생성하는 경우, 샌드박스는 세션 정리의 일부로 이를 종료해야 하며, 무기한 실행되도록 허용하지 않아야 합니다. 플랫폼의 정리가 실행 호출의 직계 자식뿐만 아니라 전체 프로세스 트리를 포함하는지 확인하십시오.
용량 및 할당량 오류: 플랫폼이 세션 용량에 도달했거나 테넌트가 할당량에 도달한 경우, API는 애플리케이션이 명시적으로 처리할 수 있는 특정 오류 코드를 반환해야 합니다. 일반 500 오류나 자동 중단이 아닙니다. 이를 통해 애플리케이션은 대기열에 추가하거나, 백오프하거나, 사용자에게 유용한 메시지를 표시할 수 있습니다.
Novita Agent Sandbox
Novita Agent Sandbox는 에이전트 워크로드를 위해 구축된 관리형 샌드박스 플랫폼입니다. 코딩 에이전트, 데이터 분석 에이전트, 브라우저 지향 워크플로 및 생성된 코드가 애플리케이션 서버나 공유 인프라에 배치되지 않고 격리되고 관찰 가능한 환경에서 실행되어야 하는 장기 실행 에이전트 세션을 대상으로 합니다.
이미 Novita AI 모델 API를 사용하는 팀의 경우 Agent Sandbox는 더 넓은 에이전트 아키텍처의 일부가 될 수 있습니다. 모델이 코드를 계획하고 생성하고, 샌드박스가 프로그램 가능한 수명 주기로 격리된 실행을 제공하며, 애플리케이션 계층이 권한 부여, 승인 게이트 및 결과 처리를 소유합니다.
Novita는 MicroVM 격리, 동시 세션 지원, 생성, 실행, 스트리밍, 종료 및 정리를 포함한 수명 주기 API, 세션 상태 관리를 위한 일시 중지 및 자동 재개, 빠르고 반복 가능한 환경 시작을 위한 템플릿 및 스냅샷, Novita 모델 API와의 통합을 포함한 기능을 설명했습니다. 아키텍처 결정을 내리기 전에 Novita Agent Sandbox 문서 및 제품 페이지에서 현재 기능 가용성, 리소스 구성 옵션 및 가격을 확인하십시오. 특정 격리 경계, 동시성 제한, 시작 지연 시간 및 네트워크 정책에 대한 주장은 현재 제품 문서와 대조하여 확인해야 합니다.
이 가이드의 요구 사항에 대해 Novita Agent Sandbox를 평가할 때는 다른 공급업체와 동일한 체크리스트를 적용하십시오: 세션당 격리 경계, 수명 주기 API 완전성, 관찰 가능성 표면, 구성 가능한 리소스 제한, 패키지 정책 옵션, 이그레스 제어, 비밀 처리, 지속성 모델 및 백엔드 통합 지원.
FAQ
AI 생성 코드에 어떤 격리 모델을 선택해야 합니까?
MicroVM 격리는 신뢰할 수 없는 AI 생성 코드에 가장 강력한 경계를 제공하지만 운영 복잡성을 추가합니다. 컨테이너 격리는 컨테이너가 올바르게 강화된 경우(권한 모드 없음, 최소 기능, 가능한 경우 읽기 전용 루트 파일 시스템, 호스트 소켓 마운트 없음) 위험이 낮은 워크로드에 적합합니다. 프로세스 격리만으로는 syscall, 하위 프로세스 생성 또는 패키지 설치를 시도할 수 있는 신뢰할 수 없는 코드에 비해 너무 얇은 경계입니다. 실제 위협 모델에 맞게 격리 수준을 일치시키십시오.
프로덕션 샌드박스에서 패키지 설치는 어떻게 처리합니까?
기본적으로 열린 액세스 대신 레지스트리 허용 목록을 사용하십시오. 풀스루 캐시를 추가하여 중복 다운로드를 줄이고 검사 지점을 제공하십시오. 패키지 이름, 버전, 소스 및 결과와 함께 모든 설치 시도를 기록하십시오. 재현성이 유연성보다 더 중요한 워크로드(평가 실행, 자동화된 파이프라인)의 경우 환경이 미리 내장되고 설치가 완전히 금지되는 오프라인 모드를 고려하십시오.
수명 주기 API는 최소한 무엇을 노출해야 합니까?
생성, 출력 스트리밍 실행, 종료 및 정리. 출력 스트리밍은 최소 구현에서 가장 자주 누락되는 기능이며, 대화형 에이전트 UI에 가장 중요한 기능입니다. 정리는 멱등적이어야 하며 진입점 프로세스뿐만 아니라 전체 프로세스 트리를 포함해야 합니다.
샌드박스를 통한 비밀 유출을 어떻게 방지합니까?
자격 증명을 광범위한 환경 파일이 아닌 작업에 좁게 범위를 지정하십시오. 단기 토큰을 선호하십시오. 비밀이 나타날 수 있는 경우 기본적으로 전체 stdout을 기록하지 마십시오. 샌드박스가 세션 해체 시 환경 변수와 마운트된 비밀 파일을 정리하는지 확인하십시오. 수정을 샌드박스 보장이 아닌 애플리케이션 책임으로 취급하십시오.
