클로드 스킬이 무엇인지는 이해했습니다. 메모리와 다르고, 프로젝트와 다르고, GPTs와도 다르다는 것까지 정리했습니다. 그런데 막상 만들려고 하면 첫 번째 질문이 나옵니다. “이름은 영어로 써야 하나요?” 개념이 아니라 실행의 벽입니다. 이 글은 클로드 스킬을 처음 만들고 운영할 때 반복되는 실전 질문 5가지에 답합니다.
Contents
시스템 이름은 영문, 부르는 이름은 한글
스킬의 “시스템 이름”과 “부르는 이름”은 다릅니다. 이 구분을 알면 혼동이 사라집니다.
스킬을 만들면 폴더가 하나 생깁니다. 이 폴더명이 시스템 이름입니다. 공식 규칙은 “소문자 영문, 숫자, 하이픈(-)만 사용, 최대 64자”입니다. 예를 들어 blog-writing-workflow처럼 케밥케이스(kebab-case)로 적어야 합니다. 대문자, 공백, 한글, 밑줄(_)은 사용할 수 없습니다. SKILL.md 안의 name 필드도 같은 규칙을 따릅니다.
반면 대화창에서 스킬을 부를 때는 한글로 작동합니다. “블로그 글쓰기 스킬로 작성해줘”, “강의 슬라이드 스킬로 만들어줘”라고 입력하면, 클로드가 description 필드를 참조해서 해당 스킬을 찾아 적용합니다. description은 한글로 작성해도 됩니다. 오히려 한글 트리거 키워드를 description에 넣어두면 인식률이 올라갑니다. 예를 들어 description에 “블로그 글쓰기, 블로그 포스트, 워드프레스 블로그”를 포함시키면, 사용자가 이 단어를 언급할 때 해당 스킬이 자동으로 선택됩니다.
정리하면 이렇습니다. 폴더명과 name은 영문, description과 대화창 호출은 한글. 이 구분만 기억하면 됩니다.
SKILL.md는 500줄 이내, 보조 파일은 간결할수록 정확하다
500줄 제한은 SKILL.md에 적용되는 기준입니다. 앤트로픽 공식 가이드에서 “SKILL.md body는 500줄 이내로 유지하라”고 권장합니다. 보조 파일(references, templates, examples 폴더 안의 파일)에는 별도의 줄 수 제한이 명시되어 있지 않습니다.
그렇다고 보조 파일을 무한정 길게 쓸 수 있는 건 아닙니다. 클로드가 스킬을 읽는 방식 때문입니다. 클로드는 먼저 SKILL.md를 읽고, 필요한 보조 파일만 선택적으로 불러옵니다. 이 방식을 점진적 공개(Progressive Disclosure)라고 합니다. 파일이 길수록 컨텍스트 윈도우를 많이 차지하고, 지시사항의 집중도가 떨어집니다.
실무 기준으로 정리하면 이렇습니다. SKILL.md에는 작업 절차와 핵심 규칙만 넣고, 상세 레퍼런스(문체 가이드, SEO 체크리스트, 예시 글 등)는 보조 파일로 분리합니다. 보조 파일 하나당 150줄 이내면 클로드가 안정적으로 참조합니다. SKILL.md가 절차서라면, 보조 파일은 절차서에서 “참조”로 언급하는 부속 문서입니다.
직접 만들 수도, 남이 만든 걸 가져다 쓸 수도 있다
스킬을 확보하는 경로는 세 가지입니다.
첫째, 앤트로픽이 기본 제공하는 스킬입니다. 엑셀, 파워포인트, 워드, PDF 생성 등의 문서 스킬이 미리 내장되어 있고, Customize > Skills에서 토글만 켜면 작동합니다. 별도 설치가 필요 없습니다.
둘째, 다른 사람이 만든 스킬을 파일로 받아 업로드하는 방식입니다. 현재 GPT Store 같은 스킬 마켓은 없습니다. 대신 ZIP 또는 .skill 파일을 직접 전달받아 Customize > Skills에서 업로드합니다. 앤트로픽의 GitHub 저장소(github.com/anthropics/skills)에도 예제 스킬이 공개되어 있어 다운로드해서 참고하거나 그대로 등록할 수 있습니다. Team·Enterprise 플랜에서는 관리자가 조직 전체에 스킬을 배포하는 기능도 지원됩니다.
셋째, 직접 만드는 방식입니다. Customize > Skills에서 Skill Creator를 활성화한 뒤, 대화창에서 “글쓰기 스킬을 만들어줘”라고 요청하면 클로드가 용도, 문체, 작업 단계 등을 물어보며 SKILL.md와 보조 파일을 생성합니다. 스킬 구조를 모르는 상태에서도 대화만으로 첫 스킬을 만들 수 있는 경로입니다.
단계별 멈춤은 케바케가 아니라 3가지 조건의 조합이다
강의에서 같은 스킬을 실행했는데, 어떤 사람은 단계별로 멈추면서 확인을 받고, 어떤 사람은 한번에 끝까지 진행되었습니다. 케바케처럼 보이지만, 실제로는 3가지 조건의 조합입니다.
첫째, 모델 차이입니다. 오퍼스(Opus)는 SKILL.md에 “사용자 확인 후 다음 단계로 진행”이라는 규칙이 있으면 그대로 따르는 경향이 강합니다. 소넷(Sonnet)은 같은 규칙이 있어도 한번에 끝까지 진행하는 경우가 있습니다.
둘째, SKILL.md 설계 차이입니다. “각 Step 완료 후 사용자 확인을 받는다”는 규칙이 명시되어 있으면 단계별로 멈출 확률이 올라갑니다. 이 규칙이 없으면 클로드는 연속 진행합니다.
셋째, 사용자 지시입니다. “한 번에 끝까지 해줘”라고 요청하면 모델과 스킬 설계에 관계없이 연속 진행됩니다. 반대로 “1단계만 먼저 보여줘”라고 하면 멈춥니다.
원하는 동작이 있다면 SKILL.md에 명시하는 것이 가장 확실합니다. “각 Step 완료 후 사용자 확인을 받는다. 단, 사용자가 ‘한 번에 해줘’라고 요청한 경우 확인 없이 연속 진행한다.” 이 한 줄이면 대부분의 상황을 통제할 수 있습니다.
업데이트는 삭제 후 재업로드, 백업은 습관으로
스킬을 수정하는 방법은 두 가지입니다.
첫째, 클로드에게 수정을 요청하는 방법입니다. 대화창에서 “글쓰기 스킬의 금지어 목록에 ‘활용하다’를 추가해줘”라고 하면, 클로드가 수정된 스킬 파일을 ZIP으로 생성합니다. 이 파일을 다운로드한 뒤, Customize > Skills에서 기존 스킬을 삭제하고 새 파일을 업로드하면 됩니다.
둘째, 스킬 파일을 직접 편집하는 방법입니다. 로컬에 보관해둔 파일을 텍스트 에디터에서 수정한 뒤, 폴더를 ZIP으로 압축해서 다시 업로드합니다. 이 경우에도 기존 스킬을 먼저 삭제한 뒤 업로드하는 순서를 따릅니다.
두 방법 모두 “삭제 → 재업로드” 과정이 들어갑니다. 현재는 스킬을 선택해서 부분만 수정하는 인라인 편집 기능은 제공되지 않습니다. 수정 전에 기존 스킬 파일을 로컬에 백업해두면, 수정 결과가 마음에 들지 않을 때 이전 버전으로 돌아갈 수 있습니다. 스킬을 자주 수정하는 사람이라면 버전 번호를 붙여서 관리하는 것도 방법입니다.
처음 한 번의 벽을 넘으면, 다음은 수정과 확장이다
5가지 질문의 공통점이 있습니다. 모두 “처음 한 번”의 벽에서 나온 질문입니다. 이름 규칙, 파일 구조, 업로드 방법, 실행 방식, 수정 절차 — 한 번 경험하면 다음부터는 반복입니다.
스킬의 진짜 가치는 만든 이후에 나타납니다. 같은 기준으로 10번, 20번 반복 작업을 시켰을 때, 결과물의 일관성이 유지되는 경험을 하면 “왜 스킬을 만들어야 하는가”라는 질문은 사라집니다. 남는 건 “이 스킬을 어떻게 더 정밀하게 만들 것인가”입니다.
