왜 나는 SkillsBench에 행동하지 않을까

Source: Dev.to

개요

SkillsBench(paper, Feb 2026)를 Theo를 보면서 우연히 발견했고, 정말 흥미로웠습니다. 이 논문은 두 가지 핵심 질문을 제시합니다:

1. 정제된 절차 문서(“Skills”)가 실제로 코딩 에이전트에 도움이 될까요?
2. 어떤 코딩 에이전트가 이를 가장 잘 활용할까요?

핵심 수치 – 정제된 Skills에서 +16.2 pp – 는 즉시 실행 가능한 느낌을 주었습니다.

First Impressions

Then I started pulling at the methodology, and things unraveled.

• Scope – 84 tasks, 11 domains, 7 coding agents, 7,308 trajectories.
• Conditions – each task is evaluated under three settings:
  • No Skills
  • Curated (expert‑written) Skills
  • Self‑generated Skills
• Skill package – every task ships with a fixed Skill package (markdown instructions, sometimes with scripts or templates) that is provided to the agent alongside the task.

리더보드 결과

모든 벤치마크에서 핵심 결과는 리더보드입니다.

Finding 2 (§4.1.1) – 최고의 순수 성능

이는 정당한 결과이며, Flash가 Opus 4.5/4.6을 앞선 것은 다소 놀라운 일입니다.

리더보드가 실제로 측정하는 것

리더보드는 어떤 에이전트가 가장 좋은 성과를 냈는지를 보여주지만, Skills 메커니즘이 어떤 차이를 만들었는지, 혹은 동일한 결과를 콘텐츠를 프롬프트에 직접 넣음으로써 얻을 수 있었는지는 알려주지 않습니다.

누락된 실험

동일한 Skill 콘텐츠를 프롬프트에 직접 삽입하는 경우(베이스라인)와 Harness가 자체 탐색 메커니즘을 통해 Skills를 로드하도록 하는 경우를 비교한다.

이 실험은 논문에 포함되지 않았으며, **“SkillsBench”**라는 벤치마크를 정당화할 수 있는 바로 그 실험입니다.

디자인‑지향적 발견

논문의 디자인‑지향적 발견 두 가지는 실용적으로 들립니다:

1. Skill 수 – 2–3개의 Skill이 최적(+18.6 pp); 4개 이상은 수익 감소(+5.9 pp)를 보입니다. (Finding 5, §4.2.1)
2. Skill 길이 – 중간 길이 Skill이 포괄적인 Skill보다 성능이 좋습니다 — 상세(+18.8 pp)와 간결(+17.1 pp)이 포괄적(–2.9 pp)보다 우수합니다. (Finding 6, §4.2.2)

왜 이러한 발견이 문제인가

• 각 작업은 고정된 Skill 패키지와 함께 제공되므로 “Skill 수”와 “Skill 복잡도”는 작업의 속성이며, 독립 변수는 아닙니다.
• 따라서 실험은 Skill 수의 효과와 어떤 작업을 해결하고 있는지의 효과를 구분할 수 없습니다.
• 논문은 사후에 Skill 수에 따라 층화하고 인과적 언어(“최적”, “수익 감소”)를 사용하지만, 설계 자체가 그런 추론을 뒷받침하지 못합니다.

복잡도에도 동일한 문제가 적용됩니다: –2.9 pp를 보이는 N = 140 “포괄적” 버킷은 단순히 더 어려운 작업들만 포함했을 수도 있습니다. 작업 난이도를 통제하지 않거나, 더 나아가 작업 내에서 Skill 수/복잡도를 변동시키지 않는 한, 이러한 결과는 설계 지침으로 포장된 단순한 상관관계 관찰에 불과합니다.

Source: …

도메인 세부 분석 (표 4)

이 수치는 “모델 사전학습에서 지식이 과소대표되는 도메인이 Skills(발견 4, §4.1.3)에서 가장 큰 혜택을 받는다는 논문의 주장을 뒷받침합니다.

도메인 분석상의 문제점

• 헬스케어 – 2개 작업만 포함.
• 제조 – 3개 작업만 포함.

단일 이상치 작업—그리고 몇몇 개별 작업이 70–85 pp 정도 변동—이 전체 도메인의 집계에 큰 영향을 미칠 수 있습니다. 이렇게 작은 표본(N)으로는 도메인 효과를 측정하는 것이 아니라 몇 개 작업을 측정하는 것이 됩니다. 논문은 도메인 수준에서 신뢰구간 없이 이러한 수치를 보고하고 표본 크기 제한을 표시하지 않았습니다.

반면 소프트웨어 엔지니어링(N = 16)은 훨씬 더 신뢰할 수 있는 추정치를 보여주지만, 그 효과는 덜 흥미롭습니다.

결과를 프롬프트 결과로 재구성

Since Skills are lazily loaded prompt pieces, replace “Skills” with “prompt” in the remaining findings:

These re‑framings are not surprising; the prompting literature has already established both points.

자체 생성된 스킬

Finding 3 – 자체 생성된 스킬은 이점이 없다는 점은 메타‑프롬프트(모델이 스스로 프롬프트를 생성하도록 하는)가 일부 상황에서는 작동한다는 점 때문에 약간 더 흥미롭습니다.

가능한 설명:

• 모델이 도메인 지식이 부족한 작업에서는 지식이 없기 때문에 효과적인 스킬을 작성할 수 없습니다.
• 모델이 이미 도메인 지식을 보유하고 있는 작업에서는 스킬이 가져오는 한계 기여도가 최소에 불과합니다.

어느 쪽이든, 모델이 자체 스킬을 작성해도 성능이 향상되지 않으며, 이는 “모델이 자체 컨텍스트를 제공해도 성능이 향상되지 않는다”는 의미와 같습니다 — 역시 놀라운 일은 아닙니다.

무엇이 부족한가 & 제안된 실험

논문은 올바른 질문을 제기하지만, 이를 답할 실험이 아직 부족합니다. 아래는 필요한 조사 항목을 정리한 목록입니다.

1. 메커니즘 분리

• 목표: Skills 메커니즘이 중요한지, 아니면 Skills 내용이 도움이 되는지만을 확인합니다.
• 실험: 동일한 Skill 내용을 프롬프트에 직접 삽입(베이스라인)하는 경우와, 하네스가 자체 탐색 메커니즘을 통해 로드하도록 하는 경우를 비교합니다.
  • 네이티브 로딩이 더 좋다면 → Skills 아키텍처가 실제로 작동하고 있는 것입니다.
  • 결과가 동등하다면 → Skills는 프롬프트 내용의 포장 형식에 불과합니다.

2. 내용 분리

• 목표: 절차적 구조가 성능 향상의 핵심 요인인지 테스트합니다.
• 실험: 동일한 토큰 수의 주제와 관련된 비절차적 텍스트(예: API 문서, 레퍼런스 자료)를 삽입하고 성능을 비교합니다.

3. 작업별 Skills 변형

• 목표: Skill 수/복잡도와 작업 난이도를 분리합니다.
• 설계: 동일한 작업에 대해, 개수나 길이만 다르고 기본 작업은 동일한 여러 Skill 패키지를 만듭니다.

4. 도메인 수준 견고성

• 목표: 신뢰할 수 있는 도메인 수준 추정치를 얻습니다.
• 설계: 도메인당 작업 수를 늘립니다(특히 헬스케어와 제조처럼 데이터가 적은 도메인). 그리고 신뢰 구간을 보고합니다.

5. 베이스라인 프롬프트 품질

• 목표: 관찰된 향상이 단순히 더 나은 프롬프트 때문이 아닌지 확인합니다.
• 설계: 동일한 길이와 토큰 예산을 가진 전문가가 만든 프롬프트와 큐레이션된 Skills를 비교합니다.

Take‑away

• SkillsBench는 코딩 에이전트를 위한 선별된 절차 문서의 유용성에 대해 중요한 질문을 제기합니다.
• 현재 방법론은 내용과 메커니즘을 혼동하고, 상관관계 관찰을 인과 언어와 뒤섞어 사용하고 있습니다.
• Skills 로딩 메커니즘을 일반 프롬프트 베이스라인과 직접 비교하는 등, 엄격하고 통제된 실험이 필요합니다. 이러한 실험 없이는 “Skills”가 별개의 벤치마크 구성 요소로서 고유한 가치를 제공한다고 주장하기 어렵습니다.

Skill‑Based Agent Design에 대한 권장 사항

1. Skill 설계 결과와 Task 정체성 분리

• 통제된 실험 수행:
  • 동일한 작업을 여러 번 실행하되, 사용 가능한 Skill 수를 매번 다르게 설정합니다.
  • 각 변형에 대한 성능 차이를 측정합니다.
• Skill 복잡도 다양화:
  • 동일한 작업에 대해 컴팩트한 Skill 세트와 포괄적인 Skill 세트를 제공합니다.
  • 복잡성이 결과에 어떻게 영향을 미치는지 관찰합니다.
• 목표: 상관관계 관찰을 구체적인 설계 지침으로 전환합니다.

2. 고정된 Skill 라이브러리로 테스트

• 현재 설정 제한: 각 작업에 손수 선택된 Skill 패키지를 제공하여 완벽한 매치를 보장합니다.
• 제안된 실험:
  • 정적 라이브러리(약 20–30개의 Skill)를 만들어 모든 작업에 동일하게 유지합니다.
  • 에이전트가 스스로 적절한 Skill을 발견하고 적용하도록 합니다.
• 중요한 이유:
  • 이는 Skill 선택(더 어렵고 현실적인 문제)을 평가하는 것이며, 단순히 Skill 사용을 평가하는 것이 아닙니다.

3. 실용적인 권장 사항

• 논문의 결과를 그대로 적용하지 마세요.
• 오늘날 에이전트를 위해 Skill에 투자하고 있다면, 연구 결론에 의존하기보다 자신의 시행착오를 기반으로 투자를 조정하십시오.