팀원이 같은 버전의 코딩 에이전트를 쓰는데 한 사람에게만 권한 질문이 늘거나 금지한 파일을 읽는 일이 생길 수 있다. 원인은 모델보다 설정 계층, 개인 지침, 자동 메모리의 차이인 경우가 많다. 저장소의 공용 파일만 같다고 실행 조건까지 같은 것은 아니다.
버전 선별과 단계 배포는 이 시리즈의 007번 글에서 다뤘다. 여기서는 기능이 활성화된 출처를 찾아 팀 기준과 개인 실험이 어긋나는 ‘설정 드리프트’를 추적한다. 핵심 산출물은 기능 목록이 아니라 현재 실행 조건을 다시 만들 수 있는 설정 지문이다.
1. 증상을 받으면 실행 지문부터 고정한다
문제가 난 세션을 닫기 전에 도구 버전, 실제 모델과 공급자, 저장소 머리 SHA, 운영체제, 시작 디렉터리와 실행 명령을 적는다. 이어 불러온 설정 계층, 프로젝트 지침 파일의 SHA, auto memory 사용 여부를 기록한다. 프롬프트만 복사해서는 같은 실행을 재현할 수 없다.
지문은 비밀값을 담는 로그가 아니다. API 키와 토큰은 제외하고 파일 경로, 키 이름, 값의 해시나 마스킹된 값만 남긴다. 문제가 없는 팀원의 지문도 같은 양식으로 받아 두 기록의 첫 차이부터 조사한다.
2. 설정 키마다 출처와 병합 방식을 적는다
Claude Code 설정 우선순위는 관리 정책, 명령행, 로컬 프로젝트, 공유 프로젝트, 사용자 설정 순이다. 그러나 permissions.allow 같은 배열은 높은 계층이 낮은 계층을 통째로 덮지 않고 합쳐진다. 공식 설정 문서에서 우선순위와 병합 예외를 확인한다.
/status의 Setting sources는 어떤 계층이 로드됐는지만 보여 주며 각 키의 최종값과 출처까지 계산해 주지는 않는다. 관련 파일을 직접 대조해 키 | 실효값 | 기여한 출처 | 소유자 | 변경일 표를 만든다. 예컨대 프로젝트에서 읽기 권한을 줄였어도 사용자 설정의 허용 배열이 합쳐졌다면 그 항목까지 표에 남겨야 한다.
3. 지침과 자동 메모리를 설정 파일과 함께 본다
공유 기준은 버전 관리되는 .claude/settings.json과 CLAUDE.md에 둔다. 개인 실험은 .claude/settings.local.json에 두고 공용 기준으로 보고하지 않는다. 지침은 권한을 강제하는 설정이 아니므로 “비밀 파일을 읽지 말라”는 문장만 쓰지 말고 실제 permissions.deny도 확인한다.
auto memory는 기기 로컬이지만 같은 Git 저장소의 하위 디렉터리와 모든 worktree가 하나의 메모리 디렉터리를 공유한다. 따라서 새 worktree만 만들어서는 격리되지 않는다. 공식 메모리 안내처럼 실험 전에 auto memory를 끄고 새 세션을 열거나 별도 저장소를 사용한다. 사용자 범위의 autoMemoryDirectory를 바꿨다면 그 경로도 지문에 적는다.
4. 변경 카드는 상태와 원복 동작까지 가진다
변경 카드는 PROPOSED → LOCAL_TRIAL → SHARED_PENDING → ACTIVE로 이동한다. 끝난 항목은 ROLLED_BACK이나 RETIRED로 닫는다. 카드에는 변경 표면, 이전값과 새 값, 정확한 출처, 담당자, 만료일, 확인 과제와 원복 명령을 적는다.
원복은 표면마다 다르다. 버전은 지정 버전으로 되돌린 뒤 claude --version을 확인하고, 모델·공급자는 해석된 선택값을 복구한다. 공유 설정과 지침은 해당 커밋을 되돌리며, 사용자·로컬 설정은 기록한 파일을 복원한다. 관리 정책은 관리자가 원복하고, auto memory는 스냅샷을 보관한 뒤 수정·비활성화한다. 마지막으로 새 세션에서 같은 확인 과제를 실행한다.
매주 활성 카드와 설정 지문을 대조하면 조용히 쌓인 개인 예외를 찾을 수 있다. 좋은 팀 표준은 모두가 같은 화면을 보는 문서가 아니라, 서로 다른 결과가 나왔을 때 어느 계층의 어떤 변화가 원인인지 되짚을 수 있는 기록이다.