AI 스터디 · 7주차
skill-creator— 스킬을 "감으로 고치는 것"에서 측정 가능한 아티팩트 로
스킬을 만들고 나서 "잘 트리거되나?" 어떻게 검증하나? skill-creator는 eval 세트, train/test 분리, 벤치마크 수치로 스킬 품질을 수치로 읽게 한다.
공식 설명 (verbatim): "Create new skills, modify and improve existing skills, and measure skill performance. Use when users want to create a skill from scratch, edit, or optimize an existing skill, run evals to test a skill, benchmark skill performance with variance analysis, or optimize a skill's description for better triggering accuracy."
발표자 노트: 표지에서 핵심 키워드만 짚고 넘어가기. "측정 가능한"이 이번 발표 전체의 키워드. 스킬을 쓰다 보면 "이게 제대로 트리거 되나?" 불안한 순간이 있는데, 그 불안을 수치로 바꾸는 게 오늘 주제.
출처: anthropics/skills — skills/skill-creator/SKILL.md
문제 인식
스킬을 "그냥 써보고 감으로 고치면" 무엇이 문제인가
스킬을 작성하고 → Claude에 붙여보고 → "잘 되는 것 같으면" 끝.
이게 검증 불가 인 이유는?
감(感) 기반 개선의 문제
트리거가 과소인지 과다인지 모름
description 수정이 나아진 건지 확인 불가
"됩니다" → 다음 버전에서 또 깨짐
이 스킬이 어느 케이스 를 못 잡는지 체계적으로 알 수 없음
skill-creator의 답
eval 세트로 구체적 테스트 케이스 를 만든다
train / test 60/40 분리 → 과적합 방지
iteration마다 벤치마크 수치 생성
description을 최대 5회 자동 반복 최적화
핵심 시각 전환: 스킬은 "vibe-writing" 대상이 아니라 테스트된 소프트웨어 아티팩트 다. skill-creator는 그 방법론을 도구로 굳힌 것.
발표자 노트: "검증 불가"라는 감각이 공감 포인트. 직접 스킬을 만들어본 사람은 "트리거 됐는지 어떻게 알아?"라는 불안을 느껴봤을 것. 그 불안을 수치로 해소하는 게 오늘 도구의 가치.
출처: anthropics/skills — skill-creator/SKILL.md
핵심 루프
skill-creator의 답: 반복 가능한 제작-평가 루프
공식 문서의 core loop (verbatim):
decide what skill should do → write a draft → create test prompts and run claude-with-the-skill on them → evaluate qualitatively AND quantitatively → rewrite based on feedback → repeat → expand test set at larger scale
"정성 AND 정량" 두 가지 모두를 강조하는 이유: 정성만으론 방향을 잡기 어렵고, 정량만으론 왜 틀렸는지 를 모른다. 두 평가가 함께 있어야 개선이 수렴한다.
발표자 노트: 이 루프는 소프트웨어 TDD(red-green-refactor)와 구조가 같다. 스킬 개발도 같은 원리 — 실패 케이스를 먼저 정의하고, 통과할 때까지 고친다. "expand test set at larger scale"이 중요 — 테스트셋이 작으면 과적합된 스킬이 만들어진다.
출처: anthropics/skills — skill-creator/SKILL.md (Core Loop)
핵심 메커니즘
Progressive Disclosure: 왜 스킬이 컨텍스트를 터뜨리지 않나
스킬이 많아질수록 컨텍스트 창이 폭발하지 않을까? — 3단계 점진적 로딩 이 이를 막는다.
1
메타데이터만 (name + description, ~100 words)
→ 항상(ALWAYS) 컨텍스트에 있음
Claude의 available_skills 목록에 이름+설명만 실린다. Claude는 이걸 보고 트리거 여부를 결정.
↓ 트리거되면
2
SKILL.md 본문 로드
→ 트리거 시(WHEN triggered), 이상적으로 <500 lines
실제 지시문·절차·제약이 담긴 SKILL.md 전체가 컨텍스트에 추가된다. 500줄 이내 권장.
↓ 필요하면
3
번들 리소스 로드
→ 필요 시(AS NEEDED), 무제한 크기
scripts/ · references/ · assets/ — 스크립트는 컨텍스트에 로드하지 않고 직접 실행 가능. 크기 제한 없음.
비유: 도서관 카탈로그(1단계) → 책 본문(2단계) → 책 안의 부록 CD(3단계). 카탈로그는 항상 손 안에 있고, 책은 골랐을 때만 꺼내고, CD는 꼭 필요할 때만 꺼낸다. 스킬 10개를 붙여도 컨텍스트에는 카탈로그 10개(~1000 words)만 평소에 있다.
scripts/는 컨텍스트에 로드하지 않고 실행된다 — 수천 줄짜리 파이썬 스크립트도 컨텍스트 부담 없이 번들할 수 있는 이유. 이것이 스킬이 확장성을 갖는 구조적 이유.
발표자 노트: 이 슬라이드가 "왜 스킬이 잘 설계된 메커니즘인가"를 설명하는 핵심. 컨텍스트 창 = RAM 비유로 설명하면 좋다. ALWAYS/WHEN triggered/AS NEEDED 세 키워드를 강조.
출처: anthropics/skills — skill-creator/SKILL.md (Progressive Disclosure 섹션)
인터랙티브 인터뷰
스킬 제작 시작: 4문 인터뷰로 설계를 굳힌다
skill-creator를 실행하면 먼저 4가지 질문을 던진다. 이 단계가 "감"으로 시작하는 것과 결정적으로 다른 지점.
질문 왜 이걸 먼저 묻나
1. 이 스킬은 Claude가 무엇을 하게 해야 하나?
범위를 좁혀 SKILL.md 본문의 초점을 잡는다
2. 언제 트리거되어야 하나? (사용자 문구·맥락)
description 초안의 트리거 패턴을 결정한다
3. 기대하는 출력 형식은?
eval 기준(expected_output)을 만들기 위한 사전 정의
4. 테스트 케이스를 바로 설정할까?
eval 루프를 즉시 연결할지 결정
인터뷰 없이 SKILL.md를 먼저 쓰면 → eval 케이스를 나중에 설계하기 어렵고, description이 "무엇을 트리거해야 하는지" 모호해진다. 순서가 중요.
발표자 노트: 4문 중 2번이 핵심. "언제 트리거" = description에 직접 영향. 3번 출력 형식 = evals.json의 expected_output 필드가 된다. 인터뷰를 건너뛰고 싶은 유혹이 있지만, 이 4문이 나중에 eval을 만들기 훨씬 쉽게 만든다.
출처: anthropics/skills — skill-creator/SKILL.md (Interactive Interview 섹션)
파일 구조
스킬이 만들어내는 파일 구조
skill-creator가 생성하는 디렉토리 레이아웃 — 각 폴더의 역할이 progressive disclosure 3단계와 1:1 대응한다.
skill-name/
├── SKILL.md # 필수. YAML frontmatter(name+description) + 마크다운 본문
│ # frontmatter = 1단계(ALWAYS), 본문 = 2단계(WHEN triggered)
├── scripts/ # 선택. 실행 가능한 결정론적 스크립트 → 컨텍스트 로드 없이 실행
├── references/ # 선택. 필요할 때만 로드하는 참조 문서
└── assets/ # 선택. 템플릿·아이콘·폰트 등
SKILL.md 구조
YAML frontmatter: name, description 필수
description이 트리거의 1차 판단 근거
본문: 마크다운, 500줄 이내 권장
scripts/ 의 특수성
결정론적(deterministic)이어야 함
실행 가능(executable) 형태
컨텍스트에 로드 없이 직접 실행
크기 제한 없음 — 대용량 로직 가능
evals/ 폴더는 skill-creator가 추가로 생성: evals/evals.json — eval 결과는 <skill-name>-workspace/iteration-N/eval-K/ 아래에 쌓인다.
발표자 노트: 파일 구조를 보여줄 때 "SKILL.md가 2개 역할을 한다"를 강조. frontmatter = 항상 보이는 카탈로그, 본문 = 트리거됐을 때 로드되는 지시문. scripts/는 "코드를 컨텍스트에 넣지 않고 실행한다"는 개념이 생소하므로 한 번 더 설명.
출처: anthropics/skills — skill-creator/SKILL.md (File Structure 섹션)
Eval 루프 · 코드/메커니즘
Eval 루프: train/test 분리로 과적합을 막는다
이 슬라이드가 핵심 — 단순 "테스트"와 다른 이유가 여기 있다.
evals.json 구조
{
"skill_name": "my-skill",
"evals": [
{
"id": "eval-01",
"prompt": "...",
"expected_output": "..." ,
"files": [] // 첨부 파일 (선택)
}
]
}
결과 디렉토리 & 벤치마크
<skill-name>-workspace/
└── iteration-N/
├── eval-K/ # 각 eval 결과
└── timing.json # total_tokens, duration_ms 포함
# 벤치마크 집계
python -m scripts.aggregate_benchmark <workspace>/iteration-N \
--skill-name <name>
→ benchmark.json + benchmark.md 생성
벤치마크가 주는 것: iteration 간 비교 가능한 수치 + 분산(variance) 분석. "이번 수정이 나아졌나?"를 감이 아닌 숫자로 답 한다.
발표자 노트: timing.json의 total_tokens + duration_ms — 성능 비교에 쓰인다. iteration-N 폴더가 쌓이면 "1회차 벤치 vs 3회차 벤치" 비교가 가능. 이게 "버전 관리된 스킬 개선"의 증거.
출처: anthropics/skills — skill-creator/SKILL.md (Eval System 섹션)
Description 최적화
Claude는 스킬을 과소 트리거한다 — 그래서 description을 최적화한다
스킬이 있어도 Claude가 꺼내지 않으면 의미 없다. skill-creator는 description 자체를 자동 반복 개선한다.
트리거 eval 구성 (~20개)
Should-trigger (8-10개)
이 스킬이 반드시 동작해야 하는 사용자 문구. 예: "스킬 만들어줘", "새 skill 작성"
Should-NOT trigger (8-10개)
근접 오발사(near-miss) : 비슷해 보이지만 이 스킬이 아닌 케이스. 예: "코드 리뷰해줘"
자동 최적화 루프
python -m scripts.run_loop \
--eval-set <path> \
--skill-path <path> \
--model <id> \
--max-iterations 5
→
→
best_description TEST 점수로 선택
best_description 선택 기준이 TEST 점수 라는 것이 중요. train 점수로 고르면 과적합 — 테스트셋에서만 좋은 description이 실제로도 좋다.
왜 "살짝 pushy"하게 만들라 하나: Claude는 기본적으로 스킬을 과소트리거 하는 경향이 있다. description이 소극적이면 사용자가 명시적으로 불러도 Claude가 스킬을 꺼내지 않는다.
발표자 노트: "undertrigger" 개념이 체감이 안 될 수 있다. 예: 스킬 description에 "코드 리뷰 요청 시 사용"이라고만 써두면 Claude가 "이건 그냥 내가 리뷰해도 되겠다"라고 판단해 스킬을 꺼내지 않는다. near-miss 케이스를 description에 반영하면 경계가 명확해진다.
출처: anthropics/skills — skill-creator/SKILL.md (Description Optimization 섹션)
패키징 · 환경 적응
패키징과 환경별 적응
패키징
python -m scripts.package_skill <folder>
→ .skill 파일 생성
사용자가 설치할 수 있는 단일 파일. 폴더 전체(SKILL.md + scripts/ + references/ + assets/)를 번들.
.skill 파일 = 배포 단위. "내가 만든 스킬 팀원에게 공유"가 이 파일 하나로 가능.
환경 적응
환경 제약 / 적응
Claude.ai 서브에이전트 없음 → 테스트를 하나씩 실행, baseline 생략
Cowork 서브에이전트 있음, 브라우저 없음 → --static으로 독립 HTML 뷰어
환경에 따라 eval 실행 방식이 달라진다. 로컬 Claude Code에서 돌리는 게 가장 완전한 eval 경험.
발표자 노트: 패키징 명령 한 줄이 단순해 보이지만, "재현 가능한 배포 단위"를 만든다는 점에서 중요. 환경 적응 표는 "왜 로컬에서 eval 하면 더 좋은가"를 설명하기 위한 컨텍스트.
출처: anthropics/skills — skill-creator/SKILL.md (Packaging, Environment Adaptations 섹션)
정리
skill-creator가 바꾸는 것 하나
"스킬을 만들었다" 에서"스킬이 이 케이스를 X% 잡는다" 로.
요소 이전 (ad-hoc) skill-creator 사용 후
트리거 검증 감(感), 직접 써보기 should/should-not eval 20개 + 수치
개선 방향 description 랜덤 수정 train 60%로 반복, test 40%로 선택
버전 비교 기억에 의존 iteration-N 벤치마크 수치 비교
배포 폴더 복사 .skill 파일 단일 배포
메타 교훈: 스킬도 소프트웨어다. 소프트웨어는 테스트하고 측정한다. skill-creator는 그 원칙을 스킬 개발에 적용한 도구.
이번 주에 해볼 것: 평소 Claude에게 자주 시키는 작업이 있다면, 그걸 스킬로 만들고 should-trigger 케이스 5개만 적어보기. 측정 가능한 스킬의 첫 걸음.
발표자 노트: 표의 "이전 vs 이후" 비교가 핵심 메시지. 청중이 "나도 이렇게 만들어야겠다"고 느끼면 성공. 마지막 callout의 "5개만"이 중요 — 부담을 낮춰 실제로 해보게 유도.
출처: anthropics/skills — skill-creator/SKILL.md
참고자료
참고자료
이 자료의 모든 인용문, 명령어, 파일 구조, 수치는 위 SKILL.md에서 직접 확인한 것만 포함했습니다. 확인되지 않은 내용은 생략했습니다.
발표자 노트: 질문 받을 때 "원문 어디 있나요?"라는 질문이 가장 많이 나온다. SKILL.md 링크 하나로 답 가능. 발표 전날 링크가 살아있는지 확인.