7.1팀 단위 도구와 환경 표준화

조직 단위로 도구를 배포할 때 가장 먼저 이해해야 할 것은 설정이 여러 계층에서 오고, 충돌하면 무엇이 이기는가입니다. Claude Code의 설정 우선순위는 높은 쪽부터 다음과 같습니다.

1. 관리형(managed) 설정 — 조직이 배포하는 정책. 원칙적으로 하위에서 덮어쓸 수 없습니다.
2. 명령줄 인자 — 해당 세션에만 적용되는 임시 지정
3. 로컬 프로젝트 설정 — 저장소 루트의 .claude/settings.local.json
4. 공유 프로젝트 설정 — .claude/settings.json, 저장소에 커밋되어 팀이 공유
5. 사용자 설정 — ~/.claude/settings.json, 개인 환경

여기서 주의할 예외가 하나 있습니다. 권한 규칙은 단순 덮어쓰기가 아니라 계층 간에 병합됩니다. 상위 계층이 하위 계층의 권한 설정을 통째로 대체하는 것이 아니라 규칙이 합쳐지므로, 조직이 차단 규칙을 배포하면 프로젝트나 개인이 허용 규칙을 추가하더라도 차단이 유지됩니다.

이 성질이 표준화 설계의 핵심입니다. 조직은 금지선을 관리형 계층에 두고, 개인과 팀은 그 안에서 자유롭게 자기 설정을 얹습니다. 반대로 조직이 허용 목록까지 촘촘히 관리하려 들면 팀마다 다른 작업 방식과 충돌하며 지속적인 예외 요청을 낳습니다.

시험에서는 "이 설정이 적용되는가"를 묻는 판별 문제가 나옵니다. 우선순위와 함께 권한만 병합된다는 예외를 기억해 두십시오.

표준화 범위를 정하는 기준은 "일관성이 주는 이득이 자율성을 제한하는 비용보다 큰가"입니다. 실무에서 갈리는 지점을 정리하면 다음과 같습니다.

중앙에서 강제할 것

• 보안 경계 — 비밀 파일 읽기 차단, 외부로 데이터를 내보내는 명령 차단
• 되돌릴 수 없는 작업의 확인 요구 — 배포, 강제 푸시, 운영 데이터 조작
• 관측 설정 — 사용량과 비용을 조직 차원에서 집계하기 위한 텔레메트리
• 승인된 외부 연결 목록 — 어떤 MCP 서버와 외부 도구를 붙일 수 있는가

팀과 개인에게 맡길 것

• 개인 메모리와 작업 습관
• 프로젝트별 관례와 코딩 규칙
• 개인용 슬래시 명령어와 별칭
• 편집기 통합과 화면 구성

경계가 모호한 것이 하나 있습니다. 모델 선택입니다. 비용 관점에서는 중앙 통제가 매력적이지만, 작업 성격에 따라 적합한 모델이 달라 일률 지정은 품질을 떨어뜨립니다. 실무에서는 상한만 정하고(예산·최대 등급) 선택 자체는 맡기는 절충이 흔합니다.

기억할 원칙은 금지는 좁고 명확하게, 허용은 넓게입니다. 금지 목록이 길어질수록 우회 동기가 커집니다.

정책을 정했다면 그것을 수백 대의 장비에 실제로 도달시켜야 합니다. Claude Code는 여러 배포 경로를 제공합니다.

• 관리형 설정 파일 — 운영체제별 정해진 경로에 managed-settings.json을 둡니다. macOS는 /Library/Application Support/ClaudeCode/, Linux와 WSL은 /etc/claude-code/, Windows는 C:\Program Files\ClaudeCode\ 입니다.
• 드롭인 디렉터리 — managed-settings.d/ 아래에 10-telemetry.json, 20-security.json처럼 조각으로 나누어 둘 수 있습니다. 정책을 주체별로 분리해 관리할 때 유용합니다.
• 서버 관리 설정 — 관리 콘솔을 통해 원격으로 배포합니다.
• MDM과 OS 정책 — macOS 속성 목록이나 Windows 레지스트리 정책으로 배포합니다.

드롭인 방식이 운영상 특히 편리합니다. 보안팀과 플랫폼팀이 각자의 파일을 소유하면 한 파일을 두고 충돌할 일이 없고, 변경 이력도 주체별로 남습니다.

// managed-settings.d/20-security.json — 보안팀 소유
{
  "permissions": {
    "deny": [
      "Read(./.env)",
      "Read(./.env.*)",
      "Bash(curl *)"
    ],
    "ask": ["Bash(git push --force *)"]
  }
}

배포 후에는 실제로 적용되었는지 확인하는 수단이 필요합니다. 정책을 배포했다는 사실과 장비에 적용되었다는 사실은 다르며, 신규 입사자 장비나 예외적으로 구성된 개발 환경에서 누락되기 쉽습니다. 다음 수업에서 다룰 관측 설정이 이 확인의 기반이 됩니다.

표준화 실패는 대개 기술이 아니라 설계 판단의 문제입니다. 전형적인 세 가지를 알아 두십시오.

과잉 차단으로 인한 우회 — 금지 목록이 넓어 일상 작업이 막히면 사람들은 도구를 우회합니다. 개인 계정으로 옮겨 가거나, 정책이 적용되지 않는 환경에서 작업합니다. 이때 조직은 통제력을 얻은 것이 아니라 관측 가능성을 잃습니다. 정책 밖에서 벌어지는 일은 보이지 않기 때문입니다.

예외 경로 부재 — 정당한 예외는 항상 생깁니다. 예외를 신청하고 승인받는 경로가 없으면 사람들은 예외를 만들지 않고 그냥 우회합니다. 예외 경로 설계는 통제를 느슨하게 만드는 것이 아니라, 예외를 보이는 곳에서 처리하게 만드는 장치입니다.

변경 없는 정책 — 처음 정한 목록을 그대로 두면 시간이 지나며 현실과 어긋납니다. 정책에도 재검토 주기가 필요하고, 차단 규칙 중 실제로 발동한 적 없는 항목은 재검토 대상입니다.

정책 건강성 점검 항목
- 최근 90일간 한 번도 발동하지 않은 차단 규칙: 필요성 재확인
- 예외 신청 상위 항목: 정책이 현실과 어긋나는 지점
- 정책 미적용 장비 비율: 배포 경로의 구멍
- 우회 정황(개인 계정 사용 등): 과잉 차단의 신호

마지막 항목이 가장 중요합니다. 우회가 늘고 있다면 통제를 더 조일 것이 아니라 왜 우회하는지를 먼저 확인해야 합니다. 대개는 정책이 실제 작업을 막고 있다는 뜻입니다.