Claude Code가 하루 치 작업량을 날려버릴 뻔한 git 명령어를 차단하기 시작했습니다. 그럼에도 저는 deny rules를 유지할
요약
Claude Code의 오토 모드에 도입된 새로운 가드레일 기능과 사용자가 직접 설정하는 deny rules의 차이점을 분석합니다. Claude Code의 안전 분류기가 의도를 추론하여 명령어를 차단하는 방식과 정적 규칙의 결정론적 차이를 설명합니다.
핵심 포인트
- Claude Code 오토 모드는 파괴적인 git 명령어를 기본적으로 차단함
- 가드레일은 단순 규칙 매칭이 아닌 안전 분류기(safety classifier)의 실시간 추론 기반임
- 분류기 오류나 모델 장애 시 '페일 클로즈' 방식으로 작동하여 명령어를 차단함
- 사용자 정의 deny rules는 모드와 상관없이 작동하는 결정론적 보호 수단임
얼마 전, 저는 에이전트에게 예전 코드를 잠시 살펴볼 수 있도록 마지막 푸시(push) 상태로 되돌려 달라고 요청했습니다. 에이전트는 git reset --hard를 실행했고, 제가 커밋하지 않은 작업물까지 함께 날려버렸습니다. 그 아찔한 경험 이후, 저는 settings.json에 직접 deny rules(거부 규칙)를 추가하기 시작했습니다. 제가 직접 이름을 불러 요청하지 않는 한, 파괴적인 git 명령어가 실행되는 것을 거부하는 지루한 코드 줄들을 말이죠.
이번 달, Claude Code는 제가 수동으로 구축해 오던 가드레일(guardrail) 기능을 출시했습니다. 2026년 6월 19일 변경 로그(changelog)에 따르면, 이제 오토 모드(auto mode)에서는 기본적으로 파괴적인 명령어들을 차단합니다. 로컬 작업을 폐기하라는 요청을 하지 않았다면 git reset --hard, git checkout -- ., git clean -fd, git stash drop 등의 명령어가 거부됩니다. 또한, 이번 세션에서 에이전트가 생성한 커밋이 아니라면 git commit --amend가 차단됩니다. 그리고 terraform, pulumi, cdk의 destroy 명령어는 특정 스택(stack)을 직접 지정하지 않는 한 차단됩니다.
저의 첫 반응은 제가 직접 작성한 코드 줄들을 삭제하는 것이었습니다. 이제 기본 설정이 제가 수동으로 해오던 일을 해주는데, 굳이 유지보수를 할 필요가 있을까요? 하지만 이 가드(guard)가 실제로 어떻게 작동하는지 읽어본 후, 저는 다시 deny rules를 복구했습니다.
가드는 실재하며, 규칙이 아니라 분류기(classifier)입니다
제 마음을 돌린 부분은 바로 여기입니다. 오토 모드에서 Claude Code는 각 명령어를 승인해 달라고 사용자에게 묻지 않습니다. 대화 내용을 읽는 두 번째 모델인 안전 분류기(safety classifier)가 각 동작이 안전한지 실시간으로 결정합니다. 새로운 가드레일은 바로 그 분류기 내부에 존재합니다. git reset --hard를 차단할 때, 이는 단순히 고정된 패턴을 매칭하는 것이 아닙니다. 대화 기록(transcript)을 바탕으로, 사용자가 작업을 버리라고 요청하지 않았음을 추론(inferring)하는 것입니다.
그러한 추론(inference)은 훌륭하며 환영할 만한 일이지만, 규칙(rule)과는 동일한 것이 아닙니다. 분류기(classifier)는 의도(intent)를 판단하며, 이는 곧 의도를 잘못 판단할 수도 있음을 의미합니다. 솔직한 진실은 실패 모드(failure mode)에서 드러납니다. 분류기 모델을 일시적으로 사용할 수 없을 때, 자동 모드(auto mode)는 '페일 클로즈(fail closed, 차단 상태로 종료)' 방식으로 작동하여 모델이 복구될 때까지 명령어를 차단합니다. 페일 클로즈는 올바른 결정이며, 이는 또한 이 보호 기능이 모델의 도달 가능 여부와 상관없이 단순히 참인 정적 라인이 아니라, 의존성을 가진 실시간 추론(live inference)임을 상기시켜 줍니다.
내가 직접 작성한 코드 라인을 유지하는 세 가지 이유
첫 번째는 모드(mode)입니다. 이 가드레일(guardrail)은 자동 모드(auto-mode)의 기능입니다. 만약 일반적인 권한 프롬프트(permission prompts)와 함께 Claude Code를 실행하거나, 자동 모드 분류기가 명령어를 제어하지 않는 설정에서 실행한다면, 기본 설정은 이를 대신 수행해주지 않습니다. settings.json의 거부 규칙(deny rule)이나 PreToolUse 훅(hook)은 모드와 상관없이 실행됩니다. 이는 당신이 오늘 에이전트(agent)를 어떻게 운전하고 있는지에는 신경 쓰지 않습니다.
두 번째는 결정론(determinism)입니다. 분류기는 당신이 요청했는지를 추론(infer)하지만, 거부 규칙은 당신이 실제로 했는지를 매칭(match)합니다. 대부분의 명령어에 대해서는 추론이 괜찮지만, 저에게 하루 치 작업량을 앗아갈 수 있는 단 하나의 명령어에 대해서는, 실행되거나 되지 않거나 둘 중 하나인 지루할 정도로 확실한 패턴의 확실성을 원합니다. PreToolUse 훅 또한 권한 시스템(permission system) 이전에 실행되므로, 더 느슨한 체크를 통과해버리는 것들을 잡아냅니다. 추론은 하한선(floor)을 높여주지만, 매칭된 규칙은 그 자체로 하한선입니다.
세 번째는 범위(scope)입니다. 새로운 가드는 git과 코드형 인프라(infrastructure-as-code)를 다룹니다. 이는 시작하기에 정확히 적절한 지점이지만, 전체 지도는 아닙니다. 이 기능은 에이전트와 rm -rf, 데이터베이스 삭제, main 브랜치로의 강제 푸시(force-push), 또는 파일에서 비밀 정보를 읽어 어딘가로 전송하는 행위 사이를 막아주지 않습니다. 제가 가장 걱정하는 몇몇 아찔한 순간(near-misses)들은 git과 전혀 관련이 없으며, 그런 경우 기본 설정은 아무것도 하지 않았습니다. 애초에 그렇게 설계되지 않았기 때문입니다.
추론이 유일한 계층은 아니며, 샌드박스(sandbox) 또한 마찬가지입니다
미묘한 이유 때문에 샌드박스(sandbox) 또한 이 문제를 해결하지 못한다는 점을 언급할 가치가 있습니다. 자동 모드(Auto mode)의 샌드박싱은 파일 시스템과 네트워크를 격리하지만, git reset --hard는 샌드박스 입장에서 안전해 보입니다. 프로젝트 디렉토리 내부의 파일만 건드리기 때문입니다. 경계(boundary)를 넘지 않았습니다. 작업 내용은 그저 사라질 뿐입니다. 파괴성(destructiveness)과 격리(containment)는 서로 다른 문제입니다. 도구는 하나를 완벽하게 해결하면서도 다른 하나는 열어둘 수 있습니다.
그래서 저는 이것들을 서로 경쟁하는 옵션으로 생각하는 것을 멈추고, 층층이 쌓기(stacking) 시작했습니다. 내장된 분류기(classifier)는 의도 추론(intent inference)입니다. 저의 거부 규칙(deny rules)과 훅(hooks)은 결정론적 강제(deterministic enforcement)입니다. 샌드박스는 격리(containment)입니다. 각각은 다른 것이 포착하는 것을 놓치며, 방지하기 위한 가장 비용이 적게 드는 아슬아슬한 상황(near-miss)은 한 계층이 아닌 세 계층이 거부하는 상황입니다.
제가 실제로 변경한 것
가드(guard)가 이제 중복해서 수행하게 된 줄들을 삭제하지 않았습니다. 확률론적 개선(probabilistic improvement) 아래에 결정론적 안전장치(deterministic backstop)로서 그대로 두었습니다. 이것이 바로 심층 방어(defense-in-depth)가 무엇인지 보여주는 방식입니다. 제가 실제로 변경한 것은, 새로운 기본 설정(default)이 확보해 준 주의력을 어디에 쏟을 것인가 하는 점입니다. 즉, 그것이 커버하지 못하는 공백에 집중했습니다. 이제 git 사례는 세 가지 방식으로 처리됩니다. rm -rf, 데이터베이스, 그리고 비밀 정보 유출(secret-exfiltration) 사례는 여전히 제가 작성한 규칙에 의존하고 있으므로, 다음 한 시간 동안의 설정 작업은 그곳에 투입될 것입니다.
미래의 나에게 남기는 노트
더 나은 기본 설정은 설정을 삭제하기 위해서가 아니라, 설정을 감사(audit)해야 할 이유가 됩니다. 바닥(floor)이 높아지면, 무엇이 이제 중복되었는지 확인하고, 그럼에도 안전장치로서 유지하며, 새로운 기본 설정이 여전히 도달하지 못하는 곳으로 노력을 옮기십시오. 분류기가 당신의 의도를 확신하지 못하거나, 명령어가 아예 git 명령어가 아닌 날, 당신과 사라진 작업 사이를 가로막고 있는 유일한 것은 아무것도 당신을 대신해 잡아줄 것이라 믿지 않았을 때 당신이 직접 작성했던 결정론적인 코드 한 줄뿐일 것입니다.
자동 모드 안전 상세 사항(차단된 git 및 IaC 명령어, "삭제 요청을 받지 않음" 조건, amend 규칙)은 2026년 6월 19일자 Claude Code 공식 변경 로그(changelog)에서 가져온 것입니다: https://code.claude.com/docs/en/changelog. 사고를 면했던 경험은 저의 것입니다. 동작 및 버전의 세부 사항은 빠르게 변경되므로, 이를 신뢰하기 전에 현재의 변경 로그를 통해 확인하십시오.
면책 조항: 이 포스트에 담긴 경험과 결정은 저 개인의 것입니다. 영어가 제 모국어가 아니기에, 글을 초안하고 편집하는 데 AI 어시스턴트의 도움을 받았습니다.
면책 조항: 이 포스트에 담긴 경험과 결정은 저 개인의 것입니다. 영어가 제 모국어가 아니기에, 글을 초안하고 편집하는 데 AI 어시스턴트의 도움을 받았습니다.
AI 자동 생성 콘텐츠
본 콘텐츠는 Dev.to AI tag의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기