Claude Code Auto mode의 13.6%와 89%: 사람 검토를 어디에 남길까

Claude Code가 위험한 명령을 실행하려 할 때마다 사람이 버튼을 누르면 더 안전할까. Anthropic이 공개한 통제 실험에서는 위험 명령 1,053개 중 사람이 143개를 막았고 자동 분류기는 937개를 막았다. 발표에서 표시한 탐지율은 각각 13.6%와 89%다. 차이는 크지만, 이 결과를 “사람 검토는 필요 없다”로 읽으면 핵심을 놓친다. 같은 실험에서 사람만 잡아낸 명령도 있었기 때문이다.

개발자가 결정할 문제는 승인 버튼을 전부 없앨지 여부가 아니다. 반복적인 로컬 작업은 어디까지 맡기고, 어떤 변경에서는 사람이 목적지와 영향 범위를 직접 확인할지를 정하는 일이다. 이 글은 원문의 실험 분모를 풀어 읽고, 현재 공식 설정 문서와 연결해 그 경계를 정리한다. AI를 활용해 공개 자료를 분석한 해설이며 제품 사용 후기나 독립 재현 보고서가 아니다.

1. 13.6%는 평소 거부율이 아니라 위험 명령 탐지율이다

2026년 8월 7일 발표에 따르면 유급 전문 테스터 1,053명이 연구용 환경에서 코딩 작업을 수행했다. 자신의 저장소나 실제 운영 프로젝트를 다루는 상황은 아니었다. 연구진은 각 세션 도중 승인 요청 하나를 명백히 위험한 명령으로 바꾸고, 참여자가 이를 승인하는지 관찰했다. 참여자는 평가받는다는 사실은 알았지만 어떤 행동을 측정하는지는 몰랐다. 위험한 요청을 승인해도 실제로 위험한 동작이 실행되지는 않았다.

따라서 13.6%의 분모는 일반적인 승인 요청 전체가 아니다. 연구자가 넣은 위험 명령 1,053개다. 사람이 그중 143개를 알아보고 차단했다는 뜻이다. 자동 분류기는 같은 명령 가운데 937개를 차단했다. 이 수치를 평소 사용자의 일반 거부율, 모든 작업의 안전도, 운영 사고 감소율로 바꿔 적을 수 없다. Anthropic이 자사 제품을 설명하기 위해 발표한 결과이지, 이 글에서 독립적으로 검증한 성능도 아니다.

0–100% 동일 축으로 비교했다. 통제 실험의 탐지율이며 일반 거부율·사고율이 아니다. 출처: claude.com/resources/articles/auto-mode-default-in-claude-code.

원문의 정수 건수로 계산한 탐지율 차이는 약 75.4퍼센트포인트다. 두 비율을 빼는 값이므로 “안전이 75.4% 개선됐다”는 표현과 다르다. 이 계산은 발표된 집계의 산술 확인에 불과하며 모델을 다시 실행한 벤치마크가 아니다. 독자가 직접 확인하려면 사람은 143을 1,053으로, 분류기는 937을 같은 1,053으로 나누면 된다.

2. 사람만 잡은 6개가 보여 주는 검토의 자리

원문은 분류기가 사람은 승인한 명령 800개를 막았고, 사람은 분류기가 허용한 명령 6개를 막았다고 설명한다. 같은 비교 안에서도 탐지 대상이 완전히 겹치지는 않았다는 의미다. 사람의 총 차단 143개와 분류기의 총 차단 937개를 단순히 더하면 중복을 세게 된다.

공개 집계에서 겹침을 풀면 둘 다 차단한 명령은 137개, 분류기만 차단한 명령은 800개, 사람만 차단한 명령은 6개, 둘 다 놓친 명령은 110개다. 아래 그림은 새로운 측정이 아니라 그 집계를 재배열한 것이다. “분류기를 쓰면 사람보다 더 많은 위험 요청을 발견했다”는 결론과 “남은 위험을 사람이 검토할 이유가 있다”는 결론은 동시에 성립한다.

발표 집계를 산술 재구성했다. 결합 제품의 실험 결과나 운영 안전 보증이 아니다. 출처: claude.com/resources/articles/auto-mode-default-in-claude-code.

다만 사람이 먼저 보고 분류기가 나중에 보는 결합 제품의 성능을 이 표만으로 주장할 수는 없다. 실제 결합 방식에서는 문맥, 경고 표시, 검토자의 주의와 행동이 달라질 수 있다. 여기서 얻을 수 있는 실무적 교훈은 자동화의 높은 평균 점수만으로 되돌리기 어려운 변경까지 무조건 위임하지 말자는 정도다. 사람 검토 역시 안전 보증서가 아니므로 변경 범위와 복구 가능성을 함께 확인해야 한다.

3. 자동 분류는 격리도 무제한 실행 권한도 아니다

발표 당시 설명에서 Auto mode는 도구 호출을 분류해 되돌릴 수 없거나 파괴적이거나 작업 환경 밖을 향하는 동작을 막도록 설계됐다. 차단되면 에이전트가 다른 안전한 방법을 찾거나 사용자에게 확인하고, 연속 세 번 또는 세션 전체 스무 번 차단되면 수동 승인으로 돌아간다고 적혀 있다. 이 횟수는 8월 발표에 적힌 동작 설명이며, 이 글에서 현재 설치본의 모든 동작을 시험한 것은 아니다.

분류기는 명령의 뜻과 사용자 의도를 판단하는 층이다. 운영체제 차원의 파일 접근 제한이나 네트워크 격리가 실제 실행 가능 범위를 제한하는 것과 구분해야 한다. 위험해 보이는 명령을 걸러 준다고 해서 외부 전송 경로가 물리적으로 사라지는 것은 아니다. 반대로 복구 가능한 로컬 파일 수정과 운영 데이터 삭제를 같은 강도의 승인 대상으로 묶으면, 확인 횟수만 늘어 중요한 판단이 흐려질 수 있다.

권한 규칙이 분류기보다 먼저 작동한다. 모든 호출이 모든 행을 순서대로 통과한다는 뜻은 아니다. 출처: code.claude.com/docs/en/auto-mode-config.

현재 공식 설정 문서는 명시적인 deny와 ask 규칙이 분류기보다 먼저 평가된다고 설명한다. 금지해야 하는 동작은 맞는 deny 규칙으로 차단하고, 사람이 확인해야 하는 동작은 맞는 ask 규칙으로 질문하게 만드는 구분이다. 분류기 내부의 자연어 규칙과 도구 권한 규칙은 같은 통제가 아니므로 이름이 비슷하다고 서로 대체한다고 보면 안 된다.

4. 작업 이름보다 목적지와 되돌리기 비용으로 나눈다

되돌릴 수 있는 로컬 작업은 위임 후보로, 외부 전송과 되돌리기 어려운 변경은 별도 검토 대상으로 나눈다. 아래 표는 기능을 켜는 법보다 작업을 맡기기 전에 정할 조건에 초점을 맞춘다. “위임 후보”도 안전하다는 인증은 아니며, 테스트가 외부 시스템을 건드리거나 비밀을 읽는다면 다른 범주로 다시 판단해야 한다.

작업 상황	위임 전에 확인할 것	사람 검토를 남길 지점
임시 작업 디렉터리의 수정과 로컬 테스트	입력에 비밀이 없는지, 테스트가 외부 쓰기를 하지 않는지	diff와 테스트 결과를 다음 단계로 넘기기 전
작업 저장소에 push 또는 PR 생성	실제 원격 저장소, 공개 여부, 포함 파일과 CI 후속 동작	팀이 외부 반영 전 검토를 원하면 명시적 checkpoint
운영 DB 변경과 인프라 배포	정확한 대상, 변경 범위, 백업·복구 절차와 실행 권한	영향이 발생하기 전 변경 내용과 대상을 직접 검토
보고서나 소스의 외부 업로드	수신 목적지와 공개 범위, 전송 데이터의 민감도	내부 전송 실패 뒤 공개 서비스로 우회하지 않는지 확인

이 표는 공식 문서에 근거한 편집 판단이며, 실제 Claude Code 실행이나 보안 정책 적용 시험 결과가 아니다. 특히 현재 문서는 작업 중인 저장소의 기본 브랜치 push와 PR 생성이 기본 허용 범위에 들어갈 수 있다고 설명한다. 배포·공개 목적을 드러내는 비기본 브랜치나 비밀이 포함된 push 등에는 별도 판단이 붙는다. 그러므로 “Auto mode가 켜졌으니 push 직전에 항상 물어본다”는 기대는 맞지 않는다.

공식 문서에서 도출한 편집 판단이다. 목적지와 복구 가능성을 확인하며 제품 시험 결과가 아니다. 출처: code.claude.com/docs/en/auto-mode-config.

또 다른 함정은 규칙이 명령의 실제 표기와 일치해야 한다는 점이다. 공식 문서의 Bash(git push *) 예시는 그 형태로 시작하는 명령을 질문 대상으로 삼지만, git -C <dir> push나 git -c <key>=<value> push처럼 쓴 명령까지 같은 예시가 보장하지는 않는다. 문서는 전체 명령을 검사하는 checkpoint가 필요하면 PreToolUse hook을 검토하도록 안내한다. 이 글은 hook 구현이나 모든 우회 표현을 막는 정책을 제공하지 않는다.

대화에 “검토하기 전에는 push하지 마”라고 말하는 방법도 영구 설정과 다르다. 현재 문서는 문맥 압축으로 해당 메시지가 사라지면 경계도 유실될 수 있다고 경고한다. 작업 규약을 대화 한 줄에만 맡기지 말고, 필요한 강도에 맞는 런타임 규칙과 조직 정책을 검토해야 한다. 여기서는 사용자의 설정이나 보안 정책을 변경하지 않았다.

5. 도입 판단에서 빼야 할 숫자와 남겨야 할 질문

원문에는 운영 세션의 위해 비교와 생산성 수치도 있지만, 통제 실험과 같은 분모가 아니다. 특히 위해 비교는 데이터 활용에 동의한 계정 중 안전 파이프라인이 검토 대상으로 표시한 세션을 모델이 다시 평가한 것이다. 이를 전체 사용자의 사고율이나 Auto mode 도입의 인과 효과로 읽으면 표본의 조건을 지워 버린다. 이번 글에서는 그 비율을 안전 점수로 합치지 않는다.

가격과 이용 범위도 시점을 나누어야 한다. 8월 발표는 Pro·Max·Team의 기본 모드 전환과 분류기 추가 토큰 비용 면제를 설명했지만, 그것이 작업 전체가 무료라는 뜻은 아니다. 당시 다른 공급자 경로의 향후 계획도 10월의 모든 계정 설정이 자동으로 바뀌었다는 증거는 아니다. 현재 구성 문서는 공급자 전반의 이용 가능성을 설명하면서 모델과 조직 차원의 요건을 별도로 확인하라고 안내한다. 자신의 계정에서 적용되는 조건은 실제 환경에서 확인해야 한다.

도입 전에는 질문을 세 가지로 좁히는 편이 낫다. 반복 승인 중 실제로 판단할 정보가 없는 로컬 작업은 무엇인가. 목적지나 공개 범위가 바뀌는 순간을 어느 통제에서 잡을 것인가. 되돌리기 어려운 변경을 실행하기 전에 누가 diff와 대상을 확인할 것인가. 탐지율은 첫 질문을 자동화할 근거가 될 수 있지만 나머지 질문을 없애지는 못한다. Anthropic도 고위험 운영 인프라 변경은 직접 검토할 것을 권고한다.

참고 자료

• Anthropic의 2026년 8월 7일 발표: 통제 실험의 분모·차단 건수·실험 조건과 고위험 변경 검토 권고. 발표자가 보고한 결과로 한정해 사용했다.
• Claude Code 공식 Auto mode 구성 문서: 2026년 10월 19일 수집·확인한 본문에서 Common boundaries와 Add a human checkpoint를 중심으로 읽었다. 기본 push 허용 범위, ask 규칙의 표기 한계, 대화 경계의 유실 가능성을 구분했다.

관련 글은 이번 패키지에 별도로 추가하지 않았다. 기존 권한 파서·무인 승인 글의 보존된 본문은 중복 구분에만 사용했으며, 이 단계에서 해당 공개 페이지의 실제 URL과 현재 본문을 새로 검증하지 않았기 때문이다.