Claude Code MCP와 `.claude/rules/`로 팀별 AI 도구 접근 권한을 선언적으로 분리하는 방법

AI 코딩 도구를 팀 전체에 도입하려다 보면 생각보다 빨리 이런 고민에 부딪히게 됩니다. "백엔드 개발자한테는 DB 접근이 필요한데, 프론트엔드 개발자가 실수로 DROP TABLE을 날리면 어떡하지?" 저도 처음엔 그냥 모든 팀원에게 동일한 MCP 서버 설정을 뿌려놨습니다. 그러다 어느 날 스테이징 DB 스키마가 예상치 못하게 바뀌는 경험을 한 번 겪고 나서야 제대로 권한 분리를 고민하게 됐죠.

문제는 생각보다 복잡한 데 있었습니다. AI가 어떤 경로에서 어떤 작업을 할 때 어떤 도구에 접근할 수 있는지를 체계적으로 설계해야 했습니다. "이 팀은 이 도구 못 써"라는 단순한 규칙이 아니라, 파괴적인 명령을 날릴 가능성 자체를 아예 닫아버리는 구조가 필요했습니다. 처음엔 어디서 시작해야 할지도 막막했고, 설정 파일을 만들어놨더니 어느 계층에서 어떤 규칙이 적용되는지 파악하는 것도 쉽지 않았습니다.

Claude Code는 settings.json의 권한 블록과 .claude/rules/의 팀별 규칙 파일을 조합해, 팀·역할별 MCP 도구 접근 권한을 파일 시스템 수준에서 선언적으로 관리할 수 있는 구조를 제공합니다. 이 글에서는 그 구조가 어떻게 동작하는지, 어디서 막히는지, 그리고 운영하면서 흔히 저지르는 실수가 무엇인지를 다룹니다. 이 글을 다 읽고 나면, MCP 권한 판정이 어떤 우선순위로 동작하는지 이해하고, 백엔드·프론트엔드·DevOps 팀을 위한 권한 파일을 직접 구성할 수 있을 겁니다.

핵심 개념

MCP란 무엇이고, 왜 권한 관리가 필요한가

MCP(Model Context Protocol)는 Anthropic이 2024년 11월에 공개한 오픈 표준입니다. 한마디로, AI가 외부 도구나 데이터 소스에 접근하는 방식을 USB-C처럼 단일 규격으로 통일한 것입니다. GitHub, PostgreSQL, Slack, AWS 같은 서비스들을 각각 다른 방식으로 연결할 필요 없이, MCP 서버 하나로 연결 방식을 표준화합니다.

문제는 이 강력함이 그대로 위험 요소가 된다는 점입니다. AI가 외부 시스템에 접근할 수 있다는 뜻은, 잘못 설정하면 AI가 프로덕션 DB를 날리거나, Slack에 의도치 않은 메시지를 보내거나, AWS 인스턴스를 종료할 수도 있다는 의미입니다. 그래서 MCP 도구에 누가, 어떤 조건에서 접근할 수 있는지를 명확하게 설계하는 것이 팀 도입의 핵심 과제가 됩니다.

MCP 도구 식별 형식: Claude Code에서 MCP 도구 권한은 mcp__<서버명>__<도구명> 형태로 표현합니다. 예를 들어 mcp__github__list_issues는 GitHub MCP 서버의 list_issues 도구를 가리킵니다. 와일드카드(*)로 서버 전체를 허용하거나 차단하는 것도 가능합니다.

settings.json과 .claude/rules/의 역할 구분

이 부분이 처음엔 가장 헷갈렸는데, 둘의 역할을 명확히 구분하면 전체 구조가 훨씬 명확해집니다.

settings.json 이 실제로 MCP 권한을 집행하는 파일입니다. permissions.allow와 permissions.deny 블록으로 어떤 도구를 허용하고 차단할지 선언합니다.

.claude/rules/ 는 MCP 권한을 직접 제어하지 않습니다. 이 디렉터리 안의 *.md 파일들은 Claude Code가 프로젝트 컨텍스트에 따라 선택적으로 로드하는 규칙 파일들로, 팀별 작업 지침과 맥락을 AI에게 주입합니다. 각 파일 상단에 globs 패턴을 지정하면, 그 경로의 파일을 다룰 때만 해당 규칙이 활성화됩니다.

---
globs: ["src/server/**", "src/api/**"]
---
백엔드 개발 컨텍스트입니다.
데이터베이스 마이그레이션 전 반드시 팀장 승인을 받으세요.

중요한 점은, 이 규칙 파일이 활성화된다고 해서 도구 접근이 자동으로 제한되지는 않는다는 겁니다. settings.json의 deny 규칙이 없으면 도구 접근은 막히지 않습니다. 두 가지를 함께 써야 비로소 "이 경로에서 작업할 때는 이 도구만 쓸 수 있다"는 구조가 완성됩니다.

권한 판정 우선순위

권한이 충돌할 때 어떤 규칙이 이기는지 알아야 설계를 제대로 할 수 있습니다. 우선순위는 아래 계층 구조를 따릅니다.

Managed Settings  ← 중앙 관리자 설정 (최강)
    └── User Settings  ← 개별 사용자 설정
            └── Project Settings  ← 프로젝트 전체 설정
                    └── Local Settings  ← 개인 로컬 설정 (최약)
 
충돌 시: deny > ask > allow  (첫 번째 매칭 규칙이 승리)

deny 규칙은 계층 구조와 무관하게 항상 allow보다 강력합니다. 보안 팀장이 managed-settings.json으로 잠근 도구는 개발자가 아무리 로컬 설정을 뒤져봐도 소용없다는 뜻입니다. 이 구조가 엔터프라이즈 환경에서 특히 유용한 이유이기도 합니다.

실전 적용

예시 1: 팀별 디렉터리 구조 설계

실무에서 가장 먼저 해야 할 일은 .claude/ 디렉터리 구조를 팀 구조에 맞게 설계하는 것입니다.

.claude/
├── settings.json           # 프로젝트 전체 공유 (Git 커밋)
├── settings.local.json     # 개인 설정 (.gitignore)
├── rules/
│   ├── backend.md          # 백엔드 팀 맥락·작업 지침
│   ├── frontend.md         # 프론트엔드 팀 맥락·작업 지침
│   └── devops.md           # DevOps 팀 맥락·작업 지침
└── managed-mcp.json        # 관리자 전용 (예시 3 참고)

settings.json은 Git에 커밋해서 팀 전체가 공유하고, settings.local.json은 개인 오버라이드 용도로 .gitignore에 추가해두는 것이 기본 패턴입니다.

예시 2: 팀별 MCP 권한 설정 (settings.json)

각 팀의 역할에 맞게 허용/차단 규칙을 선언합니다. 단일 저장소에서 여러 팀이 함께 작업하는 경우, 팀별로 별도 저장소를 운영하거나 팀별 브랜치에 각자의 settings.json을 두는 방식이 일반적입니다. 단일 settings.json 안에서 팀을 분기하는 기능은 현재 지원되지 않으므로, 모노레포 환경이라면 가장 제한적인 공통 설정을 기본값으로 두고 팀별 확장은 별도 저장소로 분리하는 방향을 검토해볼 수 있습니다.

백엔드 팀:

{
  "permissions": {
    "allow": [
      "mcp__postgres__query",
      "mcp__postgres__schema",
      "mcp__github__*",
      "mcp__slack__read_message"
    ],
    "deny": [
      "mcp__postgres__drop_table",
      "mcp__slack__send_message",
      "mcp__aws__terminate_instance"
    ]
  }
}

프론트엔드 팀:

{
  "permissions": {
    "allow": [
      "mcp__playwright__*",
      "mcp__github__get_pull_request",
      "mcp__github__list_issues",
      "mcp__figma__*"
    ],
    "deny": [
      "mcp__postgres__*",
      "mcp__aws__*",
      "mcp__slack__send_message"
    ]
  }
}

처음 이 설정을 구성할 때 가장 고민했던 부분이 "프론트엔드 팀한테 GitHub 전체를 줘도 되나?"였습니다. 결국 읽기 관련 도구만 명시적으로 허용하고 나머지는 필요할 때 추가하는 방식을 택했는데, 이 방향이 훨씬 안전했습니다.

DevOps 팀:

{
  "permissions": {
    "allow": [
      "mcp__aws__*",
      "mcp__gcp__*",
      "mcp__github__*",
      "mcp__atlassian__*"
    ],
    "deny": [
      "mcp__postgres__drop_table"
    ]
  }
}

예시 3: 엔터프라이즈 중앙 배포 (managed-mcp.json)

이 예시는 100명 이상 규모 조직을 위한 설정입니다. 소규모 팀이라면 예시 2까지로도 충분합니다.

규모가 큰 조직이라면 개발자가 임의로 MCP 서버를 추가하는 것을 원천적으로 차단하고 싶을 겁니다. 이때 활용할 수 있는 방식이 MDM(Mobile Device Management)으로 managed-mcp.json을 배포하는 것입니다.

MDM은 회사 IT 부서가 기기 전체에 설정을 일괄 배포하고 관리하는 방식입니다. 이 메커니즘을 활용하면 Claude Code 설정도 중앙에서 강제할 수 있습니다.

경로를 정확히 구분해야 합니다. 프로젝트 내 .claude/managed-mcp.json과 MDM으로 배포하는 시스템 전체 경로는 별개입니다. macOS 기준 시스템 전체 적용 경로는 아래와 같습니다.

/Library/Application Support/ClaudeCode/managed-mcp.json
/Library/Application Support/ClaudeCode/managed-settings.json

이 경로의 파일은 프로젝트 단위 설정보다 우선 적용되며, IT 부서가 MDM으로 배포하면 기기 전체에 강제됩니다.

managed-mcp.json 예시:

{
  "mcpServers": {
    "github": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"],
      "env": {
        "GITHUB_TOKEN": "${GITHUB_TOKEN}"
      }
    },
    "postgres": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-postgres", "${DATABASE_URL}"]
    }
  }
}

${DATABASE_URL} 같은 환경 변수 참조는 배포 시 IT 부서가 각 기기에 환경 변수를 별도로 설정해야 작동합니다. 이 파일이 배포되면 공식 문서에 따라 개발자의 ~/.claude/settings.json에서 추가한 MCP 서버는 무시되고 승인된 서버 목록만 동작합니다. 배포 전 서버 목록을 꼼꼼히 검토하는 것이 중요한 이유입니다.

예시 4: OAuth 2.1 스코프 기반 세분화

이 섹션은 OAuth 2.1에 익숙한 독자를 위한 내용입니다. OAuth가 처음이라면 이 섹션은 건너뛰어도 됩니다.

2025년 6월 MCP 스펙 업데이트로 MCP 서버가 OAuth 2.1 Resource Server로 분류되면서, 스코프 기반 접근 제어도 가능해졌습니다. 이때 스코프는 콜론(:)으로 구분하는 형식을 사용합니다.

mcp:tools:weather                   # 날씨 도구만 접근
mcp:resources:customer-data:read    # 고객 데이터 읽기 전용
mcp:exec:workflows:*                # 워크플로우 전체 실행 권한

앞서 소개한 mcp__github__list_issues처럼 언더스코어(__)로 구분하는 형식은 Claude Code 내부에서 도구를 식별하는 레이어입니다. 콜론으로 구분하는 형식은 OAuth 인증 서버와 MCP 서버 간의 스코프 협상 레이어로, 같은 도구를 다른 계층에서 다른 방식으로 표현하는 것입니다. 둘을 혼동하지 않는 것이 중요합니다.

서버가 WWW-Authenticate 헤더에 scope 파라미터를 명시하면 클라이언트가 필요 이상의 권한을 요청하는 것을 방지할 수 있습니다. 다만 아직 모든 MCP 서버가 이 스펙을 완전히 구현한 것은 아니기 때문에, 실제 도입 전에 사용하려는 서버의 OAuth 구현 수준을 먼저 확인해보는 것이 좋습니다.

장단점 분석

장점

단점 및 주의사항

Claude Code Enterprise는 RBAC(Role-Based Access Control) 기능을 제공하지만, 현재 Cowork, 웹 검색, 메모리 등 6개 고수준 기능만 제어합니다. MCP 서버 접근이나 개별 도구 권한은 직접 제어하지 않기 때문에, 이 글에서 설명한 settings.json 권한 블록을 병행 관리해야 합니다.

Prompt Injection: AI 모델이 외부 도구에서 가져온 콘텐츠 안에 숨겨진 악의적 명령을 실행하도록 유도하는 공격입니다. MCP 환경에서는 외부 서버가 응답에 악성 지시를 심어 토큰이나 세션 정보를 탈취하려 시도할 수 있습니다.

실무에서 가장 흔한 실수

1. deny 없이 allow만 정의하는 경우 — 명시적으로 허용한 도구 외에는 기본적으로 차단될 것이라고 가정하지만, 설정 구조에 따라 상위 레이어에서 허용된 도구가 그대로 상속될 수 있습니다. 위험한 도구는 반드시 명시적으로 deny에 추가해두는 것이 안전합니다.

2. managed-mcp.json 배포 전 검토 생략 — 이 파일 하나로 모든 개발자의 기존 MCP 설정이 교체됩니다. 배포 전 스테이징 환경에서 충분히 검증하고, 사전에 팀에 공지하는 과정을 거치는 것이 좋습니다.

3. settings.local.json을 Git에 커밋하는 실수 — 개인 설정 파일에 API 토큰이나 내부 서버 URL이 담겨있는 경우가 많습니다. .gitignore에 settings.local.json이 등록되어 있는지 프로젝트 초기에 확인해두는 것을 권장합니다.

마치며

MCP와 .claude/rules/의 조합은 AI 도구를 팀 전체에 안전하게 확장하기 위한 현실적인 출발점입니다. 완벽한 RBAC 시스템은 아직 성숙하는 중이지만, 지금 당장 settings.json의 deny 블록 몇 줄만 추가해도 사고 위험을 크게 줄일 수 있습니다.

지금 바로 시작할 수 있는 3단계:

1. MCP 서버 현황 파악: ~/.claude/settings.json을 열어 연결된 MCP 서버 목록을 확인하고, 위험 도구를 팀과 분류합니다.
2. deny 목록 정의: "이 팀이 절대 써선 안 되는 도구가 뭔가?"라는 질문에서 시작합니다. mcp__postgres__drop_table, mcp__aws__terminate_instance 같은 파괴적 도구부터 차단 목록에 올립니다.
3. 팀별 rules 파일 작성: .claude/rules/ 아래에 팀별 *.md 파일을 만들고 globs 패턴으로 작업 경로를 연결합니다. 권한 설명과 운영 정책을 함께 명시해두면 AI가 작업 맥락을 이해하는 데도 도움이 됩니다.

참고 자료

• MCP 공식 스펙 (2025-11-25) | modelcontextprotocol.io
• MCP Authorization 스펙 | modelcontextprotocol.io
• Claude Code: MCP 연결 공식 문서 | code.claude.com
• Claude Code: 권한 설정 공식 문서 | code.claude.com
• Claude Code: settings.json 레퍼런스 | code.claude.com
• MCP 2025년 6월 인증 스펙 업데이트 분석 | auth0.com
• MCP 11월 인증 스펙 상세 분석 | den.dev
• Claude Code 엔터프라이즈 보안 실무 | truefoundry.com
• Claude Code 권한 5가지 패턴 | DEV Community
• MCP 인증 Claude Code 2026 | truefoundry.com
• Stack Overflow Blog: MCP 인증과 인가 | stackoverflow.blog
• CoSAI MCP 보안 분석 | github.com/cosai-oasis
• MCP Wikipedia | wikipedia.org