Claude Code 플러그인 (Plugin)

Claude Code 플러그인(Plugin) 은 개인이 만든 Skill·에이전트·훅·외부 도구 연결을 폴더 하나로 묶어, 팀이 같은 버전으로 설치하고 자동으로 갱신받게 만드는 패키지입니다. AI 자산화의 4단계 사다리에서 마지막 칸 — 개인 자산을 조직 자산으로 옮기는 자리 — 에 해당합니다.

문제는 공유 속도가 아니라 기준이 갈라지는 것

Claude Code를 쓰다 보면 나만의 도구가 생깁니다. 우리 서비스 배포 절차를 그대로 밟아주는 Skill, 팀 컨벤션 기준으로 코드를 봐주는 리뷰 에이전트 같은 것들입니다. 문제는 이것들이 내 컴퓨터에만 있다는 점입니다.

가장 자연스러운 해결은 파일을 슬랙으로 보내는 것입니다. 팀원 다섯 명이 각자 복사합니다. 여기서 벌어지는 일을 시간순으로 보면 이렇습니다.

1주차  원본 1개 → 슬랙 전송 → 사본 5개
2주차  내가 개선 → 다시 전송 → 다시 복사 (한 명은 빠뜨림)
3주차  버그 제보 → 확인해보니 구버전 문제
4주차  누가 어떤 버전을 쓰는지 아무도 모름

여기서 진짜 비용은 재전송에 드는 시간이 아닙니다. 사본 5개 = 기준 5개 라는 사실입니다. 자산화의 목적이 "누가 실행해도 같은 판정이 나오는 것"이었는데, 사본이 갈라지는 순간 그 목적이 무너집니다. 팀은 같은 도구를 쓴다고 믿지만 실제로는 다섯 개의 서로 다른 기준으로 일하고 있습니다.

재정의 — 플러그인의 가치는 배포가 아니라 회수다

플러그인을 소개할 때 보통 강조되는 것은 배포 편의입니다. 팀 저장소에 올려두면 두 줄로 설치가 끝나고, 내가 버전을 올리면 팀원은 따로 받을 필요 없이 최신 상태가 됩니다.

하지만 실무에서 더 중요한 쪽은 반대 방향입니다.

파일 복사는 배포는 되지만 회수가 안 됩니다.

잘못된 기준을 담은 Skill을 배포했다고 해봅시다. 파일로 나눠줬다면 회수 방법은 "모두에게 다시 연락해서 지워달라고 부탁하는 것"뿐입니다. 누가 지웠는지 확인할 방법도 없습니다. 반면 플러그인은 원본 하나를 고치면 그 즉시 팀 전체에 반영됩니다.

이 차이가 왜 결정적이냐면, 자산은 반드시 틀리기 때문 입니다. 규정이 바뀌고, 기준이 개정되고, 처음 만든 판단 기준에 구멍이 발견됩니다. 자산화가 지속 가능하려면 "고칠 수 있다"가 아니라 "고친 것이 확실히 반영된다"가 보장돼야 합니다. 플러그인은 배포 채널이기 이전에 팀 기준의 단일 진실 원천(SSOT)을 유지하는 장치 입니다.

무엇이 한 패키지에 담기는가

플러그인은 흩어져 있던 도구들을 업무 단위로 묶습니다.

deploy-kit/
├── .claude-plugin/plugin.json   ← 이름표 (이것만 붙이면 패키지가 된다)
├── skills/deploy/               ← 배포 절차 Skill
├── agents/reviewer.md           ← 리뷰 에이전트
├── hooks/hooks.json             ← 커밋 전 자동 검사
└── .mcp.json                    ← 외부 도구 연결

여기서 눈여겨볼 것은 훅 입니다. Skill과 에이전트는 사람이 불러야 작동하지만, 훅은 정해진 시점에 자동으로 걸립니다. 즉 플러그인은 노하우뿐 아니라 강제되는 검사 지점까지 함께 배포 할 수 있습니다. 팀 기준을 "권고"가 아니라 "경로"로 만드는 수단입니다.

팀 배포와 프로젝트 배포는 다른 문제를 푼다

설치 범위를 어디로 두느냐에 따라 해결되는 문제가 다릅니다.

• 개인 범위 설치 — 내가 쓰는 도구를 정리해 관리합니다. 이름 앞에 플러그인 이름이 붙어 기능 이름이 충돌하지 않고, 필요 없을 때는 삭제 대신 잠시 꺼둘 수 있습니다.
• 프로젝트 범위 설치 — 설정이 프로젝트 저장소 안에 들어갑니다. 저장소를 받아오면 그 설정이 그대로 적용됩니다.

두 번째가 조직 관점에서 훨씬 큽니다. 신규 입사자 온보딩에서 도구 설정 복사가 사라집니다. 지금까지 온보딩 문서에 적혀 있던 "이 Skill을 여기에 복사하세요" 같은 항목들이, 저장소를 받는 것만으로 해결됩니다. 팀의 일하는 방식이 문서가 아니라 코드와 함께 따라오는 형태입니다.

언제 플러그인으로 만들면 안 되는가

플러그인화를 권하는 입장에서도 반드시 붙여야 할 조건이 있습니다. 아직 기준이 흔들리는 Skill은 배포하지 않는 편이 낫습니다.

배포는 좋은 것을 퍼뜨리는 만큼 잘못된 것도 똑같은 속도로 퍼뜨립니다. 게다가 자동 갱신이 붙어 있으면 잘못된 기준은 팀원이 눈치채기도 전에 전원에게 반영됩니다. 개인이 틀린 기준으로 일하면 한 사람의 결과물이 틀리지만, 조직 자산이 틀리면 모든 사람이 같은 방향으로 일관되게 틀립니다.

그래서 플러그인화 전에 통과해야 할 관문은 AI 자산화의 세 조건과 같습니다.

• 여러 번 재실행해봤고 결과가 안정적 이다
• 나 말고 다른 사람이 돌려도 같은 판정 이 나온다
• 결과가 부족할 때 어디를 고쳐야 하는지 가 파일 안에서 지목된다
• 이 자산의 갱신 담당자 가 정해져 있다
• 사람이 반드시 검토해야 할 지점이 명시 되어 있다

앞의 세 개가 안 되어 있으면 아직 개인 도구 단계이고, 뒤의 두 개가 안 되어 있으면 배포는 되지만 오래 못 갑니다.

정리 — 개인 도구에서 팀 자산으로 넘어가는 지점

플러그인은 기술적으로는 폴더 하나에 이름표를 붙이는 단순한 작업입니다. 하지만 조직 관점에서 이 단계는 "내 노하우"가 "우리 팀의 기준"이 되는 경계선 입니다. 그 경계를 넘기 전에, 넘길 만한 기준인지부터 확인하는 것이 순서입니다.