Claude Code는 여러 파일에서 설정을 읽어오며, 대부분의 팀은 그중 하나의 설정만 사용합니다. 만약 실수로 자신의 허용 목록(allow-list) 수정 사항을 커밋했거나, 어떤 모델 선택이 저장소에 들어가야 하는지에 대해 논쟁한 적이 있다면, 공유 규칙과 개인 규칙을 분리하는 것이 해결책입니다.
세 가지 파일
~/.claude/settings.json: 사용자 설정을 담고 있으며, 사용자의 컴퓨터에서 실행되는 모든 프로젝트에 적용됩니다..claude/settings.json: 프로젝트 설정을 담습니다. 이 파일을 커밋하면 팀 전체가 동일한 규칙을 갖게 됩니다..claude/settings.local.json: 해당 프로젝트를 위한 개인 설정을 담습니다. Claude Code는 이 파일을 생성할 때 git이 무시하도록 구성하므로, 이 파일은 사용자의 컴퓨터에만 남아있게 됩니다.
동일한 설정이 여러 파일에 나타날 경우, 더 구체적인 설정이 우선합니다: 로컬(local) > 프로젝트(project), 그리고 프로젝트(project) > 사용자(user) 순서입니다. 만약 회사에서 사용하는 관리형 엔터프라이즈 정책(Managed enterprise policy)이 있다면, 이 모든 것보다 상위에 위치합니다.
작동하는 분리 방법
공유 규칙은 .claude/settings.json에 작성합니다:
{
"permissions": {
"allow": ["Bash(npm test:*)", "Bash(git diff:*)"]
...
}
개인 규칙은 .claude/settings.local.json에 작성합니다:
{
"permissions": {
"allow": ["Bash(docker compose up:*")]
...
}
이 방법을 사용하면 팀은 안전장치(safety rails)를 유지하고, 사용자는 풀 리퀘스트(pull request) 없이 추가 명령을 사용할 수 있습니다.
팁
- 거부 규칙(deny rules)은 프로젝트 파일에 넣으세요. 동료의 로컬 파일이
.env 보호 장치가 있어야 할 곳은 아닙니다.
- 만약
settings.local.json 파일을 Claude Code를 통해 생성한 것이 아니라 수동으로 만들었다면, 한 번 .gitignore를 확인하세요.
- Claude Code 내부에서
/permissions를 실행하여 어떤 규칙이 활성화되었고 각각의 규칙이 어디서 왔는지 확인해 보세요.
프로젝트 측 파일과 짧은 CLAUDE.md, 위험한 git hook, 그리고 읽기 전용 검토자 서브 에이전트가 Vildanden Agent Config에 포함되어 배포됩니다. 무료 샘플만으로도 오늘 바로 설정을 완료하기에 충분합니다.