오토 모드(Auto Mode) – 승인 대신 분류기가 검사하는 구조

오토 모드(Auto Mode)는 Claude Code가 행동할 때마다 사용자에게 승인을 묻는 대신, 별도의 분류기(Classifier) 모델이 실행 전에 그 행동을 검토하게 하는 권한 모드(Permission Mode)입니다. 공식 문서에 따르면 Claude Code v2.1.283부터는 플랜과 관계없이 터미널과 VS Code 대화형 세션이 이 모드로 시작돼요. 이전 버전에서는 Pro, Max, Team 플랜에만 기본 적용되던 방식이었습니다.

기본으로 작동하는 권한 체계인 만큼 내부에서 어떤 판정이 일어나는지 알아둘 가치가 있습니다. Anthropic은 2026년 3월 25일 엔지니어링 블로그에 오토 모드의 설계 아키텍처를 공개했습니다. 내부 동작과 실제 측정 수치가 상세히 실려 있어 공식 문서와 함께 분석했습니다.

승인 피로와 오토 모드의 출발점

Claude Code는 원래 터미널 명령을 실행하거나 파일을 수정하기 전 매번 승인을 요청합니다. Anthropic의 설계 글은 바로 이 지점에서 출발해요. 승인 팝업이 반복되면 사용자가 내용을 꼼꼼히 확인하지 않고 관성적으로 수락하는 승인 피로(Approval Fatigue)가 발생하기 때문입니다.

글에 따르면 사용자는 승인 요청의 무려 93%를 무비판적으로 수락하는 경향을 보였습니다. 지금까지의 선택지는 양극단에 가까웠어요. 도구를 환경 격리하는 샌드박스(Sandbox)는 안전하지만 도구가 늘어날 때마다 복잡한 설정이 필요하고, 승인을 전부 끄는 무승인 플래그는 편리하지만 위험한 행동에 대한 최소한의 방어선마저 사라집니다.

Anthropic은 직접 승인과 무방비 상태 사이에 지능형 검사 계층을 배치했습니다. 의도 파악에 특화된 모델 기반 분류기에 사전 검토를 위임해, 사용자의 작업 맥락을 벗어난 위험 행동은 막아내고 일상적인 개발 작업은 중단 없이 흐르도록 설계한 것입니다.

권한 모드 여섯 가지 가운데 오토 모드의 자리

공식 문서는 권한 모드를 “세션에서 Claude가 묻지 않고 실행할 수 있는 행동의 범위를 정하는 규칙”으로 정의합니다.

공식 문서의 여섯 가지 권한 모드를 핵심 용도별로 대조하면 다음과 같습니다.

터미널 작업 중에는 Shift+Tab 단축키를 눌러 권한 모드를 손쉽게 전환할 수 있습니다. 오토 모드 상태에서 Shift+Tab을 누르면 가장 보수적인 default로 즉시 바뀌며, 이후 누를 때마다 default -> acceptEdits -> plan 순서로 순환해요. 세션 시작 시점에 직접 지정하려면 터미널에 아래 명령을 입력합니다.

claude --permission-mode auto

권한 모드는 세션의 기본 동작을 결정할 뿐이며, 그 위에 세부 권한 규칙(Rule)을 얹을 수 있습니다. 특히 거부 규칙(Deny Rule)은 bypassPermissions를 포함한 모든 모드에서 최우선으로 적용되어 해당 명령을 차단합니다.

행동 하나가 분류기까지 가는 3단계 판정 순서

오토 모드라고 해서 모든 작업마다 매번 무거운 분류기 모델을 호출하지는 않습니다. Anthropic은 불필요한 지연을 줄이기 위해 판정 과정을 3단계 계층으로 구성했습니다.

첫 번째 계층은 상태 변경이 없는 안전한 도구 목록과 사용자가 사전 정의한 명시적 허용 규칙입니다. 파일 읽기(Read), 검색(Grep/Glob), 코드 탐색 도구는 분류기를 거치지 않고 즉각 통과해요.

두 번째 계층은 현재 작업 중인 프로젝트 디렉토리 내부의 파일 쓰기 및 수정입니다. 저장소 내부의 코드 수정은 Git 같은 버전 관리 도구로 사후 검토와 롤백이 가능하기 때문에 분류기 호출 없이 허용됩니다.

세 번째 계층이 바로 별도의 모델 분류기 검사입니다. 셸(Bash) 명령어 실행, 웹 네트워크 요청, 외부 툴 호출, 서브에이전트 생성, 그리고 프로젝트 폴더 외부 파일 수정 등 시스템 전반에 영향을 줄 수 있는 작업이 이 검사대로 올라갑니다.

분류기가 보는 정보와 프롬프트 인젝션 방어

분류기 계층은 2단계 모델 파이프라인으로 작동합니다. 1단계(Stage 1)는 행동을 막을지 여부를 단 1토큰으로 출력하는 초고속 필터이며, 안전을 위해 기본적으로 차단 방향으로 민감하게 반응하도록 가중치가 설정되어 있습니다. 여기서 위험 신호가 잡힌 행동만 2단계(Stage 2)로 넘어가 심층 추론을 거쳐 최종 판정을 받습니다.

설계에서 눈에 띄는 대목은 분류기 모델에 전달되는 컨텍스트의 격리 방식입니다. 공식 아키텍처에 따르면 분류기에는 오직 사용자의 지시문, 에이전트의 도구 호출 명세, 그리고 저장소의 CLAUDE.md 파일만 입력됩니다.

이렇게 컨텍스트를 분리한 이유는 명확합니다. 에이전트가 “사용자가 앞선 대화에서 암묵적으로 허가했다”는 식의 유려한 설명을 붙여 분류기를 기만하는 현상을 막기 위함입니다. 또한 도구 실행 결과물을 배제함으로써 외부 웹페이지나 감염된 문서에 숨겨진 프롬프트 인젝션(Prompt Injection) 공격이 분류기 판정을 오염시키지 못하도록 원천 차단했습니다. 즉, 에이전트가 한 말이 아니라 실제 수행하려는 행동 자체만 평가받도록 만든 셈입니다.

도구 실행 결과물에 담긴 위험 요소는 클라이언트 분류기가 아니라 독립된 서버 측 인젝션 탐지기가 전담합니다. 도구 실행 결과에서 시스템 가로채기 패턴이 탐지되면 에이전트의 다음 턴 컨텍스트에 보안 경고를 주입하여 위험을 환기합니다. 분류기 검사 모델은 현재 최신 Claude Sonnet 5 기반으로 동작하며, 사용자가 세션에서 /model 명령으로 선택한 개발용 주 모델과는 완전히 독립적으로 구동됩니다.

기본으로 막는 행동과 claude auto-mode defaults

오토 모드의 분류기는 기본적으로 현재 프로젝트 폴더와 세션 시작 시 지정된 원격 Git 저장소만을 안전지대로 간주합니다. 별도의 신뢰 설정을 주지 않는 한 모든 외부 인프라는 잠재적 위험 구역으로 분류돼요.

터미널에서 claude auto-mode defaults 명령을 실행하면 내장된 JSON 규칙 명세를 직접 열람할 수 있습니다. 대표적으로 다음과 같은 위험 행동들이 기본 차단 대상으로 정의되어 있습니다.

• curl | bash처럼 원격 스크립트를 내려받아 파이프로 즉시 실행하는 명령
• 시스템 환경 변수나 SSH 키 등 민감 정보를 외부 엔드포인트로 전송하는 통신
• 운영(Production) 환경 대상의 배포 파이프라인이나 DB 마이그레이션 실행
• S3 버킷이나 클라우드 데이터베이스 등 원격 인프라의 대량 삭제 조작
• 세션 시작 전부터 존재하던 로컬 중요 파일을 비가역적으로 강제 삭제하는 행위
• Git 저장소 대상의 강제 푸시(git push --force)

대화 중에 사용자가 내린 자연어 지시도 판정에 실시간 반영됩니다. 예를 들어 “운영 서버에는 배포하지 마”라거나 “푸시는 내가 직접 확인할게”라고 지시하면 분류기가 이를 강력한 차단 신호로 해석해요. 이 지시는 이후 대화에서 사용자가 명시적으로 해제하기 전까지 유지되며, Claude가 임의로 판단해 무력화할 수 없습니다.

반대로 차단된 명령을 대화로 허용할 때는 구체적인 대상을 명시해야 합니다. “강제 푸시해도 돼”처럼 일반적인 표현만으로는 분류기의 빗장이 풀리지 않으며, 대상 브랜치나 원격 저장소를 구체적으로 지목해야 승인으로 인정받습니다.

막히면 멈추지 않고 다른 길을 찾는다 (서킷 브레이커)

분류기가 특정 행동을 차단했다고 해서 전체 세션이 즉시 중단되지는 않습니다. 차단 신호는 구체적인 거부 사유와 함께 에이전트에게 도구 실패 형태로 반환되며, Claude는 위험한 명령을 우회하려 시도하지 않고 더 안전한 대안 경로를 찾아 작업을 이어갑니다.

만약 Claude가 안전한 대안을 찾지 못하고 위험 행동을 반복하면 내장된 서킷 브레이커(Circuit Breaker)가 발동합니다. 공식 문서 기준으로 연속 3회 또는 단일 세션 누적 20회 이상 차단이 누적되면 오토 모드가 멈추고 사용자에게 직접 승인 여부를 묻습니다. 이 기준 수치는 환경설정으로 임의 수정할 수 없습니다.

차단된 행동 내역은 /permissions 명령의 ‘최근 거부(Recent Rejections)’ 탭에 기록되며, 개발자가 내용을 확인한 뒤 수동으로 승인하여 즉시 재실행할 수 있습니다. 서브에이전트를 호출할 때도 하위 작업 프롬프트 사전 검토, 실행 중 개별 명령 실시간 검사, 작업 종료 후 결과 보고서 최종 검토의 3중 방어선이 동일하게 적용됩니다.

Anthropic이 공개한 실측 평가 지표와 현실적인 한계

Anthropic 엔지니어링 팀은 설계 글을 통해 실제 환경에서 오토 모드 분류기 파이프라인을 검증한 3대 벤치마크 평가 결과를 공개했어요.

공개된 실측 지표는 아래 표와 같습니다.

단독 1단계 필터만 구동했을 때는 정상 작업을 불필요하게 가로막는 오탐률이 8.5%에 달했지만, 2단계 심층 추론 필터를 결합해 일상 작업 방해율을 0.4% 수준으로 낮췄습니다.

하지만 17%라는 미탐률 수치에 대해 Anthropic은 상당히 솔직한 평가를 덧붙였습니다. 승인 요청을 아예 꺼두고 개발하던 사용자에게는 안전망이 대폭 보강되는 셈이지만, 모든 명령을 한 줄씩 수동 검토하던 개발자 기준에서는 잠재적 위험이 존재한다는 의미입니다. 즉, 오토 모드는 사람의 최종 검토를 대체하는 완전무결한 방패가 아니라, 일상적인 승인 피로를 덜어주는 현실적인 보조 장치로 이해해야 합니다.

내 프로젝트 규칙 파일(CLAUDE.md)에 적용하는 방법

프로젝트 루트의 규칙 파일(CLAUDE.md)을 활용하면 오토 모드의 자율 작업 범위를 팀 정책에 맞춰 엄격하게 통제할 수 있습니다.

- `./wc push`는 항상 임시글(draft) 상태로만 업로드한다. `--publish`는 사용자가 명시 지시했을 때만 허용한다.
- 가드 검사 오류 발생 시 우회 스크립트를 작성하지 않고 원고 본문을 직접 수정한다.

분류기는 매 판정 시마다 CLAUDE.md의 내용을 지침으로 참조하므로, 저장소의 민감한 작업 규칙을 문서화해두면 모델이 이를 인지하고 차단 결정을 내립니다.

특정 명령에 대해 반드시 사람의 육안 승인을 강제하고 싶다면 settings.json이나 권한 설정에 permissions.ask 규칙을 명시하면 됩니다. 패턴에 매칭된 명령은 오토 모드 상태라 하더라도 분류기를 건너뛰고 항상 대화창에 승인 팝업을 띄웁니다. AI 하네스 설계에서 살펴본 것처럼, 도구에 자율성을 위임하되 핵심 경계선에는 명시적 검증 장치를 심어두는 접근이 중요합니다.

글에 나온 규칙 파일과 에이전트는 Claude Code에서 쓰는 방식이고, 공식 안내는 Claude Code 공식 문서에 있습니다.

이 글은 직접 만들고 운영하며 남긴 기록입니다. 적힌 수치는 작성 시점의 제 계정 기준이며, 같은 결과나 수익을 보장하지 않습니다.