오픈소스 AI 에이전트 샌드박스 옵션: 자체 호스팅 전 확인해야 할 사항

오픈소스 AI 에이전트 샌드박스 옵션: 자체 호스팅 전 확인해야 할 사항

오픈소스 AI 에이전트 샌드박스를 평가하는 팀은 먼저 실제 격리 경계, 워크스페이스 지속성 모델, 이그레스 및 패키지 제어, 비밀 처리, 감사 가능성, 그리고 이를 안전하게 운영하는 데 필요한 운영 노력을 확인해야 합니다. 올바른 선택은 보편적인 승자를 찾는 것보다는 위협 모델, 에이전트 워크로드, 규정 준수 요구 사항, 엔지니어링 역량에 맞는 샌드박스 모델을 선택하는 데 더 가깝습니다.

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

AI 에이전트 샌드박스는 에이전트가 호스트 머신이나 프로덕션 네트워크에 대한 광범위한 액세스 없이 코드를 실행하고, 파일을 검사하고, 브라우저를 자동화하고, 도구를 호출하거나 작업을 완료할 수 있는 실행 환경입니다. 이는 모델 추론과 실제 세계 부작용 사이의 경계입니다.

현대 에이전트는 단순히 텍스트를 작성하는 것 이상을 수행하기 때문에 이 경계가 중요합니다. 코딩 에이전트는 리포지토리를 복제하고, 종속성을 설치하고, 테스트를 실행하고, 미리보기 포트를 열고, 풀 리퀘스트를 작성할 수 있습니다. 브라우저 또는 데이터 에이전트는 스크립트를 실행하고, 상태를 유지하고, 파일을 다운로드하고, 스크린샷을 캡처할 수 있습니다. 이러한 작업에는 런타임이 필요하며, 런타임에는 제어가 필요합니다.

평가를 위해 네 가지 레이어를 분리하세요.

레이어 결정하는 사항 중요한 이유
에이전트 프레임워크 모델이 계획을 세우고, 도구를 호출하고, 결과에 반응하는 방식 좋은 프레임워크가 자동으로 안전한 런타임을 만들지 않음
샌드박스 런타임 명령, 파일, 브라우저 세션, 프로세스가 실행되는 곳 주요 격리 및 수명 주기 경계
정책 플레인 샌드박스가 읽고, 가져오고, 설치하고, 노출하거나 유지할 수 있는 항목 샌드박스가 위험 모델과 일치하는지 결정
검토 플레인 실행 후 사용 가능한 로그, 차이점, 아티팩트, 승인 사람이 무슨 일이 일어났는지 확인할 수 있는지 결정

자체 호스팅 및 오픈소스 옵션은 팀이 해당 레이어를 더 잘 제어할 수 있게 해줍니다. 또한 운영 팀에 더 많은 책임을 부여합니다.

자체 호스팅은 언제 합리적인가요?

자체 호스팅은 팀이 배포 위치, 네트워크 경로, 기본 이미지, 보존 규칙, 로깅 시스템 또는 내부 보안 검토를 직접 제어해야 할 때 합리적일 수 있습니다.

실제 요구 사항이 단순히 "에이전트가 안전하게 코드를 실행하도록 하는 것"인 경우에는 덜 매력적입니다. 이 경우 관리형 샌드박스가 프로비저닝, 확장, 런타임 업데이트, 가동 시간 및 개발자 경험의 일부를 제공자가 처리하므로 운영하기 더 쉬울 수 있습니다.

다음 중 하나라도 해당되면 자체 호스팅을 사용하세요.

  • 정책상 특정 클라우드 계정, VPC, 리전 또는 프라이빗 네트워크 내에서 실행해야 합니다.
  • 에이전트에 사용자 지정 기본 이미지, 내부 패키지 미러, 비공개 소스 시스템 또는 내부 브라우저 대상이 필요합니다.
  • 보안 팀이 격리 스택, 이그레스 경로, 보존 모델 및 로그를 검사하려고 합니다.
  • 런타임 구성 요소 패치, 남용 신호 감시, 비밀 순환, 오류 디버깅을 수행할 엔지니어링 역량이 있습니다.

운영 작업을 수행할 인력이 없으면 기본적으로 자체 호스팅을 피하세요. 단일 컨테이너나 VM이 명령을 실행할 수 있기 때문에 샌드박스는 데모 중에 간단해 보입니다. 프로덕션은 다릅니다. 동시성 제한, 리소스 할당량, 이미지 정리, 패키지 캐시 전략, 네트워크 정책, 비밀 범위 지정, 원격 측정, 인시던트 대응 및 명확한 업그레이드 경로가 필요합니다.

평가할 오픈소스 샌드박스 옵션

오픈소스 환경은 빠르게 변화하고 있으므로 이 정보를 영구적인 기능 매트릭스가 아닌 날짜가 지정된 오리엔테이션으로 취급하세요. 2026년 6월 24일 기준으로 다음 프로젝트와 도구는 자체 호스팅 또는 오픈소스 에이전트 샌드박스 경로를 비교할 때 검사할 수 있는 유용한 예시입니다.

옵션 먼저 검사할 사항 자체 호스팅 질문
E2B 오픈소스 샌드박스/런타임 구성 요소, SDK, 템플릿 및 Firecracker 기반 샌드박스 포지셔닝 어떤 부분이 오픈소스이며, 현재 지원되는 배포 모드는 무엇이며, 팀에 남은 운영 작업은 무엇인가요?
Daytona 개발 및 AI 에이전트 사용 사례를 위한 워크스페이스 및 샌드박스 인프라(오픈소스 리포지토리 및 자체 호스팅 문서 경로 포함) 워크스페이스 모델, API 표면 및 배포 아키텍처가 에이전트 워크로드 및 보안 정책과 일치합니까?
OpenHands 샌드박스 환경을 사용하여 에이전트 작업을 실행하기 위한 문서화된 런타임 아키텍처를 갖춘 에이전트 플랫폼 전체 에이전트 플랫폼을 채택하는 것인지, 아니면 런타임 패턴만 차용하는 것인지?
SWE-ReX 소프트웨어 엔지니어링 에이전트 연구 및 평가 워크플로에 사용되는 오픈소스 런타임 인터페이스 추상화가 프로덕션 요구 사항에 적합합니까, 아니면 주로 제어된 평가 도구로 유용합니까?
Modal Sandbox 오픈소스 자체 호스팅 런타임이 아닌 관리형 샌드박스 API API 인체 공학, 프로세스 실행, 파일 시스템 및 시간 초과 동작에 대한 비교 포인트로 유용하지만 자체 호스팅 옵션으로는 유용하지 않음

표만 보고 선택하지 마세요. 각 프로젝트에 대해 현재 문서를 읽고, 최신 릴리스 노트를 검토하고, 자체 워크로드로 소규모 개념 증명을 실행하세요. 평가는 다음 질문에 답해야 합니다: 무엇을 실행할 수 있는지, 무엇이 격리되는지, 무엇이 지속되는지, 네트워크에 도달할 수 있는 것은 무엇인지, 비밀을 볼 수 있는 것은 무엇인지, 작업 후 어떤 증거가 남는지.

격리 경계: 컨테이너, 마이크로VM, 전체 VM

첫 번째 질문은 "안전한가?"가 아닙니다. 유용한 질문은 "격리 경계는 무엇인가?"입니다.

컨테이너는 빠르고 친숙하며 Docker 이미지를 기반으로 구축하기 쉽기 때문에 매력적입니다. 신뢰할 수 있는 내부 작업, CI 유사 작업, 단기 분석 및 위협 모델이 적당한 개발 워크플로에 적합할 수 있습니다. 그러나 컨테이너는 호스트 커널을 공유하므로 신뢰할 수 없는 코드나 멀티 테넌트 워크로드를 처리하는 팀은 커널 노출, seccomp/AppArmor 프로필, 사용자 네임스페이스, 마운트된 볼륨, 권한 모드 및 탈출 대응을 평가해야 합니다.

Firecracker 스타일 격리와 같은 마이크로VM은 컨테이너 워크플로보다 전통적인 VM에 더 가까운 시작 및 밀도를 유지하면서 더 강력한 VM 경계를 추가합니다. 각 세션에 별도의 커널과 더 엄격한 리소스 경계를 제공할 수 있기 때문에 에이전트 샌드박스 논의에서 일반적입니다. 이것이 네트워크 정책, 비밀 제어, 패치 또는 호스트 강화의 필요성을 제거하지는 않습니다. 런타임 격리 계층만 명확히 할 뿐입니다.

전체 VM은 더 엄격한 엔터프라이즈 환경, 데스크톱 자동화 또는 더 넓은 OS 표면이 필요한 워크플로에 적합할 수 있습니다. 트레이드오프는 더 무거운 시작, 이미지 관리 및 용량 계획입니다.

자체 호스팅 전에 다음 질문을 하세요.

확인 사항 검증할 내용
커널 경계 샌드박스가 다른 워크로드와 커널을 공유합니까, 아니면 각 세션이 별도의 커널을 얻습니까?
테넌트 경계 두 고객 세션이 호스트 수준 리소스, 볼륨, 캐시, 브라우저 프로필 또는 네트워크 네임스페이스를 공유할 수 있습니까?
권한 모델 샌드박스가 권한 있는 컨테이너, 루트 사용자, 마운트된 Docker 소켓 또는 호스트 경로를 실행합니까?
탈출 대응 커널, 런타임, 컨테이너 및 하이퍼바이저 취약점이 어떻게 패치되고 배포됩니까?
리소스 제어 CPU, 메모리, 디스크, 프로세스 수, 열린 파일 및 런타임 지속 시간이 세션별로 적용됩니까?
부수 채널 위험 모델에 공유 CPU, 캐시, 디스크 또는 소음 이웃 동작에 대한 완화가 필요합니까?

프로젝트가 "격리됨"이라고 설명하면 메커니즘을 알 때까지 계속 읽으세요.

상태, 파일 및 워크스페이스 수명 주기

샌드박스가 수명이 짧더라도 에이전트 작업은 상태 저장입니다. 에이전트는 파일을 생성하고, 패키지를 설치하고, 브라우저 프로필을 유지하고, 백그라운드 프로세스를 실행하거나 사람이 아티팩트를 검토하는 동안 일시 중지할 수 있습니다. 샌드박스에는 명확한 워크스페이스 모델이 필요합니다.

수명 주기로 시작하세요.

  1. 기본 이미지 또는 템플릿에서 샌드박스를 생성합니다.
  2. 허용된 워크스페이스를 마운트하거나 복제합니다.
  3. 정책에 따라 설정 명령을 실행합니다.
  4. 에이전트가 명령, 브라우저 작업 및 파일 작업을 실행하도록 합니다.
  5. 출력 추출: 차이점, 로그, 스크린샷, 보고서 또는 다운로드된 파일.
  6. 샌드박스를 중지, 일시 중지, 스냅샷, 보관 또는 삭제합니다.

중요한 점은 지속성이 의도적이어야 한다는 것입니다. 지속적인 워크스페이스는 장기 실행 에이전트, 다단계 코딩 작업 및 사람이 개입하는 검토에 유용합니다. 또한 정리가 약한 경우 만료된 자격 증명, 캐시된 종속성, 브라우저 쿠키, 생성된 데이터 및 부분 작업이 세션 간에 누출될 수 있는 곳이기도 합니다.

자체 호스팅 전에 다음을 정의하세요.

  • 각 에이전트 작업이 새 파일 시스템을 가져오는지 여부.
  • 패키지 캐시가 공유, 범위 지정 또는 재구축되는지 여부.
  • 브라우저 프로필이 실행 간에 지속되는지 여부.
  • 사용자 업로드가 복사, 마운트 또는 스트리밍되는지 여부.
  • 스냅샷에 비밀, 토큰, 쿠키 또는 내부 로그가 포함되는지 여부.
  • 로그 및 아티팩트가 보존되는 기간.
  • 일시 중지된 세션을 다시 열 수 있는 사람.

좋은 샌드박스는 기본 수명 주기를 지루하게 만듭니다. 작업이 시작되기 전에 무엇이 존재하는지, 작업 중에 무엇이 변경되는지, 정리 후에 무엇이 남는지 설명할 수 있어야 합니다.

네트워크, 패키지 및 이그레스 정책

네트워크 액세스는 많은 샌드박스 설계가 모호해지는 부분입니다. 에이전트는 종종 인터넷이 필요하지만 "인터넷 액세스"는 하나의 권한이 아닙니다.

코딩 에이전트는 패키지 레지스트리, 공개 문서, Git 리모트 및 미리보기 URL이 필요할 수 있습니다. 브라우저 에이전트는 테스트 애플리케이션, 스테이징 API 및 스크린샷 저장소가 필요할 수 있습니다. 데이터 에이전트는 객체 스토리지, 데이터베이스 복제본 또는 제한된 SaaS API가 필요할 수 있습니다. 이는 서로 다른 위험이 있는 서로 다른 권한입니다.

범주를 사용하세요.

이그레스 유형 일반적인 필요 정책 질문
패키지 레지스트리 npm, pip, apt, cargo, 모델/도구 종속성 레지스트리가 허용 목록에 포함되고, 캐시되고, 스캔되고, 로깅됩니까?
공개 웹 문서 조회, 브라우저 작업, 공개 데이터 수집 임의 브라우징이 허용, 프록시, 속도 제한 및 감사 가능합니까?
Git 액세스 리포지토리 복제, 브랜치 푸시, 서브모듈 가져오기 토큰이 가능한 경우 읽기 전용이고 작업 범위로 지정됩니까?
내부 API 스테이징 서비스, 테스트 앱, 비공개 패키지 미러 환경, 서비스, 경로 및 자격 증명별로 액세스가 제한됩니까?
미리보기 인그레스 로컬 웹 앱 또는 생성된 보고서의 사람 검토 어떤 포트가, 누구에게, 얼마 동안, 어떤 인증으로 노출됩니까?
웹훅 에이전트 콜백, CI 이벤트, 외부 도구 통합 샌드박스가 임의 호스트로 아웃바운드 콜백을 보낼 수 있습니까?

패키지 정책은 특별한 주의가 필요합니다. 많은 에이전트 작업은 종속성 설치 없이 실패하지만, 패키지 설치는 설치 후 스크립트, 네이티브 바이너리, 레지스트리 손상, 타이포스쿼팅 위험 및 긴 캐시 수명을 가져옵니다. Lockfile 기반 설치, 승인된 레지스트리, 수명이 짧은 토큰 및 설치 로그를 선호하세요.

자체 호스팅 시스템의 경우 DNS 로그, 프록시 구성, 인증서 신뢰 저장소 및 네트워크 인시던트 대응을 누가 소유할지도 결정하세요.

비밀, 로그 및 감사 추적

에이전트 샌드박스는 모델이 원시 자격 증명을 쉽게 출력, 복사 또는 유출할 수 있는 장소가 되어서는 안 됩니다.

가장 안전한 패턴은 작업 범위 액세스입니다. 샌드박스에 작업에 필요한 최소 자격 증명을 부여하고 작업이 끝나면 제거하세요. 코딩 작업에는 읽기 전용 리포지토리 토큰과 풀 리퀘스트 토큰이 필요할 수 있습니다. 브라우저 작업에는 프로덕션 사용자가 아닌 테스트 계정이 필요할 수 있습니다. 데이터 작업에는 상시 클라우드 자격 증명이 아닌 임시 서명된 URL이 필요할 수 있습니다.

에이전트가 쉽게 읽을 수 있는 파일에 비밀을 저장하지 마세요. 환경 변수는 편리하지만 많은 디버깅 명령이 환경 상태를 출력합니다. 플랫폼이 브로커된 작업을 지원하는 경우 이를 사용하세요. 샌드박스가 모델 루프에 원시 자격 증명을 노출하지 않고 좁은 작업을 수행하도록 합니다.

로깅은 검토 및 인시던트 대응에 충분히 강력해야 합니다.

  • 요청, 승인, 거부 및 실행된 명령.
  • 작업 디렉터리, 종료 코드, stdout, stderr, 시간 초과 및 리소스 사용량.
  • 작업에서 생성된 파일 아티팩트.
  • 정책이 지원하는 세분성의 네트워크 대상.
  • 패키지 이름, 버전, 레지스트리 및 설치 출력.
  • 비밀 수정 결정 및 수정 실패.
  • 위험한 작업에 대한 사람의 승인.

목표는 검토자를 로그에 빠뜨리는 것이 아닙니다. 목표는 에이전트가 놀라운 출력을 생성하거나, 종속성이 변경되거나, 토큰이 노출된 것으로 의심될 때 무슨 일이 일어났는지 재구성하는 것입니다.

재설정, 스냅샷 및 멀티 테넌트 위험

재설정 동작은 데모 끝의 정리 스크립트가 아닌 프로덕션 기능입니다.

임시 샌드박스는 추론하기 더 간단합니다. 생성, 실행, 아티팩트 추출, 삭제. 짧은 코드 실행, 일회성 브라우저 작업 및 평가 작업에 잘 작동합니다. 영구 샌드박스는 더 긴 워크플로에 도움이 되지만 소유권, 만료 및 검토 제어가 필요합니다.

스냅샷 및 템플릿은 이 두 모델 사이에 있습니다. 준비된 환경을 보존하여 시작 속도를 높일 수 있지만 스냅샷 내부의 모든 것도 보존합니다. 다음이 포함되어 있는지 확인하세요.

  • 설치된 패키지 및 캐시.
  • 셸 기록 또는 프로세스 상태.
  • 브라우저 쿠키, 로컬 저장소 및 다운로드.
  • 임시 파일 및 생성된 출력.
  • 자격 증명 또는 구성 파일.
  • 이전 작업의 로그.

멀티 테넌트 시스템의 경우 스케줄러가 워크로드를 배치하는 방법, 캐시가 공유되는지, 디스크가 지워지는 방법 및 호스트 수준 리소스가 모니터링되는지 물어보세요. 또한 실패 중에 무슨 일이 일어나는지 물어보세요. 충돌, 시간 초과 또는 컨트롤러 손실이 발생한 샌드박스는 여전히 정리 및 아티팩트 처리가 필요합니다.

개발자 액세스 및 디버깅 경로

자체 호스팅 샌드박스에는 실용적인 디버깅 스토리가 필요합니다. 에이전트가 실패하면 개발자는 문제가 모델, 도구 호출, 런타임, 이미지, 패키지 미러, 네트워크 경로 또는 대상 애플리케이션 중 어디에 있는지 알아야 합니다.

유용한 디버깅 경로는 다음과 같습니다.

  • 동일한 기본 이미지에서 명령을 재생하는 방법.
  • 명령 실행 및 도구 호출에 대한 구조화된 로그.
  • 다운로드 가능한 아티팩트 및 스크린샷.
  • 명시적 시간 초과 및 리소스 제한 오류.
  • 정책이 허용하는 경우 개발자가 라이브 세션에 연결할 수 있는 제어된 방법.
  • 버전이 지정된 템플릿 또는 이미지를 통해 실패를 환경 버전에 연결할 수 있습니다.
  • 사용자에게 표시되는 출력과 내부 런타임 로그의 명확한 분리.

긴급 액세스에 주의하세요. 라이브 샌드박스에 대한 광범위한 셸 액세스는 샌드박스가 적용하도록 구축된 동일한 격리 가정을 위반할 수 있습니다. 누가 연결할 수 있는지, 무엇을 볼 수 있는지, 비밀이 수정되는지, 액세스가 기록되는지 정의하세요.

Novita Agent Sandbox의 위치

Novita Agent Sandbox는 코드 실행, 브라우저 자동화, 컴퓨터 사용 스타일 워크플로, 데이터 분석, 평가 및 장기 실행 에이전트 워크플로를 위한 관리형 에이전트 런타임입니다. Novita Agent Sandbox 문서는 수명 주기, 명령, 파일, 브라우저 세션 및 관련 워크플로 프리미티브에 대한 SDK 및 CLI 경로가 있는 상태 저장 샌드박스 환경을 설명합니다.

따라서 Novita는 팀이 처음부터 전체 자체 호스팅 운영 부담을 지지 않고 에이전트 실행 인프라를 원할 때 평가할 대상입니다.

경계를 명확히 유지하세요.

  • 배포 제어, 소스 수준 사용자 지정 또는 내부 인프라 소유권이 우선시되는 경우 오픈소스 또는 자체 호스팅 런타임을 사용하세요.
  • 더 빠른 채택, 제공자 관리 런타임 운영 및 모든 계층을 소유하는 것보다 API 우선 워크플로가 더 중요한 경우 관리형 샌드박스를 사용하세요.
  • 두 경우 모두 격리, 이그레스, 패키지 설치, 비밀, 로그, 지속성 및 검토 게이트를 자체 정책에 대해 평가하세요.

어떤 제공자 이름도 보안 보장으로 취급하지 마세요. 여전히 아키텍처 검토가 필요한 런타임 선택으로 취급하세요.

자체 호스팅 체크리스트

오픈소스 AI 에이전트 샌드박스를 프로덕션에 도입하기 전에 이 체크리스트를 사용하세요.

영역 프로덕션 전 최소 질문
격리 경계가 컨테이너, 마이크로VM, 전체 VM 또는 다른 것이며, 워크로드에 충분합니까?
워크스페이스 각 작업이 알려진 파일 시스템 상태에서 시작되며 재설정할 수 있습니까?
지속성 일시 중지, 재개, 스냅샷 및 보존이 우발적이지 않고 명시적입니까?
네트워크 패키지 가져오기, 브라우징, API 호출, Git, 웹훅 및 미리보기 인그레스가 별도로 제어됩니까?
패키지 Lockfile, 레지스트리, 설치 후 스크립트, 네이티브 바이너리 및 캐시가 관리됩니까?
비밀 자격 증명이 작업 범위로 지정되고, 수정되고, 순환되며 관련 없는 명령에 사용할 수 없습니까?
로그 검토자가 명령, 출력, 파일 변경, 네트워크 경로 및 승인을 재구성할 수 있습니까?
멀티 테넌시 호스트 공유, 캐시 공유, 디스크 정리, 할당량 및 소음 이웃 동작을 이해하고 있습니까?
디버깅 엔지니어가 보안 모델을 우회하지 않고 실패를 재현할 수 있습니까?
운영 누가 이미지, 런타임, 커널, 종속성 및 샌드박스 컨트롤러를 패치합니까?
남용 제어 시간 초과, 리소스 제한, 속도 제한 및 종료 경로가 적용됩니까?
종료 경로 샌드박스가 충돌하거나 시간 초과되더라도 아티팩트를 내보내고 검토할 수 있습니까?

여러 답변이 불명확하면 프로젝트를 프로토타입 단계로 유지하세요. 경계를 설명할 수 없는 샌드박스는 대규모로 신뢰할 수 없는 에이전트 작업을 실행할 준비가 되지 않은 것입니다.

FAQ

가장 좋은 오픈소스 AI 에이전트 샌드박스는 무엇인가요?

모든 팀에 적합한 단일 최고의 오픈소스 AI 에이전트 샌드박스는 없습니다. 올바른 선택은 격리 요구 사항, 배포 모델, 에이전트 워크로드, 이그레스 정책, 지속성 요구 사항 및 운영 역량에 따라 달라집니다. 각 후보 런타임 내에서 자체 작업을 실행하여 옵션을 비교하세요.

Docker가 AI 에이전트 샌드박스에 충분한가요?

Docker는 신뢰할 수 있는 내부 자동화, 로컬 개발 및 CI 유사 작업에 충분할 수 있지만 신뢰할 수 없는 코드 또는 엄격한 멀티 테넌트 워크로드에는 충분하지 않을 수 있습니다. 컨테이너만으로는 커널 공유, 권한, 마운트된 볼륨, 네트워크 액세스, 비밀 및 탈출 대응을 확인하세요.

마이크로VM이 에이전트 워크로드에서 컨테이너보다 더 안전한가요?

마이크로VM은 각 샌드박스가 별도의 커널로 실행될 수 있기 때문에 더 강력한 격리 경계를 제공할 수 있습니다. 이것이 이그레스, 패키지, 비밀, 로깅, 패치 또는 멀티 테넌트 운영을 자동으로 해결하지는 않습니다. 마이크로VM을 전체 보안 모델이 아닌 아키텍처의 한 부분으로 취급하세요.

에이전트 샌드박스를 자체 호스팅하기 전에 무엇을 테스트해야 하나요?

파일을 복제하거나 마운트하고, 종속성을 설치하고, 명령을 실행하고, 비밀을 처리하고, 승인된 네트워크 대상에 도달하고, 아티팩트를 생성하고, 시간 초과되고, 재설정되는 실제 워크로드를 테스트하세요. 또한 패키지 설치 실패, 브라우저 충돌, 네트워크 거부, 리소스 제한 및 컨트롤러 오류 후 샌드박스 정리와 같은 실패 경로도 테스트하세요.

자체 호스팅 대신 관리형 샌드박스를 언제 사용해야 하나요?

팀이 런타임 패치, 확장, 용량 계획 및 인프라 운영을 소유하지 않고 에이전트 실행 API 및 검토 아티팩트를 원할 때 관리형 샌드박스를 사용하세요. 배포 제어 또는 소스 수준 사용자 지정이 해당 작업을 정당화할 만큼 중요한 경우 자체 호스팅하세요.

추천 문서