Claude Code 보안 가이드: 권한, MCP, 샌드박싱

전통적인 챗봇은 API 뒤에서 동작하기 때문에 최악의 경우 할루시네이션을 일으키는 정도입니다. 하지만 AI 코딩 에이전트는 리포지토리, 터미널, (흔히) 클라우드 자격 증명 안으로 들어가며, 과거에 "챗봇"이라 부르던 것보다 훨씬 특권이 있는 개발 환경에 더 가까워집니다.

문제는 속도를 늦추지 않고 Claude Code를 어떻게 안전하게 사용할 것인가입니다. 권한 설정, MCP 제어, 그리고 적절히 조정한 샌드박싱이 그 해답입니다.

이 글에서는 Claude Code의 보안 모델이 실제로 어떻게 작동하는지, 어디에 주의를 기울여야 하는지, 의도한 범위를 넘지 않는 선에서 유용하게 사용하는 방법을 안내합니다.

Claude와 Claude Code가 완전히 처음이라면, 무료 Claude Code 101 코스를 수강해 오후 한 번에 기본기를 익히세요.

Claude Code 보안 모델 이해하기

단 하나의 규칙을 조정하기 전에, Claude Code가 실제로 무엇을 통제하는지에 대한 개념 모델이 필요합니다.

핵심 요소는 다섯 가지입니다. 허용 범위를 결정하는 권한 시스템, 개별 기능 범위를 지정하는 도구 접근 제어, 외부 통합을 위한 MCP 권한, OS 수준 격리를 위한 샌드박싱, 사후 검토를 위한 감사 가능성. 각각이 다른 문제를 해결하지만 서로 겹겹이 쌓입니다.

권한 시스템

권한 시스템은 정적 레이어입니다.

settings.json에서 세 가지 목록 allow, ask, deny를 사용해 Claude가 무엇을 할 수 있는지 선언합니다. 규칙은 deny → ask → allow 순으로 평가되며, 먼저 일치하는 규칙이 우선합니다. 더 넓은 allow 규칙과 일치하더라도 deny 규칙이 있으면 호출이 차단됩니다.

일치하는 규칙이 없으면, Claude는 세션의 defaultMode로 돌아갑니다(모드에 대해서는 다음 섹션에서 다룹니다).

도구 접근 제어

권한은 에이전트 전체가 아니라 도구에 부여됩니다.

Claude Code에는 자체 내장 도구가 있습니다. 예를 들어 셸 명령을 위한 Bash, 파일 시스템 작업을 위한 Read, Edit, Write, HTTPS 요청용 WebFetch, 검색용 WebSearch 등이 있습니다. 각 규칙은 도구 이름과 (선택적으로) 괄호 안 지정자를 사용해 Bash(git commit:*) 또는 Read(./.env)처럼 작성합니다.

이는 최소 권한 원칙을 가능하게 합니다. 예를 들어 테스트를 위해 Bash(npm run:*)만 허용하고, Claude에 전체 셸 접근 권한을 주지 않을 수 있습니다.

MCP 권한

MCP 서버는 Claude Code에 원래 설계에 없던 도구들을 확장 제공합니다.

각 서버는 자체 도구 세트를 가지고 옵니다(예: GitHub 서버는 PR 도구, 데이터베이스 서버는 쿼리 도구 등). 권한 시스템은 MCP에도 적용되지만 문법이 다릅니다. 괄호 지정자 대신 mcp__servername__toolname 형식을 사용합니다.

기억할 점은 MCP가 질문을 거의 두 배로 만든다는 사실입니다. 셸에서 무엇을 할 수 있는지뿐만 아니라, 연결한 모든 외부 시스템에서 무엇을 할 수 있는지도 결정해야 합니다.

샌드박싱

샌드박싱은 Bash 도구 아래에서 동작하는 OS 수준의 안전장치입니다.

권한 규칙은 Claude가 무엇을 해야 하는지 알려줍니다. 샌드박싱은 운영체제 수준에서 파일 시스템 접근과 외부 네트워크 호출을 제한해, Claude가 실제로 할 수 있는 일을 강제합니다. macOS에서는 Seatbelt를 통해 기본 제공됩니다. Linux와 WSL2에서는 먼저 bubblewrap과 socat을 설치해야 합니다.

두 레이어는 비슷하게 작동하지만 시나리오가 다릅니다. 권한은 Claude가 시도하는 것을 막고, 샌드박싱은 프롬프트 인젝션으로 Claude가 시도하도록 유도돼도 그 시도가 성공하지 못하게 합니다.

감사 가능성

마지막 요소는 무슨 일이 일어났는지 볼 수 있는 능력입니다.

/permissions 명령은 모든 활성 규칙과 각 규칙이 소속된 설정 파일을 나열해, "왜 Claude가 그걸 실행했지?"라는 질문에 답할 수 있게 합니다. 훅(PreToolUse, PostToolUse 등)을 통해 모든 도구 호출을 자체 시스템에 로깅할 수 있습니다. 팀 환경에서는 OpenTelemetry 내보내기를 통해 사용량과 도구 호출 데이터를 기존 관측 스택으로 보낼 수 있습니다.

Claude Code 권한 및 접근 제어

안전의 대부분은 권한 설정에서 비롯되므로, 이 부분을 가장 많이 조정하게 됩니다.

파일 접근

기본적으로 Claude는 실행한 디렉터리의 파일을 읽고 수정할 수 있습니다.

읽기는 Read 도구가, 수정은 Edit과 Write가 담당합니다. 각각 괄호 안에 경로 패턴을 gitignore 스타일로 받습니다. 예를 들어 Read(**/.env)는 모든 깊이의 .env 파일과 일치하고, Edit(src/**)는 src/ 아래의 모든 항목과 일치합니다.

Read에 대한 deny는 Claude Code의 자체 파일 도구(Read, Grep, Glob, LS)에 적용되지만, 최선의 시도일 뿐입니다. Bash를 통해 실행되는 Python 또는 Node 스크립트는 여전히 파일을 열 수 있습니다. 이는 해당 읽기가 Claude의 Read 도구가 아니라 셸을 통해 발생하기 때문입니다. 비밀이 중요하다면, Read deny에 더해 해당 경로에 대한 cat, head, tail을 Bash에서 deny로 결합하세요.

작업 디렉터리 밖으로 접근을 확장하려면 settings.json의 additionalDirectories를 사용하세요. 이를 통해 리포 외부의 공유 라이브러리나 홈 디렉터리의 설정 파일에 대한 접근을 허용하면서, 작업 디렉터리 경계를 완전히 해제하지 않을 수 있습니다.

명령 실행

Bash 도구는 가장 신중하게 범위를 지정해야 하는 도구입니다.

제한 없는 Bash 규칙은 모든 명령을 허용합니다. Bash(npm run:*)처럼 범위를 지정하면 일치하는 호출만 허용됩니다. 여기서는 콜론-별 패턴을 사용해야 하며, Claude Code는 셸 연산자를 이해하므로 Bash(safe-cmd:*) 규칙은 safe-cmd && rm -rf /와 일치하지 않습니다.

일부 명령은 기본적으로 읽기 전용으로 처리되어 모든 모드에서 프롬프트 없이 실행됩니다. 목록에는 ls, cat, echo, pwd, head, tail, grep, find, wc, which, diff, stat, du, cd, 그리고 읽기 전용 형태의 git이 포함됩니다. 이 목록을 수동으로 줄일 수는 없지만, 해당 명령들에 대해 ask 또는 deny 규칙을 추가해 기본값을 재정의할 수 있습니다.

사전 승인되지 않은 모든 항목에 대해서는 기본 모드에서 Claude가 프롬프트를 표시합니다. 프롬프트는 정확한 명령을 보여 주며, 한 번 승인, 패턴과 일치하는 향후 모든 호출 승인, 거부 중에서 선택할 수 있습니다.

권한 모드

권한 규칙은 정적이지만, 권한 모드는 일치하지 않는 호출의 동작을 변경합니다.

다섯 가지가 있습니다:

• default: 각 도구의 첫 사용 시 프롬프트를 표시합니다.

• acceptEdits: 작업 디렉터리의 파일 수정은 자동 승인하고, 셸 명령은 계속 통제합니다. 수정은 신뢰하지만 셸은 신뢰하지 않을 때 유용합니다.

• plan: Claude가 읽고 분석만 하며, 파일 수정이나 명령 실행은 불가합니다. 코드 리뷰나 계획 수립에 적합한 모드입니다.

• dontAsk: allow 목록에 명시되지 않은 모든 항목을 자동 거부합니다.

• bypassPermissions: 모든 프롬프트를 건너뜁니다. 컨테이너나 VM 같은 완전히 격리된 환경에서만 안전합니다.

세션 중에는 Shift+Tab으로 세 가지 주요 모드를 순환할 수 있으며, settings.json에서 기본 모드를 선택할 수도 있습니다:

{
  "permissions": {
    "defaultMode": "acceptEdits",
    "deny": ["Read(**/.env)", "Read(**/.env.*)"]
  }
}

팀 환경에서는 관리형 설정을 통해 사용자가 변경할 수 없는 레이어를 제공합니다. 파일 형식은 동일한 JSON이며, 시스템 경로에 위치합니다:

• /Library/Application Support/ClaudeCode/managed-settings.json (macOS)

• /etc/claude-code/managed-settings.json (Linux)

• C:\ProgramData\ClaudeCode\managed-settings.json (Windows)

관리형 설정의 deny 규칙은 해당 머신의 모든 프로젝트에 적용됩니다. 이를 통해 조직 전반에 "아무도 .env 파일을 읽지 않는다" 또는 "아무도 bypassPermissions를 실행하지 않는다"와 같은 규칙을 강제할 수 있습니다.

이 모든 것의 원칙은 최소 권한입니다. 어떤 서비스 계정에나 적용하는 원칙과 같습니다. 

작업을 수행하는 데 필요한 최소 권한으로 시작하고, 벽에 부딪힐 때만 범위를 넓히세요. Anthropic의 가이드도 같은 방향을 제시합니다. Claude가 만든 변경 사항을 검토하고, /permissions로 규칙을 감사하며, 프로젝트별 설정을 버전 관리에 체크인해 팀이 Claude의 작업 범위에 합의하도록 하세요.

Claude Code 샌드박싱

Claude의 자율 실행을 더 허용할수록 샌드박싱의 필요성은 커집니다.

셸 명령은 사용자가 읽을 수 있는 모든 파일을 읽고, 쓰기 권한이 있는 모든 것을 수정할 수 있으므로 Bash 도구의 노출 범위가 가장 큽니다. 샌드박싱은 모든 Bash 명령과 그 자식 프로세스에 OS 수준 경계를 강제해, 경계 내부에서는 각 호출을 승인하지 않고도 Claude가 더 자유롭게 실행될 수 있게 합니다. Anthropic은 보다 안전한 자율 실행을 지원하기 위해 이를 내장했습니다.

주의할 점은 샌드박스가 Bash와 그 자식 프로세스에만 적용된다는 것입니다. Read, Edit, Write 도구에는 제한을 두지 않으며, 이들은 계속 권한 시스템을 통과합니다.

네이티브 샌드박싱

네이티브 샌드박스는 Claude Code에 내장되어 있으며 /sandbox로 활성화합니다.

macOS에서는 기본 Seatbelt 프레임워크를 사용하므로 설치할 것이 없습니다. Linux와 WSL2에서는 파일 시스템 격리를 위한 bubblewrap, 네트워크 프록시를 위한 socat를 설치합니다. 네이티브 Windows는 지원되지 않으므로, 대신 WSL2 배포판 내에서 Claude Code를 실행해야 합니다.

파일 시스템 경계는 이해하기 쉽습니다. 읽기는 거부된 경로를 제외한 모든 곳에서 가능하고, 쓰기는 작업 디렉터리와 허용한 추가 경로에서만 가능합니다. 샌드박스 내부에서 ~/.bashrc에 쓰기를 시도하면 Claude가 실패를 알기도 전에 "Operation not permitted"가 발생합니다.

네트워크 경계는 다소 다릅니다. 아웃바운드 트래픽은 샌드박스 외부에서 실행되는 프록시 서버를 통해 라우팅되며, 모든 요청을 allowedDomains 목록과 대조합니다. 새 도메인은 대신 권한 프롬프트를 트리거하므로, Claude가 정확히 무엇에 접근하려는지 확인할 수 있습니다.

작동 예시는 다음과 같습니다:

{
  "sandbox": {
    "enabled": true,
    "autoAllowBashIfSandboxed": true,
    "filesystem": {
      "allowWrite": ["/workspace", "/tmp"],
      "denyRead": ["~/.aws", "~/.ssh"]
    },
    "network": {
      "allowedDomains": ["github.com", "*.npmjs.org"]
    }
  }
}

Anthropic 내부 사용 기준으로, 샌드박싱은 권한 프롬프트를 84% 줄여줍니다.

개발 컨테이너

개발 컨테이너는 격리를 한 단계 더 강화합니다.

Anthropic은 Claude Code용 참조 devcontainer를 제공합니다. Ubuntu 환경을 구성하고, 리포를 마운트하며, 에이전트에 작업용 셸을 제공합니다. 네이티브 샌드박싱 대비 장점은 재현성입니다. 팀원 모두가 동일한 도구와 동일한 설정의 동일한 환경을 갖게 됩니다.

단점은 오버헤드입니다. 

컨테이너 빌드, 파일 마운트, (가끔은) 느린 피드백 루프가 추가됩니다. 단일 개발자에게는 네이티브 샌드박스만으로 충분한 경우가 많습니다. 팀 또는 CI 용도라면 이 구성이 그만한 가치가 있습니다.

Docker 기반 격리

장시간 자율 에이전트 세션의 경우, Docker로 샌드박싱 경계를 더 넓힐 수 있습니다.

일반적인 구성은 다음과 같습니다:

• 최소 베이스 이미지: 작업에 불필요한 패키지 관리자와 네트워크 도구를 제거합니다.
• 비루트 사용자: Claude는 루트로 실행되지 않아 시스템 파일을 수정하거나 전역 패키지를 설치할 수 없습니다.
• 읽기 전용 루트 파일 시스템: 컨테이너 루트를 읽기 전용으로 마운트하고, 특정 출력 디렉터리만 쓰기 가능하게 합니다.
• Egress 프록시: 아웃바운드 네트워크를 프록시로 라우팅해 패키지 레지스트리(npm, PyPI)는 허용하고 그 외는 차단합니다. 그래서 npm install은 동작하지만 임의의 curl은 동작하지 않습니다.
• 리소스 제한: CPU, 메모리, I/O 제한을 설정해 단일 프로세스가 호스트를 다운시키지 못하게 합니다.

Docker Sandboxes는 각 샌드박스에 전용 마이크로VM과 독립 Docker 데몬을 제공합니다. 호스트 데몬은 docker ps에서도 샌드박스를 볼 수 없습니다. 경계는 컨테이너보다는 VM에 가깝기 때문에, 개발자들이 우려하는 컨테이너 이스케이프 경로 대부분을 차단합니다.

엔터프라이즈 샌드박싱 전략

조직에서는 샌드박스 기술을 사용할지 여부가 아니라, 어떻게 계층화할지가 핵심입니다.

대부분 다음과 같이 접근합니다:

• 권한 규칙은 managed-settings.json에 두어 개별 개발자가 변경하지 못하게 합니다.

• 권한 레이어 아래에서 네이티브 샌드박싱을 실행합니다.

• 그 아래에 Dev 컨테이너 또는 Docker를 실행합니다.

• 최고 신뢰 시나리오(프로덕션 접근, 비밀 관리)에서는 호스트 파일 시스템 마운트가 없는 전용 VM이 마지막 레이어가 됩니다.

웹용 Claude Code는 같은 개념의 관리형 버전입니다. 각 세션은 Anthropic이 관리하는 VM에서 실행되며, git 토큰 같은 민감한 자격 증명은 샌드박스 외부의 프록시에 배치되고, 경계는 인프라로 강제됩니다.

Claude Code의 MCP 보안

MCP는 Claude Code에서 가장 빠르게 성장하는 영역입니다.

연결하는 MCP 서버마다 Claude가 할 수 있는 일이 대폭 늘어나지만, 프롬프트 인젝션이나 손상된 의존성이 도달할 수 있는 표면도 늘어납니다. 

예를 들어:

• GitHub MCP 서버는 Claude에 PR 접근 권한을 부여합니다.
• 데이터베이스 MCP 서버는 스키마와 쿼리에 접근하게 합니다.
• Slack 서버는 채널에 접근하게 합니다.

그 자체로 문제는 아니지만, MCP에는 별도의 거버넌스가 필요하다는 뜻입니다. MCP 도구를 통해 가져온 콘텐츠(웹 페이지나 API 응답)에는, Claude가 사용자가 입력한 것처럼 실행할 수 있는 지시가 주입되어 있을 수 있습니다. 또한 각 서버는 별도로 관리해야 하는 자격 증명과 인증 경로를 추가합니다.

도구 권한

MCP 도구는 내장 도구와 다른 명명 규칙을 사용합니다.

규칙 형식은 괄호 지정자 없이 mcp__servername__toolname입니다. 예를 들어 mcp__github__create_pull_request는 해당 도구 호출만 정확히 허용하며, mcp__github__delete_repo에 대한 deny는 위험한 도구를 차단합니다. Bash나 Read와 마찬가지로 allow, ask, deny 목록이 동일하게 작동합니다.

우선순위 규칙도 동일합니다. 먼저 deny, 그다음 ask, 마지막으로 allow입니다. mcp__github__delete_*에 대한 관리형 설정의 deny는 해당 머신의 모든 프로젝트에 유효합니다.

리소스 권한

MCP 서버는 도구와 함께 리소스를 노출할 수 있습니다.

리소스는 서버가 Claude가 읽을 수 있도록 제공하는 데이터 조각입니다(프로젝트 관리 서버의 파일, 데이터베이스 서버의 행 등). 리소스 접근은 도구 호출과 동일한 신뢰 검사 과정을 거치며, MCP 서버의 최초 연결 시에는 도구와 리소스에 접근하기 전 신뢰 검증 단계를 수행합니다.

기본값으로는 리소스를 또 하나의 도구처럼 취급하는 것이 맞습니다. 자격 증명을 부여하지 않을 것이라면, 리소스 접근도 부여하지 마세요.

승인된 MCP 서버

Anthropic Directory는 Anthropic의 등록 기준에 따라 검토된 커넥터를 나열합니다.

조직에서 좋은 패턴은 내부 허용 목록을 사용하는 것입니다. 다음 두 설정으로 제어할 수 있습니다:

• allowedMcpServers: 개발자가 프로젝트에 추가할 수 있는 서버의 glob 패턴(예: 내부 관리 서버만 허용하려면 company-*).

• deniedMcpServers: 개발자가 시도해도 추가할 수 없는 서버 패턴.

모든 세션에 반드시 포함되어야 하는 서버는 관리형 설정에 위치한 managed-mcp.json 파일로 배포하는 것이 좋습니다. 개발자는 항목을 제거하거나 수정할 수 없습니다.

공유 리포에서 피해야 할 설정은 enableAllProjectMcpServers입니다. 이는 .mcp.json에 정의된 모든 MCP 서버를 자동 승인합니다. 개인 작업에는 편리하지만, 체크인되는 모든 항목에는 위험합니다. 악성 PR이 .mcp.json에 새 서버를 추가해 프롬프트 없이 실행될 수 있기 때문입니다.

최소 권한 도구 접근

Bash 권한과 동일한 원칙을 MCP에 적용합니다.

출발점은 각 서버의 자격 증명이 무엇인지입니다. 데이터베이스 MCP 서버는 쓰기 권한이 있는 프라이머리가 아니라, 읽기 전용 접근의 리드 레플리카에 연결해야 합니다. API MCP 서버는 조직 전체 권한의 개인 토큰이 아니라 필요한 최소 엔드포인트 범위로 제한된 토큰을 사용해야 합니다. 등등.

서브에이전트도 MCP 접근 범위를 지정하는 또 다른 방법입니다. .claude/agents/의 서브에이전트 정의에서 (mcp:<server>:<tool> 문법으로) 접근 가능한 도구를 정확히 선언할 수 있습니다. 예를 들어 "deploy-agent"는 인프라 서버를, "review-agent"는 Read, Grep, Glob만 갖도록 합니다. 에이전트는 부여되지 않은 도구를 호출할 수 없습니다.

MCP 거버넌스

규모 있게 Claude Code를 운영하는 팀이나 조직에는, MCP도 다른 프로덕션 통합과 동일한 거버넌스가 필요합니다.

즉, 승인된 서버의 레지스트리(책임자 지정), 도구 호출의 종단 간 감사 추적(어떤 MCP 도구가, 누가, 어떤 파라미터로 호출했는지), 승인 목록의 주기적 검토가 필요합니다. Claude Code의 OpenTelemetry 내보내기는 기존 관측 스택에 바로 투입 가능한 형식으로 감사 데이터를 제공합니다.

규모가 큰 조직에서는 중앙 집중식 MCP 게이트웨이가 가장 깔끔한 해법입니다. 

개발자는 개별 서버를 등록하는 대신 게이트웨이에 연결합니다. 게이트웨이는 인증을 처리하고, 도구 수준의 역할 기반 접근을 강제하며, 단일 감사 로그를 제공합니다. 또한 자격 증명 난립 문제를 해결합니다. 게이트웨이의 한 세트 자격 증명이 모든 개발자가 모든 API 키 사본을 보유하는 상황을 대체합니다.

시크릿 관리와 민감 데이터

Claude Code는 사용자가 읽을 수 있는 것은 무엇이든 읽을 수 있으므로, 시크릿이 접근 가능해집니다.

기본적으로 Claude Code는 사용자 계정이 읽을 수 있는 모든 파일을 읽을 수 있습니다. 여기에는 프로젝트의 .env 파일, ~/.aws/의 AWS 자격 증명, ~/.ssh/의 SSH 개인 키, 셸 rc 파일의 GitHub 토큰, Claude가 생성하는 모든 하위 프로세스의 환경 변수가 포함됩니다. 이는 정상적이며 설계 의도입니다.

시크릿을 작업 공간에서 분리

첫 번째 조치는 시크릿이 Claude가 읽는 디렉터리 안에 없도록 하는 것입니다.

.env 파일이 가장 흔합니다. 프로젝트 루트에 있고, 모든 개발 도구가 로드하며, Claude 컨텍스트에 두고 싶지 않은 값(데이터베이스 URL, API 키 등)을 정확히 담고 있습니다. 

다음 패턴을 사용할 수 있습니다:

• 시크릿을 작업 트리 외부 디렉터리(예: ~/.config/myapp/secrets.env)로 옮기고, 외부 파일을 가리키는 환경 관리자나 direnv 설정을 통해 로드합니다.

• 컨테이너화된 작업에서는 바인드 마운트 외부에 .secrets/ 폴더를 두어, 컨테이너 내부에서 파일이 보이지 않도록 합니다.

• permissions.deny 목록에 Read(**/.env)와 Read(**/.env.*)를 추가하고, Read 도구가 읽지 못하는 것을 셸 스크립트도 읽지 못하도록 Bash(cat:*/.env) deny를 함께 설정합니다.

시크릿 관리자 사용

데모 프로젝트를 넘어서는 모든 경우, 시크릿의 올바른 위치는 시크릿 관리자입니다.

벤더(1Password, AWS Secrets Manager, HashiCorp Vault, Doppler, Infisical)와 관계없이 패턴은 동일합니다. 시크릿은 관리자에 저장됩니다. 셸이나 런타임은 필요할 때 시크릿을 가져와 필요한 프로세스에만 노출합니다. Claude는 실제 값을 보지 못합니다.

Claude Code의 경우, CLAUDE_CODE_SUBPROCESS_ENV_SCRUB을 설정해 하위 프로세스에서 Anthropic 및 클라우드 제공업체 자격 증명을 제거하거나, sandbox.credentials를 사용해 샌드박스된 명령에서 특정 변수를 해제하는 방식을 사용합니다. 전자는 ANTHROPIC_API_KEY가 빌드 스크립트로 전달되는 것을 막고, 후자는 민감한 환경 변수가 셸 명령으로 흘러가는 더 광범위한 경우를 커버합니다.

리포지토리 접근 제한

세 번째 옵션은 리포 수준에서의 통제입니다.

개발자가 프로덕션 전용 설정에 쓰기 권한이 필요 없다면, 그 개발자의 Claude Code 세션에도 필요하지 않습니다. 자명해 보이지만, 대부분 팀의 기본값은 개발자 권한이 일상적으로 사용하는 범위를 넘어 넓으며, Claude는 이를 그대로 상속합니다.

다음 두 단계를 고려하세요:

• 프로덕션 설정을 접근이 더 엄격한 별도 리포로 분리해, Claude가 작업하는 개발 환경에 처음부터 프로덕션 시크릿이 없도록 합니다.

• Claude가 상호작용하는 모든 서비스에 범위가 지정된 토큰을 사용하세요. 예를 들어 코드 리뷰용 GitHub 토큰에는 repo:delete가 필요하지 않습니다.

팀을 위한 Claude Code 보안

개별 개발자는 마음대로 settings.json을 변경할 수 있지만, 팀은 그렇게 할 수 없습니다. 전체 보안은 가장 취약한 머신의 가장 약한 설정만큼만 안전하기 때문입니다. 팀 및 조직 배포를 위해 Claude Code는 관리자가 하향식으로 적용하고 개별 사용자가 재정의할 수 없는 별도의 제어 레이어를 제공합니다.

관리형 설정

관리형 설정이 기반입니다.

파일은 관리자 권한이 있어야 쓸 수 있는 시스템 경로에 위치합니다:

• /Library/Application Support/ClaudeCode/managed-settings.json (macOS)

• /etc/claude-code/managed-settings.json (Linux)

• C:\ProgramData\ClaudeCode\managed-settings.json (Windows)

이 파일의 설정은 사용자 및 프로젝트 수준 설정보다 우선합니다. 여기에 둔 deny 규칙은 해당 머신의 모든 프로젝트에 적용되며, 개발자는 자신의 settings.json을 수정해도 제거할 수 없습니다. 대부분의 조직은 이 파일을 MDM(Mobile Device Management)이나 기타 개발 도구에 사용하는 동일한 구성 채널을 통해 배포합니다.

관리 레이어에서 알아둘 만한 설정은 다음과 같습니다:

• permissions.deny의 민감 경로 및 위험 명령에 대한 규칙

• defaultMode를 default 또는 plan으로 설정(절대 bypassPermissions는 금지)

• allowManagedPermissionRulesOnly: true로 권한 세트를 잠금

• enableAllProjectMcpServers: false로 MCP의 명시적 승인을 요구

• 로깅을 위한 OpenTelemetry 내보내기 구성

공유 권한 정책

Claude가 할 수 있는 일에 팀이 합의했다면, 그 합의를 버전 관리해야 합니다.

프로젝트 수준 설정은 리포 루트의 .claude/settings.json에 위치합니다. 여기에 체크인한 내용은 해당 리포에서 Claude를 실행하는 모든 사람에게 적용됩니다. 이 파일은 프로젝트별 allow/deny를 정의하기에 적합한 위치입니다.

이때 관리형 설정과 프로젝트 설정 간에 알아둬야 할 분리가 있습니다:

• 관리형 설정에는 조직 정책이 담깁니다(아무도 bypassPermissions를 실행하지 않음, 아무도 .env를 읽지 않음).

• 프로젝트 설정에는 워크플로 합의가 담깁니다(이 리포의 테스트는 npm test로 실행, 이 리포의 배포 스크립트는 금지 등).

팀 거버넌스

팀 도입 시, 정책 레이어에는 책임자가 필요합니다.

Claude Code를 규모 있게 운영하는 대부분의 팀은 보안/플랫폼 엔지니어링으로 구성된 소그룹이 관리형 설정, MCP 허용 목록, 훅 스크립트, OpenTelemetry 파이프라인을 담당합니다. 동일한 그룹이 예외 요청을 검토하고, 새로운 사용 사례가 생길 때 정책을 조정합니다.

다음 요소들을 문서화하는 것을 목표로 하세요:

• 어떤 리포가 범위에 포함/제외되는지와 위험 계층별 모드(규제 데이터 리포는 plan 모드, 마케팅 사이트 리포는 acceptEdits 등).
• 누가 예외를 승인할 수 있으며 어떻게 추적하는지.
• 팀이 권한 규칙, MCP 서버, 인시던트 데이터를 재검토하는 주기(분기별이 일반적).

감사 로깅

Claude Code는 모든 도구 결정, MCP 서버 연결, 권한 모드 변경, API 요청에 대해 OpenTelemetry 이벤트를 발생시킵니다. 관리형 설정에서 OTLP 엔드포인트를 구성하기 전까지 데이터는 전송되지 않습니다.

다음은 최소한의 텔레메트리 관리형 설정 블록입니다:

{
  "env": {
    "CLAUDE_CODE_ENABLE_TELEMETRY": "1",
    "OTEL_METRICS_EXPORTER": "otlp",
    "OTEL_LOGS_EXPORTER": "otlp",
    "OTEL_EXPORTER_OTLP_PROTOCOL": "grpc",
    "OTEL_EXPORTER_OTLP_ENDPOINT": "http://collector.internal:4317"
  }
}

기본적으로 프롬프트 콘텐츠와 도구 파라미터는 내보내기에서 제외되므로, 수집되는 이벤트는 전체 대화가 아닌 메타데이터입니다. 프롬프트 텍스트를 포함하려면 OTEL_LOG_USER_PROMPTS=1을 설정합니다. 도구 인자(감사를 위해 보통 필요한 항목)를 포함하려면 OTEL_LOG_TOOL_DETAILS=1을 설정합니다. 두 결정은 프라이버시에 영향을 주므로, 대부분의 팀은 이를 정책적으로 결정하고 저장 전에 백엔드에서 필터링 또는 마스킹을 구성합니다.

사용량 모니터링

감사에 사용되는 동일한 OpenTelemetry 스트림은 사용량 모니터링에도 사용됩니다.

Claude Code는 토큰 사용량, 요청당 비용, 세션 수, 도구 결정 비율에 대한 메트릭을 내보냅니다. 이를 집계하면 어떤 팀이 가장 큰 가치를 얻는지, 어떤 워크플로우에서 거부가 많이 발생하는지, 어떤 모델이 비용을 유발하는지 알 수 있습니다. Datadog, Honeycomb, SigNoz, Elastic, Splunk 등은 모두 표준 OTLP 형식을 수집합니다.

decision=deny가 포함된 permission_decision 이벤트의 급증은 Claude가 시도를 과도하게 하고 있음을 의미할 수 있지만, 팀의 allow 규칙이 너무 빡빡함을 의미할 수도 있습니다.

자주 발생하는 Claude Code 보안 실수

소수의 오구성이 대부분의 Claude Code 인시던트에서 반복적으로 나타납니다. 이제 무엇이 문제인지와 해결 방법을 살펴보겠습니다.

너무 넓은 권한

권한 시스템을 무디게 만드는 가장 빠른 방법은 너무 많은 것을 허용하는 것입니다.

명령별 프롬프트는 마찰을 유발하며, 쉬운 해결책은 광범위한 Bash(*) 허용이나 defaultMode: bypassPermissions 설정입니다. 둘 다 권한 시스템의 대부분을 무력화합니다.

allow 규칙은 실제 사용하는 특정 도구와 명령에만 범위를 지정하고(예: Bash(npm test:*), Bash(git status)), 나머지는 프롬프트에 맡기세요. 처음에는 프롬프트가 더 많지만, 몇 세션 내에 사용하는 명령을 허용 목록에 추가하면 대부분의 프롬프트가 사라집니다.

무제한 MCP 접근

두 번째 실수는 MCP 서버의 자격 증명과 접근 범위를 확인하지 않고 연결하는 것입니다.

대개 enableAllProjectMcpServers를 켜고, 공개 MCP 디렉터리에서 서버 몇 개를 연결한 다음, 이후로 검토하지 않아 발생합니다. 자격 증명이 약한 서버가 민감한 정보를 유출할 즈음에는, 연결이 설정의 꽤 뒤쪽에 있어 누구도 승인 사실을 기억하지 못합니다.

해결책은 권한과 같습니다. allowedMcpServers를 통한 명시적 허용 목록, 모두가 필요한 서버에 대한 내부 managed-mcp.json, 그리고 목록의 정기 검토를 사용하세요.

샌드박싱 미사용

샌드박싱이 꺼져 있으면, Claude와 파일 시스템 사이에는 권한 시스템 하나뿐입니다.

각 명령을 승인하는 짧은 대화형 세션에서는 괜찮지만, 자율 실행, 허용 규칙을 넓힌 세션, 외부 소스 코드를 다루는 작업에는 적합하지 않습니다.

/sandbox로 켤 수 있습니다. 의존성이 설치되지 않았으면, 메뉴에서 플랫폼별 설치 항목을 안내합니다. 켜고 나면 권한 프롬프트가 줄고, allow 규칙이 놓친 부분을 OS가 잡아냅니다.

변경 사항 무비판 수용

acceptEdits는 편리하면서도 위험합니다.

Claude가 함수를 다시 쓰고 있고 이를 모니터링 중이라면 자동 승인도 괜찮습니다. 하지만 Claude가 한 시간 동안 30개 파일을 반복 수정하는 상황에서는, diff를 읽는 대신 에이전트를 신뢰하기 시작하기 쉽습니다. 문제가 생기는 지점입니다.

다음 두 가지 습관을 들이세요:

• Claude를 자율 실행하기 전에 항상 커밋해, 롤백 경로를 git reset 한 번 거리로 유지합니다.

• 세션 종료 후 누적 diff가 아니라, Claude가 작성한 각 커밋의 diff를 검토합니다.

감사 로그 무시

텔레메트리 없이 Claude Code를 운영하는 팀은 "어느 세션이 그걸 했지?"라는 질문에 답할 방법이 없습니다. 이벤트는 각 머신에 로컬로 쌓여 그대로 남습니다. 감사 추적이 처음으로 필요해지는 순간은, 그걸 구성하지 않았다는 사실을 알게 되는 최악의 타이밍이기도 합니다.

최소 유효 기준은 팀이 이미 운영 중인 관측 스택으로 tool_decision, permission_decision, api_request 이벤트를 내보내는 것입니다. 그다음에는 사용 사례에 맞춰 대시보드와 알림을 구축합니다.

결론

챗봇의 최악의 시나리오는 잘못된 답변입니다. 하지만 코딩 에이전트의 최악의 시나리오는 여러분의 자격 증명으로 프로덕션에서 실행되는 셸 명령입니다.

그래서 세 가지 기둥이 중요합니다:

• 권한은 Claude가 무엇을 할 수 있는지 결정합니다
• MCP 제어는 연결 가능한 외부 시스템을 결정합니다
• 샌드박싱은 앞의 두 가지가 부족할 때 무엇이 일어나는지 결정합니다

각 요소는 다른 요소가 커버하지 못하는 실패 모드를 보완합니다. 함께 모여 Claude가 실제로 작업하는 경계를 정의합니다.

생성형 AI 자격증을 고려 중이시라면, 2026년 최고의 생성형 AI 자격증 비교, 추천 과정, 준비 팁, FAQ를 확인하세요.