코드 실행에서 지속 운영까지, 기업용 에이전트 샌드박스 실천

Coding Agent가 실제로 작업을 시작하면, 모델을 호출하는 것만으로는 훨씬 부족합니다. 코드를 가져오고, 의존성을 설치하고, 테스트를 실행하고, 파일을 수정한 뒤, 몇 시간 뒤의 다음 대화 라운드에서 이전 환경에 이어서 계속 작업합니다. 이러한 실행 환경은 어디서 오고, 서로 어떻게 격리되며, 유휴 상태일 때 누가 해제할까요? VCI Agent Sandbox가 내놓은 답은 이것입니다. Agent의 실행 환경을 Kubernetes 네이티브로 선언 가능하고, 관리 가능하며, 회수 가능한 워크로드로 만드는 것입니다.

Agent 실행 환경은 클라우드 네이티브 관리가 필요하다

답변 생성에서 작업 실행으로 넘어가면서, Agent가 마주하는 것은 더 이상 텍스트 입출력만이 아닙니다. 서로 다른 Agent 시나리오가 필요로 하는 데이터와 권한은 모두 다르며, Agent가 실행하는 동작은 모두 환경을 변화시키기 때문에 권한, 데이터, 네트워크 접근이 반드시 관리해야 할 경계가 됩니다.

Coding Agent 시나리오: 프로덕션 애플리케이션으로 들어가는 실행 프로세스를 제약해야 합니다. 목표 작업이 정상적인 데이터 분석이나 코드 수정이라 하더라도, 실행 과정에서는 잘못된 파일 조작, 의존성 충돌, 통제를 벗어난 리소스 소모가 발생할 수 있습니다. 코드를 독립된 VCI Agent Sandbox에서 실행하게 하고, Agent가 외부에서 작업을 오케스트레이션하고 결과를 받도록 하면, 실행 이상이 주 애플리케이션과 다른 작업에 미치는 영향을 줄일 수 있습니다.

Computer-use Agent 시나리오: 코드와 Agent 조작 권한을 격리해야 합니다. 브라우저, 데스크톱, 파일 시스템은 Agent에게 작업을 완수할 도구를 제공하지만, 잘못된 조작이 곧바로 비즈니스 데이터에 직접 영향을 미치게 할 수도 있습니다. 따라서 작업을 위해 독립된 브라우저 또는 데스크톱 환경을 준비하고, 필요한 파일과 신원 자격 증명만 제공하며, 접근 가능한 네트워크 대상을 제한해야 합니다. 거래, 인가 등 영향이 큰 작업이 관련되면 여전히 사람의 확인이 필요합니다.

Agent RL 및 평가 시나리오: 독립적인 시행착오 환경이 필요합니다. 서로 다른 작업과 탐색 분기에는 각자의 파일, 의존성, 환경 상태가 필요하며, 이전 라운드 실행이 남긴 수정이 다음 라운드 결과에 영향을 주지 않도록 해야 합니다. 환경 실행을 모델 추론, 훈련 프로세스와 분리하면 이들의 리소스와 라이프사이클을 각각 관리하기 쉬워집니다. 모델 서비스는 지속적으로 의사결정을 제공하고, 실행 환경은 작업에 따라 준비, 재설정 또는 회수됩니다.

서로 다른 시나리오의 Agent 요구를 종합하면, Agent가 작업을 실행하는 것은 그것에 비즈니스 시스템의 권한을 부여하는 것과 같지 않습니다. 기업은 두 가지를 동시에 해결해야 합니다.

- Agent 실행 리스크를 명확한 경계 안으로 제한할 것;

- 독립된 VCI Agent Sandbox를 기업의 기존 인프라와 연동하여 통합된 운영 체계로 들어가게 할 것.

Agent Sandbox: 실행 환경은 독립적, 인프라와 운영 방식은 통합 운영

실행 리스크를 격리한다고 해서 기업이 Agent Sandbox를 위해 별도의 고립된 플랫폼을 다시 구축해야 하는 것은 아닙니다. 이미 Kubernetes로 Agent 서비스, 작업 오케스트레이션, 비즈니스 애플리케이션을 운영하는 팀에게 Agent Sandbox는 기업의 기존 클라우드 네이티브 인프라의 일부가 되는 편이 더 적합합니다. 실행 경계는 독립적으로 유지하고, 관리 방식은 일관되게 유지하는 것입니다. Kubernetes에서 Agent Sandbox를 관리하는 데에는 이미 커뮤니티 표준화된 리소스 모델과 오픈소스 컨트롤러가 있어, 기업이 범용 라이프사이클 관리 로직을 처음부터 자체 개발할 필요가 없습니다. kubernetes-sigs/agent-sandbox는 독립 실행 환경을 선언 가능하고 관리 가능한 리소스로 추상화하여, 앞 절에서 말한 "실행에는 경계가 있고 관리에는 연동이 가능하다"는 것에 바로 쓸 수 있는 오픈소스 기반을 마련했습니다.

- 기존 Agent 인프라와 연동. Kubernetes 기반으로 Agent 인프라를 구축한 기업의 경우, 작업 오케스트레이션 서비스와 샌드박스 실행 환경은 동일한 클라우드 네이티브 기반 위에 구축될 수 있습니다. Agent Sandbox는 Kubernetes 리소스의 형태로 기존 플랫폼에 포함되어 Agent 서비스와 협력하여 운영되며, 기존의 이미지, 네트워크, 스토리지 및 리소스 관리 체계를 재사용합니다. 기업은 실행 환경을 위해 단절된 인프라를 따로 구축하지 않고도, 작업 격리를 유지하면서 오케스트레이션과 실행의 통합 관리를 실현할 수 있습니다.

- 운영팀의 업무 방식과 연동. 사용자는 선언적 방식으로 VCI Agent Sandbox에 필요한 이미지, 리소스, 스토리지를 정의하고, 관리 컴포넌트가 이를 Agent Sandbox 환경의 목표 상태로 자동 정렬하며, 과정에서 문제가 발생하면 자동으로 재시도하고 롤백합니다. 각 비즈니스에 흩어져 있는 생성, 폴링, 정리 스크립트를 줄일 수 있습니다.

기업에 필요한 것은 고립된 코드 실행 컨테이너가 아니라 "실행에는 경계가 있고, 관리·운영에는 연동이 가능한" Agent Sandbox 체계입니다. 애플리케이션 개발자는 Agent의 작업 오케스트레이션에 집중하고, 플랫폼과 운영팀은 클라우드 네이티브 Agent Sandbox 실행 환경을 통합 관리합니다.

VCI Agent Sandbox: 기업에 완전한 Agent 실행 환경과 운영 관리 기반을 제공

화산엔진 탄력 컨테이너 인스턴스(Volcengine Container Instance, 약칭 VCI)는 서버리스이자 컨테이너화된 컴퓨팅 서비스로, 화산엔진 컨테이너 서비스(VKE)와 원활하게 통합되어 Kubernetes 오케스트레이션 기능을 제공합니다.

VCI는 커뮤니티 Agent Sandbox(github.com/kubernetes-… AI Agent의 운반체)를 기반으로, AI Agent 전용 코드 실행 환경을 관리하기 위해 구축되어 강력한 프로세스 격리, 스토리지 격리, 네트워크 격리 기능을 갖추게 합니다.

제품 기능에 대해 더 알아보려면 클릭: docs.volcengine.com/docs/vke/Fe…

VCI Agent Sandbox 설계 이념:

- 네이티브 접속, 기존 도구와 거버넌스 메커니즘 그대로 사용. VCI Agent Sandbox 리소스는 Kubernetes API와 kubectl을 통해 관리할 수 있으며, API 계층의 인증, 인가, 감사 메커니즘을 재사용하고 접근 권한을 필요에 따라 구성합니다. 개발/운영팀은 VCI Agent Sandbox를 위해 별도의 관리 인터페이스를 배워야 하지 않으며, Kubernetes API를 중심으로 구축한 자동화 흐름도 연동 기반을 갖추게 됩니다. 네이티브 확장으로서 프로젝트는 Kubernetes 생태계의 진화에 따라 지속적으로 적응할 수 있습니다.

- 개방적 공동 구축, 요구와 역량의 지속적 반복. 커뮤니티에는 공개 토론, 코드 리뷰, 서브 프로젝트 회의가 마련되어 있으며, 릴리스 기록은 SDK, 예열 풀, 런타임 접근, 관측성 등의 방향에 대한 개선을 지속적으로 다룹니다. 기업이 마주친 공통 문제는 업스트림 논의로 들어갈 수 있고, 이미 해결된 문제는 다른 팀이 재사용할 수 있는 성과가 될 수 있습니다. 기업마다 각자 사설 구현을 유지하는 것과 비교하면, 커뮤니티 협업은 중복 구축을 줄이고 더 많은 엔지니어링 투입을 자사의 업무 차이에 쓸 수 있게 돕습니다.

- 벤더 중립, 실행 환경에 대한 선택권 보장. 프로젝트는 공개된 리소스 모델을 기반으로 하며, 서로 다른 런타임을 지원하고 벤더 중립을 유지하는 것을 설계 목표로 합니다. 기업은 공통 인터페이스를 중심으로 환경 템플릿과 관리 흐름을 구축하여 단일 벤더의 사설 API에 대한 의존을 낮출 수 있습니다.

격리 실행이 필요한 Agent 작업의 경우, VCI의 microvm 런타임은 가상 머신 수준의 격리 환경을 제공한다. 이를 기반으로 기업은 Kubernetes RBAC를 통해 VCI Agent Sandbox 리소스의 작업 권한을 관리하고, 리소스 쿼터로 사용 규모를 제한하며, 네트워크 보안 그룹과 결합해 허용되는 네트워크 접근을 제어할 수 있다. 런타임 격리, 관리 권한, 네트워크 접근이 각자의 역할을 수행함으로써 서로 다른 테넌트와 서로 다른 작업의 실행 환경이 명확한 경계를 갖추게 되고, 단일 작업의 이상이 주 애플리케이션과 다른 작업에 미치는 영향을 줄인다.

커뮤니티 오케스트레이션을 기반으로 환경 준비, 복구, 스토리지 적응을 더 효율적으로

1. 이미지 캐시: 이미지 준비를 앞당겨 시작 대기 시간을 줄인다. ImageCache를 통해 작업에 필요한 이미지 데이터를 미리 준비하여 동시 시작 시 이미지를 집중적으로 가져오면서 저장소와 네트워크에 가해지는 부담을 낮추고, 환경이 더 빠르게 실행 가능한 상태로 진입하도록 한다.

2. 스냅샷 관리: 작업 파일을 보존하여 복구 시 반복적인 준비를 줄인다. 커뮤니티의 일시 중지／복구 메커니즘 위에 VCI는 SandboxSnapShot과 SandboxSnapShotClass를 도입하여 스냅샷, 상태, 보존 정책을 통일적으로 기술한다. VCI Agent Sandbox 복구 시에는 저장된 작업 상태를 기반으로 환경을 재구축할 수 있어, 이미 존재하는 파일과 의존성을 다시 준비할 필요가 없다.

3. 차별화된 스토리지 마운트: 환경 템플릿은 공유하되, 인수 시 각자의 데이터를 연결한다. 워밍 풀은 일반적으로 동일한 SandboxTemplate을 기반으로 인스턴스를 준비하지만, 서로 다른 테넌트나 작업의 데이터 요구는 동일하지 않다. VCI는 사전 마운트와 동적 마운트 두 가지 모드를 제공한다. 사전 마운트는 고정 디렉터리에서 스토리지 볼륨이나 하위 디렉터리를 교체하고, 동적 마운트는 인수 시 디렉터리를 지정하고 마운트를 추가한다. 이렇게 하면 같은 종류의 작업은 환경 템플릿을 재사용하면서도 권한에 따라 각자의 작업 데이터를 연결할 수 있다.

클라우드 자원과 연동하여 VCI Agent Sandbox를 기업 통합 운영 체계에 포함

- 관측과 알림: 작업 실행은 물론 자원 사용도 확인한다. VCI Agent Sandbox의 지표, 로그, 이벤트를 기업의 기존 관측 체계와 연동하고, 매니지드 Prometheus, TLS 클라우드 로그, 메시지 알림과 결합하여 운영 상태와 자원 수위부터 이상排查에 이르는 운영 체인을 구축한다.

- 영속 스토리지: 작업 데이터와 컴퓨팅 인스턴스의 수명 주기를 분리하여 관리한다. 데이터 접근 방식에 따라 객체 스토리지 TOS와 탄력 파일 스토리지 EFS를 연결한다. 전자는 객체 데이터와 작업 산출물에, 후자는 파일 디렉터리와 공유 작업 공간에 사용된다.

- 네트워크와 접근: 호출 진입점을 기업 네트워크 아키텍처와 연결한다. 로드 밸런싱 CLB, API 게이트웨이 등의 컴포넌트를 통해 배포 방안에 따라 VCI Agent Sandbox 관리 및 실행 요청을 처리하여, Agent 애플리케이션이 통제된 경로에서 실행 환경에 접근하도록 한다.

VCI Agent Sandbox 모범 사례

CodingAgent의 클라우드 AI Coding

기업용 Coding Agent는 클라우드에서 코드를 실행하고 작업 파일을 관리하며, 여러 차례의 세션 사이에서 작업 상태를 이어가야 한다. VCI Agent Sandbox를 통해 모 CodingAgent는 클라우드 AI Coding의 코드 실행을 구현했다. 작업마다 독립적인 VCI Agent Sandbox를 부여받고, 환경은 필요에 따라 생성되고 사용 후 회수되며, 작업 파일은 VCI Agent Sandbox와 함께 보존되어 여러 차례의 작업이 지난번에 이어 계속될 수 있다.

사무용 개인 비서의 클라우드 AI Docs

모 사무용 개인 비서는 VCI Agent Sandbox를 통해 클라우드 AI Docs를 구현했다. 사용자 파일이 TOS 클라우드 스토리지에 우회 업로드되고, 권한에 따라 독립 샌드박스에 마운트되며, Agent가 E2B를 통해 샌드박스를 호출하여 코드 실행과 문서 처리를 수행하고, 생성된 산출물을 클라우드 스토리지에 다시 기록하여 클라이언트에 반환함으로써 작업 오케스트레이션, 격리 실행, 문서 스토리지를 분리한다.

서두의 장면으로 돌아가 보자. Agent가 코드를 실행하기 시작하고, 작업 파일을 생성하며, 다음 대화에서 작업을 이어갈 때, 이러한 실행 환경에는 통일된 답이 필요하다. VCI Agent Sandbox의 답은 세 문장으로 요약할 수 있다.

- 커뮤니티 표준에 정렬: 리소스 모델은 kubernetes-sigs/agent-sandbox에서 비롯되어 단일 벤더에 종속되지 않는다.

- 선제적 역량 강화: 호환성을 바탕으로 imagecache, sandboxsnapshot 등 핵심 특성을 확장하고, E2B SDK로 익숙한 호출 방식을 유지한다.

- 시나리오별 연산 자원 선택: 기업급 컴퓨팅 성능이 필요한 작업에는 vci.n4i를 선택할 수 있고, 개발 환경과 작업 데이터를 장기간 보존해야 하는 개발기와 다회차 Agent 시나리오에는 vci.u1을 선택할 수 있으며, 시작 지연과 동시 생성 능력에 대한 요구가 높은 RL, 배치 평가 등 시나리오에는 vci.s1을 선택할 수 있다.

부록: VCI Agent Sandbox 리소스 선정 참고

서로 다른 Agent 작업의 실행 환경에 대한 요구는 동일하지 않다. 어떤 것은 배치 시작과 동시성에 주목하고, 어떤 것은 작업 공간의 장기 보존을 필요로 하며, 어떤 것은 지정된 CPU나 GPU에 의존한다.

아래의 전형적인 시나리오에 따라 규격 패밀리를 선택한 뒤, 실제 작업을 결합하여 리소스 구성을 확정할 수 있다.

소속 팀이 이미 Kubernetes를 기반으로 코드 실행, Coding Agent 작업 공간 또는 배치 평가 환경을 구축했다면, VCI Agent Sandbox 체험을 신청하고 실제 작업 하나를 가지고 검증해 보길 바란다. 환경 준비가 빠른지, 상태 보존이 예상에 부합하는지, 리소스 청구서가 통제 가능한지, 기존 Kubernetes 플랫폼과 원활하게 융합될 수 있는지를 확인할 수 있다. 클릭 여기 로 문의하기 바란다.