Claude Code의 --dangerously-skip-permissions 옵션을 운영 DB에서 실행했을 때의 경험과 변경 사항

지난 화요일 새벽 3시, 멀티 에이전트 루프 (multi-agent loop)가 분당 12,000회의 KV 쓰기(writes)를 기록하며 멈춰버렸습니다. 해당 루프는 단 한 줄의 카운터 버그 때문이었습니다. 그 부분은 수정이 가능했습니다. 하지만 추적 과정에서 발견한 문제는 더 심각했습니다.

저는 D1 마이그레이션 (migrations)을 실행 중이던 Claude Code 세션에서 --dangerously-skip-permissions 옵션을 활성화해 두었습니다. 저는 그것이 스테이징 (staging) 환경을 가리키고 있다고 생각했습니다. 하지만 그렇지 않았습니다. .dev.vars 대신 .env.production을 로드하도록 환경 변수 (env) 파일 참조를 잘못 설정한 것이었습니다. Claude는 묻지 않았습니다. 해당 플래그 (flag)가 묻지 말라고 명령했기 때문입니다. 마이그레이션 내용은 DROP COLUMN이 아닌 ADD COLUMN이었기에 데이터 손실은 없었습니다. 간신히 버틸 수 있는 수준이었습니다.

제가 잘못 생각한 점은 --dangerously-skip-permissions를 "귀찮은 확인 팝업을 건너뛰는 것"으로 취급했다는 것입니다. 사실 이 옵션은 "인간이 실행될 명령이 무엇인지 확인하는 유일한 순간을 제거하는 것"입니다. 이 둘은 매우 다른 의미입니다. 플래그를 다시 끄는 것이 도움이 되긴 하지만, Claude가 _무엇을 시도하는지_를 제한하지는 못합니다. 그저 새벽 3시에 어차피 클릭하게 될 프롬프트 (prompt)를 추가할 뿐입니다.

실제로 효과가 있었던 방법은 .claude/settings.json에 거부 규칙 (deny rule)을 추가하는 것이었습니다:

{
  "permissions": {
    "allow": ["Bash(wrangler d1 execute * --local*)"],
...

허용 규칙 (allow rule)이 거부 규칙 (deny)보다 더 구체적이므로, --local 호출은 통과되고 그 외의 모든 것은 실행 전에 차단됩니다. 수정 후 2주 동안 Claude는 운영 DB 명령을 단 한 번도 시도하지 않았습니다. 세 건의 거부 이벤트 (deny events)가 로그에 기록되었으나, 이는 Claude가 폭주한 것이 아니라 빠른 컨텍스트 전환 (context-switches) 중에 제가 작성한 모호한 프롬프트 때문이었습니다.

결국 저는 세 가지 계층을 운영하게 되었습니다: settings.json 허용 목록 (allowlist), 스테이징 자격 증명 (credentials)만 물리적으로 포함하는 마이그레이션 작업용 별도 git 워크트리 (worktree), 그리고 운영 환경에 손을 대기 전에 반드시 물어보라고 Claude에게 지시하는 CLAUDE.md입니다. 다만 CLAUDE.md 방식에는 실제적인 주의 사항이 있습니다. 세션이 길어지면 컨텍스트 (context)가 커짐에 따라 지시 사항의 영향력이 약해진다는 점입니다. 중요한 사항은 프롬프트 자체에 다시 명시해야 합니다.

worktree 설정, 정확한 CLAUDE.md 문구, 그리고 왜 MCP 도구 권한 (tool permissions)이 거부 규칙 (deny rules)과 일관되지 않게 작동하는지를 포함한 전체 분석 내용을 riversealab.com에 작성했습니다.

전체 포스트 보기 →