Claude Code 상세 사용법 48: 설정과 권한을 팀 규칙으로 고정하기 | DAKER 커뮤니티

Claude Code 상세 사용법 48: 설정과 권한을 팀 규칙으로 고정하기

Claude Code를 팀에서 쓰기 시작하면 질문은 “프롬프트를 어떻게 잘 쓰나”에서 “어떤 일을 자동으로 허용할 것인가”로 바뀝니다. 공식 settings 문서는 ~/.claude/settings.json, .claude/settings.json, .claude/settings.local.json, managed settings, --settings의 계층을 설명합니다. 오늘은 이 계층을 클로드 코드 팀 운영의 control plane으로 쓰는 방법입니다.

먼저 파일 역할을 나눈다

팀 공통 규칙은 repo 안의 .claude/settings.json에 둡니다. 개인 실험은 .claude/settings.local.json에 둡니다. 회사 정책은 managed settings가 있으면 그 위에서 잠깁니다.

{
  "$schema": "https://json.schemastore.org/claude-code-settings.json",
  "permissions": {
    "allow": [
      "Bash(npm run lint)",
      "Bash(npm run test *)"
    ],
    "deny": [
      "Read(./.env)",
      "Read(./.env.*)",
      "Read(./secrets/**)",
      "Bash(curl *)"
    ]
  }
}

핵심은 “Claude를 믿는다”가 아니라 “반복 작업은 열고, 비밀과 외부 side effect는 닫는다”입니다. 바이브코딩도 운영 환경에서는 권한 설계가 먼저입니다.

권한은 세 칸으로 설계한다

allow에는 매일 돌리는 검증 명령만 넣습니다. 예를 들어 lint, unit test, 타입체크입니다. ask나 기본 prompt 영역에는 패키지 설치, DB migration, 배포처럼 사람이 봐야 하는 작업을 남깁니다. deny에는 .env, credential 파일, 알 수 없는 네트워크 호출을 둡니다.

공식 permissions 문서는 read-only Bash 명령 일부가 프롬프트 없이 실행될 수 있고, devbox run, docker exec, npx 같은 wrapper 명령은 내부 명령까지 구체적으로 허용해야 안전하다고 설명합니다. Bash(devbox run *)처럼 넓은 규칙은 실제로는 위험합니다.

설정이 안 먹을 때의 순서

Claude Code가 규칙을 무시하는 것처럼 보이면 바로 프롬프트를 고치지 말고 로딩 상태를 확인하세요.

/status       활성 settings source 확인
/permissions  최종 allow/deny 규칙 확인
/context      CLAUDE.md, skills, MCP가 들어왔는지 확인
/doctor       schema 오류와 설치 상태 확인

settings 문서 기준으로 대부분의 설정 변경은 실행 중에도 reload되지만, 일부 key는 새 세션에서 적용됩니다. 따라서 팀 규칙을 바꾼 뒤에는 /status로 source를 보고, 이상하면 새 세션에서 다시 확인하는 습관이 필요합니다.

선임 엔지니어 takeaways

Claude Code, 클로드 코드, agentic coding을 팀 생산성 도구로 쓰려면 프롬프트보다 설정 계층이 먼저입니다. .claude/settings.json은 코드 리뷰 가능한 운영 정책이고, .claude/settings.local.json은 개인 실험장입니다. 민감 파일 deny, 반복 테스트 allow, wrapper 명령 최소화, /doctor 검증까지 묶으면 AI 코딩이 개인 요령이 아니라 팀의 LLM 개발 워크플로우가 됩니다.

참고: Claude Code 공식 settings, permissions, debug configuration 문서를 기준으로 작성했습니다.