WikiSkill 소개
에이전트가 배운 것은 어디에 남는가
어제 알려준 요령을 오늘 다시 알려주는 일이 반복된다면, 문제는 상대의 이해력이 아니라 알게 된 내용이 어디에도 적혀 있지 않다는 데 있습니다. WikiSkill은 Google Research와 Virginia Tech 연구진이 2026년 8월 27일 arXiv에 공개한 논문으로, LLM 에이전트에게도 같은 문제가 있다고 보고 에이전트의 실행 경험을 영속적인 지식 베이스(위키)로 압축한 뒤 그 지식 위에서 실행 가능한 스킬(skill)을 반복 개선하는 프레임워크를 제안합니다.
배경을 조금 더 살펴보겠습니다. 범용 AI 에이전트는 여러 분야의 복잡한 작업을 점점 더 잘 수행하고 있지만, 실제 업무를 안정적으로 끝내려면 그 분야에만 통하는 절차 지식(procedural knowledge)과 작업 흐름이 필요합니다. 에이전트 스킬(agent skill) 은 모델 파라미터를 건드리지 않고 이런 전문성을 담아내기 위한 가벼운 개방형 형식입니다. 스킬 하나는 지시문, 스크립트, 부속 자원을 하나의 파일시스템 디렉토리로 묶은 모듈이며, 고유한 이름과 짧은 설명을 프론트매터에 적은 SKILL.md 파일이 그 중심에 있습니다. Anthropic이 정리한 스킬 작성 가이드가 이 형식의 대표적인 문서입니다.
이 설계에는 두 가지 장점이 있습니다. 첫째, 전문 지식이 파일로 남아 있어 사람이 감사할 수 있고 스킬 형식을 지원하는 여러 에이전트가 그대로 재사용할 수 있습니다. 둘째, 점진적 공개(progressive disclosure) 가 가능해 에이전트가 그때그때 필요한 내용만 읽어 들이므로 컨텍스트 공간을 아낄 수 있습니다. 무엇보다 스킬은 모델 파라미터와 무관하게 지식을 축적하는 통로가 됩니다.
스킬을 사람이 쓰는 데서 오는 한계
문제는 좋은 스킬을 만드는 일 자체가 어렵다는 데 있습니다. 대부분의 에이전트 스킬은 사람이 직접 작성하는데, 그러려면 에이전트가 앞으로 어떤 절차 지식과 작업 흐름을 필요로 할지 미리 예측해야 합니다. 실제로 어디서 막힐지는 돌려 보기 전까지 알 수 없으므로, 이 예측은 자주 빗나갑니다.
그래서 최근 연구들은 스킬을 자동으로 만들고 다듬는 쪽으로 옮겨갔습니다. 공통 구조는 같습니다: 학습 작업 위에서 에이전트를 실행하고, 성공과 실패 궤적(trajectory)을 분석하고, 거기서 얻은 경험으로 스킬을 고치고, 검증 점수로 변경을 걸러내는 순환입니다. WikiSkill 논문은 이 계열의 대표적인 방법 3가지를 비교 대상으로 삼습니다.
EvoSkill은 스킬 진화를 후보 프로그램들의 프론티어(frontier) 위에서 벌어지는 탐색으로 봅니다. 매 반복마다 카테고리 순환 일정에 따라 학습 작업을 샘플링해 롤아웃(rollout)을 수행하고, 제안자에게는 실패 궤적만 과거 제안 결과의 평탄한 이력과 함께 전달합니다. 제안자가 만든 후보 스킬은 SKILL.md 파일로 구체화되어 검증 분할에서 채점되고, 상위 프로그램들의 유한한 프론티어에 편입됩니다.
Trace2Skill은 병렬 궤적 분석과 계층적 병합을 축으로 하는 3단계 파이프라인입니다. 현재 스킬을 학습 작업에서 평가한 뒤 성공 분석가와 오류 분석가를 병렬로 투입해, 통과한 작업에서는 효과적인 전략을 뽑고 실패한 작업에서는 근본 원인을 진단합니다. 이렇게 나온 구조화된 패치들은 계층적 병합 연산자로 재귀적으로 하나의 패치 집합으로 합쳐진 뒤 스킬 문서에 적용됩니다.
SkillOpt은 롤아웃, 반성, 집계, 선택, 갱신, 평가로 이어지는 6단계 ReflACT 파이프라인을 구현합니다. 매 에포크마다 학습 작업에서 에이전트를 실행하고 성공과 실패를 모두 포함한 전체 궤적을 반성해 후보 패치를 만든 뒤, 이를 계층적으로 집계하고 선택해 하나의 단일 스킬 문서를 갱신합니다.
세 방법은 배운 것을 보존하는 방식이 서로 다릅니다. EvoSkill은 과거 제안과 평가 결과의 누적 이력을 유지하고, Trace2Skill은 궤적을 가로지르는 교훈을 추출해 스킬 갱신에 녹여 넣고, SkillOpt는 거절된 편집에 대한 피드백과 에포크 단위 메타 가이드를 사용합니다. 그런데 연구팀이 지적하는 공통점이 있습니다: 어느 방법도 배운 것 자체를 별도의, 스스로 진화하는 지식 표현으로 유지하지 않습니다. 스킬 개발을 이끄는 통찰이 최적화 이력 여기저기에 흩어진 채로 남아 있어, 반복을 거치며 체계적으로 재사용되지 못한다는 것입니다.
발상의 전환: 지식과 절차를 분리해 지식만 영속시킨다
WikiSkill의 출발점은 Andrej Karpathy가 제시한 LLM Wiki 구상입니다. 경험을 영속적이고 누적되는 지식으로 정리해 축적하자는 관점인데, 연구팀은 여기서 "에이전트의 경험도 같은 방식으로 영속 지식으로 정리해서 장기적인 스킬 진화를 뒷받침할 수 있는가?"라는 질문을 끌어냅니다. PyTorchKR에도 이 구상을 멀티에이전트로 구현한 LLM Wiki Newsroom 소개 글이 올라와 있으니 함께 참고하셔도 좋겠습니다.
WikiSkill이 도입하는 것은 원시 경험과 실행 가능한 절차 사이에 놓이는 구조화된 지식 계층입니다. 스킬 개발이 스킬 진화 산출물 여기저기에 흩어진 지식이 아니라, 반복을 거치며 점점 더 잘 뒷받침되고 통합된 지식 위에서 이루어지도록 하는 것이 목적입니다. 도서관에 비유하자면, 기존 방법들이 대출 기록만 남겨 두고 책은 매번 새로 쓰는 쪽이었다면 WikiSkill은 서가를 따로 두고 그 서가를 참고해 매뉴얼을 고쳐 쓰는 쪽입니다.
핵심 결과를 미리 말씀드리면, 5개 모델 모두에서 WikiSkill이 5개 벤치마크 평균 성능으로 기존 스킬 진화 방법을 앞섰습니다. Gemini-3.5-Flash의 경우 평균 정확도가 스킬 없이 49.5\% 에서 68.1\% 로 올랐고, Qwen-3.6-27B는 스프레드시트 조작 과제에서 40.8\% 에서 81.7\% 로 두 배 이상 상승했습니다. 그리고 이 글 후반부에서 다룰 두 가지 발견, 즉 스킬이 모델 사이를 건너뛴다는 것과 자기가 만든 스킬보다 남이 만든 스킬이 더 나을 때가 있다는 것이 이 논문에서 가장 흥미로운 부분입니다.
문제 정의: 반복적 스킬 진화
방법론에 들어가기 전에 논문이 세운 형식적 정의를 짚어 두겠습니다. 작업 데이터셋 \mathcal{D} = \{(x_i, y_i)\}_{i=1}^{N} 이 주어지고, 이를 학습 \mathcal{D}_{\text{train}} , 검증 \mathcal{D}_{\text{val}} , 테스트 \mathcal{D}_{\text{test}} 세 분할로 서로 겹치지 않게 나눕니다.
에이전트 \pi 는 도구 집합 \mathcal{U} (bash 셸, 검색 API, 파일 리더 등)와 활성 스킬 집합 S = \{s_1, \dots, s_M\} 을 갖춘 LLM 기반 시스템입니다. 작업 x_i 를 수행할 때 에이전트는 여러 단계에 걸쳐 환경과 상호작용하며 실행 궤적 \tau_i \sim \pi(x_i; S) 를 만들어냅니다. 궤적은 관측 o_t 와 행동 a_t 의 나열이고, 마지막 행동 a_T 가 예측 답안 \hat{y}_i 를 내놓습니다. 정답 여부는 도메인별 채점 함수 f(\hat{y}_i, y_i) \in [0, 1] 이 판정합니다.
여기서 WikiSkill이 기존 방법과 다른 점은 시스템 상태의 정의입니다. 반복 k 에서의 상태는 활성 스킬 집합 하나가 아니라 튜플 (S_k, W_k) 로 표현되며, W_k 가 영속 지식 베이스(위키)입니다. 후보 스킬 갱신은 검증 게이팅과 점수 하락 시 롤백의 대상이 되지만, W_k 는 반복을 거치며 계속 남아 누적됩니다. 시스템은 (S_0, W_0) = (\emptyset, \emptyset) 에서 출발해 두 상태를 함께 진화시키며 최종 테스트 성능 \mathcal{R}(\mathcal{T}_{\text{test}}) 를 최대화합니다.
3계층 작업 공간
WikiSkill의 작업 공간은 서로 성격이 다른 세 계층으로 나뉩니다. 위 그림의 왼쪽에 보이는 세 개의 가로 막대가 각각 이 계층에 해당합니다.
원본 계층(Raw Layer): 손대지 않는 실행 기록
raw/ 디렉토리는 매 반복마다 학습 예제에서 수집한 원시 실행 궤적 \tau_i \in \mathcal{T}_{\text{train},k} 를 저장합니다. 이 궤적에는 에이전트의 단계별 상호작용이 빠짐없이 담깁니다: 추론(reasoning) 내용, 도구 호출, 도구 호출 결과, 그리고 최종 답변입니다.
이 계층의 성격을 규정하는 것은 불변성입니다. 위키 관리자와 스킬 제안자 에이전트는 이 원시 궤적을 읽어 에이전트의 행동을 분석할 수 있지만, 원본 이력을 보존하기 위해 계층 자체는 수정되지 않습니다. 나중에 어떤 패턴이 어느 궤적에서 나왔는지 되짚을 수 있어야 하므로, 요약본이 아니라 원본이 남아 있어야 한다는 판단입니다.
위키 계층(Wiki Layer): 누적되는 구조화 지식
wiki/ 디렉토리는 원시 궤적을 구조화된 지식으로 정리하고 스킬 진화 내내 그 지식을 유지합니다. 구성은 네 부분입니다.
patterns/: 특정 실패 유형이나 성공 전략을 실행 가능한 우회책과 함께 문서화한 개별 마크다운 파일들이 들어갑니다.index.md: 알려진 패턴의 간결한 목록으로, 패턴 하나당 한 줄씩 기재합니다.logs.md: 위키 관리자가 갱신하는 시간순 진화 로그입니다.skill-impact.md: 검증 게이팅 이후 외부 루프 하니스(harness)가 프로그램적으로 갱신하는 스킬 영향 추적 기록입니다.
이 기록들 덕분에 위키 관리자와 스킬 제안자는 세 가지를 알 수 있습니다: 첫째, 전체 스킬 수락 이력을 관찰해 거절된 개입을 다시 제안하지 않고, 둘째, 이전 반복에서 무엇이 제안되었고 그 제안이 성공했는지를 추적하며, 셋째, 어떤 오류가 반복해서 나타나는지를 식별합니다.
가장 중요한 성질은 위키가 반복 사이에 초기화되지 않는다는 점입니다. 진화 과정 내내 지식을 계속 축적하고 정리해 나갑니다.
스킬 계층(Skills Layer): 실행되는 절차 지식
skills/ 디렉토리는 추론 에이전트가 읽는 활성 스킬 집합 S 를 담습니다. WikiSkill의 각 스킬 디렉토리에는 두 개의 파일이 들어갑니다: SKILL.md는 스킬의 전체 내용을 담고, PURPOSE.md는 그 스킬의 생성이나 수정을 촉발한 위키 패턴으로 되짚어 갈 수 있게 연결해 둡니다.
PURPOSE.md는 다른 프레임워크에서 보기 어려운 장치입니다. 스킬 문서만 보면 "왜 이 규칙이 여기 있는가"를 알 수 없는데, 이 파일이 그 스킬을 낳은 증거로 되돌아가는 경로를 남깁니다.
진화 루프를 구성하는 네 구성요소
WikiSkill의 순환은 네 단계로 이루어집니다. 위 그림 아래쪽의 파란색, 붉은색, 노란색, 초록색 박스가 각각 이 네 단계입니다.
추론 에이전트(Inference Agent): 스킬은 주고 위키는 막는다
반복 k 에서 추론 에이전트 \pi 는 활성 스킬 집합 S_{k-1} 을 조건으로 받아 환경 도구 \mathcal{U} 를 사용하며 다중 턴 궤적 \tau_i \sim \pi(x_i; S_{k-1}) 을 실행합니다.
여기서 WikiSkill은 활성 스킬의 전체 내용을 추론 에이전트의 시스템 프롬프트에 직접 주입합니다. 선행 연구를 따른 이 전면 주입(full-injection) 설정은 절차 지시가 작업 수행 중에 즉시 사용 가능하도록 보장하며, 그 결과 스킬 트리거링이나 검색 실패가 연구의 교란 변수로 끼어드는 것을 막습니다. 다시 말해 이 논문은 "좋은 스킬을 만드는 문제"만 다루고 "필요한 스킬을 골라 오는 문제"는 의도적으로 제외합니다. 후자는 SkillComposer처럼 스킬 조합과 검색을 정면으로 다루는 별도 연구의 영역입니다.
학습 롤아웃 동안 추론 에이전트는 위키 계층에 접근하지 못하도록 차단됩니다. 왜 그렇게 했는지는 뒤의 제거 연구(ablation study)에서 수치로 확인하겠습니다.
위키 관리자(Wiki Maintainer): 궤적을 패턴으로 압축
반복 k 에서 학습 분할 롤아웃 궤적 \mathcal{T}_{\text{train},k} 를 얻은 뒤, 컨텍스트 윈도우 한계를 피하기 위해 성공과 실패 궤적의 부분집합 \mathcal{T}_{\text{sample},k} 를 샘플링합니다. 구체적인 예산은 반복당 최대 8개 궤적이고, 오류의 근본 원인 분석을 위한 실패 궤적 최대 5개와 효과적인 전략을 확인하고 잘 동작하던 행동의 퇴행을 막기 위한 성공 궤적 최대 3개로 층화(stratified)합니다. 개별 실행 로그는 프롬프트에 주입되기 전에 15,000자로 잘립니다.
위키 관리자 에이전트 \mathcal{M}_{\text{WM}} 는 기존 위키 W_{k-1} 전체와 샘플링된 궤적을 함께 받아 중간 위키 상태 W'_k 를 만들어냅니다. 실패한 작업에는 근본 원인 분석을 수행하고, 통과한 작업에서는 성공 전략을 추출합니다. 매 반복마다 wiki/patterns/ 아래에 새 패턴 페이지를 만들거나 기존 페이지를 새로운 증거와 개선된 해법으로 갱신할 수 있습니다.
기존 페이지 갱신에는 증분 패치 방식을 씁니다. 논문 부록에 실린 위키 관리자 시스템 프롬프트를 보면 편집 연산이 세 가지로 정해져 있습니다.
| 연산 | 동작 |
|---|---|
append |
문서 끝에 새 증거를 덧붙입니다 |
replace |
기존 텍스트를 정확히 찾아 수정하거나 다듬습니다 |
insert_after |
지정한 줄 뒤에 새 항목을 삽입합니다 |
같은 프롬프트에는 패턴 문서 작성 규칙도 명시되어 있습니다. 각 패턴 페이지는 패턴이 무엇인지에 대한 설명, 왜 그런 일이 벌어지는지에 대한 근본 원인 분석, 궤적에서 가져온 정확한 명령 시퀀스, 그리고 구체적인 문법까지 포함한 알려진 해법을 담아야 합니다. 분량은 에세이가 아니라 10줄에서 30줄 사이로 제한되고, 중복 패턴을 만들지 말고 기존 패턴을 새 증거로 갱신하라는 지시도 함께 명시되어 있습니다.
연구팀이 시스템 프롬프트에서 가장 중요하다고 표시한 부분은 index.md의 항목 설명입니다. 색인 항목이 에이전트가 전체 패턴 페이지를 읽을지 말지를 결정하기 때문입니다. 그래서 항목 하나의 형식까지 프롬프트에 정해 두었습니다.
- [pattern-name](wiki/patterns/pattern-name.md): PROBLEM + ROOT CAUSE + FIX in one or two sentence.
문제, 근본 원인, 해법을 모두 담아 한두 문장으로 적되, 전체 페이지를 읽지 않고도 관련성을 판단할 수 있을 만큼 구체적이어야 한다는 요구입니다. 반복당 생성하거나 갱신할 패턴의 개수에는 상한이 없고, 위키 관리자가 궤적과 현재 위키 상태를 보고 어떤 갱신이 타당한지 스스로 판단합니다.
스킬 제안자(Skill Proposer): 필요한 것만 골라 읽는다
제안자 \mathcal{M}_{\text{P}} 는 스킬 발견과 개선을 담당하는 LLM 기반 에이전트이며, 다중 턴 ReAct 방식으로 동작합니다.
긴 실행 이력을 분석할 때 컨텍스트가 고갈되는 것을 피하기 위해, 제안자에게는 미리 샘플링된 궤적 묶음을 통째로 주지 않습니다. 대신 처음에는 위키 색인 I(W'_k) , 과거 스킬 영향 추적 기록(skill-impact.md), 그리고 모든 학습 작업 결과의 간결한 요약(통과 및 실패 여부, 예측값과 정답)만 제공합니다. 그 다음부터는 자율 에이전트로서 스스로 추론하고 read_file 도구를 사용해 특정 패턴 페이지와 원시 실행 궤적을 필요할 때 골라서 열어 봅니다.
이 설계는 스킬 형식의 점진적 공개 원리를 최적화 루프 자체에 적용한 셈입니다. 색인을 먼저 보고 무엇을 읽을지 정하는 구조라, 궤적이 길어져도 제안자의 컨텍스트가 선형으로 부풀지 않습니다.
매 반복에서 스킬 제안자는 하나의 스킬만 겨냥하는 원자적 제안 P_k 를 내놓습니다. 새 스킬을 만들거나, 지목한 기존 스킬에 증분 패치 편집을 적용하는 것 중 하나입니다. 논문 부록의 시스템 프롬프트를 보면 세 번째 선택지도 있습니다. 제안자는 {"action": "no_action"} 을 반환해 이번 반복에는 아무것도 바꾸지 않겠다고 결정할 수 있습니다.
같은 프롬프트에는 제안자가 지켜야 할 규칙도 몇 가지 명시되어 있습니다. 먼저 wiki/index.md와 wiki/skill-impact.md를 읽어 이미 시도되어 거절된 접근을 반복하지 말아야 하고(skill-impact.md에는 거절된 제안의 전체 내용이 들어 있습니다), 스킬 변경을 제안하기 전에 실행 궤적을 최소 4개 이상 읽어야 하며, 기존 스킬이 부분적으로라도 맞다면 새로 만들기보다 패치하는 쪽을 선호해야 합니다. 위키 관리자가 미리 골라진 최대 8개의 표본 궤적을 받는 것과 달리, 제안자는 무엇을 읽을지 스스로 정하되 하한선이 걸려 있는 셈입니다.
제안자가 만들어야 하는 산출물의 구조도 정해져 있습니다. 새 스킬을 만들 때 SKILL.md는 YAML 프론트매터에 이어 언제 적용하는지(When to Apply), 언제 적용하지 않는지(When NOT to Apply), 그리고 지시문을 담아야 하고, PURPOSE.md는 이 스킬이 어디서 나왔는지(Origin), 어떤 패턴을 해결하는지(Patterns Addressed), 그리고 진화 이력(Evolution History)을 담아야 합니다. 적용 조건뿐 아니라 적용하지 않을 조건까지 요구한다는 점이 눈에 띕니다.
게이팅과 롤백: 스킬은 되돌리고 위키는 남긴다
제안 P_k 가 생성되면 작업 공간에 적용해 후보 스킬 집합 S'_k 를 얻습니다. 시스템은 이 후보를 검증 분할에서 평가하고, 다음 규칙으로 수락 여부를 결정합니다.
수락되면 후보 스킬이 새 활성 집합이 되고 기준 점수 \mathcal{R}_{\text{best}} 가 갱신됩니다. 이 기준값은 진화 루프 이전에 빈 스킬 집합 S_0 를 검증 분할에서 평가한 점수로 초기화됩니다. 검증 점수가 진화 도중 최대값 \mathcal{R}_{\text{best}} = 1.0 에 도달하면 루프는 조기 종료합니다. 거절되면 후보 수정을 버리고 가장 최근의 성공 구성 S_{k-1} 으로 되돌립니다.
여기가 이 논문의 이름값을 하는 대목입니다. 수락 여부와 무관하게 위키 W_k 는 결코 롤백되지 않습니다. 누적된 패턴과 로그는 모든 반복에 걸쳐 남아 장기 지식 보존을 보장합니다. 그리고 검증 평가가 끝날 때마다 외부 루프 오케스트레이션 하니스가 wiki/skill-impact.md에 항목을 프로그램적으로 덧붙이는데, 여기에는 제안 메타데이터, 대상 스킬 이름, 수정 사항의 통합 diff, 검증 점수, 그리고 최종 수락 결과 a_k \in \{\text{Accepted}, \text{Rejected}\} 가 기록됩니다.
즉 스킬 계층에서 지워진 실패한 시도가 위키 계층에는 객관적인 감사 추적(audit trail)으로 남습니다. 스킬 제안자는 이후 반복에서 이 기록을 참고해 실패한 수정을 반복하지 않습니다. 위키가 관측한 증거를 모으는 자리라면, skill-impact.md는 그 증거로 무엇을 시도했고 어떻게 판정됐는지를 모으는 자리입니다.
실험 설계
WikiSkill은 서로 성격이 다른 5개 벤치마크에서 평가되었습니다. 각 벤치마크의 분할 크기와 사용 가능한 도구는 아래와 같습니다.
| 벤치마크 | 상호작용 | 학습 | 검증 | 테스트 | 환경 도구 |
|---|---|---|---|---|---|
| LiveMath | 단일 단계 | 35 | 18 | 124 | 없음(직접 추론) |
| SealQA | 다단계 | 16 | 10 | 85 | web_search, read_file |
| SpreadSheet | 다단계 | 80 | 40 | 280 | bash |
| OfficeQA | 다단계 | 50 | 24 | 172 | glob, grep, read |
| ALFWorld | 다단계 | 39 | 18 | 134 | 시뮬레이터 허용 행동 |
각 벤치마크가 무엇을 측정하는지 순서대로 보겠습니다.
- LiveMathematicianBench(LiveMath)는 최근 몇 달 사이의 수학 경시 문제를 객관식으로 구성한 벤치마크로, 복잡한 수학적 추론과 한정사, 극값 조건 처리 능력을 시험합니다.
- SealQA는 여러 주제에 걸친 학술적 질문으로 이루어진 사실 질의응답 벤치마크입니다. 효과적인 검색 질의를 세우고 웹 검색 결과에서 답을 추출하는 능력을 평가하며, 실험에는 2026년 7월 버전이 사용되었습니다.
- SpreadsheetBench(SpreadSheet)는 수식 평가 제약 같은 라이브러리 제한 아래에서 올바른 코드를 작성하고 복잡한 표 변환을 실행하는 능력을 시험합니다.
- OfficeQA는 대규모 재무부 회보 저장소에 대한 긴 컨텍스트 질의응답입니다. 긴 문맥과 여러 페이지에 걸친 재무 표를 가로질러 근거를 종합해야 합니다. 에이전트에게는 미리 파싱된 오라클 참조 페이지가 초기 문서 증거로 프롬프트에 주어지고, 동시에 디스크의 회보 파일 전체를 검색하고 대조할 수 있는 로컬 텍스트 처리 도구가 제공됩니다.
- ALFWorld는 텍스트 기반 체화(embodied) 환경입니다. 에이전트가 시뮬레이터에 텍스트 행동을 출력해 물건을 집어 옮기거나 데우고 식히는 등의 다단계 가사 작업을 해결합니다. 정적인 질의응답 벤치마크와 달리 순차적 의사결정, 공간 추론, 시뮬레이터 피드백을 통한 오류 복구를 시험합니다.
모델은 개방형 가중치와 폐쇄형을 함께 사용했습니다. 폐쇄형으로는 Gemini-3.5-Flash를, 개방형 가중치로는 Qwen-3.5-4B/9B-Instruct, Qwen-3.6-27B, Gemma-4-31B-It를 사용했고 개방형 모델은 vLLM으로 서빙했습니다.
평가의 신뢰도를 위해 두 가지 장치가 들어갔습니다. 첫째, 벤치마크 검증 분할이 상대적으로 작아 게이팅 결정에 평가 잡음이 섞일 수 있으므로, 보고된 모든 점수는 전체 진화 파이프라인을 독립적으로 3회 반복한 결과의 평균입니다. 둘째, 성능 차이의 통계적 유의성은 1,000회 반복 짝지은 부트스트랩 검정으로 p < 0.05 수준에서 평가했습니다. 벤치마크를 가로지르는 종합 성능은 벤치마크마다 동일한 가중치를 주는 층화 매크로 평균 재표집으로 계산했습니다.
한 가지 유의할 점이 있습니다. 공정한 비교를 위해 모든 스킬 진화 방법은 빈 스킬 집합에서 출발하며, 진화된 스킬은 추론 시점에 추론 에이전트의 프롬프트에 주입됩니다.
실험 결과
Google Research 연구팀이 자체적으로 측정해 공개한 주요 결과는 다음과 같습니다. 모든 수치는 3회 독립 실행의 평균 테스트 성능(%)입니다.
| 모델 | 방법 | LiveMath | SealQA | SpreadSheet | OfficeQA | ALFWorld | 평균 |
|---|---|---|---|---|---|---|---|
| Qwen-3.5-4B | No skill | 29.1 | 32.5 | 14.6 | 30.2 | 24.4 | 26.2 |
| Qwen-3.5-4B | Trace2Skill | 31.5 | 37.6 | 17.5 | 31.0 | 42.8 | 32.1 |
| Qwen-3.5-4B | EvoSkill | 41.7 | 37.3 | 18.6 | 29.5 | 41.5 | 33.7 |
| Qwen-3.5-4B | SkillOpt | 48.7 | 33.3 | 14.0 | 34.5 | 45.3 | 35.2 |
| Qwen-3.5-4B | WikiSkill | 49.7 | 39.4 | 21.1 | 28.5 | 53.7 | 38.5 |
| Qwen-3.5-9B | No skill | 28.2 | 26.3 | 24.3 | 35.9 | 34.7 | 29.9 |
| Qwen-3.5-9B | Trace2Skill | 33.1 | 36.9 | 26.5 | 38.4 | 48.8 | 36.7 |
| Qwen-3.5-9B | EvoSkill | 58.1 | 34.5 | 35.4 | 34.9 | 48.5 | 42.3 |
| Qwen-3.5-9B | SkillOpt | 48.7 | 29.4 | 29.0 | 38.0 | 55.7 | 40.2 |
| Qwen-3.5-9B | WikiSkill | 56.3 | 43.1 | 33.6 | 40.5 | 63.4 | 47.4 |
| Qwen-3.6-27B | No skill | 33.9 | 27.5 | 40.8 | 42.1 | 52.8 | 39.4 |
| Qwen-3.6-27B | Trace2Skill | 36.3 | 37.3 | 53.3 | 54.3 | 55.5 | 47.3 |
| Qwen-3.6-27B | EvoSkill | 57.3 | 32.9 | 59.5 | 52.5 | 64.2 | 53.3 |
| Qwen-3.6-27B | SkillOpt | 51.9 | 34.5 | 53.2 | 54.8 | 59.2 | 50.7 |
| Qwen-3.6-27B | WikiSkill | 61.9 | 41.6 | 81.7 | 53.7 | 77.6 | 63.3 |
| Gemma-4-31B | No skill | 33.9 | 30.6 | 48.3 | 43.3 | 50.4 | 41.3 |
| Gemma-4-31B | Trace2Skill | 32.3 | 37.7 | 58.5 | 43.2 | 57.2 | 45.8 |
| Gemma-4-31B | EvoSkill | 29.8 | 38.4 | 56.4 | 39.9 | 52.6 | 43.4 |
| Gemma-4-31B | SkillOpt | 40.1 | 36.1 | 63.1 | 44.4 | 61.9 | 49.1 |
| Gemma-4-31B | WikiSkill | 56.7 | 41.2 | 68.0 | 44.2 | 64.4 | 54.9 |
| Gemini-3.5-Flash | No skill | 33.0 | 29.4 | 50.5 | 48.6 | 85.9 | 49.5 |
| Gemini-3.5-Flash | Trace2Skill | 41.9 | 44.3 | 56.0 | 50.0 | 85.9 | 55.6 |
| Gemini-3.5-Flash | EvoSkill | 44.6 | 43.6 | 55.4 | 51.2 | 85.9 | 56.1 |
| Gemini-3.5-Flash | SkillOpt | 49.7 | 28.2 | 66.1 | 49.8 | 85.9 | 55.9 |
| Gemini-3.5-Flash | WikiSkill | 72.6 | 44.7 | 76.6 | 60.7 | 85.9 | 68.1 |
위 표를 통해 3가지를 알아볼 수 있습니다.
첫째, WikiSkill은 5개 모델 전부에서 가장 높은 평균 성능을 기록했습니다. 각 모델에서 가장 강한 경쟁 방법과 비교하면 Qwen-3.5-4B에서 3.3 점, Qwen-3.5-9B에서 5.1 점, Qwen-3.6-27B에서 10.0 점, Gemma-4-31B에서 5.8 점, Gemini-3.5-Flash에서 12.0 점 앞섰습니다. 다만 가장 작은 Qwen-3.5-4B에서는 이 3.3 점 차이가 부트스트랩 검정을 통과하지 못해, 논문 표에서 SkillOpt의 평균도 WikiSkill과 함께 최상위 그룹으로 표시되어 있습니다. 나머지 네 모델의 평균에서는 WikiSkill이 단독 최상위입니다.
둘째, 개선의 폭이 상당한 경우가 있습니다. Gemini-3.5-Flash는 LiveMath에서 33.0\% 에서 72.6\% 로, SpreadSheet에서 50.5\% 에서 76.6\% 로 올랐고, Qwen-3.6-27B는 ALFWorld에서 52.8\% 에서 77.6\% 로 상승했습니다.
셋째, 기존 방법들은 일관성이 떨어집니다. EvoSkill은 Qwen-3.5-9B의 LiveMath 성능을 28.2\% 에서 58.1\% 로 크게 올렸지만 같은 벤치마크에서 Gemma-4-31B는 33.9\% 에서 29.8\% 로 떨어뜨렸고, SkillOpt는 Gemini-3.5-Flash의 SealQA 성능을 29.4\% 에서 28.2\% 로 떨어뜨렸습니다.
다만 평균 열만 보면 드러나지 않는 부분이 있어 개별 칸도 확인해 볼 필요가 있습니다. 25개 모델-벤치마크 조합 중 WikiSkill이 가장 높은 칸은 19개이고, 1개는 동점이며, 5개 칸에서는 다른 방법이 더 높았습니다. 진 5개 칸은 Qwen-3.5-4B의 OfficeQA(SkillOpt 34.5\% 대 WikiSkill 28.5\% ), Qwen-3.5-9B의 LiveMath(EvoSkill 58.1\% 대 56.3\% )와 SpreadSheet(EvoSkill 35.4\% 대 33.6\% ), Qwen-3.6-27B의 OfficeQA(SkillOpt 54.8\% 대 53.7\% ), Gemma-4-31B의 OfficeQA(SkillOpt 44.4\% 대 44.2\% )입니다. 5개 중 3개가 OfficeQA에 몰려 있습니다. 그리고 스킬이 없을 때보다 오히려 낮아진 칸은 Qwen-3.5-4B의 OfficeQA(30.2\% 에서 28.5\% ) 한 곳입니다.
점수가 뒤졌다고 해서 모두 유의한 패배는 아닙니다. 논문 표는 부트스트랩 검정에서 최상위와 구분되지 않는 방법들을 함께 굵은 글씨로 묶어 표시하는데, 위 5개 칸 중 Qwen-3.5-9B의 LiveMath와 SpreadSheet, Qwen-3.6-27B의 OfficeQA 세 칸에서는 WikiSkill도 그 최상위 그룹에 함께 들어 있어, 점수 차이가 통계적으로 구분되지 않았습니다. 한편 어느 방법도 굵은 글씨로 표시되지 않은 칸이 4개 있고 그중 3개가 OfficeQA입니다. 여기에 네 방법이 한꺼번에 최상위 그룹으로 묶인 Qwen-3.6-27B의 OfficeQA까지 더하면, OfficeQA 5개 칸 중 4개에서는 어느 방법이 낫다고 가릴 수 없었습니다. 단독 최상위가 나온 것은 WikiSkill이 60.7\% 를 기록한 Gemini-3.5-Flash 한 칸뿐입니다.
Gemini-3.5-Flash의 ALFWorld 점수가 모든 방법에서 85.9\% 로 같은 것은 우연이 아닙니다. 이 모델이 스킬 진화 이전에 검증 분할에서 이미 100\% 를 달성해 진화 루프가 조기 종료되었기 때문입니다.
스킬 진화는 모델 스케일과 상보적이다
위 그래프는 Gemma-4-31B를 제외한 4개 모델을 능력 순으로 놓고, 스킬 없음과 EvoSkill, SkillOpt, WikiSkill의 평균 정확도를 이은 것입니다. 노란색 WikiSkill 선과 나머지 선의 간격이 오른쪽으로 갈수록 벌어지는 것이 눈에 띕니다.
Qwen 계열 안에서 WikiSkill의 평균 개선폭은 모델 크기와 함께 커집니다. Qwen-3.5-4B가 +12.3 점, Qwen-3.5-9B가 +17.5 점, Qwen-3.6-27B가 +23.9 점입니다. 이 경향은 SpreadSheet에서 특히 두드러져 세 모델의 개선폭이 각각 +6.5 , +9.3 , +40.9 점으로 나타납니다.
그런데 동시에 진화된 스킬은 모델 규모의 격차를 상당 부분 메울 수 있었습니다. WikiSkill을 적용한 Qwen-3.5-9B는 평균 정확도 47.4\% 로, 스킬 없는 Qwen-3.6-27B의 39.4\% 를 앞섭니다. 여기서 나오는 해석은 모델 능력과 진화된 절차 지식이 서로를 대체하는 관계가 아니라는 것입니다. 더 강한 모델은 더 효과적인 스킬을 만들고 실행할 수 있어 스킬 진화에서 더 큰 가치를 얻고, 반대로 효과적인 스킬은 작은 모델이 스킬 없는 훨씬 큰 모델을 앞서게 해 줍니다.
벤치마크마다 이득의 크기가 다르다
어떤 데이터셋은 다른 데이터셋보다 스킬 진화에 잘 반응합니다. Qwen-3.6-27B를 기준으로 보면 OfficeQA에서 11.6 점, SealQA에서 14.1 점 오른 반면 ALFWorld에서 24.8 점, LiveMath에서 28.0 점, SpreadSheet에서 40.9 점 올랐습니다. LiveMath는 다섯 모델 모두에서 20.6 점에서 39.6 점 사이의 이득을 일관되게 보였고, ALFWorld는 스킬이 진화된 네 모델에서 14.0 점에서 29.3 점 사이의 이득을 보였습니다.
문제는 OfficeQA입니다. 긴 컨텍스트 문서 검색이라는 요구 조건이 다른 성격의 어려움을 만듭니다. 큰 모델은 진화된 검색 작업 흐름을 활용해 긴 문서를 잘 탐색합니다(Qwen-3.6-27B가 +11.6 점, Gemini-3.5-Flash가 +12.1 점). 반면 Qwen-3.5-4B는 긴 컨텍스트에서 다단계 검색 작업 흐름을 실행하지 못하고 기본 읽기 방식으로 되돌아가 버려, 오히려 성능이 소폭 하락했습니다. 스킬이 효과를 내려면 그 스킬이 지시하는 절차를 끝까지 실행할 수 있는 능력이 먼저 필요합니다.
스킬은 모델을 건너뛴다: 교차 모델 전이
지금까지는 한 모델이 자기 경험으로 자기 스킬을 만든 경우였습니다. 그렇다면 A 모델이 만든 스킬을 B 모델에게 주면 어떻게 될까요? 연구팀은 서로 다른 원천 모델(source model)로 진화시킨 WikiSkill 스킬을 다른 추론 모델에 주입해 측정했습니다.
| 추론 모델 | 스킬 원천 | LiveMath | SealQA | SpreadSheet | OfficeQA | ALFWorld |
|---|---|---|---|---|---|---|
| Qwen-3.5-4B | 없음 | 29.1 | 32.5 | 14.6 | 30.2 | 24.4 |
| Qwen-3.5-4B | Qwen-3.5-4B(자기 자신) | 49.7 | 39.4 | 21.1 | 28.5 | 53.7 |
| Qwen-3.5-4B | Qwen-3.6-27B | 59.7 | 38.8 | 33.0 | 25.4 | 57.0 |
| Qwen-3.5-4B | Gemini-3.5-Flash | 62.6 | 37.3 | 23.0 | 32.2 | - |
| Qwen-3.5-9B | 없음 | 28.2 | 26.3 | 24.3 | 35.9 | 34.7 |
| Qwen-3.5-9B | Qwen-3.5-4B | 61.0 | 40.4 | 25.0 | 40.3 | 69.2 |
| Qwen-3.5-9B | Qwen-3.5-9B(자기 자신) | 56.3 | 43.1 | 33.6 | 40.5 | 63.4 |
| Qwen-3.5-9B | Qwen-3.6-27B | 59.1 | 40.4 | 50.5 | 39.9 | 70.2 |
| Qwen-3.5-9B | Gemini-3.5-Flash | 53.0 | 39.6 | 48.8 | 40.5 | - |
| Qwen-3.6-27B | 없음 | 33.9 | 27.5 | 40.8 | 42.1 | 52.8 |
| Qwen-3.6-27B | Qwen-3.5-4B | 62.6 | 41.6 | 40.6 | 52.9 | 72.1 |
| Qwen-3.6-27B | Qwen-3.6-27B(자기 자신) | 61.9 | 41.6 | 81.7 | 53.7 | 77.6 |
| Qwen-3.6-27B | Gemini-3.5-Flash | 65.1 | 51.0 | 76.0 | 52.5 | - |
| Gemma-4-31B | 없음 | 33.9 | 30.6 | 48.3 | 43.3 | 50.4 |
| Gemma-4-31B | Qwen-3.5-4B | 73.1 | 38.8 | 37.1 | 42.1 | 66.9 |
| Gemma-4-31B | Qwen-3.6-27B | 73.7 | 37.7 | 72.0 | 44.2 | 66.9 |
| Gemma-4-31B | Gemma-4-31B(자기 자신) | 56.7 | 41.2 | 68.0 | 44.2 | 64.4 |
| Gemma-4-31B | Gemini-3.5-Flash | 61.8 | 37.7 | 68.8 | 43.4 | - |
| Gemini-3.5-Flash | 없음 | 33.0 | 29.4 | 50.5 | 48.6 | 85.9 |
| Gemini-3.5-Flash | Qwen-3.5-4B | 67.5 | 40.0 | 18.1 | 48.5 | 87.3 |
| Gemini-3.5-Flash | Qwen-3.6-27B | 73.9 | 43.5 | 63.4 | 47.7 | 86.8 |
| Gemini-3.5-Flash | Gemini-3.5-Flash(자기 자신) | 72.6 | 44.7 | 76.6 | 60.7 | - |
- 표시는 원천 모델이 스킬 진화 전에 이미 검증 성능 100\% 에 도달해 스킬이 진화되지 않은 경우입니다.
측정 결과, 전이된 스킬은 스킬 없는 기준선뿐 아니라 자기가 만든 스킬보다 나은 경우가 자주 있었습니다. Qwen-3.6-27B의 스킬은 Qwen-3.5-9B의 SpreadSheet 성능을 50.5\% 로 끌어올려, 스킬 없는 24.3\% 와 자기가 만든 스킬의 33.6\% 를 모두 앞섰습니다. 같은 원천 스킬은 Gemma-4-31B의 LiveMath 성능을 73.7\% 로 올려, 33.9\% 와 56.7\% 를 각각 앞섰습니다.
LiveMath는 특히 전이가 잘 되는 벤치마크입니다. Qwen-3.5-4B와 Qwen-3.6-27B가 만든 스킬은 Gemini-3.5-Flash의 LiveMath 성능을 33.0\% 에서 각각 67.5\% 와 73.9\% 로 올렸는데, 뒤쪽 수치는 Gemini-3.5-Flash가 자기 경험으로 만든 스킬의 72.6\% 보다도 높습니다.
위 표 전체를 놓고 세어 보면 이 경향이 더 분명해집니다. 자기가 만든 스킬이 존재하는 24개 칸 중 그 스킬이 단독으로 가장 높은 칸은 9개뿐이고, 2개는 공동 최고이며, 나머지 13개 칸에서는 다른 모델이 만든 스킬이 더 높은 점수를 냈습니다.
주목할 것은 작은 모델에서 큰 모델로 가는 전이도 성립한다는 점입니다. Qwen-3.5-4B가 만든 스킬이 Gemma-4-31B의 LiveMath 성능을 73.1\% , ALFWorld 성능을 66.9\% 로 올렸습니다. 연구팀은 더 강한 원천 모델이 반드시 더 좋은 스킬을 만드는 것은 아니며, 한 모델의 경험에서 만들어진 절차 지식이 모델 규모와 계열을 가로질러 전이될 수 있다고 정리하였습니다.
전이가 성공하는 스킬과 실패하는 스킬
그렇다면 언제 전이가 깨질까요? 위 표에서 가장 극적인 칸은 Gemini-3.5-Flash의 SpreadSheet 행입니다. Qwen-3.5-4B가 만든 스킬을 주입하자 성능이 50.5\% 에서 18.1\% 로 떨어졌습니다. 같은 자리에 Qwen-3.6-27B의 스킬을 주입하면 63.4\% 로 올라가므로, 원천과 대상의 조합에 따라 결과가 크게 달라진다는 것을 알 수 있습니다.
연구팀의 오류 분석은 이 음의 전이(negative transfer)를 두 가지 요인으로 설명합니다. 첫째, Qwen-3.5-4B의 스킬은 한 줄짜리 Python 명령이나 문자열 변환 규칙 같은 저수준 우회책을 담고 있습니다. 이런 우회책은 작은 모델이 실행 실패를 피하는 데는 도움이 되지만, Gemini-3.5-Flash처럼 강한 모델이 포괄적인 종단 간 스크립트를 작성하는 것을 오히려 제약합니다. 둘째, 파편화된 진단 절차가 중복된 도구 호출을 유발해, Gemini-3.5-Flash가 작업을 끝내기 전에 상호작용 예산을 소진하게 만듭니다.
정리하면 WikiSkill이 만들어내는 스킬에는 두 종류가 섞여 있습니다: 모델을 가리지 않는 일반적인 절차 지식과, 특정 모델의 약점을 메우려고 만든 모델 고유의 우회책입니다. 후자를 다른 모델에 그대로 주면 도움이 되기는커녕 방해가 됩니다.
스킬을 발견하는 능력과 실행하는 능력은 다르다
같은 원천 모델의 스킬을 여러 추론 모델이 받으면 어떻게 될까요? Qwen 계열 안에서는 더 강한 모델이 같은 절차 지식에서 더 큰 가치를 얻습니다. Qwen-3.6-27B의 SpreadSheet 스킬은 Qwen-3.5-4B, Qwen-3.5-9B, Qwen-3.6-27B의 스킬 없는 기준선 대비 각각 18.4 점, 26.2 점, 40.9 점을 올렸습니다.
OfficeQA에서는 더 흥미로운 사례가 나옵니다. Qwen-3.5-4B가 만든 스킬은 자기 성능은 30.2\% 에서 28.5\% 로 떨어뜨리면서, Qwen-3.6-27B의 성능은 42.1\% 에서 52.9\% 로 올렸습니다. 자기가 발견해 놓고 자기는 못 쓰는 지식인 셈입니다. 연구팀의 궤적 분석에 따르면 긴 컨텍스트 환경에서 작은 모델은 방대한 문서 문맥에 주의를 빼앗겨 세밀한 다단계 검색 지시를 따르지 못하고 기본 문서 읽기 행동으로 되돌아갑니다. 반면 강한 모델은 스킬이 지정한 구조화된 탐색 절차를 긴 컨텍스트에서도 더 안정적으로 실행합니다.
이 결과가 구분해 내는 것은 자기 진화가 보통 하나로 뭉뚱그리는 두 가지 능력입니다: 경험에서 유용한 절차 지식을 발견하는 능력과, 추론 시점에 그 지식을 효과적으로 실행하는 능력입니다. 두 능력이 분리된다면 스킬을 만드는 모델과 스킬을 쓰는 모델을 따로 고르는 운영 방식도 가능해집니다.
영속 지식이 정말 기여하는가
지금까지 WikiSkill이 잘 동작한다는 것은 확인했지만, 그 성능이 정말 위키 계층에서 나온 것인지는 아직 확인하지 않았습니다. 연구팀은 Gemini-3.5-Flash를 사용해, 진화 과정에서 위키를 사용할 수 있는 두 구성요소의 위키 접근 권한을 독립적으로 바꿔 가며 네 가지 설정을 비교했습니다. 스킬 제안자가 위키에 접근하지 못하는 설정에서는 위키 관리자도 함께 제거해, 반복을 가로지르는 영속 지식 축적 자체를 없앴습니다.
| 설정 | 추론 에이전트 위키 접근 | 스킬 제안자 위키 접근 | LiveMath | SealQA | SpreadSheet | OfficeQA | 평균 |
|---|---|---|---|---|---|---|---|
| 스킬 없음(기준선) | 해당 없음 | 해당 없음 | 33.0 | 29.4 | 50.5 | 48.6 | 40.4 |
| 위키 관리자 제거 | 있음 | 없음 | 43.8 | 42.0 | 44.4 | 51.0 | 45.3 |
| 위키 관리자 제거 | 없음 | 없음 | 51.3 | 38.4 | 49.9 | 55.2 | 48.7 |
| 양쪽 모두 접근 | 있음 | 있음 | 64.8 | 42.8 | 80.2 | 55.6 | 60.9 |
| WikiSkill 기본 설정 | 없음 | 있음 | 72.6 | 44.7 | 76.6 | 60.7 | 63.7 |
가장 큰 차이를 만드는 것은 스킬 제안자의 위키 접근입니다. 제안자가 위키를 볼 수 없는 두 설정은 평균 45.3\% 와 48.7\% 에 그쳐, 기본 설정 63.7\% 보다 각각 18.4 점과 15.0 점 낮습니다. 영속 지식 축적이 스킬 진화의 성능을 실제로 좌우한다는 것을 보여주는 수치입니다.
두 번째로 눈에 띄는 것은 추론 에이전트에게 위키를 열어 준 설정이 오히려 손해라는 점입니다. 스킬 제안자가 영속 위키에 접근할 수 있을 때, 학습 롤아웃 동안 추론 에이전트에게도 위키 접근을 허용하면 평균 성능이 63.7\% 에서 60.9\% 로 떨어지고 LiveMath에서는 72.6\% 에서 64.8\% 로 크게 하락합니다. 연구팀의 가설은 이렇습니다. 학습 롤아웃 중 추론 에이전트가 스킬과 위키를 모두 볼 수 있으면 작업 해결에 필요한 지식 일부를 스킬이 아니라 위키에서 직접 얻게 되고, 그 결과 만들어지는 궤적이 스킬 개발에 필요한 정보를 덜 담게 된다는 것입니다.
바꿔 말하면 학습 롤아웃은 스킬만으로 얼마나 되는지를 재는 자리여야 합니다. 위키를 함께 열어 주면 그 측정이 오염됩니다. 다만 SpreadSheet만은 예외로, 양쪽 모두 위키에 접근한 설정이 80.2\% 로 기본 설정 76.6\% 보다 높았습니다.
스킬과 위키는 어떻게 자라는가
진화 과정에서 실제로 무엇이 얼마나 만들어지는지도 흥미로운 부분입니다. 아래는 스킬과 위키 패턴의 생성 및 편집 통계로, 위쪽 5행은 모든 벤치마크를 평균한 모델별 수치이고 아래쪽 5행은 모든 모델을 평균한 벤치마크별 수치입니다.
| 구분 | 스킬 생성(제안/수락) | 스킬 편집(제안/수락) | 스킬 평균 길이(줄) | 위키 패턴 생성 | 위키 패턴 편집 | 패턴 평균 길이(줄) |
|---|---|---|---|---|---|---|
| Qwen-3.5-4B | 3.1 / 1.6 | 4.9 / 1.3 | 126.2 | 8.8 | 18.4 | 48.2 |
| Qwen-3.5-9B | 4.6 / 1.4 | 3.4 / 0.7 | 128.6 | 7.3 | 10.9 | 26.6 |
| Qwen-3.6-27B | 4.4 / 1.5 | 3.6 / 0.8 | 118.9 | 6.5 | 17.9 | 47.7 |
| Gemma-4-31B | 4.8 / 1.3 | 3.2 / 0.8 | 45.1 | 6.3 | 13.7 | 23.7 |
| Gemini-3.5-Flash | 2.3 / 1.2 | 5.7 / 1.1 | 81.2 | 8.9 | 7.0 | 18.1 |
| LiveMath | 1.9 / 1.1 | 6.1 / 1.9 | 84.6 | 4.4 | 12.1 | 31.7 |
| SealQA | 4.9 / 0.9 | 3.1 / 0.4 | 98.5 | 9.4 | 15.9 | 26.9 |
| SpreadSheet | 4.5 / 1.4 | 3.5 / 1.1 | 142.5 | 9.8 | 11.3 | 38.5 |
| OfficeQA | 4.7 / 1.8 | 3.3 / 0.3 | 102.9 | 8.3 | 14.9 | 31.4 |
| ALFWorld | 3.9 / 1.6 | 4.1 / 0.8 | 93.5 | 5.8 | 14.3 | 40.6 |
모델별로 보면 Qwen 계열이 118.9줄에서 128.6줄에 이르는 긴 절차 스킬을 만드는 반면 Gemma-4-31B와 Gemini-3.5-Flash는 각각 45.1줄, 81.2줄의 더 압축된 스킬을 만듭니다. 위키 패턴 축적도 모델마다 달라, 평균 6.3개에서 8.9개의 패턴이 생성되고 7.0회에서 18.4회의 편집이 이루어집니다. 벤치마크별로는 SpreadSheet가 가장 긴 스킬(142.5줄)과 가장 많은 위키 패턴(9.8개)을 만들고, LiveMath가 가장 짧은 스킬(84.6줄)과 가장 적은 위키 패턴(4.4개)을 만듭니다.
여기서 두 계층의 비대칭이 수치로 드러납니다. 스킬 쪽은 제안 대비 수락 비율이 낮습니다. SealQA에서는 평균 4.9건의 스킬 생성이 제안되어 0.9건만 수락되고, OfficeQA에서는 3.3건의 편집 제안 중 0.3건만 수락됩니다. 반면 위키 패턴의 생성과 편집은 전부 그대로 유지됩니다. 게이팅을 통과해야 남는 스킬과, 게이팅 없이 계속 쌓이는 위키가 이 프레임워크의 두 축인 셈입니다.
수락된 스킬 갱신이 언제 일어나는지도 살펴볼 만합니다. 아래 표도 위쪽 5행이 모델별, 아래쪽 5행이 벤치마크별 수치입니다.
| 구분 | 초기(반복 0~1) | 중기(반복 2~4) | 후기(반복 5~7) |
|---|---|---|---|
| Qwen-3.5-4B | 39% | 39% | 21% |
| Qwen-3.5-9B | 52% | 30% | 19% |
| Qwen-3.6-27B | 43% | 40% | 17% |
| Gemma-4-31B | 52% | 37% | 11% |
| Gemini-3.5-Flash | 50% | 46% | 4% |
| LiveMath | 44% | 42% | 14% |
| SealQA | 39% | 33% | 28% |
| SpreadSheet | 41% | 48% | 11% |
| OfficeQA | 58% | 26% | 16% |
| ALFWorld | 55% | 34% | 10% |
모델을 가로질러 초기 단계가 수락된 갱신의 39\% 에서 52\% 를 차지하고, 상당한 비율이 중기와 후기까지 이어집니다. 벤치마크에서도 39\% 에서 58\% 가 초기 단계에 일어나는 비슷한 양상이 나타납니다. 개선이 후반까지 계속되는 경향은 SealQA에서 특히 뚜렷해, 수락된 갱신의 33\% 가 중기에, 28\% 가 후기에 일어납니다. 앞의 제거 연구와 함께 놓고 보면, 영속 지식 축적이 반복을 가로지르는 지속적인 스킬 개선을 뒷받침한다는 해석이 가능합니다.
사례 연구: ALFWorld의 반복 행동 문제
논문 그림 3이 보여주는 것은 Qwen-3.6-27B가 ALFWorld에서 실제로 겪은 진화 과정입니다(발표를 위해 단순화된 내용입니다).
반복 0에서 위키 관리자는 기본적인 반복 행동을 발견해 take-examine-move-loop.md로 기록합니다. 에이전트가 물건을 집어 살펴본 뒤 도로 내려놓고 다시 집는 순환입니다. 같은 반복에서 스킬 제안자는 goal-directed-action이라는 스킬을 제안하지만, 검증 세트 성능을 개선하지 못해(검증 점수 0.72 ) 거절됩니다. 중요한 것은 skill-impact.md가 제안 diff와 거절 결과를 보존한다는 점입니다.
이 감사 추적을 참고해 스킬 제안자는 반복 1에서 break-repetition-loop을 만듭니다. 이번에는 구체적인 행동 규칙, "물건을 원래 자리로 되돌리지 말 것"을 담았고 수락됩니다(검증 점수 0.78 ). 이 스킬의 PURPOSE.md에는 이전 시도인 goal-directed-action이 너무 추상적이어서 거절되었으므로 이번 버전은 더 간결하고 구체적인 행동 패턴을 사용한다고 적혀 있습니다.
롤아웃이 계속되면서 새로운 형태의 반복 행동이 나타나자 위키 관리자는 multi-operation-loop.md에 새 증거를 축적합니다. 축적된 위키 패턴과 새로 저장된 궤적을 근거로 스킬 제안자는 반복 4에서 스킬을 한 번 더 다듬어 새 규칙, "물건마다 각 조작 유형은 한 번만"을 추가합니다.
이 사례가 잘 보여주는 것은 거절된 제안이 그냥 사라지지 않는다는 점입니다. 스킬 계층에서는 지워졌지만 위키 계층에는 "이 방향은 이미 시도했고 실패했다"는 정보로 남아, 다음 제안이 다른 방향을 찾도록 유도합니다.
최적화 비용은 얼마나 드는가
성능이 좋아도 최적화 비용이 감당하기 어렵다면 실용성이 떨어집니다. 연구팀은 진화 반복 1회당 옵티마이저 API 호출 복잡도 \mathcal{C} 를 프레임워크별로 비교했습니다. N_{\text{train}} 은 학습 작업 수, B 는 배치 크기, T_{\text{ReAct}} 는 WikiSkill 스킬 제안자가 사용하는 ReAct 추론 턴 수, K_{\text{opt}} 는 SkillOpt의 단계당 반성 및 병합 호출 수, c 는 Trace2Skill의 축약 트리 분기 계수입니다.
| 프레임워크 | 반복당 호출 수 | 복잡도 |
|---|---|---|
| Trace2Skill | N_{\text{train}} + \left(1 + \frac{1}{c-1}\right)\frac{N_{\text{train}}}{B} + 1 | \mathcal{O}\left(N_{\text{train}} + \frac{N_{\text{train}}}{B}\right) |
| EvoSkill | \frac{2N_{\text{train}}}{B} | \mathcal{O}\left(\frac{N_{\text{train}}}{B}\right) |
| SkillOpt | \frac{K_{\text{opt}} \cdot N_{\text{train}}}{B} | \mathcal{O}\left(\frac{N_{\text{train}}}{B}\right) |
| WikiSkill | (1 + T_{\text{ReAct}})\frac{N_{\text{train}}}{B} | \mathcal{O}\left(\frac{N_{\text{train}}}{B}\right) |
WikiSkill의 배치 크기당 비용은 위키 관리자의 LLM 호출 1회에, 스킬 제안자가 자율 다중 턴 ReAct 에이전트로 도는 T_{\text{ReAct}} 턴을 더한 값입니다. 각 ReAct 턴이 LLM 호출 1회에 해당하며, 실험에서 관측된 범위는 대략 10 \le T_{\text{ReAct}} \le 20 이었습니다.
주목할 것은 WikiSkill이 모든 데이터셋에서 B = N_{\text{train}} , 즉 전체 배치 모드로 동작한다는 점입니다. 이 경우 옵티마이저 호출 횟수가 학습 집합 크기와 무관해져 반복당 1 + T_{\text{ReAct}} 회로 고정됩니다. Trace2Skill이 N_{\text{train}} 에 비례하는 항을 갖는 것과 대비되는 성질입니다. 다만 이 표는 옵티마이저 호출 횟수만 세는 것이고, 각 호출이 소비하는 토큰량과 롤아웃 자체의 비용은 포함하지 않습니다.
관련 연구 속에서의 위치
WikiSkill이 무엇을 다루고 무엇을 다루지 않는지는 인접한 연구와 나란히 놓을 때 분명해집니다. 연구팀은 크게 두 갈래를 언급합니다.
첫째는 스킬 검색(skill retrieval) 입니다. 재사용 가능한 스킬이 많아질수록 작업마다 라이브러리에서 관련 스킬을 골라 오는 문제가 따로 생기고, 최근에는 이 문제를 정면으로 다루는 연구들이 나오고 있습니다. WikiSkill은 검색을 다루지 않고 스킬의 품질 자체에만 집중하며, 그래서 앞서 본 대로 활성 스킬을 프롬프트에 전부 주입합니다. PyTorchKR에는 이 갈래에 해당하는 SkillComposer 정리 글이 올라와 있습니다.
둘째는 에이전트 하네스 최적화입니다. 프롬프트, 컨텍스트, 도구, 메모리, 작업 흐름을 포함한 에이전트 시스템 전반을 실행 궤적과 환경 피드백으로 분석해 더 나은 구성을 탐색하는 연구들입니다. 연구팀은 이 방향이 WikiSkill과 경쟁하는 것이 아니라 상보적이라고 정리합니다. WikiSkill은 재사용 가능한 절차 스킬을 진화시키는 데 집중하고 나머지 하네스는 고정한 채로 둡니다. 벤치마크에서 관측된 향상이 스킬 하나에서 나온 것이라고 해석할 수 있는 근거이면서, 동시에 하네스까지 함께 최적화했을 때 어떻게 될지는 이 논문이 답하지 않는다는 뜻이기도 합니다. 이 갈래에 해당하는 글로는 HarnessX와 Meta-Harness 정리가 있습니다.
스킬 진화 자체를 다루는 인접 사례도 PyTorchKR에 정리되어 있습니다. 평가와 회귀 테스트를 게이트로 삼아 스킬을 진화시키는 darwin-skill, 그리고 스킬과 프롬프트를 함께 자동 진화시키는 Hermes Agent Self-Evolution이 그 예입니다.
한계점 및 향후 연구 방향
연구팀은 네 가지 한계를 밝히고 있습니다.
첫째, 스킬 검색과 트리거링을 평가하지 않았습니다. 스킬 품질 자체를 분리해 측정하고 검색으로 인한 교란 효과를 피하기 위해, 이 연구는 선행 연구를 따라 활성 스킬을 에이전트 프롬프트에 직접 주입했습니다. 그러나 사용 가능한 스킬의 수가 늘어나면 어떤 스킬을 언제 불러올지가 중요해집니다. 실제 운영 환경에서는 이 부분이 성능의 병목이 될 수 있으므로, 스킬 검색 연구와 결합했을 때 이 결과가 어떻게 유지되는지는 별도로 확인해야 합니다.
둘째, 검증 게이팅 기준이 엄격합니다. 현재 규칙은 수락된 제안이 반드시 검증 점수를 개선해야 한다고 요구하므로, 당장의 성능은 유지하지만 이후 반복에서 이득을 낳을 수 있는 중립적인 제안이 배제됩니다. 연구팀은 공정한 비교를 위해 선행 스킬 진화 프레임워크를 따라 이 엄격한 기준을 채택했다고 밝히면서, 더 유연한 수락 기준을 탐색하는 것이 중요한 후속 방향이라고 적고 있습니다. 앞의 통계에서 본 낮은 수락 비율을 함께 놓고 보면, 이 기준을 완화했을 때 얻을 수 있는 여지가 남아 있습니다.
셋째, 위키를 정리하는 장치가 없습니다. 위키 계층은 반복을 거치며 패턴 페이지, 진화 로그, 제안 diff를 계속 축적하는데, WikiSkill에는 현재 위키를 가지치기(pruning)하는 자동 메커니즘이 없습니다. 진화를 더 오래 돌릴수록 지식이 쌓이므로, 이런 정리 장치가 필요해질 수 있습니다. 영속성이 이 프레임워크의 강점인 만큼, 무엇을 버릴지 결정하는 일은 그만큼 조심스러운 문제이기도 합니다.
넷째, 매우 긴 호흡의 작업은 다루지 않았습니다. 벤치마크 모음에 긴 컨텍스트 문서 추론(OfficeQA)과 다단계 도구 상호작용이 포함되어 있지만, 수백 번의 환경 행동이나 여러 시간에 걸치는 초장기 작업은 포함되지 않았습니다. 하나의 긴 실행 롤아웃 안에서 절차 지식을 다듬는 온라인 스킬 적응 방법을 개발하는 것이 중요한 후속 연구 방향이라고 연구팀은 밝히고 있습니다.
논문 부록에는 추론 에이전트, 위키 관리자, 스킬 제안자 세 에이전트의 시스템 프롬프트 전문이 실려 있습니다. 다만 구현 코드 저장소는 공개되어 있지 않으므로, 직접 재현하려면 이 프롬프트와 부록의 알고리즘 의사코드를 바탕으로 구현해야 합니다.
연구팀은 AI 사용 내역도 함께 공개하였습니다. 대형 언어 모델과 코딩 에이전트가 집필을 돕고 다듬는 데 사용되었으며, 일부 표와 도표를 생성하는 데도 사용되었다고 적혀 있습니다.
결론
WikiSkill이 제안하는 구조는 단순합니다. 에이전트가 남긴 실행 기록, 그 기록에서 추출한 지식, 그리고 그 지식으로 만든 실행 가능한 절차를 서로 다른 계층으로 분리하고, 절차만 되돌릴 수 있게 하고 지식은 되돌리지 않는 것입니다. 이 단순한 분리가 5개 모델 모두의 벤치마크 평균 성능을 끌어올렸고, 제거 연구는 그 향상의 상당 부분이 지식 계층에서 나온다는 것을 보여줍니다. 개별 벤치마크로 내려가면 OfficeQA처럼 이득이 작거나 통계적으로 가려지지 않는 자리도 있습니다.
여기서 파생되는 관점도 있습니다. 스킬을 발견하는 능력과 실행하는 능력이 분리된다면, 에이전트 시스템을 설계할 때 "가장 좋은 모델 하나"를 고르는 대신 "스킬을 만드는 모델"과 "스킬을 쓰는 모델"을 따로 배치하는 선택지가 생깁니다. 작은 모델이 만든 스킬이 큰 모델의 성능을 올린 사례가 그 가능성을 보여줍니다. 물론 SpreadSheet에서 확인한 음의 전이처럼 조합에 따라 크게 손해를 보는 경우도 있으므로, 어떤 스킬이 일반적이고 어떤 스킬이 모델 고유의 우회책인지 구분하는 일이 다음 과제로 남습니다.
WikiSkill: Compiling Agent Experience into Persistent Knowledge for Skill Evolution 논문
LLM Wiki (Andrej Karpathy)
A Complete Guide to Building Skills for Claude
더 읽어보기
- SkillComposer: 스킬을 몇 개나 어떤 순서로 쓸지 한 번에 예측하는 LLM 에이전트 스킬 조합 방식에 대한 연구
- darwin-skill: 평가와 회귀 테스트로 에이전트 스킬을 진화시키는 최적화 루프
- LLM Wiki Newsroom: 신문사 편집국을 본뜬 멀티에이전트로 지식을 위키로 관리
- Hermes Agent Self-Evolution: Hermes Agent의 스킬과 프롬프트를 자동 진화시키는 NousResearch의 자가 개선 프레임워크
- HarnessX: 에이전트 하네스를 실행 트레이스로 진화시키는 연구
- Meta-Harness: Stanford IRIS Lab이 공개한, LLM 주변 실행 코드를 자동으로 최적화하는 에이전트 하네스 탐색 프레임워크에 대한 연구
이 글은 GPT 모델로 정리한 초안을 바탕으로 한 것으로, 원문의 내용 또는 의도와 다르게 정리된 내용이 있을 수 있습니다. 관심있는 내용이시라면 원문도 함께 참고해주세요! 읽으시면서 어색하거나 잘못된 내용을 발견하시면 댓글로 알려주시기를 부탁드립니다. 
논문의 주장이나 벤치마크에 대한 의견, 직접 재현해보신 결과가 있다면 
파이토치 한국 사용자 모임
회원들을 위해 댓글로 공유해주세요! 