Junhyun
포스트

[Agent] 스킬이 실제로 보탠 몫 재기 — 그리고 제가 어제 쓴 글의 한계

NVIDIA가 제안한 Skill Lift를 원 논문으로 확인합니다. 스킬을 붙였을 때와 뺐을 때를 짝지어 재는 방법과, 정적으로 뜯어본 평가가 실제 기여를 예측하지 못했다는 결과를 정리합니다.

게시 업데이트
By Junhyun
14 분읽는 시간
[Agent] 스킬이 실제로 보탠 몫 재기 — 그리고 제가 어제 쓴 글의 한계

바로 앞 글에서 스킬 파일 하나를 뜯어봤습니다. 321바이트를 한 줄씩 읽고 “이래서 잘 만든 것” 이라고 썼습니다.

그 글을 올린 날 나온 논문이 이렇게 말합니다. 뜯어본 평가는 실제 기여를 거의 예측하지 못한다.

먼저 논문을 보고, 마지막에 제 글로 돌아오겠습니다.

원 논문

Evaluating Skills, Not Just Agents: Agentic Continuous Evaluation of Skills (arXiv 2608.20614 v1, 2026-08-20)

저자 12인이고, 오픈소스 구현이 NVIDIA/SkillEvaluator 로 공개돼 있습니다(별 389개, 2026-09-02 확인).

문제의식은 스킬 아홉 분류 글에서 짚었던 빈칸 그대로입니다. 에이전트 성능은 재는데 스킬 하나하나가 얼마나 보탰는지는 아무도 안 잽니다.

어떻게 재나 — 붙였다 뺐다 해봅니다

방법은 단순합니다. 같은 과제를 두 조건으로 돌립니다.

조건상태
with-skill대상 스킬을 쓸 수 있음
baseline대상 스킬만 빼고 나머지는 그대로

논문 표현으로는 “질문, 에이전트, 모델, 과제 자산, 보조 스킬, 채점 정책을 조건 사이에 고정한다” 입니다.

눈여겨볼 것은 미끼 스킬(decoy) 까지 그대로 둔다는 점입니다. 스킬 하나를 빼면 목록이 짧아지는데, 그 자체가 성능에 영향을 줄 수 있으니 자리를 채워둔 겁니다. 빼는 것 말고는 아무것도 안 달라지게 하려는 설계입니다.

규모는 145개 실제 스킬(사내 저장소 + 공개 카탈로그), 하네스 넷은 Claude Code · Codex · OpenCode · Terminus-2, 그중 채점된 짝 사례가 64개 중 58개 스킬에서 947건입니다.

대표 수치에 무엇이 섞여 있나

img_file여섯 항목을 같은 비중으로 평균한 값이 대표 수치입니다

종합 Skill Lift 는 여섯 항목을 각 1/6 로 평균한 값입니다.

  • security, skill_execution, skill_efficiency, behavior_check — 과정·안전
  • accuracy, goal_accuracy — 결과

그래서 대표 수치 0.2134 는 “얼마나 잘 해냈나”만의 값이 아닙니다. 결과 지표 둘만 평균한 값은 0.1799 로 더 낮습니다.

둘 다 논문에 적혀 있으니 숨긴 게 아닙니다. 다만 “스킬이 21% 올려준다” 로 옮겨지면 안 되는 값이고, 옮겨질 여지가 있는 값입니다.

전체 짝 사례 중 72.8% 에서 종합 lift 가 양수였습니다. 뒤집으면 네 건 중 하나 이상은 스킬을 붙이는 게 도움이 안 됐다는 뜻이기도 합니다.

저자들은 인과 주장을 하지 않습니다

이게 이 논문에서 가장 마음에 드는 부분입니다.

“lift” 라는 말은 인과처럼 들립니다. 그런데 짝 설계는 무작위 배정이 아닙니다. 같은 과제를 두 조건으로 돌린 것이지, 조건을 무작위로 나눈 게 아닙니다.

저자들이 먼저 선을 긋습니다.

짝 설계는 과제·하네스·모델·채점자·샌드박스·설정된 비대상 스킬을 고정하므로 단일 조건 점수보다는 강하다. 그렇다고 환경과 무관한 ‘내재적’ 기여를 식별하는 것은 아니다. 우리는 Skill Lift 를 선언된 작업공간과 기준선 정책 아래에서의 한계 기여로 해석한다.

“이 스킬은 좋다”가 아니라 “이 환경에서 이만큼 보탰다” 입니다. 환경이 바뀌면 값도 바뀝니다.

재현성에 남은 구멍

같은 조건이라도 LLM 은 돌릴 때마다 다르게 답합니다. 그래서 반복 실행이 중요한데, 여기가 절반만 채워져 있습니다.

201개 칸 중 88개만 짝 시행 파일이 둘이고, 나머지 113개는 하나입니다. 반복이 있는 88개에서 칸 내부 표준편차 중앙값은 0.0319 였습니다.

절반 이상이 한 번 돌린 결과라는 뜻입니다. 저자들이 “부분적”이라고 정직하게 적었지만, 개별 스킬의 값을 그대로 믿기는 어렵다는 뜻이기도 합니다.

그리고 이 글을 쓰게 만든 결과

한계 절에 이 문장이 있습니다.

스캔 점수와 실제 lift 사이의 거의 0에 가까운 상관(Tier 1 $\rho = -0.0181$, Tier 2 $\rho = -0.0266$)은, 음의 관계라는 증거라기보다 이 스캔 점수들에 쓸 만한 단조 런타임 대리 지표가 없다는 것과 부합한다.

스킬을 정적으로 검토해서 매긴 점수가, 실제로 얼마나 보탰는지를 예측하지 못했습니다. 상관이 낮은 게 아니라 사실상 없습니다.

게다가 두 스캔 방식끼리의 상관도 $\rho = 0.14$ 로 약합니다. 검토 방법을 바꾸면 점수도 갈립니다.

그래서 제 앞 글은 어떻게 되나

eli5 글에서 저는 321바이트 파일을 읽고 이런 것들을 짚었습니다 — description 이 본문보다 길다, 제약을 둘만 걸었다, 3분에 세 번 고쳤다.

그 글은 파일이 어떻게 쓰였는지에 대한 관찰입니다. 그 스킬이 실제로 좋은 설명을 내놓는지에 대한 근거는 아니고, 저도 그 글에 그렇게 적었습니다 — “출력 품질은 제가 재지 않았습니다.”

이 논문은 그 거리를 숫자로 보여줍니다. 잘 쓰인 것처럼 보이는 것과 실제로 보탬이 되는 것은 다른 축이고, 이 코퍼스에서는 둘이 거의 무관했습니다.

다만 여기에도 단서가 필요합니다. 논문이 검토한 코퍼스는 시스템 접근·배포·플랫폼·데이터 인프라 쪽에 치우쳐 있고, 저자들도 문제해결·개발도구·창작 계열 스킬에는 같은 분포를 주장하지 않는다고 적었습니다. eli5 는 정확히 그 빠진 쪽입니다.

그러니 이 결과가 “스킬 파일을 읽는 일이 무의미하다”는 뜻은 아닙니다. 읽어서 알 수 있는 것과 없는 것을 갈라야 한다는 뜻입니다.

읽어서 알 수 있는 것돌려봐야 아는 것
언제 발동하도록 적혔나실제로 발동하나
무엇을 지시했나그 지시가 결과를 바꾸나
구조가 일관된가붙였을 때 성능이 오르나

읽을 때 붙여야 할 단서

arXiv v1 이고 동료 심사 전입니다. 2026-08-20 등록본입니다.

무작위 배정이 아닙니다. 짝 설계는 단일 조건보다 강하지만 인과 추정이 아니고, 저자들도 그렇게 주장하지 않습니다.

절반 이상의 칸이 단일 실행입니다. 201개 중 113개입니다. 전체 평균은 몰라도 개별 스킬 값은 흔들릴 수 있습니다.

코퍼스가 치우쳐 있습니다. 저자들이 직접 밝힌 한계이고, 이 글이 제 앞 글에 대보는 대목에서도 그대로 적용됩니다.

저자 소속을 논문에서 확인하지 못했습니다. 오픈소스 구현이 NVIDIA 조직 계정으로 공개돼 있고 논문이 그것을 자기 구현이라 밝히지만, 초록 페이지에서 개별 저자 소속 표기는 확인하지 못했습니다. 그래서 이 글에서는 “NVIDIA 연구진”이라고 단정하지 않았습니다.

저는 SkillEvaluator 를 직접 돌려보지 않았습니다. 레포가 실재하고 별이 389개라는 것까지만 확인했습니다.

정리

Skill Lift 는 같은 과제를 스킬만 빼고 다시 돌려 그 차이를 재는 방법입니다. 목록이 짧아지는 효과까지 미끼 스킬로 상쇄합니다.

대표 수치 0.2134 는 여섯 항목의 평균이고, 결과 지표 둘만 보면 0.1799 입니다. 그리고 짝 사례의 72.8% 에서만 양수였습니다 — 나머지는 스킬이 도움이 안 됐습니다.

저자들은 이것을 인과가 아니라 “선언된 환경 아래의 한계 기여” 로 못박습니다.

가장 무거운 결과는 한계 절에 있습니다. 정적 검토 점수와 실제 기여의 상관이 사실상 0 이었습니다.

그래서 바로 앞 글에 단서를 하나 더 답니다. 스킬 파일을 읽어서 알 수 있는 것은 그것이 어떻게 쓰였는가까지입니다. 보탬이 되는지는 돌려봐야 압니다.

참고

Research
Agent skill evaluation benchmark LLM
이 기사는 저작권자의 CC BY 4.0 라이센스를 따릅니다.