클로드 코드, 팀 설정을 플러그인 하나로 패키징한다

풀어서 설명하면, 클로드 코드는 스킬과 서브에이전트, 훅, MCP 서버로 동작을 다르게 설정할 수 있는데요. 이 조합 전체를 하나의 파일 묶음으로 만든 것이 플러그인이에요. 앤스로픽은 커뮤니티가 만든 플러그인 목록을 깃허브 저장소(anthropics/claude-plugins-community)로 매일 밤 미러링해 두고 있는데, 이번 강의는 그 반대편, 즉 팀이 직접 플러그인을 만들어 나눠 쓰는 방법을 설명해요.

왜 지금 패키징이 필요한가

강의는 클로드 코드를 쓰는 팀이 흔히 겪는 문제에서 출발해요. 한 사람이 유용한 설정 파일을 만들어도 다른 팀원에게 전달하려면 파일을 하나씩 복사해 붙여넣는 수밖에 없었거든요. 스킬 폴더, 서브에이전트 마크다운 파일, 훅 설정, MCP 서버 설정을 각각 옮기다 보면 버전이 어긋나거나 일부가 빠지기 쉬워요. 플러그인은 이 과정을 하나의 설치 단위로 압축해서, 설치 명령 한 줄로 전체 구성이 그대로 전달되게 만들어요.

플러그인 하나에 담기는 것들

구성요소	담기는 형태
스킬	폴더 하나당 스킬 하나
서브에이전트	마크다운 파일 하나당 하나
훅	hooks/hooks.json에 정의, 매 도구 호출마다 실행
MCP 서버	mcp.json에 정의
설정 일부	settings.json 중 agent·statusline 키만 적용

여기에 언어서버 프로토콜(LSP) 서버, 백그라운드 모니터, 테마까지 더 얹을 수 있어요. 매니페스트 파일은 .claude-plugin/plugin.json에 두는데, name 필드만 필수고 version·description·author는 선택이에요. 매니페스트를 아예 안 만들어도 클로드 코드가 폴더 구조만 보고 구성 요소를 알아서 찾아내요.

어떻게 써보나

설치와 패키징은 각각 명령이 달라요.

방식	명령	적용 범위
개인 설치	/plugin install 조직명@플러그인명	지금 세션에 바로 설치
팀 배포	/plugin marketplace add 조직명/저장소명	이후 모든 설치가 이 마켓플레이스를 거침

다른 사람이 만든 플러그인을 쓰려면 세션 안에서 슬래시 명령 한 줄만 입력하면 돼요. 팀 전체에 배포하려면 먼저 프라이빗 마켓플레이스를 한 번 등록해두고, 그 뒤로는 모든 설치가 중앙 집중식 검색과 버전 추적, 업데이트를 거쳐 이뤄져요.

직접 만들 때는 이미 쓰고 있는 .claude 디렉터리 구조를 그대로 옮기면 돼요. skills 폴더, agents 폴더, hooks.json, mcp.json을 플러그인 루트에 두고 plugin.json으로 이름을 붙이면 끝이에요. 이름은 그대로 네임스페이스가 돼서, 회사명/스킬명 형태로 다른 플러그인의 스킬과 충돌하지 않아요. 예를 들어 사내 코드 리뷰 규칙과 배포 체크리스트를 스킬과 훅으로 만들어 뒀다면, 이 구조 그대로 매니페스트만 얹어 신입 팀원에게 설치 명령 한 줄로 전달할 수 있어요.

훅은 조용히 실행된다

강의는 편리함 뒤에 있는 위험도 짚어요. 플러그인은 사용자 권한 그대로 코드를 실행하고, 훅은 조건에 맞는 모든 도구 호출에서 자동으로 작동해요. 스킬만 쓰려고 설치해도 그 플러그인의 pre_tool_use 훅과 stop 훅은 읽어보지 않아도 함께 따라와요. 강의는 커뮤니티 플러그인이 설정 화면에 아무런 경고 없이 네트워크 엔드포인트를 호출하는 종료 훅을 포함할 수 있다고 설명해요.

설치 경로에 따라 검증 수준도 달라요. 앱 내 제출 폼으로 올린 플러그인은 앤스로픽의 자동 심사를 거쳐 커뮤니티 마켓플레이스에 올라가고, 공식 마켓플레이스는 별도로 직접 큐레이션해요. 다만 심사를 거쳤다는 것과 신뢰할 수 있다는 것은 다른 이야기라, 어떤 훅과 에이전트, MCP 서버가 딸려오는지 직접 확인하는 절차가 필요해요. 플러그인은 기존 설정을 덮어쓰지 않고 나란히 함께 작동하기 때문에, 훅은 서로 쌓여서 같은 도구 호출에 여러 개가 동시에 반응할 수 있어요.

에디터의 시선

이 강의가 다루는 건 새 기능이 아니라 이미 있던 기능을 팀 규모로 키우는 방법이에요. 앤스로픽은 지난달 커뮤니티 플러그인을 깃허브로 미러링해 배포 경로를 만들었고, 이번에는 그 경로에 올릴 물건, 즉 개인이 만든 설정을 패키징하는 절차를 채워 넣었어요. 순서를 보면 앤스로픽의 전략이 읽혀요. 먼저 유통망을 깔고, 그 다음 생산자를 늘리는 방향이에요.

npm 대신 스크립트 설치로 넘어간 것도, 커뮤니티 마켓플레이스를 저장소로 미러링한 것도 결국 같은 방향을 가리켜요. 클로드 코드를 개인 도구에서 팀 표준 도구로 옮기려는 움직임이에요. 이런 흐름에서 실무 조직이 챙길 건 도구 자체보다 검증 습관이에요. 스킬 하나 써보려고 설치한 플러그인이 훅까지 함께 데려온다는 점은 가볍게 넘길 부분이 아니거든요. 특히 사내 코드베이스처럼 민감한 데이터를 다루는 팀이라면, 설치 전에 매니페스트와 hooks.json을 열어 어떤 도구가 어디로 호출을 보내는지 확인하는 절차를 먼저 표준으로 정해두는 게 맞아요.

코딩 에이전트 도구를 실무에 붙여본 경험으로 보면, 편의 기능이 늘어날 때마다 검증 단계는 항상 뒤로 밀리기 쉬워요. 이번 플러그인 구조도 마찬가지예요. 설치가 명령 한 줄로 쉬워질수록, 그 한 줄 뒤에 뭐가 딸려오는지 보는 습관이 팀 단위로 자리잡아야 사고를 막을 수 있어요. 앞으로 몇 주 안에는 사내 표준 플러그인을 만들어 배포하는 팀들의 사례가 늘어날 텐데, 동시에 검증 안 된 커뮤니티 플러그인을 그대로 설치했다가 문제가 생기는 사례도 함께 나올 가능성이 커요.