Claude Code 서버 관리 설정 vs Codex 관리형 정책: 개발팀 권한 통제는 무엇을 고를까

TL;DR

핵심 3줄 요약

이 글에서 다룰 내용

먼저 답: 정책의 배포 단위로 고르세요

개발팀이 “위험한 명령을 막자”라고만 적으면 선택이 어렵습니다. 요구 문장을 배포 단위까지 구체화하세요.

현재 Claude Code 조직 사용자 모두에게 같은 JSON 정책을 적용하려면 Claude Code server-managed settings를 검토합니다. 공식 문서는 현재 설정이 조직의 모든 사용자에게 균일하게 적용되며 그룹별 구성은 아직 지원하지 않는다고 밝힙니다.

지원되는 로컬 Codex 클라이언트에 requirements.toml 호환 제약을 만들고 적용 대상을 할당하려면 Codex managed configuration을 검토합니다. 이 정책은 ChatGPT 워크스페이스 접근이나 좌석, RBAC를 부여하지 않습니다. 로컬 런타임 정책과 워크스페이스 권한은 별도입니다.

두 형식을 한 번에 배포하거나 자동 변환하는 절차는 공식 문서에 없습니다. 혼합 환경이라도 첫 파일럿에서는 실제로 채택한 제품의 한 경로만 실행하세요.

두 기능을 한 문장으로 정의하면

선택 기준 1: 모든 사용자에게 같은 정책이 필요한가

Claude Code server-managed settings를 저장하면 설정 변경이 조직의 모든 사용자에게 영향을 줍니다. 같은 조직 안에서 개발팀 A와 B에 서로 다른 server-managed settings를 주는 그룹별 구성은 현재 지원되지 않습니다.

이 특성은 전사 공통 금지선을 한곳에서 관리할 때 단순합니다. 반대로 소수 그룹만 대상으로 시험해야 한다면 운영 조직에 바로 저장하지 마세요. 별도 승인된 테스트 조직을 사용하거나, 먼저 한 테스트 기기에 endpoint-managed 설정을 배포해 동작을 확인하는 편이 안전합니다. endpoint-managed와 server-managed는 공식 문서가 구분하는 별도 전달 경로입니다.

Codex cloud-managed requirements는 로그인한 identity에 해당하는 정책 묶음을 지원 클라이언트가 받는 방식입니다. 공식 문서는 Managed configuration에서 정책을 만들고 할당하며, 정책별 소유자와 대상 사용자 또는 그룹을 기록하라고 안내합니다. 구체적인 할당 규칙은 복사한 설명에 기대지 말고 현재 관리 화면에서 직접 확인합니다.

선택 기준 2: 강제 제약과 기본값을 분리해야 하는가

Claude Code에서는 관리형 설정이 다른 일반 설정 계층보다 우선합니다. 명령줄이나 사용자·프로젝트 설정은 관리형 권한 규칙을 덮어쓸 수 없습니다. 다만 공식 문서가 열거한 보안 민감 예외에서는 하위 계층의 더 엄격한 값이 적용될 수 있습니다. allowManagedPermissionRulesOnly 를 켜면 권한 규칙의 출처를 관리형 설정으로 제한할 수 있고, permissions.disableBypassPermissionsMode 를 "disable" 로 두면 bypass 권한 모드를 막을 수 있습니다.

{
"permissions": {
"deny": [
"Read(./.env)",
"Read(./secrets/**)"
],
"disableBypassPermissionsMode": "disable"
},
"allowManagedPermissionRulesOnly": true
}

이 예시는 Anthropic 공식 문서의 구조를 좁혀 옮겼습니다. 실제 경로와 업무 명령을 추가하기 전에는 테스트 저장소에서 확인하세요. 특히 allowManagedPermissionRulesOnly 는 호스트가 주는 allow 규칙까지 제외할 수 있으므로 Cowork 작업 폴더 같은 인접 표면에 그대로 일반화하지 않습니다.

Codex에서는 requirements.toml 과 managed defaults의 목적을 분리합니다. 승인 정책, 승인 검토자, 권한 프로필, 웹 검색, 관리형 hooks, 허용 MCP 서버 같은 항목을 사용자가 약화하지 못하게 하려면 requirements에 둡니다. managed defaults는 표준 시작값이지만 실행 중 바뀔 수 있습니다.

Codex 0.138.0 이상에서는 allowed_permission_profiles 와 관리형 default_permissions 를 우선 검토하라고 공식 문서가 안내합니다. 이전 버전은 이 두 항목을 무시할 수 있습니다. 혼합 버전 조직이라면 클라이언트 목록부터 확인하세요.

default_permissions = ":workspace"
[allowed_permission_profiles]
":read-only" = true
":workspace" = true

위 예시는 읽기 전용과 workspace 범위만 허용하고 :danger-full-access 를 목록에서 제외합니다. 이 설정만으로 네트워크, 연결 서비스 권한, 저장소 보호 규칙까지 해결되는 것은 아닙니다.

선택 기준 3: 시작 실패와 캐시를 어떻게 다룰 것인가

원격 정책은 저장 성공만 보고 끝내면 안 됩니다. 네트워크 장애와 캐시가 실제 시작 동작을 바꿀 수 있습니다.

Claude Code는 시작할 때 서버 관리 설정을 가져오고 실행 중에는 주기적으로 갱신합니다. 캐시가 없는 첫 실행에서 fetch가 실패하면 기본적으로 server-managed settings 없이 계속하고 대화형 세션에 경고합니다. 이 동작이 허용되지 않는 조직은 관리 소스에 forceRemoteSettingsRefresh: true 를 두어 새 원격 설정을 받지 못하면 CLI가 종료되도록 할 수 있습니다. 다만 api.anthropic.com 이 막히면 사용자가 Claude Code를 시작하지 못합니다. 별도 승인과 rollback을 미리 잡아 두세요.

Codex cloud-managed requirements는 유효하고 identity가 일치하는 캐시를 먼저 확인합니다. 유효 캐시가 없고 fetch가 실패하거나 시간 초과되면 관리형 제약 없이 조용히 시작하지 않고 오류를 반환합니다. 현재 프로세스가 시작된 뒤 받은 background refresh는 다음 시작에 쓸 캐시를 바꾸며, 실행 중인 프로세스의 requirements를 교체하지 않습니다.

두 제품의 실패 동작을 같다고 가정하지 마세요. 운영팀은 허용된 시작, fetch 실패, 유효 캐시 존재 여부를 각각 시험합니다. 결과도 따로 기록합니다.

개발팀 권한 정책을 고르는 실행 순서

1단계. 요구 문장을 네 칸으로 나눕니다

승인된 내부 요구사항 한 건만 가져옵니다. 정책 대상, 적용 제품, 허용할 정상 작업, 반드시 차단할 동작을 각각 한 줄로 적습니다. “보안을 강화한다”처럼 결과를 확인할 수 없는 표현은 완료 기준으로 쓰지 않습니다.

예시는 다음과 같습니다.

• 정책 대상: 승인된 개발자 계정 또는 테스트 조직
• 정상 작업: 테스트 저장소의 README.md 읽기
• 차단 작업: 테스트 저장소의 가짜 .env 읽기 또는 허용하지 않은 full-access 선택
• 승인자: 보안 담당자와 개발 플랫폼 담당자

2단계. 한 제품의 한 경로만 선택합니다

조직 사용자 모두에게 같은 Claude Code 정책이 필요하면 Claude 경로를 선택합니다. 대상 할당형 requirements.toml 제약이 필요하고 지원되는 Codex 로컬 표면을 운영한다면 Codex 경로를 선택합니다.

선택 사유를 한 문장으로 남기세요. 제품명이나 선호도가 아니라 배포 단위와 검증할 통제로 설명해야 나중에 판단을 재현할 수 있습니다.

3단계. 저장 전 변경안을 검토합니다

원본 설정을 별도로 보존하고 변경안에는 필요한 제한만 둡니다. 실제 secret, 운영 저장소, 원격 push, 삭제 명령은 테스트 입력에서 제외합니다.

Claude 경로에서는 Admin Settings > Claude Code > Managed settings에 넣을 JSON을 먼저 코드 리뷰합니다. 운영 조직에서 Save를 누르면 모든 사용자에게 영향을 줄 수 있으므로 테스트 조직이나 승인된 endpoint-managed 시험을 먼저 마칩니다.

Codex 경로에서는 현재 Managed configuration 화면에서 requirements.toml 호환 정책을 만들고 대상과 지원 클라이언트 버전을 확인합니다. managed defaults를 강제 제약으로 오인하지 않았는지도 검토합니다.

4단계. 비민감 fixture에서 정상 작업을 확인합니다

가짜 .env 와 일반 README.md 만 있는 전용 테스트 저장소를 사용합니다. 먼저 허용한 README.md 읽기가 정상적으로 끝나는지 확인합니다. 차단만 확인하면 정책 때문에 정상 개발까지 막힌 사실을 놓칠 수 있습니다.

테스트 결과에는 계정, 제품, 클라이언트 버전, 정책 식별자, 실행 시각, 정상 작업 결과를 적습니다. 정책 hash를 남기고 싶다면 내부 증적 규칙으로 별도 정의하세요. 두 제품이 자동으로 만드는 공통 감사 필드라고 쓰면 안 됩니다.

5단계. 의도한 차단과 유효 설정을 확인합니다

Claude Code 사용자는 재시작 뒤 /permissions 에서 유효 권한 규칙을 확인합니다. Claude Code v2.1.248 이상이라면 claude doctor 의 Managed settings (remote) 행에서 설정 로드, 미설정, fetch 실패, fetch 생략 상태를 구분할 수 있습니다. 그런 다음 가짜 .env 읽기가 거부되는지 확인합니다.

Codex 사용자는 지원 클라이언트에서 effective settings를 확인하고, 허용 목록에서 제외한 full-access 권한 프로필을 선택할 수 없는지 시험합니다. 이어 README.md 읽기가 계속 가능한지 다시 확인합니다. workspace role이나 대상 그룹에 속했다는 사실만으로 정책 집행을 통과 처리하지 않습니다.

6단계. 확대와 rollback을 사람이 결정합니다

허용 동작과 차단 동작이 모두 기대와 일치해야 파일럿이 끝납니다. 한쪽이라도 다르면 원래 정책으로 돌리고 원인을 정책 미수신 , 지원 버전 불일치 , 규칙 오류 , 승인 대기 로 나눠 기록합니다.

조직 전체 확대, 더 넓은 파일 접근, 네트워크 허용, MCP 추가, hooks 실행은 별도 변경입니다. 첫 파일럿 결과만으로 묶어서 승인하지 않습니다.

복사해서 쓰는 정책 선택 검토 프롬프트

아래 프롬프트는 정책을 자동 적용하지 않습니다. 변경안을 검토용 문서로 정리하는 데만 사용하세요.

실무에서 놓치기 쉬운 인사이트

주의할 점

자주 묻는 질문

출처

마무리

선택은 한 문장으로 끝낼 수 있습니다. 모든 Claude Code 사용자에게 같은 조직 공통 정책이 필요하면 server-managed settings를, 지원되는 로컬 Codex 클라이언트에 관리자 제약을 만들고 할당해야 하면 managed configuration을 검토합니다.

어느 쪽을 고르든 저장 버튼이 완료 지점은 아닙니다. 비민감 fixture에서 정상 작업과 차단 작업을 확인하고 실제 유효 설정을 기록한 뒤 사람이 확대를 승인하세요.