클로드 코드 샌드박스, OS 레벨 격리로 안전하게 코딩하기
![]()
왜 샌드박스인가
클로드 코드를 쓰다 보면 "이 명령어를 실행해도 될까요?"라는 팝업이 자주 뜹니다. 처음엔 안전장치로 다행이지만 반복되면 피로해지고, 결국 대충 보고 승인하게 되면서 오히려 보안이 약해집니다. 클로드 코드 샌드박스는 명령어를 하나하나 검사하는 대신, OS 레벨에서 실행 환경 자체를 격리합니다. 정해진 경계 안에서는 승인 없이 자유롭게 실행하고, 경계 밖으로 나가는 시도는 OS가 막습니다. 승인 팝업은 줄이면서 보안은 강화하는 방식입니다. 한 가지 중요한 점은 파일 시스템 격리와 네트워크 격리를 반드시 같이 적용해야 한다는 것입니다. 파일만 막고 네트워크를 열면 SSH 키 등이 유출될 수 있고, 네트워크만 막고 파일을 열면 시스템 파일을 조작해 네트워크 권한을 얻을 수 있습니다.
파일 시스템 격리
샌드박스는 현재 작업 디렉토리와 그 하위에만 읽기·쓰기를 허용합니다. 그 밖의 경로는 기본적으로 읽기만 가능하고, `~/.bashrc`나 `/bin/` 같은 민감한 시스템 경로는 아예 접근이 막힙니다. 프롬프트 인젝션으로 클로드의 판단이 흐려져도, 샌드박스가 시스템 파일 수정을 물리적으로 막아 주기 때문에 방어가 유지됩니다. settings.json의 Read·Edit deny 규칙으로 더 세밀한 파일 접근 제어를 둘 수 있습니다.
네트워크 격리
네트워크 격리는 샌드박스 밖에서 동작하는 프록시로 구현됩니다. 모든 네트워크 요청이 이 프록시를 지나기 때문에 허용된 도메인만 접근할 수 있고, 허용되지 않은 도메인으로 나가는 요청은 OS 레벨에서 차단되며 사용자에게 알림이 갑니다. 이 제한은 클로드가 실행하는 명령뿐 아니라 그 명령이 띄운 모든 자식 프로세스에도 적용됩니다. `npm install`이 보내는 HTTP 요청이나 빌드 스크립트의 API 호출도 같은 도메인 규칙을 따릅니다.
OS 레벨 강제
샌드박스는 단순한 앱 수준 제한이 아니라 OS 보안 기능을 사용합니다. macOS에서는 Apple의 Seatbelt 프레임워크를, Linux와 WSL2에서는 bubblewrap을 씁니다. Ubuntu/Debian은 `apt-get install bubblewrap socat`, Fedora는 `dnf install bubblewrap socat`으로 설치하면 되고, WSL1은 bubblewrap이 필요로 하는 커널 기능이 없어 지원되지 않으며 WSL2로 올려야 합니다. OS 보안 원시를 쓰기 때문에 클로드가 실행한 명령과 그 자식 프로세스 모두 같은 경계를 물려받고, 앱 레벨에서 우회하기가 사실상 어렵습니다.
활성화와 모드
클로드 코드에서 `/sandbox`를 치면 샌드박스 설정 메뉴가 열립니다. 자동 허용 모드(Auto-allow)에서는 샌드박스 안에서 실행 가능한 Bash 명령이 권한 확인 없이 자동 실행되고, 샌드박스로 실행할 수 없는 경우(허용되지 않은 도메인 접근 등)만 기존 권한 흐름을 따릅니다. 일반 권한 모드에서는 샌드박스 안에서 돌아가더라도 모든 Bash 명령이 기존처럼 권한 확인을 받습니다. 보안을 최우선으로 할 때 적합하지만 팝업이 더 자주 뜹니다. 두 모드 모두 파일·네트워크 격리는 동일하고, 차이는 승인 과정뿐입니다. 자동 허용 모드는 "accept edits" 모드와 독립적으로 동작하므로, 에디트는 수동 승인이라도 샌드박스 안의 Bash는 자동 실행될 수 있습니다.
설정과 한계
settings.json의 `sandbox` 블록으로 활성화 여부, `autoAllowBashIfSandboxed`, 제외할 명령(`excludedCommands`: docker·jest 등), 샌드박스 실패 시 밖에서 재시도 허용(`allowUnsandboxedCommands`), `network.allowedDomains`(와일드카드 지원), `network.allowLocalBinding` 등을 조정할 수 있습니다. 권한(Permissions)은 "어떤 도구를 쓸 수 있는지"를, 샌드박스는 "Bash와 자식 프로세스가 접근할 수 있는 파일·네트워크"를 OS 레벨에서 격리하므로, 둘을 함께 쓰면 다층 방어가 됩니다. 한계로는 네트워크가 도메인 단위라 세밀한 제어에 한계가 있고, `allowUnixSockets`를 켜면 강한 시스템 서비스에 접근할 수 있으며, 파일 쓰기 권한을 넓히면 권한 상승 공격 가능성이 생깁니다. 조직 단위 보안이 필요하면 커스텀 프록시를 둘 수 있고, 샌드박스 런타임은 오픈 소스 npm 패키지로 공개되어 있어 다른 AI 에이전트에서도 활용할 수 있습니다.
맺음말
클로드 코드 샌드박스는 "하나하나 물어보고 허가받는" 방식에서 "울타리 안에서는 자유롭게, 밖으로는 못 나가게" 하는 방식으로 전환해 줍니다. 파일 시스템과 네트워크를 OS 레벨에서 함께 격리하므로 프롬프트 인젝션 같은 공격이 들어와도 피해를 줄일 수 있습니다. `/sandbox`로 활성화한 뒤 자동 허용 모드를 켜기만 해도 체감이 크게 달라지고, 권한 설정·Hooks와 함께 쓰면 안전하면서도 흐름이 끊기지 않는 AI 코딩 환경을 만들 수 있습니다.