Anthropic Skills는 모델에 새 도구를 제공하는 MCP 서버가 아니라, 이미 가진 도구를 언제 어떤 순서로 쓸지 SKILL.md에 적은 재사용 가능한 작업 지침입니다. 메타데이터로 필요한 스킬을 찾고, 발동한 뒤 본문과 추가 리소스를 단계적으로 읽는 구조가 핵심입니다. 설치 전에 지침, 스크립트, 권한을 검토하고 결과를 실제 파일과 로그로 확인해야 합니다.
Anthropic Skills는 MCP와 무엇이 다를까: SKILL.md 구조부터 검증까지
MCP와 Skills는 무엇이 다를까?
원문은 MCP를 칼이나 프라이팬 같은 도구, Skills를 그 도구로 일을 끝내는 레시피에 비유합니다. 문서 작성, 브라우저 테스트, Git 작업처럼 여러 단계가 필요한 업무에서 지침을 모듈로 나누고 팀과 공유할 수 있다는 뜻입니다.
스킬 파일이 있다고 해서 Claude가 Word 파일을 편집하거나 브라우저를 조작할 권한을 자동으로 얻는 것은 아닙니다. 실제 실행 도구, 파일 접근 권한, 런타임이 따로 있어야 합니다. 반대로 도구가 있어도 발동 조건과 검증 순서가 없으면 에이전트가 잘못된 순간에 사용할 수 있습니다.
예를 들어 브라우저를 여는 MCP 도구가 연결돼 있어도 어느 페이지를 어떤 순서로 검사하고 무엇을 결과로 남길지는 정해져 있지 않을 수 있습니다. 스킬은 그 절차와 중단 조건을 제공할 수 있지만, 연결되지 않은 브라우저 기능을 만들어 내지는 못합니다. 도구의 능력과 지침의 품질을 분리해 평가해야 하는 이유입니다.
같은 스킬도 권한 환경에 따라 결과가 달라집니다. 읽기만 가능한 작업 공간에서는 수정 절차가 중단돼야 하고, 외부 네트워크가 막힌 환경에서는 다운로드를 전제로 한 단계가 실패해야 합니다. 좋은 스킬은 이런 선행 조건을 숨기지 않고 확인하게 합니다.
SKILL.md는 왜 필요한 순간에만 읽힐까?
원문이 설명하는 구조는 세 층입니다. 먼저 YAML frontmatter의 이름과 설명으로 필요한 스킬을 찾고, 발동한 뒤 SKILL.md 본문 지침을 읽으며, 작업 중 필요할 때 템플릿이나 예제 같은 추가 리소스에 접근합니다. 모든 지침을 항상 문맥에 넣지 않는 점진적 공개 방식입니다.
좋은 description은 “무엇을 하는가”뿐 아니라 “언제 써야 하는가”를 구체적으로 말해야 합니다. 본문에는 입력 조건, 실행 순서, 실패 시 중단 기준, 산출물 검증이 있어야 합니다. 리소스가 많아도 어떤 조건에서 읽을지 없다면 토큰과 시간이 낭비됩니다.
점진적 로딩은 모든 업무 지침을 한 번에 문맥에 넣지 않도록 합니다. 처음에는 이름과 설명만 비교하고, 실제로 선택된 스킬의 본문을 읽은 뒤, 특정 형식이나 도구가 필요할 때만 관련 자료를 확인합니다. 이 구조가 작동하려면 description이 너무 넓거나 모호하지 않아야 합니다.
발동 조건에는 제외 조건도 중요합니다. “문서를 다룰 때”처럼 넓게 쓰면 단순 요약에도 복잡한 파일 생성 절차가 켜질 수 있습니다. 입력 파일이 없거나 필요한 도구가 없을 때 질문할지 중단할지, 여러 스킬이 동시에 맞을 때 어떤 순서로 적용할지도 본문에서 확인해야 합니다.
저장소를 복제한 뒤 무엇부터 확인해야 할까?
원문은 docx, pdf, pptx, xlsx 같은 문서 스킬과 MCP 서버 생성, Playwright, Git, algorithmic-art 관련 예를 소개합니다. 이름만 보고 완성된 기능으로 가정하지 말고 각 폴더의 SKILL.md와 필요한 스크립트, 도구를 함께 확인해야 합니다.
원문에 제시된 저장소 복제 명령은 다음과 같습니다.
1
git clone https://github.com/anthropics/skills.git
이 명령은 저장소를 내려받을 뿐 Claude Code나 Claude.ai에 자동 설치하지 않습니다. 설정 경로와 업로드 방식은 제품 버전에 따라 달라질 수 있으므로, 이 글은 현재 설치법을 보증하지 않습니다. 사용 시점에는 저장소, Anthropic 문서, 저장소 README를 직접 대조해야 합니다.
복제 후에는 관심 폴더의 SKILL.md 전체와 그 파일이 직접 가리키는 스크립트, 템플릿을 읽습니다. 파일 확장자만 보고 안전한 예제라고 가정하거나, 다른 환경의 경로를 현재 설정에 그대로 적용해서는 안 됩니다. 실행 명령, 외부 통신, 파일 덮어쓰기, 삭제 가능성이 있는 단계를 먼저 표시하는 편이 좋습니다.
버전도 기록해야 합니다. 저장소가 바뀌면 같은 이름의 스킬이 다른 절차를 실행할 수 있으므로, 팀에서 검토한 커밋과 실제 사용한 커밋을 맞춰야 재현이 가능합니다. 저장소 전체 라이선스 안내와 개별 리소스의 조건이 다른지도 확인해야 합니다.
스킬 도입 효과를 어떻게 안전하게 검증할까?
반복 업무 하나를 골라 예상 입력과 정답 조건을 만듭니다. 스킬 없이 수행한 결과와 적용 결과를 비교하고, 발동하지 말아야 할 요청에서도 스킬이 켜지지 않는지 시험합니다. 문서 스킬이라면 내용뿐 아니라 파일이 열리는지, 표와 서식이 보존되는지 확인해야 합니다.
스킬은 실행 절차를 담을 수 있으므로 출처를 모르는 파일을 곧바로 신뢰해서는 안 됩니다. 지침과 스크립트를 검토하고 제한된 작업 공간에서 실행하며, 네트워크, 파일 삭제, 외부 전송 같은 권한은 필요한 범위로 줄여야 합니다. 원문이 언급한 Apache 2.0 라이선스도 개별 리소스의 사용 조건과 동일하다고 가정하지 말고 실제 파일을 확인하는 편이 안전합니다.
작은 시험에서는 발동 정확도, 단계 누락, 결과 품질을 따로 봅니다. 스킬이 필요한 요청에서 켜지지 않거나 불필요한 요청에서 켜지면 description을 손봐야 하고, 실행은 됐지만 파일이 열리지 않거나 형식이 깨지면 검증 단계가 부족한 것입니다. 같은 입력을 반복했을 때 핵심 절차와 산출물 기준이 유지되는지도 확인할 수 있습니다.
도입을 보류할 조건은 명확합니다. 스킬이 필요한 권한을 설명하지 않거나, 실패 뒤에도 작업을 계속하거나, 완료 보고만 있고 실제 산출물 검사가 없다면 운영 환경에 넣으면 안 됩니다. 반대로 반복 업무의 누락을 줄이고 사람이 결과 근거를 더 쉽게 확인하게 한다면 재사용 지침으로서 가치가 있습니다.
새 SKILL.md를 작성할 때 어떤 순서로 좁혀야 할까?
먼저 하나의 반복 업무와 성공 조건을 문장으로 정합니다. “문서 작업을 돕는다”보다 “주어진 DOCX의 표와 서식을 보존하며 지정 문단을 수정하고 결과 파일이 열리는지 확인한다”처럼 입력, 변경, 검증 범위가 드러나야 합니다. 서로 다른 산출물을 한 스킬에 모두 넣으면 발동 조건과 실패 처리가 모호해집니다.
description에는 사용해야 할 요청과 사용하지 말아야 할 요청을 구분할 단서를 넣습니다. 본문은 선행 조건, 작업 순서, 위험한 단계의 승인, 검증, 실패 시 중단을 배열합니다. 사용자가 선택해야 결과가 달라지는 지점은 에이전트가 임의로 가정하지 않도록 질문 조건으로 남겨야 합니다.
스크립트와 템플릿은 본문을 짧게 만드는 수단이지만 숨겨진 실행 경로가 되어서는 안 됩니다. 어떤 상황에서 어떤 파일을 읽고 실행하는지 적고, 입력과 출력 경로를 좁게 제한하며, 덮어쓰기 전에 기존 파일을 확인하게 합니다. 외부 네트워크와 자격 증명이 필요한 경우도 선행 조건에서 드러나야 합니다.
마지막에는 정상 요청, 발동하면 안 되는 요청, 필수 입력이 빠진 요청, 도구가 실패하는 요청을 각각 시험합니다. 결과가 좋아도 잘못된 상황에서 스킬이 켜지거나 실패 뒤에 부분 파일을 정상 산출물처럼 남긴다면 수정해야 합니다. 이 경계 테스트가 재사용 가능한 지침과 한 번만 작동한 프롬프트를 가르는 기준입니다.
팀 배포 전에는 스킬이 참조하는 경로와 도구 이름이 모든 환경에서 같은지 확인합니다. 한 개발자의 홈 디렉터리나 설치된 프로그램을 전제로 하면 다른 사용자는 중간 단계에서 실패할 수 있습니다. 환경 차이를 자동 감지하거나 필요한 준비물을 분명히 안내해야 합니다.
관찰 가능성도 설계에 포함합니다. 어떤 스킬이 왜 선택됐고 어느 단계에서 어떤 도구를 사용했는지 남기면 잘못된 발동과 권한 사용을 검토할 수 있습니다. 민감한 입력과 비밀 키는 로그에 그대로 남기지 않도록 기록과 보안 요구를 함께 정해야 합니다.
스킬이 많아지면 설명이 겹쳐 잘못 선택될 가능성도 커집니다. 비슷한 두 스킬을 합칠지, 더 구체적인 제외 조건으로 나눌지 실제 발동 오류를 보고 결정합니다. 목록의 개수보다 필요한 업무를 정확히 선택하고 실패했을 때 멈추는 능력이 중요합니다.
폐기할 스킬도 정기적으로 찾습니다. 더 이상 존재하지 않는 도구나 경로를 가리키는 지침은 선택되기만 해도 시간을 낭비하고, 오래된 설치 명령은 현재 환경을 손상시킬 수 있습니다. 마지막 검토일과 호환 환경을 표시하고 대표 시험이 계속 통과하는지 확인해야 합니다.
담당자가 바뀌어도 같은 기준으로 비활성화하고 복구할 수 있어야 운영 가능한 스킬 목록이 됩니다.
함께 읽으면 이해가 이어지는 글
- DeepSeek-TUI 16K Star, V4 주장은 확인됐나: 저장소 정체와 Shell 권한 감사 — DeepSeek-TUI 글에 섞인 official repository, 16K star, V4, 1M context 주장의 출처를 분리하고, dispatcher, TUI, MCP, shell 권한을 검증하는 방법을 정리합니다.
- xai-org/grok-build: 100만 줄의 Rust 코드로 구현된 터미널 AI 에이전트의 모든 것 — 과도한 원격 데이터 수집 논란 이후 전면 오픈소스화된 SpaceXAI의 터미널 기반 AI 코딩 에이전트, Grok Build의 내부 아키텍처와 작동 원리를 깊이 있게 살펴봅니다.
- Ruflo로 멀티 에이전트를 조율할까: 토폴로지, 기억, 드리프트 검증 — Ruflo가 특화 에이전트, 토폴로지, AgentDB, MCP로 작업을 분담하는 방식과, 병렬 비용, 권한, 드리프트, 검증 책임을 정리합니다.
표지 1 —
←→ 키와 좌우 스와이프를 지원합니다. 읽던 페이지는 이 기기에 저장됩니다.
이 기사는 저작권자의 CC BY 4.0 라이센스를 따릅니다.