Claude Code의 안전한 사내 도입을 위한 시스템 엔지니어용 보안 실무 가이드

서론

Claude Code는 "AI가 리포지토리(Repository)를 읽고, 파일을 편집하며, 셸(Shell)을 실행하는" 도구입니다. 편리한 반면, 코드베이스에 대한 자율적 액세스·셸 실행·외부 API 통신이라는 넓은 공격 표면(Attack Surface)을 가지고 있어, "개발 팀이 사용하고 싶어 한다. 하지만 사내 보안 요건을 충족할 수 있는가?"라는 질문은 정보 시스템 부서·SRE·보안 담당자에게 이제 피할 수 없는 과제가 되었습니다. 무엇을 어디까지 허용하고, 누가 감사할 것인가. 설계를 잘못하면 편리함의 대가로 사고를 초래할 수 있습니다.

다행히 Claude Code는 권한 제어·OS 샌드박스(Sandbox)·Managed Settings·OpenTelemetry 감사를 결합한 **다층 방어(Defense in Depth)**를 갖추고 있습니다. 본 기사에서는 공식 문서에 준거하여, 사내 도입 여부 판단부터 도입 후의 가드레일(Guardrail) 설계까지, 안전한 도입 및 운용을 위한 구체적인 지침을 정리합니다.

이 기사에서 알 수 있는 내용

• 어떤 리스크가 있는가: 프롬프트 인젝션(Prompt Injection, 외부에서 가져온 코드·README·웹 기사 등에 심어진 지시문으로 AI를 조종하는 공격)·데이터 유출·권한 폭주 등 특유의 위협
• 어떻게 통제할 것인가: 권한 관리 4계층, Sandboxing(OS 레벨에서 Bash 실행을 격리하는 메커니즘), Managed Settings(IT 관리자만이 배포할 수 있는 조직용 정책 파일. 사용자가 덮어쓰기 불가)를 통한 정책 강제
• 어떻게 감사할 것인가: OpenTelemetry(메트릭·로그·트레이스 수집의 업계 표준 규격) 연동을 통해 사내 SIEM으로 집약
• 도입 시 무엇을 확인할 것인가: 체크리스트와 권장 settings.json 템플릿

최소한 이것만은: 절대 빼놓을 수 없는 3가지 설정

이 3가지가 포함되지 않은 시점에서 보안 통제는 성립하지 않습니다. 상세 내용은 본문에서 해설합니다.

#	설정	방지하는 내용
1	(Managed Settings) disableBypassPermissionsMode: "disable"	모든 권한 프롬프트를 스킵하는 bypassPermissions 모드를 개발자 개인이 활성화할 수 없도록 봉쇄. AI의 폭주를 막는 최후의 보루
2	Read(./.env) / Read(~/.ssh/**) / Read(~/.aws/**) 를 deny 에 추가	기밀 파일·인증 정보를 컨텍스트에 혼입시키지 않음. .gitignore만으로는 불충분 (로컬에는 실제로 존재하기 때문)
3	(OpenTelemetry 활성화) CLAUDE_CODE_ENABLE_TELEMETRY=1	사내 SIEM에 감사 로그를 집약. 감사 추적(Audit Trail) 없이는 인시던트 추적도 비용 통제도 성립하지 않음

나머지 설정(Sandboxing, 도메인 제한, MCP(Model Context Protocol: LLM이 외부 도구·데이터에 접속하는 표준 프로토콜) 승인제 등)은 이 3가지를 토대로 쌓아 올리는 발전 형태입니다.

1. 사내 도입 시 파악해야 할 5가지 보안 리스크

기존의 IDE 플러그인에는 없었던 종류의 리스크가 에이전트형 도구인 Claude Code에는 존재합니다. 사내 도입 전에 파악해야 할 5가지는 다음과 같습니다.

#	리스크	발생하는 현상	주요 대책
1	프롬프트 인젝션 (Prompt Injection)	외부에서 가져온 코드, README 등에 심어진 명령으로 인해 AI가 조종됨	Sandboxing, curl/wget 자동 차단, Trust verification
2	기밀 정보 유출	.env 등 명시적인 기밀 파일뿐만 아니라, 로그·테스트 데이터·설정 파일 내 주석 등에 섞여 있는 기밀이 컨텍스트 (AI에 전달되는 파일·대화 문맥)를 통해 API로 전송됨	Read deny rules, 사전 스캔, Sandboxing의 파일 격리, 읽기 범위 최소화, ZDR (Zero Data Retention: 전송 데이터를 학습·보유에 사용하지 않는 계약)
3	권한 폭주	rm -rf 등 파괴적인 명령어가 의도치 않게 실행됨	Bash deny rules, Plan mode (읽기 전용으로 계획 수립만 수행하는 모드), bypassPermissions 금지
4	공급망 오염 (Supply Chain Contamination)	신뢰할 수 없는 MCP 서버·플러그인 (Plugin, Claude Code에 기능을 추가하는 확장 패키지)이 사내 환경으로 유입됨	Managed Settings를 통한 허가 목록 고정
5	감사 추적 (Audit Trail) 결여	'누가 무엇을 했는지' 사후 추적이 불가능하여 인시던트 조사에 지장	OpenTelemetry 연동을 통한 SIEM 집약

전체 아키텍처: 위협과 방어 계층

여러 방어 계층을 두어, 한 계층이 뚫리더라도 다음 계층에서 저지할 수 있도록 설계되었습니다.

"모든 계층을 강제력 있는 수준으로 설정하는 것"이 엔터프라이즈 운영의 기본 방침입니다 (제5장의 프롬프트 인젝션 대책은 이러한 다층 방어의 종합 운용에 해당합니다).

2. 권한 관리의 4계층: 통제의 기본 구조

Claude Code의 권한 관리는 4개의 설정 스코프(Scope)가 우선순위 순으로 겹치는 구조입니다. 사내 통제의 핵심이므로 가장 먼저 파악해야 합니다.

2-1. 설정 파일의 우선순위

우선순위	스코프	경로	덮어쓰기 가능 여부
1 (최강)	Managed settings	/Library/Application Support/ClaudeCode/managed-settings.json (macOS) 등	❌ 사용자가 덮어쓰기 불가
2	커맨드라인 인자 (Command line arguments)	--allowedTools 등	일시적
3	로컬 프로젝트	.claude/settings.local.json	✅
4	공유 프로젝트	.claude/settings.json	✅ (Git 관리)
5 (최약)	사용자 설정	~/.claude/settings.json	✅

Managed settings에서 정의한 deny 규칙은 개발자가 어떻게 설정하더라도 해제할 수 없습니다. 이것이 사내 통제의 핵심입니다.

2-2. allow / ask / deny의 3가지 규칙

Claude Code 내에서 /permissions를 실행하면, 현재 규칙을 탭별로 확인할 수 있습니다.

/permissions

• Allow 탭 (자동 승인되는 도구 목록)
• /permissions
• Ask 탭 (매번 확인이 필요한 도구 목록)
• /permissions
• Deny 탭 (반드시 거부되는 도구 목록)

권한 규칙은 deny → ask → allow 순으로 평가되며, deny가 항상 우선합니다.

{
"permissions": {
"allow": [
...

💡

deny rules에서 자주 지정하는 대상: .env 계열의 기밀 파일, SSH 키, CI/CD 워크플로우 정의 (GitHub Actions 등), 운영 환경 스크립트, rm -rf 계열의 파괴적 명령어. "읽히면 곤란한 것", "편집되면 곤란한 것"을 망라하여 나열합니다.

실제로 프로젝트 레벨에서 .claude/settings.json을 만드는 최소 예시와 그 적용 결과는 다음과 같습니다.

터미널에서 .claude/settings.json을 생성하는 실연 (히어 도큐먼트(Here Document)로 deny/ask 규칙을 작성) 생성 후의 /permissions Ask 탭 (Bash(git push *)

、Bash(npm publish *)가 반영된 상태) 생성 후의

/permissions

Deny 탭(rm -rf 계열, .env, ~/.ssh/ 등의 deny 규칙이 반영된 상태)

⚠️

주의: 이것은 Bash(curl * | sh) / Bash(wget * | sh)에 대해 프로젝트 레벨의 최소 예시로, "파이프로 즉시 셸 실행되는 케이스만" 좁게 deny하고 있습니다. 사내 전체에 강제하고 싶다면 다음 절 이후에서 다루는 Managed Settings (4-3장)에서 Bash(curl *) / Bash(wget *) 전체를 차단(block)하는 것을 권장합니다 (이유는 2-3장을 참조).

2-3. Bash 권한의 와일드카드(Wildcard) 사양

Bash 커맨드의 패턴 매칭에서 인수(Argument) 제한은 취약하다고 공식적으로 경고하고 있습니다.

패턴	매칭 예시	매칭되지 않는 예시
Bash(npm run *)	npm run build	npm install, pnpm run build
Bash(curl http://github.com/*)	curl http://github.com/foo	curl -L ..., curl https://...
Bash(git * main)	git checkout main	git push origin develop

⚠️

인수 기반의 제한은 우회(Bypass)되기 쉽습니다: 예를 들어 Bash(curl http://github.com/*)를 허용(또는 거부) 규칙으로 설정하더라도, 다음과 같은 방식으로 쉽게 벗어날 수 있습니다.

# ① 옵션을 앞에 붙이면 매칭되지 않음: curl -X GET http://github.com/foo
# ② 셸 변수를 통해 URL을 숨김: URL=http://github.com && curl $URL/foo

①은 "curl 직후가 URL이 아니다", ②는 "실행 시점까지 URL이 확정되지 않는다"는 점 때문에, 둘 다 단순 문자열 패턴 매칭으로는 포착할 수 없습니다. 네트워크 통신을 제한하려면 curl / wget을 일괄 deny하고, WebFetch(Claude Code 내장 웹 가져오기 도구) 측에서 도메인 허용 리스트를 설정하는 것이 견고합니다.

2-4. Permission Modes: 실행 모드에 따른 동작 전환

모드	동작	권장 유스케이스
default	최초 이용 시 매번 승인	일반적인 이용
acceptEdits	파일 편집을 자동 승인	신뢰할 수 있는 리ポジトリ에서의 작업
plan	읽기 전용, 변경 불가	코드 리뷰 및 조사 태스크
dontAsk	allow rules로 명시적 허용된 것 외에는 자동 거부	고보안 환경 (권장)
bypassPermissions	모든 권한 프롬프트를 스킵	❌ 사내 도입 시 금지해야 함

⚠️

주의: Managed settings에 다음을 추가하면 개발자 개인이 활성화할 수 없게 됩니다. bypassPermissions는 조직 정책으로 무효화하십시오.
{ "permissions": { "disableBypassPermissionsMode": "disable", "disableAutoMode": "disable" } }

3. Sandboxing: OS 레벨의 자동 방어

Permissions만으로는 프롬프트 인젝션 (Prompt Injection)으로 인해 AI가 조종당할 경우의 방어가 불충분합니다. 따라서 OS 레벨에서 Bash 실행을 격리하는 Sandboxing 기능을 병행합니다.

3-1. Sandboxing의 메커니즘

OS	사용하는 메커니즘
macOS	Seatbelt (OS 내장)
Linux / WSL2	bubblewrap ( apt install bubblewrap socat 등 필요)
WSL1	❌ 미지원

파일 시스템 격리 (File System Isolation): 쓰기 작업은 작업 디렉토리 하위로만 제한됩니다. ~/.ssh/, /etc/ 등의 시스템 영역은 OS 레벨에서 보호됩니다. 네트워크 격리 (Network Isolation): 허용 리스트에 있는 도메인만 통신이 가능하며, 데이터 유출 경로를 물리적으로 차단합니다.

3-2. 활성화 및 권장 설정

# Linux/WSL2는 사전에 의존성 패키지를 설치해야 합니다
sudo apt-get install bubblewrap socat

[Claude Code 세션 내]
> /sandbox

/sandbox의 Mode 설정 화면. 기본값은 No Sandbox (current)로 설정되어 있으며, 명시적으로 Auto-allow 또는 Regular permissions를 선택하지 않으면 활성화되지 않습니다.

settings.json을 통한 영구 설정 예시:

{
"sandbox": {
"enabled": true,
...
}
}

💡 팁: 의존성 패키지가 설치되어 있지 않거나 지원하지 않는 OS에서 샌드박스 (Sandbox)를 실행할 수 없는 경우, Claude Code는 경고만 표시하고 샌드박스 없이 동작합니다. 이 설정을 통해 failIfUnavailable: true를 적용하여 하드 페일 (Hard Fail) 방식으로 보안 게이트를 철저히 관리할 수 있습니다.

3-3. 샌드박싱 (Sandboxing)으로 방어할 수 없는 것 (중요)

방어 가능	방어 불가능
작업 디렉토리 외부에 대한 쓰기	작업 디렉토리 내의 기밀 데이터
허용된 도메인 외로의 통신	TLS 내부 내용 (프록시는 내용을 보지 않음)
~/.ssh/ 등 시스템 영역 읽기	광범위하게 허용된 github.com을 통한 도메인 프론팅 (Domain Fronting)
서브 프로세스 (Subprocess)로부터의 이탈	컨텍스트를 통한 API 전송 (샌드박싱은 정상적인 통신을 방해하지 않음)
—	dangerouslyDisableSandbox 사용

⚠️ '정상적인 통신'을 통한 유출은 별개의 문제입니다: 샌드박싱은 통신 대상 도메인만 확인하며, 전송 내용 (Payload)은 검사하지 않습니다. 설정 파일의 주석, 테스트 픽스처 (Test Fixture), 로그, git 히스토리 등에 포함된 기밀 정보가 허용된 api.anthropic.com을 통해 그대로 외부로 전송될 위험이 남아 있습니다. 대책은 원칙적으로 3단계로 구성해야 합니다: ① 읽기 (Read) 권한의 최소화 (예: Read(./src/**)와 같은 한정적 지정), ② gitleaks / trufflehog 등을 이용한 사전 스캔, ③ ZDR 계약 검토.

⚠️ 주의: dangerouslyDisableSandbox는 샌드박스 내에서 동작하지 않는 도구에 대한 탈출구(Escape Hatch) 역할을 하지만, 사내 정책에 따라 반드시 무효화해야 합니다. dangerouslyDisableSandbox 사용은 비권장하며, { "sandbox": { "allowUnsandboxedCommands": false } } 설정을 권장합니다.

4. Managed Settings: 조직 정책 강제

지금까지의 설정을 '개발자 개인에게 맡기는 것'은 권장되지 않습니다 (NG). Managed Settings를 통해 조직 정책으로서 배포하고 강제해야 합니다.

4-1. 배포 방법

방법	적합한 환경
MDM/OS 레벨 정책	Jamf, Intune 등으로 관리되는 디바이스
Managed settings 파일 직접 배치	/Library/Application Support/ClaudeCode/managed-settings.json (macOS), /etc/claude-code/managed-settings.json (Linux), C:\ProgramData\ClaudeCode\managed-settings.json (Windows)
서버 관리형 설정 (Server-managed settings)	서버로부터 동적 취득 (Fail-closed 운영 가능)

4-2. Managed-only 설정 (관리자만 지정 가능)

Managed settings를 통해서만 적용되는 사내 통제의 핵심 키:

설정	효과
disableBypassPermissionsMode: "disable"	bypassPermissions (우회 권한) 모드 사용 불가
allowManagedPermissionRulesOnly: true	Managed 이외의 allow/ask/deny 규칙 무효화
allowManagedMcpServersOnly: true	Managed에서 정의한 MCP 서버만 허용
sandbox.network.allowManagedDomainsOnly: true	Managed에서 정의한 도메인만 통신 허용
forceRemoteSettingsRefresh: true	원격 설정 취득 실패 시 Claude Code 실행 차단
strictKnownMarketplaces	허가된 마켓플레이스(Marketplace)를 통해서만 플러그인(Plugin) 도입 가능

4-3. 권장 Managed Settings 템플릿

사내 배포용 템플릿의 시작점:

{
"permissions": {
"disableBypassPermissionsMode": "disable",
...

4-4. 자사 커스터마이징 시 변경해야 할 사항

위의 템플릿은 그대로 사용하는 것이 아니라, 자사 환경에 맞춰 반드시 다음 항목을 교체해야 합니다.

• permissions.deny: 사내 고유의 기밀 경로(예: Read(./db-scripts/**), Edit(./terraform/**/prod/**) 등)를 추가
• sandbox.network.allowedDomains: 사내 패키지 저장소(Verdaccio / Artifactory / 사내 GitLab 등)를 추가
• env.OTEL_EXPORTER_OTLP_ENDPOINT: 자사 OpenTelemetry Collector 엔드포인트로 교체
• env.OTEL_RESOURCE_ATTRIBUTES: department=xxx,team.id=yyy,cost_center=zzz와 같이 부서 및 코스트 센터(Cost Center) 식별자 부여
• allowedMcpServers: 사내 승인된 MCP 서버 이름만 나열 (미승인 서버로의 접속 차단)

특히 deny rules(거부 규칙)는 "자사에서 무엇이 기밀인가"를 먼저 정리한 후 채워 넣는 것이 철칙입니다. 템플릿을 그대로 유용하기만 해서는 누락이 발생할 수 있습니다.

5. 프롬프트 인젝션 (Prompt Injection) 대책

Claude Code에는 **프롬프트 인젝션을 전제로 한 다층 방어 (Defense in Depth)**가 내장되어 있습니다. 이는 설정으로 활성화/비활성화를 전환하는 성격의 것이 아니라, 기본적으로 작동합니다.

대책	내용
커맨드 블랙리스트 (Command Blocklist)	curl, wget 등 웹에서 임의의 콘텐츠를 가져오는 명령어를 기본적으로 차단
신뢰성 확인 (Trust verification)	최초 리포지토리 및 신규 MCP 서버는 사용 전 명시적 확인 필요
격리된 컨텍스트 윈도우 (Isolated context windows)	WebFetch는 별도의 컨텍스트에서 동작 (악의적인 내용이 메인 컨텍스트에 섞이지 않음)
커맨드 인젝션 탐지 (Command injection detection)	의심스러운 Bash 명령어는 허가 목록에 있더라도 다시 수동 승인을 요구
페일 클로즈 매칭 (Fail-closed matching)	허가 목록에 일치하지 않는 것은 자동으로 거부

💡

Fail-closed란: 판정에 실패하거나 해당 사항이 없을 때 "안전한 쪽(=거부)"으로 결정하는 설계 사상입니다. 반대로 통과시켜 버리는 설계를 fail-open이라고 합니다. 보안 메커니즘은 fail-closed가 원칙입니다.

새 폴더를 열었을 때 나타나는 신뢰성 확인 (Trust verification) 다이얼로그. "Yes, I trust this folder"를 선택하기 전까지 Claude Code는 파일 조작을 실행하지 않습니다. 프롬프트 인젝션을 "폴더를 여는 순간"에 차단하는 첫 번째 관문입니다.

권장되는 추가 대책

• VM/Dev Container 내에서 실행: 외부 웹 서비스 연동 처리는 격리된 환경에서 수행
• 신뢰할 수 없는 콘텐츠를 파이프로 흘려보내지 않기: cat untrusted.md | claude 등은 피할 것
• 중요 파일에 대한 변경 제안은 반드시 리뷰: CI 설정, 인증 로직, 암호화 키 주변은 인간의 확인 필요

⚠️

Windows 주의사항: WebDAV 관련 경로(\\*와 같은 UNC 경로)는 Claude Code가 이용하지 못하도록 설정하십시오. WebDAV를 통해 권한 시스템을 우회하는 네트워크 통신이 발생할 위험이 있습니다 (공식 경고).

6. 감사 로그(Audit Log)와 OpenTelemetry 연동

**감사 추적(Audit Trail)**은 사내 통제의 전제 조건입니다. Claude Code는 OpenTelemetry를 통해 메트릭(Metrics), 로그(Logs), 트레이스(Traces)를 사내 SIEM, Splunk, Datadog 등으로 집약할 수 있습니다.

6-1. 활성화

export CLAUDE_CODE_ENABLE_TELEMETRY=1
export OTEL_METRICS_EXPORTER=otlp
export OTEL_LOGS_EXPORTER=otlp
...

6-2. 취득 가능한 데이터

종류	내용
메트릭 (Metrics)	세션 수, 도구 사용 횟수, 토큰 소비, 비용
로그/이벤트 (Logs/Events)	프롬프트 전송, 도구 실행, 권한 승인·거부, 에러
트레이스 (Traces, Beta)	프롬프트 → API 호출 → 도구 실행 → 자식 프로세스로 이어지는 모든 요청 흐름

트레이스를 활성화하려면 CLAUDE_CODE_ENHANCED_TELEMETRY_BETA=1과 OTEL_TRACES_EXPORTER=otlp를 추가하십시오.

6-3. 팀별/부서별 속성 부여

비용 분석 및 알람 설정을 위해 속성을 부여합니다:

export OTEL_RESOURCE_ATTRIBUTES="department=engineering,team.id=platform,cost_center=eng-123"

⚠️

속성값에 공백을 사용할 수 없습니다: team.id=Platform Team은 무효합니다. 언더스코어(_) 또는 카멜 케이스(CamelCase, 예: Platform_Team / PlatformTeam)를 사용하십시오.

6-4. 대시보드 구성 예시

「비용 통제 × 정책 위반 탐지 × 이상 탐지 × 외부 연결 모니터링」의 4개 축으로 구성하면, 정보시스템팀·보안팀·재무팀 각각의 관점을 한 화면에 담을 수 있습니다. 구현 도구는 Grafana, Datadog, Splunk, Honeycomb 등을 가리지 않습니다.

모니터링 항목	목적	취득원 (OTel)
부서별 토큰 소비량	비용 배분·예산 알람	claude_code.llm_request의 token 관련 항목 × OTEL_RESOURCE_ATTRIBUTES
도구 거부율	정책 위반 시도 탐지	claude_code.tool.blocked_on_user의 decision: reject
이상 에러 빈도	프롬프트 인젝션 (Prompt Injection) 징후 탐지	claude_code.tool.execution의 success: false
MCP 연결 대상 편중	예상치 못한 외부 서비스 이용 탐지	tool spans + mcp__* 도구명

4개의 타일을 한 화면에 배치하는 레이아웃 이미지:

타일	주요 메트릭 (예시)	상태
부서별 토큰 소비 (월간)	Engineering: 4.2M / Product: 1.8M / Data Science: 1.1M ／ 월간 예산 70% 사용	✅ 녹색
도구 거부율 (24h)	denied 합계 12건 (deny rule: 8 / user reject: 4) ／ 임계값 50/h	✅ 정상
이상 에러 빈도 (1h)	에러 3건 (timeout: 2 / sandbox_violation: 1) ／ 급증 알람 없음	✅ 정상
MCP 연결 대상 분포 (주간)	github: 68% / internal-jira: 22% / internal-db: 10% / 미승인: 0%	✅ 정상

부서별 이용량을 원형 그래프로 시각화할 경우의 표시 이미지 (비용 배분의 근거 자료로 바로 사용할 수 있습니다):

💡

이상 탐지 임계값 설계의 팁: 「tool.blocked_on_user에서 reject가 시간당 평소의 5배 이상 발생할 때」, 「sandbox_violation이 새로 발생할 때」, 「미승인 MCP 서버로의 연결 시도」. 이 세 가지를 푸시 알림(Slack/Teams)과 연동해 두면 공격의 징후를 놓치지 않습니다.

7. 사내 도입 체크리스트

승인 프로세스 및 운영 설계에서 바로 사용할 수 있는 형태로 정리합니다.

7-1. 도입 전 평가

• 이용 예정 플랜(Team／Enterprise／Console 권장, 무료 플랜은 미지원) 확정
• Anthropic Trust Center에서 SOC 2 Type 2／ISO 27001 인증 확인
• 법무 부서와 Commercial Terms／Privacy Policy(개인정보 처리방침) 검토

7-2. 환경 구축

• Managed Settings 배포 경로(MDM／직접 배치／Server-managed) 결정
• OS 지원 확인: macOS 13+／Linux(bubblewrap 필요)／WSL2(WSL1은 미지원)
• Managed settings 템플릿을 사내 리스크에 맞춰 커스텀
• OpenTelemetry Collector의 사내 엔드포인트 준비
• 리포지토리 내 기밀 정보 혼입을 gitleaks/trufflehog 등으로 사전 스캔
• 운영 데이터(Production Data)를 포함한 테스트 픽스처(Test Fixture) 존재 확인 및 마스킹(Masking)
• Read 권한을 최소 범위로 설정(Read(./src/**)와 같은 한정 지정)
• ZDR(Zero Data Retention) 계약 검토(Enterprise／Console)

7-3. 정책 설계

• disableBypassPermissionsMode: "disable"를 반드시 설정
• sandbox.enabled: true ＋ failIfUnavailable: true ＋ allowUnsandboxedCommands: false 설정
• Deny(거부) 리스트 최소화: rm -rf 계열, curl/wget, .env, ~/.ssh/, CI 설정 등
• 허용 도메인을 최소화(api.anthropic.com ＋ 필요한 패키지 리포지토리만)
• MCP/Plugin 제한(strictKnownMarketplaces, allowManagedMcpServersOnly)

7-4. 감사 및 운영

• OpenTelemetry로 메트릭(Metrics) 및 로그(Logs)를 사내 SIEM으로 집약
• 부서별 속성(OTEL_RESOURCE_ATTRIBUTES)을 통한 비용 배분 메커니즘 설계
• 대시보드화(토큰 소비량, 거부율, 이상 에러 빈도)
• 인시던트 대응 플로우에 「Claude Code를 경유한 사고」 추가
• 개발자 대상 트레이닝(프롬프트 인젝션(Prompt Injection), Plan mode, /feedback)

7-5. 지속적 운영

• Managed Settings를 분기별로 리뷰
• Anthropic HackerOne에서 취약점 정보 모니터링
• 릴리스 노트 확인(특히 기본 동작의 변경 사항)

8. 자주 묻는 질문 (FAQ)

Q1. 개인용 Claude Pro/Max 계정을 업무에 사용해도 괜찮나요?