프로덕션 앱에서 AI 생성 코드를 실행하려면 프로세스 수준 격리를 강제하고, 동시 세션을 지원하며, 프로그래밍 가능한 라이프사이클 API를 제공하고, 관찰 가능한 로그와 리소스 메트릭을 제공하며, 패키지 및 네트워크 정책을 시행하고, 앱 백엔드와 깔끔하게 통합되는 샌드박스가 필요합니다. 이러한 각 차원을 체계적으로 평가하지 않고 샌드박스를 선택하는 것은 팀이 출시 후 문제에 부딪히는 가장 일반적인 방법입니다. 스테이징에서는 안전해 보였던 워크로드가 실제 트래픽에서 실패하거나, 테넌트 간에 상태가 유출되거나, 앱이 의도하지 않은 코드를 조용히 실행하게 됩니다.
이 가이드는 요구 사항 체크리스트입니다. 각 격리 수준에서 확인해야 할 사항, 프로덕션 라이프사이클 API가 노출해야 하는 사항, 관찰 가능성 및 리소스 제어의 모습, 백엔드 통합 패턴이 설계를 성사시키거나 망치는 부분을 다룹니다. 관리형 샌드박스를 평가하든 직접 구축하든, 출시 전에 답을 찾아야 할 질문들입니다.
샌드박스 격리: 프로세스, 컨테이너, MicroVM
격리는 스펙트럼이며, 각 수준은 성능, 이식성, 생성된 코드에 부여하는 신뢰의 정도에 대해 서로 다른 트레이드오프를 수반합니다.
프로세스 수준 격리 는 OS 프리미티브(네임스페이스, cgroups, seccomp, AppArmor 또는 SELinux 프로필)를 사용하여 프로세스가 접근할 수 있는 대상을 제한합니다. 빠르고 별도의 VM 커널이 필요하지 않지만, 모든 프로세스가 호스트 커널을 공유합니다. 커널 취약점이나 seccomp 필터를 통과하는 특권 시스템 호출은 동일한 호스트의 다른 워크로드에 영향을 줄 수 있습니다. 프로세스 격리는 저위험, 단기, 신뢰할 수 있는 코드 경로에 대한 합리적인 출발점이지만, syscall, 서브프로세스 생성 또는 패키지 설치를 시도할 수 있는 신뢰할 수 없는 AI 생성 코드에는 얇은 경계입니다.
이 수준에서 확인할 사항:
- 차단된 syscall은 무엇이며, 알 수 없는 syscall이 시도될 때 기본 정책은 무엇입니까?
- 네임스페이스가 작업별, 테넌트별로 범위가 지정됩니까, 아니면 작업 간에 공유됩니까?
- cgroup 제한이 작업 수준에서 시행됩니까, 아니면 호스트 수준에서만 시행됩니까?
- 샌드박스가 종료 시 모든 프로세스, 임시 파일, 소켓, 공유 메모리를 정리합니까?
컨테이너 수준 격리 는 파일 시스템 및 네트워크 네임스페이스 경계를 추가하고 이미지 관리를 반복 가능하게 만듭니다. 컨테이너는 전체 VM보다 시작 속도가 빠르고, 구성하기 쉬우며, 오케스트레이션 계층에서 널리 지원됩니다. 트레이드오프는 컨테이너가 여전히 호스트 커널을 공유하며, 컨테이너 경계는 기본 런타임 구성만큼만 강력하다는 것입니다. 특권 컨테이너, 광범위한 기능 세트, 마운트된 호스트 소켓, 호스트 네트워크 모드는 모두 효과적인 경계를 거의 무효화합니다.
이 수준에서 확인할 사항:
- 컨테이너 이미지가 최소화되어 워크로드에 실제로 필요한 런타임과 도구만 포함되어 있습니까?
- 기능이 필요한 최소 세트로 축소되었습니까?
- 컨테이너가 rootless입니까, 아니면 루트가 필요하며 이에 대한 제어는 무엇입니까?
- 호스트 PID 네임스페이스, 호스트 네트워크, Docker 소켓이 명시적으로 제외되었습니까?
- 마운트된 볼륨이 명시적으로 정의된 경로로 제한되고, 루트 파일 시스템은 가능한 경우 읽기 전용입니까?
MicroVM 격리 는 각 워크로드를 자체 게스트 커널, 가상 장치, 게스트와 호스트 간의 KVM 기반 경계를 갖춘 경량 가상 머신 내부에 배치합니다. Firecracker와 같은 기술은 최소 장치 모델을 사용하여 공격 표면을 줄이면서도 대화형 사용에 충분히 빠른 시작을 유지합니다. MicroVM 경계는 게스트의 커널 익스플로잇이 호스트나 다른 게스트에 자동으로 영향을 미치지 않음을 의미합니다.
이 수준에서 확인할 사항:
- 각 에이전트 실행, 각 테넌트, 각 동시 세션이 별도의 MicroVM을 얻습니까?
- API 호출부터 실행 준비까지의 시작 지연 시간은 얼마이며, 이는 웜 풀, 스냅샷, 또는 콜드 부트에서 측정됩니까?
- 게스트 이미지가 버전 관리되고, 포함된 런타임과 도구에 대해 감사되며, 정기적으로 업데이트됩니까?
- 게스트 커널 패닉이 발생하거나 응답하지 않으면 호스트 수준에서 어떻게 됩니까?
실용적인 결정은 위협 모델에 관한 것입니다. MicroVM 격리는 신뢰할 수 없는 AI 생성 코드에 대해 일반적으로 사용 가능한 가장 강력한 경계이지만, 파일 시스템 정책, 이그레스 제어, 패키지 거버넌스 또는 비밀 처리(secrets handling)를 대체하지는 않습니다. 이러한 제어는 선택한 격리 계층 위에 위치해야 합니다.
동시 샌드박스 세션 관리
여러 사용자를 위해 동시에 코드를 생성하는 프로덕션 앱은 동시성을 부차적인 문제가 아닌 일급 관심사로 처리하는 샌드박스가 필요합니다.
핵심 질문은 다음과 같습니다:
세션별 격리: 50개의 세션이 동시에 실행 중일 때, 각 세션은 자체 격리된 파일 시스템, 프로세스 트리, 네트워크 네임스페이스 및 자격 증명 범위를 가지고 있습니까? 세션 간 상태 누출은 멀티 테넌트 샌드박스 앱에서 가장 해로운 실패 모드 중 하나이며, 세션이 순차적으로 실행되는 테스트에서는 종종 보이지 않습니다.
세션 한도 및 역압: 샌드박스가 동시성 한도를 명확한 API 계약으로 표시합니까? 500개의 요청이 도착하고 플랫폼이 100개의 동시 세션을 지원하는 경우, API는 구조화된 오류를 반환합니까, 요청을 대기열에 넣습니까, 아니면 조용히 성능을 저하시킵니까? 프로덕션 앱은 역압, 대기열 관리, 사용자 피드백을 구현하기 위해 이 신호가 필요합니다.
부하 시 리소스 공정성: 한 세션이 비정상적으로 높은 CPU 또는 메모리를 소비할 때, 세션별 리소스 제한에 의해 다른 세션이 보호됩니까, 아니면 하나의 시끄러운 워크로드가 전체 풀을 저하시킬 수 있습니까?
웜 풀 및 세션 시작 대기 시간: 대화형 코딩 기능은 1초 미만의 세션 시작 시간이 필요합니다. 일반적으로 주문형 부팅이 아닌 즉시 클레임할 수 있는 사전 초기화된 환경 풀이 필요합니다. 플랫폼이 웜 풀 가용성과 다양한 동시성 수준에서 예상되는 시작 대기 시간을 문서화하는지 확인하십시오.
세션 재사용 vs. 새 환경: 일부 앱은 여러 에이전트 턴에 걸쳐 장기 실행 세션을 재사용하는 것이 유리한 반면, 다른 앱은 각 요청에 대해 깨끗한 환경이 필요합니다. 두 패턴이 모두 지원되는지, 그리고 세션 재사용이 이전 대화의 오래된 상태를 전달하지 않는지 확인하십시오.
라이프사이클 API: 생성, 실행, 종료
라이프사이클 API는 애플리케이션과 샌드박스 런타임 간의 인터페이스입니다. 프로덕션 등급의 API는 최소한 다음을 노출해야 합니다:
생성(Create): 선택적으로 템플릿 또는 스냅샷에서, 지정된 리소스 제한, 환경 변수, 마운트된 볼륨으로 새 샌드백 세션을 초기화합니다. 응답에는 세션 ID와 준비 신호가 포함되어야 하며, 단순한 확인(acknowledgment)이 아니어야 합니다.
실행(Execute): 실행할 코드 또는 명령을 제출합니다. 실행 ID를 반환하는 비동기 호출이어야 합니다. API는 작업 디렉토리, 호출에 대한 환경 재정의, 시간 초과를 지정하는 것을 지원해야 합니다.
출력 스트리밍: 실행이 완료된 후의 최종 결과뿐만 아니라 스트림으로 stdout 및 stderr를 검색합니다. 스트리밍은 장기 실행 작업, 많은 초가 걸리는 에이전트 단계, 사용자에게 점진적 진행 상황을 보여주는 UX에 중요합니다.
종료(Terminate): 실행이 완료되기 전에 실행 중인 작업을 종료합니다. 샌드박스는 프로세스 트리가 정리됨을 보장해야 하며, 부모 프로세스만 정리해서는 안 됩니다.
정리(Cleanup): 세션을 파괴하고 모든 관련 리소스(파일 시스템, 메모리, 프로세스 슬롯, 네트워크 상태, 보유된 자격 증명)를 해제합니다. 이 호출은 멱등(idempotent)이어야 하므로 네트워크 오류 후 재시도가 오류를 발생시키지 않아야 합니다.
파일 업로드 및 다운로드: 실행 전에 입력 파일을 샌드박스로 전송하고 실행 후에 출력 아티팩트를 검색합니다. 파일 전송은 크기 제한이 있어야 하며, 쓰기 가능한 경로에 대해 정책이 제어되어야 합니다.
프로덕션 사용을 위해 확인할 가치가 있는 추가 기능:
- 일시 중지 및 재개: 장기 실행 세션을 상태 손실 없이 일시 중지했다가 나중에 재개할 수 있습니까? 이는 속도 제한, 비용 제어, 에이전트 턴 간 세션 핸드오프에 유용합니다.
- 스냅샷: 현재 세션 상태를 캡처하여 향후 세션의 시작점으로 사용할 수 있습니까? 이는 웜 풀 및 재사용 가능한 환경을 위한 핵심 메커니즘입니다.
- 시간 초과 강제: 실행 중인 코드가 벽시계 시간 초과를 초과하면 플랫폼이 이를 깔끔하게 종료하고 올바른 종료 상태를 보고합니까?
관찰 가능성: 로그, 메트릭, 트레이스
볼 수 없는 것은 디버깅하거나 감사할 수 없습니다. 프로덕션 샌드박스는 부가적인 기능이 아니라 내장된 관찰 가능성이 필요합니다.
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을 기록하지 마십시오. 샌드박스가 세션 종료 시 환경 변수와 마운트된 비밀 파일을 정리하는지 확인하십시오. 편집을 샌드박스 보장이 아닌 애플리케이션 책임으로 취급하십시오.
