Claude Code가 매번 물어보지 않게 하려면 -- dangerously-skip-permissions 파헤치기
왜 이 얘기를 하냐면
Claude Code로 작업하다 보면 파일 하나 고칠 때마다, 커맨드 하나 실행할 때마다 "이 작업을 진행할까요?" 팝업이 뜬다. 처음 며칠은 안전하다는 느낌에 안심이 되는데, 반복 작업을 시킬 때는 얘기가 다르다. 예를 들어 "이 폴더에 있는 마크다운 파일 50개 전부 프론트매터 수정해줘" 같은 요청을 하면, 파일마다 승인 버튼을 눌러야 해서 자리를 뜰 수가 없다.
그러다 커뮤니티에서 claude --dangerously-skip-permissions라는 옵션을 알게 됐다. 이름부터 "dangerously"가 붙어 있어서 호기심 반, 불안 반으로 찾아봤는데, 실제로 써보니 왜 이렇게 이름을 지었는지 이해가 됐다. 이 글에서는 이 플래그가 정확히 뭘 하는지, 언제 쓰면 되고 언제는 절대 쓰면 안 되는지, 그리고 물어보는 횟수만 줄이고 싶을 때 쓸 수 있는 더 안전한 방법들을 정리해봤다.
Claude Code의 권한 확인은 원래 왜 있는가
Claude Code는 기본적으로 파일을 읽고 쓰고, 터미널 명령을 실행하고, 필요하면 웹에서 정보를 가져오는 등 실제로 내 컴퓨터에서 "행동"을 한다. 그래서 기본 권한 모드에서는 다음과 같은 작업을 시도할 때마다 확인을 받는다.
- 새 파일 생성 / 기존 파일 수정
rm,git push,npm install같은 셸 명령 실행- 외부 API 호출이 필요한 도구 사용
이 확인 절차는 번거롭지만 존재 이유가 명확하다. AI가 잘못 해석한 명령으로 중요한 파일을 지우거나, 의도치 않게 git push --force를 실행하거나, 민감한 정보를 외부로 보내는 사고를 막기 위한 마지막 안전장치다.
--dangerously-skip-permissions는 무엇을 하는가
한 줄로 요약하면 이 플래그는 이 확인 절차 전체를 꺼버린다. 실행하면 이렇게 된다.
claude --dangerously-skip-permissions
이 명령으로 세션을 시작하면 Claude Code는 파일 수정, 명령 실행, 외부 호출 등 거의 모든 도구 사용에 대해 사용자에게 묻지 않고 곧바로 실행한다. 반복 작업을 맡길 때는 체감 속도가 확실히 다르다. 50개 파일을 고치는 작업이라면 팝업 50번을 누를 필요 없이 한 번에 끝까지 돌아간다.
문제는 이 편의성이 "브레이크 없는 자동차"와 같다는 점이다. AI가 요청을 잘못 해석해도, 의도치 않은 명령을 생성해도, 확인 없이 그대로 실행된다.
왜 "dangerously"라는 이름이 붙었는가
실제로 겪을 수 있는 위험은 대략 이런 것들이다.
- 의도치 않은 삭제/덮어쓰기: "임시 파일 정리해줘" 같은 모호한 요청에서 AI가 범위를 잘못 잡으면, 확인 없이 필요한 파일까지 지워버릴 수 있다.
- 위험한 셸 명령 실행:
git reset --hard,git push --force처럼 되돌리기 어려운 명령이 확인 없이 실행될 수 있다. - 프롬프트 인젝션 노출: 만약 작업 중에 외부 콘텐츠(웹페이지, 이슈 내용, 파일 내용 등)를 읽다가 그 안에 악의적인 지시문이 숨어 있다면, 평소에는 실행 전 확인 단계에서 걸러지는데 이 플래그를 쓰면 그 방어선이 사라진다.
- 범위를 넘는 네트워크 접근: 인증 정보가 있는 환경에서 외부 API를 호출하는 작업이 확인 없이 진행될 수 있다.
즉 이 플래그는 "느려서 답답한 확인 절차"가 아니라 "사고를 막는 마지막 브레이크"를 없애는 것이다.
언제 써도 괜찮은가
무조건 쓰면 안 된다는 얘기는 아니다. 아래 조건을 같이 만족할 때는 실용적인 선택이 될 수 있다.
- 격리된 환경에서 작업할 때 (Docker 컨테이너, 일회용 VM, 샌드박스 등 — 사고가 나도 그 환경만 날아가고 내 실제 시스템에는 영향이 없는 곳)
- git으로 이미 커밋된, 되돌릴 수 있는 상태에서 작업할 때 (뭔가 잘못돼도
git reset으로 복구 가능) - 네트워크나 민감한 자격증명 접근이 없는 순수 로컬 코드 작업일 때
- 반복적이고 예측 가능한 범위의 작업(예: 정해진 포맷으로 여러 파일 일괄 수정)을 짧게 감독하며 돌릴 때
반대로 아래 상황이라면 절대 쓰지 않는 게 맞다.
- 프로덕션 서버나 실제 배포 파이프라인에 접근 가능한 환경
- 커밋되지 않은 중요한 로컬 변경사항이 있는 상태
- 외부 콘텐츠(웹, 이메일, 이슈, PR 등)를 읽어들이는 작업이 포함된 세션
- 팀 전체가 공유하는 저장소나 인프라에 직접 쓰기 권한이 있는 상황
더 안전한 대안: 전부 끄지 않고 필요한 것만 허용하기
사실 우리가 진짜 원하는 건 "매번 물어보지 않는 것"이지 "전혀 확인 안 하는 것"이 아닌 경우가 많다. Claude Code는 이 중간 지점을 위한 설정을 제공한다.
1. 프로젝트 단위 allowlist 설정 (settings.json)
프로젝트 루트의 .claude/settings.json에 자주 쓰는 안전한 명령/도구를 미리 허용 목록으로 등록해두면, 그 패턴에 맞는 요청은 확인 없이 바로 실행되고 나머지는 여전히 확인을 받는다.
{
"permissions": {
"allow": [
"Bash(git status:*)",
"Bash(git diff:*)",
"Bash(npm test:*)",
"Read(**)"
]
}
}
이 방식의 장점은 "위험할 게 없는 반복 명령"만 콕 집어서 자동화하고, git push --force나 rm -rf 같은 명령은 여전히 확인 단계를 거치게 만들 수 있다는 점이다.
직접 이 설정을 하나씩 채우기 귀찮다면, 최근 세션에서 자주 승인했던 읽기 전용 명령 패턴을 스캔해서 allowlist를 자동으로 만들어주는 기능도 있다. 매번 승인 버튼을 눌렀던 로그를 분석해서 "이건 계속 허용해도 되는 패턴이네" 하는 걸 추려주는 식이다.
2. 권한 모드 전환
세션 도중에도 권한 모드를 상황에 맞게 바꿔가며 쓸 수 있다. 예를 들어 파일 수정은 자동으로 받아들이되 명령 실행이나 삭제처럼 더 위험한 행동은 여전히 확인받는 중간 단계 모드도 있다. 매번 전체를 끄는 대신, "이번 작업에서 반복될 만한 행동만" 선택적으로 자동화하는 접근이 훨씬 안전하다.
3. deny 목록으로 위험한 것만 확실히 막기
반대로 접근할 수도 있다. 기본적으로는 어느 정도 자유롭게 두되, 절대 자동 실행되면 안 되는 명령만 명시적으로 차단하는 것이다.
{
"permissions": {
"deny": [
"Bash(git push --force:*)",
"Bash(rm -rf:*)",
"Bash(git reset --hard:*)"
]
}
}
allow와 deny를 같이 쓰면 "이건 자동, 이건 무조건 확인, 나머지는 기본 정책"으로 세밀하게 관리할 수 있다.
정리
claude --dangerously-skip-permissions는 모든 확인 절차를 끄는 가장 극단적인 방법이고, 이름 그대로 위험을 감수하는 선택이다. 격리된 일회성 환경에서 짧게 쓰는 건 몰라도, 실제 프로젝트나 프로덕션 근처에서는 권장하지 않는다.
내가 진짜 원했던 건 "반복되는 안전한 작업까지 매번 확인받는 피로감"을 줄이는 것이었고, 그건 전체 권한을 끄지 않고도 settings.json의 allow/deny 목록과 권한 모드 조합으로 충분히 해결됐다. 정리하면 이렇다.
| 상황 | 추천 방법 |
|---|---|
| 격리된 샌드박스에서 빠르게 반복 작업 | --dangerously-skip-permissions (제한적으로) |
| 프로젝트에서 반복되는 안전한 명령이 있음 | .claude/settings.json의 permissions.allow |
| 위험한 명령만 확실히 막고 싶음 | permissions.deny |
| 상황에 따라 유연하게 조절하고 싶음 | 권한 모드 전환 |
결론적으로, "안 물어보게 하는 것"과 "안전하게 안 물어보게 하는 것"은 다른 문제다. 후자를 목표로 잡으면 대부분의 경우 --dangerously-skip-permissions 없이도 원하는 생산성을 얻을 수 있다.
backtodev
40대 PM, 다시 개발자로 돌아갑니다. 실패하고 배우며 성장하는 기록.