기술(skill)을 작성하다 보면, 나도 모르게 '좋은 기술(skill)이 늘어나면 에이전트(agent)는 강해질 것'이라고 생각하게 된다. SKILL.md에 도메인 절차를 작성한다. 태스크 완료율이 올라간다. 그러니 더 많이 작성한다. 더 많이 추가한다.

하지만 그 '추가해 나가는' 방향에는 그동안 별로 논의되지 않았던 함정이 있다. 이번에 읽은 논문은 그 부분을 정면으로 측정하고 있다. 결론부터 말하자면 ── 도움이 되는 기술(skill)들만 모아두더라도, 그 수가 늘어나면 에이전트(agent)는 오히려 약해진다. 게다가 약해지는 이유가 아마 직관과는 다를 것이다.

어떤 논문인가

"More Skills, Worse Agents? Skill Shadowing Degrades Performance When Expanding Skill Libraries". Databricks의 Hongwen Song · Song (Vinson) Wei가 작성한 Workshop Agent Skills '26 논문입니다.

혼동을 피하기 위해 미리 써둔다. 이것은 SkillsBench ── 사람이 만든 기술(skill)은 도움이 되고, AI가 자기 생성한 기술(skill)은 거의 도움이 되지 않는다는 것을 보여준 그 논문 ── 과 다른 것이다. 평가 데이터셋으로 SkillsBench를 사용하고는 있지만, 이 논문이 묻고 있는 것은 단 하나다. 라이브러리에 기술(skill)이 늘어났을 때, 어떤 일이 벌어지는가.

얼마나 떨어지는가

실험은 심플하다. 두 가지 조건에서 성공률을 비교한다. 하나는 해당 태스크의 성공률을 높인다고 알려진 기술(skill)들로만 구성된 작은 라이브러리. 다른 하나는 거기에 기술(skill)을 대량으로 추가한 큰 라이브러리다.

기술(skill)을 202개까지 늘리면, 성공률은 최대 21포인트 하락했다(2개 모델의 평균). 추가된 기술(skill)은 고장 난 것이나 악의적으로 심어놓은 것이 아니다. 모두 사람이 직접 작성한, 각각 다른 어딘가의 태스크에서 도움이 되는 기술(skill)들이다. 그럼에도 불구하고 선반에 놓인 개수만 늘어날 뿐 성능은 떨어진다.

열화를 두 가지로 나누다

이 논문의 흥미로운 점은 그 저하를 원인별로 나누어 보여주었다는 것이다.

하나는 context overhead ── 문맥 오버헤드(context overhead)다. 기술(skill)이 늘어나면 그 이름과 설명문이 문맥(context)을 압박한다. 올바른 기술(skill)을 선택하더라도, 문맥이 부풀어 오른 만큼 실행의 질이 떨어진다.

또 다른 하나는 skill shadowing ── 기술 섀도잉(skill shadowing)이다. 라이브러리가 커질수록 에이전트(agent)가 잘못된 기술(skill)을 선택하게 된다. 프로그래밍의 변수 섀도잉(variable shadowing)과 마찬가지로, 설명문이 그럴싸하게 겹치는 다른 기술(skill)이 원래 선택해야 할 기술(skill)을 가려버린다.

의외인 것은, 누가 범인인가

직관적으로는 범인이 context overhead라고 생각하기 쉽다. 기술(skill)이 늘어난다, 문맥(context)이 부풀어 오른다, 악화된다 ── 자연스러운 논리다.

하지만 측정해 보니 그렇게 단순하지 않았다. 202개일 때의 21포인트 하락을 점 추정(point estimation)으로 내역을 나누면, shadowing이 약 68%, context overhead가 약 3할 ── shadowing 쪽이 더 크다. 게다가 context overhead는 신뢰 구간이 0을 걸치고 있어, 통계적으로 실재를 확정할 수 없다. 논문 자체에서도 context overhead도 있을 것 같다 ── 올바른 기술(skill)을 선택하고 있는 케이스에서도 라이브러리가 클수록 성공률은 떨어진다 ── 는 언급했지만, 이번 샘플 수로는 측정할 수 없다고 적고 있다. 따라서 데이터로 명확히 지목할 수 있는 범인은 shadowing 쪽이다. "잘못된 기술(skill)을 잡는 것". 문맥의 무게도 발목을 잡고 있겠지만, 이번 규모에서는 확정할 수 없었을 뿐이다.

논문의 mario-coin-counting 예시가 이해하기 쉽다. 코인을 세는 태스크인데, 라이브러리에는 video-frame-extraction이라는 이름의 기술(skill)이 섞여 있다. 설명문의 모습이 쿼리(query)와 잘 맞아떨어진다. 결과적으로 에이전트(agent)는 26번의 시도 모두에서 이 잘못된 기술(skill)을 선택했다. 단 한 번도 원래 선택해야 할 기술(skill)을 선택하지 않았다.

이 오선택을 설명하는 것이 shadowing이 발생하는 타이밍이다. 에이전트(agent)가 기술(skill)을 선택할 때 보이는 것은 각 기술(skill)의 이름과 description뿐이다. 본문(SKILL.md의 내용)은 아직 읽어 들여지지 않았다. 즉, 오선택은 내용을 보기 전 ── 인터페이스(interface) 정보만으로 ── 일어나고 있다.

모델마다 무너지는 방식이 다르다

부차적인 내용이지만, 모델에 따라 무너지는 방식이 달랐다는 점도 흥미롭다. 라이브러리가 커지면 Haiku 4.5는 "애초에 skill을 선택하지 않게 되는" 방향으로, Sonnet 4.6은 "잘못된 skill을 계속 선택하는" 방향으로 무너졌다. 이 실험 범위 내에서는 작은 모델은 포기하고, 큰 모델은 오선택을 하는 방식으로 무너지는 것처럼 보인다.

skill을 운용하는 사람에게 무엇이 변하는가

여기서부터는 실제로 .claude/skills/를 키워나가고 있는 사람들을 위한 이야기입니다.

shadowing이 이름과 description만으로 발생한다면, 손을 대야 할 곳은 "skill의 내용을 다듬는 것"보다 "선택을 설계하는 것"이 된다.

손대기 쉬운 것은 명명(naming)과 설명문이다. description을 서로 겹치지 않도록 작성한다. 자신의 skill 선반에 설명문이 유사한 skill이 여러 개 나열되어 있다면, 그것은 장차 어딘가에서 오선택을 일으킬 씨앗이라고 생각하는 편이 좋다.

구체적으로 어떻게 해야 할까. 예를 들어 video-processing, frame-extraction, image-analysis와 같이 설명이 유사한 skill이 나열된다면, description 단계에서 차이를 명확히 해두어야 한다. "입력은 동영상인가, 정지 영상인가", "최종 결과물은 프레임 이미지인가, 수치 집계인가, 리포트인가", "사용해서는 안 되는 상황은 어디인가" ── 이 정도까지 description에 써버리는 것이다. 본문(SKILL.md의 내용)에서 아무리 정성스럽게 설명해도, 선택할 때는 읽히지 않는다. 그러면 늦다.

한 단계 더 나아간다면, 라이브러리 전체를 문맥(context)에 쌓는 것을 그만두는 방향이다. 논문에서도 다음 단계로 검색을 통해 후보를 미리 좁히기, description의 모호함을 줄이기, 선택 그 자체를 학습시키기 등의 방향을 제시하고 있다. 전부 보여준 뒤에 선택하게 하는 것이 아니라, 후보를 좁힌 뒤에 보여주는 것이다.

엉뚱한 이야기가 아니다. "결국, skill은 몇 개까지 실을 수 있는가" ── 운용하다 보면 한 번쯤 품게 되는 이 질문에, 성능 측면에서 접근한 것이 이 논문이라고 읽을 수도 있다. 같은 문제의식을 가진 연구로는 칭화대학교의 "Skill Retrieval Augmentation for Agentic AI"도 있다.

맹신하지 않기 위해서

흥미로운 논문이지만, 과대평가하지 않는 것이 좋다. 이것은 워크숍(workshop) 논문이며 규모도 겸손하다. skill 202개, 2개의 모델, 게다가 단일 프로바이더(Anthropic의 Haiku 4.5와 Sonnet 4.6) 범위에서의 결과다. 그리고 또 하나, 평가 대상이 된 것은 "그 skill이 나름대로 도움이 된다"고 확인된 task/model 조합뿐이다. skill이 애초에 도움이 되지 않는 태스크까지 포함한 일반적인 평균이 아니다. 저자 스스로도 라이브러리가 한 자릿수 더 커졌을 때나, 다른 아키텍처에서도 같은 경향이 지속될지는 미해결 상태라고 적고 있다. "skill을 늘리지 마라"라는 단순한 교훈으로 결론짓는 것은 아마 과한 해석일 것이다.

요약하자면

이 논문을 한 줄로 요약하면 다음과 같다. 에이전트에게 올바른 가이드를 제공해야 할 skill이 정리되지 않은 채 늘어나면, 그 자체로 잘못된 선택을 유발한다.

까다로운 점은, shadowing을 일으키는 skill이 망가져 있지도 않고 악의적으로 만들어지지도 않았다는 것이다. video-frame-extraction은 동영상 프레임 추출 태스크에 있어서 완전히 올바른 skill이다. 즉, "올바름"은 skill이 단독으로 가지는 성질이 아니다. 그 skill과, 지금 풀려고 하는 태스크와, 선반에 다른 무엇이 나열되어 있는가 ── 그 관계 속에서 비로소 "올바른 가이드"가 될지 "함정"이 될지가 결정된다.

skill 라이브러리를 키울 때, 정말로 설계해야 하는 것은 아마 하나하나의 내용보다는 "무엇을 선택하게 할 것인가" 쪽일 것이다.

참고

참고

• More Skills, Worse Agents? Skill Shadowing Degrades Performance When Expanding Skill Libraries(Song & Wei, Agent Skills '26)── https://openreview.net/pdf/d0442bc35b36808ccd4a60602430b40597dff620.pdf
• SkillsBench: Benchmarking How Well Agent Skills Work Across Diverse Tasks(arXiv:2602.12670)── https://arxiv.org/abs/2602.12670
• Skill Retrieval Augmentation for Agentic AI(arXiv:2604.24594)── https://arxiv.org/abs/2604.24594

논의 (Discussion)