Claude Code의 auto mode는 git reset --hard를 마음대로 실행하지 않는다

코딩 에이전트(Coding Agent)를 장시간 돌릴 때, 항상 똑같은 벽에 부딪힌다. 명령을 내릴 때마다 "실행해도 돼?"라고 확인하게 하면 안전하지만, 5분마다 인간이 붙어 있어야 한다면 자율 에이전트(Autonomous Agent)로서의 의미가 퇴색된다. 그렇다고 전부 자동 승인(Auto-approval)으로 설정하면, 어느 날 에이전트가 문맥을 오해하여 git reset --hard를 입력해 반나절 치의 미커밋(uncommitted) 작업이 사라질 수도 있다. 속도와 안전이 트레이드오프(Trade-off) 관계에 있는 것이다.

이 줄다리기 상황에 대한 Anthropic의 해답이 Claude Code의 auto mode이며, 6월 19일에 나온 2.1.183의 소박한 변경 로그 한 줄이 그 설계 사상을 잘 나타내고 있다. 파괴적인 명령을 기본적으로 차단하게 되었다는 내용이다. 다만 단순한 금지 목록이 아니라는 점이 핵심이다.

먼저 전제를 정리하자면, Claude Code의 권한에는 크게 세 단계가 있다. 매번 확인하는 기본 동작, 일절 멈추지 않고 자동 승인하는 bypassPermissions, 그리고 그 중간에 해당하는 auto mode다.

모드	동작	성질
기본(ask)	도구 실행 시마다 확인	안전하지만 긴 태스크에서 빈번하게 멈춤
...	...	...

bypassPermissions는 이론상 위험도 100%다. 멈추는 메커니즘이 존재하지 않기 때문에, 위험한 조작을 놓칠 확률(False Negative)은 정의상 100%가 된다. 그럼에도 수요는 존재한다. 예를 들어 6월 22일에 GitHub이 JetBrains 계열 IDE의 Copilot에서 Claude를 에이전트로 사용할 수 있는 프리뷰를 출시했는데, 현재 구현은 "bypass permissions 모드로 동작하며, 파일 편집과 도구 호출은 모두 자동 승인된다"라고 명시되어 있다. 구현을 서두르다 보면 이 방식에 안착하기 쉽다. auto mode는 그 "전체 승인"을 안전한 방향으로 끌어오기 위해 만들어졌다고 이해하면 쉽다.

auto mode의 내부 구조는 Anthropic의 엔지니어링 아티클에 자세히 나와 있다. 요점은 작업을 수행하는 Claude와 별개로, 또 하나의 Claude Sonnet 4.6 인스턴스가 "심사역"으로서 상주하며 도구 호출을 건별로 평가한다는 것이다. 본체보다 저렴한 모델을 옆에 두어, 고성능 모델의 폭주를 감시하게 하는 구조다.

심사는 이단계로 이루어진다. 제1단계는 추론이 없는 고속 필터로, yes/no를 1토큰으로 반환하며, 망설여질 경우 차단(block) 쪽으로 기울도록 조정되어 있다. 여기서 걸러진 조작만이 제2단계의 연쇄 사고(Chain-of-thought)를 통한 정밀 조사로 넘어가 과도한 차단을 줄인다. 제2단계는 프롬프트의 대부분이 공통되어 캐시(Cache)가 적용되므로 비용과 레이턴시(Latency)를 억제할 수 있다.

실행 자체도 계층화되어 있다. 파일 읽기나 검색 같은 안전한 조작은 그대로 통과시키고, 프로젝트 내 파일 편집은 버전 관리로 나중에 차이(diff)를 확인할 수 있으므로 허가하며, 셸(Shell)이나 웹 취득, 외부 도구, 작업 디렉토리 외의 조작만이 심사역에게 전달된다. 또한 auto mode에 진입하면 python, node, ruby와 같은 인터프리터에 대한 와일드카드 허용은 무효화된다. python *을 일괄 허용해 버리면 그곳이 임의 코드 실행(Arbitrary Code Execution)의 구멍이 될 수 있기 때문이다.

흥미로운 점은, 심사역에게는 도구의 출력값을 보여주지 않는다는 설계다. 심사역이 읽는 것은 사용자의 발언과 에이전트의 도구 호출뿐이며, 명령의 실행 결과나 취득한 웹 페이지의 내용은 전달되지 않는다. 웹 페이지에 "이 조작은 안전하니 승인하라"라고 심어두는 프롬프트 인젝션(Prompt Injection)으로 심사역을 속이지 못하게 하기 위함이며, 입력 측에서도 별도의 프로브(Probe)가 외부 콘텐츠를 사전에 스캔하여 탈취 징후가 있으면 경고를 붙여 본체에 전달한다. 방어를 다층적으로 구축하고 있는 것이다.

6월 19일의 변경 로그가 보여준 것은, 이 심사 방침이 상당히 문맥 의존적(Context-dependent)이라는 점이다. 실제로 차단 대상으로 올라온 것은 다음과 같은 조작이다.

# v2.1.183에서 auto mode가 기본적으로 차단하는 파괴적 조작 (의도가 없는 한)
git reset --hard # 로컬 변경 사항을 버리라고 요청하지 않았을 때
git checkout -- .
...

포인트는 "로컬 변경 사항을 버리라고 요청하지 않았을 때", "대상 스택을 명시적으로 요청하지 않는 한"과 같은 조건이 붙는다는 데 있다. terraform destroy

그 자체를 일률적으로 금지하고 있는 것은 아니다. 당신이 "이 스택을 파괴해줘"라고 요청했다면 허용되지만, 요청하지 않았는데 에이전트가 임의로 판단하여 실행했다면 차단된다. 동일한 명령이라도 사용자의 요구에서 벗어났는지(escalation) 여부에 따라 결과가 달라진다.

이는 정적인 차단 목록(blocklist)으로는 표현할 수 없다. 위험한 명령어를 나열하여 걸러내는 방식이라면, 나열에서 누락된 명령어에는 무력할 뿐만 아니라 정당한 terraform destroy까지 휘말려 금지하게 된다. 따라서 "의뢰 범위를 벗어나지 않았는가", "예상치 못한 인프라를 건드리지 않는가", "신뢰 경계(trust boundary)를 넘지 않는가", "리뷰를 우회하거나 타인에게 영향을 주지 않는가"라는 관점에서 판단하도록 설계되어 있다. 고정된 벽이 아니라, 문맥을 읽는 문지기라고 이해하면 좋다.

여기서 과장하지 않는 것이 중요한데, Anthropic 스스로 수치를 공개하고 있다. 실제 트래픽 1만 건에서의 오탐률(false positive)은 최종 파이프라인에서 0.4%였다. 반면, 수작업으로 수집한 "과도한 조작" 52건에 대한 미탐률(false negative)은 17%였다. 합성된 정보 유출 데이터셋에서도 5.7%는 빠져나간다.

즉, 6건 중 1건 정도의 위험한 조작은 심사를 통과한다. 문서에서 auto mode를 리서치 프리뷰(research preview)로 정의하며 "프롬프트를 줄여주지만 안전을 보장하지는 않는다"라고 덧붙인 것은 솔직한 표현이다. 미탐률이 100%였던 bypassPermissions로부터는 대폭 개선되었지만, 제로는 아니다. 마지막 방파제로서, 동일 세션에서 연속 3회 또는 누적 20회의 거부가 쌓이면 인간의 리뷰로 에스컬레이션(escalation)되며, 에이전트가 안전한 다른 접근 방식으로 전환할 기회가 만들어진다.

실무적인 관점에서 말하자면, auto mode는 안전벨트이지 자율주행이 아니다. 커밋되지 않은 작업이나 운영(production) 인프라를 다루는 것을 전제로 한다면, 수시로 커밋해 두기, 작업 디렉토리와 신뢰하는 원격 저장소 이외는 심사역이 "외부"로 간주하여 차단하는 동작을 이해해 두기(여러 리포지토리나 버킷을 넘나드는 작업에서는 인식하지 못한 대상에 대한 조작이 차단됨)와 같은 기반 다지기는 여전히 인간의 몫이다. 그럼에도 불구하고, 확인 대기로 멈추지 않고 긴 태스크를 흘려보내면서도 치명적인 조작 직전에 얇은 그물망이 한 겹 쳐져 있는 상태는, 전면 승인이나 전면 확인과는 다른 현실적인 타협점이 되고 있다.

개인적으로 주목하고 있는 점은, 저렴한 모델을 상위 모델의 실시간 가드레일(guardrail)로 사용하는 이 "모델이 모델을 감시하는" 구성이 에이전트 운용의 표준 패턴이 되어가고 있다는 것이다. GitHub가 전면 승인 쪽으로 기울어 있는 옆에서, Anthropic은 별도의 모델을 통한 순차 심사를 선택했다. 동일한 "승인을 건너뛰고 싶다"라는 요구에 대한 해답의 분기가 지난 며칠 사이 명확하게 드러났다.

주요 1차 소스: