# SkillsBench: 다양한 작업에서 에이전트 스킬의 성능을 평가하는 벤치마크 > Clean Markdown view of GeekNews topic #26759. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=26759](https://news.hada.io/topic?id=26759) - GeekNews Markdown: [https://news.hada.io/topic/26759.md](https://news.hada.io/topic/26759.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2026-02-18T03:34:29+09:00 - Updated: 2026-02-18T03:34:29+09:00 - Original source: [arxiv.org](https://arxiv.org/abs/2602.12670) - Points: 3 - Comments: 1 ## Topic Body - 대형 언어 모델(LLM) 기반 에이전트의 **스킬(Agent Skills)** 효과를 정량적으로 평가하기 위한 첫 벤치마크로, 11개 도메인 84개 작업을 포함함 - 각 작업은 **스킬 미적용**, **큐레이션된 스킬 적용**, **자체 생성 스킬 적용**의 세 조건에서 평가되며, 총 **7,308개의 실행 경로**가 수집됨 - 큐레이션된 스킬은 평균 **+16.2%p의 성능 향상**을 보였으나, 도메인별 편차가 크고 일부 작업(84개 중 16개)은 오히려 성능이 하락함 - **자체 생성 스킬(Self-generated Skills)** 은 평균적으로 효과가 없었으며, 모델이 스스로 절차적 지식을 안정적으로 생성하지 못함을 보여줌 - **작고 집중된 스킬 모듈(2–3개 구성)** 이 포괄적 문서형 스킬보다 효율적이며, 스킬을 활용한 소형 모델이 스킬 없는 대형 모델과 유사한 성능을 달성함 --- ### SKILLSBENCH 개요 - SKILLSBENCH는 **LLM 에이전트의 스킬 보강 효과**를 평가하기 위한 벤치마크로, Harbor 프레임워크 기반에서 구축됨 - 각 작업은 컨테이너 환경, 결정적 검증기, 참조 해답(oracle)을 포함 - 스킬 적용 여부에 따라 동일 작업을 반복 수행해 **스킬의 순수 효과**를 측정 - 기존 벤치마크가 모델의 기본 능력만 평가한 것과 달리, SKILLSBENCH는 **스킬이 성능에 미치는 영향**을 직접 측정함 ### 스킬(Agent Skills)의 정의와 구성 - 스킬은 **절차적 지식(procedural knowledge)** 을 담은 구조화된 패키지로, 모델 수정 없이 추론 시점에 에이전트 행동을 확장함 - 구성 요소: `SKILL.md`(작업 접근 절차), 실행 가능한 스크립트, 코드 템플릿, 예제 등 - 스킬은 다음 네 가지 기준을 충족해야 함 - 절차적 내용 포함 - 단일 사례가 아닌 **작업 클래스 단위 적용** - 구조화된 구성요소 포함 - 파일 시스템 기반으로 **이식성 확보** - 시스템 프롬프트, few-shot 예시, RAG 검색, 도구 문서는 스킬로 간주되지 않음 ### 작업(Task) 구성 및 데이터셋 구축 - 각 작업은 **지시문, 환경, 해답, 검증기**의 네 요소로 구성 - 환경은 Docker 컨테이너로 격리되어 재현성 보장 - 검증기는 결정적 테스트 스크립트로 통과/실패를 자동 판정 - 105명의 기여자가 322개 후보 작업을 제출, 자동 검증과 인간 검토를 거쳐 **최종 84개 작업**을 선정 - 기여자는 다음 요건을 충족해야 함 - **인간 작성 지시문** (LLM 생성 금지) - 스킬은 특정 작업 해답이 아닌 **절차적 지침** 제공 - 모든 검증은 **결정적(assertion 기반)** 방식으로 수행 - 자동 구조 검증, 오라클 실행, AI 생성 탐지, 누출 감사를 통과해야 함 - 누출 방지를 위해 스킬 내에 **작업별 파일명, 상수, 테스트 참조** 등이 포함되면 거부됨 ### 벤치마크 구성 및 난이도 분류 - SKILLSBENCH는 **11개 도메인(소프트웨어, 헬스케어, 금융, 로보틱스 등)** 의 84개 작업으로 구성 - 난이도는 인간 수행 시간 기준으로 세 단계로 구분 - Core(60분 미만) 17개 - Extended(1–4시간) 43개 - Extreme(4시간 초과) 26개 ### 실험 설정 - 세 가지 상용 에이전트 하니스 평가: **Claude Code**, **Gemini CLI**, **Codex CLI** - 일곱 개 모델 사용: GPT-5.2, Claude Opus 4.5/4.6, Claude Sonnet 4.5, Claude Haiku 4.5, Gemini 3 Pro, Gemini 3 Flash - 세 가지 조건에서 평가 - **No Skills**: 스킬 미적용 - **With Skills**: 큐레이션된 스킬 적용 - **Self-Generated Skills**: 모델이 직접 스킬 생성 후 적용 - 총 **7,308개의 유효 실행 경로(trajectories)** 수집 ### 평가 지표 - **통과율(pass rate)** 을 기본 지표로 사용 - **정규화 이득(normalized gain)** 을 추가 계산해 절대 향상과 비율 향상을 함께 분석 - 각 작업은 5회 반복 후 평균 점수를 산출 ### 주요 결과 - **큐레이션된 스킬**은 평균 **+16.2%p 향상**, 구성별로 +13.6~+23.3%p 범위 - 도메인별 편차가 크며, 헬스케어(+51.9%p)에서 가장 큰 향상, 소프트웨어 엔지니어링(+4.5%p)에서 가장 낮음 - 84개 중 16개 작업에서는 오히려 성능 하락 - **자체 생성 스킬**은 평균적으로 효과가 없거나 부정적 영향 - 모델이 스스로 절차적 지식을 안정적으로 생성하지 못함 - **집중형 스킬(2~3 모듈)** 이 포괄적 문서형보다 높은 효율을 보임 - **소형 모델 + 스킬 조합**이 스킬 없는 대형 모델과 유사한 성능을 달성 ### 결론 - SKILLSBENCH는 **스킬 중심 평가 체계**를 제공하며, 스킬이 LLM 에이전트의 실제 작업 수행력에 미치는 영향을 정량적으로 입증함 - 결과는 **스킬 설계 품질과 도메인 적합성**이 성능 향상에 결정적임을 보여줌 - 향후 연구에서 스킬의 **구조적 설계 원칙과 자동 생성 한계**를 규명하는 기반 자료로 활용 가능함 ## Comments ### Comment 51301 - Author: neo - Created: 2026-02-18T03:34:29+09:00 - Points: 1 ###### [Hacker News 의견들](https://news.ycombinator.com/item?id=47040430) - “Self-Generated Skills”라는 개념이 흥미롭지만, 사람들이 생각하는 **‘LLM이 스스로 기술을 학습하는 과정’** 과는 다르다는 점을 짚고 싶음 연구에서는 단순히 문제를 풀기 전에 관련 절차적 지식을 생성하도록 프롬프트를 주는 것뿐이라, 실제 ‘경험에서 배운 기술’과는 거리가 있음 언론이 이 차이를 잘 구분해 보도하길 바람 - 실험의 **‘task’ 범위가 너무 제한적**임. 단일 마크다운 파일과 검증기만 사용하고, 기존 코드베이스나 리팩터링 같은 현실적 문제는 다루지 않음 LLM이 스스로 기술을 생성한다고 해도 탐색이나 학습이 불가능한 구조라, 결국 자기 맥락을 되풀이하는 셈임 이런 결과를 일반화하는 건 오해의 소지가 큼 - ‘스킬’의 본래 목적은 짧은 **how-to 메모**처럼 필요한 순간에 불러와 활용하는 것임 이미 모델 내부에 있는 지식이라면 굳이 문서로 쓸 필요가 없고, 정말 드러나기 어려운 정보일 때만 의미가 있음 - 나도 LLM이 **시도 후 학습한 교훈**을 기술로 정리하는 방식에 관심이 있음 시도 전에 기술을 만드는 건 현실과 동떨어진 접근임 - 나는 ‘role play session’을 통해 유용한 스킬을 만들었음 에이전트에게 질문하게 하고 문제 해결 과정을 거친 뒤, 그 결과를 **증거 기반의 압축된 스킬**로 정리하는 방식이 효과적이었음 - [thisistheway.to/ai](https://thisistheway.to/ai)에 정리했듯, 우리는 에이전트의 실패를 학습 기회로 삼음 ① 실패 포착 → ② 원인 진단 → ③ 개선 도구 선택 → ④ **버전 관리된 산출물로 기록** → ⑤ 필요 시 게이트로 승격 이런 루프를 모든 에이전트에 기본 지침으로 포함시킴 - 나는 **Claude용 skill-creator**를 따로 만들어 사용 중임 Claude가 이미 알고 있는 정보를 다시 기술로 쓰는 걸 방지하기 위해, 문서에는 반드시 ① 훈련 데이터 밖의 정보, ② 현재 세션에만 유효한 맥락, ③ 미래 Claude의 행동을 정렬시키는 정보만 포함하도록 함 전체 내용은 [GitHub 링크](https://github.com/j-r-beckett/SpeedReader/blob/main/.claude/skills/skill-creator/SKILL.md)에 있음 - LLM이 자신이 **무엇을 알고 모르는지 성찰**하는 능력은 약하지만, 이 접근 자체는 매우 유용하다고 생각함 - 다만 Claude가 ‘가장 좋은 지식’을 고를 수 있다고 가정하는 건 위험함 인터넷 학습 데이터는 품질이 들쭉날쭉하므로, 모델이 ‘전문가 수준의 선택’을 할 거라 기대하기 어려움 - 이 스킬 문서가 마치 **좋은 블로그 글처럼 읽힌다**는 점이 마음에 듦 비자명한 통찰을 담은 글이 곧 좋은 스킬이라는 기준이 될 수 있음 - 이런 실무적 통찰은 연구자들이 논문으로 내기 전에 **arXiv에 먼저 공개**해도 좋을 듯함 - 연구 결과 중 가장 흥미로운 건 **자체 생성 스킬은 성능을 떨어뜨리고(-1.3pp)** , **큐레이션된 스킬은 크게 향상(+16.2pp)** 시킨다는 점임 LLM은 절차적 지식의 **소비자**로는 뛰어나지만 **생산자**로는 약하다는 가설과 일치함 특히 소프트웨어 분야보다 헬스케어에서 효과가 훨씬 큰데, 이는 SWE 데이터가 이미 풍부하기 때문일 가능성이 큼 - 나도 이 차이에 주목했음. **새롭거나 희귀한 라이브러리**를 다룰 때 스킬의 효과가 극적으로 커짐 예를 들어 Adobe React Spectrum UI는 스킬 없이 쓰면 엉망이지만, 잘 만든 스킬을 쓰면 완전히 달라짐 - 단순히 모델에게 “스킬을 만들어라”라고 하는 건 의미가 없음 **새로운 정보나 외부 자료**로 지식을 확장하지 않으면, 결국 자기 출력을 다시 입력하는 순환에 불과함 나는 스킬 생성 시 자동으로 연구를 수행하고, 최신 정보나 워크플로에 맞게 정제하도록 하는 [skill-creator](https://github.com/sammcj/agentic-coding/blob/main/Skills/skill-creator/SKILL.md)를 사용함 - 연구에서는 에이전트에게 **자율 탐색이나 자료 접근 권한**을 주지 않았음 이런 조건에서 스킬을 만드는 건 무의미함 - 실제로는 스킬을 현장에서 사용한 뒤 **피드백으로 자동 개선**하도록 하면 훨씬 유용함 - LLM을 여러 계층으로 자동화할수록 각 단계의 품질이 떨어지는 경향이 있음 아이디어와 구현 계획을 사람이 잡고 LLM이 코딩만 하면 괜찮지만, 계획까지 맡기면 급격히 **품질 저하**가 일어남 - 이런 현상을 나는 **‘semantic collapse’** 라 부름 반복 요약이나 재생산을 거듭하면 결국 의미가 붕괴됨 일정 시점마다 **신선한 인간 입력**이 필요함 - 하지만 맥락 관리가 잘 되면 반대의 경우도 있음 나는 대규모 코드베이스에서 LLM에게 먼저 탐색 보고서를 쓰게 하고, 새 세션에서 그걸 참고해 작업함 토큰은 더 들지만 중요한 세부사항을 놓치지 않음 - Google의 **Aletheia**는 이런 파이프라인 구조에서도 오히려 성능이 향상됨 결국 핵심은 모델에 충분한 **세계 지식**을 공급하느냐임 - 이 과정을 **‘전화 게임’** 에 비유하고 싶음 자연어는 본질적으로 불안정해서, 반복 전달될수록 왜곡이 커짐 우리가 이렇게 잘 소통하는 것 자체가 놀라운 일임 - 다만 피드백 루프가 있다면 얘기가 달라짐 **open loop** 구조에서는 정확도가 떨어지지만, 각 단계가 스스로 조정할 수 있다면 훨씬 안정적임 - 나는 **agentic-ready 데이터 웨어하우스**( [GitHub.com/mathisdrn/orca](https://github.com/mathisdrn/orca) )를 만들고 있음 처음엔 스킬을 벤치마크로 최적화하려 했지만, **DsPy**와 **GEPA**처럼 모델 언어 자체를 평가자이자 빌더로 쓰는 접근이 더 효율적임 Anthropic이나 OpenAI의 skill-creator도 이런 **자기 최적화 구조**를 갖고 있는지 궁금함 - 이 연구가 놀랍지도, 실무적으로도 큰 의미가 없다고 생각함 실제로는 모델이 **자기 잠재 지식만으로 스킬을 만드는 경우가 거의 없음** 연구는 그런 제한된 조건에서 실험했기 때문에 결과가 당연함 더 흥미로운 건 모델이 인간과 인터뷰하거나, **깊은 리서치 후 스킬을 생성**하는 방식일 것임 - 이런 지적에 전적으로 동의함. 오히려 이런 논문이 나왔다는 사실이 더 놀라움 - 현대 과학은 **‘놀랍지 않은 결과’도 출판**을 장려함 게다가 이런 연구가 “모델에게 아무 맥락 없이 베스트 프랙티스 문서를 쓰게 하는 관리자들”을 막는 데 도움이 됨 - 과거에는 ‘계획 후 실행’ 같은 접근이 실제로 효과적이었던 사례도 있었음 이번 연구는 그런 맥락을 고려하지 않음 - 결국 이건 CLAUDE.md나 AGENTS.md를 모델이 스스로 썼다고 해서 무의미하다고 말하는 것과 같음 - 요즘 너무 많은 똑똑한 사람들이 이런 **AI 논쟁에 에너지를 낭비**하고 있는 느낌임 예전엔 그냥 유용한 소프트웨어를 만들었는데, 이제는 매주 새로 나오는 AI 주제에 매몰되어 있음 Web3나 JS 프레임워크보다도 더 강력한 **nerd-sniping 효과**가 있음 이번 기사도 사실상 예상 가능한 결과를 확인했을 뿐임 - 지금은 **분산된 진화 과정**이 진행 중이라 중복 시도가 많음 하지만 곧 새 모델이 나와 이런 논의가 무의미해질 가능성도 큼 많은 팀이 ‘스킬 전략’으로 전환하라는 지시를 받지만, 그 사이 새 모델이 더 잘 만들어버림 결국 다들 **불안정한 생존 구조** 속에서 방향을 찾지 못하고 있음 - 나도 **자체 생성 문서의 품질 저하**를 자주 목격했음 LLM이 코드에서 ‘베스트 프랙티스’를 추출하면, 종종 잘못된 패턴이 그대로 문서화됨 예를 들어 C# 코드에서 `ConfigureAwait(false)`나 `Task.Run`을 오용한 사례가 있었음 이런 문제를 해결하기 위해, 우리는 **큐레이션된 지식 시스템**을 구축 중임 Markdown 기반의 **agentic coding**이 다음 세대의 추상화 계층이 될 것이라 믿음 - 다만 LLM 계층은 이전 언어들과 달리 **비결정적**이라는 점이 다름 이 특성이 전체 동작 방식에 어떤 영향을 주는지 아직 명확하지 않음 - 제출된 제목이 “Self-generated agent skills are useless”였는데, 이는 [HN 가이드라인](https://news.ycombinator.com/newsguidelines.html)에 어긋남 원제목을 유지하고, 의견은 댓글로 표현하는 게 공정함 - 하지만 너무 **모호한 제목 아래 핵심 결과가 묻히는** 것도 문제임 명확한 제목이 커뮤니티에 더 큰 통찰을 줄 수 있다고 생각함 의도는 클릭 유도가 아니라 **핵심 발견을 강조**하는 것이었음