에이전트 스킬 모음, 어디서 찾고 어떻게 검증하나

에이전트 스킬 모음은 어디에 있나

에이전트 스킬 모음은 거의 전부 GitHub 저장소 하나로 배포된다. 받는 경로는 두 가지다. Claude Code의 플러그인 마켓플레이스에 그 저장소를 등록해서 설치하거나, 스킬 디렉터리 하나를 ~/.claude/skills/ 아래에 직접 복사하는 것이다. 어느 쪽이든 스킬 본문은 에이전트의 프롬프트로 그대로 들어간다. 그래서 스킬을 설치하는 일은 남이 쓴 지시문에 내 셸과 내 저장소를 열어주는 일과 무게가 같다.

이 글은 두 부분이다. 앞부분은 실제로 존재하고 관리되는 모음이 어디인지, 뒷부분은 그중 하나를 내 저장소에 넣기 전에 무엇을 읽어야 하는지다. 스킬이라는 형식 자체가 처음이라면 에이전트 스킬이 무엇이고 언제 로드되는지를 먼저 보고 오는 편이 빠르다. 아래 명령은 전부 독자가 자기 장비에서 직접 실행하는 것을 전제로 적었다.

이름을 알아둘 만한 스킬 모음

관리 주체를 모르는 스킬은 검토 대상이 아니라 그냥 거르는 편이 낫다. 그래서 저장소 이름과 누가 만드는지를 같이 적는다. 2026년 9월 기준이며, 아래 다섯 곳은 모두 README에 MIT 라이선스를 명시하고 있다.

• anthropics/skills: Anthropic이 직접 공개하는 저장소. 스킬을 포장하는 package_skill.py 스크립트도 여기에 있다. 공식 문서가 참조하는 기준점 역할을 한다.
• obra/superpowers: Jesse Vincent와 Prime Radiant 팀이 관리한다. 브레인스토밍, 테스트 주도 개발, 코드 리뷰처럼 개발 절차 자체를 스킬로 묶은 프레임워크에 가깝다. Claude Code 공식 마켓플레이스에도 올라가 있어서 /plugin install superpowers@claude-plugins-official로 받을 수 있다.
• mattpocock/skills: TypeScript 교육으로 알려진 Matt Pocock이 관리한다. 큰 프레임워크 대신 작고 조합 가능한 스킬 스무 개 남짓이 들어 있다.
• cloudflare/security-audit-skill: Cloudflare가 취약점 탐색 연구에서 뽑아낸 보안 감사 스킬 하나짜리 저장소다. 조직이 관리하는 단일 목적 스킬이 어떻게 생겼는지 보기에 좋은 예다.
• davila7/claude-code-templates: 개인 관리자가 여러 출처에서 모은 대형 집합체다. 에이전트, 커맨드, MCP 설정, 스킬이 한 저장소에 섞여 있다. README가 구성 요소마다 원래 출처와 라이선스가 따로 있다고 밝히고 있으니, 여기서 가져온 스킬은 저장소 전체의 라이선스가 아니라 그 스킬 폴더의 출처를 따로 봐야 한다.

여기에 Claude Code가 기본으로 붙여주는 공식 마켓플레이스 claude-plugins-official이 있다. 세션 안에서 /plugin을 치면 등록된 마켓플레이스와 거기 올라온 플러그인을 목록으로 볼 수 있다. 플러그인이 스킬과 어떻게 다른 단위인지는 플러그인이 무엇을 묶어서 배포하는 단위인지에 정리되어 있다.

별 개수는 인기이지 검토가 아니다

스타 수는 그 저장소를 몇 명이 북마크했는지를 알려줄 뿐이다. 누가 코드를 읽었는지, 스킬 본문에 무슨 명령이 들어 있는지, 지난달 커밋이 무엇을 바꿨는지는 아무것도 알려주지 않는다. 스킬은 컴파일되지 않고 테스트도 강제되지 않는 마크다운 파일이라서, 오탈자와 악성 지시문이 저장소 통계상으로는 완전히 똑같이 보인다.

그래서 별 개수는 후보에 올릴지 말지를 정하는 신호로만 쓰고, 실제 판단은 아래의 읽기 절차로 한다. 스킬 하나를 처음부터 끝까지 읽는 데 보통 10분이 걸리지 않는다.

설치 경로 두 가지를 구분한다

마켓플레이스를 통한 설치는 Claude Code가 저장소를 클론해서 플러그인 캐시에 두고, 설정 파일에 기록을 남긴다. 셸에서는 이렇게 등록하고 설치한다.

claude plugin marketplace add obra/superpowers
claude plugin marketplace list
claude plugin install superpowers@superpowers-marketplace
claude plugin list
claude plugin details superpowers

두 번째 줄이 찍어주는 마켓플레이스 이름은 저장소의 매니페스트에 적힌 값이라서 저장소 이름과 다를 수 있다. 설치 식별자는 <플러그인 이름>@<마켓플레이스 이름> 형태이므로, 세 번째 줄은 그 출력을 보고 채워야 한다.

claude plugin details는 그 플러그인이 실제로 어떤 스킬, 에이전트, 훅, MCP 서버를 들고 왔는지를 구성 요소 목록으로 보여준다. 설치 직후에 이 명령을 한 번 쳐보고, 목록에 무엇이 나오는지 그리고 그것이 왜 거기 있는지를 스스로 설명할 수 있는지 확인한다. 설명이 안 되는 항목이 있으면 그 시점이 멈출 자리다.

디렉터리 복사는 더 단순하다. SKILL.md가 든 폴더 하나를 스킬 디렉터리 아래에 두면 끝이다. 설정 파일에 아무 기록도 남지 않고 업데이트를 챙겨주는 장치도 없다. 대신 무엇이 들어왔는지가 파일 시스템에 그대로 보인다.

일부 모음은 skills CLI를 안내한다. Node.js 18 이상이 필요하고, -g를 붙이면 프로젝트 대신 사용자 홈에 설치한다.

npx skills@latest add mattpocock/skills --list
npx skills add https://github.com/cloudflare/security-audit-skill --skill security-audit

--list를 먼저 써서 그 저장소가 어떤 스킬을 들고 있는지 확인한 다음, --skill로 필요한 것만 집어오는 순서를 권한다. 저장소 전체를 통째로 받는 습관은 검토할 분량을 스무 배로 늘린다.

검토 1단계: SKILL.md 프런트매터를 읽는다

스킬 하나는 SKILL.md 파일 하나가 전부다. 먼저 어디에 무엇이 들어왔는지 본다.

find ~/.claude/skills .claude/skills -name SKILL.md 2>/dev/null

그다음 문제의 파일 앞부분을 연다. 프런트매터는 파일의 첫 줄이 ---일 때만 읽히고, 인식하지 못하는 필드는 오류 없이 조용히 무시된다. 그래서 오탈자가 난 필드는 있으나 마나 한 상태로 조용히 지나간다.

head -n 30 ~/.claude/skills/pr-summary/SKILL.md

여기서 확인할 필드는 정해져 있다.

• description과 when_to_use: 에이전트가 이 스킬을 언제 스스로 불러올지 결정하는 문장이다. 넓게 쓰여 있을수록 내가 부르지 않아도 자주 끼어든다.
• allowed-tools: 이 스킬이 실행되는 턴 동안 권한 확인 없이 쓸 수 있는 도구 목록이다. Bash(gh *)처럼 명령 패턴까지 적을 수 있다. 여기에 넓은 Bash 권한이 적혀 있다면, 그 스킬은 자기가 쓴 셸 명령을 물어보지 않고 실행할 권한을 요구하는 것이다.
• disallowed-tools: 반대로 스킬이 활성화된 동안 도구를 빼는 필드다. 이게 적혀 있으면 작성자가 경계를 고민했다는 신호로 읽어도 좋다.
• hooks: 스킬이 호출될 때 훅을 등록한다. 중요한 점은 그 훅이 스킬이 끝난 뒤에도 세션이 끝날 때까지 계속 살아 있다는 것이다. 훅은 에이전트의 판단과 무관하게 도구 호출마다 돌아가는 코드이므로, 이 필드가 있으면 훅 본문을 반드시 읽는다. 동작 방식은 훅이 어느 시점에 무엇을 가로채는지에 더 자세히 있다.
• disable-model-invocation과 user-invocable: 누가 이 스킬을 부를 수 있는지를 정한다. disable-model-invocation: true면 내가 /이름으로 칠 때만 돈다.
• context: fork와 agent: 스킬을 별도 서브에이전트 컨텍스트에서 돌린다. 기본값이 백그라운드 실행이라서, 내가 다른 일을 하는 동안 조용히 돌아간다는 뜻이다.
• license: 아래 5단계에서 다시 본다.

프런트매터가 얌전한데 본문이 수상한 경우는 있어도, 프런트매터가 넓은 권한을 요구하는데 본문이 얌전한 경우는 거의 없다. 필드 이름과 역할이 낯설다면 스킬을 직접 하나 써 보는 쪽이 남의 스킬을 읽는 속도도 같이 올려준다.

검토 2단계: 셸 명령이 언제 실행되는지 본다

이것이 가장 중요한 항목이다. Claude Code는 스킬 본문의 ` !<명령> ` 자리를 에이전트가 본문을 보기 전에 먼저 실행하고, 그 출력으로 자리를 채운다. 즉 이 명령은 모델의 판단을 거치지 않고, 도구 권한 확인도 거치지 않는다. 스킬이 로드되는 순간 이미 돌아간 뒤다.

공식 문서의 예시 스킬은 이렇게 생겼다.

---
name: pr-summary
description: Summarize changes in a pull request
context: fork
agent: Explore
allowed-tools: Bash(gh *)
---

## Pull request context
- PR diff: !`gh pr diff`
- PR comments: !`gh pr view --comments`

gh pr diff라면 납득이 된다. 같은 자리에 curl이나 base64 -d가 들어 있다면 납득할 이유가 없다. 그러니 설치한 스킬 전체를 이 패턴으로 한 번 훑는다.

grep -rn -- '!`' ~/.claude/skills/
grep -rn -E 'curl|wget|base64|eval|chmod|nc ' ~/.claude/skills/

인라인 형태 말고, 백틱 세 개와 느낌표로 여는 코드 펜스도 같은 일을 한다. 여러 줄 명령을 넣을 때 쓰는 형태이므로 펜스를 여는 줄까지 같이 봐야 한다. 걸린 줄마다 무엇이 출력될지, 그리고 그 출력이 왜 프롬프트에 필요한지를 설명할 수 있어야 통과다.

조직 단위로 이 기능을 끄고 싶다면 설정에 "disableSkillShellExecution": true를 넣는다. 그러면 각 명령이 실행되는 대신 [shell command execution disabled by policy]라는 문자열로 대체된다. 관리 설정에 넣으면 사용자가 되돌릴 수 없다. 외부 스킬을 많이 쓰는 팀이라면 이 한 줄이 가장 값싼 방어선이다.

검토 3단계: 실행 시점에 네트워크에서 지시문을 가져오는가

스킬 본문이 실행 시점에 외부 URL을 읽어와서 그 내용을 따르라고 적어두는 경우가 있다. "최신 가이드는 여기서 받아서 그대로 따르라" 같은 문장이다. 이것은 단계가 하나 더 붙은 프롬프트 인젝션이다. 내가 검토한 것은 스킬 파일이고, 에이전트가 실제로 따르는 것은 내가 본 적 없는 원격 문서이기 때문이다. 그 원격 문서는 내가 커밋을 고정해도 바뀐다.

grep -rn -E 'https?://' ~/.claude/skills/

걸린 URL을 세 부류로 나눈다. 사람이 읽으라고 적어둔 참고 링크는 문제가 없다. 스킬이 실행 중에 가져오는 URL은 그 문서를 직접 열어보고, 그 문서가 누구 손에 있는지 확인한다. 도메인이 개인 계정이거나 단축 URL이면 거기서 멈춘다. 이 공격면이 왜 막기 어려운지는 코딩 에이전트를 노리는 프롬프트 인젝션에 정리해 두었고, 같은 원리가 메모리 파일에도 적용된다는 이야기는 에이전트 메모리를 오염시키는 방식 쪽에 있다.

검토 4단계: 환경 변수와 dotfile을 읽는가

스킬이 가져갈 수 있는 가장 값비싼 것은 자격 증명이다. 그리고 자격 증명은 거의 항상 환경 변수 아니면 홈 디렉터리의 점 파일에 있다.

grep -rn -E 'AWS_|GITHUB_TOKEN|_API_KEY|_SECRET|[.]env|[.]aws|[.]ssh|[.]netrc|[.]npmrc' ~/.claude/skills/

정당한 이유가 있는 경우도 있다. 배포 스킬이 리전 변수를 읽는 것은 자연스럽다. 판단 기준은 읽는지가 아니라 읽은 값이 어디로 가는지다. 읽은 값이 프롬프트 본문으로 들어가면 대화 기록에 남는다. 읽은 값이 curl의 인자로 들어가면 그것은 유출이다. 애초에 에이전트가 도는 셸에 장기 토큰을 두지 않는 구성은 비밀값을 에이전트 환경에서 떼어놓는 방법에서 다룬다. 처음 보는 모음을 통째로 시험해 보고 싶다면 버리는 VM 한 대에서 먼저 돌려보는 쪽이 안전하다.

검토 5단계: 라이선스가 회사 저장소를 통과하는가

스킬은 코드가 아니라 문서처럼 보여서 라이선스 검토를 건너뛰기 쉽다. 하지만 회사 저장소에 커밋되는 순간 그것은 배포되는 파일이고, 원 저장소의 조건을 그대로 짊어진다.

ls ~/.claude/skills/security-audit/
grep -rn -i 'license' ~/.claude/skills/security-audit/SKILL.md

확인할 것은 두 가지다. 원 저장소 루트의 LICENSE 파일이 무엇인지, 그리고 내가 가져오는 스킬 폴더에 별도 표기가 있는지다. 여러 출처를 모아둔 집합형 저장소에서는 이 둘이 다를 수 있다. 프런트매터의 license 필드는 Agent Skills 표준의 일부라서 Claude Code는 값을 받아들이기만 하고 아무 동작도 하지 않는다. 즉 그 필드는 사람이 읽으라고 있는 것이고, 비어 있다고 해서 자유롭게 써도 된다는 뜻은 전혀 아니다.

브랜치를 따라가지 말고 커밋이나 태그에 고정한다

이 저장소들은 주 단위로 바뀐다. 오늘 읽고 통과시킨 스킬과 다음 주에 팀원 장비에서 도는 스킬이 같은 파일이라는 보장이 없다. 검토의 의미를 유지하려면 고정해야 한다.

마켓플레이스 소스는 owner/repo@ref 또는 owner/repo#ref 형태를 그대로 받는다. ref 자리에는 태그 이름이나 커밋 해시를 적으면 되고, Claude Code는 그 지점으로 클론한다.

claude plugin marketplace add obra/superpowers@<태그 또는 커밋 해시>
claude plugin marketplace list

디렉터리를 직접 복사하는 쪽이라면 클론한 저장소에서 고정한다.

git clone https://github.com/mattpocock/skills ~/src/mattpocock-skills
git -C ~/src/mattpocock-skills log -1 --format='%H %ci %s'
git -C ~/src/mattpocock-skills checkout <커밋 해시>

업데이트는 자동으로 받지 말고, 고정한 지점과 최신 지점 사이의 차이를 먼저 읽는다.

git -C ~/src/mattpocock-skills fetch origin
git -C ~/src/mattpocock-skills diff <고정한 해시>..origin/main

이 diff가 길면 그 주에는 올리지 않는다. 짧고 이해되면 2단계와 3단계의 grep만 다시 돌리고 올린다. 이 절차를 팀 전체로 넓히는 방법은 여러 저장소에 같은 스킬을 배포하는 방법에 따로 적어두었다.

어디에 둘 것인가: 사용자별과 프로젝트별

배치는 되돌리기의 절반이다. 위치에 따라 누가 영향을 받는지가 달라지기 때문이다.

• ~/.claude/skills/<이름>/SKILL.md: 이 장비의 내 모든 프로젝트. 나만 쓰는 개인 도구에 맞다.
• .claude/skills/<이름>/SKILL.md: 이 저장소. 커밋하면 팀 전원이 받는다. 외부에서 가져온 스킬을 여기에 넣는 것이 사실상의 배포 행위다.
• <하위디렉터리>/.claude/skills/<이름>/SKILL.md: 모노레포에서 그 하위 트리에만 적용한다. 세션이 그 아래 파일을 건드릴 때 로드된다.
• 플러그인이 들고 온 스킬: /플러그인이름:스킬이름 형태로 이름이 구분되므로, 내 스킬과 이름이 겹쳐도 충돌하지 않는다.

같은 이름이 여러 곳에 있으면 순서가 정해져 있다. 기업 관리 설정이 개인 설정을 이기고, 개인 설정이 프로젝트 설정을 이긴다. 즉 ~/.claude/skills/deploy가 있는 상태에서 저장소의 .claude/skills/deploy를 커밋하면, 그 장비에서는 개인 쪽이 돈다. 팀원마다 다른 스킬이 도는 상황이 여기서 나온다.

검토를 마치지 않은 외부 스킬은 개인 디렉터리에 두고 며칠 써 본 다음에 프로젝트로 옮기는 순서를 권한다. 스킬과 MCP 서버, 규칙 파일 중 무엇으로 배포할지 아직 정하지 않았다면 세 가지 배포 형식의 차이를 먼저 보는 편이 낫다.

스킬이 이상하게 굴 때 무엇을 지우나

되돌리는 방법을 설치 전에 알아두면 실험이 쉬워진다.

디렉터리로 넣은 스킬은 디렉터리를 지우면 끝이다. Claude Code는 스킬 디렉터리의 변경을 감시하므로 세션을 다시 시작하지 않아도 목록에서 빠진다.

rm -rf ~/.claude/skills/<이름>

지우기 전에 한 단계 약하게 막고 싶다면 프런트매터에 disable-model-invocation: true를 넣는다. 그러면 에이전트가 스스로 부르지는 못하고, 내가 /이름으로 칠 때만 돈다. 파일을 고치기 싫으면 설정의 skillOverrides에서 같은 효과를 줄 수 있다.

플러그인으로 들어온 것은 파일을 지우지 말고 명령으로 뺀다. 캐시와 설정 기록이 따로 있기 때문이다.

claude plugin disable <플러그인>
claude plugin uninstall <플러그인> --scope user
claude plugin marketplace remove <마켓플레이스 이름>

disable은 설치를 남겨둔 채 끄기만 하므로 원인을 좁힐 때 먼저 쓴다. marketplace remove는 그 마켓플레이스와 거기서 설치한 플러그인을 함께 제거한다. 한 가지 더 기억할 것은, 이미 로드되어 대화 컨텍스트에 들어간 스킬 본문은 파일을 지워도 그 세션에서는 사라지지 않는다는 점이다. 스킬이 수상해서 지웠다면 세션도 새로 시작한다.

FAQ

스타가 많은 스킬 저장소면 안전한가요?

아닙니다. 스타 수는 북마크한 사람 수이지 코드를 읽은 사람 수가 아닙니다. 스킬은 마크다운 파일이라 컴파일도 테스트도 거치지 않으므로, 저장소 통계만으로는 본문에 어떤 셸 명령이 들어 있는지 알 수 없습니다. 최소한 SKILL.md의 프런트매터와 ` !명령 ` 자리를 직접 읽고, 관리 주체가 개인인지 조직인지 확인하세요.

마켓플레이스로 설치하는 것과 폴더를 복사하는 것은 무엇이 다른가요?

마켓플레이스 설치는 Claude Code가 저장소를 클론해 캐시에 두고 설정 파일에 기록을 남깁니다. claude plugin list와 claude plugin details로 무엇이 들어왔는지 확인할 수 있고, claude plugin uninstall로 뺄 수 있습니다. 폴더 복사는 기록이 남지 않는 대신 파일이 그대로 보이고, 제거는 그 디렉터리를 rm -rf 하는 것입니다. 업데이트를 챙겨주는 장치는 없습니다.

스킬 안에서 느낌표로 시작하는 백틱 명령은 언제 실행되나요?

에이전트가 스킬 본문을 보기 전에 실행됩니다. 출력이 명령 자리를 대신 채운 다음 프롬프트로 들어가기 때문에, 모델의 판단이나 도구 권한 확인을 거치지 않습니다. 그래서 스킬 검토에서 이 패턴을 가장 먼저 찾아야 합니다. 조직 차원에서 막으려면 설정에 "disableSkillShellExecution": true를 넣으면 되고, 그러면 명령 대신 [shell command execution disabled by policy] 문자열이 들어갑니다.

스킬 저장소를 특정 커밋에 고정하려면 어떻게 하나요?

마켓플레이스 소스는 owner/repo@ref와 owner/repo#ref 형태를 받으므로, 저장소 이름 뒤에 태그나 커밋 해시를 붙이면 Claude Code가 그 지점으로 클론합니다. 직접 클론해서 쓰는 경우에는 git checkout <해시>로 고정하고, 올릴 때마다 git diff <고정한 해시>..origin/main으로 바뀐 내용을 먼저 읽으세요. 이 저장소들은 주 단위로 바뀌므로 브랜치를 그대로 따라가면 검토한 파일과 실제로 실행되는 파일이 달라집니다.

외부 스킬은 개인 디렉터리와 프로젝트 디렉터리 중 어디에 두어야 하나요?

검토가 끝나기 전에는 ~/.claude/skills/에 두세요. 그 장비의 내 세션에만 영향을 줍니다. .claude/skills/에 넣고 커밋하는 순간 팀 전원에게 배포하는 것이며, 같은 이름이 개인 디렉터리에도 있으면 개인 쪽이 우선하므로 팀원마다 다른 스킬이 도는 상태가 만들어집니다. 며칠 써 보고 문제가 없을 때 프로젝트로 옮기는 순서가 안전합니다.