Sandboxes for Agents

Claude Code에서 /sandbox를 켜면 에이전트가 실행하는 셸 명령은 macOS의 프로세스 샌드박스인 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은 샌드박스마다 커널을 따로 할당합니다. 부팅 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 취약점 두 건에서는 프롬프트 인젝션으로 들어온 지시가 작업 공간 밖에 파일을 써서 샌드박스 도우미 프로그램을 덮어쓰고, 결국 샌드박스를 꺼 버릴 수 있었습니다.

그래서 시크릿을 어디에 둘지에 대해서는 여러 벤더의 문서가 같은 경고를 적어 두었습니다. LangChain의 샌드박스 문서는 시크릿을 절대 샌드박스 안에 넣지 말라고 적었습니다. Claude Code의 샌드박스 문서는 샌드박스가 위험을 줄여 주지만 완전한 격리 경계는 아니라고 밝히고, github.com처럼 범위가 넓은 도메인을 허용하면 데이터가 빠져나갈 길이 생긴다고 경고합니다. 벤더들이 내놓은 해법도 한 가지입니다. 자격 증명은 샌드박스 밖의 프록시가 들고 있다가, 허용된 목적지로 나가는 요청에만 끼워 넣습니다. Claude Code의 mask 모드는 명령에는 자리표시 값만 보여 주고 프록시가 진짜 값을 채워 넣습니다. Vercel 샌드박스 방화벽과 Docker Sandboxes의 호스트 프록시도 같은 방식으로 동작합니다.

다 쓴 샌드박스가 언제나 사라지는 것은 아닙니다. 상태를 지울지 남길지는 직접 골라야 하고, 그 선택에 따라 비용이 달라집니다. 결국 샌드박스를 붙일 때 답해야 할 질문은 세 가지입니다.

• 자격 증명, 환경 변수, 마운트할 디렉터리 가운데 무엇을 샌드박스 안에 들고 들어갈지
• 밖으로 나가는 트래픽을 기본적으로 차단할지 허용할지, 그리고 도메인 이름만 볼지 TLS 안까지 들여다볼지
• 작업이 끝난 뒤 상태를 어디에 남길지, 그에 따라 유휴 시간 과금과 스냅숏, 재시작을 어떻게 처리할지

그 컴퓨터를 통째로 직접 만들려는 팀도 있습니다.

직접 만들 때 어려운 부분은 VM이 아니라 그 주변입니다

Firecracker는 오픈소스로 공개되어 있고 부팅도 125밀리초 안에 끝납니다. 그래서 샌드박스 인프라를 직접 구축해도 될 것처럼 보입니다. 그런데 Firecracker가 맡아 주는 범위는 VM을 만들고 없애는 API까지입니다. 그보다 아래에 있는 계층과 위에 있는 계층은 모두 직접 준비해야 합니다.

Firecracker는 Linux 커널의 가상화 장치인 KVM에 직접 접근해야 하므로 베어메탈 서버나 중첩 가상화를 켠 VM에서 실행해야 합니다. AWS에서는 .metal 인스턴스를 골라야 합니다. 게스트 운영체제로는 Linux와 OSv만 지원하고 GPU 패스스루는 제공하지 않습니다. 메인테이너는 2025년 초에 GPU 작업에 쓸 여력이 없다고 밝혔고, 올해 9월에 나온 1.17.0에도 GPU 패스스루는 들어가지 않았습니다. 네트워크는 VM마다 가상 네트워크 인터페이스인 TAP 장치를 만들고 NAT를 직접 구성해야 하며, 커널 이미지와 루트 파일시스템도 직접 빌드해야 합니다.

그 위에 있는 계층에서 해야 할 일은 더 많습니다. 에이전트 수천 개가 동시에 실행되면 VM마다 이미지를 어떻게 전달할지부터 문제가 됩니다. VM은 저장소에 올려 둔 이미지를 내려받아 부팅하기 때문에, 수천 대가 같은 이미지를 한꺼번에 요청하는 순간 이미지를 내려 주는 쪽이 병목이 됩니다. 올해 1월에 공개된 Fly.io의 Sprites 설계 글에 따르면 컨테이너 이미지 레지스트리가 그 속도를 감당하게 만드는 작업에만도 공수가 엄청나게 들어갔습니다. AWS Lambda는 블록 단위 지연 로딩과 중복 제거, 계층형 캐시를 어떻게 구현했는지 논문 한 편으로 설명해야 했습니다. Modal은 gzip으로 압축된 레이어를 푸는 속도가 단일 스레드에서 80MiB/s를 넘지 못하자 FUSE 기반 지연 파일시스템을 따로 만들었습니다.

스냅숏에도 제약이 많습니다. Firecracker 문서를 보면 스냅숏은 하드웨어와 소프트웨어 구성이 같은 환경에서만 복원되고, 복제된 VM이 같은 엔트로피를 물려받기 때문에 암호 토큰이 중복될 수 있으며, 네트워크 연결은 보존되지 않습니다.

콜드 스타트를 줄이려고 VM을 미리 실행해 두면 이번에는 유휴 상태에서 발생하는 비용이 문제가 됩니다. 그래서 Agent Sandbox 프로젝트는 미리 실행해 둔 VM 묶음, 즉 웜 풀을 핵심 기능으로 내세웁니다.

E2B는 자사 인프라를 Apache 2.0으로 공개했지만 직접 설치해서 쓰는 패키지는 평가 용도라고 분명히 밝혔습니다. 마이크로VM을 판매하는 회사도 실제로 파는 것은 이미지 배포와 네트워크, 스냅숏, 웜 풀, 모니터링까지 묶어 놓은 컨트롤 플레인입니다. SaaS를 쓰면 이 고민이 초당 요금으로 바뀌고, 직접 만들면 요금이 팀의 시간으로 바뀝니다.

네 계층으로 나누면 고를 수 있습니다

샌드박스 제품은 이름만 나열해도 서른 개가 넘어가기 때문에, 그 목록을 훑는 것만으로는 무엇을 골라야 할지 판단하기 어렵습니다. 2026년 샌드박싱 가이드는 이 제품들을 프리미티브와 런타임, 플랫폼이라는 세 계층으로 나누었습니다. 저는 그 샌드박스를 누가 운영하는지, 그리고 무엇에 종속되는지를 기준으로 삼아 네 계층으로 다시 나눕니다.

같은 계층에 속한 제품들 사이에서도 격리 등급은 서로 다릅니다. 가장 많이 쓰이는 것은 Firecracker이고, E2B와 Vercel, Fly Sprites가 여기에 해당합니다. Docker Sandboxes는 macOS와 Windows에서도 동작해야 하므로 자체 VMM으로 마이크로VM을 띄우고, Modal과 GKE는 gVisor를, Azure는 Hyper-V를 씁니다. Daytona는 기본 격리 수단이 컨테이너이기 때문에, VM을 쓰려면 따로 지정해야 합니다.

과금 방식은 이보다 더 제각각입니다. E2B와 Daytona는 할당한 vCPU와 메모리를 초 단위로 계산해서 요금을 매기고, Vercel과 AWS AgentCore는 CPU를 실제로 사용한 시간만 계산하기 때문에 I/O를 기다리는 시간에는 요금을 물리지 않습니다. 작업이 끝난 뒤 상태를 어떻게 처리하는지도 갈립니다. E2B는 일시 정지한 샌드박스를 기한 없이 보관하지만, Cloudflare는 샌드박스가 휴면 상태로 들어가면 파일을 지웁니다. 무엇을 남기는지 하나만 비교해도 이만큼 차이가 나기 때문에, 위 표에 적은 예시는 어디에서부터 살펴볼지 정하는 출발점일 뿐입니다.

어디에서부터 살펴볼지는 누가 어떤 조직에서 에이전트를 만드는지에 따라 달라집니다.

• 혼자 만들어서 혼자 쓴다면 에이전트에 붙어 나오는 샌드박스로 충분합니다. Claude Code의 /sandbox나 Codex CLI의 샌드박스는 명령 한 줄로 켤 수 있고, 한 노트북에서 여러 에이전트를 함께 실행한다면 Docker Sandboxes가 에이전트마다 마이크로VM을 하나씩 띄워 줍니다. 비용은 따로 들지 않거나 이미 내고 있는 구독료에 포함되어 있습니다.
• 소규모 팀이 자체 에이전트를 만든다면 샌드박스 전용 서비스나 이미 쓰고 있는 인프라의 샌드박스가 적합합니다. OpenAI Agents SDK와 LangChain deepagents가 기본으로 붙여 주는 백엔드 목록에 E2B와 Daytona, Modal, Vercel이 들어 있습니다. 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가 그런 예이고, 사용자는 샌드박스가 동작하고 있다는 사실조차 알지 못합니다. 이런 에이전트를 만든다면 VM 한 대를 통째로 내어 주는 샌드박스는 과한 선택입니다. 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은 이 발표에 맞춰, 모델 루프를 실행 환경 밖에 두면 보안 경계를 따지기가 쉬워진다고 썼습니다. 그리고 같은 달 시리즈 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을 쓸지는 대개 가장 먼저 정합니다. 그런데 그 결정만으로 설계가 끝나지는 않습니다. 그 에이전트에게 어떤 컴퓨터를 줄지, 그 컴퓨터에 무엇을 들고 들어갈지, 무엇을 밖으로 나가게 할지, 일이 끝난 뒤 무엇을 남길지를 이어서 정해야 합니다. 이 질문들에 답하지 않은 설계는 에이전트에게 아직 자유로운 도구를 주지 않은 것과 같습니다.