이 기사를 통해 얻을 수 있는 것

• 「조사 계열 명령의 승인을 제로로 만드는」 설정(허가 목록 방식)과, 「야간 배치로 기사 생성 → 커밋(Commit) → push → PR 생성까지 무인으로 돌리는 것」 사이에 존재했던 간극
• claude --help를 실제로 읽고 찾아낸, 허가 목록 방식과는 별개의 권한 모드(--permission-mode, --dangerously-skip-permissions) - 왜 그것을 평소 사용하는 환경에서 그대로 사용하는 것이 위험한지, 어떻게 안전하게 사용해야 하는지

이전에, 【복사 붙여넣기 OK】 Kiro/Claude Code의 「신뢰할 수 있는 명령(Trusted Commands)」 설정으로 조사 작업의 승인을 완전 자동화한다는 기사를 작성했습니다. 이 설정을 넣으면 야간 배치도 완전 무인으로 돌아갈 것이라고 생각했지만, 실제로는 push 전후에서 멈췄습니다. 그 원인을 조사한 기록입니다.

배경: 「돌아갈 줄 알았던 것」이 돌아가지 않았다

과거에 공개한 기사에서는 grep / cat / git log와 같은 **읽기 전용 명령(Read-only command)**을 .claude/settings.json의 permissions.allow에 등록하여, 조사 작업의 승인을 20회에서 0회로 줄이는 내용을 소개했습니다.

이를 베이스로 하여, 「Zenn/Qiita의 트렌드를 조사하여 기사를 쓰고, 커밋(Commit)하여 push하고 PR을 만드는」 일련의 작업을 야간에 무인으로 돌리려고 시도했으나, git push나 gh pr create 직전에서 멈추거나, 허가 목록에 추가해도 세션 중에는 반영되지 않는 현상에 직면했습니다.

원인: 허가 목록은 처음부터 쓰기 계열 명령을 대상에서 제외하고 있었다

과거 기사의 허가 목록을 다시 살펴보니, 의도적으로 아래 항목들을 제외하고 있었습니다.

• git push / git commit / gh pr create
• 파일의 신규 생성 및 수정을 동반하는 명령 전반

이는 안전성을 우선시한 설계로, 「읽기 전용 조사 작업」의 승인 피로를 해소하는 것이 목적이었습니다. 쓰기를 동반하는 완전 무인화는 애초에 해당 기사의 스코프(Scope) 밖이었던 것입니다. 「한 번 설정하면 모든 조사 태스크에서 효과를 발휘한다」라고는 썼지만, 「모든 작업이 무인화될 수 있다」라고는 쓰지 않았던 것이 실상 이었습니다.

claude --help를 다시 읽고 찾아낸 것

실제로 설치되어 있는 claude 명령의 도움말(Help)을 확인한 결과, 허가 목록(permissions.allow / deny)과는 별개로 다음과 같은 옵션이 존재한다는 것을 알게 되었습니다.

--permission-mode <mode> Permission mode to use for the session
(choices: "acceptEdits", "auto", "bypassPermissions", "manual", ...

즉, 허가 목록은 「개별 명령 패턴을 화이트리스트(Whitelist)화 하는」 레이어이고, --dangerously-skip-permissions / --permission-mode bypassPermissions는 「그 레이어 자체를 스킵하는」 레이어입니다. 양자는 서로 다른 것이었습니다.

저의 .claude/settings.json은 defaultMode: "acceptEdits"로 되어 있었는데, 이는 파일 편집(Edit/Write) 확인을 자동 승인하는 모드이며, 허가 목록에 없는 Bash 명령의 확인까지 면제해주지는 않습니다. 「acceptEdits로 설정했는데도 멈추는 것」은 애초에 보고 있는 레이어가 달랐기 때문이라는 결론에 도달했습니다. 도식화하면 다음과 같은 관계입니다.

과거 기사의 허가 목록(grep / cat / git log 등)은 도식에서 말하는 「E: allow에 일치」하는 가지(Branch)만을 충실히 채운 것이었습니다. git push나 gh pr create는 거기에 등록되어 있지 않았기 때문에 「H: 매번 확인」으로 떨어졌고, 야간 배치는 거기서 멈춰 있었던 것입니다.

왜 평소 환경에서 그대로 사용하지 않는가

--dangerously-skip-permissions는 공식 도움말에 "Recommended only for sandboxes with no internet access"(인터넷 접속이 없는 샌드박스에서만 권장됨)라고 명시되어 있습니다.

평소 사용하는 머신에서 이를 활성화하면, 예를 들어 작업 중에 읽어들인 웹 페이지나 리포지토리(Repository)의 내용에 악의적인 지시가 심어져 있는 경우(프롬프트 인젝션 (Prompt Injection)), 이를 의심 없이 실행해 버릴 위험이 있습니다. 허가 목록(Allowlist) 방식이 '무엇을 허용할지'를 인간이 사전에 결정하는 메커니즘인 반면, 풀 바이패스(Full Bypass)는 '에이전트의 판단을 전적으로 신뢰하는' 메커니즘이므로 리스크의 성격이 다릅니다.

안전하게 무인화하려면, 이라는 설계 방침

Zenn의 트렌드를 보다가 발견한 「PC를 닫아도 Kiro / Claude Code는 계속 움직인다 — EC2 + tmux로 24시간 개발 (AWS Japan 공식)」이 이 과제에 대한 하나의 해답이 될 것 같았습니다. EC2 인스턴스 위에서 tmux를 사용하여 Kiro/Claude Code를 계속 구동시킨다는 내용입니다.

생각하는 방식은 다음과 같습니다.

• 메인 머신(평소 사용하는 머신)에서는 --dangerously-skip-permissions를 사용하지 않는다.
• 일회용으로 사용할 수 있는 격리 환경(네트워크나 IAM 권한을 제한한 EC2 인스턴스 등)을 준비한다.
• 해당 격리 환경 안에서만 bypassPermissions를 사용한다. 망가지거나 폭주하더라도 피해 범위가 해당 환경 내에 머물도록 한다.

이 구성은 아직 구현하지 않았습니다. 다음 할 일로 남겨두었습니다. 구현하게 되면, 실제로 야간 배치(Nightly Batch)가 끝까지 무인으로 돌아갔는지 여부를 포함하여 별도의 글로 작성할 예정입니다.

요약

• 「허가 목록으로 승인을 제로로 만드는」 설정과 「야간 배치를 완전 무인으로 돌리는 것」은 서로 다른 권한 레이어의 문제였다.
• claude --help를 통해 확인한 바로는, 완전한 바이패스에는 --permission-mode bypassPermissions 또는 --dangerously-skip-permissions가 필요하다.
• 단, 공식적으로 「샌드박스 한정」이라고 명시되어 있듯이, 평소 사용하는 환경에서 그대로 사용하는 것은 위험하다. 격리 환경과 세트로 사용해야 하는 것이다.
• 격리 환경 구축은 이제부터 시작이다. 다음 실전 편으로 이어진다.

※ 본 기사는 개인 환경(Windows / Claude Code CLI)에서 확인한 내용입니다. claude --help의 출력은 사용 버전 시점의 것이며, 향후 변경될 가능성이 있습니다.

Discussion