에이전트 스킬 100개 깔았더니, 맞는 걸 고를 확률 3.3%로 주저앉았다

프린스턴·스탠퍼드 공동 연구팀이 8135건을 실측했다. 스킬은 지식을 넣어줘서가 아니라 절차를 고정해서 작동한다

Editorial data visualization illustrating an AI agent skill library expanding from 5 to 100 modules, with a dramatic collapse in correct skill selection accuracy from 29.6% to 3.3% while task success remains nearly stable; show a large modular storage wall of skill cards, progressive disclosure layers, search-and-selection bottleneck, and a subtle contrast between precise retrieval and steady execution, using clean infographic composition, dark modern tech palette with blue, cyan, and amber accents, crisp typography-like shapes without actual text, subtle charts, arrows, percentage-style bars, and a thoughtful analytical mood, high-resolution, polished magazine-style illustration, minimal background, soft glow, precise geometry, no logos, no readable text

스킬 창고를 5개에서 100개로 늘렸다. 에이전트가 맞는 스킬을 실제로 집어 든 비율은 29.6%에서 3.3%로 주저앉았다. 하지만 과제 성공률은 거의 움직이지 않았다.

지난 14일 arXiv에 올라온 논문 Demystifying Agent Skills: Why They Work-Until They Don’t의 실측값이다. 프린스턴대(Princeton University)와 스탠퍼드대, UC샌디에이고, 서던캘리포니아대(USC), 존스홉킨스대 연구진이 함께 썼다. 이들은 벤치마크 세 종과 에이전트 두 벌을 오가며 얻은 시행 기록 8135건을 정규화하고, 그중 240건을 손으로 코딩해 238개 라벨을 남겼다.

지금까지 스킬 평가는 성공률 한 줄로 끝났다. 이 논문은 스킬이 언제 도움이 되고 무엇 때문에 도움이 되며 어디서 무너지는지를 따로 떼어 재는 쪽으로 질문을 바꿨다.

스킬은 왜 유행했나

에이전트 스킬은 절차 지식을 마크다운 문서 한 장으로 묶은 꾸러미다. 앤트로픽(Anthropic) 공식 문서는 스킬을 세 단계로 나눠 읽어 들인다고 설명한다. 시작할 때 컨텍스트에 올라가는 건 이름과 설명뿐이고, 스킬 하나당 약 100토큰이다. 본문은 그 스킬이 걸렸을 때만 5000토큰 미만으로 들어오고, 첨부 파일과 스크립트는 실제로 열어보기 전까지 0토큰이다.

점진적 공개(progressive disclosure)라 부르는 이 구조가 스킬을 띄웠다. 앤트로픽 문서는 이 설계 덕분에 컨텍스트 부담 없이 많은 스킬을 설치할 수 있다고 적었고, 툴 정의 전체가 컨텍스트에 상주하는 MCP와 견주며 스킬이 부각된 근거도 여기다.

아키텍처 메커니즘

스킬의 3단계 점진적 공개(Progressive Disclosure) 구조

컨텍스트 토큰 소비 최적화 원리
1단계: 시작 메타데이터 ~100 토큰

이름 & 간략 설명문

• 시스템 시작 시 컨텍스트에 상주
• 무엇을 하는지, 언제 쓰는지 명시
• 100개를 등록해도 약 1만 토큰 유지

2단계: 온디맨드 본문 < 5000 토큰

절차 지침 (SKILL.md)

• 스킬이 필요하다고 판단될 때 로드
• 순서, 체크리스트, 예시 규칙 포함
• 필요한 순간에만 컨텍스트에 진입

3단계: 실행 도구/파일 호출 전 0 토큰

번들 스크립트 & 에셋

• 파이썬 스크립트, 데이터 템플릿 등
• 터미널에서 실제 실행할 때만 작동
• 컨텍스트 윈도우를 일체 점유하지 않음

⚖️
스킬(Skill) vs MCP(Model Context Protocol) 구조적 차이
MCP는 모든 툴 스키마가 컨텍스트에 상시 상주하지만, 스킬은 이름/설명 ➔ 본문 ➔ 실행으로 지연 로딩되어 토큰 낭비를 차단합니다.

효과는 이미 수치로 확인된 바 있다. 지난 2월 공개된 벤치마크 SkillsBench는 8개 도메인 87개 과제에서 다듬은 스킬을 붙였더니 평균 통과율이 33.9%에서 50.5%로 올랐다고 보고했다. 같은 실험에서 모듈 3개 이하의 좁은 스킬이 큰 묶음보다 성적이 좋았다.

이번 논문이 찌른 지점이 여기다. 토큰은 아꼈다. 하지만 100개 가운데 맞는 걸 골라내는 문제는 없어진 게 아니고, 컨텍스트 창에서 검색 정확도로 자리를 옮겼을 뿐이다.

네 갈래로 쪼갠 실험

논문은 질문을 넷으로 나눴다. 절차를 어떤 형식에 담느냐, 성공·실패 표시가 무슨 구실을 하느냐, 다른 에이전트 프레임워크로 옮겨도 통하느냐, 스킬 창고를 어떻게 짜느냐가 검색과 실제 사용을 어떻게 바꾸느냐다. 재료를 고정한 채 한 번에 한 조건만 흔들어 효과를 갈라내는 설계다.

평가는 Terminal-Bench 2.0과 Pro, 그리고 SkillsBench에서 돌렸다. Terminal-Bench는 명령줄 환경의 실무 과제 89개를 검증 테스트로 채점하는 벤치마크로, 프런티어 모델도 65%를 넘기지 못한다. SkillsBench는 과제와 스킬의 정답 짝을 미리 달아둬서 검색 실험을 통제할 수 있다.

에이전트 조합은 두 벌이다. 코덱스(Codex)에 GPT-5.3-Codex를 얹은 쪽, 제미나이(Gemini) CLI에 Gemini-3.1-Pro-Preview를 얹은 쪽이다. 스킬 없이 맨몸으로 돌린 기준선은 코덱스 조합에서 Terminal-Bench-2 59.35%, SkillsBench 50.83%, Terminal-Bench-Pro 53.94%였다.

비교 대상은 워크플로 메모리(Workflow Memory)다. 지난 실행 기록을 다듬어 흔적 그대로 남겨두는 방식으로, 스킬은 똑같은 기록을 표준 절차 문서 한 장으로 압축한다.

재료는 같고 담는 그릇만 다르다.

실패 기록으로 만든 스킬이 더 나았다

연구진은 스킬을 빚는 재료를 성공 궤적과 실패 궤적으로 섞어가며 바꿨다. 5s0f는 성공 5건, 0s5f는 실패 5건이라는 뜻이다.

코덱스 조합의 Terminal-Bench-2 성적을 보자. 성공만 다섯 건 넣었을 때 워크플로 메모리는 44.5%, 스킬은 75.5%였다. 성공 셋에 실패 둘을 섞었더니 스킬은 오히려 78.1%로 올랐다.

압권은 마지막 줄이다. 실패 궤적만 다섯 건 넣어 만든 스킬이 51.6%를 냈다. 성공 궤적만 다섯 건 넣어 만든 워크플로 메모리의 44.5%보다 높다.

무엇이 잘못됐는지만 담긴 문서가, 무엇이 잘됐는지 담긴 기록을 앞질렀다.

실험을 통틀어 스킬은 같은 재료로 만든 워크플로 메모리를 6.06%포인트 앞섰고, 95% 부트스트랩 신뢰구간은 0.76에서 11.36 사이로 나왔다. 하한이 0.76인 만큼 차이가 있기는 하나 여유가 크지는 않다.

성공·실패 표시를 지우면 얘기가 달라진다. 제미나이 조합의 3s2f 구성에서 표시를 붙인 스킬은 74.6%를 냈고, 표시를 뗀 스킬은 40.0%로 주저앉았다. 실패가 섞일수록 라벨이 무거워진다.

실패 기록이 값을 하려면 실패라는 사실이 문서에 적혀 있어야 한다.

실측 벤치마크

궤적 재료(성공·실패) 및 라벨 유무별 통과율 비교 (Terminal-Bench 2.0)

Codex + GPT-5.3-Codex 기준
5s0f (성공 궤적만 5건) 메모리 44.5% vs 스킬 75.5% (+31.0%p)
스킬
75.5%
메모리
44.5%
3s2f (성공 3건 + 실패 2건 혼합) ★ 최고 성적 실패가 섞이자 성적 상승
스킬
78.1%
0s5f (실패 궤적만 5건) 성공만 넣은 메모리(44.5%)를 역전
스킬
51.6%
⚠️ 라벨 유무의 결정적 차이 (Gemini 조합 3s2f 기준)
실패 원인을 ‘실패’라고 명시한 스킬(74.6%) vs 라벨을 지운 블라인드 스킬(40.0%)-34.6%p 폭락
라벨 누락 시 치명적 역효과

절차 앵커라는 대답

왜 실패 기록이 도움이 되는가. 논문의 답은 스킬이 지식을 넣어주는 물건이 아니라는 데 있다.

연구진은 스킬이 개입한 사례를 열두 갈래로 분류했다. 절차 앵커(procedural anchor)가 65.7%였다. 없던 사실을 채워 넣는 지식 주입(knowledge injection)은 4.5%에 그쳤다.

절차 앵커는 순서, 체크리스트, 툴 호출 차례, 검증 계획처럼 무엇을 어떤 차례로 하라는 뼈대를 말한다. 실패 궤적에도 이 뼈대는 고스란히 남는다. 어디서 넘어졌는지가 다음 사람에게는 걸어갈 순서가 되기 때문이다.

실패 유형별 감소폭이 이를 뒷받침한다. 맨몸 상태에서 5.3%를 차지하던 환경·인프라 실패는 스킬을 붙이자 0.2%로 사라지다시피 했다. 출력 형식 불일치는 7.4%에서 3.2%로, 백그라운드 서비스 관리 실패는 2.7%에서 0.8%로 줄었다.

전부 몰라서 나는 사고가 아니라 순서를 놓쳐서 나는 사고다.

원인 규명 분석

스킬 개입 메커니즘 비중 & 주요 오류 유형별 감소율

시행 기록 8135건 / 12갈래 정밀 분석

📊 스킬의 핵심 개입 방식 비중

절차 앵커 (순서·체크리스트 고정) 65.7%
기타 복합 요인 29.8%
지식 주입 (새로운 사실 제공) 4.5%

📉 스킬 도입 시 오류 유형별 감소율

환경·인프라 설정 실패 5.3% ➔ 0.2% (-96.2%)
출력 포맷 불일치 7.4% ➔ 3.2% (-56.8%)
백그라운드 프로세스 관리 2.7% ➔ 0.8% (-70.4%)
💡 핵심 요약: 에이전트가 문제를 틀리는 이유는 지식을 몰라서가 아니라 실행 순서와 체크리스트를 놓치기 때문이며, 스킬은 이 순서를 고정하는 ‘절차 앵커’ 역할을 훌륭히 수행합니다.

절차를 담은 문서라는 성격은 이사도 견뎠다. 연구진이 코덱스 쪽에서 만든 스킬을 제미나이 쪽으로 옮겨 붙였더니 성적이 목표 프레임워크의 맨몸 기준선 위에서 유지됐다. 다만 이 대목은 논문이 그래프로만 제시해 정확한 수치는 확인되지 않는다.

그러면 스킬을 많이 만들면 되는가

여기서 논문이 방향을 튼다. 네 번째 질문은 스킬 창고를 5개, 10개, 20개, 50개, 100개로 키우며 세 갈래를 따로 쟀다.

1번은 Qwen3-Embedding-0.6B로 순위만 매기는 임베딩 검색이다. 2번은 모델에게 쓸 만한 스킬을 지목만 시키는 단계다. 3번은 창고 전체를 열어두고 실제로 과제를 풀게 한 뒤, 손에 쥔 게 정답 스킬이었는지 확인하는 단계다. 세 값은 서로 넘겨주지 않고 독립해서 쟀다.

무작위로 채운 창고에서 임베딩 검색 정밀도는 스킬이 100개로 불어난 뒤에도 84.1%를 유지했다. 모델에게 지목만 시킨 단계는 69.8%였다. 실제 사용 정밀도는 4.4%로 떨어졌다.

검색기가 못 찾은 게 아니다. 찾아준 걸 에이전트가 손에 쥐지 않았다.

헷갈리는 스킬을 일부러 채워 넣은 창고에서는 임베딩 정밀도가 53.4%까지 떨어졌지만, 성공률은 39.6%로 거의 그대로였다. 반대로 서로 안 닮은 스킬만 모은 창고는 임베딩 정밀도가 93.2%로 가장 높았는데도 실제 사용 정밀도는 1.7%로 가장 낮았고, 성공률은 36.4%에 머물렀다.

세 창고를 평균 내면 5개에서 29.6%, 100개에서 3.3%다. 초록에 실린 그 숫자다.

검색이 무너져도 성공률은 왜 버티나

성공률 쪽을 다시 보면 기묘하다. 무작위 창고의 성공률은 스킬 5개일 때 31.8%였다가 100개에서 41.9%로 오히려 올랐다. 유사 창고는 41.7%와 39.6%, 비유사 창고는 35.7%와 36.4%로 사실상 평평하다.

앞의 65.7%가 이 역설을 풀어준다. 스킬이 건네는 값어치가 그 스킬 고유의 지식이 아니고 절차 뼈대에 있다면, 조금 어긋난 스킬을 집어도 뼈대는 그대로 나온다. 논문은 정답 스킬 호출이 성공의 충분조건도 필요조건도 아니라고 못 박았다.

앤트로픽 문서가 스킬 설명문에 무엇을 하는지와 언제 쓰는지를 함께 적으라고 강조하는 이유도 같은 자리에 있다. 발동을 가르는 건 설명문 한 줄인데, 그 한 줄이 100개로 늘어나면 서로를 가린다.

같은 벽은 툴 쪽에서도 확인됐다. 메타(Meta) 연구진은 지난 5월 툴 3251개를 늘어놓은 ToolBench 실험에서, 상위 5개만 보여주면 6~20위에 정답이 있는 어려운 질의를 하나도 건지지 못한다고 보고했다. 후보 개수를 질의마다 늘렸다 줄였다 하자 그 구간에서 16.7%를 되찾았다. 툴 370개짜리 BFCL에서는 평균 7개만 보여주고도 50개를 보여준 설정과 같은 90%대를 냈다.

스킬이든 툴이든 후보를 쌓아 올리는 방식은 같은 지점에서 걸린다.

점진적 공개는 컨텍스트 비용을 지웠지 선택 문제를 지우지 않았다.

검색 vs 실행 괴리

스킬 창고 규모(5개 ➔ 100개) 확장 시 단계별 정밀도 급락과 성공률 역설

실제 사용 정밀도 88.9% 폭락
1단계: 임베딩 검색 (Qwen3)
84.1%
100개에서도 높은 순위 정밀도
2단계: 모델 지목 정밀도
69.8%
LLM에게 고르라고만 했을 때
3단계: 실제 사용 정밀도
29.6% ➔ 3.3%
손에 쥔 스킬이 정답일 확률 급락
결과: 과제 최종 성공률
31.8% ➔ 41.9%
오히려 유지 및 미세 상승 (역설)
🔍 역설의 이유: 스킬의 가치가 지식이 아니라 ‘절차적 뼈대(체크리스트)’에 있기 때문에, 스킬 창고가 커져 비록 엉뚱한 스킬을 골랐더라도 범용적인 절차 지침이 실행 안정성을 부여하여 최종 성공률은 버텨냈습니다. 하지만 정답 스킬이 반드시 호출되어야 하는 정밀 작업에서는 치명적인 병목이 됩니다.

어디서 무너지는가

논문은 실패를 두 덩어리로 갈랐다. 실행과 검증 층위, 그리고 호출과 적용 범위 층위다.

스킬을 붙인 상태에서 지침을 잘못 갖다 쓰거나 아예 무시한 사례가 10.0%다. 실제로 돌려보지 않고 코드만 훑어 통과시킨 정적 검증이 11.7%, 알고리듬 오류가 7.4%, 시간·예산 초과가 4.4%로 뒤를 이었다. 스킬은 환경 설정 사고를 거의 지웠지만, 판단이 필요한 대목은 손대지 못한 채 그대로 남겼다.

연구진이 정리한 실패 조건은 셋이다. 전제가 취약할 때, 맥락이 안 맞을 때, 상황에 맞춰 고쳐 쓰지 못할 때다.

이 결과를 어디까지 믿을 수 있나

논문은 스스로 선을 그었다. 실험은 터미널과 툴 사용 과제에 한정됐고, 긴 호흡의 웹 조작이나 열린 협업은 다루지 않았다. 에이전트와 모델 조합도 두 벌뿐이다.

열두 갈래 분류는 정규화 기록의 약 3%를 층화 표집해 손으로 코딩한 결과다. 드물게 나타나는 행동은 과소 대표됐을 수 있다고 연구진이 직접 적었다.

네 번째 실험에는 구멍이 하나 더 있다. 도중에 GPT-5.3-Codex를 쓸 수 없게 돼 GPT-5.4로 갈아탔다. 연구진은 이 구간의 값을 다른 실험과 나란히 놓고 비교하지 말라고 단서를 달았다.

스킬 창고를 몇 개까지 두는 게 적정인지, 검색을 어떻게 고쳐야 실제 사용 정밀도가 올라가는지는 이 논문이 풀지 않았다. 실측하고 문제를 특정한 데서 멈춘다.

연구진은 논문을 이렇게 닫았다.

“스킬 사용은 기억을 한 번 주입하는 장치가 아니라 수명주기 문제로 봐야 한다. 더 나은 자기진화 에이전트를 만들려면 스킬을 더 많이 찍어내는 것만으로는 부족하고, 에이전트가 절차 지식을 어떻게 표현하고 검색하고 활용하는지를 함께 고쳐야 한다.”

자주 묻는 질문

스킬을 적게 유지하는 편이 나은가

A. 이 논문만으로는 그렇게 말하기 어렵다. 창고를 100개로 키워도 과제 성공률은 떨어지지 않았고 무작위 창고에서는 오히려 올랐다. 떨어진 건 정답 스킬을 집어 드는 비율이다. 특정 스킬이 반드시 호출돼야 하는 작업을 설계했다면 이 수치가 문제가 되고, 절차 안정화가 목적이라면 덜 문제가 된다.

스킬 문서에 실패 사례를 넣어도 되나

A. 실험 결과로는 도움이 됐다. 실패 궤적만으로 만든 스킬이 성공 궤적만으로 만든 워크플로 메모리보다 높은 성적을 냈다. 다만 성공·실패 표시를 지운 조건에서는 3s2f 구성 기준 74.6%가 40.0%로 떨어졌다. 실패 사례는 실패라고 명시해야 값을 한다.

스킬과 MCP 중 무엇을 써야 하나

A. 이 논문은 둘을 비교하지 않았다. 다만 후보를 많이 늘어놓을수록 고르기 어려워지는 문제는 스킬과 툴 양쪽에서 관측됐고, 메타 연구진의 ToolBench 실험도 같은 방향을 가리킨다. 토큰 비용만 놓고 고르면 검색과 호출 단계에서 값을 치르게 된다.

RELATED ARTICLES