Princeton·Stanford·UCSD 팀이 에이전트 스킬(skill)이 실제로 어떻게 작동하는지 분해한 논문을 냈습니다. arXiv 2608.14036, “Demystifying Agent Skills: Why They Work—Until They Don’t”입니다.
핵심 결론부터 정리했습니다.
- 스킬은 절차를 안정화해서 작동한다. 전체 스킬 효과의 65.7%가 “절차 앵커(procedural anchor)” 역할이고, 명시적 지식 주입은 4.5%에 불과하다.
- 같은 트랙토리로 만든 워크플로 메모리보다 스킬이 +6.06포인트 성공률이 높다 (61.9% vs 55.9%).
- 스킬 풀이 5개에서 100개로 커지면 실제 사용 정밀도는 29.6%에서 3.3%로 떨어진다. 근데 최종 성공률은 거의 그대로다 (36.4% → 39.3%).
- 정답 스킬을 정확히 골라도 성공이 보장되지 않고, 엉뚱한 스킬을 써도 성공하는 경우가 있다. 검색 정확도와 태스크 성공은 1:1로 연결되지 않는다.
무엇을 한 연구인가
기존 평가는 “스킬을 넣으면 성공률이 오르는가”만 봤습니다. 이 논문은 언제 도움이 되고, 왜 작동하고, 어디서 실패하는지를 쪼개서 물었습니다.
방법은 대조 실행(paired execution)입니다. 같은 태스크를 스킬 없이 / 워크플로 메모리로 / 스킬로 세팅해서 돌리고, 8,135개 트라이얼을 정규화한 뒤 240개 트랙토리를 열린 코딩으로 분석해 238개 라벨을 뽑았습니다. 그 결과를 카테고리 3개, 세부 모드 12개인 택소노미로 정리했습니다.
Figure 1 출처: 논문 Figure 1 (arXiv 2608.14036)
실험 세팅은 이렇게 구요. Codex + GPT-5.3-Codex, Gemini CLI + Gemini-3.1-Pro 두 페어링으로 Terminal-Bench와 SkillsBench를 돌렸습니다. 스킬은 초기 컨텍스트에 다 넣지 않고 실행 환경 안에 재사용 가능한 절차 리소스로 배치했습니다.
왜 작동하나: 절차 앵커
Figure 2 출처: 논문 Figure 2 (arXiv 2608.14036)
가장 중요한 발견입니다. 스킬이 작동하는 주 메커니즘은 절차 앵커링(65.7%)입니다. 지식 주입은 4.5%에 그칩니다. 환경 셋업 순서, 도구 호출 시퀀스, 중간 체크, 반복되는 함정 회피 — 이런 실행 레이어를 안정화하는 겁니다.
숫자로 보면:
| 항목 | Raw | Workflow Memory | Skill |
|---|---|---|---|
| 성공률 (oracle-status) | 59.1% | 55.9% | 61.9% |
| 실행 레이어 실패 (SC2) | 37.3% | 33.3% | 23.5% |
| 호출/경계 실패 (SC3) | 19/528 | — | 78/528 |
스킬이 실행 레이어 실패를 크게 줄이는 대신, 잘못된 호출이나 과적용 같은 새로운 실패 모드(SC3)를 조금 늘린다는 점도 같이 봐야 합니다.
워크플로 메모리도 나쁘지 않습니다 (스킬 가이드 성공 61.6% vs 워크플로 가이드 성공 54.5%). 근데 원본 트레이스에 가까워서 실패한 분기, 잡음, 장황한 과정 디테일을 함께 물고 가서 타임아웃과 드리프트를 키웁니다. 스킬은 그걸 압축해서 깨끗한 운영 절차로 만들 때 이깁니다.
검색은 별도의 병목이다
Figure 3 출처: 논문 Figure 3 (arXiv 2608.14036)
풀 크기를 5에서 100으로 키우면:
- Gemini 실사용 정밀도: 16.9% → 0.7%
- Codex 실사용 정밀도: 42.3% → 5.9%
- 평균 다운스트림 성공률: 36.4% → 39.3% (거의 플랫, Codex는 35.4% → 42.0%로 오히려 상승)
재밌는 건 k=100에서 리콜은 54.3–73.6%로 유지된다는 겁니다. 에이전트가 여러 후보를 열어보긴 하는데 정답 스킬만 쓰지 않는 거죠. 정확한 정답 스킬 호출만으로는 성공이 결정되지 않는다는 게 이 논문의 결론입니다.
프레임워크 간 전이
Figure 4 출처: 논문 Figure 4 (arXiv 2608.14036)
Codex에서 만든 스킬과 워크플로 메모리를 Gemini CLI에서 평가했습니다. 스킬이 워크플로 메모리보다 전이에서 더 견고했다는 게 논문의 리딩입니다. 원본 트레이스 특유의 프레임워크 커플링이 스킬 증류 과정에서 걸러지기 때문으로 보입니다.
그래서 스킬은 언제 깨지나
택소노미 SC3가 답을 줍니다. 스킬 실패는 크게 세 가지입니다.
- 취약한 가정(brittle assumptions): 특정 환경·버전에 묶인 지시
- 비호환 컨텍스트(incompatible contexts): 프레임워크나 태스크가 바뀐 상황에서 그대로 적용
- 불충분한 적응(insufficient adaptation): 스킬을 따르기만 하고 현재 태스크에 맞게 고치지 않음
스킬 기반 자기개선은 메모리를 더 쌓는다고 풀리는 영역이 아닙니다. 절차 추상화를 만들고·검색하고·호출하고·적응시키는 전체 파이프라인이 관건입니다.
내 해석: 실무적으로 쓸 지점
원문 근거와 제 해석을 나눠서 정리했습니다.
- 스킬은 지식 베이스보다 체크리스트에 가깝게 써야 합니다. 셋업 순서, 검증 커맨드, 흔한 함정 — 이런 걸 담을 때 효과가 큽니다.
- 스킬 라이브러리가 커지면 검색 정밀도는 반드시 무너집니다. 근데 최종 성공률은 안정적이니, “정확한 스킬 선택”에 과투자하기보다 여러 스킬을 열어봐도 절차적 도움을 받는 구조로 설계하는 게 낫습니다.
- 워크플로 메모리에서 스킬로 증류할 때 실패한 분기와 과정 잡음을 제거하는 게 핵심입니다. 그게 +6.06포인트의 출처예요.
더 실습해보고 싶은 분들께
참고: arXiv 2608.14036