Claude Code를 처음 도입한 팀이 공통적으로 겪는 패턴이 있다. 초반엔 생산성 향상에 흥분하다가, 두 주쯤 지나면 두 가지 불만이 동시에 터진다. 첫째, "승인 창이 너무 많이 떠서 집중이 안 된다." 둘째, "토큰을 너무 빨리 소진한다." 이 두 문제를 방치하면 Claude Code는 팀 표준 도구가 되지 못하고 파워유저 몇 명의 개인 장난감으로 전락한다.
최근 dev.to에 올라온 두 편의 글이 이 문제를 서로 다른 레이어에서 정면으로 다룬다. 하나는 .claude/settings.json을 이용한 권한 설계 가이드고, 다른 하나는 15개 에이전트와 17개 훅으로 구성된 자율 파이프라인 오픈소스 프로젝트(claude-god-mode)다. 두 글을 겹쳐 읽으면 Claude Code를 팀 표준으로 안착시키기 위한 설정 레이어와 자동화 레이어가 각각 무엇을 담당하는지 윤곽이 잡힌다.
설정 레이어: 승인 피로를 구조적으로 제거한다
settings.json의 핵심 아이디어는 단순하다. "반복적으로 승인하는 명령어는 미리 허용하고, 파괴적인 명령어만 게이트를 남긴다." git *, npm *, pip *, docker * 같이 개발 루틴에서 수십 번 호출되는 명령어를 allow 리스트에 올려두면 Claude가 멀티스텝 작업을 승인 없이 처리할 수 있다. 결과적으로 "프롬프트 → 승인 → 프롬프트 → 승인"의 리듬이 깨지고, Claude는 비로소 제대로 된 자율 실행 단위로 동작하기 시작한다.
그런데 이 설정이 팀 도구로서 진짜 가치를 발휘하는 지점은 따로 있다. .claude/settings.json은 프로젝트 디렉토리에 귀속된다. 이 파일을 레포에 커밋하면 팀원 전원이 동일한 권한 베이스라인에서 출발한다. 더 이상 "나는 승인했는데 왜 CI에서 막히지?" 같은 환경 불일치 이슈가 생기지 않는다. 설정 파일 하나가 온보딩 문서 역할까지 겸하는 셈이다.
다만 여기서 냉정하게 짚어야 할 게 있다. python3 *와 git * 같은 와일드카드 패턴은 생각보다 넓다. git push --force origin main과 git status가 같은 패턴으로 허용된다. 글에서도 솔직하게 인정하듯, 이 설정은 "개발 속도를 위한 실용적 선택"이지 보안 기본값이 아니다. 팀 레포에 적용할 때는 rm, curl, sudo를 명시적으로 exclude 목록에 올리고, 공유 레포일수록 git 서브커맨드를 git status, git add, git commit 수준으로 좁히는 게 맞다.
자동화 레이어: 품질 게이트를 코드로 박아넣는다
dev.to의 claude-god-mode 프로젝트는 차원이 다른 문제를 건드린다. 설정 레이어가 "Claude가 실행할 수 있는 것"을 다룬다면, 자동화 레이어는 "Claude가 생성한 결과물의 품질"을 다룬다. 이 프로젝트가 진단한 AI 코딩의 세 가지 근본 문제—토큰 과소비, 연결되지 않는 코드, 가짜 테스트—는 솔직히 모든 Claude Code 팀이 어느 시점에 한 번씩 부딪히는 것들이다.
17개의 훅(Hook)이 흥미로운 이유는 CLAUDE.md 규칙과의 비교에 있다. CLAUDE.md에 "destructive 명령어 쓰지 마"라고 써봤자 Claude는 상황에 따라 무시할 수 있다. 훅은 그렇지 않다. rm -rf나 git reset --hard를 기계적으로 차단하고, --no-verify로 git 훅을 우회하는 것도 막는다. 규칙이 아니라 메커니즘이다. 이 차이는 팀 운영 측면에서 크다. 사람이 리뷰하지 않아도 파이프라인 자체가 품질 게이트 역할을 한다.
15개 에이전트 중 실무적으로 가장 주목할 건 Integration Enforcer와 Test Authenticator다. Integration Enforcer는 새로 작성한 파일이 어디서도 import되지 않으면 "완료"를 차단한다. Test Authenticator는 mock만 잔뜩 쌓아놓고 실제 기능은 검증하지 않는 가짜 테스트를 잡아낸다. 이 두 에이전트가 겨냥하는 문제—코드는 짜지만 연결되지 않는 AI의 고질병—는 토큰 절약보다 훨씬 근본적인 품질 이슈다. 60~99% 토큰 절약이라는 숫자는 마케팅처럼 들릴 수 있지만, 이 두 품질 게이트만으로도 도입을 검토할 이유가 충분하다.
팀 표준화를 위한 실전 순서
두 레이어를 팀에 도입하는 순서는 이렇게 보는 게 현실적이다. 먼저 settings.json부터 시작한다. 이건 설정 파일 하나고, 학습 곡선이 없으며, 레포 커밋 한 번으로 팀 전체에 적용된다. 반복 승인이라는 즉각적인 마찰을 없애면서 팀이 Claude Code의 자율 실행 감각을 익히게 한다. 이 단계에서 팀 피드백을 모아 어떤 명령어 패턴이 추가로 필요한지, 어떤 패턴이 너무 넓은지 조정한다.
그 다음에 자동화 레이어를 얹는다. claude-god-mode를 그대로 가져다 쓰든, 일부만 참조해 팀 컨벤션에 맞게 훅을 직접 작성하든, 방향은 동일하다. "규칙이 아니라 메커니즘으로 품질을 강제한다." 전체 15개 에이전트를 한꺼번에 운영하는 건 팀에 따라 오버킬일 수 있다. Integration Enforcer와 Test Authenticator, 그리고 시크릿 스캐닝 훅 정도만 먼저 도입해도 AI 코딩의 가장 흔한 품질 구멍 두 개를 틀어막을 수 있다.
Claude Code를 팀 표준으로 만드는 건 결국 개인의 프롬프트 실력 문제가 아니다. 어떤 명령어를 허용할지 정의하는 설정 레이어와, AI가 생성한 결과물을 자동으로 검증하는 자동화 레이어—이 두 레이어를 코드로 관리할 때 Claude Code는 비로소 팀 인프라가 된다. 내일 당장 .claude/settings.json 하나 만들어 레포에 올리는 것부터 시작해도 충분히 가치 있다.