Claude Code "Auto Mode"란 무엇인가 — --dangerously-skip-permissions 없이 자동화를 실행하는 방법

yolo 모드를 켜고 망해본 사람을 위한 글

 

yolo 모드를 켜고 작업하다 rm -rf 한 줄이 잘못 들어가 프로젝트가 통째로 날아간 적이 있는가? 혹은 git push --force가 자동으로 통과되어 동료의 PR을 모두 덮어쓴 경험은? 한 번이라도 이런 사고를 친 적이 있다면 이 글이 도움이 될 것이다.

 

최근에 Anthropic이 Claude Code Auto Mode라는 권한 모델을 공개했다. 한 줄로 요약하면, --dangerously-skip-permissions 없이도 자동화를 돌릴 수 있게 됐다는 의미다. 그동안은 dsp 플래그(yolo 모드)와 매번 권한을 묻는 기본 모드, 두 극단만 존재했는데 그 사이를 채우는 중간 옵션이 드디어 등장한 것이다.

 

이 글을 끝까지 읽으면 Auto Mode가 정확히 무엇인지, dsp와 어떻게 다른지, 언제 어떻게 켜야 안전한지 모두 파악할 수 있다. 내가 한 달가량 켜놓고 굴려본 결과와 사고 사례, 비교표까지 담았으니 워크플로 전환 여부를 판단하는 데 활용하면 된다.

 

그동안 사용되던 yolo 모드의 진짜 문제

 

--dangerously-skip-permissions는 어떻게 동작했는가

 

기존 Claude Code는 도구를 사용할 때마다 권한 프롬프트를 띄웠다. Bash 명령 하나를 실행하려 해도 "이 명령을 실행해도 되는가?"라고 물었으며, 파일을 편집할 때도, WebFetch를 할 때도 모두 물었다. 자율 실행을 원하면 매번 엔터를 누르거나 옵션을 골라야 했고, 30분짜리 작업을 시켜놓고 옆에서 권한 프롬프트를 처리하는 일은 정말 답답했다. 나는 한 시간에 평균 40번 정도 엔터를 친 것 같다.

 

GitHub anthropics/claude-code 저장소 이슈 트래커와 Reddit r/ClaudeAI에서 자주 언급되던 우회 방법이 바로 --dangerously-skip-permissions 플래그(통칭 dsp, yolo 모드)였다. 이 플래그를 켜면 모든 권한 프롬프트가 그대로 통과된다. Bash, Edit, Write, WebFetch 전부 자동 승인된다. 자율 실행에는 편리했지만 이름 그대로 "위험하게 모두 스킵"하는 옵션이었다.

 

실제로 사고가 발생한 사례들

 

yolo 모드를 켜놓고 망한 사례는 정말 많은데, 내가 직간접적으로 본 것 몇 개를 풀어본다. 가장 흔한 것이 rm -rf가 잘못 들어간 경우다. AI가 임시 파일을 정리하려 실행했는데 경로가 잘못 잡혀 프로젝트 루트가 통째로 날아간 사례다. 백업이 없었다면 끝장이다.

 

git push --force 자동 실행 또한 만만치 않게 자주 터진다. 컨텍스트 파악이 어긋난 AI가 강제 푸시를 수행해 팀원의 작업을 모두 덮어쓰면, 리모트 히스토리를 복구하려 reflog를 뒤지면서 한나절을 날리게 된다. 거기에 환경 변수 파일을 실수로 GitHub에 push하거나 curl로 외부 서버에 토큰을 통째로 전송하는 케이스도 있다. 한 번 노출되면 키 로테이션과 감사 로그 점검이 패키지로 뒤따른다.

 

마지막으로 typosquatting을 노린 악성 npm 패키지를 AI가 의심 없이 설치하는 패턴도 있다. 공급망 공격을 그대로 당하는 셈이라 발견 시점도 늦다.

 

Anthropic이 굳이 "dangerously"를 박은 이유

 

플래그 이름에 "dangerously"를 박은 것은 진짜 위험하다는 점을 인지시키려는 의도였다. 정상적인 사용자라면 위험 표시된 옵션을 켜지 않을 텐데, Claude Code의 자율 실행 워크플로를 구성하려면 어쩔 수 없이 켜야 했다는 점이 진짜 문제였다.

 

권장 사용법은 Docker 컨테이너 안에서만 사용하는 것이었다. 호스트 시스템과 격리된 환경에서 실행하면 사고가 나도 컨테이너만 폐기하면 되기 때문이다. 다만 매번 컨테이너를 띄우는 것이 번거로워 다수가 그냥 호스트에서 켜놓고 사용했고, 그래서 사고가 발생했다. 인간은 결국 편한 길을 택하게 된다.

 

Auto Mode는 진짜로 무엇이 다른가

 

자동 승인과 수동 승인을 가르는 기준

 

Auto Mode의 핵심은 "안전한 작업은 자동, 위험한 작업은 수동"이라는 휴리스틱이다. 모든 도구를 무차별 통과시키는 것이 아니라 명령마다 위험도를 평가해 분기한다.

 

읽기 전용 명령(ls, cat, git status)이나 테스트 실행, 일반적인 파일 편집, 문서 조회 등은 알아서 처리된다. 반대로 파일 삭제, 강제 푸시, 외부 네트워크 호출, 패키지 설치, 권한 변경, sudo 등은 여전히 사람의 확인을 받는다. 이 분기를 AI가 자체적으로 판단하기 때문에 단순 패턴 매칭 기반의 allowlist보다 더 영리하다. "어떤 상황에서 이 명령이 나왔는지" 컨텍스트까지 보고 결정하는 점이 크다.

 

위험 명령 자동 차단 동작

 

rm -rf /, git push --force origin main, chmod 777 ., curl … | bash 같은 명령은 Auto Mode가 알아서 차단한다. AI가 실수로 생성하더라도 실행 전에 "이 명령은 위험한데 정말 진행할 것인가?"라고 한 번 더 묻는다. dsp 플래그였다면 그대로 통과됐을 명령들이 사람의 검토를 거치게 되는 것이다. 자율성은 거의 그대로 유지하면서 안전망 한 겹을 추가하는 셈이다.

 

실전 작동 예시

 

대략 이런 흐름으로 동작한다.

 

> Claude, 오래된 로그 파일 정리해줘

[Auto Mode] find logs/ -name "*.log" -mtime +30  → 자동 승인 (조회만)
[Auto Mode] ls logs/ | wc -l                      → 자동 승인 (조회만)
[Auto Mode] rm logs/old-2024-*.log                → 사람 확인 필요 (삭제 명령)

이 명령 실행할까요? [y/N/details]

 

읽기와 조회는 알아서 진행하고 실제로 파일을 삭제하는 단계에서만 멈춘다. 매번 묻는 기본 모드보다 훨씬 빠르며, 모두 통과시키는 yolo 모드보다 안전하다. 내가 측정해보니 30분짜리 자동화 작업에서 권한 프롬프트가 40번대에서 5~6번으로 줄었다.

 

Auto Mode 대 다른 안전 옵션 비교

 

권한 관리 옵션이 Auto Mode 하나만 있는 것은 아니다. 상황별로 골라 쓸 수 있는 옵션을 내 사용 후기와 함께 묶어 정리한다.

 

방식	안전성	속도	학습 비용	한 줄 평
Auto Mode	높음	빠름	낮음	일반 개발 자동화의 디폴트로 적합하다
`--dangerously-skip-permissions`	매우 낮음	가장 빠름	낮음	Docker 안에서만
Permissions allowlist	매우 높음	보통	중간	CI/CD에는 이것이 정답이다
Docker 샌드박스	매우 높음	느림	높음	컨테이너를 띄우는 비용이 부담스럽다
Git worktree 격리	중간	빠름	중간	병렬 작업에는 사실상 필수다
수동 모드 (default)	가장 높음	가장 느림	없음	첫 세팅 점검 단계에서 유용하다

 

옵션별로 좀 더 풀어보면, allowlist 방식은 .claude/settings.json에 Bash(npm test:), Edit(src//.ts), WebFetch(domain:github.com) 같은 형태로 허용 패턴을 명시하는 방식이다. 정형화된 작업에 강하며, CI/CD 파이프라인 내부에서 자동 코드 수정을 돌릴 때 적합하다. Docker 샌드박스**는 호스트 시스템과 완전히 격리되므로 dsp와 함께 써도 안전하지만, 매번 컨테이너를 띄우는 비용이 의외로 거슬린다.

 

Git worktree 격리는 작업 디렉터리만 분리하는 방식이라 파일시스템 보호는 안 되지만 브랜치 충돌을 막는 데 좋고, git worktree add 명령으로 시작하면 된다. 수동 모드는 매번 묻는 기본값이라 자율 실행과는 거리가 멀다. 결론적으로 일반 개발 작업에는 Auto Mode가 디폴트로 가장 적합하며, 정형화된 반복 작업에는 allowlist, 진짜 위험한 실험용에는 Docker 조합이 합리적이다.

 

 

출처: https

 

Auto Mode 활성화 방법 (실전)

 

기본 활성화 명령

 

가장 쉬운 방법은 CLI 플래그로 켜는 것이다. 정확한 플래그명은 사용 중인 버전에서 claude --help로 확인하는 것이 안전하다. 발표 직후라 옵션명이 변경될 수 있기 때문이다. 일반적으로 /permissions 슬래시 커맨드로 세션 안에서 토글하거나, 시작할 때 플래그로 지정하는 방식이다.

 

# 시작할 때 플래그로 지정
claude --auto

# 세션 안에서 토글
/permissions auto

 

켜면 프롬프트에 "Auto Mode" 인디케이터가 표시된다. 끄고 싶으면 동일한 명령으로 다시 토글하면 된다.

 

.claude/settings.json으로 프로젝트 단위 고정

 

매번 플래그를 박는 것이 번거롭다면 프로젝트 루트의 .claude/settings.json에 박아두면 된다.

 

{
  "permissions": {
    "mode": "auto",
    "allow": [
      "Bash(npm test:*)",
      "Bash(npm run lint)",
      "Edit(src/**/*.ts)"
    ],
    "deny": [
      "Bash(rm -rf:*)",
      "Bash(git push --force:*)"
    ]
  }
}

 

allow 리스트는 Auto Mode가 자동 승인하지 않더라도 무조건 통과시킬 패턴이고, deny는 절대 통과시키지 않을 패턴이다. Auto Mode 휴리스틱 위에 사용자 규칙 한 겹을 더 얹는 셈이다. 팀 단위로 settings.json을 공유하면 모든 팀원이 동일한 권한 정책으로 작업하게 된다.

 

서브에이전트 디스패치 시 권한 전파

 

Claude Code는 서브에이전트(subagent)를 띄워 작업을 분할하는 기능을 제공한다. Auto Mode를 켠 메인 세션에서 서브에이전트를 띄우면 서브에이전트도 Auto Mode 권한을 그대로 물려받는다. 서브에이전트만 따로 dsp로 돌리는 것은 불가능하므로 이 점을 알고 있어야 한다.

 

서브에이전트가 위험 명령을 실행하려 하면 메인 세션에 권한 요청이 올라온다. 사용자는 메인 터미널에서 한 번에 모두 검토 가능하다. 병렬로 작업을 돌려도 권한 흐름이 한 곳으로 모이는 구조이므로 검토 부담이 줄어드는 효과가 있다.

 

Windows / WSL 환경 주의점

 

Windows에서 Claude Code를 사용한다면 몇 가지 알아둘 것이 있다. claude.exe 경로는 보통 ~/.local/bin/claude.exe에 있고, Git Bash를 사용한다면 CLAUDE_CODE_GIT_BASH_PATH 환경 변수를 설정해야 한다. WSL2 안에서 Auto Mode를 돌릴 때는 호스트 윈도우 파일시스템 접근(/mnt/c/...)도 위험 명령으로 분류되어 호스트 파일을 만질 때는 사람 확인을 거치게 된다.

 

PowerShell에서 실행할 때 한 가지 더, && 체인이 동작하지 않는다. ; 또는 if ($?) { ... } 패턴을 사용해야 한다. 나는 처음에 이를 모르고 30분을 헤맸다.

 

그래도 dsp를 써야 하는 케이스는 존재한다

 

Auto Mode가 좋다고 dsp가 완전히 사라지는 것은 아니다. 여전히 쓸 만한 시나리오가 두어 가지 있다.

 

다만 Docker 컨테이너 안에서 일회성 자동화를 돌릴 때는 dsp가 가장 빠르다. 호스트와 완전히 격리된 환경이라면 사고가 나도 컨테이너만 폐기하면 되므로 안전성 손해도 거의 없다. 컨테이너 내부에서 대규모 코드 생성이나 데이터 처리를 수행할 때는 여전히 dsp가 합리적인 선택지다. GitHub Actions 같은 ephemeral CI 잡도 마찬가지다. 잡이 끝나면 환경이 사라지므로 dsp로 돌려도 영구적인 피해가 발생하지 않는다. 따로 분리한 VM이나 dev container에서 막 돌려보는 실험용으로도 dsp는 활용할 만하다.

 

각설하고, 호스트 시스템에서는 절대 직접 켜지 마라. 본인 노트북, 회사 개발 머신에서 dsp를 켜는 것은 진짜 위험하다. Auto Mode가 등장한 지금 시점에서는 더더욱 켤 이유가 없다.

 

자주 빠지는 함정과 알아두면 좋은 점

 

MCP 서버 권한도 Auto Mode 휴리스틱의 적용 대상이다. mcp__* 도구로 Slack 메시지 보내기, GitHub PR 만들기 등 외부 시스템을 다루는 작업은 거의 모두 사람 확인을 받는다고 봐야 한다. 나는 이를 모르고 처음에 "왜 자꾸 멈추지?"라고 생각했는데, 외부 부수효과가 있는 작업이라 멈추는 것이 맞았다.

 

Plan Mode와의 조합도 효율이 좋다. 계획을 짜는 동안은 읽기만 수행하므로 거의 모두 자동 승인되고, 실행 단계에서만 위험 명령을 검토하면 된다. Cursor의 yolo 모드, Aider의 auto-confirm 같은 옵션과 비교하면 Claude Code Auto Mode가 더 세밀한 분기를 수행한다는 점이 차별점이다. 단순한 on/off가 아니라 명령 단위의 판단이라는 점이 크다.

 

처음부터 메인 프로젝트에 박지 말고 사이드 프로젝트나 임시 디렉터리에서 한 번 켜보고 어떤 명령이 자동 승인되는지 감을 잡는 것이 좋다. 나는 첫날 30분 정도 임시 폴더에서 테스트를 돌려본 뒤 메인 프로젝트로 옮겼는데, 그 30분이 시간 절약 측면에서 가장 효율이 좋았다.

 

 

출처: prototypr.io

 

이제 yolo 모드는 잊어도 된다

 

Claude Code Auto Mode를 한 달가량 굴려본 결론을 정리하자면, 안전한 명령은 알아서 처리하고 위험한 명령만 사람에게 묻기 때문에 자율성과 안전성이 동시에 어느 정도 확보된다. 매번 권한 프롬프트를 누르던 시절은 끝났다. 그리고 --dangerously-skip-permissions는 호스트에서 절대 사용하지 마라. Docker 안과 같은 격리 환경에서만 사용해야 한다. 본인 노트북에서 켜는 것은 그냥 시한폭탄이다.

 

세밀한 제어를 원한다면 .claude/settings.json allowlist를 활용해 Auto Mode 휴리스틱 위에 사용자 규칙을 얹어 더 안전하게 다지면 된다. 팀 환경에서는 사실상 필수에 가깝다.

 

본인 환경에서 Claude Code Auto Mode를 한 번 켜보면 감이 잡힌다. Anthropic 공식 발표나 Claude Code 공식 문서에서 정확한 동작을 확인할 수 있고, 어떤 명령이 자동 승인되고 어떤 것이 차단되는지 직접 눈으로 보는 것이 가장 빠르다. 내 기준으로는 권한 프롬프트 클릭 횟수가 80% 이상 감소했고, dsp로 인한 사고 걱정도 거의 사라졌다. yolo 모드 시절로 돌아가기는 어려울 것이다.