인공지능을 위한 샌드박스 완전 정복 가이드 (2026 버전)

“Claude 코드에게 프로젝트 정리 좀 시켰다가, 레포 전체가 날아갔다.”

요즘 커뮤니티에서 심심찮게 등장하는 이야기입니다. 개발자를 돕겠다며 등장한 AI 에이전트가, 한 줄 잘못 이해한 명령 때문에 .ssh 폴더를 지우거나, 수십 시간 걸려 만든 설정을 덮어써 버리는 사고가 실제로 일어나고 있습니다¹².

이제 AI는 코드만 “추천”하는 존재가 아니라, 직접 코드를 “실행”하는 동료가 됐습니다. 문제는, 이 동료가 버그도 잘 만들고, 공격자에게 속기도 잘 속인다는 점이죠. 그래서 2026년을 준비하는 개발자라면 반드시 알아야 할 개념이 하나 생겼습니다. 바로 AI를 위한 샌드박스입니다.

이 글에서는 다음을 다룹니다.

샌드박스가 왜 지금 이렇게 중요한지
컨테이너, 마이크로VM, gVisor, WebAssembly 등 주요 샌드박스 종류와 차이
Docker Sandboxes 같은 실제 도구로 AI 코드를 안전하게 돌리는 방법²
어떤 상황에서 어떤 샌드박스를 선택해야 하는지 실전 가이드

복잡한 가상화 이론 대신, “내 노트북 안 털리고, 서버 안 뚫리려면 뭘 써야 하는지” 관점에서 정리해 보겠습니다.

AI 샌드박스란 무엇이고, 왜 지금 중요한가

먼저 정의부터 정리해 보겠습니다.

AI 샌드박스는 한마디로,
“AI가 실행하는 코드와 명령을, 내 실제 시스템과 분리해서 돌리는 안전한 상자”입니다.

사람 개발자는 보통 이런 실수를 저지르기 전에 눈치라도 챕니다.

“어 잠깐, 이 rm -rf 경로 이상한데?”
“이거 프로덕션 DB 아니야?”

하지만 에이전트는 다릅니다.

프롬프트 인젝션에 속으면 공격자가 적어준 명령을 그대로 실행합니다³.
존재하지도 않는 패키지 이름을 지어내고, 그 이름으로 악성 패키지를 설치하게 될 수 있습니다³.
스스로 작성한 코드를 자신이 다시 실행하면서 RCE(Remote Code Execution) 취약점을 만들어낼 수도 있습니다³.

게다가 최근 연구에 따르면, LLM이 만들어낸 패키지 이름 중 거의 20%가 실제로 존재하지 않는 “환각 패키지”였고³, 이런 이름을 공격자가 선점해 배포하는 사례도 늘고 있습니다.

여기에 더해:

프로젝트에 숨겨둔 악성 주석 한 줄,
화이트 텍스트로 숨긴 HTML,
PDF의 숨겨진 텍스트 레이어,

이런 것들로도 에이전트를 속여서 파일을 읽고, 코드 실행하고, 네트워크로 기밀을 빼가게 만들 수 있습니다³.

요약하면:

AI 에이전트 = “착하지만, 너무 잘 속는, 루트 권한 가진 인턴”
샌드박스 = “이 인턴에게 줄 따로 격리된 작업용 PC”

AI 코드를 샌드박스 안에서 실행한다는 건,
“혹시 사고가 나도, 피해 범위를 미리 정해 둔다”는 뜻입니다.

이제 중요한 질문은 이것입니다.

“도커만 쓰면 되는 거 아냐?”

여기서부터가 오늘의 핵심입니다.

샌드박스의 4가지 계층: 컨테이너부터 WebAssembly까지

루이스 카르도소가 정리한 샌드박스 지형도를 기준으로, AI 코드 실행에 자주 쓰이는 네 가지 계층을 이해해 보겠습니다⁴.

1. 컨테이너: 빠르고 편하지만, 커널은 함께 쓴다

우리가 가장 익숙한 샌드박스는 Docker 같은 컨테이너입니다.

컨테이너는 프로세스를 격리하고 파일 시스템을 분리해서, “각자 자기만의 작은 시스템”처럼 보이게 만듭니다. 하지만 중요한 사실이 하나 있습니다.

컨테이너 = 호스트 커널을 공유합니다.
즉, 컨테이너 안의 프로세스와 호스트의 프로세스가 같은 커널을 호출합니다⁴⁵.

보안 관점에서 보면, 컨테이너 탈출 취약점은 곧 호스트 커널 취약점입니다⁵.
커널에 LPE(Local Privilege Escalation) 버그가 하나 있다면, 컨테이너 안 공격자가 그걸 악용해 호스트로 튀어나올 수 있습니다⁵.

게다가:

커널 설정이 허술하거나,
seccomp/AppArmor/SELinux가 제대로 적용되지 않았거나,
--privileged 같은 플래그를 대충 쓴다면,

컨테이너는 사실상 “약간 불편한 chroot” 수준으로 떨어집니다⁵.

그럼에도 불구하고 컨테이너는 여전히 유용합니다.

개발 환경 구성,
신뢰할 수 있는 코드를 분리해서 돌리는 용도,
프로젝트별 의존성 충돌 방지,

이런 용도라면 컨테이너만으로도 충분합니다.

실제 예로, Docker Desktop 4.50+의 Docker Sandboxes 기능은 AI 코딩 에이전트를 컨테이너 안에서 돌리되, 프로젝트 디렉터리는 그대로 마운트해 개발 경험을 유지합니다². 호스트의 Git 설정과 API 키도 안전한 볼륨에 저장하죠².

여기서 핵심은 “편리한 개발 경험 + 기본적인 격리”입니다. 하지만 완전히 신뢰할 수 없는 코드를 돌리기엔, 방어막이 조금 얇습니다.

2. 마이크로VM: 하드웨어 가상화로 커널까지 분리

컨테이너보다 한 단계 위의 보안을 제공하는 게 마이크로VM(MicroVM)입니다.

여기서 중요한 차이는:

컨테이너: 호스트 커널 공유
마이크로VM: 게스트 커널을 따로 부팅해서, 하드웨어 가상화로 격리⁴

대표적인 예가 AWS Lambda와 Fargate에서 쓰는 Firecracker입니다³.

Rust로 구현된 경량 VMM
부팅 시간: 100ms대
메모리 오버헤드: 수 MiB 수준³
QEMU 같은 전통적인 VMM보다 코드량이 훨씬 적어 공격면이 줄어듦³

또 다른 예로 Kata Containers는 기존의 OCI 컨테이너 인터페이스는 그대로 유지하면서, 내부적으로는 각 컨테이너를 VM으로 감싸서 실행합니다⁵.
결과적으로 “도커처럼 쓰지만, 실제로는 VM 수준 격리”를 얻을 수 있습니다.

장점은 명확합니다.

커널까지 완전히 따로 쓰기 때문에,
컨테이너 탈출류 공격에 더 강합니다.
멀티 테넌트 환경에서 한 테넌트가 다른 테넌트를 건드리기 훨씬 어려워집니다.

대신 단점도 있죠.

쿠버네티스/도커에 비해 초기 설정이 복잡하고³,
VM 이미지 관리, 네트워크 구성, 모니터링 등 운영 부담이 늘어납니다.

그래서 마이크로VM은 다음 상황에 특히 잘 맞습니다.

외부 사용자의 코드, 플러그인, 스크립트를 실행해야 하는 SaaS 서비스
여러 고객의 에이전트가 한 클러스터를 공유하는 B2B 플랫폼
서버리스 스타일로 짧게 짧게 실행되는 AI 작업

“완전한 타인”의 코드를 돌린다면 컨테이너 단독은 불안하고, 마이크로VM이 사실상 기본값에 가까워지고 있습니다.

3. gVisor: 유저스페이스 커널로 시스템콜을 가로막기

세 번째 계층은 gVisor처럼 “유저스페이스 커널”을 구현한 방식입니다³⁴.

작동 방식은 이렇습니다.

애플리케이션은 여전히 리눅스 커널에 시스템 콜을 날린다고 생각합니다.
하지만 실제로는, gVisor가 중간에서 시스템 콜을 가로채고,
자체 구현된 유저스페이스 커널(Sentry)이 대신 처리합니다³.

이 구조의 장점은:

컨테이너가 호스트 커널에 직접 접근하지 못하고,
gVisor가 허용한 범위 내에서만 동작할 수 있다는 것³.

즉, 커널 공격면을 줄이면서도, 기존 컨테이너 워크플로와 꽤 잘 어우러집니다.

보안 강도는 대략 이렇게 이해하면 편합니다.

기본 컨테이너 < gVisor < 마이크로VM

마이크로VM만큼 하드웨어 차원에서 완전히 갈라놓지는 않지만,
컨테이너가 호스트 커널로 날리는 시스템콜들을 “필터링 / 에뮬레이션”해 주기 때문에 상당한 방어막을 더 씌우는 효과가 있습니다³.

AI 관점에서 gVisor는 이런 상황에서 쓸 만합니다.

사내에서만 사용하는 에이전트인데, 그래도 방어를 한 겹 더 올리고 싶을 때
클라우드 비용, 메모리, 부팅 시간을 생각할 때 마이크로VM은 과한데,
“컨테이너만으론 불안하다”고 느껴질 때

4. WebAssembly / Isolates: 런타임 안에 가둬 놓기

마지막 계층은 WebAssembly(Wasm)와 다양한 “isolate” 런타임입니다⁴⁶.

여기서는 OS 수준의 격리 대신, 런타임 자체가 샌드박스입니다.

Wasm 모듈은 가상의 스택 머신 위에서 돌아가는 바이트코드입니다⁶.
기본적으로 파일 시스템, 네트워크, 환경변수에 직접 접근할 수 없습니다.
호스트 애플리케이션이 “export된 함수”로만 통신을 허용합니다⁶.

예를 들어, 어떤 서비스가 “untrusted Python”을 Wasm 안에서 실행한다고 해 보죠⁵.

입력과 출력은 JSON 포맷으로만 주고받습니다⁵.
파라미터로 객체나 콜백을 넘길 수 없고, 순수한 데이터만 주고받습니다.
Wasm 안의 코드가 파일을 읽거나 네트워크를 호출하려면,
반드시 호스트가 제공한 API를 통해서만 가능합니다.

이 구조의 장점은:

런타임가 허용하지 않는 건 아예 할 수가 없다는 것입니다.
OS 커널을 뚫을 기회조차 주지 않으니, 공격면이 극적으로 줄어듭니다⁶.
웹 브라우저, 서버, 에지 노드 등 어디에나 embed하기 쉽습니다⁶.

WASI(WebAssembly System Interface) 1.0 이후로는,
파일 IO, 네트워크, 시계 등 기본적인 시스템 인터페이스 표준도 갖춰져서⁷,
2026년쯤엔 “뒤에서 Wasm 돌리고 있는 서비스”를 모른 채 쓰는 일이 훨씬 많아질 전망입니다⁷.

단점도 있습니다.

모든 언어나 라이브러리가 Wasm에 잘 포팅되어 있지는 않습니다.
OS 레벨 기능을 많이 쓰는 복잡한 앱은 Wasm로 옮기기 까다로울 수 있습니다.
CPU 집약적 작업은 거의 네이티브 수준 속도가 나오지만,
시스템콜이 많거나 대용량 IO가 필요한 작업은 오버헤드가 생길 수 있습니다⁶.

그럼에도 불구하고, “플러그인 플랫폼”이나 “사용자 스크립트 실행”에선 사실상 차세대 샌드박스 표준 후보로 보는 시각이 많습니다⁷⁶.

Docker Sandboxes로 AI 에이전트를 안전하게 돌리는 방법

이제 이론에서 한 발 내려와, 실제로 바로 써 볼 수 있는 도구를 예로 들어 보겠습니다. Docker Desktop 4.50 이후에 들어간 Docker Sandboxes 기능입니다².

이 기능의 목표는 명확합니다.

“Claude Code 같은 AI 코딩 에이전트를, 내 노트북을 직접 건드리지 않고도 전력으로 쓰고 싶다.”²

동작 방식 한 번에 이해하기

터미널에서 프로젝트 폴더로 들어가서, 이렇게만 입력합니다.

cd ~/my-project
docker sandbox run claude

이 한 줄에 다음 작업들이 자동으로 이루어집니다².

docker/sandbox-templates:claude-code 이미지로 새로운 컨테이너 생성
현재 작업 디렉터리를 똑같은 절대 경로로 컨테이너 안에 마운트
호스트의 Git user.name, user.email 설정을 컨테이너 안에 주입
Claude API 키를 별도 Docker volume에 안전하게 저장²

그래서 호스트와 컨테이너 안에서 경로가 이렇게 일치합니다².

# 호스트
/Users/alice/projects/myapp

# 샌드박스 컨테이너 내부
/Users/alice/projects/myapp  # 동일

덕분에:

에러 메시지에 나오는 파일 경로가 호스트와 완전히 동일하고,
에이전트가 수정한 파일은 곧바로 에디터에서 확인 가능하며,
하지만 에이전트가 접근할 수 있는 파일/네트워크 범위는 컨테이너 기준으로 제한됩니다.

또 하나 중요한 특징이 있습니다.

디렉터리별 1개 샌드박스가 유지됩니다².
같은 폴더에서 docker sandbox run을 다시 실행하면 기존 컨테이너를 재사용합니다².
따라서 한 번 설치한 패키지, 설정, 캐시는 다음 세션에서도 그대로 남습니다.

개발 경험은 거의 “로컬에서 바로 돌리는 것”과 비슷하게 유지되면서,
“최소한의 안전벨트”를 제공하는 셈입니다.

AI 환경 커스터마이징: 변수, 볼륨, 템플릿

조금 더 쓰다 보면, 샌드박스 안의 환경을 꽤 세밀하게 제어할 수 있다는 걸 알게 됩니다.

예를 들어 개발용 환경 변수를 주고 싶다면:

docker sandbox run 
  -e NODE_ENV=development 
  -e DATABASE_URL=postgresql://localhost/myapp_dev 
  -e DEBUG=true 
  claude

테스트용 API 키만 넣어서 실험해 보고 싶다면:

docker sandbox run 
  -e STRIPE_TEST_KEY=sk_test_xxx 
  claude

여기서 중요한 원칙은 하나입니다.

샌드박스엔 절대 생산용(프로덕션) 시크릿을 넣지 않는다².

또한, 데이터 과학/ML 워크플로를 떠올려보면:

docker sandbox run 
  -v ~/datasets:/data:ro 
  -v ~/models:/models 
  -v ~/.cache/pip:/root/.cache/pip 
  claude

이렇게 하면:

/data는 읽기 전용으로만 제공되어, 실수로 데이터셋을 덮어쓸 수 없고²
학습된 모델은 /models에 저장되어 호스트와 공유되며
pip 캐시는 공유돼, 패키지 설치 속도도 빨라집니다.

앞으로 자주 쓸 환경이 있다면, 아예 커스텀 템플릿 이미지를 만들어 둘 수도 있습니다.

# syntax=docker/dockerfile:1
FROM docker/sandbox-templates:claude-code

# 예: ruff 설치
RUN curl -LsSf https://astral.sh/uv/install.sh | sh && 
    . ~/.local/bin/env && 
    uv tool install ruff@latest

빌드 후:

docker build -t my-python-env .
docker sandbox run --template my-python-env claude

이렇게 해서 “나만의 AI 개발 컨테이너”를 만드는 것도 가능합니다².

가장 위험한 옵션: Docker 소켓 마운트

샌드박스 문서를 보면 눈에 띄는 옵션이 하나 있습니다.

docker sandbox run --mount-docker-socket claude

이 옵션은 간단히 말해:

“AI 에이전트에게 Docker 데몬에 대한 루트 권한을 준다”는 뜻입니다².

이걸 허용하면 에이전트는:

모든 컨테이너를 시작/중지할 수 있고
모든 볼륨의 내용을 읽고 쓸 수 있으며
사실상 호스트 전체를 마음대로 조작할 수 있습니다².

따라서 이 기능은,

에이전트에게 Docker Compose로 멀티 컨테이너 앱을 띄우게 하거나,
Dockerfile로 이미지를 빌드하게 해야 하는 등 특별한 이유가 있을 때만,
그리고 에이전트가 만지는 코드/입력을 100% 신뢰할 수 있을 때만 써야 합니다.

“신뢰할 수 없는 코드” + --mount-docker-socket은
샌드박스가 아니라 집 안에 창문을 떼어낸 수준이라는 걸 기억해 두시면 좋습니다.

상황별로 선택하는 AI 샌드박스 전략

이제 이론과 도구를 훑었으니, 현실적인 질문으로 돌아가 보겠습니다.

“나는 어떤 샌드박스를 써야 하지?”

완벽한 정답은 없지만, 현실적인 기준은 세 가지입니다.

코드/입력을 얼마나 신뢰하나?
망가지면 안 되는 자산은 어디에 있나?
비용과 복잡도를 어디까지 감당할 수 있나?

이 기준으로 상황별 전략을 정리해 보겠습니다.

1) “개인 개발자가 내 맥북에서 AI 도우미 쓰는 수준”

예:

프라이빗 레포를 Claude Code에 열어주고,
로컬에서 코드 리팩토링/테스트를 맡기고 싶다.

2) “사내 팀에서 공용 개발 서버에 에이전트를 붙이는 경우”

예:

팀 공용 GPU 서버에서 에이전트가 테스트/빌드/배포 업무를 돕는다.
여러 개발자가 같은 서버에서 자원 공유.

3) “SaaS 서비스가 고객 코드를 실행해야 할 때”

예:

사용자가 웹 에디터에서 Python/JS 코드를 작성 → 서버에서 실행 → 결과 반환
사용자가 업로드한 문서, 데이터베이스에 에이전트가 접근

여기서는 사실상 답이 정해져 있습니다.

마이크로VM (Firecracker, Kata Containers 등)를 기본으로 깔고³⁵
그 안에서 컨테이너를 돌리거나,
아예 WebAssembly 기반 런타임을 사용해 플러그인/스크립트를 돌리는 구성⁷⁶

여기에 더해:

고객별로 네트워크/스토리지 격리
데이터베이스 접근은 API나 명시적 쿼리만 허용
코드 실행 시간/메모리 제한, 실행 횟수 제한

까지 갖춰야 “감히 멀티테넌트”라고 부를 수 있습니다.

4) “플러그인/스크립트 생태계를 만들고 싶을 때”

예:

AI 에이전트용 툴 플러그인을 서드파티가 만들 수 있게 하고 싶다.
사용자가 직접 쓴 코드 조각을 붙여서 기능을 확장하고 싶다.

이때는 WebAssembly + WASI가 유력한 선택입니다⁷⁶.

플러그인 코드는 Wasm 모듈로만 받는다.
호스트 애플리케이션이 허용한 API(파일 읽기, 네트워크 호출, DB 쿼리 등)만 노출한다.
Wasm 모듈의 CPU/메모리/실행시간을 런타임에서 강하게 제한한다.

이렇게 하면, OS나 컨테이너 설정에 크게 의존하지 않고도,
“언어/플랫폼 불문”으로 꽤 튼튼한 샌드박스를 제공할 수 있습니다⁶.

시사점: 2026년, AI 샌드박스는 선택이 아니라 필수다

여기까지 긴 내용을 한 번 정리해 보겠습니다.

AI 에이전트는 착하지만 위험하다.
프롬프트 인젝션, 환각된 패키지, 파일 시스템 취약점, 네트워크 데이터 유출…
에이전트가 “노력”하는 만큼 공격자도 노력하고 있습니다³.
컨테이너는 좋은 출발점이지만, 충분한 답은 아니다.
기본 도커만으로 “완전한 샌드박스”를 기대할 수는 없습니다⁵.
특히 신뢰할 수 없는 코드를 멀티테넌트로 돌릴 땐 더더욱 그렇습니다.
마이크로VM, gVisor, WebAssembly 등 다양한 샌드박스가 있다.
- 컨테이너: 개발 경험 최고, 보안은 설정에 따라 천차만별
- 마이크로VM: 하드웨어 가상화로 커널까지 분리
- gVisor: 시스템콜을 유저스페이스에서 가로채어 커널 공격면 축소
- WebAssembly/isolates: 런타임 레벨에서 “할 수 있는 것 자체”를 강하게 제한⁴⁷⁶
도구는 이미 쏟아지고 있다.
- Docker Sandboxes: 로컬 개발에서 AI 에이전트를 안전하게 쓰기 위한 실질적인 해답²
- Kata Containers, Firecracker: “컨테이너처럼 쓰되, VM처럼 격리”하는 러닝 커브 높은 솔루션³⁵
- Wasm 런타임: 서버, 엣지, 브라우저를 가리지 않고 플러그인 샌드박스를 제공하는 차세대 옵션⁷⁶

개인적으로, 2026년을 기준으로 이렇게 생각합니다.

“샌드박스를 안 쓰는 AI 시스템은, 이미 설계 단계에서 레거시가 되기 시작했다.”

이제는 “에이전트를 쓸까 말까”의 고민이 아니라,
“어떤 수준의 샌드박스를 기본값으로 삼을 것인가”를 고민해야 할 시점입니다.

지금 할 수 있는 가장 현실적인 첫걸음은 이 정도일 겁니다.

로컬 개발: Docker Sandboxes 같은 도구로 에이전트를 컨테이너 안에 가두기
서버/팀 환경: 최소 gVisor, 가능하면 마이크로VM 검토
SaaS/플러그인: 아키텍처 설계 단계에서부터 Wasm과 VM을 옵션으로 넣어두기

AI가 점점 더 많은 일을 대신해 줄수록, 우리는 코드보다 “경계(boundary)”에 더 많은 신경을 써야 합니다.
샌드박스는 그 경계를 눈에 보이게 만들어 주는 도구입니다.

이제, 여러분의 에이전트는 어디에서, 어떻게 격리되어 돌고 있나요?

참고

¹The Complete Guide to Sandboxing Autonomous Agents: Tools, Frameworks, and Safety Essentials

²Docker Sandboxes Tutorial and Cheatsheet

³The Complete Guide to Sandboxing Autonomous Agents: Tools, Frameworks, and Safety Essentials

⁴A field guide to sandboxes for AI

⁵Sandboxing Untrusted Python | Hacker News

⁶WebAssembly - Wikipedia

⁷WASI 1.0: You Won't Know When WebAssembly Is Everywhere in 2026 - The New Stack