에이전트 스킬을 반복해서 고치면 처음 한두 번은 좋아 보이지만, 곧 개선이 멈추거나 문서가 길어지고 기존 규칙이 사라지는 문제가 생긴다.
이때 부족한 것은 대개 editor model의 문장력이나 iteration 횟수가 아니다.
다음 수정 방향을 알려 줄 새롭고 신뢰할 수 있는 실패 신호가 계속 나오는가가 더 근본적인 병목이다.
SkillEvo: Self-Renewing Evolution Gradients from Multi-Turn Interaction Feedback는 이 질문을 스킬 진화의 중심으로 둔다.[1][2]
저자들은 single-turn QA가 처음 질문에서 드러난 결함만 빠르게 보완한 뒤 plateau에 이르는 반면, 다중 턴 interaction은 수정된 답변을 발판으로 사용자의 다음 의도와 더 깊은 결함을 꺼내므로 feedback 자체가 다음 round의 evolution gradient를 다시 만든다고 주장한다.
무엇을 해결하려는가
논문은 기존 agent skill을 사람이 작성하거나 LLM이 한 번 생성한 문서로 출발하는 경우가 많다고 본다.
실패 사례를 반영해 스킬을 갱신하는 접근도 있지만, 그 피드백이 한 번의 질문과 답에 머물면 dialogue 중간에서만 드러나는 지식 누락, 조건 해석 오류, follow-up 대응 실패를 놓치기 쉽다.[1][2]
저자들이 제안하는 관점은 단순하다.
첫 라운드에서 답변이 보완되면 사용자는 그 답을 기반으로 다음 조건을 묻고, 그 과정에서 이전에는 가려져 있던 결함이 드러난다.
따라서 좋은 feedback loop는 결과를 채점하고 끝나는 evaluator가 아니라, 수정 후에도 새 실패를 생성하는 simulator여야 한다.[2]
다만 반복 편집은 또 다른 위험을 만든다.
새로운 규칙을 넣으려다 기존의 안정된 사실을 삭제하거나, 참조 관계를 끊거나, 문서를 불필요하게 부풀릴 수 있다.
SkillEvo는 이를 단일 end-to-end score로 거절하는 대신, factual consistency와 structural consistency를 별도로 진단하는 governance layer로 다룬다.[2]
핵심 구조: feedback 생성과 거버넌스를 분리한다
SkillEvo의 loop는 Scenario Synthesizer → UserAgent → Verifier → Collective Attribution → Skill Optimizer → Skill Governor로 구성된다.[2]
위쪽은 신뢰할 수 있는 failure signal을 만들고, 아래쪽은 수정 과정이 지식 자산을 훼손하지 않도록 제어한다.
| 단계 | 공개된 설계 |
|---|---|
| Scenario Synthesizer | ticket에서 agenda, 사실, 감정 상태를 포함한 user scenario를 재구성한다. |
| Multi-turn interaction | UserAgent와 service agent가 follow-up·clarification을 포함한 대화를 수행한다. |
| Dual-sided evaluation | simulator의 intent coverage와 agent의 exposed-intent accuracy를 분리해 평가한다. |
| Collective attribution | 실패를 Knowledge Gap, Capability Limit, Evaluation Noise로 나누고, 지식 결함만 수정 신호로 보낸다. |
| Bounded editing | 근거에 묶인 범위에서 Skill과 reference file을 제한적으로 수정한다. |
| Governance와 선택 | fact/structure consistency를 검사하고, round별 checkpoint 중 development set 기준 최선의 버전을 고른다. |
여기서 attribution이 특히 중요하다.
어떤 실패가 skill 문서에 없는 사실 때문인지, base agent의 능력 한계인지, simulator·evaluator의 noise인지 분리하지 않으면 오류 원인을 모두 스킬에 쌓는 방향으로 drift할 수 있다.
논문은 Knowledge Gap만 feedback set에 넣는다.[2]
Governance는 두 층이다. fact consistency는 production baseline S0와 직전 버전 S(t-1)이라는 dual anchor로 stable fact 삭제, 이번 round에 새로 생긴 사실 오류, self-contradiction을 검사하며 위반 candidate를 거절하고 같은 round에서 repair한다. structural consistency는 knowledge bloat, 끊어진 reference, 지나친 일반화처럼 scalar score가 놓치는 구조적 열화를 soft recommendation으로 다음 수정에 반영한다.[2]
공개된 근거에서 확인되는 점
실험은 Tencent Cloud의 기술 지원 failure set에서 수행됐다.
논문 기준 6개 cloud-service category, 9개 production Skill, 98개 skill-reference file을 다루며, 모든 ticket은 기존 스킬로 해결되지 않아 human agent에게 escalated된 사례다.
각 Skill의 ticket은 시간 순서로 4등분해 앞의 3/4만 development evolution loop에 사용하고 마지막 1/4는 hold-out evaluation으로 남겼다.[2]
평가 지표인 TSR은 verifier knowledge score가 60점 이상이고 task definition의 key condition이 빠지지 않은 ticket 비율이다.
원 논문은 verifier 판정과 domain expert consensus의 일치가 90%를 넘는다고 보고하지만, 이 검증은 논문 내부의 표본 평가이므로 외부 서비스·다른 domain에 그대로 일반화된 결과로 볼 수는 없다.[2]
| Method | Evaluation-set TSR: 초기 → R1 → R2 → R3 → R4 |
|---|---|
| Original Skill | 30.0% → — → — → — → — |
| Self-Reflection | 30.0% → 59.2% → 58.7% → 57.4% → 58.8% |
| Single-turn QA | 30.0% → 58.9% → 64.5% → 65.7% → 66.4% |
| SkillEvo | 30.0% → 59.4% → 71.3% → 77.9% → 81.8% |
같은 4개 round에서 SkillEvo는 single-turn QA보다 +15.4 percentage point, self-reflection보다 +23.0pp 높았다.[1][2]
가장 중요한 비교는 R1 이후다.
첫 round의 차이는 작지만, single-turn QA는 58.9%에서 66.4%로 점차 완만해지는 반면 SkillEvo는 59.4%에서 81.8%까지 계속 올라간다.
논문의 해석대로라면, 이 차이는 editor를 바꾼 결과가 아니라 feedback modality를 바꿨기 때문에 생긴다.[2]
Ablation도 이 경계를 보여 준다. multi-turn interaction만 single-turn QA로 교체하면 R4 TSR은 66.4%로 내려가 full system 대비 차이가 전부 사라진다. governance를 제거하면 TSR은 78.6%로 3.2pp 낮아진다.
즉 feedback generator가 성능 상승의 주된 원인이고, governance는 최고 점수를 만들기보다 반복 수정에서의 퇴화를 막는 역할에 가깝다.[2]
| 반복 수정 안정성 | 논문에서 확인되는 비교 |
|---|---|
| 누적 knowledge bloat | Governance 사용: +2.8% · 미사용: +16.2% |
| cross-round regression rate | 사용 설정에서 R1→2 28.2% → R3→4 21.1%. 미사용 직접 비교 수치는 논문 표에 없다. |
문서가 무조건 길어져서 좋아진 결과라는 해석도 경계할 수 있다.
논문은 baseline 대비 TSR이 51.8pp 올라가는 동안 governance를 쓴 설정의 누적 line growth는 2.8%라고 보고한다.[2]
물론 text-line 수는 정확성이나 운영 안전성의 완전한 대리 지표가 아니지만, 최소한 성능 향상이 단순한 정보량 팽창에만 의존하지 않았다는 보조 근거는 된다.
실무에서 읽는 법: 스킬 진화에는 승인 가능한 feedback surface가 필요하다
SkillEvo가 주는 가장 실용적인 교훈은 스킬을 자동으로 수정하기 전에 무엇이 다음 수정의 유효한 근거인지를 정해야 한다는 점이다.
실제 운영 로그의 failure는 지식 부족, 권한 부족, product bug, model hallucination, evaluator bug가 섞여 있다.
이를 모두 SKILL.md에 추가하면 문서가 길어질 뿐 아니라 잘못된 운영 규칙이 고착될 수 있다.
따라서 도입 순서는 좁게 잡는 편이 낫다.
- failure taxonomy를 먼저 둔다. Knowledge Gap과 capability·infrastructure·evaluation failure를 구분해야 한다.
- 다중 턴 verifier를 만든다. 한 번의 정답 대신 follow-up에서 조건, 예외, 다음 행동이 유지되는지 확인한다.
- production baseline을 보존한다. 새 사실만 검증하지 말고 기존 stable fact 삭제와 reference breakage도 diff 수준에서 막는다.
- human gate를 남긴다. 논문도 production rollout 전 human confirmation을 아키텍처 원칙으로 둔다. 비용·권한·규정에 영향을 주는 스킬은 자동 publish 대상이 되어서는 안 된다.[2]
이 접근의 외부 재현성은 아직 열려 있다. arXiv v1에서 확인되는 공개물은 논문 HTML·PDF와 TeX source이며, arXiv가 연결한 공식 code repository나 model checkpoint는 확인되지 않는다.[1][2]
또한 실험은 human-escalated Tencent Cloud support ticket이라는 이미 어려운 failure set과 특정 service domain에 기반한다.
그래서 지금 시점의 SkillEvo는 바로 설치할 수 있는 framework라기보다, 다중 턴 실패를 재생산하고, 원인을 귀속하고, 지식 자산의 퇴화를 통제하는 self-evolution 설계 원리로 읽는 편이 정확하다.
결국 SkillEvo의 주장은 “agent skill을 계속 고치자”가 아니다.
수정이 좋은 방향으로 이어지려면 다음 실패가 다시 나타나는 interaction loop와, 이미 알고 있던 것을 잃지 않게 하는 governance loop가 동시에 필요하다는 것이다.
스킬 관리가 단순한 prompt writing을 넘어 운영 지식의 lifecycle 관리로 이동할수록, 이 두 루프의 분리가 더 중요해질 가능성이 크다.