▲

SkillsBench: 다양한 작업에서 에이전트 스킬의 성능을 평가하는 벤치마크

 (arxiv.org)
1P by GN⁺ 5시간전 | ★ favorite | 댓글 1개
  • SkillsBench는 대형 언어 모델(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 에이전트의 실제 작업 수행력에 미치는 영향을 정량적으로 입증함
  • 결과는 스킬 설계 품질과 도메인 적합성이 성능 향상에 결정적임을 보여줌
  • 향후 연구에서 스킬의 구조적 설계 원칙과 자동 생성 한계를 규명하는 기반 자료로 활용 가능함
▲
GN⁺ 5시간전  [-]
Hacker News 의견들

  • “Self-Generated Skills”라는 개념이 흥미롭지만, 사람들이 생각하는 ‘LLM이 스스로 기술을 학습하는 과정’ 과는 다르다는 점을 짚고 싶음
    연구에서는 단순히 문제를 풀기 전에 관련 절차적 지식을 생성하도록 프롬프트를 주는 것뿐이라, 실제 ‘경험에서 배운 기술’과는 거리가 있음
    언론이 이 차이를 잘 구분해 보도하길 바람

    • 실험의 ‘task’ 범위가 너무 제한적임. 단일 마크다운 파일과 검증기만 사용하고, 기존 코드베이스나 리팩터링 같은 현실적 문제는 다루지 않음
      LLM이 스스로 기술을 생성한다고 해도 탐색이나 학습이 불가능한 구조라, 결국 자기 맥락을 되풀이하는 셈임
      이런 결과를 일반화하는 건 오해의 소지가 큼
    • ‘스킬’의 본래 목적은 짧은 how-to 메모처럼 필요한 순간에 불러와 활용하는 것임
      이미 모델 내부에 있는 지식이라면 굳이 문서로 쓸 필요가 없고, 정말 드러나기 어려운 정보일 때만 의미가 있음
    • 나도 LLM이 시도 후 학습한 교훈을 기술로 정리하는 방식에 관심이 있음
      시도 전에 기술을 만드는 건 현실과 동떨어진 접근임
    • 나는 ‘role play session’을 통해 유용한 스킬을 만들었음
      에이전트에게 질문하게 하고 문제 해결 과정을 거친 뒤, 그 결과를 증거 기반의 압축된 스킬로 정리하는 방식이 효과적이었음
    • thisistheway.to/ai에 정리했듯, 우리는 에이전트의 실패를 학습 기회로 삼음
      ① 실패 포착 → ② 원인 진단 → ③ 개선 도구 선택 → ④ 버전 관리된 산출물로 기록 → ⑤ 필요 시 게이트로 승격
      이런 루프를 모든 에이전트에 기본 지침으로 포함시킴

  • 나는 Claude용 skill-creator를 따로 만들어 사용 중임
    Claude가 이미 알고 있는 정보를 다시 기술로 쓰는 걸 방지하기 위해, 문서에는 반드시
    ① 훈련 데이터 밖의 정보, ② 현재 세션에만 유효한 맥락, ③ 미래 Claude의 행동을 정렬시키는 정보만 포함하도록 함
    전체 내용은 GitHub 링크에 있음

    • LLM이 자신이 무엇을 알고 모르는지 성찰하는 능력은 약하지만, 이 접근 자체는 매우 유용하다고 생각함
    • 다만 Claude가 ‘가장 좋은 지식’을 고를 수 있다고 가정하는 건 위험함
      인터넷 학습 데이터는 품질이 들쭉날쭉하므로, 모델이 ‘전문가 수준의 선택’을 할 거라 기대하기 어려움
    • 이 스킬 문서가 마치 좋은 블로그 글처럼 읽힌다는 점이 마음에 듦
      비자명한 통찰을 담은 글이 곧 좋은 스킬이라는 기준이 될 수 있음
    • 이런 실무적 통찰은 연구자들이 논문으로 내기 전에 arXiv에 먼저 공개해도 좋을 듯함

  • 연구 결과 중 가장 흥미로운 건 자체 생성 스킬은 성능을 떨어뜨리고(-1.3pp) , 큐레이션된 스킬은 크게 향상(+16.2pp) 시킨다는 점임
    LLM은 절차적 지식의 소비자로는 뛰어나지만 생산자로는 약하다는 가설과 일치함
    특히 소프트웨어 분야보다 헬스케어에서 효과가 훨씬 큰데, 이는 SWE 데이터가 이미 풍부하기 때문일 가능성이 큼

    • 나도 이 차이에 주목했음. 새롭거나 희귀한 라이브러리를 다룰 때 스킬의 효과가 극적으로 커짐
      예를 들어 Adobe React Spectrum UI는 스킬 없이 쓰면 엉망이지만, 잘 만든 스킬을 쓰면 완전히 달라짐

  • 단순히 모델에게 “스킬을 만들어라”라고 하는 건 의미가 없음
    새로운 정보나 외부 자료로 지식을 확장하지 않으면, 결국 자기 출력을 다시 입력하는 순환에 불과함
    나는 스킬 생성 시 자동으로 연구를 수행하고, 최신 정보나 워크플로에 맞게 정제하도록 하는 skill-creator를 사용함

    • 연구에서는 에이전트에게 자율 탐색이나 자료 접근 권한을 주지 않았음
      이런 조건에서 스킬을 만드는 건 무의미함
    • 실제로는 스킬을 현장에서 사용한 뒤 피드백으로 자동 개선하도록 하면 훨씬 유용함

  • LLM을 여러 계층으로 자동화할수록 각 단계의 품질이 떨어지는 경향이 있음
    아이디어와 구현 계획을 사람이 잡고 LLM이 코딩만 하면 괜찮지만, 계획까지 맡기면 급격히 품질 저하가 일어남

    • 이런 현상을 나는 ‘semantic collapse’ 라 부름
      반복 요약이나 재생산을 거듭하면 결국 의미가 붕괴됨
      일정 시점마다 신선한 인간 입력이 필요함
    • 하지만 맥락 관리가 잘 되면 반대의 경우도 있음
      나는 대규모 코드베이스에서 LLM에게 먼저 탐색 보고서를 쓰게 하고, 새 세션에서 그걸 참고해 작업함
      토큰은 더 들지만 중요한 세부사항을 놓치지 않음
    • Google의 Aletheia는 이런 파이프라인 구조에서도 오히려 성능이 향상됨
      결국 핵심은 모델에 충분한 세계 지식을 공급하느냐임
    • 이 과정을 ‘전화 게임’ 에 비유하고 싶음
      자연어는 본질적으로 불안정해서, 반복 전달될수록 왜곡이 커짐
      우리가 이렇게 잘 소통하는 것 자체가 놀라운 일임
    • 다만 피드백 루프가 있다면 얘기가 달라짐
      open loop 구조에서는 정확도가 떨어지지만, 각 단계가 스스로 조정할 수 있다면 훨씬 안정적임

  • 나는 agentic-ready 데이터 웨어하우스( 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 가이드라인에 어긋남
    원제목을 유지하고, 의견은 댓글로 표현하는 게 공정함

    • 하지만 너무 모호한 제목 아래 핵심 결과가 묻히는 것도 문제임
      명확한 제목이 커뮤니티에 더 큰 통찰을 줄 수 있다고 생각함
      의도는 클릭 유도가 아니라 핵심 발견을 강조하는 것이었음
답변달기