Claude Code strictPluginOnlyCustomization으로 팀 확장 기능 출처를 관리하는 방법 | DAKER 커뮤니티

팀이 Claude Code를 함께 쓰기 시작하면 생산성은 빠르게 올라갑니다. 다만 skills, agents, hooks, MCP 서버처럼 실행 경계와 데이터 접근에 영향을 주는 확장 기능이 각자 로컬에서 섞이기 시작하면, 편의성과 별개로 관리 기준은 더 중요해집니다.

특히 관리형 환경에서는 무엇을 쓸 수 있는지보다 어디서 온 커스터마이징을 허용할지부터 정리하는 것이 좋습니다. 2026년 7월 16일 KST 기준 공식 문서를 바탕으로, strictPluginOnlyCustomization이 무엇을 잠그는 설정인지와 팀 보안 기준에서 어떻게 이해하면 좋은지 정리합니다.

strictPluginOnlyCustomization은 사용자와 프로젝트 출처의 커스터마이징을 막고, 관리 설정이나 승인된 플러그인 출처로 좁히는 정책입니다.

로컬 확장 기능을 어디까지 믿을 수 있을까

팀원이 각자 만든 skill, agent, hook, MCP 서버를 자유롭게 섞으면 작업 속도는 빨라질 수 있습니다. 하지만 보안 검토를 거치지 않은 확장 기능이 프로젝트 설정에 들어오면 권한, 외부 도구 접근, 자동 명령 실행의 경계가 흐려질 수 있습니다. 이 때문에 관리형 환경에서는 기능 자체보다 확장 기능의 출처를 먼저 통제하는 정책이 필요합니다.

strictPluginOnlyCustomization이 막는 범위

strictPluginOnlyCustomization은 Claude Code 커스터마이징의 출처를 관리 설정과 플러그인으로 제한하는 설정입니다. 공식 settings 문서 기준으로 전체 표면을 true로 잠글 수도 있고, skills, agents, hooks, MCP servers 가운데 필요한 표면만 배열로 지정해 잠글 수도 있습니다.

true는 네 가지 표면 전체를 잠그고, 배열은 필요한 표면만 골라 잠그는 방식입니다.

즉, 모든 확장 기능을 한 번에 막는 정책으로도 쓸 수 있고, 위험도가 높은 표면부터 단계적으로 관리 설정 출처로 제한하는 방식으로도 운영할 수 있습니다.

팀 환경에 적용할 때 보는 기준

실무에서는 모든 표면을 한 번에 잠그기보다, 어떤 확장 기능이 실제로 외부 실행이나 데이터 접근에 연결되는지부터 나눠 보는 것이 좋습니다. 예를 들어 hooks나 MCP servers는 셸 명령 실행이나 외부 도구 연결과 맞닿아 있어 더 보수적으로 시작하기 쉽습니다. 반면 skill 공유는 상대적으로 완화된 기준으로 운영할 여지가 있을 수 있습니다.

이 설정을 검토할 때는 개인 로컬 설정에서 허용해도 되는 표면과, 관리 설정에서만 허용해야 하는 표면을 구분해 두면 정책 설명이 분명해집니다. 여기에 허용 marketplace가 있다면 strictKnownMarketplaces 기준도 함께 문서화하는 편이 좋습니다.

한쪽은 설치 가능한 marketplace를, 다른 한쪽은 커스터마이징 출처를 좁히는 역할을 합니다.

hooks와 MCP부터 잠그는 접근

팀이 skill 공유는 허용하되 셸 명령 자동 실행과 외부 도구 연결은 엄격하게 보려면, hooks와 MCP servers를 먼저 관리 설정 출처로 제한하는 방식이 가능합니다. 이렇게 시작하면 가장 민감한 실행 경계를 먼저 정리하면서도, 모든 개발자 루틴을 한 번에 바꾸지 않아도 됩니다.

이때 실행 경계는 위험 명령 차단 hooks 글과 함께 보고, 플러그인 출처 점검은 플러그인 마켓플레이스 글을 함께 참고하면 정책을 설명하기 수월합니다.

잠금 전에 확인해 둘 점

설정을 적용하기 전에는 현재 팀이 실제로 쓰는 skill, agent, hook, MCP 서버 목록을 먼저 정리하는 것이 좋습니다. 각 항목의 출처와 담당자, 필요한 권한을 적어 두면 어떤 표면을 먼저 잠글지 판단하기 쉬워집니다. 승인되지 않은 marketplace나 로컬 확장 경로가 운영 문서에 남아 있다면 함께 정리해 두는 편이 안전합니다.

또한 잠금 이후 실패할 수 있는 개발자 루틴이 있는지도 미리 살펴봐야 합니다. 특히 기존 프로젝트 skill이나 hook에 의존하는 저장소가 있다면, 작은 저장소에서 먼저 확인한 뒤 점진적으로 적용하는 방식이 무리가 적습니다. 권한 모드 운영은 Manual 권한 모드 글과 함께 검토하면 맥락을 잡는 데 도움이 됩니다.

공식 문서 기준으로 주의할 점

작성 기준일은 2026년 7월 16일 KST입니다. 공식 settings 문서는 이 설정을 managed settings 항목으로 설명하므로, 개인 실험용 설정과 조직 배포 설정은 구분해서 봐야 합니다. 팀 정책으로 운영할 때는 특히 이 점을 분리해 이해하는 것이 중요합니다.

자주 묻는 질문

true와 배열 설정은 어떻게 다른가

true는 skills, agents, hooks, MCP servers 네 가지 표면 전체를 잠그는 방식입니다. 배열은 이 가운데 필요한 표면만 골라 잠그는 방식입니다.

strictKnownMarketplaces도 함께 봐야 할까

플러그인 출처까지 통제하려면 함께 검토하는 편이 좋습니다. strictKnownMarketplaces는 설치 가능한 marketplace를, strictPluginOnlyCustomization은 커스터마이징 출처를 좁히는 역할을 합니다.

개발자 개인 skill을 모두 금지해야 할까

항상 그럴 필요는 없습니다. 다만 보안 저장소, 고객 데이터 접근 저장소, 배포 자동화 저장소에서는 관리 출처 중심으로 좁히는 편이 더 안전할 수 있습니다.

오늘 바로 점검할 항목은 무엇일까

팀 저장소의 hooks와 MCP 서버 목록을 먼저 확인하고, 누가 승인했는지와 어떤 권한이 필요한지 적어 보면 됩니다.

참고 자료

https://daker.ai/community/claude-code-hooks-block-dangerous-commands
https://daker.ai/community/claude-code-plugins-marketplace
https://daker.ai/community/claude-code-manual-permissions-2-1-200-team-settin

여러분의 팀에서는 skills, hooks, MCP servers 가운데 어떤 표면부터 관리 설정으로 옮기는 것이 가장 현실적이라고 보시나요?