Auto mode가 생긴 이유 — 수동 승인의 민낯

Claude Code의 기본 동작 방식은 파일 쓰기나 셸 명령 실행 전에 매번 사용자 승인을 요청하는 것입니다. 안전해 보이지만, 실제로는 아무도 꼼꼼하게 읽지 않습니다. Anthropic이 내부 직원 세션 데이터를 분석한 결과, 수동 승인 요청의 93%는 그냥 승인 처리됩니다 (출처: Anthropic Engineering Blog, 2026.03.24). 7%만 실제로 검토되는 셈인데, 이건 안전망이 아니라 클릭 피로를 유발하는 형식적 절차에 불과합니다.

그래서 개발자들이 선택한 대안이 --dangerously-skip-permissions 플래그였습니다. 이름 그대로 모든 권한 확인을 건너뜁니다. Anthropic의 내부 인시던트 로그에는 이 플래그 환경에서 발생한 사례가 기록되어 있습니다. 에이전트가 잘못 해석된 명령으로 원격 git 브랜치를 삭제했고, 엔지니어의 GitHub 인증 토큰을 내부 컴퓨팅 클러스터에 업로드했으며, 프로덕션 DB에 마이그레이션을 시도했습니다. 모두 악의가 아닌 “도움이 되려는” 에이전트의 자율 판단에서 비롯된 사고들입니다.

Auto mode는 이 양극단 사이의 중간 경로를 목표로 합니다. 각 액션 전에 별도의 분류기 모델이 검토하고, 안전하면 자동 진행, 위험하면 차단합니다. 출시 트윗은 590만 뷰, 좋아요 3만 7천을 기록했습니다. 사람들이 얼마나 이 문제를 답답해하고 있었는지 보여줍니다.

▲ 목차로 돌아가기

작동 방식: 2단계 분류기 구조와 비용

입력 레이어 + 출력 레이어, 두 겹으로 막습니다

Auto mode는 두 가지 방어 레이어로 구성됩니다. 입력 레이어는 파일 읽기, 웹 가져오기, 셸 출력 같은 툴 결과를 에이전트 컨텍스트에 넣기 전에 프롬프트 인젝션 여부를 서버 측에서 스캔합니다. 악성 주입이 감지되면 에이전트에게 경고를 먼저 보내 원래 사용자 의도에 다시 집중하도록 유도합니다. 출력 레이어는 각 툴 호출이 실행되기 전에 트랜스크립트 분류기(Sonnet 4.6 구동)가 해당 액션을 검토합니다 (출처: Anthropic Engineering Blog, 2026.03.24).

모든 액션이 분류기를 거치지는 않습니다

3단계 결정 구조로 운영됩니다. 1단계는 기본 허용 목록과 사용자 설정 규칙으로 즉시 처리합니다. 2단계는 프로젝트 디렉토리 내 파일 편집을 자동 허용합니다. 3단계만 실제 분류기를 거칩니다. 셸 명령, 웹 요청, 외부 툴 연동, 프로젝트 외부 파일시스템 작업이 여기 해당합니다. 일반적인 코딩 작업(소스 파일 편집 등)은 분류기를 건너뛰기 때문에 지연이 크지 않습니다.

분류기 자체도 토큰을 씁니다 — 비용이 올라갑니다

공식 문서는 명확하게 밝힙니다. “Auto mode는 토큰 사용량, 비용, 지연에 소규모 영향이 있습니다”라고 적혀 있는데, 여기서 ‘소규모’라는 단어는 액션 유형에 따라 달라집니다 (출처: Claude Code 공식 문서 — Permission Modes, 2026.03.24). 분류기는 Sonnet 4.6을 사용하며, 각 검사는 대화 트랜스크립트 일부와 대기 중인 액션을 분류기에 전달합니다. 추가 비용은 주로 셸 명령과 네트워크 요청에서 발생하며, 읽기 전용 작업과 작업 디렉토리 내 파일 편집은 분류기 호출을 트리거하지 않습니다.

▲ 목차로 돌아가기

공식 수치로 본 한계 — 17%가 의미하는 것

Anthropic이 직접 세 가지 데이터셋으로 측정한 결과를 공개했습니다. 이 투명성은 드문 일입니다.

17%라는 숫자의 실제 의미를 짚어봐야 합니다. 에이전트가 사용자가 승인하지 않은 범위를 넘어서는 행동을 시도했을 때, 분류기가 6건 중 1건 꼴로 그냥 통과시킨다는 뜻입니다. 이 실패의 주된 이유는 흥미롭습니다. 분류기가 위험한 액션 자체는 인식합니다. 그런데 대화에서 ‘동의처럼 보이는 증거’를 찾고, 그것이 해당 액션의 실제 범위까지 커버하는지 검증하지 못합니다. “PR 정리해줘”라는 말이 있었어도 그게 force push를 승인하는 건 아닌데, 분류기가 승인처럼 읽어버리는 패턴입니다 (출처: Anthropic Engineering Blog, 2026.03.24). Anthropic은 프롬프트 엔지니어링으로 이 문제를 개선하려 시도했지만 “더 나쁜 결과를 낳지 않는 수정을 아직 찾지 못했다”고 직접 인정합니다.

한 명의 사람이 매번 꼼꼼히 검토한다면 Auto mode보다 나을 수 있습니다. Auto mode가 실질적으로 의미 있는 건 --dangerously-skip-permissions를 쓰던 환경과 비교할 때입니다. 그 비교에서는 분명한 개선입니다.

▲ 목차로 돌아가기

공급망 공격 앞에서 Auto mode는 무력합니다

Auto mode의 기본 허용 목록에는 pip install -r requirements.txt가 포함됩니다. 선언된 의존성 설치는 사용자가 요청한 작업의 일부로 보고 분류기 없이 통과시킵니다. 이 판단 자체는 합리적입니다.

그런데 Auto mode 출시와 같은 시기에 litellm 공급망 공격이 알려졌습니다. 보안 스캐너로 위장한 PyPI 패키지가 SSH 키, 클라우드 자격증명, Kubernetes 시크릿을 탈취했습니다. 월 9,700만 다운로드 규모에서 일어난 일이고, 공격자 코드에 버그가 있어 우연히 발각된 케이스입니다. Auto mode는 이 시나리오에서 아무것도 막지 못합니다. 분류기가 보는 건 pip install -r requirements.txt라는 명령이고, 그 명령이 설치하는 패키지 안에 뭐가 들어있는지는 보지 않습니다.

이건 Auto mode만의 결함이 아닙니다. 결정론적 OS 레벨 샌드박싱도 같은 맹점을 갖습니다. 명령 자체가 아닌 그 명령이 가져오는 것의 전이적 신뢰 체인을 어떤 접근 방식도 완전히 평가할 수 없습니다. 다만 이 한계를 인지하고 있어야 합니다. Auto mode가 “패키지 설치는 안전하다”고 판단하는 환경에서 공급망이 오염되어 있다면, 그 결과는 사용자가 책임져야 합니다.

실측 데이터 탈취 탐지에서 합성 데이터 기준 5.7%의 탐지 실패율이 나온다는 것도 함께 고려할 필요가 있습니다. 이는 정교한 데이터 탈취 시나리오 중 약 6건에 1건 꼴로 통과한다는 뜻입니다 (출처: Anthropic Engineering Blog, 2026.03.24). 민감한 자격증명이 있는 프로덕션 환경이라면 이 숫자를 가볍게 볼 수 없습니다.

▲ 목차로 돌아가기

안전하게 켤 수 있는 환경 조건

Anthropic이 Auto mode와 --dangerously-skip-permissions에 동일하게 붙이는 권고사항은 “격리된 환경에서 사용하라”는 것입니다 (출처: Claude Code 공식 문서 — Permission Modes, 2026.03.24). 이 동일한 권고가 두 모드에 모두 적용된다는 사실이 Auto mode의 위치를 가장 명확하게 보여줍니다. Auto mode가 더 나은 것은 맞지만, 만능이 아닙니다.

✅ Auto mode를 켜도 괜찮은 환경

• 컨테이너, VM, devcontainer 같은 격리된 환경
• 프로덕션 자격증명이 없는 개발 전용 머신
• 실수로 삭제해도 복구 가능한 git 저장소 범위 내 작업
• 장시간 실행이 필요한 리팩토링, 파일 구조 정리 작업
• --dangerously-skip-permissions를 이미 사용 중이던 파이프라인

⛔ Auto mode를 켜면 안 되는 환경

• 실제 클라우드 자격증명(AWS, GCP, Azure)이 환경 변수에 있는 경우
• 프로덕션 DB에 접근 가능한 환경
• 공유 인프라에 영향을 줄 수 있는 CI/CD 파이프라인
• 신뢰하지 않는 외부 패키지를 설치해야 하는 작업

또 한 가지 중요한 점은 세션 내에서 분류기가 3회 연속 또는 총 20회 차단하면 Auto mode가 자동으로 일시 중지되고 수동 승인 모드로 전환됩니다. 비대화형 모드(claude -p)에서는 세션 자체가 종료됩니다. 장시간 실행 파이프라인에서 이 동작을 미리 파악해두지 않으면 예상치 못한 지점에서 작업이 끊깁니다 (출처: Claude Code 공식 문서, 2026.03.24).

▲ 목차로 돌아가기

설정 방법 — Team 플랜 기준 정확한 절차

현재(2026.03.28 기준) Auto mode는 Team 플랜 리서치 프리뷰로 제공됩니다. Enterprise와 API 사용자에게는 며칠 내로 확장 예정이며, Claude Sonnet 4.6 또는 Opus 4.6 모델에서만 작동합니다. Haiku, claude-3 모델군, Bedrock/Vertex/Foundry 서드파티 제공자에서는 사용할 수 없습니다 (출처: Claude Code 공식 문서, 2026.03.24).

관리자 사전 활성화 (필수)

Team/Enterprise 환경에서는 관리자가 먼저 Claude Code 관리자 설정(claude.ai/admin-settings/claude-code)에서 Auto mode를 활성화해야 합니다. 비활성화하려면 관리 설정에서 "disableAutoMode": "disable"을 설정합니다.

CLI에서 활성화하는 방법

# Auto mode 활성화 후 시작
claude --enable-auto-mode
# 시작 후 Shift+Tab으로 모드 순환
# default → acceptEdits → plan → auto 순서로 전환
# (--enable-auto-mode 없이 시작하면 auto는 순환 목록에 나타나지 않음)
# 기본값으로 설정하고 싶다면 settings 파일에 추가
# ~/.claude/settings.json
{
"permissions": {
"defaultMode": "auto"
}
}

VS Code 확장에서 활성화하는 방법

확장 설정에서 Allow dangerously skip permissions 옵션을 먼저 켜야 Auto 모드 선택지가 나타납니다. 이후 세션 내 프롬프트 박스 하단 모드 표시기를 클릭해 Auto로 전환합니다. Desktop 앱은 Settings → Claude Code에서 먼저 토글을 켠 후 세션 내 드롭다운에서 선택합니다.

▲ 목차로 돌아가기

Q&A

▲ 목차로 돌아가기

마치며

Auto mode에서 가장 솔직한 문장은 Anthropic 엔지니어링 블로그에 직접 나옵니다. “Auto mode는 신중한 인간 검토의 대체품이 아닙니다”라고 명시하고, 동시에 “–dangerously-skip-permissions와 비교하면 실질적인 개선”이라고도 인정합니다. 두 문장 모두 사실입니다.

실제로 대부분의 개발자가 수동 승인을 93% 그냥 클릭하고 있었다면, Auto mode는 그 자리를 훨씬 잘 채웁니다. 적어도 분류기는 24시간 집중해서 읽습니다. 하지만 분류기도 AI입니다. 오버이저 액션 6건에 1건, 데이터 탈취 시도 6건에 1건 정도는 놓칩니다. 이 숫자가 용납 가능한지는 어떤 작업을, 어떤 환경에서 돌리느냐에 달려 있습니다.

격리된 개발 환경에서 장시간 코딩 자동화를 돌린다면, 이제 --dangerously-skip-permissions를 고집할 이유가 없습니다. 프로덕션 자격증명이 있는 머신에서라면, 이 기능은 아직 쓰지 않는 것이 맞습니다. Anthropic도 같은 말을 합니다.

본 포스팅 참고 자료

1. ① Anthropic 공식 블로그 — Auto mode for Claude Code (2026.03.24): https://claude.com/blog/auto-mode
2. ② Anthropic Engineering Blog — Claude Code Auto Mode 기술 문서 (2026.03.24): https://www.anthropic.com/engineering/claude-code-auto-mode
3. ③ Claude Code 공식 문서 — Permission Modes (2026.03.24): https://code.claude.com/docs/en/permission-modes