Claude Code managedMcpServers 운영법: 조직 공통 MCP를 안전하게 배포하는 순서

검색 의도: Claude Code managedMcpServers, Claude Code MCP 서버 조직 배포, managed settings MCP, Claude Code headless permission prompts

Claude Code 2.1.259 changelog에는 조직 단위 운영자가 볼 만한 변화가 여럿 들어 있다. 그중 가장 눈에 띄는 항목은 managedMcpServers managed setting이다. 조직은 HTTP/SSE MCP 서버를 모든 사용자에게 제공할 수 있고, .mcp.json과 같은 entry shape를 사용한다. 다만 실행 command를 포함한 entries는 skip된다고 명시돼 있다. 같은 버전에는 unattended headless host를 위한 --permission-prompts none, claude plugin validate --json, managed settings 파싱 실패 시 시작 거부 같은 운영 개선도 포함됐다.

MCP 서버를 개인별로 붙이는 단계에서는 편하다. 하지만 팀 전체로 확장하면 문제가 생긴다. 누가 어떤 MCP를 추가했는지, 어떤 서버가 민감 시스템에 연결되는지, 장애가 나면 누가 끄는지 알기 어렵다. managedMcpServers는 MCP를 “개인 설정”에서 “조직 배포 자산”으로 올리는 기능이다.

조직 공통 MCP가 필요한 순간

모든 MCP를 중앙 배포할 필요는 없다. 실험용 로컬 도구, 개인 노트 검색, 개인 productivity 서버는 개인 설정에 남겨도 된다. 중앙 배포가 필요한 것은 팀이 반복적으로 쓰고, 권한 경계가 명확하고, 장애 영향이 큰 서버다.

예를 들어 사내 문서 검색 MCP, 이슈 트래커 읽기 MCP, 배포 상태 조회 MCP, feature flag 조회 MCP는 공통 서버 후보가 된다. 반대로 로컬 shell을 실행하거나, 사용자의 파일 시스템을 넓게 읽거나, 외부 계정에 쓰기 권한을 가진 MCP는 중앙 배포 전에 별도 보안 검토가 필요하다.

조직 공통 MCP의 목적은 “도구를 많이 붙이기”가 아니다. 개발자가 매번 설정 파일을 복사하지 않아도 같은 품질의 context를 쓰게 만드는 것이다.

HTTP/SSE 서버만 배포한다는 의미

changelog에서 command를 포함한 entries가 skip된다는 점은 중요하다. 조직이 모든 사용자 머신에서 임의 command를 실행하게 만들지 않겠다는 안전장치로 볼 수 있다. 중앙 배포 대상은 HTTP/SSE MCP 서버다. 즉 서버 실행과 관리는 별도 인프라에서 하고, Claude Code 사용자는 네트워크로 연결한다.

이 구조는 운영 책임을 분리한다. MCP 서버는 플랫폼 팀이 배포하고, 인증·로그·rate limit을 서버 쪽에서 관리한다. 개발자 머신은 클라이언트 역할만 한다. 보안 사고가 났을 때도 로컬에 흩어진 command를 찾는 대신 중앙 서버를 차단하거나 설정에서 제거하면 된다.

배포 전 체크해야 할 보안 기준

MCP 서버는 모델에게 “할 수 있는 일”을 늘려준다. 그래서 API 서버보다 더 조심해야 한다. 일반 API는 사람이 명시적으로 호출하지만, MCP는 에이전트가 판단해서 호출할 수 있다. 최소 기준은 네 가지다.

첫째, read와 write를 분리한다. 처음에는 읽기 전용 MCP로 시작한다. 둘째, 서버가 반환하는 데이터에 secret, 개인 정보, 고객 원문이 섞이지 않게 필터링한다. 셋째, tool 이름과 설명을 구체적으로 작성한다. 모델이 잘못된 도구를 고르지 않게 하기 위해서다. 넷째, 호출 로그를 남긴다. 누가, 어떤 session에서, 어떤 tool을, 어떤 parameter로 호출했는지 추적할 수 있어야 한다.

권한도 사용자 신원 기준이어야 한다. “MCP 서버 하나의 공용 토큰”으로 모든 사용자의 Jira나 GitHub 데이터를 읽게 만들면 감사를 할 수 없다. 가능하면 OAuth, workload identity, service account impersonation처럼 사용자 또는 팀 단위 권한을 남기는 방식을 택한다.

headless 환경에서는 permission prompt를 없애는 대신 거절해야 한다

--permission-prompts none은 unattended headless host에서 prompt가 필요한 작업을 자동 거절하는 옵션이다. 이 방향이 맞다. 서버나 cron에서 프롬프트가 뜨면 아무도 승인하지 못하고 작업이 멈춘다. 더 위험한 것은 자동 승인이다. unattended 환경에서는 “묻지 못하면 하지 않는다”가 기본값이어야 한다.

따라서 headless Claude Code를 운영한다면 허용할 도구를 사전에 좁히고, 나머지는 실패하게 둔다. 실패한 작업은 로그와 함께 재시도 큐나 사람 승인 단계로 넘긴다. 특히 MCP write action, 외부 메시지 발송, 배포, 비용 발생 작업은 headless에서 자동 실행하지 않는 편이 안전하다.

설정 파일은 실패하면 멈추게 해야 한다

2.1.259에는 managed settings 파일, drop-in, MDM plist, HKLM value를 파싱할 수 없을 때 Claude Code가 시작을 거부하고 원인을 표시한다는 수정도 들어 있다. 이건 운영상 좋은 변화다. 정책 파일이 깨졌는데 도구가 기본 허용 상태로 떠버리면 더 위험하다. 보안 설정은 fail-open보다 fail-closed가 맞다.

관리자는 이 특성을 전제로 rollout을 설계해야 한다. 설정 배포 전에 JSON schema 검증을 돌리고, canary 사용자 그룹에 먼저 적용한다. claude plugin validate --json처럼 기계가 읽을 수 있는 검증 결과가 있으면 CI에 붙인다. 설정 변경은 “문서 수정”이 아니라 “조직 개발 환경 변경”으로 취급해야 한다.

실행 체크리스트

• 공통 배포할 MCP 후보를 읽기 전용, 쓰기 가능, 실험용으로 나눈다.
• 중앙 배포 대상은 HTTP/SSE MCP 서버로 제한하고 로컬 command 실행형 entry는 제외한다.
• MCP 서버마다 owner, SLA, data classification, 로그 위치를 정한다.
• tool 이름과 description을 모델이 오해하지 않게 구체적으로 작성한다.
• 사용자 또는 팀 단위 인증을 사용하고 공용 만능 토큰을 피한다.
• headless Claude Code에는 --permission-prompts none을 적용하고 실패 로그를 남긴다.
• managed settings 변경은 JSON/schema 검증 후 canary rollout한다.
• 정책 파싱 실패 시 fail-closed로 멈추는 것을 정상 동작으로 문서화한다.

Claude Code managedMcpServers는 MCP를 팀 생산성 인프라로 끌어올리는 기능이다. 하지만 MCP가 늘어날수록 에이전트가 할 수 있는 일도 늘어난다. 안전한 배포의 기준은 도구 수가 아니라 권한, 로그, 실패 모드, rollback을 얼마나 명확하게 설계했는지다.