목차
이 글은 Anthropic 엔지니어링 블로그에 2025년 10월 20일 게재된 “Beyond permission prompts: making Claude Code more secure and autonomous” 를 읽고, 내용을 정리한 글입니다. 원문: https://www.anthropic.com/engineering/claude-code-sandboxing
한 줄로 말하면 #
매번 팝업으로 묻지 말고, 미리 울타리를 쳐두자 — 권한 프롬프트가 84% 줄었다.
어떤 문제를 해결하려 했나 #
Claude Code를 처음 쓰는 사람들이 똑같이 부딪히는 함정.
“파일 쓸까요?” → 승인 “bash 명령 실행할까요?” → 승인 “또 파일 쓸까요?” → … 승인 “또…” → (이제 그냥 자동으로 엔터)
처음에는 신중하게 검토하지만, 열 번째 팝업쯤엔 읽지도 않고 클릭합니다. 이걸 원문은 “approval fatigue(승인 피로)” 라고 부릅니다. 결과적으로 안전 장치가 보호 기능을 못 합니다 — 사용자가 무비판적으로 승인하니까요.
해결책: 미리 울타리를 친 샌드박스 #
1. 작동 원리 — OS 수준 격리 #
리눅스의 bubblewrap, macOS의 seatbelt 같은 OS 원시 도구로 두 가지 경계를 동시에 강제합니다.
| 경계 | 무엇을 막나 |
|---|---|
| 파일시스템 격리 | 작업 디렉토리 밖 파일을 읽기·쓰기 못 함. SSH 키·시스템 파일 안전 |
| 네트워크 격리 | 미리 허용된 도메인만 접근. 데이터 유출·악성 다운로드 차단 |
둘 다 켜져 있어야 의미가 있습니다. 하나만 있으면 프롬프트 인젝션이 다른 쪽으로 빠져나갑니다.
2. 권한 팝업 / 자동 모드 / 샌드박스 비교 #
[권한 팝업] (전통적)
모든 동작마다 "허용?" → 피로, 무비판적 승인
[자동 모드]
분류 모델이 위험만 차단 → 위험 분류기 자체에 의존
[샌드박스]
울타리 안: 마음대로 → 빠르고 안전
울타리 밖: 시도 자체가 OS 레벨에서 막힘 → 침해돼도 영향 없음샌드박스의 핵심은, 프롬프트 인젝션이 성공해도 OS가 차단하기 때문에 사용자 보안에 영향 없다는 점입니다.
3. 샌드박스 안에서 가능한 일 / 불가능한 일 #
[가능]
- 작업 디렉토리 내 파일 읽기·쓰기
- 디렉토리 내에서 bash 명령 실행
- 사전 승인된 도메인만 네트워크 호출
- 스크립트·서브프로세스 실행 (울타리 안에서)
[차단]
- 디렉토리 밖 파일 접근 (SSH 키 ~/.ssh 등)
- 임의 외부 서버 호출
- 시스템 설정 변경git 같은 작업은 외부 프록시를 통해 인증 처리를 분리합니다. 자격 증명을 에이전트에 노출하지 않고도 푸시·풀이 가능해요.
결과 / 효과 #
- 권한 프롬프트 84% 감소 (Anthropic 내부 테스트)
- 침해 발생 시에도 세션 격리로 사용자 보안 영향 없음
- Claude Code on the Web 같은 클라우드 코딩 환경에서 특히 유용
핵심 결론 #
자동 에이전트 보안을 강화하려 할 때 사람들은 본능적으로 “더 많은 권한 확인 팝업을 띄우자"고 생각합니다. 이 글의 답은 다릅니다.
“안전이 부족한 줄 알았는데, 사실은 너무 자주 묻는 게 안전을 망치고 있었다.”
매번 묻는 것보다, 한 번 잘 정해둔 울타리가 안전과 자율성을 동시에 올립니다.
내 작업에 적용한다면 #
시나리오 1 — 일반적인 데이터 분석 과정 #
분석 자동화에서도 같은 함정이 있습니다. 매 단계마다 “이 파일 읽어도 돼?”, “이 SQL 실행해도 돼?” 묻는 구조라면, 결국 사람이 다 클릭하게 되고 자동화의 의미가 사라져요.
[Before — 매 동작 확인]
스크립트 단계마다 권한 확인
→ 야간 자동 분석에 사람 개입 필요
[샌드박스 패턴 적용]
[울타리 설정]
- 파일: 분석 디렉토리 + 데이터 폴더만 접근 가능
- 네트워크: 사내 DB / 정해진 API 도메인만
- 쓰기: 보고서 폴더만, 원본 데이터는 읽기 전용
[자유 영역]
- 울타리 안에서는 임의 쿼리/스크립트 실행 가능
[알림]
- 울타리 밖 시도 시에만 사람에게 알림핵심: 분석 자동화의 안정성은 “매 단계 검문"이 아니라 “한 번 잘 친 울타리” 에서 옵니다.
시나리오 2 — 웹 사이트를 자동으로 운영할 때 #
운영 자동화도 똑같습니다. 모든 배포에 사람 승인을 받으면 자동화가 아니고, 그렇다고 마음대로 풀어두면 사고가 납니다.
[Before — 모든 배포 수동 승인 or 풀 자동화]
수동 승인 → 야간 배포 못 함
풀 자동화 → 사고 시 피해 큼
[샌드박스 패턴 적용]
[울타리 설정]
- 파일: 사이트 콘텐츠 디렉토리 + 빌드 결과물만
- 네트워크: CMS API, CDN, 빌드 서버 도메인만
- 쓰기: 스테이징 환경만 자유, 프로덕션은 별도 게이트
[자유 영역]
- 스테이징 빌드·배포·롤백은 자유
- 콘텐츠 수정·발행도 정해진 폴더 내 자유
[알림]
- 프로덕션 직배포·외부 도메인 호출 시도 → 사람 승인 필요핵심: 자동 운영의 신뢰성은 “위험한 일만 사람이 본다” 는 분리 설계에서 옵니다. 모든 일에 사람이 끼면 자동화가 아니고, 모든 일이 자동이면 위험합니다. 그 사이의 울타리 설계가 핵심이에요.
Anthropic 엔지니어링 블로그를 오래된 순서대로 읽고 정리합니다.
