Claude Code Approval / Sandbox Guide | 매일 안전하게 쓰는 설정법

Claude Code를 안전하게 쓰려면 approval 창이 뜬다는 사실만으로는 부족합니다. 승인 요청이 너무 많아지면 사람은 읽지 않고 누르게 되고, allow 범위가 너무 넓으면 원래 사람이 멈춰야 할 작업까지 그대로 흘러갑니다.

이 글은 Claude Code 시작 가이드 이후 단계에 있는 사람을 위한 글입니다. 편리함은 이미 알지만, 이제는 무엇을 자동으로 돌리고 무엇을 승인으로 남기고 무엇을 금지할지 운영 규칙으로 정리하고 싶은 경우에 맞춰 썼습니다. 개념부터 보고 싶다면 Harness Engineering 가이드, Permissions 가이드, 보안 실패 사례도 함께 보세요.

approval만으로는 안전하지 않다

안전한 일상 설정은 보통 세 층으로 나뉩니다.

제어	역할	예시
permission rules	allow / ask / deny 경계 정의	secrets, destructive commands, deploy
approval flow	되돌리기 어려운 부작용 앞에서 멈춤	git push, publish, send
sandbox	shell이 닿는 범위 자체를 줄임	build, verification, exploratory scripts

공식 문서는 항상 기본 기준으로 두는 편이 좋습니다: permissions, settings, hooks. 핵심은 간단합니다. 되돌릴 수 있는 일은 빠르게, 되돌릴 수 없는 일은 느리게 처리하는 것입니다.

매일 쓰기 위한 기본 분리

작업	기본값	이유
파일 읽기, 검색, diff 확인	allow	위험이 낮고 가치가 큼
build, test, lint, analytics	allow	반복 속도를 지켜야 함
브랜치 안에서의 코드 수정	ask 또는 session allow	저장소 성숙도에 따라 다름
git push, deploy, publish, send	ask	외부 부작용 발생
.env 읽기, rm -rf, git reset --hard	deny	사고 범위가 너무 큼
외부 API 쓰기	ask	실제 시스템에 영향

문제는 “수정 자체”가 아니라 수정 뒤에 어떤 검증을 붙이느냐입니다. 그래서 위험한 프롬프트 패턴을 피하는 것도 중요합니다.

바로 시작할 수 있는 .claude/settings.json

{
  "$schema": "https://json.schemastore.org/claude-code-settings.json",
  "permissions": {
    "allow": [
      "Read",
      "Grep",
      "Glob",
      "Bash(npm run build)",
      "Bash(npm run test)",
      "Bash(node scripts/analytics-report.mjs *)"
    ],
    "ask": [
      "Edit",
      "Write",
      "Bash(git push *)",
      "Bash(npx wrangler pages deploy *)",
      "Bash(node scripts/outreach-send-mails.mjs --send)",
      "WebFetch(domain:api.gumroad.com)"
    ],
    "deny": [
      "Read(./.env)",
      "Read(./.env.*)",
      "Bash(rm -rf *)",
      "Bash(git reset --hard *)",
      "Bash(curl * | sh)"
    ]
  },
  "sandbox": {
    "enabled": true,
    "failIfUnavailable": false
  }
}

현재 공식 sandbox 설명은 macOS, Linux, WSL2 중심입니다. 비슷한 경계가 없는 환경에서는 sandbox만 믿지 말고, side effect가 있는 작업을 더 많이 ask에 두는 편이 안전합니다.

hooks를 더하면 실수가 줄어든다

permissions가 “해도 되는가”를 정한다면, hooks는 “실행 전후에 무엇을 강제로 돌릴 것인가”를 정합니다.

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash(git add*)",
        "hooks": [{
          "type": "command",
          "command": "git diff --cached --name-only | grep -E '^\\.env' && echo 'Blocked: .env staged' && exit 1 || exit 0"
        }]
      },
      {
        "matcher": "Bash(npx wrangler pages deploy*)",
        "hooks": [{
          "type": "command",
          "command": "npm run build"
        }]
      }
    ],
    "PostToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [{
          "type": "command",
          "command": "npm run test || true"
        }]
      }
    ]
  }
}

핵심은 세 가지입니다.

• commit 전에 secret 파일을 막는다
• deploy 전에 build를 강제한다
• edit 뒤에는 결정론적인 검증을 붙인다

실제 워크플로 3개

1. 콘텐츠 사이트

콘텐츠 운영에서 중요한 것은 “글을 썼다”가 아니라 “공개 상태까지 확인했다”입니다. analytics 확인, 주제 선택, 다국어 작성, build, deploy, 공개 URL 확인, Playwright 모바일 검증까지 한 흐름으로 묶어야 합니다.

2. 앱 저장소

코드 검색, diff 확인, 브랜치 내 리팩터링, build / test 반복은 Claude Code가 잘합니다. 하지만 shared branch push, DB migration, production admin API, infra 변경은 ask에 남겨야 합니다.

3. 영업 / 백오피스 자동화

조사, 분류, 초안 작성은 자동화해도 좋지만, 메일 발송이나 실제 레코드 변경은 approval이 필요합니다. drafting과 sending을 분리해야 합니다.

자주 터지는 실패

1. 모든 것을 ask로 두고 안심한다.
2. --dangerously-skip-permissions가 일상이 된다.
3. build 성공을 곧 release 성공으로 착각한다.

특히 세 번째는 콘텐츠 운영에서 자주 나옵니다. 공개 URL 확인과 Playwright 검증이 없으면 한 언어만 빠지거나 모바일 CTA가 깨진 채로 넘어가기 쉽습니다.

오늘 실제로 바꾼 규칙

ClaudeCodeLab에서는 오늘 이 원칙을 daily automation에 그대로 반영했습니다.

• 매 run마다 새 글 1개를 반드시 공개
• 기존 작업도 1개 이상 추가로 진행
• Playwright로 모바일 확인
• 새 글의 모든 언어 URL을 production에서 확인

안전한 agent는 “조심해”라는 문장보다 구체적인 운영 규칙에서 나옵니다.

다음 단계

먼저 무료 cheatsheet로 daily workflow의 기본을 옆에 두세요. 설정, hooks, CLAUDE.md, CI/CD 예시까지 한 번에 정리된 자료가 필요하면 English products page를 보고, 팀 도입 규칙이나 안전한 운영 경계를 같이 설계하고 싶다면 consultation page를 이용하면 됩니다.