Claude Code를 써본 개발자라면 알 겁니다. 매번 “이 파일 읽어도 될까요?” “이 명령 실행해도 될까요?” 물어보는 게 귀찮아서 --dangerously-skip-permissions 옵션을 켜고 싶은 유혹이요. 일명 “YOLO 모드”죠. 하지만 AI가 잘못된 명령을 실행하거나 중요한 파일을 덮어쓰면 어떻게 될까요?

AI 코딩 도구가 점점 더 많은 권한을 요구하면서 이 문제가 현실화되고 있습니다. 특히 LLM이 생성한 코드가 API 키를 다루고 외부 서비스를 호출하는 상황에서는 단순히 “프로세스 격리”만으론 부족합니다. 두 가지 접근법—로컬 개발용 bubblewrap과 서비스 구축용 Deno Sandbox—이 이 문제를 어떻게 해결하는지 살펴봅니다.

출처:

• Sandboxing AI agents in Linux – Senko Rašić
• Introducing Deno Sandbox – Deno Blog

문제의 본질, AI가 생성한 코드를 어디까지 믿을 수 있나

AI 에이전트가 코드를 작성하고 실행하는 것은 편리하지만 근본적인 불확실성이 있습니다. 프롬프트 인젝션으로 악의적 코드가 생성될 수 있고, 단순한 실수로도 중요한 파일이 손상될 수 있죠.

Claude Code의 기본 모드는 매번 권한을 확인합니다. 안전하지만 개발 흐름을 끊고, 다른 작업을 병행하기 어렵게 만듭니다. 반대편 끝에는 “YOLO 모드”가 있습니다. 모든 권한을 자동 승인하는 거죠. 빠르지만 위험합니다.

전통적인 “신뢰할 수 없는 플러그인 실행” 문제와도 다릅니다. AI가 생성한 코드는 리뷰 없이 즉시 실행되고, 그 코드 자체가 다시 LLM을 호출하면서 실제 API 키를 사용합니다. 컴퓨팅 자원만 격리해서는 부족하고, 네트워크 접근과 시크릿까지 통제해야 합니다.

로컬 개발자를 위한 해법, bubblewrap으로 가벼운 격리

Linux 개발자라면 bubblewrap이 좋은 선택지입니다. Docker보다 가볍고, Linux 커널의 cgroups와 user namespaces를 활용해 프로세스를 격리합니다.

핵심은 “최소 권한 원칙”입니다. 개발자 Senko Rašić는 자신의 환경에 맞춰 다음을 설정했습니다:

• 시스템 바이너리와 라이브러리는 읽기 전용으로 마운트
• 현재 프로젝트 디렉토리만 쓰기 가능
• .claude.json 설정은 임시로 주입 (변경사항 저장 안 됨)
• 네트워크는 허용 (AI 서비스 접속 및 서버 실행용)

이 방식의 장점은 실제 개발 환경과 동일하게 작동한다는 점입니다. 파일 경로가 같고, 프로젝트 구조가 그대로여서 IDE에서 바로 확인하고 수정할 수 있죠. 원격 샌드박스나 Docker처럼 별도 환경을 관리할 필요가 없습니다.

물론 Linux 커널 제로데이 취약점이나 프로젝트 내 API 키 유출까지는 막지 못합니다. 하지만 실용적 수준의 보안은 확보됩니다. 코드베이스 손상은 git으로 복구하면 되고, 민감한 시스템 파일 접근은 차단되니까요.

서비스 구축자를 위한 해법, Deno Sandbox의 혁신

사용자가 생성한 코드를 실행해야 하는 서비스를 만든다면 Deno Sandbox가 더 나은 선택입니다. 1초 내에 부팅되는 경량 Linux microVM을 제공하고, 단순한 격리를 넘어선 두 가지 혁신이 있습니다.

첫째는 네트워크 egress 제어입니다. 샌드박스가 접근할 수 있는 호스트를 화이트리스트로 지정합니다:

await using sandbox = await Sandbox.create({
  allowNet: ["api.openai.com", "*.anthropic.com"],
});

승인되지 않은 호스트로의 요청은 VM 경계에서 차단됩니다. 프롬프트 인젝션으로 evil.com에 데이터를 보내려 해도 막히는 거죠.

둘째는 시크릿 보호 메커니즘입니다. API 키가 환경변수로 노출되지 않습니다:

await using sandbox = await Sandbox.create({
  secrets: {
    OPENAI_API_KEY: {
      hosts: ["api.openai.com"],
      value: process.env.OPENAI_API_KEY,
    },
  },
});

코드가 $OPENAI_API_KEY를 보면 placeholder만 보입니다. 실제 키는 승인된 호스트(api.openai.com)로 요청을 보낼 때만 아웃바운드 프록시가 주입합니다. 악의적 코드가 placeholder를 빼내가도 쓸모없죠.

이 두 기능은 httpjail 같은 아웃바운드 프록시로 구현됩니다. VM 레벨 네트워크 제한과 Deno 런타임의 --allow-net 플래그를 함께 쓰면 다층 방어가 됩니다.

추가로 Deno Sandbox는 샌드박스에서 테스트한 코드를 sandbox.deploy() 한 줄로 Deno Deploy 프로덕션에 바로 배포할 수 있습니다. 별도 CI 시스템이나 재인증 없이 개발 환경이 곧바로 오토스케일링 서버리스 배포로 전환되는 거죠.

AI 에이전트 시대의 새로운 보안 패러다임

AI 에이전트가 코드를 생성하고 실행하는 시대에는 “신뢰”의 경계가 달라집니다. 사람이 작성한 코드도 완벽하지 않지만, AI가 생성한 코드는 리뷰 없이 즉시 실행되고 외부 API를 호출합니다.

bubblewrap 접근은 개인 개발자에게 실용적입니다. 개발 흐름을 유지하면서 시스템 손상 리스크를 줄이죠. Deno Sandbox는 한 단계 더 나아갑니다. 네트워크 제어와 시크릿 보호로 LLM 생성 코드가 API 키를 다루는 상황에서도 안전하게 작동합니다.

두 접근법 모두 완벽한 보안을 제공하지는 않습니다. 하지만 “모든 권한 vs 매번 확인”이라는 이분법을 벗어나 실용적 중간 지대를 제시합니다. Deno Sandbox는 베타로 출시되었고, Deno Deploy 플랜에 포함됩니다. 원문에는 기술 스펙과 가격 정책, SDK 사용법이 자세히 나와 있습니다.

참고자료:

• coder/httpjail – 아웃바운드 프록시 구현
• Deno Sandbox 문서
• bubblewrap GitHub