3줄 요약
- Google Research가 2026년 8월 27일 arXiv에 올린 WikiSkill은, 에이전트 스킬을 반복 실행으로 고쳐 나가는 기존 루프 안에 영속 위키 계층을 하나 더 넣은 프레임워크다. 실행 기록, 누적 지식, 실행 가능한 스킬을 서로 다른 층에 나눠 둔다.
- WikiSkill은 다섯 모델과 다섯 벤치마크에서 기존 스킬 진화 기법 세 종을 모두 앞섰다. Qwen 계열의 평균 향상은 4B에서 12.3점, 9B에서 17.5점, 27B에서 23.9점으로, 모델이 커질수록 스킬이 주는 이득도 덩달아 커졌다.
- 진화한 스킬은 모델과 모델 계열을 건너 옮겨 갔다. 남이 만든 스킬을 빌려 쓴 쪽이 자기가 만든 스킬보다 나은 경우가 여럿 나왔다.
스킬을 고치는 법은 이미 여럿 있다
에이전트 스킬은 도메인 지식과 절차를 파일 시스템 위의 디렉토리 하나로 묶어 재사용하게 만드는 형식이다. SKILL.md 파일 하나에 이름과 설명, 전체 절차, 적용 조건을 담는다. 모델 가중치를 건드리지 않고도 전문성을 쌓아 둘 수 있고, 필요할 때만 읽어 들이는 점진적 공개가 가능하다.
문제는 그 스킬을 누가 쓰느냐다. 지금까지는 대부분 사람이 손으로 썼고, 그러려면 에이전트가 앞으로 어디서 막힐지를 미리 알아맞혀야 했다. 그래서 최근 연구들은 에이전트를 훈련 과제에 굴리고, 성공과 실패 궤적(trajectory)을 분석하고, 그 결과로 스킬을 고치는 반복 루프를 만들었다. 비교 대상은 Trace2Skill, EvoSkill, SkillOpt 세 기법이다.
| 기법 | 방식 |
|---|---|
| Trace2Skill | 궤적마다 성공 분석가와 오류 분석가를 병렬로 붙여 패치를 뽑고, 계층적 병합으로 하나의 패치 집합으로 합친다 |
| EvoSkill | 스킬 진화를 후보 프로그램 집합 위의 탐색으로 본다. 실패한 실행 기록만 제안자에게 넘기고, 과거 제안 결과는 밋밋한 목록으로 같이 준다 |
| SkillOpt | 롤아웃, 반성, 집계, 선택, 갱신, 평가의 6단계 파이프라인으로 단일 스킬 문서를 갱신한다 |
세 기법에는 공통으로 빠진 것이 하나 있다. 셋 모두 학습한 것을 별도의 진화하는 지식 표현으로 유지하지 않는다. 통찰이 최적화 이력 여기저기에 흩어진 채로 남아, 다음 반복이 그것을 체계적으로 다시 쓰지 못한다.
작업 공간을 세 층으로 나눈다
WikiSkill의 작업 공간은 세 개의 디렉토리로 나뉜다.
raw/ (원시 계층) 은 각 반복에서 훈련 과제를 돌려 얻은 실행 궤적을 그대로 담는다. 추론, 도구 호출, 도구 출력, 최종 답까지 전 과정이 들어간다. 이 층은 한번 쌓이면 바뀌지 않는다.
wiki/ (위키 계층) 은 그 기록을 구조화된 지식으로 컴파일한다. patterns/ 아래에는 실패 양상이나 성공 전략 하나하나를 담은 마크다운 파일이 쌓이고, 대응 방안도 나란히 들어간다. 여기에 더해 두 종류의 장기 기억이 있다.
logs.md는 위키 관리자가 갱신하는 진화 로그다. 회차마다 무엇을 발견했는지 이어 붙인다.skill-impact.md는 스킬 영향 추적기다. 검증 게이팅이 끝나면 외부 루프 하니스가 여기에 한 줄을 자동으로 더한다. 제안 메타데이터, 대상 스킬 이름, 수정 내용의 통합 diff, 검증 점수, 그리고 수락 여부가 남는다.
이 두 파일 덕분에 다음 반복의 에이전트는 (1) 어떤 개입이 거절당했는지를 알고 같은 제안을 다시 내지 않으며, (2) 과거에 무엇을 제안했고 그것이 통했는지를 확인하고, (3) 여러 회차에 걸쳐 되풀이되는 오류를 찾아낸다.
skills/ (스킬 계층) 은 현재 활성 스킬 집합이다. 스킬마다 SKILL.md 와 함께 PURPOSE.md 를 둬서, 이 스킬이 어떤 위키 패턴에서 비롯됐는지를 거슬러 올라갈 수 있게 연결해 둔다.
한 번의 반복이 도는 순서
WikiSkill에서 한 번의 반복은 네 가지 구성 요소를 차례로 거친다.
- 추론 에이전트가 현재 활성 스킬을 시스템 프롬프트에 통째로 받아 훈련 과제를 수행한다. 스킬 검색이나 발동 실패가 실험의 교란 변수가 되지 않도록 전량 주입 방식을 택했다. 이때 추론 에이전트는 위키에 접근하지 못한다.
- 위키 관리자가 그중 일부 실행 기록을 넘겨받아 실패의 근본 원인을 분석하고 성공 전략을 뽑아낸다. 패턴 페이지를 새로 만들거나 기존 페이지에 증거를 덧붙이며, 수정은 추가와 치환과 삽입 같은 패치 방식으로 이뤄진다. 한 반복에 만들거나 고칠 패턴 수에 상한은 없다.
- 스킬 제안자가 ReAct 방식으로 움직인다. 이 에이전트는 미리 뽑아 둔 기록 묶음을 받지 않는다. 위키 색인과
skill-impact.md, 훈련 과제 결과 요약만 먼저 받은 뒤,read_file도구로 필요한 패턴 페이지와 원시 실행 기록을 스스로 골라 읽는다. 그 뒤 스킬 하나를 대상으로 하는 원자적 제안 하나를 내놓는다. - 게이팅과 롤백이 후보 스킬을 검증 분할에서 평가한다. 최고 점수를 넘겼을 때만 수락하고, 아니면 직전 스킬 집합으로 되돌린다. 검증 점수가 1.0에 닿으면 진화 루프는 조기 종료한다.
여기서 눈여겨볼 것은 롤백의 범위다. 스킬은 되돌아가지만 위키는 되돌아가지 않는다. 거절당한 제안도 그 diff와 결과가 skill-impact.md 에 남고, 위키 패턴은 회차가 바뀌어도 계속 쌓인다.
표본은 실행 기록 최대 8개다. 실패 5개와 성공 3개까지 비율을 지켜 뽑는다. 실행 로그 하나는 프롬프트에 넣기 전 15,000자로 자른다.
다섯 모델과 다섯 벤치마크
평가에 쓴 벤치마크는 수학 추론(LiveMathematicianBench), 웹 검색(SealQA), 스프레드시트 조작(SpreadsheetBench), 장문 문서 질의응답(OfficeQA), 상호작용형 체화 과제(ALFWorld)다. 분할과 도구 구성은 선행 연구와 동일하게 맞췄다.
| 벤치마크 | 상호작용 | 훈련 | 검증 | 테스트 | 환경 도구 |
|---|---|---|---|---|---|
| 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 | 허용 행동 집합 |
모델은 Qwen-3.5-4B/9B-Instruct, Qwen-3.6-27B, Gemma-4-31B-It, Gemini-3.5-Flash 다섯 종이다. 모든 스킬 진화 기법은 빈 스킬 집합에서 출발했고, 보고된 점수는 전체 진화 과정을 세 번 독립 실행한 평균이다.
| 모델 | 기법 | LiveMath | SealQA | SpreadSheet | OfficeQA | ALFWorld | 평균 |
|---|---|---|---|---|---|---|---|
| Qwen-3.5-4B | 스킬 없음 | 29.1 | 32.5 | 14.6 | 30.2 | 24.4 | 26.2 |
| Trace2Skill | 31.5 | 37.6 | 17.5 | 31.0 | 42.8 | 32.1 | |
| EvoSkill | 41.7 | 37.3 | 18.6 | 29.5 | 41.5 | 33.7 | |
| SkillOpt | 48.7 | 33.3 | 14.0 | 34.5 | 45.3 | 35.2 | |
| WikiSkill | 49.7 | 39.4 | 21.1 | 28.5 | 53.7 | 38.5 | |
| Qwen-3.5-9B | 스킬 없음 | 28.2 | 26.3 | 24.3 | 35.9 | 34.7 | 29.9 |
| Trace2Skill | 33.1 | 36.9 | 26.5 | 38.4 | 48.8 | 36.7 | |
| EvoSkill | 58.1 | 34.5 | 35.4 | 34.9 | 48.5 | 42.3 | |
| SkillOpt | 48.7 | 29.4 | 29.0 | 38.0 | 55.7 | 40.2 | |
| WikiSkill | 56.3 | 43.1 | 33.6 | 40.5 | 63.4 | 47.4 | |
| Qwen-3.6-27B | 스킬 없음 | 33.9 | 27.5 | 40.8 | 42.1 | 52.8 | 39.4 |
| Trace2Skill | 36.3 | 37.3 | 53.3 | 54.3 | 55.5 | 47.3 | |
| EvoSkill | 57.3 | 32.9 | 59.5 | 52.5 | 64.2 | 53.3 | |
| SkillOpt | 51.9 | 34.5 | 53.2 | 54.8 | 59.2 | 50.7 | |
| WikiSkill | 61.9 | 41.6 | 81.7 | 53.7 | 77.6 | 63.3 | |
| Gemma-4-31B | 스킬 없음 | 33.9 | 30.6 | 48.3 | 43.3 | 50.4 | 41.3 |
| Trace2Skill | 32.3 | 37.7 | 58.5 | 43.2 | 57.2 | 45.8 | |
| EvoSkill | 29.8 | 38.4 | 56.4 | 39.9 | 52.6 | 43.4 | |
| SkillOpt | 40.1 | 36.1 | 63.1 | 44.4 | 61.9 | 49.1 | |
| WikiSkill | 56.7 | 41.2 | 68.0 | 44.2 | 64.4 | 54.9 | |
| Gemini-3.5-Flash | 스킬 없음 | 33.0 | 29.4 | 50.5 | 48.6 | 85.9 | 49.5 |
| Trace2Skill | 41.9 | 44.3 | 56.0 | 50.0 | 85.9 | 55.6 | |
| EvoSkill | 44.6 | 43.6 | 55.4 | 51.2 | 85.9 | 56.1 | |
| SkillOpt | 49.7 | 28.2 | 66.1 | 49.8 | 85.9 | 55.9 | |
| WikiSkill | 72.6 | 44.7 | 76.6 | 60.7 | 85.9 | 68.1 |
WikiSkill은 다섯 모델 모두에서 평균 성능 1위였다. 모델별로 가장 강한 경쟁 기법과 견주면 3.3점, 5.1점, 10.0점, 5.8점, 12.0점씩 앞섰다. 향상 폭이 큰 사례를 보면, 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는 28.2%에 그쳐 무스킬 29.4%보다 낮았다.
Gemini-3.5-Flash의 ALFWorld가 모든 행에서 85.9%로 같은 것은 눈속임이 아니다. 이 모델은 진화 시작 전 검증 분할에서 이미 100%를 받아 조기 종료 조건에 걸렸다. 스킬이 아예 만들어지지 않았다.
스킬은 모델 규모를 보완한다
Qwen 계열 안에서 WikiSkill의 평균 향상은 4B가 12.3점, 9B가 17.5점, 27B가 23.9점으로 규모를 따라 커졌다. SpreadSheet에서 이 경향이 가장 뚜렷해, 세 모델의 향상 폭이 각각 6.5점, 9.3점, 40.9점이었다.
작은 모델이 스킬을 갖추면 스킬 없는 큰 모델을 앞서기도 한다. WikiSkill을 붙인 Qwen-3.5-9B의 평균 47.4%는 스킬 없는 Qwen-3.6-27B의 39.4%를 넘는다. 모델 능력과 진화한 절차적 지식은 서로 다른 성능 원천이고, 둘은 서로를 보완한다.
벤치마크별 편차도 있다. 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는 긴 맥락에서 다단계 검색 절차를 끝까지 수행하지 못하고 원래의 문서 읽기 습관으로 돌아갔다. 점수는 오히려 살짝 내려갔다.
스킬은 모델 사이를 건너간다
같은 스킬을 다른 모델에 붙이는 실험이 이 논문에서 가장 흥미로운 결과를 낸다.
| 추론 모델 | 스킬 출처 | LiveMath | SealQA | SpreadSheet | OfficeQA | ALFWorld |
|---|---|---|---|---|---|---|
| Qwen-3.5-9B | 없음 | 28.2 | 26.3 | 24.3 | 35.9 | 34.7 |
| Qwen-3.5-4B | 61.0 | 40.4 | 25.0 | 40.3 | 69.2 | |
| Qwen-3.5-9B (자기) | 56.3 | 43.1 | 33.6 | 40.5 | 63.4 | |
| Qwen-3.6-27B | 59.1 | 40.4 | 50.5 | 39.9 | 70.2 | |
| Gemini-3.5-Flash | 53.0 | 39.6 | 48.8 | 40.5 | 없음 | |
| Gemma-4-31B | 없음 | 33.9 | 30.6 | 48.3 | 43.3 | 50.4 |
| Qwen-3.5-4B | 73.1 | 38.8 | 37.1 | 42.1 | 66.9 | |
| Qwen-3.6-27B | 73.7 | 37.7 | 72.0 | 44.2 | 66.9 | |
| Gemma-4-31B (자기) | 56.7 | 41.2 | 68.0 | 44.2 | 64.4 | |
| Gemini-3.5-Flash | 61.8 | 37.7 | 68.8 | 43.4 | 없음 |
Qwen-3.6-27B가 만든 스킬을 붙인 Qwen-3.5-9B는 SpreadSheet에서 50.5%를 기록했다. 스킬 없이는 24.3%, 자기가 만든 스킬로는 33.6%였다. Gemma-4-31B의 LiveMath도 자기 스킬 56.7%보다 남의 스킬 73.7%가 나았다.
하위 모델이 만든 스킬이 상위 모델에서 효과를 내는 경우도 있다. Qwen-3.5-4B가 만든 스킬은 Gemma-4-31B의 LiveMath를 73.1%로, ALFWorld를 66.9%로 올렸다. 더 강한 모델이 반드시 더 좋은 스킬을 만들지는 않는다.
옮겨지지 않는 스킬도 있다
전이가 늘 이롭지는 않았다. Qwen-3.5-4B가 만든 SpreadSheet 스킬을 Gemini-3.5-Flash에 붙이자 50.5%였던 성능이 18.1%까지 무너졌다. 같은 모델에 Qwen-3.6-27B 스킬을 넣으면 63.4%를 기록한다.
오류 분석은 두 가지 원인을 지목한다. 첫째, 작은 모델이 만든 스킬에는 한 줄짜리 파이썬 명령이나 문자열 변환 규칙 같은 저수준 우회책이 담긴다. 이것이 작은 모델의 실행 실패는 막아 주지만, 강한 모델은 처음부터 끝까지 이어지는 스크립트를 짜지 못하게 한다. 둘째, 잘게 쪼개진 진단 절차가 중복 도구 호출을 불러, 과제를 끝내기 전에 Gemini-3.5-Flash의 상호작용 예산을 소진시킨다.
역으로 같은 출처의 스킬도 받는 쪽에 따라 값이 달라진다. Qwen-3.6-27B가 만든 SpreadSheet 스킬은 4B, 9B, 27B의 무스킬 대비 각각 18.4%, 26.2%, 40.9% 향상을 냈다. OfficeQA에서는 Qwen-3.5-4B가 만든 스킬이 정작 자기 성능을 30.2%에서 28.5%까지 깎았다. 반면 같은 스킬을 받은 Qwen-3.6-27B는 42.1%에서 52.9%를 기록했다.
자기 진화는 평소 두 능력을 한 덩어리로 뭉뚱그린다. 위의 두 관찰이 그 덩어리를 둘로 떼어 놓는다. 경험에서 쓸모 있는 절차를 발견하는 능력, 그리고 그 절차를 실제로 수행해 내는 능력이다.
위키를 떼어내면
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 |
| 없음 | 있음 (기본값) | 72.6 | 44.7 | 76.6 | 60.7 | 63.7 |
추론 에이전트의 위키 접근을 끈 상태에서 스킬 제안자에게 위키를 주면 평균은 48.7%에서 63.7%가 된다. 15.0점 차이다. LiveMath는 51.3%에서 72.6%로, SpreadsheetBench는 49.9%에서 76.6%로 움직인다. 영속 지식을 쌓아 두지 않으면 제안자는 복잡한 실패 양상을 끝내 풀어내지 못한다.
반대로, 훈련 롤아웃을 도는 추론 에이전트에게 위키를 열어 주면 평균은 60.9%로 2.8점 낮아진다. LiveMath는 72.6%에서 64.8%까지 밀린다. 가설은 이렇다. 스킬과 위키를 함께 볼 수 있으면 추론 에이전트는 과제에 필요한 지식 일부를 위키에서 가져온다. 그러면 남는 실행 기록에는 스킬의 부족한 곳을 보여 줄 정보가 줄어든다.
그래서 기본 설정은 스킬 제안자에게만 위키를 준다.
위키는 쌓이고 스킬은 짧아진다
진화 과정에서 만들어진 산출물의 통계도 모델마다 서로 달랐다. Qwen 계열은 118.9줄에서 128.6줄에 이르는 긴 절차 스킬을 뽑아냈고, Gemma-4-31B는 45.1줄, Gemini-3.5-Flash는 81.2줄로 훨씬 간결했다. 위키 패턴은 모델당 평균 6.3개에서 8.9개가 생성됐고 수정은 7.0회에서 18.4회 사이였다.
벤치마크로 보면 SpreadSheet가 가장 긴 스킬(142.5줄)과 가장 많은 패턴(9.8개)을 낳았고, LiveMath가 가장 짧은 스킬(84.6줄)과 가장 적은 패턴(4.4개)을 남겼다.
수락된 스킬 갱신이 언제 일어났는지도 세어 봤다. 초기 단계(반복 0에서 1)가 모델별로 39%에서 52%를 차지했지만, 중기와 후기에도 상당한 몫이 남았다. SealQA는 중기 33%, 후기 28%로 개선이 늦게까지 이어졌다.
ALFWorld에서 벌어진 일
구체적 사례 하나가 이 구조의 작동을 잘 보여 준다. Qwen-3.6-27B로 ALFWorld를 돌린 경우다.
반복 0에서 위키 관리자는 에이전트가 물건을 집고, 살피고, 옮기는 동작을 계속 되풀이한다는 것을 발견해 take-examine-move-loop.md 패턴을 만든다. 같은 반복에서 스킬 제안자는 goal-directed-action 스킬을 제안하지만 검증 점수를 올리지 못해 거절당한다. 여기서 중요한 것은 그 제안의 diff와 거절 결과가 skill-impact.md 에 남는다는 점이다.
반복 1에서 제안자는 그 감사 기록을 읽고, 이번에는 구체적 행동 규칙 하나를 담은 break-repetition-loop 를 만든다. 규칙은 “물건을 원래 자리로 되돌려 놓지 말 것"이다. 이 제안은 수락된다.
이후 롤아웃에서 새로운 형태의 반복 행동이 나타나자 위키 관리자는 multi-operation-loop.md 로 증거를 더 쌓는다. 반복 4에서 제안자는 이 누적된 패턴을 근거로 스킬을 한 번 더 다듬어 “물건마다 각 조작 유형은 한 번씩만"이라는 규칙을 넣는다.
최적화 비용
반복 한 번에 드는 옵티마이저 API 호출 수도 비교했다. WikiSkill이 쓰는 호출은 위키 관리자 1회에 스킬 제안자의 ReAct 턴 수를 더한 값이다. 실험에서 그 턴 수는 대략 10에서 20 사이였다. 배치 크기를 훈련 집합 전체로 잡았기 때문에, 훈련 과제가 몇 개든 반복당 호출 수는 변하지 않는다.
| 프레임워크 | 훈련 집합 크기에 대한 복잡도 |
|---|---|
| Trace2Skill | 선형. 실행 기록 하나마다 독립 분석 호출이 필요하다 |
| EvoSkill | 미니배치 수에 선형 |
| SkillOpt | 미니배치 수에 선형. 단계마다 반성과 병합 호출이 6회에서 8회 |
| WikiSkill | 전체 배치 설정에서 상수 |
EvoSkill과 SkillOpt는 미니배치 설정에서 최고 성능을 내는데, 그 때문에 호출 수가 훈련 집합 크기에 비례해 늘어난다. 데이터셋에 따라 추론 비용이 더 들 수 있다는 점은 저자들도 인정한다. 그 대가로 성능 향상이 일관되게 따라온다.
저자들이 남긴 한계
네 가지가 적혀 있다.
- 스킬을 프롬프트에 통째로 주입하는 설정이라, 스킬 수가 늘었을 때 필요한 검색과 발동은 평가하지 않았다.
- 게이팅 기준이 엄격해서, 당장의 성능을 유지하면서 다음 반복의 개선을 여는 중립적 제안이 배제된다.
- 위키가 패턴 페이지와 로그와 diff를 계속 쌓기만 하고, 이를 쳐내는 자동 장치가 없다.
- 수백 번의 환경 행동이나 수 시간에 걸치는 초장기 과제는 다루지 않았다. 단일 롤아웃 안에서 절차를 다듬는 온라인 적응은 후속 과제로 남겨 뒀다.
가장 흥미로운 지점
내가 오래 곱씹은 대목은 추론 에이전트에게 위키를 열어 주면 오히려 성능이 떨어진다는 절제 실험이다. 지식을 더 많이 준 쪽이 더 나빠졌다.
관건은 정보의 양이라기보다 증거의 순도다. 훈련 롤아웃이 뽑아내야 하는 것은 높은 점수가 아닌, 스킬이 지금 어디서 부족한지를 드러내는 실행 기록이다. 에이전트가 위키에서 답을 바로 가져오면 그 기록은 스킬의 결함을 더 이상 비추지 못한다. 시험지를 채점하려는데 학생이 참고서를 펴 놓고 푼 셈이다. 점수는 오르고 진단은 사라진다.
전이 실험도 같은 이야기를 한다. 남이 만든 스킬이 자기 것보다 나은 경우가 흔하다는 결과는, 스킬을 만드는 일과 스킬을 따르는 일이 별개의 능력이라는 뜻이다. 작은 모델이 자기 손발에 맞춰 만든 우회책은 큰 모델의 발목을 잡고, 큰 모델이 정리한 절차는 작은 모델이 끝까지 수행하지 못한다. 절차적 지식을 자산으로 굴리려는 쪽이라면, 그 자산이 어느 모델의 몸에 맞춰져 있는지를 따로 관리해야 한다는 이야기가 된다.
참고서 비유는 시험 상황을 전제한다. 실제 서비스 환경에서는 에이전트가 위키든 무엇이든 쓸 수 있는 것을 다 써서 과제를 끝내는 편이 낫다. 위키 접근을 막는 제약은 진화 루프의 훈련 국면에만 해당하는 것이지, 배포된 에이전트에게 지식 접근을 줄이라는 처방이 아니다.
출처
Liyan Tang, Cyrus Rashtchian, Chun-Sung Ferng, Andrew Tomkins, Da-Cheng Juan, Tu Vu (Google Research, Virginia Tech), “WikiSkill: Compiling Agent Experience into Persistent Knowledge for Skill Evolution”, arXiv:2608.27454, 2026년 8월 27일.
원문: https://arxiv.org/abs/2608.27454
본문 그림 두 장은 원문 HTML 판에서 인용했다.