저 사실 고백할 게 있습니다.
AI 스킬을 33개 만들어놓고, 한 번도 테스트해본 적이 없습니다.
블로그 작성 스킬, 트레이딩 코치 스킬, 크립토 분석 스킬, URL 요약 스킬… 1년 넘게 하나씩 쌓아왔어요. 새 스킬 만들 때마다 뿌듯했고, 에이전트 팀까지 구성하면서 “나 이제 좀 하는데?” 싶었습니다.
근데 말이죠.
만드는 건 재밌었는데, 관리는 한 번도 안 했어요.
3월 3일에 Anthropic이 skill-creator에 evals와 benchmark 기능을 추가했다는 글을 읽었습니다. 처음엔 “오, 좋은 기능이네” 하고 넘길 뻔했어요. 근데 한 문장이 발목을 잡더라고요.
“대부분의 스킬 작성자는 엔지니어가 아니라 도메인 전문가다. 스킬이 계속 작동하는지 검증할 인프라가 없다.”
이거 완전 내 얘기잖아요.
그래서 그날 바로 제 전체 시스템을 감사해봤습니다. 에이전트 63개, 스킬 33개(+아카이브 12개), 설정 파일, 메모리, 규칙까지 전부.
결과요?
42점(100점 만점).
만드는 건 5분, 망가지는 건 조용히
스킬을 만드는 건 쉽습니다. Claude한테 “이거 스킬로 만들어줘” 하면 5분이면 됩니다.
근데 그 스킬이 언제부터 안 되고 있었는지 아는 건 어렵습니다.
제가 감사하면서 발견한 것들을 보여드릴게요.
유령 참조 5건
obsidian-semantic-brain → 3곳에서 참조 중 → 스킬 자체가 없음 blog-insight-analyzer → 4곳에서 참조 중 → 3달 전에 blog-analytics로 병합됨 portfolio-risk-checker → goal-tracker에서 참조 → portfolio-checker로 이름 바뀜
이게 무슨 뜻이냐면요.
블로그 글 쓸 때 AI가 “obsidian-semantic-brain을 호출해야겠다” → 없음 → 조용히 실패 → 글 품질 저하.
에러 메시지도 안 뜹니다. 그냥 조용히 없는 스킬을 찾다가 포기하고 넘어가요.
소프트웨어에서 가장 무서운 버그가 뭔지 아시죠? 크래시 나는 버그가 아니라 조용히 틀린 결과를 내는 버그입니다. AI 스킬도 똑같아요.
절대경로 하드코딩 2건
agents/ralph-loop-team.md → /Users/jtpark/Library/... (하드코딩) agents/agent-ops.md → WORKSPACE = /Users/jtpark/... (하드코딩)
이건 제 맥에서만 돌아가는 코드를 공유 가능한 시스템이라고 착각하고 있었던 거예요. 다른 환경으로 옮기는 순간 전부 터집니다.
context/ vs MEMORY/warm/ 이중 경로
같은 파일이 두 곳에 있는데, 버전이 달랐습니다.
| 파일 | context/ | MEMORY/warm/ |
|---|---|---|
| recent-patterns.md | 2026-02-28 (최신) | 2026-02-19 (구버전) |
| my-crypto-perspective.md | 2026-02-27 (최신) | 2026-02-15 (구버전) |
어떤 규칙은 context/를 가리키고, 어떤 건 MEMORY/warm/을 가리켜요. AI가 어느 쪽을 읽느냐에 따라 글의 트레이딩 관점이 달라지는 상황이었습니다.
이런 걸 1년 동안 몰랐어요.
42점이 나온 이유: P0 9건, P1 15건, P2 18건
전수 감사 결과를 스코어보드로 정리했습니다.
| 영역 | P0 (치명) | P1 (경고) | P2 (제안) |
|---|---|---|---|
| 에이전트 (63개) | 2 | 4 | 6 |
| 스킬 (33개) | 3 | 6 | 5 |
| 문서 | 2 | 2 | 3 |
| 규칙/메모리 | 1 | 2 | 1 |
| 루트 설정 | 1 | 1 | 1 |
| 합계 | 9 | 15 | 18 |
P0 9건 중에서 가장 황당했던 건 뭐냐면요.
33개 활성 스킬 중 Evals 섹션이 있는 스킬: 0개.
하나도 없었습니다. 테스트 코드 없는 프로덕션 서비스를 1년 돌린 셈이에요.
그리고 1389줄짜리 스킬이 있었습니다. 블로그 작성용 unified-blog-writer인데요. 공식 가이드라인이 50-100줄이거든요. 14배 초과. Good/Bad 예시가 100줄, 중복 체크리스트가 6개, 변경 로그만 60줄. 쌓이고 쌓이다 보니 이 지경이 된 거예요.
문제는 이게 “그냥 길어서” 안 좋은 게 아니에요. AI가 이 스킬을 로드하면 컨텍스트 윈도우를 1400줄이나 차지합니다. 정작 중요한 대화 내용이 밀려나요.
소프트웨어 개발에서 테스트 없이 배포하면 욕먹잖아요. 근데 AI 스킬은 아무도 뭐라 안 해요. 왜냐면 아직 스킬에 테스트를 붙이는 게 표준이 아니니까요.
그래서 Anthropic이 움직인 겁니다.
Anthropic이 3월 3일에 한 일
Anthropic은 2026년 3월 3일, skill-creator에 4가지 모드를 추가했습니다.
| 모드 | 기능 | 비유 |
|---|---|---|
| Create | 스킬 생성 | 코드 작성 |
| Eval | 테스트 작성 + 실행 | 유닛 테스트 |
| Benchmark | 성능 측정 (pass rate, 토큰, 시간) | CI/CD 파이프라인 |
| Improve | 결과 기반 개선 | 리팩토링 |
기존에는 Create만 있었어요. “잘 만들어라.” 끝.
이제는 **”만든 다음에 검증하고, 측정하고, 개선해라”**까지 한 세트입니다.
Eval 파이프라인의 구조
내부적으로 4개의 서브 에이전트가 병렬로 돌아갑니다.
Executor → 스킬에 테스트 프롬프트를 던짐 Grader → 출력을 기대 결과와 비교 Comparator → 스킬 A vs B를 블라인드 비교 Analyzer → 패턴을 찾아서 개선안 제시
여기서 Comparator가 특히 중요한데요. “스킬 있을 때 vs 없을 때”를 블라인드로 비교해줍니다.
왜 중요하냐고요?
스킬이 오히려 성능을 깎는 경우가 있거든요. 너무 장황한 규칙이 모델의 자연스러운 추론을 방해하는 거예요. 이걸 수치로 확인할 수 있게 된 겁니다.
Anthropic이 자사 문서 생성 스킬 6개를 테스트했더니, 5개에서 트리거 품질이 개선됐다고 합니다. 자기네 스킬도 안 완벽했다는 뜻이에요.
트리거 설명문이 왜 그렇게 중요한지
스킬이 아무리 잘 만들어져 있어도, 불러지지 않으면 소용없습니다.
description이 너무 넓으면? “블로그 써줘”라는 요청에 블로그 관련 스킬 3개가 동시에 발동합니다. description이 너무 좁으면? 정확히 “unified-blog-writer-markdown-eeat 실행해줘”라고 말해야만 불립니다.
제 시스템에서도 트리거 겹침이 6그룹이나 있었습니다.
| 그룹 | 겹치는 스킬 | 위험 |
|---|---|---|
| 블로그 작성 | unified-blog-writer vs blog-writer-skill | “블로그 써줘”에 둘 다 발동 |
| 크립토 분석 | crypto-analyzer vs crypto-multi-analyzer | “BTC 분석해줘”에 둘 다 후보 |
| 포트폴리오 | portfolio-checker vs weekly-portfolio-snapshot | “포트폴리오 점검”에 둘 다 후보 |
이런 건 evals의 false positive/false negative 테스트 없이는 발견이 안 돼요. 실제로 써보면서 “어? 왜 엉뚱한 스킬이 불렸지?” 할 때야 비로소 알게 되는 거예요.
스킬 유형이 테스트 전략을 바꾼다
Anthropic이 이번 업데이트에서 강조한 개념이 하나 있습니다.
Capability Uplift vs Encoded Preference.
| 유형 | 설명 | 예시 | 모델 업그레이드 영향 |
|---|---|---|---|
| Capability Uplift | 모델이 못하는 걸 가르침 | 특수 포맷 변환, 도메인 지식 | 모델이 좋아지면 불필요해질 수 있음 |
| Encoded Preference | 내 워크플로우를 인코딩 | 블로그 작성 규칙, 트레이딩 체크리스트 | 모델과 무관하게 항상 필요 |
제 33개 스킬을 분류해봤더니요.
전부 Encoded Preference였습니다.
하나도 빠짐없이. Capability Uplift가 0개.
이건 뭘 의미하냐면, 제 스킬들은 “Claude가 못하는 걸 가르친 게 아니라, 제가 일하는 방식을 기록해둔 것”이라는 거예요.
좋은 소식: Claude 5가 나와도 제 스킬은 안 깨집니다. 워크플로우는 모델 성능과 무관하니까요. 나쁜 소식: 그렇다고 테스트 안 해도 되는 건 아닙니다. 내 워크플로우 자체가 변하거든요.
3달 전에 portfolio-risk-checker를 portfolio-checker로 병합했는데, 참조하는 곳을 안 고쳤어요. 이건 모델 업그레이드 문제가 아니라 내가 시스템을 바꾸면서 정합성을 안 챙긴 문제입니다.
Encoded Preference 스킬에서 evals가 잡아야 할 건 이런 겁니다:
- 참조하는 파일/스킬이 아직 존재하는가?
- 출력 형식이 기대대로인가?
- 트리거 description이 다른 스킬과 안 겹치는가?
실제로 고친 것들: 하루 30건 수정
감사 결과를 보고 그날 바로 수정에 들어갔습니다.
P0 수정 (13건, 1시간)
| 작업 | 수정 |
|---|---|
| 절대경로 2개 | {WORKSPACE} 상대경로로 교체 |
| 유령 스킬 5건 | 실제 스킬명으로 교체 (obsidian-semantic-brain → Grep + SemanticSearch) |
| docs 유령 참조 4건 | @skill-creator → “AI가 .claude/docs/ 직접 참조” |
| .cursorrules 예시 | 존재하지 않는 markdown-formatter → 실제 url-summarizer로 교체 |
P1 수정 (17건, 2시간)
| 작업 | 수정 |
|---|---|
| context/ → MEMORY/warm/ 동기화 | 3개 파일 최신 버전으로 덮어쓰기 |
| 경로 통일 | rules, skills, agents 8곳에서 context/ → MEMORY/warm/ |
| Evals 추가 | 자주 쓰는 5개 스킬에 트리거 검증 + 출력 검증 + 벤치마크 추가 |
| 인벤토리 재생성 | 33 active + 12 archive 반영 |
| 숫자 업데이트 | CLAUDE.md 에이전트/스킬 카운트 수정 |
Evals 추가한 5개 스킬이 뭐냐면요.
url-summarizer — 가장 단순. eval 작성 연습용으로 딱 trading-coach — 매일 쓰니까 회귀 방지 중요 crypto-analyzer — 출력 형식(29개 지표 표)이 정확한지 검증 blog-idea-manager — Archive/중복 탐지 로직 검증 inbox-organizer — 모드별(정리/분석/이동) 동작 검증
각 스킬에 넣은 eval 구조는 이렇습니다:
트리거 검증: "이 프롬프트에 불려야 하는가?" 4개
"이 프롬프트에 불리면 안 되는가?" 4개
출력 검증: "이 섹션이 포함되어야 하는가?" 3-4개
벤치마크: pass_rate, avg_tokens, avg_time 추적
스킬당 5분이면 됩니다. 어렵지 않아요. 근데 이 5분을 1년 동안 안 한 거예요.
보너스: 1389줄 → 954줄 압축
가장 자주 쓰는 unified-blog-writer 스킬이 1389줄이었습니다.
가이드라인이 50-100줄인데 14배 초과. 문제는 분리하면 다른 IDE(Claude Code, Codex)에서 호출할 때 서브 파일을 못 읽을 수 있다는 거였어요.
그래서 전략을 바꿨습니다. 분리 대신 압축.
- Good/Bad 예시 100줄 삭제
- 중복 체크리스트 6개 → 1개로 통합
- 변경 로그 60줄 → 테이블 12줄
- 경험 표현 예시 압축
결과: 954줄. 31% 감량. 파일 1개 유지하면서 크로스 IDE 호환성 확보.
내가 느낀 점
이 작업을 하면서 계속 드는 생각이 있었어요.
“나 이거 1년 동안 뭐 한 거지?”
33개 스킬을 만들면서 한 번도 “이거 제대로 작동하고 있나?” 확인을 안 했습니다. 새 스킬 만드는 건 도파민이 나오거든요. 기존 스킬 점검하는 건 안 나옵니다.
소프트웨어 엔지니어링에서 수십 년 전에 배운 교훈이잖아요.
“코드 작성 시간의 20%가 새 기능이고, 80%가 유지보수다.”
AI 스킬도 똑같았습니다. 아니, 더 심해요. 왜냐면 AI 스킬은 조용히 실패하거든요. 컴파일 에러도 없고, 런타임 에러도 없어요. 그냥 결과물이 살짝 나빠질 뿐.
불안하지만 방향은 찾았습니다
Anthropic이 evals와 benchmark를 공식 지원하기 시작했다는 건, 이 문제가 저만 겪는 게 아니라는 뜻이에요.
Minko Gechev의 블로그에서 본 문장이 정확히 제 상황이었습니다:
“Skills are procedural instructions that teach agents how to use tools and follow workflows. Testing them requires running agents in isolated containers and tracking skill adherence scores over time.”
스킬은 절차적 지시문이고, 테스트하려면 독립된 환경에서 에이전트를 돌리면서 점수를 추적해야 한다.
맞는 말인데, 이게 원래 쉬운 일이 아니에요. 소프트웨어 테스트도 귀찮은데, AI 스킬 테스트는 비결정적(non-deterministic)이라 더 어렵습니다. 같은 입력에 다른 출력이 나오니까요.
앞으로 할 것들
- 나머지 28개 스킬에 Evals 추가 — 스킬당 5분씩, 점진적으로
- 트리거 겹침 6그룹 description 개선 — false positive 줄이기
- 분기별 전수 감사 — 이번에 한 번 해보니까 패턴이 보임
이번 경험에서 배운 가장 큰 교훈은 이겁니다.
“잘 만드는 것보다 안 망가지는 게 중요하다.”
새 스킬 만들 시간에 기존 스킬 5개에 eval 붙이세요. 진짜로요.
FAQ
Q1. Evals 없이도 스킬 잘 쓰고 있는데 꼭 필요한가요?
꼭은 아닙니다. 스킬 5개 이하이고, 혼자 쓰고, 자주 안 바꾸면 직감으로 충분해요. 근데 10개 넘어가는 순간부터 “어? 이거 원래 이렇게 동작했나?” 하는 순간이 옵니다. 그때는 이미 늦었어요.
Q2. Capability Uplift 스킬이 0개인 게 문제인가요?
오히려 좋은 신호입니다. Encoded Preference 스킬은 모델 업그레이드에 영향받지 않아요. Claude 5가 나와도 “내 블로그 작성 규칙”은 변할 이유가 없으니까요. Capability Uplift 스킬은 모델이 좋아지면 오히려 불필요해집니다.
Q3. 1389줄짜리 스킬, 분리 안 하고 압축만 해도 되나요?
됩니다. 핵심은 “다른 IDE에서도 스킬 파일 1개만 읽으면 전부 작동하는가?”입니다. 분리하면 Claude Code에서는 서브 파일을 자동으로 안 읽을 수 있어요. 압축은 중복 제거와 예시 정리로 충분히 효과가 있었습니다. 31% 줄었거든요.
Q4. 전수 감사는 어떻게 시작하나요?
제가 한 방법: (1) 모든 스킬/에이전트 파일을 AI에게 읽히고 (2) “존재하지 않는 참조 찾아줘”부터 시작 (3) P0/P1/P2로 분류 (4) P0부터 즉시 수정. 처음이 가장 오래 걸리고, 두 번째부터는 패턴이 보여서 빠릅니다.
Q5. 트리거 겹침은 어떻게 해결하나요?
각 스킬 description에 배타적 키워드를 넣으면 됩니다. 예: portfolio-checker는 “실시간 리스크 검증 + 청산 위험 경고”, weekly-portfolio-snapshot은 “일요일 주간 결산 리포트 생성”. 사용 시점과 목적이 다르면 description에 그걸 명확하게 적어야 합니다.
Q6. Anthropic의 Comparator가 정확히 뭔가요?
스킬 버전 A와 B를 블라인드로 비교해주는 에이전트입니다. “스킬 있을 때 vs 없을 때” 비교도 가능해요. 핵심은 블라인드라는 것 — 어느 쪽이 스킬을 쓴 건지 모르는 상태에서 품질을 평가하니까 편향이 줄어듭니다.
Q7. 이거 개발자가 아니어도 할 수 있나요?
네. 오히려 Anthropic의 포인트가 그거예요. “스킬 작성자 대부분은 엔지니어가 아니라 도메인 전문가다.” 코드를 몰라도 “이 프롬프트에 이 스킬이 불려야 한다 / 불리면 안 된다” 정도는 적을 수 있잖아요. 그게 eval의 시작입니다.
결론: 만드는 것에서 운영하는 것으로
AI 스킬 생태계는 지금 “만드는 시대”에서 “운영하는 시대”로 넘어가고 있습니다.
Anthropic이 evals와 benchmark를 공식 지원하기 시작한 건, 스킬이 충분히 쌓인 팀들이 이제 **”이거 진짜 작동하는 거 맞아?”**를 묻기 시작했다는 뜻이에요.
제가 직접 겪어보니 확실합니다.
- 만들 때는 모릅니다. 유령 참조, 절대경로, 이중 경로 — 만드는 시점에는 전부 정상입니다.
- 시간이 지나면 망가집니다. 스킬 이름 바꾸고, 폴더 옮기고, 새 스킬 추가하면서 정합성이 무너집니다.
- 조용히 실패합니다. 에러 메시지가 없어요. 결과물이 살짝 나빠질 뿐이에요.
하나만 해보세요.
지금 가장 자주 쓰는 스킬 하나를 골라서, “이 스킬이 불려야 하는 프롬프트 3개”와 “불리면 안 되는 프롬프트 3개”를 적어보세요.
이게 eval의 시작이고, 이게 스킬을 운영하는 첫걸음입니다.
저도 이걸 1년 뒤에야 깨달았어요. 여러분은 좀 더 일찍 시작하시길 바랍니다.
진짜로요.
참고 자료
- Improving skill-creator: Test, measure, and refine Agent Skills — Anthropic 공식 블로그 (2026-03-03)
- Anthropic brings evals to skill-creator — tessl.io 분석
- Unit Tests for AI Agent Skills — Minko Gechev 블로그
- AgentAssay: Token-Efficient Regression Testing — arxiv 논문 (2026-03)
- AI Agent Evaluations: The Complete 2025-2026 Guide
🏷️ 태그: #AI에이전트 #스킬운영 #evals #benchmark #ClaudeCode #Anthropic #AI자동화 #프롬프트엔지니어링