승인 창은 뜨는데, 검토는 점점 짧아진다
클로드 코드가 셸 명령을 실행할 때마다 승인을 요청하면 처음에는 내용을 꼼꼼히 읽습니다. 하지만 테스트와 파일 탐색이 이어질수록 승인 창은 안전장치보다 작업을 끊는 알림에 가까워지죠. 결국 넓은 허용 규칙을 만들거나 권한 확인을 건너뛰고 싶어집니다.
실제 사용 데이터에서도 권한 요청의 97%가 승인됐습니다. 다만 이 숫자만으로 모든 사용자가 내용을 읽지 않고 반사적으로 클릭했다고 단정할 수는 없어요. 관측 기간과 전체 프롬프트 수가 공개되지 않았고, 대부분은 정상적인 일상 명령이었을 가능성도 있습니다. 정확한 해석은 반복 승인이 위험을 잘 가려내는 장치인지 다시 살펴볼 이유가 생겼다는 정도입니다.
Anthropic은 이 문제를 해결하기 위해 2026년 8월 14일부터 Pro·Max·Team 플랜의 새 세션에서 오토모드를 내장 시작 모드로 적용했습니다. 기존에 다른 기본 모드를 지정한 사용자와 조직의 관리 설정은 유지됩니다.
같은 위험 명령에서 사람은 143번, 오토모드는 937번 멈췄다
통제 실험에서는 오토모드가 반복적인 수동 승인보다 위험 명령을 훨씬 많이 차단했습니다. Anthropic은 유료 전문 테스터 1,053명이 참여한 코딩 연구 환경에서 권한 요청 하나를 명백히 위험한 명령으로 바꿨습니다. 명령은 실제로 실행되지 않았고, 사람과 오토모드가 같은 1,053개 명령을 어떻게 처리하는지 비교했습니다.
| 판단 주체 | 차단한 위험 명령 | 차단율 |
|---|---|---|
| 수동 승인 사용자 | 143개 / 1,053개 | 13.6% |
| 오토모드 | 937개 / 1,053개 | 89% |
사람의 차단율은 세션 초반 약 17%에서 앞선 권한 요청이 50개를 넘었을 때 약 5%로 낮아졌지만, 오토모드의 차단율은 세션 길이에 따라 달라지지 않았습니다. 이 결과는 승인 요청이 누적되는 환경에서 자동 분류가 더 일관된 기본 통제가 될 수 있음을 보여줍니다.
89%를 모든 개발 작업의 안전성으로 확대하면 안 됩니다. 참가자는 실제 저장소가 아닌 테스트 환경에서 작업했고 평가 중이라는 사실도 알고 있었습니다. 구간별 표본 수와 신뢰구간, 위험 명령 목록 역시 공개되지 않았어요. 따라서 세심하게 인프라 변경을 검토하는 전문가보다 오토모드가 언제나 우월하다는 증거는 아닙니다.
오토모드는 모든 명령을 AI에게 묻는 구조가 아니다
오토모드는 먼저 명백히 안전한 작업을 통과시키고, 잠재적으로 위험한 작업만 2단계 분류기로 보냅니다. 읽기 전용 도구, 프로젝트 내부 파일 편집, 범위가 좁은 사용자 허용 규칙은 앞단에서 처리됩니다. 분류기의 1단계는 의심스러운 작업을 민감하게 골라내고, 2단계는 표시된 작업을 다시 추론해 불필요한 차단을 줄입니다.
분류기는 Claude가 작성한 설명이나 실행 이유 대신 사용자 메시지와 실제 도구 입력을 중심으로 판단합니다. 에이전트가 만든 그럴듯한 설명에 안전 판단이 끌려가지 않게 입력을 분리한 설계입니다.
외부로 민감정보를 보내는 작업, 프로덕션 배포와 마이그레이션, 공유 인프라 변경, 강제 푸시, 기존 파일의 비가역적 파괴 등은 기본 차단 범주에 포함됩니다. 다만 20여 개 규칙을 모두 어떤 상황에서도 해제할 수 없는 절대적 금지로 이해하면 곤란합니다. 사용자는 오토모드를 벗어날 수 있고, 조직은 별도의 deny·ask 정책을 추가해야 합니다.
기존 허용 규칙도 범위를 확인해야 합니다. Bash(npm test)처럼 좁은 규칙은 유지되지만, Bash(*)나 인터프리터·패키지 매니저에 광범위한 코드 실행 권한을 주는 규칙은 오토모드에 들어갈 때 제외될 수 있습니다. 모드를 벗어나면 제외됐던 규칙은 복원됩니다.
분류기도 놓친다: 실제 과잉 행동 52건 중 17%
오토모드의 장점은 위험 제거가 아니라 반복 승인보다 일관된 선별입니다. 배포된 2단계 분류기는 Anthropic 직원 세션에서 수집한 실제 과잉 행동 표본 52건 가운데 17%를 허용했습니다. 합성 데이터 유출 시도 1,000건에서는 5.7%를 놓쳤고, 정상적인 내부 트래픽 1만 건을 잘못 막은 비율은 0.4%였습니다.
여기서 17%는 전체 실사용 명령의 실패율이 아닙니다. 이미 거부되거나 사후에 문제로 표시된 52건만 모은 작고 편향된 표본이에요. 반대로 89% 차단율도 실제 프로덕션 환경 전체를 대표하지 않습니다. 두 수치는 오토모드가 유용하면서도 고위험 작업의 사람 검토를 대체할 수 없다는 경계를 함께 보여줍니다.
권한 모드는 작업의 되돌릴 수 있는 정도로 나누세요. 로컬 코드 수정과 테스트처럼 diff로 확인하고 되돌릴 수 있는 작업은 오토모드로 시작할 수 있습니다. 프로덕션 배포, 공유 인프라 변경, 민감정보 전송, 대량 데이터 변경은 별도의 사람 승인과 조직 정책을 유지하는 편이 안전합니다.
첫 확인은 테스트 저장소에서 시작한다
오토모드가 내 환경에서 어떻게 작동하는지는 커밋·푸시·배포가 필요 없는 버전 관리 저장소에서 먼저 확인하세요. 선택한 계정·조직·모델이 오토모드를 지원해야 하며, 어떤 설정 파일에도 permissions.disableAutoMode가 "disable"로 지정되어 있지 않아야 합니다. Team·Enterprise에서는 관리자가 이 값을 조직 설정으로 배포했을 수 있습니다.
실습 전에는 프로젝트 의존성을 설치하고, 기존 테스트 명령으로 반복해서 재현되는 실패 테스트가 하나 있는 저장소를 준비하세요. 실패 테스트가 없다면 코드를 일부러 망가뜨리지 말고, 팀에서 이미 수정 대상으로 정한 테스트 저장소를 사용하면 됩니다.
- Claude Code와 테스트 저장소를 준비합니다.
아직 설치하지 않았다면 공식 Quickstart에서 운영체제에 맞는 설치 방법을 선택하세요. 설치 후claude --version으로 확인하고, 준비한 프로젝트 디렉터리에서claude를 실행해 로그인합니다. - 실패를 먼저 직접 재현합니다.
저장소에 정의된 테스트 명령을 실행해 같은 테스트가 반복해서 실패하는지 확인하세요. 이때 실행한 명령과 실패한 테스트 이름을 기록합니다. 의존성 누락이나 외부 서비스 장애처럼 코드 수정으로 해결할 문제가 아니라면 다른 테스트를 선택합니다. - 새 세션에서 Auto를 선택합니다.
CLI에서는Shift+Tab으로 권한 모드를 순환해 상태 표시줄에auto mode on이 나타나는지 확인합니다. 데스크톱과 VS Code에서는 입력창 주변의 모드 선택기에서 Auto를 고릅니다. - 재현한 실패 하나만 맡깁니다.
“방금 실행한 테스트 명령에서 실패한 테스트 하나의 원인을 분석하고, 최소한의 코드 수정으로 고친 뒤 같은 명령을 다시 실행해 주세요. 커밋, 푸시, 배포, 외부 서비스 전송은 하지 마세요”라고 입력합니다. - 성공 여부와 차단 기록을 함께 봅니다.
같은 테스트 명령이 성공하고git diff에 해당 실패를 고치는 데 필요한 변경만 남았는지 확인하세요. 작업이 막혔다면/permissions의 Recently denied에서 차단 항목을 찾고, 즉시 우회하기보다 요청 범위와 신뢰 경계를 더 좁혀 다시 시도합니다.
같은 세션에서 연속 3회 또는 누적 20회 차단되면 오토모드는 일시 중지되고 수동 승인 프롬프트로 돌아갑니다. 사용자가 작업을 승인하면 오토모드가 재개됩니다. 비대화형 실행에서는 승인 창으로 전환되지 않으며, 해당 작업을 실행하지 않고 다른 작업을 계속합니다.
