Claude Code를 직장에서 사용하려고 하면, IT 관리 부서(情シス)나 보안 담당자로부터 자주 듣게 되는 질문들이 있습니다. 예를 들어 이 Qiita 기사에서는 IT 관리 부서에게 반드시 묻는 세 가지 질문으로 다음을 언급하고 있습니다. 도입 과정의 어려움을 다룬 다른 글에서도 같은 종류의 질문이 반복적으로 나옵니다.
- 위험한 조작을 임의로 하지 않는가
- AI가 무엇을 하고 있는지 확인할 수 있는가
- 문제가 생겼을 때 설명할 수 있는가
그 전에 반드시 "코드는 학습에 사용되지 않는가"라는 질문도 나옵니다.
'CLAUDE.md에 금지되어 있습니다'라는 답변으로는 부족합니다. 그것은 요청일 뿐, 강제력이 없기 때문입니다. 이 글에서는 **사용자가 덮어쓸 수 없는 관리 설정(managed settings)**을 통해 답합니다. 실제로 효력이 있는지 여부는 직접 시험해 보았습니다. 어느 정도까지 막히고, 어디부터는 막히지 않는지도 테스트 결과대로 작성하겠습니다.
- 검증 환경: Claude Code 2.1.294, Linux (컨테이너, root로 실행),
claude -p
(비대화 모드), 2026-10-08 - 방법: 일회용 프로젝트에 더미의 .env
・삭제용 디렉터리・로컬 push 대상을 두고, 조건별로 다시 만들어서 한 번씩 실행했습니다.
전제: 관리 설정이란
관리 설정은 단말기의 관리자가 배치하는 설정 파일입니다. 사용자 본인의 설정(~/.claude/settings.json), 프로젝트의 설정, 시작 시 --settings의 어느 것을 사용해도 덮어쓸 수 없습니다. 공식 설명은 "Nothing in your own settings files or --settings overides a managed key"입니다 (설정).
| OS | 배치 위치 |
|---|
| macOS | /Library/Application Support/ClaudeCode/managed-settings.json |
| 出典: managed-settings (2026-10-08 확인). MDM으로 배포하는 것도 가능합니다. Team / Enterprise 플랜이라면, claude.ai 관리 화면에서 전원에게 배포하는 방식도 있습니다 (server-managed-settings). | |
질문 0: 코드는 학습에 사용되는가
답변은 계약 종류에 따라 다릅니다. 이 부분을 모호하게 두고 이야기하면 나중에 문제가 생길 수 있습니다.
| 계약 | 모델의 학습 이용 여부 | Anthropic 측 보관 기간 |
|---|---|
| 상용 (Team / Enterprise / API) | 사용하지 않음 (명시적으로 참여를 신청한 경우 제외) | 표준 30일. 제로 데이터 보관(ZDR)은 Enterprise 대상 조직만 가능하며, 조직별로 활성화해야 함 |
| 개인용 (Free / Pro / Max) | 본인의 설정에 따라 사용됨 | 학습을 허가할 경우 5년, 허가하지 않을 경우 30일 |
出典: data-usage (2026-10-08 확인. 약관은 바뀌므로 제출 전에 최신 버전을 확인하세요).
IT 관리 부서에 전달해야 할 점이 두 가지 있습니다.
- 개인 계약 상태로 업무 코드를 다루지 않는 것이 첫 번째 경계가 됩니다 - 본인의 PC에도 대화 내용이
~/.claude/projects/에 평문으로 남습니다 (기본 30일, cleanupPeriodDays로 변경 가능. 데스크톱 버전・Cowork의 세션은 다른 설정).
- 단말기 분실 대비 범위에 포함합니다 - "30일"에는 예외가 있습니다.
/feedback (/bug・/share도 같은 경로)으로 보낸 대화는 5년간 보관됩니다. 세션 후 설문조사에서 대화 공유에 "Yes"라고 답할 경우, 소스 코드를 포함한 대화가 전송되며 최대 6개월간 보관됩니다. 막으려면 환경 변수 DISABLE_FEEDBACK_COMMAND=1와 CLAUDE_CODE_DISABLE_FEEDBACK_SURVEY=1를 관리 설정의 env에 배포합니다 (동일 페이지. 이 두 가지는 이번에 시험하지 않았습니다).
질문 1: 위험한 조작을 임의로 하지 않는가
관리 설정의 deny는 사용자 허용보다 우선한다
우선 비교를 위해, 관리 설정 없이 시작 옵션 --allowedTools로 rm -rf victim, git push, cat을 허용했습니다. 지시대로 세 가지 모두 실행되었고, .env의 내용도 출력되었습니다.
다음으로, 동일한 허가(permission) 상태에서 관리 설정에 다음을 추가했습니다.
{
"permissions": {
"deny": ["Bash(rm -rf:*)", "Bash(git push:*)", "Read(./.env)", "Read(**/.env)"]
...
}
| 시도한 것 | 결과 |
|---|
rm -rf victim | 거부됨 (디렉토리는 남아 있음) |
git push origin HEAD:main | 거부됨 (push 대상에 커밋이 도착하지 않음) |
cat .env | 거부됨 (내용물이 나오지 않음) |
echo start && git push origin HEAD:main (복합 명령어) | 거부됨 |
사용자가 그 자리에서 허가하더라도, 관리 설정의 deny가 우선했습니다.
참고로 Bash(rm -rf:*)는 'rm -rf로 시작하는 명령어'와 일치하는 방식으로, 표기 방식의 오차를 흡수하지 않습니다. 추가적으로 시도한 결과 (2026-10-11, Claude Code 2.1.296):
| deny | 실행시킨 명령어 | 결과 |
|---|---|
Bash(rm -rf:*) | rm -rf victim | 거부됨 |
Bash(rm -rf:*) | rm -fr victim | 실행되어 사라짐 |
Bash(rm -rf:*) | rm -r -f victim | 실행되어 사라짐 |
Bash(rm:*) | rm -r -f victim | 거부됨 |
Bash(git push --force:*) | git push -f origin HEAD:main | push 됨 |
Read(**/.env) | cat .env.local | 값이 출력됨 |
실제로 배포할 때는, rm이나 git push는 전체를 deny 또는 ask에 넣고, .env는 Read(**/.env.*)도 추가해야 합니다. 현재 설정에 이런 허점이 없는지는 설정 검사기(setting checker)에 붙여서 한 번에 확인할 수 있습니다.
게다가 allowManagedPermissionRulesOnly: true를 추가하면, 사용자 측의 allow(허가) 규칙 자체가 무시됩니다. `--allowedTools
の行を足す前に試しました。足した後の完成形でも python の読み取りは失敗します）。
設定の意味は次のとおりです（sandboxing）。
failIfUnavailable: 샌드박스를 시작할 수 없는 환경에서는 Claude Code 자체를 시작하지 않습니다. 이것을 붙이지 않으면, 샌드박스 없이 조용히 작동합니다 -
allowUnsandboxedCommands: false: 실패한 커맨드를 샌드박스 밖에서 재시행하지 않음 -
autoAllowBashIfSandboxed: false: 이것을 잊으면 역효과가 납니다. 기본값은 true여서, 샌드박스 안에서 작동하는 Bash 명령어는 확인 없이 실행됩니다 (settings-reference). 실제로, 기본값 그대로는 허용하지 않은 rm victim/a.txt가 확인 없이 실행되어 파일이 지워졌습니다. false로 설정하면 거부되었습니다 (비대화 모드에서는 확인할 수 없기 때문에 거부됨). 멈추는 것은 deny에 적은 것뿐만 아니라, 일반적인 확인 흐름으로 돌아가기 위한 설정입니다.
사용 가능한 OS는 macOS・Linux・WSL2입니다. Windows 네이티브와 WSL1에서는 사용할 수 없습니다. Linux・WSL2에서는 bubblewrap과 socat이 필요합니다. 또한, 파일 조작 도구・MCP・hooks는 샌드박스 밖에서 작동합니다.
또 한 가지 주의할 점이 있습니다. 샌드박스 설정에는 사용자가 자신의 설정으로 확장할 수 있는 것이 있습니다. 공식 문서는 excludedCommands (샌드박스 밖에서 실행하는 커맨드)나 filesystem.allowWrite에 대해
「入力した内容を管理者に読まれるのか」もよく聞かれる質問です。既定では読まれず、設定すれば記録できる、というのが正確な答えです。どちらにするかは規程で決めて、利用者に知らせておきます。
질문 3: 무슨 일이 생겼을 때 설명할 수 있는가
여기는 설정 하나로 해결되는 것이 아닙니다. 설명에 사용할 재료를 모아두는 것이 답이 됩니다.
- 무엇을 막고 있는가: 관리 설정 파일 그 자체. 누구에게나 열려있는 곳에 두기 -
- 무슨 일이 일어났는가: 훅(hook) 기록, 또는 OpenTelemetry의 이벤트. 여기에 git 히스토리 -
- 막고 있지 않은가: 아래의 「한계」를 미리 서면으로 전달해두는 것이 가장 중요합니다.
세 번째가 가장 중요합니다. 「모든 것을 막을 수 있습니다」라고 말하다가 구멍이 발견되는 것보다, 「여기까지는 막히고, 여기부터는 막히지 않습니다」를 먼저 내놓는 편이 신뢰를 얻습니다.
이번 설정의 완성형
위의 검증을 하나로 모은 것입니다. 이 파일로, git push
의 거부, python에 의한 .env
읽기 실패, 허가하지 않은 rm victim/a.txt
의 거부, 허가한 ls
의 실행, 거부분을 포함한 기록을 확인했습니다 (2.1.294, Linux). rm
은 위의 추가 검증을 받아 Bash(rm -rf:*)
에서 Bash(rm:*)로 변경했습니다 (rm -fr
・rm -r -f도 거부되는 것을 2.1.296으로 확인).
인증 정보 보호를 더욱 넓히고 싶다면, 공식 리포지토리의 설정 예시(examples/settings/settings-hipaa.json)
가 ~/.git-credentials
・~/.netrc
・~/.config/gh
등의 읽기/쓰기 거부나 환경 변수의 비밀을 숨기는 설정까지 포함하고 있으니, 함께 참고해 주세요.
{
"permissions": {
"deny": [
...
기록 훅은 입력을 그대로 쓰기 때문에, Write로 작성한 내용이나 명령어 중의 토큰도 기록에 남습니다 (실측). 기록을 보여주거나 남기는 전제라면, 내용을 쓰지 않고 도구명・명령어・파일명만 골라서 쓰는 형태로 해 주세요.
git push까지 금지하면 곤란한 팀도 많을 것입니다. deny에 무엇을 넣을지는 팀의 운영에 맞춰 선택해 주세요. Read(**/.env.*)는 .env.example도 읽을 수 없게 하므로, 템플릿을 읽게 하고 싶다면 조정해 주세요.
정보 시스템 관리자에게 제출할 답변표 (양식)
| 질문 | 답 | 근거 (설정・문서) | 한계 |
|---|
| 코드는 학습에 사용되는가 | 상용 계약(Team / Enterprise / API)에서는 사용되지 않습니다. 표준 보존 기간은 30일 | data-usage (확인일 기재) | 개인 계약에서는 설정에 따름. /feedback으로 보낸 대화는 5년 보존 (환경 변수로 막을 수 있음) |
| ... | | | |
직접 설정에, 여기서 본 것과 같은 구멍이 없는지 무료 설정 검사기에 붙여넣으면 한 번에 확인할 수 있습니다: https://acerola-tools.acerola.workers.dev/check/?from=claude-code-managed-settings-security-qa
토론
