Sandboxes for Agents

macOS에서 Claude Code의 /sandbox를 켜면 에이전트가 실행하는 셸 명령은 운영체제의 프로세스 샌드박스인 Seatbelt 안에서 돌아갑니다. 명령을 실행할 때마다 뜨던 확인 창은 거의 사라집니다. 그 대신 접근이 허용되지 않은 파일을 건드리거나 허용 목록에 없는 도메인으로 요청을 보내는 명령은 바로 실패합니다. 그러면 에이전트는 샌드박스를 벗어나서 다시 실행해도 될지 사용자에게 물어봅니다.

코드를 실행하는 에이전트를 만드는 팀은 샌드박스를 어떻게 연결할지도 고민해야 합니다. LangChain도 에이전트와 샌드박스를 연결하는 두 가지 패턴을 다룬 글에서 샌드박스를 에이전트 아키텍처에 통합하는 방법을 설명합니다. 어떤 방식을 고를지 판단하려면 샌드박스가 에이전트의 작업에 어떤 도움을 주는지부터 알아야 합니다.

샌드박스가 있으면 더 많은 작업을 에이전트에게 맡길 수 있습니다

샌드박스라는 말을 들으면 보통 위험한 작업을 막아 주는 보안 장치를 떠올립니다. 에이전트를 만드는 입장에서는 이 보호 장치 덕분에 더 많은 작업을 에이전트에게 맡길 수 있다는 점도 중요합니다.

샌드박스가 없어도 에이전트는 코드를 작성해서 로컬에서 실행할 수 있습니다. 문제는 그 코드가 실제 컴퓨터나 서버에서 사용자 권한으로 그대로 돌아간다는 점입니다. 그래서 보통은 에이전트가 미리 정의된 도구만 쓰게 하거나, 명령을 실행할 때마다 사람이 승인하도록 합니다. 샌드박스로 접근할 수 있는 파일과 네트워크를 제한하면, 그 범위 안에서는 에이전트가 필요한 코드를 직접 작성하고 실행하게 둘 수 있습니다. 미리 준비한 도구로 할 수 없는 작업도 코드로 처리할 수 있습니다.

코드로 작업을 처리하면 모델이 읽고 출력해야 하는 데이터도 줄일 수 있습니다. 에이전트가 도구를 직접 호출하면 도구의 응답이 모델이 입력으로 읽는 내용, 즉 컨텍스트에 추가됩니다. 모델은 다음에 무엇을 할지 판단할 때마다 이 내용을 다시 읽습니다. 응답이 길고 호출이 잦을수록 처리할 토큰이 많아져 비용과 응답 시간도 늘어납니다. 반면 샌드박스에서 실행하는 코드는 중간 결과를 변수나 파일에 저장해 두고 다음 작업에 사용할 수 있습니다. 모델에는 작업이 끝난 뒤 필요한 결과만 전달하면 됩니다.

예를 들어 스프레드시트의 데이터를 다른 시스템에 복사한다고 해 보겠습니다. 모델이 읽기 도구와 쓰기 도구를 차례로 호출하는 방식에서는, 먼저 읽기 도구가 반환한 행 데이터를 모델이 입력으로 받습니다. 그런 다음 쓰기 도구에 보낼 요청을 만들면서 같은 데이터를 다시 출력합니다. 복사할 내용이 많을수록 모델이 읽고 출력해야 하는 양도 많아집니다. 이 작업을 코드로 작성하면, 코드가 스프레드시트를 읽고 다른 시스템에 저장하는 과정까지 처리합니다. 모델에는 전체 행 데이터 대신 몇 행을 옮겼는지만 알려 주면 됩니다.

Anthropic은 2025년 11월에 발표한 Code execution with MCP에서 이런 방식으로 토큰 사용량을 줄인 사례를 소개했습니다. 에이전트가 도구를 직접 호출하는 대신 코드를 작성해서 실행 환경 안에서 도구를 호출하게 했더니, 같은 작업의 토큰 사용량이 15만에서 2천으로 약 98.7% 줄었습니다. 중간 결과를 모델에 전달하지 않고 샌드박스 안에서 처리했기 때문입니다. 같은 달에 공개한 programmatic tool calling에서도 복잡한 리서치 작업의 토큰 사용량이 평균 37% 줄었습니다.

Cloudflare는 Code Mode를 소개하면서 LLM이 도구를 직접 호출하는 것보다 도구를 호출하는 코드를 작성하는 데 더 능숙하다고 설명했습니다. 학습 데이터에 코드가 풍부한 반면 도구 호출에 관한 데이터는 드물다는 이유를 들었습니다.

샌드박스를 쓰면 사람이 명령을 하나하나 확인하고 승인하는 부담도 줄일 수 있습니다. 승인 요청을 모두 끄는 옵션은 대부분의 코딩 에이전트에 있으므로, 샌드박스가 없어도 매번 확인하지 않고 실행하게 할 수는 있습니다. 다만 에이전트가 잘못된 명령을 실행했을 때 어떤 파일이나 시스템이 영향을 받을지는 달라집니다. 샌드박스가 없으면 사용자가 접근할 수 있는 파일과 시스템을 에이전트도 건드릴 수 있습니다. 샌드박스를 쓰면 에이전트가 접근할 수 있는 범위를 따로 제한할 수 있어, 그 안의 작업은 매번 승인하지 않고 맡기기가 쉬워집니다.

Simon Willison은 에이전트 루프 설계에 관한 글에서, 승인 없이 실행하는 모드는 위험하지만 에이전트가 가장 많은 일을 해내는 방식이기도 하다고 썼습니다. 명령마다 확인을 요구하면 에이전트가 시행착오를 거치며 문제를 풀어 가는 능력이 크게 떨어지기 때문입니다. Anthropic이 Claude Code에 샌드박스를 넣은 이유도 같습니다. 사내에서 써 보니 권한 확인 요청이 84% 줄었다고 합니다. 작업 범위를 제한해 두면 사람이 덜 개입해도 되고, 에이전트는 그 안에서 여러 방법을 시도하며 작업을 이어 갈 수 있습니다.

실행 환경이 있으면 에이전트는 코드를 작성하는 데서 그치지 않고 패키지를 설치하고, 테스트를 돌리고, 결과 파일까지 만들 수 있습니다. Anthropic은 Building effective agents에서 에이전트가 각 단계의 도구 호출 결과나 코드 실행 결과를 확인해야 한다고 강조했습니다. 코딩 에이전트라면 테스트 결과를 보고 다음 작업을 결정할 수 있습니다. LangChain도 올해 6월에 쓴 에이전트에게 컴퓨터를 주라는 글에서, 에이전트가 작업을 계획하는 데 그치지 않고 실제로 수행하려면 컴퓨터가 필요하다고 설명했습니다.

벤더가 제공하는 샌드박스를 쓰더라도 어떤 파일과 자격 증명에 접근하게 할지, 외부 통신을 어디까지 허용할지는 직접 정해야 합니다.

격리 등급을 정해도 접근 권한과 외부 통신은 따로 관리해야 합니다

클라우드 샌드박스는 보통 필요한 프로그램을 미리 설치해 둔 이미지로 시작하고, 사용한 자원과 시간에 따라 요금을 냅니다. 작업이 끝나면 폐기할 수도 있고, 나중에 이어서 작업할 수 있도록 상태를 보관할 수도 있습니다. 샌드박스 안의 파일과 프로그램을 호스트에서 분리하면 에이전트가 작업하는 동안 사용자의 노트북이나 서버에 미치는 영향을 줄일 수 있습니다.

샌드박스를 실행하는 컴퓨터를 호스트라고 합니다. 샌드박스를 호스트나 같은 호스트의 다른 샌드박스와 얼마나 강하게 분리하는지에 따라 격리 등급이 달라집니다.

컨테이너는 호스트와 커널을 공유합니다. 따라서 커널이나 컨테이너 런타임의 취약점을 이용한 공격이 호스트에까지 영향을 줄 수 있습니다. 2025년 11월에 공개된 runc 취약점 세 건도 컨테이너 밖의 호스트를 공격할 수 있는 사례였습니다.

Google의 gVisor는 프로그램이 운영체제에 보내는 요청인 시스템 콜을 사용자 공간의 커널에서 처리합니다. 프로그램이 호스트 커널을 직접 호출하는 일을 줄여 격리를 강화하지만, 모든 시스템 콜을 지원하지는 않아 일부 프로그램은 제대로 동작하지 않을 수 있습니다.

Firecracker 같은 마이크로VM은 샌드박스마다 별도의 커널을 사용하고 하드웨어 가상화로 격리합니다. Firecracker는 부팅 시간 125밀리초 이내, 추가 메모리 사용량 5MiB 이하라는 목표를 두고 지속적 통합(CI) 테스트에서 확인합니다.

클라우드에서는 고객의 코드를 컨테이너에서 실행하는 경우가 많습니다. AWS와 Azure, Google은 에이전트용 샌드박스에 그보다 강한 격리 방식을 적용했습니다. AWS AgentCore는 세션마다 전용 마이크로VM을 사용하고, Azure는 Hyper-V로 격리합니다. Google은 Kubernetes SIG의 오픈소스 프로젝트인 Agent Sandbox를 GKE 애드온으로 제공하면서 gVisor를 사용합니다. LLM이 생성한 코드를 신뢰하지 않고 실행 환경에서 제한을 두는 방식입니다.

그런데 실행 환경을 격리하는 것만으로는 막을 수 없는 사고도 있습니다. 2025년 7월에는 Replit 에이전트가 코드를 바꾸지 말라는 지시를 무시하고 프로덕션 데이터베이스를 지웠습니다. 에이전트에게 말로 작업을 금지해도 실제 실행을 막지는 못한 사례입니다.

올해 4월에 일어난 PocketOS 사고에서는 자격 증명에 부여된 권한이 문제가 됐습니다. Cursor에서 동작하던 에이전트는 스테이징용 자격 증명으로 작업을 진행하지 못하자, 관련 없는 파일에서 더 넓은 권한을 가진 Railway 토큰을 찾아냈습니다. 그리고 그 토큰으로 프로덕션 데이터와 백업이 함께 저장된 볼륨을 9초 만에 지웠습니다. Railway CEO는 사용자든 사용자의 에이전트든 인증을 거쳐 삭제를 요청하면 그대로 실행한다고 답했습니다. 샌드박스 안의 코드도 자격 증명과 외부 서비스에 접근할 수 있으면 그 권한으로 요청을 보낼 수 있습니다. 실행 환경을 격리한다고 토큰의 권한까지 줄어들지는 않습니다.

외부 통신을 허용할 때는 데이터 유출도 따로 고려해야 합니다. 2025년 10월에 Johann Rehberger는 Claude Pirate라는 공격 시나리오를 공개했습니다. Claude 샌드박스가 기본으로 접속을 허용하는 api.anthropic.com을 통해 사용자 데이터를 공격자의 계정에 업로드하는 방식입니다. 샌드박스를 뚫지 않고도 허용된 도메인을 이용해 데이터를 유출할 수 있었습니다.

에이전트가 샌드박스 설정이나 실행에 필요한 파일을 바꿀 수 있는지도 확인해야 합니다. 올해 7월에 공개된 Cursor 취약점 두 건에서는 공격자가 외부 콘텐츠에 심은 지시를 에이전트가 따르도록 하는 프롬프트 인젝션이 사용됐습니다. 에이전트가 그 지시에 따라 작업 공간 밖의 샌드박스 도우미 프로그램을 덮어쓰면, 이후 명령을 샌드박스 없이 실행하게 만들 수 있었습니다.

여러 벤더도 API 키나 토큰 같은 비밀 정보의 보관 위치와 외부 통신 권한을 주의해서 정하라고 경고합니다. LangChain의 샌드박스 문서는 비밀 정보를 샌드박스 안에 넣지 말라고 안내합니다. Claude Code의 샌드박스 문서도 샌드박스가 모든 위험을 막아 주지는 않는다고 밝힙니다. 특히 github.com처럼 여러 사용자가 콘텐츠를 올리는 도메인을 통째로 허용하면 데이터 유출에 악용될 수 있다고 경고합니다.

자격 증명이 샌드박스 안에 노출되지 않도록 여러 제품은 샌드박스 밖의 프록시가 자격 증명을 보관하게 합니다. 프록시는 외부 요청을 중계하면서 허용된 목적지로 보내는 요청에만 자격 증명을 추가합니다. Claude Code의 mask 모드에서는 샌드박스 안의 명령이 실제 비밀 값 대신 대체 값을 사용하고, 프록시가 요청을 보낼 때 실제 값으로 바꿉니다. Vercel 샌드박스 방화벽과 Docker Sandboxes의 호스트 프록시도 이런 방식을 사용합니다.

작업이 끝난 뒤 파일이나 실행 상태를 어떻게 처리할지도 정해야 합니다. 모두 지우고 다음 작업을 새로 시작할 수도 있고, 상태를 보관해 두었다가 이어서 작업할 수도 있습니다. 보관 방식에 따라 저장 비용과 재시작에 걸리는 시간이 달라집니다. 샌드박스를 연결할 때는 다음 세 가지를 함께 정해야 합니다.

• 샌드박스에서 사용할 수 있는 자격 증명과 환경 변수를 정하고, 호스트의 어떤 디렉터리를 연결할지 선택해야 합니다.
• 외부 통신을 기본적으로 차단할지 허용할지 정해야 합니다. 도메인 이름만 검사할지, TLS로 암호화된 요청의 내용까지 검사할지도 결정해야 합니다.
• 작업이 끝난 뒤 파일과 실행 상태를 지울지 보관할지 정해야 합니다. 보관한다면 실행 상태를 저장한 스냅숏으로 복원할지, 샌드박스를 계속 켜 둘지에 따라 재시작 시간과 비용을 비교해야 합니다.

이런 정책을 직접 구현하고 운영하려면 샌드박스 인프라를 자체 구축하는 데 드는 작업도 살펴봐야 합니다.

VM을 띄운 뒤에도 이미지 배포와 네트워크를 운영해야 합니다

Firecracker는 오픈소스로 공개되어 있고 부팅도 빠릅니다. 이를 이용하면 샌드박스 인프라도 쉽게 구축할 수 있을 것 같습니다. 하지만 VM을 만들고 제어하는 API를 쓸 수 있다고 운영에 필요한 기능까지 모두 갖춰지는 것은 아닙니다. VM을 실행할 서버와 네트워크를 준비하고, 이미지 배포와 상태 복원도 직접 구현해야 합니다.

Firecracker는 Linux 커널의 가상화 기능인 KVM에 직접 접근해야 합니다. 따라서 물리 서버를 직접 사용하는 베어메탈 환경이나, VM 안에서 다시 VM을 실행할 수 있도록 중첩 가상화를 켠 환경이 필요합니다. AWS의 .metal 인스턴스가 베어메탈 환경에 해당합니다.

VM 안에서 실행하는 게스트 운영체제로는 Linux와 OSv만 지원합니다. GPU를 VM에 직접 연결하는 GPU 패스스루는 제공하지 않습니다. 메인테이너는 2025년 초에 GPU 지원을 개발할 여력이 없다고 밝혔고, 올해 9월에 나온 1.17.0에도 이 기능은 포함되지 않았습니다. 네트워크를 연결하려면 VM마다 가상 네트워크 인터페이스인 TAP 장치를 만들고 주소를 변환하는 NAT를 구성해야 합니다. 커널 이미지와 운영체제의 기본 파일을 담는 루트 파일시스템도 직접 빌드해야 합니다.

VM 한 대를 실행할 준비가 끝나도, 수천 대에 이미지를 배포하는 일은 별도로 해결해야 합니다. 여러 VM이 같은 이미지를 한꺼번에 내려받으면 이미지를 제공하는 저장소에 요청이 몰립니다. 그 결과 이미지 다운로드 때문에 VM 시작이 늦어질 수 있습니다.

Fly.io는 올해 1월에 공개한 Sprites 설계 글에서 컨테이너 이미지 저장소가 이런 요청을 처리하도록 만드는 데 많은 개발 작업이 필요했다고 설명했습니다. AWS Lambda 팀은 이미지를 필요한 블록부터 읽고 중복 데이터를 제거하며 여러 단계의 캐시를 사용하는 방법을 논문으로 발표했습니다. Modal은 gzip으로 압축된 이미지 레이어를 푸는 속도가 단일 스레드에서 80MiB/s를 넘지 못하자, 필요한 데이터를 나중에 읽는 FUSE 기반 파일시스템을 따로 만들었습니다. FUSE는 커널 밖의 사용자 공간에서 파일시스템을 구현할 수 있게 해 줍니다.

스냅숏을 복원할 때도 제약이 있습니다. Firecracker 문서는 복원할 환경의 하드웨어와 소프트웨어가 호환되어야 한다고 설명합니다. 같은 스냅숏으로 여러 VM을 만들면 고유해야 할 식별자나 암호 토큰까지 복제될 수 있습니다. 복원한 뒤에도 기존 네트워크 연결이 유지된다는 보장은 없습니다.

요청을 받은 뒤 실행 환경을 새로 준비하는 시간을 콜드 스타트라고 합니다. 이를 줄이려면 샌드박스를 미리 실행해 두었다가 요청이 오면 바로 할당할 수 있습니다. 이렇게 준비해 둔 샌드박스 묶음이 웜 풀입니다. Agent Sandbox도 웜 풀을 관리하는 기능을 제공합니다. 다만 미리 실행한 샌드박스는 요청을 기다리는 동안에도 자원을 사용하므로, 시작 시간을 줄이는 효과와 대기 비용을 함께 따져야 합니다.

E2B는 자사 인프라를 Apache 2.0 라이선스로 공개했지만, 직접 설치해서 쓰는 패키지는 평가 용도라고 밝혔습니다. 샌드박스 서비스가 제공하는 것은 마이크로VM만이 아닙니다. 이미지 배포와 네트워크, 스냅숏, 웜 풀, 모니터링을 관리하는 시스템도 제공합니다. 이런 관리 시스템을 컨트롤 플레인이라고 합니다. 서비스를 이용하면 이 운영 작업을 맡기는 대가로 요금을 내고, 직접 구축하면 서버 비용에 더해 팀이 개발하고 운영하는 시간도 필요합니다.

누가 운영할지 정하면 제품을 좁힐 수 있습니다

샌드박스 제품이 많아 이름만 나열해서는 무엇을 골라야 할지 판단하기 어렵습니다. 2026년 샌드박싱 가이드는 제품을 프리미티브와 런타임, 플랫폼이라는 세 계층으로 나누었습니다. 저는 누가 샌드박스를 운영하는지, 특정 클라우드나 에이전트 제품과 얼마나 결합되어 있는지를 기준으로 네 가지 유형으로 나누었습니다. 격리 기능을 구현하는 기본 도구인 프리미티브부터, 이미 쓰는 제품에 포함된 샌드박스까지 구분한 것입니다.

같은 유형의 제품이라도 격리 방식은 다릅니다. E2B와 Vercel, Fly Sprites는 Firecracker를 사용합니다. Docker Sandboxes는 macOS와 Windows에서 자체 가상 머신 관리 프로그램(VMM)으로 마이크로VM을 실행합니다. Modal과 GKE는 gVisor를, Azure는 Hyper-V를 사용합니다. Daytona는 기본적으로 컨테이너를 사용하므로 VM이 필요하면 따로 지정해야 합니다.

과금 기준도 다릅니다. E2B와 Daytona는 할당한 vCPU와 메모리를 기준으로 초당 요금을 계산합니다. Vercel과 AWS AgentCore의 서버리스 실행 환경은 CPU를 실제로 사용한 시간을 기준으로 CPU 요금을 계산합니다. 네트워크 응답 같은 입출력을 기다리며 CPU를 사용하지 않는 시간에는 CPU 요금이 붙지 않지만, 메모리 요금은 별도로 계산합니다.

작업이 끝난 뒤 상태를 보관하는 방식도 다릅니다. E2B는 일시 정지한 샌드박스를 기한 없이 보관하지만, Cloudflare는 샌드박스가 휴면 상태로 들어가면 파일을 지웁니다. 같은 유형의 제품이라도 요금과 상태 보존 조건은 별도로 비교해야 합니다.

기존에 쓰는 제품과 직접 운영할 수 있는 범위를 기준으로 후보를 좁히면 다음과 같습니다.

• 개인 작업에 기성 코딩 에이전트를 쓴다면 제품에 포함된 샌드박스부터 확인하면 됩니다. Claude Code의 /sandbox나 Codex CLI의 샌드박스가 여기에 해당합니다. 한 노트북에서 여러 에이전트를 함께 실행한다면 에이전트마다 마이크로VM을 제공하는 Docker Sandboxes도 검토할 수 있습니다.
• 소규모 팀이 자체 에이전트를 만든다면 샌드박스 전용 서비스나 기존 클라우드의 샌드박스를 검토할 수 있습니다. OpenAI Agents SDK나 LangChain deepagents를 쓴다면 E2B, Daytona, Modal, Vercel 가운데 사용하는 SDK에서 연동을 지원하는 서비스를 확인하면 됩니다. Vercel에 배포하는 팀은 Vercel Sandbox를 기존 계정으로 사용하고 요금도 함께 청구받을 수 있으며, 서울 리전도 선택할 수 있습니다.
• 기업 안의 한 부서라면 이미 계약한 클라우드의 샌드박스부터 살펴보는 편이 좋습니다. 기존 계정과 리전, 감사 로그, 비용 청구 체계를 활용하고 보안 검토도 기존 절차에 맞춰 진행할 수 있습니다. AWS를 쓴다면 AgentCore, Azure라면 dynamic sessions, GKE라면 Agent Sandbox 애드온을 검토하면 됩니다. 새 업체를 도입할 때는 연동 작업뿐 아니라 보안 심사에 걸리는 시간도 고려해야 합니다.
• 전사 플랫폼을 만든다면 격리 도구를 조합해 직접 구축하는 방법과 샌드박스 서비스의 직접 호스팅 옵션을 함께 검토할 수 있습니다. 데이터가 외부로 나가면 안 되는 조직은 자사 클라우드 계정에 설치하는 BYOC 방식의 E2B나 Northflank를 살펴볼 수 있습니다. 외부망과 분리된 에어갭 환경이라면 Agent Sandbox와 microsandbox가 검토 대상입니다. 직접 운영하는 범위가 넓어질수록 이미지 배포와 웜 풀, 스냅숏을 관리하는 비용도 조직이 부담해야 합니다.

사용자가 맡길 작업에 따라서도 필요한 실행 환경이 달라집니다. 저장소를 수정하고 테스트하는 에이전트에는 개발 도구를 갖춘 환경이 필요하고, Docker까지 실행해야 할 때도 있습니다. Claude Code on the web과 Codex cloud는 세션마다 VM이나 컨테이너를 새로 만들고 그 안에 저장소를 복제합니다.

파일을 읽어 계산하고 새 파일을 만드는 작업이라면, 코드를 실행해 결과를 확인할 수 있는 코드 인터프리터만으로 충분한 경우가 많습니다. ChatGPT의 데이터 분석과 Claude의 파일 생성, Microsoft 365 Copilot의 Analyst가 그런 예입니다. 이런 제품에서는 사용자가 샌드박스를 직접 관리하지 않아도 됩니다. 파일 분석이나 생성만 처리한다면 Anthropic의 code execution 도구나 Azure의 코드 인터프리터 세션처럼 코드 실행에 필요한 기능을 제공하는 환경부터 검토할 수 있습니다.

모델을 고른 뒤에는 실행 환경까지 설계해야 합니다

AWS와 Azure, Google은 코드 인터프리터를 클라우드 기능으로 제공합니다. Anthropic의 code execution 도구는 조직마다 매달 1,550시간까지 무료로 쓸 수 있습니다. 올해 4월 공개 베타로 나온 Claude Managed Agents는 모델이 판단하고 도구를 호출하는 과정을 반복하는 에이전트 루프와 샌드박스를 함께 운영하며, 세션 시간당 0.08달러를 받습니다. 이런 서비스를 이용하면 실행 환경을 별도로 구축하는 작업을 줄일 수 있습니다.

에이전트 플랫폼을 쓰면서 도구 실행 환경은 별도로 선택할 수도 있습니다. Anthropic은 올해 5월에 직접 호스팅하는 샌드박스 지원을 시작했습니다. 에이전트 루프는 Anthropic이 실행하고, 도구는 고객이 연결한 별도의 실행 환경에서 실행합니다. 지원 목록에는 Cloudflare, Daytona, Modal, Vercel, E2B, GKE Agent Sandbox가 들어 있습니다. Modal은 이 발표에 맞춰, 모델 루프와 코드 실행 환경을 분리하면 각각 어디까지 접근할 수 있는지 파악하기 쉬워진다고 썼습니다.

샌드박스 인프라를 제공하는 사업도 성장하고 있습니다. Modal은 같은 달 시리즈 C 투자를 발표하면서 샌드박스 매출이 전체 매출의 3분의 1을 넘는다고 밝혔습니다. Daytona는 올해 2월에 모든 에이전트에게 컴퓨터를 주겠다는 목표로 2,400만 달러를 투자받았습니다.

플랫폼에 샌드박스가 포함되어 있어도 자격 증명과 외부 통신을 누가 관리할지는 정해야 합니다. 에이전트를 클라우드에서 실행할지, 로컬이나 사내 인프라에서 실행할지에 따라 직접 관리할 범위가 달라집니다.

클라우드 에이전트를 쓰면 서비스 제공자가 실행 환경과 접근 제한을 관리합니다. Claude Code on the web은 Git 자격 증명을 샌드박스 밖의 프록시에 보관하고, Codex cloud는 에이전트가 작업하는 동안 기본적으로 인터넷 접근을 차단합니다.

로컬에서 실행하는 개발자 에이전트는 노트북 안에서 접근 범위를 제한합니다. Claude Code와 Codex CLI는 macOS의 Seatbelt나 Linux의 bubblewrap, seccomp 같은 운영체제 격리 기능을 사용합니다. Docker Sandboxes는 노트북 안에 마이크로VM을 실행해 에이전트마다 별도의 커널과 Docker 데몬을 제공합니다. 구체적인 구현은 달라도 접근할 파일과 외부 통신 대상, 자격 증명 사용 범위를 제한해야 한다는 점은 같습니다.

클라우드에서 제공하는 실행 환경을 선택할 때는 어떤 작업을 얼마나 오래 실행할 수 있는지 확인해야 합니다. 짧은 계산을 처리하는 코드 인터프리터와 저장소를 복제해 몇 시간 동안 작업하는 환경은 용도가 다릅니다. AWS AgentCore Runtime은 세션당 최대 8시간 유지되는 마이크로VM을 제공하고, Azure의 코드 인터프리터 세션은 한 번의 코드 실행 시간을 220초로 제한합니다. 세션을 유지하는 시간과 명령 하나를 실행할 수 있는 시간도 구분해서 봐야 합니다.

사내 인프라에서 모델을 직접 운영한다면 코드 실행 환경도 별도로 준비해야 합니다. 모델은 코드를 생성할 뿐, 그 코드를 실행할 환경까지 제공하지는 않습니다. 올해 8월에 1.0이 나온 Agent Sandbox를 비롯해 microsandbox나 Kata 같은 프로젝트를 검토할 수 있습니다. 이를 이용해 직접 구축한다면 이미지 배포와 웜 풀을 포함한 운영 작업도 조직이 맡아야 합니다.

에이전트를 설계할 때는 LLM을 고른 뒤 코드를 실행할 환경도 정해야 합니다. 어떤 파일과 자격 증명에 접근하게 할지, 외부 통신을 어디까지 허용할지, 작업이 끝난 뒤 어떤 상태를 보관할지 먼저 정해 두면 필요한 샌드박스와 직접 운영할 범위를 좁힐 수 있습니다. 이 범위가 분명해야 사람이 매번 승인하지 않고도 에이전트에게 작업을 맡길 수 있습니다.