- Published on
Claude Skills란? — 프롬프트도 MCP도 아닌 세 번째 방법
- Authors
- Name
- junyeol kim
이번 주 유튜브를 보면 채널 여러 개가 동시에 같은 주제를 다뤘습니다. Eric Tech는 Matt Pocock의 Claude Code 스킬 51개 에피소드를 전부 분석했고, Chase AI는 인기 디자인 스킬의 업그레이드를 다뤘고, Andy Stapleton은 "스킬은 그냥 엄청 긴 프롬프트 아니냐"는 질문에 답하는 영상을 올렸습니다. 국내에서도 김지백 강사가 CLAUDE.md·메모리·스킬을 묶어 강의를 냈고요. 다들 지금 Claude Skills를 파고들고 있길래 저도 정리해봤습니다.
🤔 그냥 긴 프롬프트 아닌가
가장 먼저 드는 의문이 이거였습니다. "결국 지시문 모아둔 거 아니야?" 절반은 맞습니다. Skill의 본문(SKILL.md)은 실제로 마크다운으로 쓴 지시문이니까요. 하지만 작동 방식이 프롬프트와는 다릅니다.
일반 프롬프트는 대화할 때마다 매번 반복해서 넣어줘야 합니다. 반면 Skill은 파일시스템에 디렉터리로 존재하고, Claude가 필요할 때 스스로 bash로 읽어들입니다. 한 번 만들어두면 "이 작업엔 이 스킬이 필요하다"는 판단부터 로딩까지 전부 Claude가 알아서 합니다. Anthropic 공식 문서의 비유를 빌리면, 신입 팀원에게 줄 온보딩 가이드를 만드는 것과 비슷합니다 — 매번 옆에서 설명하는 대신, 문서 하나로 넘겨주고 필요할 때 찾아보게 하는 것.
🧩 핵심은 3단계로 나눠 불러오는 것
Skill이 프롬프트와 진짜 다른 지점은 **프로그레시브 디스클로저(progressive disclosure)**입니다. 스킬 전체를 매번 컨텍스트에 욱여넣는 대신, 필요한 만큼만 단계적으로 불러옵니다.
| 레벨 | 로딩 시점 | 토큰 비용 | 내용 |
|---|---|---|---|
| Level 1: 메타데이터 | 항상 (시작 시) | 스킬당 약 100토큰 | name, description (YAML 프런트매터) |
| Level 2: 본문 지시문 | 스킬이 트리거될 때 | 5,000토큰 이하 | SKILL.md 본문 (워크플로우, 가이드) |
| Level 3: 리소스·스크립트 | 실제로 참조할 때 | 사용 전까진 0 | 참고 문서, 실행 스크립트, 템플릿 |
즉 설치해둔 스킬이 몇십 개여도 평소엔 이름과 설명(Level 1)만 컨텍스트에 떠 있습니다. 사용자 요청이 그 description과 맞아떨어질 때만 Claude가 cat skill-name/SKILL.md로 본문을 읽고, 본문이 또 다른 참고 문서(FORMS.md 같은)를 가리키면 그것도 필요할 때만 추가로 읽습니다. 스크립트는 아예 코드 자체가 컨텍스트에 들어오지 않고 실행 결과만 들어옵니다 — "양식 검증 완료" 같은 한 줄만 남는 식이라, Claude가 매번 같은 검증 로직을 새로 짜는 것보다 훨씬 효율적입니다.
이 구조 덕분에 스킬 안에 방대한 API 문서나 예제를 다 넣어둬도 실제로 쓰이지 않으면 토큰 페널티가 없습니다.
⚖️ MCP랑 뭐가 다른가
Skill이 나오면서 가장 많이 헷갈리는 게 MCP와의 관계입니다. 결론부터 말하면 **MCP는 접근(access), Skill은 방법(how)**을 담당합니다.
| 구분 | MCP | Skills |
|---|---|---|
| 역할 | Claude를 데이터·시스템에 연결 | 그 데이터로 뭘 어떻게 할지 가르침 |
| 예시 | 회사 DB에 접근할 수 있게 해줌 | "DB 조회할 땐 항상 날짜 범위부터 필터링해라" |
| 로딩 | 툴 정의가 항상 컨텍스트에 상주 | 트리거되기 전까진 이름·설명만 상주 (프로그레시브 디스클로저) |
| 실패 시 | "그 데이터에 접근을 못 함" | "접근은 했는데 엉뚱하게 처리함" |
DB에 붙는 MCP 서버가 있어도, "우리 회사는 항상 최신 파티션부터 조회한다" 같은 절차 지식은 Skill이 담당합니다. 반대로 아무리 좋은 Skill이 있어도 DB에 접근할 권한 자체가 없으면 무용지물이고요. 그래서 실무에서는 "MCP로 연결하고 Skill로 가르친다"는 조합이 자연스럽게 쓰입니다.
🛠️ 실전: 왜 22개 스킬로 쪼갰나
이 흐름을 가장 적극적으로 실험하는 사람이 Matt Pocock입니다. 그의 스킬 저장소(grill-me 하나만 78.7만 설치, 전체 다운로드 1,300만)는 4가지 실패 패턴을 각각 스킬로 대응시킨 구조입니다.
| 실패 패턴 | 원인 | 대응 스킬 |
|---|---|---|
| 정렬 부족 (misalignment) | 개발자와 요구사항 제시자 간 소통 간격 | /grill-me, /grill-with-docs |
| 과도한 장황함 | 에이전트가 프로젝트 용어를 몰라 풀어서 설명 | CONTEXT.md (공유 용어 문서) |
| 코드 품질 저하 | 정렬 이후에도 피드백 루프 부재 | /tdd, /diagnosing-bugs |
| 복잡한 아키텍처 | 빠른 개발 속도로 인한 엔트로피 누적 | /improve-codebase-architecture |
전체 워크플로우는 이렇게 이어집니다.
/grill-with-docs → 질문을 하나씩 던지며 설계를 정렬
/to-spec → 합의된 대화 내용을 스펙 문서로 변환
/to-tickets → 스펙을 블로킹 관계가 명시된 티켓으로 분해
/implement (+/tdd) → 티켓 단위로 레드-그린-리팩터 구현
/code-review → 기준·스펙 준수를 나란히 검증
핵심 가치관은 "항상 작고 신중한 단계를 밟아라, 피드백 속도가 곧 당신의 속도 제한이다"입니다.
여기서 흥미로운 지점은, Matt Pocock이 하나의 큰 프레임워크 대신 22개의 작은 스킬을 택했다는 겁니다. Agent OS류의 프레임워크는 단계·역할·산출물 형식과 실행 순서까지 전부 미리 정해두는데, 문제가 생기면 "내가 안 짠 상태 머신"을 디버깅해야 합니다. 반면 각 스킬은 "한 가지 일만 하는 평범한 마크다운 파일"이라 몇 분이면 전체를 읽고 이해할 수 있고, 실행 순서는 사용자가 직접 정합니다. 튜닝된 프롬프트나 코드가 아니라 평범한 지시문이라 Claude든 Codex든 모델을 갈아타도 그대로 씁니다.
물론 공짜는 아닙니다. 시퀀싱 책임이 사용자에게 넘어오기 때문에, 정해진 역할 분담과 자동 진행을 원하는 팀에는 오히려 불편할 수 있습니다. "구조는 원하되 자동화 매니저처럼 통제당하긴 싫다"는 사람에게 맞는 방식이라는 게 더 정확한 표현입니다.
📚 정리
- Skill은 긴 프롬프트가 아니라 파일시스템 위의 온디맨드 지시문 — 매번 반복 설명할 필요 없이 Claude가 알아서 판단하고 불러옴
- 프로그레시브 디스클로저 3단계: 메타데이터(항상, ~100토큰) → 본문(트리거 시, 5천토큰 이하) → 리소스/스크립트(참조 시에만, 그 전엔 0)
- MCP는 접근, Skill은 방법 — 데이터 연결은 MCP, 그 데이터를 다루는 절차는 Skill
- Matt Pocock의 22개 스킬은 4가지 실패 패턴(정렬 부족·장황함·코드 품질·아키텍처 엔트로피)에 각각 대응 — grill-with-docs → to-spec → to-tickets → implement → code-review로 이어지는 체인
- 큰 프레임워크 대신 작은 스킬을 쪼개 쓰는 이유는 투명성과 제어권 — 대신 시퀀싱 책임은 사용자 몫
참고: Anthropic 공식 문서 「Agent Skills」, Anthropic Engineering 「Equipping agents for the real world with Agent Skills」, Anthropic 「Skills explained: How Skills compares to prompts, Projects, MCP, and subagents」, GitHub 「mattpocock/skills」, Botmonster 「Matt Pocock's 22 small skills beat one big framework」