"편리하다는 건 알지만, 솔직히 AI가 직원 PC에서 명령어를 실행하는 게 무섭지 않나요?"
AI 도입을 지원할 때 경영진에게서 가장 자주 듣는 이야기입니다. ChatGPT처럼 브라우저 안에서만 활동하는 AI는 그렇게 위협적으로 느껴지지 않습니다. 하지만 Claude Code는 직원 컴퓨터의 파일을 읽고, 명령어를 실행하며, 인터넷에 접속합니다. "속도가 빨라지는 건 알겠는데, 만약 사고가 나면 누가 책임을 질 건가요?" 많은 기업이 이 지점에서 막혀 있을 가능성이 높습니다.
한 대기업이 그 불안감에 대한 해답을 제시했습니다. Mercari가 최근 스터디 세션에서 Claude Code를 수백 명의 직원에게 배포할 때 사용한 "보안 설정 및 배포 방법"을 공유한 것입니다.
게다가 그 내용은 비싼 사내 시스템에 관한 것이 아니었습니다. 설정 파일 하나를 준비해서 배포함으로써 중소기업(SME)도 대부분을 따라할 수 있습니다.
Mercari가 수백 명에게 배포할 수 있었던 이유는 고비용 메커니즘 때문이 아니라, 단 하나의 "직원이 삭제할 수 없는 설정 파일" 덕분이었습니다. 중소기업도 오늘부터 똑같이 할 수 있습니다.
이 글에서는 Mercari의 설계를 "무엇을 두려워해야 하는지", "Mercari가 어떻게 관리했는지", "여러분의 회사는 어디서부터 시작할 수 있는지"로 나누어 최대한 간단하게 설명하겠습니다. 기술 용어가 나올 때마다 설명을 덧붙일 예정이니, 엔지니어가 아닌 경영진이나 PM도 따라올 수 있습니다.
참고 자료는 여기에서 확인할 수 있습니다.
(Mercari Claude Code 조직 배포 보안 설정 / Speaker Deck
설정의 정확한 구문은 Anthropic의 공식 문서를 기준으로 확인했습니다.
Claude Code가 "편리하지만 무서운" 이유
먼저, 두려움의 본질을 명확히 해야 합니다. 설정을 이해하지 않고 그대로 복사만 하면 실제로 무엇을 보호하고 있는지 모를 수 있기 때문입니다.
Claude Code가 일반 채팅 AI와 다른 점은 로컬 컴퓨터 내에서 스스로 움직일 수 있다는 것입니다. 파일을 찾아 읽고, 수정하고, 쉘 명령어(터미널에 입력하는 명령어)를 실행할 수 있습니다. 또한 인터넷에 접속할 수도 있습니다. 즉, 해당 컴퓨터에서 할 수 있는 거의 모든 것을 AI도 할 수 있습니다.
구체적으로 무엇이 문제가 될까요? 컴퓨터에는 보통 남들이 보면 안 되는 것들이 들어 있습니다.
- 클라우드나 API의 비밀번호 역할을 하는 정보 (.env, ~/.aws/credentials 등의 설정 파일)
- 서버에 로그인하기 위한 키 (~/.ssh/ 디렉토리 내용)
- 삭제되면 큰일 나는 중요한 파일
AI에게 악의는 없습니다. 하지만 모호한 지시나 웹 상의 수상한 텍스트에 포함된 명령어(프롬프트 인젝션이라고 함)로 인해 실수로 이러한 비밀 파일을 읽어 인터넷으로 보내거나, rm 명령어로 중요한 항목을 삭제할 수 있습니다. Anthropic의 공식 문서는 이러한 위험을 기반으로 권한을 제한하는 설계를 권장합니다 (권한 설정 - 공식 문서).
요약하자면, 보호해야 할 세 가지는 비밀 정보 유출 방지, 위험한 작업 자동 실행 방지, 그리고 애초에 접근 가능한 범위를 좁히는 것입니다. Mercari의 조치를 이 세 가지 관점에서 보면 훨씬 이해하기 쉽습니다.
Mercari의 "5가지 조치" 분석
Mercari의 발표는 5가지 주요 조치로 요약됩니다. 각각의 "목적"과 "구현 방법"을 살펴보겠습니다.
발표 슬라이드는 개념에 초점을 맞추고 있으며, 설정 파일의 모든 세부 사항을 포함하고 있지는 않습니다. 따라서 "Claude Code의 공식 설정을 사용하여 Mercari의 정책을 구현하는 방법" 형태로 설명하겠습니다. 키 이름과 구문은 모두 Anthropic 공식 문서를 기준으로 확인했습니다.
조치 ①: 사람의 확인을 "건너뛸 수 없게" 만들기
Claude Code에는 매번 확인을 요청하지 않고 자동으로 진행되는 모드가 있습니다. 개발자가 실험용 PC에서 사용하기에는 편리하지만, 회사 전체에 배포할 때 이 기능을 허용하면 안전 브레이크가 사라집니다.
Mercari는 이 "확인 우회 모드"를 비활성화했습니다. 공식적으로는 permissions.disableBypassPermissionsMode(자동 모드를 차단하는 disableAutoMode도 있음)와 같은 설정을 사용할 수 있습니다. 이 값을 "disable"로 설정하면 사용자가 해당 모드에 진입하는 것을 막을 수 있습니다. 또한, 나중에 설명할 "관리형 설정"에 배치하면 직원 스스로 비활성화할 수 없습니다 (권한 설정 - 공식 문서).
의미는 간단합니다. "AI가 움직이기 전에 사람이 승인해야 한다"는 규칙을 회사 전체에 강제하는 것입니다.
조치 ②: 위험한 명령어 차단 또는 항상 확인하기
다음으로, 명령어 자체에 통제를 가합니다. 예를 들어, curl(인터넷에서 데이터를 가져오는 명령어)이 있습니다. 자유롭게 사용되면 비밀 파일을 외부로 보내는 통로가 될 수 있습니다.
Claude Code에서는 특정 명령어에 대한 deny 목록과 실행 전 확인이 필요한 ask 목록을 설정할 수 있습니다. 구문은 다음과 같습니다.
1{2 "permissions": {3 "deny": [4 "Bash(curl:*)",5 "Bash(wget:*)"6 ],7 "ask": [8 "Bash(git push:*)"9 ]10 }11}
Bash(curl:*)는 "curl로 시작하는 모든 명령어를 차단"한다는 의미입니다(끝의 :*는 "뒤에 오는 모든 것"을 나타냅니다). 한 가지 중요한 점은 공식 문서에 따르면 GitHub 같은 특정 대상에 대해서만 curl을 허용하려는 시도는 리디렉션을 통해 쉽게 우회될 수 있기 때문에, 인터넷 통신을 완전히 차단하고 필요한 페치는 별도의 안전한 포트를 통해 통합하는 것이 공식 권장 사항입니다 (권한 설정 - 공식 문서). 이 "안전한 포트"는 WebFetch(인터넷 검색을 위한 Claude Code 내장 기능)이며, 여기서 대상을 화이트리스트에 추가할 수 있습니다.
조치 ③: 비밀 파일 읽기 및 시스템 변경 방지
비밀번호가 있는 .env 파일이나 시스템 깊숙이 변경하는 sudo 명령어와 같은 비밀 정보 자체에 대한 접근도 차단합니다.
1{2 "permissions": {3 "deny": [4 "Read(.env)",5 "Read(.env.*)",6 "Read(**/.ssh/**)",7 "Bash(sudo:*)"8 ]9 }10}
Read(.env)를 작성하면 작업 폴더 아래 모든 수준에서 .env를 읽을 수 없게 됩니다. 안전을 위해 알아야 할 점은, 이 deny 목록이 Claude의 자체 파일 읽기나 cat 같은 명백한 명령어에는 효과적이지만, AI가 작성한 스크립트가 백그라운드에서 은밀하게 파일을 여는 것을 완전히 막을 수는 없다는 것입니다 (권한 설정 - 공식 문서). 그래서 조치 ④가 필요합니다.
조치 ④: "도달 범위"를 샌드박스로 감싸기
deny 목록이 특정 명령어에 선을 긋는 것이라면, 샌드박스는 OS 수준에서 벽을 만듭니다. AI가 작업 폴더 밖의 어떤 것도 건드리거나 허용된 인터넷 도메인 이외의 것에 연결하는 것을 물리적으로 제한합니다.
1{2 "sandbox": {3 "enabled": true,4 "network": {5 "allowedDomains": ["*.github.com", "registry.npmjs.org"]6 }7 }8}
활성화되면, AI가 실수로 비밀 파일에 접근하려고 해도 "샌드박스" 밖에 있기 때문에 닿을 수 없습니다. 공식 문서는 최종 경계선을 위해 deny 목록(조치 ② & ③)과 샌드박스를 함께 계층화해야 한다고 설명합니다 (샌드박싱 - 공식 문서). 개별 규칙과 외부 울타리를 동시에 갖추는 것으로 생각하면 됩니다.
한 가지 제약: 샌드박싱은 macOS, Linux 및 WSL2(Windows의 Linux)에서 작동하지만 네이티브 Windows에서는 지원되지 않습니다. Windows 중심의 작업 환경이라면 조치 ①~③의 권한 설정을 강화하는 방향으로 결정해야 합니다.
조치 ⑤: AI가 매번 "보호할 것"을 읽도록 만들기
마지막으로, 엄격한 설정과는 다른 각도에서 회사의 보안 정책을 AI가 매번 읽는 지침서에 작성하는 방법입니다. 설정이 "물리적인 자물쇠"라면, 이는 "직장 수칙 재검토"와 같습니다.
이를 수행하는 여러 기술적 방법이 있으며, Mercari가 어떤 방법을 사용했는지는 자료에서 명확하지 않습니다. 하지만 가장 쉬운 방법은 CLAUDE.md라는 파일을 작업 폴더에 직접 만들고 내부 규칙을 나열하는 것입니다. Claude Code는 매번 이 파일을 읽습니다.
1# 보안 요청사항2- .env 또는 키 파일 (~/.ssh/ 등)을 열지 마십시오.3- 고객 정보나 영업 비밀을 외부 서비스로 보내지 마십시오.4- 삭제 또는 게시 작업을 실행하기 전에 항상 사람과 확인하십시오.
오늘의 실천: 이 세 줄을 CLAUDE.md 파일에 붙여넣기만 하면 AI 행동에 상식적인 레이어가 하나 추가됩니다. 설정 파일보다 먼저 이것부터 시작할 수 있습니다.
오늘의 실천: 모든 것을 한 번에 구현할 필요는 없습니다. 조치 ③의 Read(.env) 줄만 .claude/settings.json 설정 파일에 추가하는 것으로 시작하세요. 프로젝트 폴더에 .claude 폴더(앞에 점 포함)를 만들고 그 안에 settings.json이라는 텍스트 파일을 저장하세요. 모든 프로젝트에 적용하려면 홈 디렉토리의 ~/.claude/settings.json에 배치하세요. 가장 효과적인 한 가지 움직임, 즉 AI가 비밀 파일을 읽지 못하게 하는 것부터 시작할 수 있습니다.
Mercari의 진짜 실력은 '배포'에 있었다
지금까지는 "무엇을 설정할지"에 대해 다뤘습니다. Mercari의 발표가 특히 실용적이었던 이유는 이러한 설정을 수백 명의 사람들에게 배포하는 방법을 다루었기 때문입니다.
일반적으로 설정 파일은 각자의 컴퓨터에 배치되므로(사용자 설정), 직원이 이를 다시 작성할 수 있습니다. 이는 "보안 설정이 배포되었지만 누군가가 비활성화했다"는 상황으로 이어집니다.
이를 해결하기 위해 Mercari는 MDM(모바일 기기 관리 - 회사가 직원 PC를 관리하는 시스템)을 사용하여 직원이 덮어쓸 수 없는 '관리형 설정'을 동시에 배포했습니다. Claude Code에는 개인 설정보다 우선하고 사용자가 변경할 수 없는 관리형 설정을 위한 지정된 위치가 있습니다. macOS의 경우 /Library/Application Support/ClaudeCode/managed-settings.json입니다 (설정 - 공식 문서). 여기에 조치 ①~④를 작성하면 현장에서 완화될 수 없습니다.
더욱 뛰어난 점은 엔지니어와 비엔지니어를 위한 안전 수준을 차별화한 것입니다.
- 엔지니어용: 어느 정도 사용자 정의가 가능하고 생산성을 크게 저해하지 않는 설정.
- 비엔지니어용: 조작할 여지가 적은 가장 안전한 기본 설정.
동일한 도구라도 사용자의 이해도에 따라 통제의 강도를 조정한 것입니다. 모든 사람을 엄격하게 제한하면 작업이 마비되고, 모든 사람을 느슨하게 하면 사고가 발생합니다. 이 문제를 배포되는 설정을 다르게 하여 해결했습니다.
중소기업이 따라할 수 있는 부분
대부분의 회사에는 MDM이 없을 것입니다. 괜찮습니다. 규모에 관계없이 작동하는 Mercari 설계의 일부를 추출할 수 있습니다.
필요한 것은 안전 설정이 포함된 단일 파일을 배포하고 배치하도록 하는 것뿐입니다. MDM이 있으면 관리형 설정으로 배포하고, 없으면 공유하면서 ".claude/ 폴더에 이 settings.json을 넣어주세요"라고 말하면 됩니다. 강제성은 낮지만 방향은 동일합니다.
최소한의 세트로, 조치 ①~③을 결합하면 다음과 같습니다. 이것을 기초로 사용하고 회사에서 금지하려는 특정 명령어를 추가하는 것을 권장합니다.
1{2 "permissions": {3 "disableBypassPermissionsMode": "disable",4 "deny": [5 "Bash(curl:*)",6 "Bash(wget:*)",7 "Bash(sudo:*)",8 "Read(.env)",9 "Read(.env.*)",10 "Read(**/.ssh/**)"11 ],12 "ask": [13 "Bash(git push:*)",14 "Bash(rm:*)"15 ]16 }17}
위에서부터: 확인 우회 비활성화, 인터넷 통신 및 관리자 작업 차단, 비밀 파일 읽기 금지, 삭제 또는 게시는 항상 확인. 내용을 이해하지 못해도 복사해서 붙여넣으면 작동합니다.
비엔지니어에게 배포하는 경우 샌드박스(조치 ④)를 추가한 가장 안전한 버전을 권장합니다. 두 설정을 하나의 파일로 결합한 모습은 다음과 같습니다.
1{2 "permissions": {3 "disableBypassPermissionsMode": "disable",4 "deny": [5 "Bash(curl:*)",6 "Bash(wget:*)",7 "Bash(sudo:*)",8 "Read(.env)",9 "Read(.env.*)",10 "Read(**/.ssh/**)"11 ],12 "ask": [13 "Bash(git push:*)",14 "Bash(rm:*)"15 ]16 },17 "sandbox": {18 "enabled": true,19 "network": {20 "allowedDomains": ["*.github.com", "registry.npmjs.org"]21 }22 }23}
단순히 permissions와 sandbox를 쉼표로 구분하여 나란히 배치했습니다. allowedDomains는 회사에서 사용하는 서비스에 맞게 변경하세요. 샌드박싱은 macOS, Linux 및 WSL2에서 작동한다는 점을 기억하세요.
도입 지원 시 항상 말하는 것은 완벽을 추구하다가 멈추지 말라는 것입니다. Mercari처럼 다층 방어를 바로 구축할 수 없더라도, 한 줄로 .env를 보호하는 것만으로도 사고 확률을 크게 낮출 수 있습니다.
오늘의 실천: 회사에서 한 명이라도 Claude Code를 사용하기 시작했다면, 최소 세트를 텍스트로 공유하고 .claude/settings.json에 붙여넣도록 하세요. 배포 연습용으로 딱 좋은 크기입니다.
주의사항: 설정 배포 전 알아야 할 3가지
보안을 강화하는 작업이기 때문에, 오해하면 위험한 지점들이 있습니다.
- "deny 목록을 작성한다고 해서 완벽하게 안전한 것은 아닙니다". 조치 ③에서 언급했듯이, deny 목록은 스크립트가 백그라운드에서 할 수 있는 모든 것을 막을 수 없습니다.
curl을 막아도 다른 통신 방법이 남아 있을 수 있습니다. 진정으로 차단하려면 샌드박스(조치 ④)와 계층화하는 전제를 잊지 마세요. - "인수(argument) 기반 필터링에 의존하지 마세요". Anthropic 자체에서도 특정 URL에 대해서만
curl을 허용하는 것과 같은 조건부 권한은 쉽게 깨진다고 경고합니다. 위험한 것을 완전히 차단하고 안전한 대안 하나를 제공하는 것이 더 견고합니다. - "설정을 배포하고 끝내지 마세요". 관리형 설정을 강제하더라도 직원이 스스로 다른 의심스러운 도구를 설치하면 의미가 없습니다. 설정은 "사고를 줄이기 위한 메커니즘"이며, 사용 교육과 함께할 때 가장 효과적입니다. 여기서 조치 ⑤인 "규칙을 읽도록 하는 것"이 비로소 빛을 발합니다.
중급 사용자 FAQ
Q. 개인용으로 설정하는 것이 의미가 있나요?
네. 기준은 회사용이 아닌 그 컴퓨터에 비밀 정보가 있는지 여부입니다. 프리랜서와 개인 개발자도 로컬에 .env와 ~/.ssh/가 있습니다. 최소한 조치 ③의 읽기 금지는 포함하는 것이 더 안전합니다.
Q. 권한을 제한하면 AI가 쓸모없어지지 않나요?
제한하는 방법의 문제입니다. 읽기 전용 명령어(예: ls 또는 cat)는 기본적으로 확인 없이 작동하므로 일상적인 작업이 거의 중단되지 않습니다. 중단되는 것은 삭제, 게시, 인터넷 통신 등 잘못되면 피해가 발생하는 작업입니다. 실제로 "위험할 때만 사람이 확인"하는 방식으로 전환하면 AI가 자동으로 수행하도록 맡기는 범위를 안전하게 확장할 수 있습니다.
Q. `settings.json`과 관리형 설정(`managed-settings.json`)의 차이점은 무엇인가요?
위치와 "강도"가 다릅니다. 프로젝트의 .claude/ 폴더에 있는 settings.json은 누구나 편집할 수 있는 공유 설정입니다. managed-settings.json은 회사에서 배포하며 사용자가 변경할 수 없습니다. 개인이나 소규모 그룹에게는 전자로 충분하며, "누군가 설정을 완화하는 것이 문제"가 되는 단계에 이르렀을 때 후자로 전환하세요.
Q. Cursor나 다른 AI 코딩 도구에도 같은 생각을 적용할 수 있나요?
보호하려는 대상(비밀, 위험한 작업, 도달 범위)은 동일하므로 개념은 적용됩니다. 하지만 구문과 샌드박싱의 존재 여부는 도구마다 다르므로, 이 settings.json 표기법은 Claude Code에 특화된 것으로 간주하세요. 다른 도구를 사용한다면, 각각의 공식 문서에 이 동일한 세 가지 관점을 적용하는 것이 빠른 방법입니다.
요약: "사용하지 말자"에서 "안전하게 배포하자"로
AI 도입에 관한 컨설팅을 받을 때, 가장 흔한 반응은 "위험하니까 아직 사용하게 할 수 없습니다"였습니다. 하지만 그 결정은 모든 편리함도 함께 던져버리는 것입니다.
Mercari는 그 이분법적 선택에서 벗어날 방법을 보여주었습니다. 확인 우회를 비활성화하고, 위험한 작업을 중단하고, 비밀 파일 접근을 금지하고, 샌드박스로 감싸고, 규칙을 읽도록 만드세요. 그런 다음, 조작할 수 없는 설정으로 모두에게 배포하세요. "무서우니까 금지"에서 "무서우니까 통제를 달고 배포"로 바꾸는 설계입니다.
- 보호 대상: 비밀 유출 방지 / 위험한 작업 방지 / 도달 범위 좁히기.
- Mercari의 5가지 조치: 우회 비활성화, 위험한 명령어 제한, 비밀 파일 금지, 샌드박스, 규칙 읽기.
- 배포: 사용자가 덮어쓸 수 없는 관리형 설정을 사용하고, 이해도에 따라 차별화.
마지막으로, 오늘부터 시작할 수 있는 세 단계입니다.
- 자신의 컴퓨터에 `Read(.env)` 추가하기: 비밀 파일 읽기 금지부터 시작하세요. 이것이 가장 효과적인 한 가지 움직임입니다.
- 최소 세트로 단일 파일 만들기: 위의
permissions예제를 기반으로 회사에서 중단하려는 명령어를 추가하세요. - 회사 내 한 명에게 배포하여 테스트하기:
.claude/settings.json에 붙여넣게 하고 작업이 중단되지 않는지 함께 확인하세요.
첫 단계는 .env를 보호하는 단 한 줄입니다. 거기서부터 하나씩 완벽한 다층 방어 체계를 쌓아갈 수 있습니다. 오늘 그 첫 번째 파일을 배치하여 "무서워서 멈추는 것"을 "통제하며 위임하는 것"으로 바꿔보는 건 어떨까요?
