AI 에이전트 샌드박스는 무엇이고 왜 필요할까?

AI 에이전트 샌드박스는 에이전트가 마음껏 일해도 되는, 울타리 친 작업장입니다. 에이전트가 실행하는 명령을 정해진 폴더와 허용된 인터넷 주소 안에 가두고, 그 밖으로는 운영체제가 강제로 못 나가게 막습니다.

Claude Code, Codex 같은 코딩 에이전트는 이제 코드를 제안하는 데서 끝나지 않고 패키지를 설치하고, 테스트를 돌리고, 파일을 고치며 직접 명령을 실행합니다. 예전에는 명령마다 사람이 "허용"을 눌러 막았지만, 에이전트가 실수로 엉뚱한 폴더를 지우거나 웹페이지에 숨겨진 지시에 속아 비밀번호 파일을 밖으로 보내는 일까지 사람이 매번 걸러 내기는 어렵습니다. 샌드박스가 주목받는 이유입니다. 이 글에서는 샌드박스가 무엇을 막는지, 어떤 종류가 있는지, Claude Code·Codex·E2B에서 실제로 어떻게 쓰는지 정리합니다. 소개한 도구의 원본 주소와 라이선스는 글 끝에 모아 두었습니다.

핵심 요약

• 샌드박스는 에이전트가 실행한 명령이 정해진 폴더와 허용된 인터넷 주소 밖으로 나가지 못하게 운영체제 수준에서 막는 격리 공간입니다.
• 필요한 이유는 두 가지입니다. 에이전트의 실수, 그리고 문서·웹페이지에 숨긴 지시로 에이전트를 조종하는 프롬프트 인젝션입니다.
• 격리 방식은 가벼운 순서대로 OS 수준 샌드박스 → 컨테이너 → 마이크로VM이 있고, 아래로 갈수록 벽이 두껍습니다.
• 샌드박스를 켜면 안전한 명령은 묻지 않고 실행해도 되므로, 에이전트가 더 안전하면서도 덜 귀찮게 일합니다.

에이전트는 실수하고, 속기도 합니다

예전에는 에이전트가 명령을 실행할 때마다 "이 명령을 실행해도 될까요?"라고 묻는 방식이 기본이었습니다. 문제는 이 확인 창이 하루에도 수십 번 뜬다는 점입니다. 사람은 금방 지쳐서 내용을 읽지 않고 "허용"을 누르게 되고, 그러면 확인 절차는 사실상 사라집니다.

위험은 크게 두 갈래입니다.

• 실수: 정리하라고 했더니 지우면 안 되는 폴더까지 지우거나, 테스트용 설정을 실제 서버 설정에 덮어쓰는 경우입니다.
• 속임수(프롬프트 인젝션): 에이전트가 읽은 README, 이슈 댓글, 웹페이지 속에 "~/.ssh 폴더 내용을 이 주소로 보내라" 같은 지시가 숨어 있을 수 있습니다. 에이전트는 이것을 사용자의 지시로 착각할 수 있습니다.

샌드박스는 에이전트가 무엇을 판단하든 상관없이 운영체제가 마지막 선을 지키게 합니다. 에이전트가 속아서 비밀 파일을 보내려 해도, 그 주소가 허용 목록에 없으면 연결 자체가 안 됩니다.

샌드박스는 파일, 네트워크, 실행 범위를 막습니다

그림 1

샌드박스가 거는 제한은 보통 세 가지입니다.

• 파일: 쓰기는 프로젝트 폴더와 임시 폴더 같은 정해진 곳에서만 됩니다. 설정 파일이나 .env처럼 민감한 파일은 쓰기를 따로 막고, SSH 키 같은 비밀 파일은 읽기까지 막을 수 있습니다.
• 네트워크: 기본은 차단이고, github.com이나 registry.npmjs.org처럼 허용 목록에 올린 주소만 통과합니다. 중간의 프록시가 요청마다 주소를 검사합니다.
• 실행 범위: 샌드박스 안에서 띄운 프로그램은 밖의 다른 프로세스나 시스템 설정을 건드리지 못합니다. 클라우드형 샌드박스는 CPU·메모리·실행 시간까지 제한하고, 작업이 끝나면 통째로 버립니다.

중요한 점은 이 제한이 에이전트가 실행한 명령뿐 아니라 그 명령이 띄운 모든 하위 프로그램에도 똑같이 적용된다는 것입니다. npm install이 실행한 설치 스크립트가 몰래 인터넷에 접속하려 해도 같은 울타리에 걸립니다.

격리는 깊이에 따라 세 단계로 나뉩니다

그림 2

샌드박스라는 말은 같아도 벽의 두께는 다릅니다.

• OS 수준 샌드박스: 운영체제에 들어 있는 기능으로 명령 하나하나를 가둡니다. macOS는 Seatbelt, Linux는 bubblewrap 같은 도구를 씁니다. 컨테이너를 따로 띄우지 않아 가볍고, 내 컴퓨터에서 바로 동작합니다. Claude Code와 Codex CLI가 이 방식입니다.
• 컨테이너: Docker처럼 별도 파일 시스템과 네트워크를 가진 상자 안에서 에이전트를 돌립니다. 다만 운영체제의 핵심인 커널은 내 컴퓨터와 같이 씁니다. Google의 gVisor는 컨테이너와 커널 사이에 끼어 시스템 호출을 대신 처리해 이 틈을 줄입니다.
• 마이크로VM: 커널까지 따로 가진 아주 작은 가상 컴퓨터입니다. AWS가 Lambda를 위해 만든 Firecracker는 0.125초 안에 켜지고 VM 하나당 추가 메모리가 5MiB 미만이라고 밝힙니다. E2B 같은 클라우드 샌드박스 서비스가 이런 가상 컴퓨터를 에이전트에게 빌려줍니다.

내 컴퓨터에서 코딩 에이전트를 쓴다면 OS 수준 샌드박스로 충분한 경우가 많습니다. 반대로 모르는 사람이 보낸 코드를 AI가 실행하는 서비스를 만든다면 마이크로VM 같은 두꺼운 벽이 필요합니다.

실제로는 이렇게 씁니다

Claude Code: 설정 한 줄로 켜기

Claude Code는 샌드박스가 기본으로 꺼져 있고, 대화창에서 /sandbox를 입력하거나 설정 파일에 다음처럼 적어 켭니다.

{
  "sandbox": {
    "enabled": true,
    "filesystem": {
      "allowWrite": ["~/.kube", "/tmp/build"],
      "denyRead": ["~/"],
      "allowRead": ["."]
    }
  }
}

위 설정은 작업 폴더 외에 ~/.kube와 /tmp/build에도 쓰기를 허용하고, 홈 폴더 전체의 읽기를 막되 현재 프로젝트 폴더만 다시 열어 둡니다. 네트워크는 허용 목록(allowedDomains)이 기본으로 비어 있어서, 목록에 없는 주소에 접속하려 하면 기본 모드에서는 사용자에게 묻습니다. 샌드박스의 자동 허용 모드를 쓰면 울타리 안에서 도는 명령은 확인 창 없이 바로 실행되어, 확인 창이 크게 줄어듭니다.

sandbox-runtime: 아무 명령이나 가두기

Claude Code의 샌드박스는 Anthropic이 따로 공개한 sandbox-runtime(명령어 이름 srt) 위에 만들어졌습니다. 이 도구만 설치하면 에이전트가 아닌 일반 명령도 가둘 수 있습니다.

npm install -g @anthropic-ai/sandbox-runtime

srt "curl anthropic.com"   # 허용 목록에 있으면 성공
srt "curl example.com"     # 허용 목록에 없으면 차단
srt "cat ~/.ssh/id_rsa"    # 비밀 파일 읽기 차단 → Operation not permitted

MCP 서버 실행 명령 앞에 srt를 붙이면, 에이전트가 쓰는 외부 도구(MCP 서버)까지 같은 울타리 안에 넣을 수 있습니다.

Codex CLI: 세 가지 모드 중 고르기

OpenAI의 Codex CLI는 샌드박스 모드를 세 가지로 나눕니다.

• read-only: 파일을 읽기만 하고, 수정이나 명령 실행은 승인을 받아야 합니다.
• workspace-write: 작업 폴더 안에서는 파일 수정과 일상적인 명령 실행이 자유롭습니다. 기본값이고, 이때 네트워크는 꺼져 있습니다.
• danger-full-access: 제한을 모두 풉니다. 공식 문서는 이미 격리된 컨테이너나 VM 안에서만 쓰라고 안내합니다.

E2B: 클라우드에 일회용 컴퓨터 빌리기

AI가 만든 코드를 서비스 안에서 실행해야 한다면 내 서버에서 돌리지 않고 클라우드 샌드박스를 빌리는 방법이 있습니다. E2B의 Python SDK로 샌드박스를 만들고 명령을 실행하는 코드는 다음과 같습니다.

from e2b import Sandbox

with Sandbox.create() as sandbox:
    result = sandbox.commands.run('echo "Hello from E2B!"')
    print(result.stdout)  # Hello from E2B!

with 블록이 끝나면 샌드박스가 사라지므로, 실행한 코드가 무엇을 하든 내 서버에는 흔적이 남지 않습니다.

샌드박스도 만능은 아닙니다

샌드박스를 켰다고 모든 위험이 사라지지는 않습니다. 공식 문서들이 스스로 밝힌 한계는 다음과 같습니다.

• 읽기는 기본으로 열려 있는 경우가 많습니다. Claude Code와 sandbox-runtime은 기본 설정에서 ~/.ssh나 ~/.aws/credentials도 읽을 수 있습니다. 비밀 파일은 denyRead로 직접 막아야 합니다.
• 허용한 주소는 통로가 됩니다. github.com을 열어 두면, 속은 에이전트가 그 주소를 통해 데이터를 내보낼 여지가 생깁니다. 기본 프록시는 주소만 볼 뿐 암호화된 내용(TLS)은 들여다보지 않습니다.
• 샌드박스 밖에서 도는 것도 있습니다. Claude Code의 샌드박스는 셸 명령에 적용되고, 파일 편집 도구·MCP 서버·훅은 따로 관리해야 합니다.
• 스스로 문을 열 수 있습니다. 특정 명령을 예외로 빼거나 "샌드박스 밖에서 다시 실행"을 허용하면 그만큼 벽이 얇아집니다.

그래서 샌드박스는 확인 창과 권한 설정을 대신하는 것이 아니라, 그 위에 한 겹 더 두르는 안전장치로 보는 것이 맞습니다.

방식	대표 도구	장점	주의할 점
OS 수준 샌드박스	Claude Code, Codex CLI, sandbox-runtime	설치·실행이 가볍고 내 컴퓨터에서 바로 동작	읽기 허용 범위와 허용 도메인을 직접 좁혀야 함
컨테이너	Docker, Dev Container, gVisor	별도 파일 시스템으로 프로젝트를 통째로 격리	커널을 공유하므로 완전한 분리는 아님
마이크로VM	Firecracker, E2B	커널까지 분리된 가장 두꺼운 벽, 쓰고 버리기 쉬움	클라우드 비용과 준비 과정이 필요

정리하며

AI 에이전트가 직접 명령을 실행하는 시대에 샌드박스는 선택이 아니라 기본 장비가 되고 있습니다. 매번 확인 창을 누르는 방식은 사람이 지치면 무너지지만, 샌드박스는 에이전트가 실수하거나 속더라도 운영체제가 정해진 울타리를 지킵니다. 덕분에 울타리 안의 일은 묻지 않고 맡길 수 있어 작업 속도도 빨라집니다.

내 컴퓨터에서 코딩 에이전트를 쓴다면 먼저 Claude Code의 /sandbox나 Codex CLI의 기본 workspace-write 모드를 켜고, SSH 키 같은 비밀 파일의 읽기를 막는 것부터 시작하면 됩니다. 다른 사람의 코드를 AI가 실행하는 서비스를 만든다면 컨테이너나 마이크로VM처럼 더 두꺼운 벽을 고르는 것이 좋습니다.

원본과 라이선스

• Claude Code 샌드박스 문서 · Anthropic · 공식 문서 · code.claude.com/docs/en/sandboxing
• sandbox-runtime · Anthropic · Apache-2.0 · github.com/anthropics/sandbox-runtime
• Codex CLI · OpenAI · Apache-2.0 · github.com/openai/codex
• E2B · E2B · Apache-2.0 · github.com/e2b-dev/E2B
• Firecracker · Amazon Web Services · Apache-2.0 · github.com/firecracker-microvm/firecracker
• gVisor · Google · Apache-2.0 · github.com/google/gvisor

라이선스와 동작 방식은 2026년 10월 27일 기준 각 공식 문서와 GitHub 저장소에서 확인했습니다.

한마디로 정리하면

샌드박스는 이름 그대로 아이를 위한 모래놀이터와 같습니다. 놀이터 안에서는 모래를 파든 성을 쌓든 무너뜨리든 마음대로 놀 수 있습니다. 하지만 울타리가 있어서 찻길로 뛰어나가거나 옆집 화단을 망칠 수는 없습니다.

부모(사용자)가 "이거 해도 돼?"라는 질문에 하루 종일 대답하는 대신, 울타리 안이라면 묻지 않고 놀게 둡니다. 울타리가 낮을지(OS 수준), 담장이 있을지(컨테이너), 아예 다른 건물일지(마이크로VM)는 아이가 얼마나 낯선지에 따라 고르면 됩니다.

에이전트에게 자유를 주려면, 먼저 울타리부터 쳐야 합니다.