WikiSkill: Compiling Agent Experience into Persistent Knowledge for Skill Evolution

Paper: Tang, L., Rashtchian, C., Ferng, C.-S., Tomkins, A., Juan, D.-C., & Vu, T. (2026). WikiSkill: Compiling agent experience into persistent knowledge for skill evolution (arXiv:2608.27454v1). arXiv. https://arxiv.org/abs/2608.27454

Abstract: 이 글은 Google Research와 Virginia Tech가 낸 WikiSkill 논문을 읽고 정리한 것이다. 에이전트가 자기 실행 경험에서 스킬을 스스로 다듬는 연구는 이미 여럿 있는데, 논문은 그 방법들이 "무엇을 배웠는지"를 별도 표현으로 남기지 않는다고 진단한다. 해법으로 실행 기록·누적 지식·실행 가능한 스킬을 세 층으로 분리하고, 가운데에 회차를 넘어 유지되는 위키를 둔다. 아래에서는 세 층 구조와 한 회차의 흐름, 다섯 벤치마크 결과, 절제와 비용을 차례로 본다. 원문은 PDF를 정본으로 삼아 표를 좌표로 복원하고 도판을 렌더해 대조했다. 확인 과정에서 표가 초록보다 조심스러운 지점이 몇 군데 나왔고, 반대로 논문이 자기 결과를 실제보다 낮춰 말하는 곳도 있었다.

---

Executive Summary

항목	설명
연구 질문	에이전트의 실행 경험을 회차를 넘어 남는 지속적 지식으로 컴파일하면(Karpathy의 LLM Wiki 관점) 장기 스킬 진화를 지원할 수 있는가?
핵심 기여	실행 기록·누적 지식(위키)·실행 가능한 스킬의 3층 분리, 시스템 상태의 (S_k, W_k) 튜플 확장, 그리고 권한 분리 — 트레이스를 분석하는 Wiki Maintainer는 스킬 쓰기 연산이 없고, 스킬을 고치는 Skill Proposer는 위키를 먼저 읽는 다중 턴 ReAct다.
방법적 결과	형식 정리는 없다. 설계 결과는 두 변수의 비대칭 갱신 규칙 — 스킬은 검증 게이팅을 통과해야 바뀌고 실패하면 롤백되지만, 위키는 조건 없이 누적된다 — 과 기본 구성에서 Inference Agent의 위키 접근 차단이다.
실험 결과 (저자 보고)	5개 벤치마크 평균에서 5개 모델 전부 1위, 최강 기준선 대비 +3.3~+12.0. 절제(Gemini-3.5-Flash, 4벤치마크)에서 위키를 빼면 63.7→48.7로 기존 세 방법의 밴드(48.05~48.70)에 정확히 복귀 — 보고된 마진 전체가 위키에 귀속된다. 무스킬 대비 25칸 중 23칸 개선.
핵심 한계	논문 자신의 볼드 규칙 기준 유의한 단독 우위는 25열 중 11열이고, 그 규칙이 4열에서 지켜지지 않는다. 스케일링 추세를 그린 Figure 1에는 단조성을 깨는 Gemma-4-31B가 빠져 있다. 절제는 1개 모델에서만 돌았고 지속성만 겨눈 대조군이 없으며, 3회 실행의 산포는 어디에도 보고되지 않는다.

목차

1. 논문이 겨냥한 문제
2. 세 층 구조
3. 한 회차가 도는 방식
4. 실험 설정
5. 결과
6. 절제 — 위키가 마진 전부다
7. 비용
8. 한계와 비판
9. 결론

---

1. 논문이 겨냥한 문제

에이전트 스킬은 특정 작업에 필요한 지식과 절차를 문서로 묶어 둔 것이다. 최근 연구들은 이 문서를 사람이 쓰는 대신 에이전트의 실행 기록에서 자동으로 뽑아내고, 회차를 거듭하며 고쳐 나간다. 논문이 기준선으로 삼는 Trace2Skill, EvoSkill, SkillOpt가 모두 그 계열이다.

논문 자신이 이 셋과 공유하는 골격을 인정한다.

"We compare WikiSkill against three representative skill-evolution baselines, including Trace2Skill (Ni et al., 2026), EvoSkill (Alzubi et al., 2026), and SkillOpt (Yang et al., 2026), all of which share the same general loop of rolling out an agent, analyzing execution traces, proposing skill modifications, and gating changes via validation." (§4.1)

같은 루프를 도는데 무엇이 다른가. 논문의 진단은 한 문장이고, §1과 §6에 같은 표현으로 두 번 나온다.

"these methods do not maintain what has been learned as a separate, evolving knowledge representation."

즉 트레이스를 분석해서 얻은 통찰이 스킬 문서에 곧바로 반영되고 나면, 그 통찰 자체는 최적화 이력 속에 흩어진 채 남는다는 것이다. 다음 회차가 그것을 체계적으로 다시 쓰지 못한다.

논문은 해법의 착상 출처를 밝힌다. §1이 Karpathy의 LLM Wiki 관점을 인용하며 "which advocates compiling experience into persistent, compounding knowledge"라 옮기고, 거기서 물음을 세운다. "Can agent experience be similarly compiled into persistent knowledge to support long-term skill evolution?" 제목의 "compiling"이 여기서 온다. 참고문헌 항목은 GitHub Gist다.

여기서 짚어 둘 것이 있다. "이력을 남긴다"는 것 자체는 새롭지 않다. 논문 스스로 EvoSkill이 "a cumulative history of prior proposals and their evaluation outcomes"를 유지하고 SkillOpt이 "rejected-edit feedback and epoch-wise meta guidance"를 쓴다고 §1에 적는다. 새로운 것은 그 이력이 평면 로그가 아니라 주제별 페이지와 색인을 갖고, 전용 에이전트가 그것을 계속 고쳐 쓴다는 점이다. 논문이 부록 D.1에서 EvoSkill을 "a flat feedback history of past proposal outcomes"라고 부르는 대목이 이 대비를 분명히 한다.

2. 세 층 구조

그림 1. Tang et al. (2026), Figure 2. 에이전트 작업공간이 세 층으로 나뉜다. 해설을 위해 인용. arXiv:2608.27454.

작업공간이 셋으로 갈린다.

원시 실행 경험은 Inference Agent가 과제를 풀며 남긴 궤적이다. 명령어, 도구 호출, 결과가 그대로 들어 있다.

위키는 그 궤적에서 뽑아낸 지식이다. 주제별 패턴 페이지와 색인, 그리고 로그로 이루어진다. 회차를 넘어 유지되고 초기화되지 않는다.

스킬은 Inference Agent가 실제로 읽는 실행 가능한 문서 집합 S = {s_1, \ldots, s_M}이다. 디렉터리로 관리되고, 각 스킬에는 그 스킬이 어느 위키 패턴에서 나왔는지 되짚는 PURPOSE.md가 붙는다.

시스템 상태가 스킬 하나가 아니라 튜플 (S_k, W_k)로 확장되는 것이 형식적 차이다. 그리고 두 변수의 갱신 규칙이 다르다. 스킬은 검증을 통과해야 바뀌고 실패하면 되돌려지지만, 위키는 조건 없이 누적된다.

3. 한 회차가 도는 방식

한 회차는 네 단계다.

Inference Agent가 실행한다. 현재 활성 스킬을 프롬프트에 통째로 주입받고 학습 과제를 푼다. 이때 위키에는 접근하지 못한다. 뒤에서 볼 절제 실험이 이 제한의 근거다.

Wiki Maintainer가 정리한다. 표집한 궤적을 읽고 근본 원인을 분석해 패턴 페이지를 만들거나 고친다. 부록 E.2가 이 에이전트에게 허용한 연산은 create_patterns, update_patterns, update_index, append_log다. 스킬을 건드리는 연산이 하나도 없다.

이 권한 구분이 선행 연구와 갈리는 가장 기계적인 지점이다. Trace2Skill은 분석 결과를 "consolidated patches are applied to the skill document"로 곧장 스킬에 적용하고, SkillOpt도 "hierarchically aggregated and selected to update a single monolithic skill document"로 직결한다(부록 D.1). WikiSkill은 그 사이에 위키라는 간접층을 넣고, 분석하는 에이전트에게서 스킬 쓰기 권한을 뺏었다.

Skill Proposer가 제안한다. 다중 턴 ReAct 방식으로 움직인다. 여기서도 선행 연구와 다른데, 트레이스를 미리 골라 받지 않는다.

"the proposer is not given a fixed set of pre-sampled traces" (§3.2.3)

대신 위키를 먼저 읽고, 필요한 궤적을 스스로 골라 읽는다. 수동 수신자에서 능동 탐색자로 바뀐 셈이고, 이 선택이 뒤에서 볼 비용 구조를 만든다.

Gating과 Rollback이 거른다. 후보 스킬을 검증 분할에서 재고, 성능이 떨어지면 되돌린다. 다만 이 장치는 WikiSkill의 발명이 아니다. §4.1이 기준선들도 "gating changes via validation"한다고 적고, 한계 절은 엄격한 기준을 "following prior skill-evolution frameworks (Alzubi et al., 2026; Yang et al., 2026) to ensure a fair comparison"이라고 명시한다.

4. 실험 설정

벤치마크 다섯이다. 수학 추론 LiveMath, 웹 검색 SealQA, 스프레드시트 조작 SpreadSheet, 장문 문서 질의응답 OfficeQA, 그리고 상호작용형 ALFWorld.

분할 크기는 부록 Table 6에 있고, 이 표가 뒤의 해석에 계속 쓰인다.

벤치마크	학습	검증	시험	도구
LiveMath	35	18	124	없음
SealQA	16	10	85	web_search, read_file
SpreadSheet	80	40	280	bash
OfficeQA	50	24	172	—
ALFWorld	39	18	134	Admissible Actions

SealQA는 학습 16문항, 검증 10문항이다. 검증 한 문항이 10%p를 움직인다. 스킬 채택 여부가 이 검증 분할에서 결정되므로, 게이팅 결정 자체가 한 문항에 흔들릴 수 있다. 논문도 부록 B에서 이 점을 적는다("benchmark validation splits are relatively small, which can introduce..."). 다만 이 설정은 선행 연구와 맞춘 것이라고 밝히므로 WikiSkill만의 문제는 아니다.

모델은 다섯이다. 폐쇄 모델로 Gemini-3.5-Flash, 공개 가중치로 Qwen-3.5-4B/9B-Instruct, Qwen-3.6-27B, Gemma-4-31B-It.

전체 진화 과정을 3회 독립 실행하고 그 평균을 보고한다. 유의성은 paired bootstrap 1,000회, p < 0.05다.

5. 결과

5.1 표

Table 1을 좌표로 복원했다. 평균 열은 다섯 벤치마크의 단순 평균으로 전 행이 맞는다.

모델	방법	LiveMath	SealQA	SpreadSheet	OfficeQA	ALFWorld	Avg.
Qwen-3.5-4B	No skill	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	No skill	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	No skill	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	No skill	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	No skill	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이다.

무스킬 대비 개선은 Qwen 계열에서 +12.3, +17.5, +23.9로 커진다. SpreadSheet만 떼어 보면 +6.5, +9.3, +40.9로 더 가파르다. 여기까지는 검산이 전부 맞는다.

ALFWorld의 Gemini 행은 다섯 방법이 전부 85.9로 같다. 논문이 이유를 밝힌다. Gemini-3.5-Flash가 진화 전에 이미 검증 분할에서 100%를 받아 게이팅이 아무것도 통과시키지 못한다. 정직한 보고이고, 뒤에 나올 절제 표에서 ALFWorld가 빠지는 이유이기도 하다.

5.2 볼드가 표보다 많은 것을 말한다

Table 1 캡션은 볼드의 뜻을 정확히 정의한다.

"Bold indicates the best performance for each dataset; multiple bold results indicate methods that are not significantly different from the best under a paired bootstrap test with 1,000 iterations (p<0.05)."

즉 공동 볼드는 "그 열에서 어느 방법의 우위도 통계적으로 확인되지 않았다"는 뜻이다. 글꼴 스팬으로 볼드를 판정해 25개 벤치마크 열을 분류하면 그림이 달라진다.

유형	열 수	비율
WikiSkill 단독 볼드	11	44%
공동 볼드(WikiSkill 포함, 2~4개 방법)	10	40%
볼드가 하나도 없음	4	16%
경쟁 방법만 볼드이고 WikiSkill은 아님	0	0%

WikiSkill이 유의한 단독 우위를 확보한 열은 25개 중 11개다. 나머지 14개에서는 단독 우위가 통계적으로 확인되지 않는다. 초록의 "consistently outperforms state-of-the-art skill-evolution methods"는 평균 기준으로는 성립하지만, 벤치마크 단위로 보면 절반이 안 되는 열에서만 검정으로 뒷받침된다. 그리고 그 사실을 논문 자신의 볼드 규칙이 이미 표에 적어 두었다.

SealQA가 대표적이다. 다섯 모델 중 셋에서 WikiSkill이 수치상 1위인데 전부 공동 볼드다. 시험 분할이 85문항이니 1점 차이가 한 문항이 채 안 된다는 것을 생각하면 자연스러운 결과다.

평균 열에서는 논문 자신의 헤드라인 첫 숫자가 동률로 표시된다. §4.2.1은 "WikiSkill improves average performance by 3.3, 5.1, 10.0, 5.8, and 12.0 points"라고 적는다. 그런데 Qwen-3.5-4B의 Avg. 열에는 WikiSkill 38.5와 SkillOpt 35.2가 함께 볼드다. 캡션 규약대로면 그 3.3점 차이는 논문 자신의 부트스트랩 검정으로 구분되지 않는다. 나머지 네 모델의 Avg. 열은 WikiSkill 단독 볼드이므로, 다섯 개 중 하나가 그렇다.

규약은 부록에 있는데 캡션 서술이 들쭉날쭉하다. 부록 C가 판정 규칙을 한곳에 적는다. 최상위 방법이 나머지 전부를 유의하게 앞서면 단독 볼드이고, 구분되지 않는 방법이 있으면 그것들을 묶어 공동 볼드로 준다는 것이다. 그런데 Table 1 캡션만 이 규칙을 옮겨 적고, Table 2 캡션은 "The highest performance per benchmark within each model block is bolded"라고만 해 동률을 언급하지 않으며, Table 3 캡션에는 볼드 설명이 없다. 규칙 자체가 다른 것은 아니고 캡션이 그것을 일관되게 옮기지 않는다.

볼드가 하나도 없는 열 넷은 그 규칙으로 설명되지 않는다. 부록 C의 규칙은 단독 볼드 아니면 공동 볼드를 낳고, 볼드가 0개인 경우를 만들지 않는다.

모델	벤치마크	그 열의 최고값
Qwen-3.5-4B	OfficeQA	SkillOpt 34.5
Qwen-3.5-9B	OfficeQA	WikiSkill 40.5
Gemma-4-31B	OfficeQA	SkillOpt 44.4
Gemini-3.5-Flash	ALFWorld	전부 85.9

Gemini/ALFWorld는 다섯 값이 같아 최고를 표시할 수 없다는 해석이 가능하다. 나머지 셋은 값이 서로 다른데도 볼드가 없다. 셋 다 OfficeQA라는 점에서 이 벤치마크에 대한 어떤 처리가 있었을 개연성이 높지만, 논문은 밝히지 않는다.

여기서 한 가지는 조심해서 적어야 한다. 볼드가 빠진 세 열 중 둘에서는 경쟁 방법이 WikiSkill을 이기고, 하나(Qwen-3.5-9B)에서는 WikiSkill이 최고인데도 볼드가 없다. 그러므로 "패배를 감추는 방향"이라고만 말하면 정확하지 않다. 확인할 수 있는 것은 두 가지다. 캡션 규칙이 네 열에서 지켜지지 않았고, 그 결과 표를 훑는 독자에게 SkillOpt이 WikiSkill을 이긴 두 칸이 보이지 않는다.

5.3 OfficeQA

WikiSkill이 단독 1위가 아닌 칸을 모으면 한곳으로 몰린다.

모델	벤치마크	이긴 방법
Qwen-3.5-4B	OfficeQA	SkillOpt 34.5 (WikiSkill 28.5)
Qwen-3.5-9B	LiveMath	EvoSkill 58.1 (WikiSkill 56.3)
Qwen-3.5-9B	SpreadSheet	EvoSkill 35.4 (WikiSkill 33.6)
Qwen-3.6-27B	OfficeQA	SkillOpt 54.8 (WikiSkill 53.7)
Gemma-4-31B	OfficeQA	SkillOpt 44.4 (WikiSkill 44.2)

OfficeQA에서 다섯 모델 중 셋이 SkillOpt에 진다. 그리고 Qwen-3.5-4B/OfficeQA는 25칸 중 유일하게 WikiSkill이 무스킬보다 나쁜 칸이다(30.2 → 28.5). 초록의 "improves over no-skill baselines in most model-benchmark settings"에서 "most"라는 헤지가 어디서 왔는지가 여기서 드러난다. 25칸 중 23칸 개선, 1칸 퇴행, 1칸 동률이다.

논문은 이 퇴행을 숨기지 않는다. 오히려 §4.2.2에서 이 칸을 근거로 삼는다. Qwen-3.5-4B가 만든 OfficeQA 스킬이 자기 성능은 30.2에서 28.5로 떨어뜨리면서 Qwen-3.6-27B는 42.1에서 52.9로 올린다는 것이다.

5.4 전이

Table 2는 한 모델이 만든 스킬을 다른 모델에 붙여 본다. 원천 모델은 셋이다(Qwen-3.5-4B, Qwen-3.6-27B, Gemini-3.5-Flash). Qwen-3.5-9B와 Gemma-4-31B는 원천으로 쓰이지 않는데 그 이유는 밝혀져 있지 않다.

전이가 자주 통한다. Qwen-3.6-27B의 SpreadSheet 스킬은 Qwen-3.5-9B를 24.3에서 50.5로 올리는데, 그 모델이 스스로 만든 스킬(33.6)보다 낫다. 작은 모델에서 큰 모델로도 통한다. Qwen-3.5-4B의 LiveMath 스킬이 Gemma-4-31B를 33.9에서 73.1로 올린다.

반대 방향도 크게 난다. 원천-대상-벤치마크 80칸 중 8칸에서 전이 스킬이 무스킬보다 나쁘고, 가장 큰 것은 Gemini-3.5-Flash가 Qwen-3.5-4B의 SpreadSheet 스킬을 받았을 때다. 50.5에서 18.1로 32.4점이 빠진다.

논문이 이것을 감추지 않는다는 점은 분명히 적어야 한다. §4.2.2가 수치를 그대로 인용하고 "negative transfer"라고 이름 붙인 뒤 원인 분석까지 붙인다. 작은 모델의 스킬이 한 줄짜리 파이썬 명령이나 문자열 변환 규칙 같은 저수준 우회책을 담고 있어서, 그것이 작은 모델에는 실행 실패를 피하게 해 주지만 강한 모델이 통짜 스크립트를 쓰지 못하게 막는다는 것이다. 두 번째 원인으로 조각난 진단 절차가 도구 호출을 늘려 Gemini의 상호작용 예산을 먼저 소진시킨다고 적는다.

조용한 쪽은 초록이다. 초록은 "skills transfer effectively across models and model families, and skills evolved by other models can outperform self-evolved skills"라고만 적는다. 본문의 균형이 초록에는 없다.

5.5 스킬은 몇 개나 남는가

Table 4가 스킬과 위키 패턴의 통계를 준다. 여기에 논문이 본문으로 밝히지 않는 것이 둘 들어 있다.

회차 수가 표의 산술에서만 복원된다. 모델별·벤치마크별 열 열 개 전부에서 "제안된 생성 + 제안된 편집"이 정확히 8.0이다. §3.2.3이 회차마다 제안 하나를 낸다고 적으므로("the Skill Proposer produces an atomic proposal P_k that targets a single skill"), 제안 수가 곧 회차 수다. 즉 진화는 여덟 회차 돌았고, Table 5의 구간 구분(Iter 0–1 / 2–4 / 5–7)과도 맞는다. 그런데 논문은 이 숫자를 어디에도 적지 않는다. Algorithm 1은 "iterations K"라고만 쓰고, 전문에서 8 iterations나 number of iterations를 찾으면 나오지 않는다.

제안의 4분의 3은 버려진다. 채택 수를 8로 나누면 채택률이 나온다.

구분	채택 합	채택률	채택된 생성
Qwen-3.5-4B	2.9	36.3%	1.6
Qwen-3.5-9B	2.1	26.2%	1.4
Qwen-3.6-27B	2.3	28.7%	1.5
Gemma-4-31B	2.1	26.2%	1.3
Gemini-3.5-Flash	2.3	28.7%	1.2
SealQA	1.3	16.2%	0.9
LiveMath	3.0	37.5%	1.1

채택된 생성이 1.2~1.6개이므로 여덟 회차가 끝난 뒤 활성 스킬은 평균 한두 개다. 이 사실이 설계 정당화 하나를 다시 보게 만든다. §3.2.1은 스킬을 프롬프트에 통째로 주입하는 이유를 "eliminating skill triggering or retrieval failures as confounding variables in our study"라고 적는데, 스킬이 한두 개인 규모에서는 검색 실패라는 교란이 애초에 생기지 않는다. 한계 절이 지목하는 체제("as the number of available skills grows")와 실험이 실제로 돈 체제 사이의 거리가 여기서 드러난다.

성능이 가장 낮은 모델의 채택률이 가장 높다는 점도 눈에 걸린다(Qwen-3.5-4B 36.3%). 게이팅 기준이 검증 점수 향상이고 검증 분할이 10~40문항이므로, 약한 모델일수록 우연한 향상으로 제안이 통과할 여지가 크다. 논문은 채택률과 성능을 대조하지 않는다.

6. 절제 — 위키가 마진 전부다

그림 2. Tang et al. (2026), Figure 3. ALFWorld(Qwen-3.6-27B)에서 위키가 스킬을 바꾸는 과정. 해설을 위해 인용. arXiv:2608.27454.

Table 3은 위키 접근 권한을 누구에게 주느냐를 바꿔 가며 잰다. Gemini-3.5-Flash 한 모델, 네 벤치마크다(ALFWorld는 앞서 본 이유로 빠진다).

구성	Inference Agent 위키	Skill Proposer 위키	LiveMath	SealQA	SpreadSheet	OfficeQA	Avg.
R0 무스킬	—	—	33.0	29.4	50.5	48.6	40.4
R1	✓	✗	43.8	42.0	44.4	51.0	45.3
R2	✗	✗	51.3	38.4	49.9	55.2	48.7
R3	✓	✓	64.8	42.8	80.2	55.6	60.9
R4 기본	✗	✓	72.6	44.7	76.6	60.7	63.7

평균은 전부 검산을 통과한다. 본문의 "48.7% to 63.7% (+15.0%)"도 63.650 − 48.700 = 14.95로 맞는다(단위는 %p가 정확하다).

두 가지가 읽힌다.

Inference Agent에게 위키를 주면 오히려 나빠진다(63.7 → 60.9). 논문은 실행 중에 위키를 읽으면 스킬 자체의 품질을 평가하기 어려워진다는 가설을 댄다. 기본 구성이 Inference Agent의 위키 접근을 막는 이유다.

위키를 빼면 기존 방법 수준으로 돌아간다. 이게 이 표에서 가장 무거운 지점인데, 논문은 이 대조를 하지 않는다. Table 1의 Gemini 행을 같은 네 벤치마크로 다시 평균 내면 이렇게 된다.

구성	4벤치마크 평균
무스킬	40.375
Trace2Skill	48.050
SkillOpt	48.450
EvoSkill	48.700
WikiSkill에서 위키 제거(R2)	48.700
WikiSkill 기본(R4)	63.650

위키를 뺀 WikiSkill과 EvoSkill이 소수점 셋째 자리까지 같다(둘 다 합 194.8). 우연이지만 그림은 분명하다. 위키를 제거한 WikiSkill은 기존 세 방법의 밴드(48.05~48.70) 안에 정확히 들어간다.

이 대조는 논문의 주장보다 강하다. 이 모델에서 WikiSkill이 선행 연구를 앞서는 마진 전체(63.65 − 48.70 = 14.95)가 위키에 귀속된다. 동시에 약점이기도 하다. 파이프라인의 나머지 — Proposer의 ReAct 다중 턴 구조, 능동적 트레이스 탐색, 스킬 집합 관리 — 가 선행 연구 대비 기여한다는 근거가 이 표에는 없다.

한 가지 더. R2는 두 가지를 동시에 뺀다. 캡션이 명시한다.

"When the Skill Proposer has no Wiki access, we also remove the Wiki Maintainer, eliminating persistent knowledge accumulation across iterations."

따라서 −15.0은 ⓐ "제안자가 정리된 지식을 조건으로 받는 것"과 ⓑ "그 지식이 회차를 넘어 지속되는 것"의 합이다. 논문은 결론에서 ⓑ에 공을 돌리지만("persistent knowledge accumulation is critical"), 회차마다 위키를 초기화하는 대조군이 없어서 ⓐ와 ⓑ를 가를 수 없다.

절제가 한 모델에서만 돌았다는 점도 함께 적어야 한다. 다섯 모델·다섯 벤치마크의 본실험 25칸 중 절제가 닿은 곳은 1모델 × 4벤치마크다.

7. 비용

부록 D가 회차당 옵티마이저 API 호출 복잡도를 비교한다.

방법	회차당 호출	복잡도	단계당 상수
Trace2Skill	N_{train} + (1 + \frac{1}{c-1})\frac{N_{train}}{B} + 1	O(N_{train} + \frac{N_{train}}{B})	—
EvoSkill	2\frac{N_{train}}{B}	O(\frac{N_{train}}{B})	2
SkillOpt	K_{opt}\frac{N_{train}}{B}	O(\frac{N_{train}}{B})	6~8
WikiSkill	(1 + T_{React})\frac{N_{train}}{B}	O(\frac{N_{train}}{B})	11~21

상수는 논문 자신의 수치다. T_{React}는 "roughly 10 \le T_{React} \le 20 across our experiment runs", K_{opt}는 "K_{opt} \approx 6\text{--}8 optimizer LLM calls per step".

논문은 여기서 O(1)을 끌어낸다.

"In our experiments, we set the batch size to the full training size (B = N_{train}) across all datasets. In this full-batch setting (\frac{N_{train}}{B} = 1), C_{WikiSkill} = 1 + T_{React}. Because T_{React} does not depend on N_{train}, WikiSkill's optimizer API call complexity is O(1) with respect to training set size."

맞는 계산이다. 다만 그 O(1)은 알고리즘의 성질이 아니라 배치 크기를 학습 집합 전체로 잡은 선택에서 나온다. 같은 선택을 EvoSkill에 적용하면 EvoSkill도 회차당 2회로 O(1)이고, SkillOpt도 6~8회로 O(1)이다. 그리고 그 경우 세 방법의 호출 수는 2 대 6~8 대 11~21이 되어 WikiSkill이 가장 많다.

논문이 기준선들을 실제로 어떤 B로 돌렸는지는 적혀 있지 않다. 그래서 실험에서 각 방법이 실제로 몇 번 호출했는지는 이 표로 계산할 수 없다. 총 토큰 소비나 벽시계 시간, 비용도 보고되지 않는다.

논문이 비용 차이를 모르는 것은 아니다.

"While this constant call complexity may incur higher inference cost on some datasets, the additional computation is accompanied by consistent performance gains over prior skill-evolution methods across our evaluation."

인정과 통제는 다르다. 성능 우위 중 얼마가 구조(위키) 덕이고 얼마가 예산 덕인지를 가르는 실험은 없다. 다만 §6의 절제가 이 걱정을 상당히 덜어 준다는 점도 공정하게 적어야 한다. R2는 WikiSkill과 같은 ReAct 제안자를 그대로 쓰면서 위키만 뺀 구성이고, 그 결과가 기존 방법 수준으로 내려앉는다. Wiki Maintainer 호출 하나가 빠질 뿐 회차당 열 번 넘는 제안자 호출은 그대로이므로, 계산량이 거의 같은 조건에서 위키 유무가 마진을 만든 셈이다. "예산이 다 한 일"이라는 해석은 이 표와 맞지 않는다.

8. 한계와 비판

8.1 논문이 밝힌 것

• 검증 분할이 작아 게이팅이 흔들릴 수 있다(부록 B).
• 스킬이 모델별 우회책을 담으면 음의 전이가 난다(§4.2.2, 원인 분석 포함).
• Inference Agent에게 위키를 주면 성능이 떨어진다(§5.1).
• 회차당 호출 상수가 커서 데이터셋에 따라 추론 비용이 늘 수 있다(부록 D).
• Gemini-3.5-Flash가 ALFWorld 검증에서 진화 전 100%라 스킬이 진화하지 않는다(§4.2).

8.2 해설자 관점

Figure 1이 그 주장을 깨는 모델을 빼고 그려져 있다. 이것이 확인 과정에서 나온 가장 무거운 지적이다.

그림 3. Tang et al. (2026), Figure 1. 네 모델에 대한 방법별 평균 정확도. 해설을 위해 인용. arXiv:2608.27454.

캡션은 "Interestingly, its advantage becomes more pronounced for stronger models"라고 적는다. 도판에 그려진 네 모델에서 최강 기준선 대비 우위는 +3.3, +5.1, +10.0, +12.0으로 단조 증가한다.

그런데 도판에는 Table 1의 다섯 모델 중 Gemma-4-31B가 없고, 네 기준선 중 Trace2Skill이 없다. 빠진 모델을 넣으면 이렇게 된다.

모델	파라미터	무스킬 평균	최강 기준선	WikiSkill	우위	Figure 1
Qwen-3.5-4B	4B	26.2	35.2	38.5	+3.3	있음
Qwen-3.5-9B	9B	29.9	42.3	47.4	+5.1	있음
Qwen-3.6-27B	27B	39.4	53.3	63.3	+10.0	있음
Gemma-4-31B	31B	41.3	49.1	54.9	+5.8	없음
Gemini-3.5-Flash	—	49.5	56.1	68.1	+12.0	있음

파라미터 순으로 놓으면 27B에서 +10.0이었다가 31B에서 +5.8로 꺾인다. "강한 모델"을 무스킬 성능으로 재도 마찬가지다. Gemma-4-31B의 무스킬 평균(41.3)이 Qwen-3.6-27B(39.4)보다 높은데 우위는 절반 가까이 작다. 단조성을 깨는 유일한 모델이 도판에서 빠진 그 모델이다.

무스킬 대비 이득으로 재면 더 직접적인 반례가 된다. Qwen-3.5-9B가 +17.5인데 파라미터가 3.4배인 Gemma-4-31B는 +13.6이다.

빠진 기준선도 같은 칸으로 모인다. 도판에서 Trace2Skill이 빠졌는데, 다섯 모델 중 Trace2Skill이 EvoSkill을 이기는 유일한 모델이 Gemma-4-31B다(45.8 대 43.4). 나머지 넷에서는 전부 EvoSkill이 앞선다. 빠진 모델과 빠진 방법이 같은 자리에서 만난다.

본문 §4.2.1은 이 주장을 "Within the Qwen family"로 한정해 조심스럽게 쓴다. 한정을 푸는 것은 도판 캡션과 초록("larger models generally benefit more from evolved skills")이다.

한정어가 반대쪽에 붙어 있다. 초록은 경쟁 방법 대비에는 "consistently outperforms"라고 단정하고, 무스킬 대비에는 "in most model-benchmark settings"라고 한정한다. 그런데 표의 분포는 반대다. 무스킬 대비는 25칸 중 23칸 개선으로 강하고, 경쟁 방법 대비는 논문 자신의 검정으로 25열 중 11열에서만 단독 우위다. 헤지가 필요한 쪽이 단정돼 있고, 단정해도 되는 쪽에 헤지가 붙어 있다.

"Avg."가 표마다 다른 수를 가리킨다. Table 1과 Table 2의 평균은 다섯 벤치마크이고 Table 3은 넷이다(ALFWorld 제외). 그래서 같은 Gemini-3.5-Flash WikiSkill 구성이 Table 1에서는 68.1, Table 3에서는 63.7로 나온다. 논문은 이 차이를 표시하지 않는다.

절제 하나로 일반 결론을 세운다. 초록과 결론이 "persistent knowledge accumulation in the wiki is critical"이라고 적는데, 절제는 Gemini-3.5-Flash 한 모델·네 벤치마크에서만 돌았다. 그리고 WikiSkill이 무스킬보다 나빠지는 유일한 칸이 Qwen-3.5-4B에 있으므로, 위키의 기여가 모델마다 다를 가능성은 가설이 아니라 표에 있는 관찰이다.

지속성만 따로 절제한 조건이 없다. 앞서 본 대로 R2는 제안자의 위키 접근과 Wiki Maintainer를 동시에 없앤다. 회차마다 위키를 초기화하는 구성이 있었다면 "지속성"의 몫이 분리됐을 텐데, 그 구성은 없다. 결론의 핵심어가 "persistent"인데 정작 지속성만 겨눈 대조군이 빠져 있다.

선행 연구 서술이 한 칸 세다. "these methods do not maintain what has been learned"는 문자 그대로 읽으면 과하다. 논문 자신이 EvoSkill의 누적 이력과 SkillOpt의 기각 편집 피드백을 §1에서 소개한다. 정확한 진술은 "별도의 진화하는 지식 표현으로 유지하지 않는다"이고, 실제로 §1과 §6의 완성된 문장은 그렇게 적혀 있다. 다만 초록의 "remain scattered across optimization histories"는 그 구분을 흐린다.

볼드 규칙이 네 열에서 지켜지지 않는다. 앞서 본 대로다. 의도를 판단할 근거는 없고, 결과만 적을 수 있다.

평균 열의 결합 방식은 밝혀져 있고, 그 선택이 논점이다. 부록 C가 절차를 적는다. "we conduct stratified macro-average bootstrap resampling: in each iteration, task instances are resampled independently with replacement within each benchmark, and we calculate macro-average accuracy by assigning equal weight to all benchmarks." 벤치마크 안에서 재표집하고 벤치마크 사이에는 같은 가중치를 준다는 것이다. 다만 시험 분할이 85문항에서 280문항까지 세 배 넘게 차이 나는데 모두 같은 무게로 세는 것이 최선인지는 따져 볼 여지가 있다. 문항 수로 가중하면 SpreadSheet가 평균을 지배하고, 같은 무게로 세면 85문항짜리 SealQA가 280문항짜리와 동등해진다. 논문은 후자를 택했고 그 사실을 밝힌다.

3회 실행의 산포가 어디에도 없다. 전문에서 ±, std, deviation, variance, error bar, confidence, seed를 찾으면 전부 0건이다. 전체 진화 과정을 3회 독립 실행한 평균이라고 밝히면서 그 셋이 얼마나 흩어졌는지는 보고하지 않는다. 있는 것은 Table 1·2의 볼드가 표시하는 유의 동률뿐이고, 절제 표(Table 3)에는 그 규약조차 캡션에 없다. 그래서 §6에서 본 R3와 R4의 2.8점 차이가 실행 간 변동과 구분되는지는 표만으로 판단할 수 없다.

SealQA는 이 비교에 쓰기에 작다. 시험 85문항에서 1점은 한 문항이 채 안 되고, 학습 16문항으로 스킬을 진화시킨다. 다섯 모델 중 셋에서 WikiSkill이 수치상 1위인데 전부 공동 볼드인 것이 이 사정을 그대로 보여 준다.

원천 모델 셋의 선택 근거가 없다. Table 2에서 Qwen-3.5-9B와 Gemma-4-31B가 원천에서 빠진 이유는 적혀 있지 않다. 계산 절약이라는 합리적 설명이 가능하지만 논문이 말하지는 않는다.

부록 프롬프트가 본문과 어긋나는 곳이 있다. Wiki Maintainer 지시문(부록 E.2)은 색인의 중요성을 이렇게 설명한다.

"The index.md entries are the MOST IMPORTANT part of the wiki because they determine whether inference agents will read the full pattern pages."

색인이 중요한 이유가 추론 에이전트가 패턴 페이지를 읽을지 결정하기 때문이라는 것이다. 그런데 기본 구성에서 추론 에이전트는 위키를 읽지 못한다. §5.1이 "Our default WikiSkill configuration gives wiki access to the Skill Proposer but not the Inference Agent"라고 적고, §3.2도 "injecting active skills but restricting Wiki access"라고 적는다. 프롬프트가 대는 이유가 기본 설정에는 없는 독자를 가리킨다. 위키를 읽는 것이 Skill Proposer이므로 색인이 쓸모없다는 뜻은 아니고, 지시문의 설명이 구성과 맞지 않는다는 뜻이다.

같은 계열로 하나 더 있다. §3.1은 진화 로그와 스킬 영향 추적기를 소개하며 "These records allow the Wiki Maintainer and Skill Proposer to (1) observe the complete skill acceptance history"라고 적는데, E.2가 Maintainer에게 준다고 열거한 입력은 실행 궤적과 "the current wiki context (index, log, pattern pages)" 둘뿐이고 skill-impact.md가 없다. 채택 이력이 로그에도 실린다면 모순이 아니므로 단정하지는 않겠으나, 그 점이 명시돼 있지 않다.

8.3 남는 기여

비판을 다 적고도 남는 것이 있다.

분석과 제안의 권한을 나눈 것이 실제 설계다. Wiki Maintainer에게서 스킬 쓰기 권한을 뺏고 위키 연산만 준 것, 그리고 Proposer가 위키를 먼저 읽도록 강제한 것은 은유가 아니라 구현된 제약이다. 선행 연구가 분석 결과를 스킬 패치로 직결하는 것과 알고리즘 층위에서 갈린다.

절제가 그 설계의 값을 실제로 잰다. 위키를 빼면 기존 방법 밴드로 정확히 돌아간다는 대조는 논문이 하지 않았지만, 논문의 표만으로 재구성된다. 그리고 이 대조는 논문의 주장을 약화시키는 게 아니라 강화한다.

음의 전이를 정면으로 다룬다. 32.4점 붕괴를 수치 그대로 싣고 원인을 둘로 나눠 분석한 것은 이 계열 논문에서 흔치 않다. 초록이 조용할 뿐 본문은 정직하다.

Inference Agent에게 위키를 막은 것이 실험에서 나온 결정이다. 직관과 반대 방향인데 표로 근거를 댄다.

9. 결론

WikiSkill은 스킬 진화 루프에 간접층을 하나 넣는다. 트레이스를 분석하는 에이전트가 스킬을 직접 고치지 못하게 하고, 대신 회차를 넘어 남는 위키에만 쓰게 한다. 스킬을 고치는 에이전트는 그 위키를 먼저 읽는다.

이 설계의 값어치는 절제 표에서 가장 분명하게 보인다. 한 모델에 대해서지만, 위키를 빼면 남는 것이 기존 세 방법과 구분되지 않는다. 뒤집어 말하면 논문이 보고하는 마진 전체가 위키 한 요소에 걸려 있고, 파이프라인의 나머지가 선행 연구를 개선한다는 증거는 이 논문 안에 없다.

주장의 강도는 표보다 초록에서 한 칸씩 높다. 벤치마크 단위로 유의한 단독 우위는 25열 중 11열이고, 스케일링 추세는 도판에서 빠진 모델이 들어오면 꺾이며, "지속적 지식 축적이 결정적"이라는 결론은 한 모델의 절제에 기대고 있다. 그럼에도 방향 자체는 표가 지지한다.

---

References

Alzubi, S., Provenzano, N., Bingham, J., Chen, W., & Vu, T. (2026). EvoSkill: Automated skill discovery for multi-agent systems (arXiv:2603.02766). arXiv. https://arxiv.org/abs/2603.02766

Karpathy, A. (2026). LLM Wiki [GitHub Gist]. https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f

Ni, J., Liu, Y., Liu, X., Sun, Y., Zhou, M., Cheng, P., Wang, D., Zhao, E., Jiang, X., & Jiang, G. (2026). Trace2Skill: Distill trajectory-local lessons into transferable agent skills (arXiv:2603.25158). arXiv. https://arxiv.org/abs/2603.25158

Shridhar, M., Yuan, X., Cote, M.-A., Bisk, Y., Trischler, A., & Hausknecht, M. (2021). ALFWorld: Aligning text and embodied environments for interactive learning. International Conference on Learning Representations. https://openreview.net/forum?id=0IOX0YcCdTn

Tang, L., Rashtchian, C., Ferng, C.-S., Tomkins, A., Juan, D.-C., & Vu, T. (2026). WikiSkill: Compiling agent experience into persistent knowledge for skill evolution (arXiv:2608.27454). arXiv. https://arxiv.org/abs/2608.27454

Yang, Y., Gong, Z., Huang, W., Yang, Q., Zhou, Z., Huang, Z., Li, Y., Gao, X., Dai, Q., Liu, B., et al. (2026). SkillOpt: Executive strategy for self-evolving agent skills (arXiv:2605.23904). arXiv. https://arxiv.org/abs/2605.23904

Yao, S., Zhao, J., Yu, D., Du, N., Shafran, I., Narasimhan, K. R., & Cao, Y. (2023). ReAct: Synergizing reasoning and acting in language models. The Eleventh International Conference on Learning Representations. https://openreview.net/forum?id=WE_vluYUL-X

서지 표기는 WikiSkill 논문 자신의 참고문헌 목록이 인쇄한 형태를 따랐다. SkillOpt 항목의 저자는 원문이 "et al."로 줄여 인쇄하므로 그대로 두었고, ALFWorld 항목의 "Cote"도 원문에 악센트 없이 인쇄된 그대로 적었다. EvoSkill의 마지막 저자 T. Vu는 이 논문의 교신저자이기도 하다.