에이전트용 「스킬 (Skill)」을 작성해 본 적이 있다면, SKILL.md라는 이름이 익숙할 것이다. 이름과 설명을 YAML로 작성하고, 그 아래에 절차나 가드레일 (Guardrail)을 Markdown으로 나열하기만 하면 되는 파일로, Claude Code, Codex, Cursor, Gemini CLI가 모두 이 형식을 읽게 되었다. 간편함 덕분에 수는 폭발적으로 늘어났지만, "많이 쌓으면 에이전트는 똑똑해지는가"를 제대로 측정한 사람은 없었다.

그 부분을 정면으로 측정한 것이 7월 17일에 arXiv에 발표된 SkillCorpus다. 공개된 스킬을 긁어모아 선별하고, 실제 태스크 (Task)에서 얼마나 효과적인지를 벤치마크 (Benchmark)로 검증하고 있다. 결론부터 말하자면, 효과는 「스킬의 수」에 의해 거의 결정되지 않는다.

논문 팀은 62개의 소스에서 약 82만 1,000개의 SKILL.md를 수집했다. 하지만 구조 필터와 리포지토리 (Repository) 단위의 중복 제거를 거치면, 파이프라인에 들어오는 것은 2만 5,159개 리포지토리까지 줄어든다. 가장 많이 깎여 나간 것이 중복 제거 단계로, 완전 일치만으로 입력의 59.7%가 사라졌고, 추가로 코사인 유사도 (Cosine Similarity) 0.90 초과로 의미론적으로도 걸러냈다. LLM 판정으로 「거의 동일」하다고 확인된 쌍은 25.4%에 달했다. 최종적으로 남은 공개 스킬은 9만 6,401개였다.

즉, 세상에 퍼져 있는 「80만 개」라는 숫자의 상당 부분은 동일한 결과물을 리포지토리 간에 복사한 것이다. 에코시스템 (Ecosystem)이 커 보이는 것은 내용이 다양해서가 아니라, 많은 부분이 복제되었기 때문이기도 하다. 남은 9만 6,401개도 일률적이지 않아서, 품질 점수 (Quality Score)가 0.7 이상인 것은 58.8%, 반대로 거의 쓸모없는 0.3 미만의 스킬도 2.8% 섞여 있었다.

선별은 16개 분류의 택소노미 (Taxonomy)와 유용성·견고성·안전성의 3축 (각 0~10점)으로 수행한다. 안전성은 프롬프트 인젝션 (Prompt Injection)이나 커맨드 인젝션 (Command Injection), 인증 정보 유출과 같은 실질적인 해악을 보는 축이며, 위험 플래그에 걸린 915개는 가차 없이 제외된다.

여기서부터가 흥미롭다. 3축을 0.50u + 0.35r + 0.15s로 합성한 품질 점수는 태스크 성공률을 거의 예측하지 못했다 (상관관계는 모두 |r|<0.10). 유일하게 안전성 축만이 SkillsBench에서 약한 양의 신호를 가지고 있었다.

이는 실무적으로 매우 중요하다. 스킬을 「품질 점수 순」으로 나열하는 마켓플레이스 (Marketplace)를 만들어도, 그 순위는 「실제로 효과가 있는가」와는 별개라는 뜻이 된다. 설명의 친절함이나 정성 들여 만든 외관은 에이전트의 성과와 직결되지 않는다. 수를 자랑하는 것도, 점수로 나열하는 것도 지표로서는 믿을 수 없다. 「좋아 보이는 스킬」을 측정하는 척도가 성과와 무관했다는 결과는, 화려하지는 않지만 유효한 부정적 지견 (Negative Insight)이라고 생각한다.

그렇다면 무엇이 효과를 가르는가. 하나는 해당 태스크에 맞는 스킬이 재고로 있는가이다. 검색 일치도로 태스크를 구분하면, 최하위 구간에서는 평균 +2.2포인트밖에 늘어나지 않지만, 최상위 구간에서는 +25.1포인트 늘어난다. 수학 (해당 4건)이나 금융 (9건)처럼 재고가 적은 분야에서는 효과가 거의 제로가 되었다. 논문은 이를 「검색의 문제가 아니라 공급의 문제」라고 구분하고 있다. 수중에 있는 태스크에 맞는 스킬이 애초에 없다면, 아무리 똑똑하게 검색해도 의미가 없다.

또 하나는 에이전트 측의 하네스 (Harness) 구성이다. 같은 스킬을 주입해도, 실행하고 검증하고 수정하는 루프를 돌리는 Raven은 SkillsBench에서 +13.4포인트 늘어난 반면, 추론에서 그치기 쉬운 OpenClaw는 +5.7포인트에 머물렀다. 스킬은 「읽고 끝」나서는 효과가 없으며, 직접 움직이는 에이전트여야만 효과를 발휘한다.

베이스라인이 78할로 높은 GDPVal이나 QwenClawBench에서 상승폭이 작은 것은 천장 효과 (Ceiling Effect) 때문이며, 여기서는 원래의 판정 노이즈 (2027포인트)도 크다. 반대로, 프런티어 모델 (Frontier Model)인 Claude Opus 4.7에서도 +8.0포인트가 나와, 약한 모델 전용 테크닉이 아님을 확인했다.

주입 방식도 허술하지 않다. Qwen3 기반의 임베딩 (Embedding)으로 1차 검색하고, 재순위화 (Re-ranking)한 후보 중에서 LLM이 정말로 필요한 0~2개만을 골라 삽입한다. 문맥에 전부를 집어넣는 것이 아니라, 압축한다. 이는 스스로 스킬을 사용할 때도 유효한 교훈이다.

SkillCorpus의 데이터셋과 코드 자체는 「채택 후 공개」라고 되어 있어 아직 내려받을 수 없다. 다만 스킬의 표준 형식과 그것을 배포하는 메커니즘은 이미 작동하고 있다.

예를 들어 huggingface/skills는 Hugging Face 조작법을 27개의 스킬로 정리한 것이며, Claude Code라면 다음과 같이 입력한다.

/plugin marketplace add huggingface/skills
/plugin install hf-cli@huggingface/skills
hf skills add <skill-name>

SKILL.md의 내용은 다음과 같은 구조다.

---
name: my-skill-name
description: Describe what the skill does and when to use it
...

직접 스킬을 만들어 평가하고 싶다면 huggingface/upskill을 사용할 수 있다. 이는 고가의 모델(teacher)로 절차를 작성하고, 저가의 모델(student)이 그것을 사용하여 어려운 태스크를 수행할 수 있는지 실측한다는 발상에서 나온 도구다.

uv pip install upskill
upskill generate "write good git commit messages"
upskill eval ./skills/git-commit-messages/ -m haiku -m sonnet

SkillCorpus의 수치를 고려한다면, upskill eval과 같이 "해당 스킬이 정말로 성공률을 높였는가"를 실행하여 확인하는 자세야말로 정답에 가깝다. 스킬을 늘리기 전에, 자신의 태스크에 재고가 있는지, 에이전트가 실행부터 검증까지 수행하는지, 주입하는 스킬은 엄선된 몇 개뿐인지. 이 세 가지 점을 파악해야 비로소 스킬의 산은 전력이 된다.