에이전트 스킬은 스스로 진화할 수 있을까 — SkillProx 논문의 실측 검증

에이전트 스킬은 스스로 진화할 수 있을까 — SkillProx 논문의 실측 검증

에이전트에게 스킬(재사용 가능한 절차 문서)을 만들어주는 도구가 늘고 있습니다. Claude Code의 CLAUDE.md, 에이전트 프레임워크의 스킬 파일처럼, 가중치를 건드리지 않고 텍스트로 절차 지식을 주입하는 방식입니다. 저도 최근 실패사례를 축적하는 스킬을 직접 만들면서 한 가지 의문이 생겼습니다. "이 스킬을 에이전트가 스스로 개선하게 하면 어떨까? 실패에서 배워서 스킬이 진화할 수 있을까?"

이 질문에 답하는 논문이 2026년 8월 7일 arXiv에 올라왔습니다. SkillProx: Self-Evolving Agent Skills via Proximal Textual Gradient Descent입니다. 읽어보니 결론이 꽤 흥미롭습니다. 스킬은 진화할 수 있지만, 검증 없이 진화시키면 오히려 망가집니다.

핵심 요약

• 에이전트 스킬을 실패 진단→재실행 검증→압축의 반복으로 스스로 진화시키는 방법을 실측으로 보여주는 arXiv 논문입니다 (arXiv:2608.07449, 2026-08-07).
• 3개 벤치마크 × 3개 모델(Qwen3.5-4B/27B, Qwen3.6-27B)에서 평가했고, SkillProx는 인-도메인 정확도를 최대 54.5점(스킬 없음 45.3)까지 끌어올렸습니다.
• 가장 중요한 발견: 사람이 손으로 만든 스킬(Human Skill)이 큰 모델에서는 오히려 성능을 떨어뜨립니다 (45.3 → 36.7). 스킬을 주는 것 자체가 항상 좋은 게 아닙니다.
• LLM이 생성한 스킬을 검증 없이 적용하면 인-도메인 점수가 54.5에서 13.0으로 폭락합니다(EvoSkill). "그럴듯해 보이는 수정"과 "실제로 좋은 수정"은 다릅니다.
• 핵심 교훈: 스킬 수정은 반드시 같은 작업에서 재실행해 실제로 성능이 올랐는지 확인한 뒤에만 반영해야 합니다.

SkillProx란 무엇인가

논문의 한 줄 정의: LLM 에이전트의 스킬을 근접 기울법(proximal gradient)에서 영감받은 forward-backward 구조로 진화시키는 프레임워크입니다. 코드는 GitHub에 공개 예정입니다.

스킬은 가중치 업데이트 없이 에이전트 컨텍스트에 로드되는 가벼운 텍스트 아티팩트입니다. SkillProx는 이 텍스트를 두 단계로 개선합니다.

Forward 단계 (진화): 실패를 진단해서 스킬을 수정한 뒤, 같은 작업 배치에서 재실행합니다. 성능이 떨어진 수정은 롤백하고, 측정된 결과를 다음 진단에 피드백으로 넣습니다.

Backward 단계 (압축): 진화된 스킬을 감사 가능한 지식 단위로 분해하고, leave-one-out 효용 감사(하나씩 빼보며 기여도 측정)로 각 단위의 가치를 추정합니다. 검증으로 확인된 단위만 유지하고, 나머지는 강등하거나 제거합니다.

기존 방법론과 구분되는 두 가지: ① 진단과 결과 피드백을 닫힌 루프로 연결했고, ② 삭제를 "일반 편집"이 아니라 지식 압축 전용 메커니즘으로 다룹니다.

실측 결과: 세 모델 × 세 벤치마크

평가는 인-도메인(SpreadsheetBench Verified)과 아웃-오브-도메인(WikiTQ, HiTab)으로 나뉘었고, Qwen 계열 세 모델로 진행됐습니다. 점수는 0~100 평균.

Qwen3.6-27B (최신 모델) 기준:

Qwen3.5-4B (작은 모델) 기준: No Skill 20.3 → SkillProx 21.0(인-도메인), WikiTQ는 65.0 → 78.5로 큰 폭 상승.

어블레이션(Qwen3.6-27B): SkillProx 전체 54.5에서, 닫힌 루프 진단을 빼면 53.0(-1.5), 근접 압축을 빼면 52.0(-2.5). 두 구성요소가 모두 기여합니다.

주장 vs 실측: 세 가지 역설

이 논문의 진짜 가치는 숫자보다 직관에 반하는 발견에 있습니다.

① 사람이 만든 스킬이 해가 될 수 있다

Human Skill은 Qwen3.6-27B의 인-도메인 점수를 45.3에서 36.7로 8.6점 떨어뜨렸습니다. "스킬을 주면 무조건 좋다"는 통념과 정반대입니다. 사람이 만든 절차 지식이 모델의 자체 판단을 간섭해서 오히려 성능을 깎는 경우가 있다는 뜻입니다. (다만 4B 모델에서는 20.3으로 변화 없음, Qwen3.5-27B도 비슷 — 큰 모델에서만 나타나는 현상입니다.)

② 검증 없는 자기 진화는 폭락한다

EvoSkill(LLM 생성 스킬)은 Qwen3.6-27B 인-도메인에서 13.0점으로 폭락했습니다. 스킬 없는 상태(45.3)의 3분의 1도 안 됩니다. 논문은 그 원인을 이렇게 설명합니다:

"진단만 보면 그럴듯해 보이는 수정이, 스킬에 반영된 뒤에는 실제 성능을 떨어뜨리는 경우가 있다. 텍스트 수정의 품질은 의미적 개연성만으로는 판단할 수 없고, 실제 실행 결과로 평가해야 한다."

같은 모델에서 10개 시드로 비교한 결과, 열린 루프(검증 없이 적용)는 평균 50.30, 닫힌 루프(재실행 검증)는 51.40이었습니다. 격차는 크지 않지만, 극단적 폭락(EvoSkill의 13.0)을 막는 안전장치로서 닫힌 루프가 작동합니다.

③ 긴 스킬이 좋은 스킬이 아니다

근접 압축(backward 단계)으로 스킬 길이는 25.6k±9.1k 토큰에서 12.6k±11.1k 토큰으로 줄었습니다(압축률 29.4%(4B) / 19.0%(27B)). 그리고 27B 모델에서는 스킬 길이와 인-도메인 정확도가 음의 상관관계였습니다. 흥미롭게도 4B 모델의 최종 스킬은 27B보다 약 45% 더 길었는데, 작은 모델일수록 더 많은 절차적 안내가 필요했던 것으로 보입니다.

한계: 어디까지 신뢰할 수 있나

• 벤치마크가 테이블 작업에 편중돼 있습니다. SpreadsheetBench, WikiTQ, HiTab 모두 표 기반 작업입니다. 코딩 에이전트 스킬에 같은 효과가 있는지는 이 논문만으로 알 수 없습니다.
• Qwen 계열만 평가했습니다. 다른 모델 패밀리(Claude, GPT 계열)에서의 재현은 미확인입니다.
• 아웃-도메인 개선은 미미합니다. WikiTQ/HiTab은 기본이 85점대라 천장 효과로 개선 여지가 작았습니다.
• 초록의 "+3.0pp" 주장은 조건부입니다. "최강 기울법 기반 베이스라인 대비 평균 3.0pp"이라는 초록의 수치는 특정 평균화 기준에서의 값이며, 벤치마크별 격차는 1.2~4.5pp로 들쭉날쭉합니다(Qwen3.6-27B 기준).

내 스킬 관리에 적용한다면

이 논문이 실무에 주는 교훈은 명확합니다. CLAUDE.md, AGENTS.md, 에이전트 스킬 파일을 운영하는 사람이라면:

1. 스킬 수정 후에는 반드시 실제 작업으로 재검증하라. "읽어보니 그럴듯하다"는 적용 근거가 될 수 없습니다. 같은 작업에서 수정 전후를 비교해야 합니다.
2. 스킬을 주기만 하면 좋아질 거라 믿지 말라. 큰 모델에서는 수동 스킬이 오히려 간섭이 될 수 있습니다. 스킬이 실제로 도움이 되는지 A/B로 확인하는 습관이 필요합니다.
3. 스킬은 주기적으로 압축하라. 쌓이기만 하는 스킬은 길어질수록 성능과 음의 상관관계일 수 있습니다. 실제로 쓰이는 부분만 남기고 나머지는 제거해야 합니다.
4. 실패 기록은 재실행 검증과 쌍으로 남겨라. 실패→수정에서 끝나면 안 되고, 수정이 실제로 문제를 해결했는지 확인한 뒤에 스킬에 반영해야 합니다.

결론

스킬 자기 진화는 작동합니다. 다만 조건이 붙습니다. 진단은 재실행으로 검증되고, 압축은 효용 감사로 뒷받침될 때만 성능이 오릅니다. 검증 없는 진화(EvoSkill)는 45점에서 13점으로 폭락하고, 검증 있는 진화(SkillProx)는 45점에서 54.5점으로 오릅니다. 같은 "자기 개선"이라도 닫힌 루프 유무가 결과를 가릅니다.

이것은 코드 리뷰나 실패 패턴 관리에도 그대로 적용되는 원칙입니다. 수정이 그럴듯해 보이는 것과 실제로 좋은 것은 다른 문제이며, 그 차이는 오직 재실행으로만 확인할 수 있습니다.

참고 자료

• arXiv:2608.07449 — SkillProx 논문 페이지
• 논문 HTML 전문 (arXiv)
• SkillProx 코드 (GitHub, 공개 예정)
• SpreadsheetBench (벤치마크 원논문)