Claude Code 서버 관리 설정 — 정책을 내려도 사용자가 거부하면 종료되고, 추적을 끄는 값만 묻지 않습니다

전에 컨테이너에 넣은 정책은 저장소 권한자면 지울 수 있다는 글을 쓰면서, 우회할 수 없는 경로는 서버 관리 설정이나 기기 관리 시스템 둘뿐이라고 적었습니다. 그 서버 관리 설정을 이번에 뜯어봤는데, "우회 불가"라는 말이 생각보다 조건부였습니다. 조직이 정책을 내려도 어떤 항목은 사용자가 승인해야 적용되고, 거부하면 도구가 그냥 종료됩니다. 반대로 묻지도 않고 적용되는 항목이 따로 있는데, 그 경계가 흥미로웠습니다.

📌 30초 요약

• 기기 관리 시스템이 있으면 오히려 그쪽이 더 강합니다. 문서가 직접 그렇게 적어놨습니다.
• 두 관리 소스는 섞이지 않습니다. 서버 쪽이 키를 하나라도 내려주면 기기 쪽은 통째로 무시됩니다.
• 셸 명령·훅·관리 지시문·일부 환경 변수는 사용자 승인이 필요합니다. 거부하면 종료됩니다.
• 추적을 끄는 값은 묻지 않고 적용하고, 그 밖의 값이면 창을 띄웁니다. 변수 이름이 아니라 값으로 판단합니다.
• 기본값은 가져오기가 실패해도 그냥 진행합니다. 첫 실행에는 정책이 안 걸린 짧은 구간이 있다고 문서가 인정합니다.
• 실패 시 종료하도록 강제할 수 있는데, 그러면 망이 막히면 아무도 못 켭니다.

기기 관리가 있으면 그쪽이 더 강합니다

중앙 설정 방식이 둘입니다. 서버 관리 설정은 인증 시점에 앤트로픽 서버에서 내려받고, 기기 관리 설정은 운영체제 정책이나 관리 설정 파일로 기기에 직접 배포됩니다. 그런데 문서가 기기 쪽이 더 강한 보안 보장을 준다고 먼저 인정합니다 — 설정 파일을 운영체제 수준에서 사용자 수정으로부터 보호할 수 있어서입니다.

방식	맞는 조직	약한 지점
서버 관리	기기 관리 체계가 없거나, 관리되지 않는 기기를 쓰는 곳	일부 항목이 사용자 승인을 요구
기기 관리	기기 관리 체계를 이미 갖춘 곳	클라우드 세션에는 안 닿음

표의 마지막 칸이 실무에서 갈리는 지점입니다. 기기 관리 설정은 앤트로픽이 호스팅하는 클라우드 세션까지 닿지 않습니다. 그래서 웹에서도 쓰는 조직이라면 서버 관리 설정을 같이 구성해야 합니다. 여기에 현재 한계 세 가지도 붙습니다 — 조직 전체에 균일하게만 적용되고 그룹별 구성은 아직 안 되며, MCP 서버 허용·거부 목록 파일은 이 경로로 배포할 수 없고, 운영체제 정책 전용 설정은 무시됩니다.

두 소스는 섞이지 않습니다

둘 다 설정 계층의 최상단이라 명령줄 인자로도 못 덮습니다. 문제는 둘을 다 설정해뒀을 때인데, 규칙이 명확합니다 — 비어 있지 않은 구성을 주는 첫 번째 소스를 쓰고, 서버 쪽을 먼저 확인합니다. 즉 서버 관리 설정이 키를 하나라도 내려주면 기기 관리 설정은 통째로 무시됩니다. 병합이 아니라 선택이라는 뜻이죠. 정책 담당자가 "둘 다 걸어놨으니 둘 다 먹겠지" 하고 넘어가면 한쪽이 조용히 사라집니다.

🔁 되돌리려고 지워도 바로 안 돌아갑니다

문서가 친절하게 경고하는 대목입니다. 관리 콘솔에서 서버 구성을 비우고 기기 정책으로 되돌리려는 경우, 클라이언트에 캐시된 설정이 다음 성공적인 가져오기 전까지 그대로 남습니다. 그래서 "지웠는데 왜 아직 그대로지"가 생기죠. 지금 어느 소스가 활성인지는 상태 확인 명령으로 볼 수 있습니다. 예외도 둘 있는데 — 샌드박스 허용목록 잠금 같은 일부 잠금 키는 관리자가 통제하는 아무 소스에서든 설정하면 반영되고, 환경 변수 블록은 키 단위로 병합됩니다. 각 변수마다 우선순위가 높은 소스가 이기고, 낮은 소스가 비어 있는 변수만 채웁니다. 다만 이 병합은 특정 버전 이상에서만 되고, 그 전에는 이긴 소스의 블록만 통째로 적용됐습니다.

측정 쪽에 재밌는 규칙이 하나 더 있습니다. 내보내기 관련 변수들은 한 덩어리로 움직입니다. 그중 하나라도 설정한 가장 높은 소스가 그 묶음 전체를 가져가고요. 그런데 자격증명 키를 함께 주는 소스는 이기지 못하면 아무것도 기여하지 않으면서, 낮은 소스가 그 자리를 채우는 것도 막습니다. 이유는 분명합니다 — 한 소스의 수집 주소와 다른 소스의 자격증명이 짝지어지는 일을 막으려는 것이죠. 사용량을 어떻게 재는지는 따로 정리해 둔 글이 있는데, 그 설정을 조직이 내려줄 때는 이 묶음 규칙을 알고 있어야 합니다.

정책을 내려도 사용자가 거부하면 종료됩니다

여기가 이 문서에서 가장 뜻밖이었습니다. 보안상 위험할 수 있는 설정은 적용 전에 사용자의 명시적 승인을 받습니다. 네 가지인데 — 셸 명령을 실행하는 설정, 승인이 필요한 환경 변수, 훅 정의 전부, 그리고 관리 설정으로 내려주는 지시문 내용입니다. 이런 게 들어 있으면 무엇을 설정하려는지 설명하는 창이 뜨고, 사용자가 거부하면 도구가 종료됩니다.

승인은 설정 폴더에 기록되는데, 기록 방식이 인증 수단에 따라 갈립니다. 계정 로그인이면 조직당 하나이고 가장 최근에 승인한 계정이 그걸 쥡니다. 그 밖의 자격증명이면 전달된 설정 한 벌에 대해 하나이고 캐시본과 함께 보관되며, 승인이 필요한 설정이 바뀌면 창이 다시 뜹니다. 재밌는 건 계정 로그인 쪽인데 — 같은 조직에 다른 계정으로 들어가면 설정이 그대로여도 창이 다시 뜨고, 그 계정의 승인이 이전 것을 대체해서 원래 계정으로 돌아가면 또 한 번 뜹니다.

🤖 비대화형 실행은 승인으로 기록되지 않습니다

자동화로 돌리는 경우가 문제입니다. 비대화형 실행은 창을 띄울 수 없습니다. 그럴 때 도구는 그 실행에 한해서만 설정을 적용하고, 승인으로 기록하지도, 캐시에 쓰지도 않습니다. 그래서 사람이 대화형에서 한 번 승인하기 전까지 비대화형 실행은 매번 설정을 새로 가져옵니다.

여기에 자기 수정 이력이 붙어 있는 게 인상적이었습니다 — 특정 버전 이전에는 비대화형 실행이 설정을 승인된 것으로 저장해버려서, 이후 대화형 세션에서 그 창이 아예 안 떴다고 문서가 적어놨습니다. 즉 사람이 한 번도 못 본 정책이 승인된 것으로 남는 경로가 있었고, 그걸 막은 것이죠. 대화형인데도 창을 못 띄우는 상황이면 전달된 설정을 적용하지 않고 마지막으로 승인된 설정을 유지합니다.

묻는 값과 안 묻는 값이 갈립니다

환경 변수는 전부 묻는 게 아닙니다. 묻지 않고 적용되는 쪽은 기능·명령 토글, 모델 선택과 동작 설정(쓸 모델·캐싱 끄기·추론 강도), 컨텍스트와 압축 설정, 터미널 화면과 접근성 옵션, 숫자 한도와 예산·시간 제한입니다. 반면 프록시·기본 주소·측정 수집 주소는 값이 비어 있지 않으면 항상 묻습니다. 창에는 어떤 변수를 설정하려는지 이름이 표시돼서, 정책이 무엇을 요구하는지 사용자가 보게 돼 있습니다.

🔍 프라이버시 토글 넷은 이름이 아니라 값으로 판단합니다

가장 설계 의도가 선명한 대목입니다. 비필수 통신 끄기·오류 보고 끄기·측정 끄기·추적 거부 네 개는 변수 이름이 아니라 전달된 값을 보고 승인 필요 여부를 정합니다. 참에 해당하는 값은 추적과 보고를 끄는 방향뿐이라 묻지 않고 적용하고, 그 밖의 비어 있지 않은 값이면 창을 띄웁니다. 정리하면 "덜 보내는 쪽으로 가는 건 조용히, 더 보내는 쪽으로 가는 건 물어본다"는 규칙입니다. 조직이 사용자 몰래 수집을 켜는 경로를 막아둔 셈이죠. 이것도 이전 버전에서는 넷 중 셋이 어떤 값이든 묻지 않고 적용됐다고 문서가 자기 이력을 밝혀뒀습니다.

가져오기가 실패하면 어떻게 되나

기본 동작을 문서가 솔직하게 적습니다. 시작할 때 가져오기가 실패하면 관리 설정 없이 그냥 계속 진행합니다. 게다가 캐시가 없는 첫 실행에는 설정이 로드되기 전 짧은 구간이 있고, 그동안은 제한이 적용되지 않는다고 인정합니다. 캐시가 있으면 즉시 적용되고 망 장애에도 유지되지만, 일부 환경 변수는 서버가 확인해 줄 때까지 보류됩니다.

보류되는 이유가 특히 좋았습니다. 보류 대상은 프록시와 인증서, API 라우팅과 공급자 선택, 인증 자격증명, 설정 폴더 선택자인데 — 캐시된 프록시나 인증서, 엔드포인트, 자격증명 값이 "그 페이로드를 확인해 주는 바로 그 요청"을 다른 데로 돌리거나 가로채거나 다시 인증시키는 걸 막기 위해서입니다. 즉 자기를 검증하는 요청을 자기가 조작하지 못하게 끊어놓은 것이죠. 이 보호는 서버에서 받아온 캐시에만 적용되고 기기 관리로 배포한 값은 영향을 받지 않습니다.

그 짧은 무방비 구간조차 허용할 수 없다면 실패 시 종료하도록 강제하는 설정이 있습니다. 켜면 새로 가져오기가 성공할 때까지 시작을 막고, 실패하면 진행하는 대신 종료합니다. 이 설정은 스스로 이어집니다 — 서버에서 한 번 내려오면 로컬에도 캐시돼 다음 시작부터 같은 동작을 강제합니다. 다만 문서가 대가를 분명히 적습니다 — 해당 주소에 연결할 수 없으면 사용자가 도구를 아예 시작할 수 없습니다. 그래서 켜기 전에 망 정책부터 확인하라고 하고요. 예외가 하나 있는데, 인증 관련 하위 명령은 이 검사에서 면제됩니다. 만료된 자격증명 때문에 가져오기가 실패한 경우 재인증할 길은 열어둔 것입니다.

🙋 정직하게 밝혀둘 것

• 제가 조직 콘솔에서 직접 내려보지 않았습니다. 관리자 화면이 어떻게 생겼는지, 반영까지 실제로 얼마나 걸리는지는 제가 확인한 값이 없습니다.
• "승인 창이 있으니 조직이 통제 못 한다"는 뜻이 아닙니다. 승인이 필요한 건 네 갈래뿐이고, 권한 규칙 같은 대부분의 정책은 묻지 않고 최상단으로 적용됩니다.
• 반대로 "승인은 형식일 뿐"도 아닙니다. 거부하면 실행 자체가 종료되고, 비대화형은 승인으로 기록되지 않습니다. 형식이었다면 굳이 이렇게 만들 이유가 없습니다.
• 버전 경계가 유난히 많은 문서입니다. 병합 규칙·보류 대상·승인 기록 방식이 전부 특정 버전을 기준으로 달라져서, 도입 전에 조직의 최소 버전을 먼저 정하는 편이 낫겠습니다.

🗺️ AI 지출 전체 지도

정책은 결국 돈이 새는 경로를 막는 장치이기도 합니다. 모델 선택, 캐싱, 추론 강도, 예산과 한도까지 묻지 않고 적용되는 항목에 다 들어 있으니까요. 구독과 종량제 선택부터 캐시, 모델 조합, 상한 걸기까지 지금까지 확인한 것들을 일곱 단계 지도 한 장으로 묶어뒀습니다.

🔁 관리형에만 둘 수 있는 키가 따로 정리됐습니다

설정 키 전체 참조 문서에서 관리형 전용 키가 명시적으로 표시되기 시작했습니다. 로그인 경로 강제·접속 허용 목록·관리형 연결만 허용에 더해, 판올림 하한과 상한을 정해 범위 밖이면 아예 시작을 거부하는 키, 명령줄 플래그로 확장을 얹는 것 자체를 거부하는 키, 스킬·에이전트·훅·연결을 사용자·프로젝트 출처에서 전면 차단하는 키가 함께 있습니다. 이 키들은 사용자 설정에 같은 이름으로 적어도 읽히지 않습니다 — 정책을 어디에 거느냐가 전부라는 이 글의 결론이 키 단위로도 확인되는 셈입니다.

자주 묻는 것

Q. 조직이 지시문을 통째로 내려줄 수도 있나요?

됩니다. 다만 승인이 필요한 네 갈래 중 하나라 사용자에게 창이 뜹니다. 개인이 쓰는 지시문과는 층이 다른데, 제가 짧고 좋은 지시문의 사례를 정리한 적이 있습니다 — 그건 내가 쓰고 내가 고치는 파일이고, 이건 조직이 내려주고 내가 못 지우는 내용입니다. 둘이 같이 있을 때 어느 쪽이 이기는지가 헷갈릴 수 있는데, 관리 설정은 설정 계층의 최상단이라 개인 파일로는 못 덮습니다. 그래서 조직 지시문은 짧고 규칙적일수록 낫습니다 — 사용자가 자기 지시문으로 조정할 여지가 없으니까요.

Q. 잘못된 항목을 하나 내려보내면 전체가 죽나요?

아닙니다. 형식 검사에 걸린 항목만 골라내고 검증 오류를 보여준 뒤 나머지 유효한 설정은 그대로 적용합니다. 캐시에도 걸러낸 뒤의 페이로드만 저장되고 원본은 남기지 않고요. 하나도 못 건지는 경우에만 마지막으로 받아들인 캐시를 유지하고 치명 오류로 기록합니다. 승인 창도 걸러낸 뒤의 내용을 기준으로 평가해서, 제거된 항목이 승인 대상으로 뜨거나 실행되는 일은 없습니다. 배포 전에는 테스트 기기에서 진단 명령으로 먼저 검증하라는 게 문서 권고입니다.

Q. 그럼 컨테이너에 정책을 넣는 건 의미가 없나요?

아닙니다. 층이 다릅니다. 컨테이너에 넣은 정책은 기본값을 팀 전체에 맞추는 데는 실제로 효과가 있고, 다만 저장소 권한자가 지울 수 있어 통제로는 못 셉니다. 반대로 서버 관리 설정은 개인이 못 덮지만 위에 적은 대로 일부 항목은 승인을 요구하고 그룹별 구분도 아직 안 됩니다. 실무적으로는 지켜야 하는 규정은 서버나 기기 관리로, 팀 편의를 맞추는 기본값은 저장소로 나누는 게 문서가 그리는 그림에 가깝습니다.

🔀 이 파일을 경쟁 도구도 읽습니다 (8월 18일 추가)

이 글은 관리 설정 파일이 어디까지 강제되는가를 다뤘습니다. 그 뒤에 알게 된 사실을 하나 붙입니다 — 다른 회사의 코딩 CLI가 이 파일을 읽어들입니다. 경쟁 제품의 엔터프라이즈 문서에 호환성 절이 따로 있어서, 이미 MDM으로 이 파일을 뿌린 조직은 그대로 쓰라고 안내합니다. 문제는 조건이 셋 붙는다는 점입니다. 첫째, 읽는 항목이 네 가지로 한정됩니다 — 권한 규칙·MCP 허용목록·일부 텔레메트리 플래그·마켓플레이스 제한. 둘째, 그쪽 자기 정책 파일이 항상 우선합니다. 셋째가 제일 중요한데, 무조건 승인 모드를 잠그는 항목은 적용되지 않습니다. 그것도 누락이 아니라 의도된 비상속이고, 문서가 이유까지 적어뒀습니다 — 보안팀이 강화해둔 공유 환경의 잠금을 물려받지 않으려고랍니다. 그러니 사내에 도구가 둘 이상이라면 이 파일 하나로 전부 커버된다는 가정은 성립하지 않습니다. 자세한 이음매는 경쟁 도구의 엔터프라이즈 문서를 뜯어본 글에 정리했습니다.

✨ 오늘 확인한 것 정리

서버 관리 설정은 설정 계층 최상단이라 개인이 못 덮지만, 셸 명령·훅·조직 지시문·일부 환경 변수는 사용자 승인을 받아야 적용되고 거부하면 종료됩니다. 그리고 추적을 끄는 값은 묻지 않고 적용, 그 밖의 값은 물어보는 식으로 이름이 아니라 값으로 갈립니다. 두 관리 소스는 섞이지 않고 서버 쪽이 키를 하나만 줘도 기기 쪽이 통째로 무시되며, 지워도 캐시가 남아 되돌리기가 바로 안 됩니다. 마지막으로 기본값은 가져오기 실패 시 그냥 진행이고, 막으려면 종료 강제 설정을 켜야 하는데 그러면 망이 막힐 때 아무도 못 켭니다.

※ 확인 경로(2026년 8월 17일 기준): code.claude.com/docs/en/server-managed-settings. 설정 항목과 변수 이름은 제가 우리말로 풀어 쓴 것입니다.

※ 병합 규칙·보류 대상·승인 기록 방식이 모두 버전에 따라 달라집니다. 도입 전에 조직의 최소 버전을 정하고, 문서의 해당 절에서 그 버전의 동작을 확인하시길 권합니다.