에이전트 스킬은 만들기보다 검증이 더 중요하다 2026 — SkillsBench로 본 Claude Code·Codex·Gemini 차이

Posted on by

처음엔 스킬을 많이 만드는 게 핵심이라고 생각했다. SKILL.md 파일을 잘 쓰고, 폴더 구조를 깔끔하게 잡으면 에이전트가 알아서 잘 따라올 거라고. 그래서 40개 넘는 스킬을 만들었다. 블로그 파이프라인, 트레이딩 분석, 온톨로지 관리까지. 3개월쯤 지나서야 알게 된 건, 스킬을 만드는 시간보다 그 스킬이 정말 작동하는지 확인하는 시간이 3배 이상 걸렸다는 사실이다.

2026년 2월, 이 의심을 데이터로 확인해 준 논문이 나왔다. SkillsBench(arXiv:2602.12670)다. 86개 태스크, 11개 도메인, 7개 프론티어 모델을 돌려서 “에이전트 스킬이 실제로 얼마나 효과가 있는지”를 처음으로 정량 측정한 벤치마크다.

결론부터 요약하면 이렇다.

사람이 검증하고 다듬은(curated) 스킬은 통과율을 평균 16.2 퍼센트 포인트 올렸다. 반면 모델이 스스로 만든(self-generated) 스킬은 효과가 0이거나 오히려 마이너스였다. 스킬의 양이 아니라 품질과 검증이 성능을 결정한다.

이 글에서는 SkillsBench의 핵심 데이터를 뜯어보고, Claude Code·Codex·Gemini CLI가 스킬을 어떻게 다르게 소화하는지 비교한다. 마지막에는 내 볼트에서 40개 스킬을 운영하면서 실제로 적용해 본 검증 체크리스트를 정리한다.

지금 결론: 스킬은 만드는 난이도가 아니라 검증 여부로 갈린다

SkillsBench가 보여주는 핵심 구도는 명확하다.

조건 평균 통과율 변화 해석
스킬 없음 (baseline) — 모델의 기본 역량
curated 스킬 제공 +16.2pp 사람이 다듬고 검증한 지식의 효과
self-gen 스킬 제공 +0pp~마이너스 모델이 자작한 스킬은 효과 없음

여기서 curated란 “잘 쓴” 게 아니라 “태스크에 맞게 검증·큐레이션한” 스킬을 뜻한다. 같은 SKILL.md 포맷이라도 내용이 모호하거나 범위가 안 맞으면 오히려 성능이 떨어진다.

실무 시사점은 두 가지다.

  1. 스킬을 많이 만드는 데 시간을 투자하지 말고, 기존 스킬이 실제 태스크에서 통과하는지 검증하라.
  2. 모델에게 “이 작업에 필요한 스킬을 직접 만들어”라고 시키는 건 아직 효과가 없다. 사람이 개입해야 한다.

SkillsBench 구조: 86개 태스크로 보는 테스트 설계

벤치마크 개요

  • 논문: SkillsBench: Benchmarking How Well Agent Skills Work Across Diverse Tasks (arXiv:2602.12670, 2026년 2월)
  • 태스크 수: 86개 (태스크당 5회 반복 시행)
  • 도메인 수: 11개 (과학, 금융, 헬스케어, 사이버보안, 에너지, SW 엔지니어링, 제조, 로보틱스, 일반 오피스 등)
  • 평가 모델: 7개 프론티어 모델 (GPT-5.2, Claude Opus 4.5, Opus 4.6, Sonnet 4.5, Haiku 4.5, Gemini 3 Pro, Gemini 3 Flash)
  • 에이전트 하네스: Claude Code, Codex CLI, Gemini CLI

3가지 실험 조건

SkillsBench는 같은 태스크를 세 가지 조건으로 돌린다.

  1. No skill — 스킬 없이 모델 기본 역량만으로 실행
  2. Curated skill — 전문가가 작성하고 검증한 스킬을 제공
  3. Self-generated skill — 모델이 태스크 설명을 보고 직접 작성한 스킬을 제공

이 설계가 좋은 이유는, “스킬 포맷 자체의 효과”와 “스킬 내용의 품질 효과”를 분리할 수 있기 때문이다. 기존에는 “스킬을 쓰면 좋아지더라”는 경험칙만 있었지, curated vs self-gen의 차이를 정량 비교한 데이터는 없었다.

핵심 비교: 에이전트별 성능 차이와 스킬 활용 패턴

에이전트-모델별 리더보드 (curated 스킬 기준)

순위 에이전트 + 모델 통과율 (스킬 적용) 스킬 없이 대비 변화
1 Gemini CLI + Gemini 3 Flash 48.7% —
2 Claude Code + Opus 4.5 45.3% +23.3pp
3 Codex CLI + GPT-5.2 44.7% —
4 Claude Code + Opus 4.6 44.5% —
5 Gemini CLI + Gemini 3 Pro 41.2% —
6 Claude Code + Sonnet 4.5 31.8% —
7 Claude Code + Haiku 4.5 27.7% —

출처: skillsbench.ai 공식 리더보드 (2026년 3월 기준)

이 표만 보면 “Gemini CLI 이기네” 끝이지만, 실전에서 더 중요한 건 에이전트별로 스킬을 활용하는 방식 차이다.

Claude Code: 스킬을 가장 잘 따른다

Claude Code는 curated 스킬이 붙었을 때 성능 개선폭이 가장 컸다. Opus 4.5 기준 +23.3 퍼센트 포인트는 전체 구성 중 최대다. 스킬 지시를 충실하게 따르는 경향이 강하고, 스킬에 명시된 절차를 건너뛰는 비율이 낮았다.

내 경험에서도 이건 체감된다. .claude/skills/ 폴더에 SKILL.md를 넣으면 Claude Code는 대부분의 경우 그 내용을 읽고 따른다. 문제는 스킬이 4개 이상 동시에 적용되면 우선순위를 혼동하기 시작하는 것인데, SkillsBench도 정확히 이 점을 확인해 주었다.

Codex CLI: 스킬을 무시하고 자기 방식대로 한다

Codex CLI + GPT-5.2 조합은 raw 성능 자체는 44.7%로 경쟁력이 있었다. 그런데 SkillsBench 분석에서 밝혀진 흥미로운 패턴이 있다. Codex가 제공된 스킬을 자주 무시하고 자체적으로 문제를 풀려 했다는 것이다. 스킬이 있어도 없는 것처럼 행동하는 빈도가 Claude Code 대비 높았다.

이건 실무에서도 비슷하다. Codex에 instructions.md를 넣어도 자기 판단으로 다른 경로를 택하는 경우가 Claude Code보다 잦다. 스킬 의존도가 낮다는 건 장단점이 있는데, 스킬 품질이 낮을 때는 오히려 Codex 방식이 나을 수 있지만, 검증된 스킬이 있을 때는 Claude Code 쪽이 안정적이다.

Gemini CLI: 균형형, 그러나 모델 크기 영향이 크다

Gemini CLI + Gemini 3 Flash가 1위를 차지한 건 흥미로운 결과다. Flash는 Pro보다 작은 모델인데, 스킬과의 조합에서는 더 높은 통과율을 보였다. 이건 작은 모델이 스킬의 지시를 더 충실하게 따르는 경향을 보여주는 데이터로 해석된다.

도메인별 격차: SW 엔지니어링은 왜 스킬 효과가 작은가

SkillsBench에서 가장 눈에 띄는 발견 중 하나는 도메인별 스킬 효과 격차다.

도메인 curated 스킬 효과 해석
헬스케어 +51.9pp 모델의 기본 지식이 약한 도메인 → 스킬 효과 극대
제조 +41.9pp 전문 절차/안전 규정 등 학습 데이터 부족 → 스킬 보충 효과 큼
사이버보안 높음 도메인 특화 프로토콜 기반
과학 중간 —
금융 중간 —
SW 엔지니어링 +4.5pp 모델이 이미 잘하는 도메인 → 추가 효과 적음

이 데이터가 실무에 주는 메시지는 명확하다.

  • 코딩 작업에 스킬을 넣어도 극적인 개선을 기대하기 어렵다. 모델이 이미 코딩을 잘하기 때문이다.
  • 그래서 코딩 스킬은 “팀별 컨벤션, 빌드 파이프라인, 보안 정책” 같은 조직 특화 지식에 집중해야 한다. 일반적인 코딩 지식은 모델이 이미 알고 있다.
  • 반대로 헬스케어, 제조, 금융 등 모델이 약한 도메인에서는 스킬 투자 ROI가 매우 높다.

제 볼트에서도 실제로 확인한 건 이와 일치한다. blog-writer 스킬처럼 도메인 특화된 절차(E-E-A-T 규칙, 채널별 톤앤매너, OREO 구조)를 명시한 스킬은 효과가 뚜렷했다. 반면 “코드를 깔끔하게 짜라”라는 식의 범용 SW 스킬은 있어도 없어도 차이가 거의 없었다.

스킬 개수의 함정: 2–3개가 최적, 4개 이상은 역효과

SkillsBench의 또 다른 핵심 발견은 스킬 개수와 성능의 관계다.

태스크당 curated 스킬 2–3개가 최적이다. 4개 이상을 동시에 제공하면 성능이 하락하거나 정체한다.

이유는 단순하다. 스킬이 많아지면 에이전트가 처리해야 할 맥락(context)이 늘어나고, 스킬 간 충돌 가능성이 생기며, 어떤 스킬을 우선할지 판단하는 데 토큰을 소모한다. SkillsBench 논문은 이것을 “인지 과부하(cognitive overhead)”라고 설명했다.

이건 내가 스킬 폴더를 운영하면서 체감한 것과 정확히 맞는다.

  • 스킬 40개를 만들었지만, 하나의 태스크에 동시 적용되는 스킬은 2–3개로 제한하는 게 결과가 좋았다.
  • blog-lead.md가 호출하는 스킬은 3개(blog-researcher, blog-writer, blog-reviewer)인데, 여기에 추가 스킬을 더 꽂으면 writer가 혼란을 일으킨 적이 있다.
  • 결국 “어떤 스킬을 이 태스크에 연결할 것인가” 자체가 설계 결정이다. 전부 다 올리면 오히려 손해다.

실전 원칙: 스킬은 태스크당 2개, 최대 3개까지. 4개째는 진짜 필요한지 증거가 있을 때만 추가하라.

작은 모델 + 좋은 스킬 > 큰 모델 + 스킬 없음

SkillsBench에서 가장 실용적인 발견이다.

Claude Haiku 4.5 + curated 스킬 = 통과율 27.7%
Claude Opus 4.5 + 스킬 없음 = 통과율 22.0%

작고 저렴한 모델에 검증된 스킬을 주면, 크고 비싼 모델을 스킬 없이 돌리는 것보다 낫다.

구성 통과율 비용 (상대적)
Opus 4.5 (스킬 없음) 22.0% 💰💰💰
Haiku 4.5 + curated 스킬 27.7% 💰
Opus 4.5 + curated 스킬 45.3% 💰💰💰

이 데이터가 말하는 건 두 가지다.

  1. 스킬 투자는 모델 업그레이드보다 가성비가 높을 수 있다. 비싼 모델로 바꾸기 전에 스킬부터 점검하라.
  2. 비용 제약이 있는 환경에서 스킬은 모델 격차를 메우는 레버다. 특히 반복적 태스크에서 이 효과가 크다.

실수 TOP 5: 스킬 검증에서 자주 놓치는 것들

3개월간 40개 스킬을 운영하면서 반복한 실수들이다. SkillsBench 데이터와 대조하면 패턴이 보인다.

1. 스킬을 만들고 “잘 되겠지” 하고 넘어간다

검증 없이 배포한 스킬 중 30%는 첫 실행에서 실패했다. SKILL.md의 절차가 모호하거나, 참조하는 경로가 틀렸거나, 에이전트가 해석할 수 없는 문장이 있었다. SkillsBench의 self-generated 스킬이 효과 0인 이유도 여기 있다 — 검증 루프가 없으면 스킬의 품질을 보장할 수 없다.

2. 범용 스킬에 에너지를 쏟는다

“코드를 깔끔하게 쓰라”, “에러 핸들링을 잘 하라” 같은 범용 지시는 모델이 이미 학습 데이터에서 알고 있다. SkillsBench에서 SW 엔지니어링 도메인의 스킬 효과가 +4.5pp에 불과한 것이 이를 증명한다. 스킬은 모델이 모르는 것, 즉 팀 컨벤션, 도메인 특화 절차, 조직 내부 규칙에 집중해야 한다.

3. 스킬을 한꺼번에 너무 많이 적용한다

“많을수록 좋겠지”라는 직관은 틀렸다. 2–3개가 최적이고 4개 이상은 역효과다. 이건 SkillsBench 데이터로도, 내 운영 경험으로도 확인된 사실이다.

4. 모델이 스킬을 따르는지 확인하지 않는다

특히 Codex CLI 계열에서 많이 발생한다. 스킬을 제공했는데 에이전트가 무시하고 자기 방식으로 풀었다면, 스킬이 있어도 없는 것이나 마찬가지다. 실행 로그에서 스킬 참조 여부를 확인하는 습관이 필요하다.

5. 한번 만든 스킬을 방치한다

도구 버전이 바뀌고, API가 변경되고, 팀 프로세스가 달라져도 스킬은 그대로 방치되는 경우가 많다. 3개월이 지나면 스킬 내용의 30% 정도는 구식이 된다. 정기적으로 스킬 리뷰 사이클을 돌려야 한다.

언제 스킬에 투자할 가치가 있고, 언제 아닌가

투자 가치가 높은 경우

  • 모델이 기본적으로 약한 도메인: 헬스케어, 제조, 금융 규정 등 → SkillsBench 기준 +40pp 이상 거능
  • 팀/조직 특화 프로세스: CI/CD 파이프라인, PR 리뷰 기준, 배포 절차 → 모델이 절대 학습 데이터에서 알 수 없는 것
  • 반복 빈도가 높은 태스크: 매일 실행하는 블로그 파이프라인, 데이터 처리 등 → 스킬 1번 검증에 비용 투입해도 회수됨
  • 비용 제약이 있는 환경: 작은 모델 + 스킬로 큰 모델 대체 가능

투자 가치가 낮은 경우

  • 모델이 이미 잘하는 범용 코딩 태스크: SkillsBench에서도 +4.5pp에 불과
  • 1회성 태스크: 스킬 만들고 검증하는 비용이 직접 하는 비용보다 큼
  • 스킬 내용이 빠르게 변하는 영역: 매번 업데이트 비용이 효과를 상쇄

실전 검증 체크리스트: 스킬 품질 확인 7단계

내가 실제로 쓰는 스킬 검증 루프다. SkillsBench의 curated 기준과 내 운영 경험을 결합했다.

스킬 배포 전(Pre-deploy)

  • [ ] 1. 태스크 매칭: 이 스킬이 적용될 태스크를 3개 이상 특정했는가?
  • [ ] 2. 스킬 개수 확인: 해당 태스크에 이미 적용 중인 스킬이 2개 이하인가? (3개째는 증거 기반 추가)
  • [ ] 3. 도메인 확인: 모델이 이미 잘하는 영역이 아닌가? (범용 코딩 지식이면 효과 미미)
  • [ ] 4. 드라이런: 실제 태스크 1건 이상에서 스킬 적용 전/후 결과를 비교했는가?

스킬 배포 후(Post-deploy)

  • [ ] 5. 로그 확인: 에이전트가 스킬의 핵심 절차를 실제로 참조했는가? (무시하면 스킬 재설계)
  • [ ] 6. 성공률 추적: 스킬 적용 후 태스크 성공률이 명확히 올라갔는가?
  • [ ] 7. 정기 리뷰: 최소 월 1회 스킬 내용이 최신 도구/프로세스와 맞는지 점검

FAQ

Q1. SkillsBench에서 말하는 “에이전트 스킬”이란? SKILL.md 같은 마크다운 형식으로 작성된 절차적 지식 패키지다. 에이전트에게 특정 도메인의 작업 방법, 규칙, 예시를 제공하는 구조화된 문서를 의미한다. Claude Code의 .claude/skills/, Codex의 instructions.md, Gemini CLI의 skill 파일 등이 모두 해당한다.

Q2. self-generated 스킬이 효과가 없다면, 스킬 자동 생성 도구는 의미 없는가? 현재 시점에서는 그렇다. SkillsBench 결과에 따르면, 모델이 자체적으로 작성한 스킬은 평균 효과가 0이거나 마이너스였다. 하지만 “자동 생성 후 사람이 검증·수정”하는 하이브리드 방식은 아직 별도로 테스트되지 않았으므로, 생성 보조 도구로서의 가능성은 열려 있다. 핵심은 최종 검증을 사람이 하느냐 여부다.

Q3. Gemini CLI가 1위인데, Claude Code 대신 Gemini로 갈아타야 하나? 리더보드 순위만큼 중요한 건 스킬 추종 안정성이다. Claude Code는 스킬을 가장 충실하게 따르는 패턴을 보였고, Codex는 제일 많이 무시했다. 팀에서 curated 스킬을 체계적으로 운영한다면 Claude Code가 안정적이고, raw 성능만 보면 Gemini CLI Flash가 현재 최고점이다. 쓰임새에 따라 다르다.

Q4. 스킬 2–3개 제한은 너무 적지 않나? 내 프로젝트에는 스킬이 10개 넘게 필요한데. 전체 프로젝트에 10개 이상의 스킬을 보유하는 건 정상이다. 제한은 태스크 단위다. 하나의 태스크를 실행할 때 동시에 활성화되는 스킬을 2–3개로 한정하는 것이다. 태스크 유형별로 서로 다른 스킬 세트를 매핑하면 총 스킬 개수는 무관하다.

Q5. SkillsBench는 코딩 전용 벤치마크인가? 아니다. 11개 도메인 중 SW 엔지니어링은 하나일 뿐이다. 헬스케어, 금융, 사이버보안, 제조, 로보틱스 등 비코딩 도메인도 포함하며, 오히려 비코딩 도메인에서 스킬 효과가 더 컸다.

참고 자료

관련 글

📮 TECHTAEK 뉴스레터를 구독하면 에이전트 운영·스킬 설계·AI 코딩 워크플로우 관련 새 글을 매주 받아볼 수 있습니다.