WikiSkill 논문 리뷰 — 에이전트 경험을 위키로 쌓아 스킬을 자동 진화시키는 법 (실무 적용 프롬프트 포함)

에이전트에게 스킬(SKILL.md)을 쥐여 주는 방식은 이제 표준이 됐다. 문제는 그 스킬을 누가 쓰느냐다. 대부분 사람이 손으로 쓴다. 에이전트가 어떤 절차 지식을 필요로 할지 미리 예측해서 적어야 하는데, 이 예측은 자주 틀린다.

그래서 최근 연구들은 에이전트를 훈련 태스크에 굴리고, 성공·실패 기록을 분석해 스킬을 자동으로 다듬는 쪽으로 움직였다. 그런데 여기에 빠진 것이 하나 있었다. 배운 것이 어디에도 쌓이지 않는다. 매 반복마다 얻은 교훈이 최적화 이력 곳곳에 흩어진 채로 버려진다.

구글 리서치가 8월 27일 공개한 WikiSkill 논문은 이 빈칸을 정확히 겨냥한다. 카파시(Karpathy)의 "LLM Wiki" 관점 — 경험을 영구적이고 복리로 쌓이는 지식으로 컴파일하자 — 을 에이전트 스킬 진화에 그대로 적용했다. 결과는 분명하다. 위키 하나 끼웠을 뿐인데 평균 정확도가 48.7%에서 63.7%로 뛴다.

이 글은 논문의 구조와 수치를 정리하고, 뒤쪽에서 이 구조를 우리 조직의 에이전트 운영에 바로 옮겨 쓸 수 있는 가이드 프롬프트 4종을 제공한다.

핵심 아이디어 — 경험·지식·스킬을 분리하라

WikiSkill의 출발점은 세 가지를 구분하는 것이다. 실행 기록(경험), 거기서 뽑아낸 패턴(지식), 그리고 에이전트가 실제로 드는 절차(스킬). 기존 방법들은 이 셋을 뭉뚱그렸다. WikiSkill은 디렉터리 세 개로 물리적으로 나눈다.

각 층의 규칙이 다르다는 점이 설계의 전부다.

• raw/ — 훈련 롤아웃의 실행 기록 원본. 추론, 도구 호출, 결과, 최종 답까지 전부 남는다. 불변이다. 한 번 쓰면 수정하지 않는다.
• wiki/ — 기록에서 뽑아낸 구조화된 지식. 실패 모드와 성공 전략을 담은 패턴 문서(patterns/), 반복별 발견을 시간순으로 적는 진화 로그(logs.md), 그리고 모든 스킬 제안의 diff·검증 점수·채택 여부를 기계적으로 기록하는 이력(skill-impact.md). 절대 리셋하지 않는다. 반복이 거듭될수록 복리로 쌓인다.
• skills/ — 에이전트가 실제로 드는 스킬. 각 스킬은 SKILL.md와 함께, 이 스킬이 어떤 위키 패턴에서 나왔는지 적는 PURPOSE.md를 가진다. 검증 게이트를 통과할 때만 갱신되고, 성능이 떨어지면 롤백된다.

스킬은 롤백돼도 위키는 남는다. 이 비대칭이 핵심이다. 실패한 제안조차 "이건 해봤고 안 됐다"는 지식으로 위키에 남아, 다음 제안이 같은 실수를 반복하지 않게 한다.

진화 루프 — 네 개의 역할이 돈다

매 반복(iteration)은 네 컴포넌트가 순서대로 돈다.

1. 추론 에이전트(Inference Agent) — 현재 스킬 세트를 프롬프트에 주입받고 훈련 태스크를 실행한다. 모든 과정이 raw/에 기록된다. 중요한 제약: 이 에이전트는 위키를 볼 수 없다. (이유는 어블레이션에서.)
2. 위키 관리자(Wiki Maintainer) — 성공·실패 기록을 샘플링해 읽고, 실패의 근본 원인을 분석하고, 성공 전략을 추출해 위키 패턴 문서를 만들거나 고친다. 통째로 다시 쓰는 게 아니라 증분 패치(추가·교체·삽입)로 편집한다.
3. 스킬 제안자(Skill Proposer) — ReAct 스타일 멀티턴 에이전트. 위키 색인, 스킬 채택 이력, 태스크 결과 요약을 받고, 필요한 패턴 문서와 원본 기록을 스스로 골라 읽으며 진단한 뒤, 스킬 하나를 겨냥한 원자적 수정안 1건을 낸다.
4. 게이트(Gating & Rollback) — 수정안을 적용한 후보 스킬 세트를 검증 세트에서 평가한다. 점수가 지금까지의 최고치를 넘으면 채택, 아니면 롤백. 어느 쪽이든 결과는 skill-impact.md에 기록된다.

결과 — 위키를 쌓으면 무엇이 달라지나

5개 벤치마크(수학 추론 LiveMath, 웹 검색 SealQA, 스프레드시트 조작 SpreadsheetBench, 장문서 QA OfficeQA, 체화 태스크 ALFWorld) × 5개 모델(Qwen 4B/9B/27B, Gemma 31B, Gemini 3.5 Flash)에서 기존 스킬 진화 방법 3종(Trace2Skill, EvoSkill, SkillOpt)과 비교했다.

숫자로 남는 것 세 가지.

• 전 모델에서 최고 평균. 가장 강한 경쟁 방법 대비 모델별로 +3.3~+12.0점. 기존 방법들은 모델·태스크에 따라 성능을 깎아 먹기도 하는데(EvoSkill은 Gemma에서 33.9→29.8로 하락), WikiSkill은 대부분의 조합에서 안정적으로 오른다.
• 모델이 클수록 이득이 크다. Qwen 계열에서 스킬 진화의 평균 이득은 4B +12.3점, 9B +17.5점, 27B +23.9점. 스킬 진화는 모델 스케일링의 대체재가 아니라 보완재다.
• 스킬이 모델 격차를 뒤집는다. 스킬을 든 Qwen 9B(47.4%)가 맨몸의 Qwen 27B(39.4%)를 이긴다. 극단적으로는 Gemini 3.5 Flash가 LiveMath에서 33.0%→72.6%, SpreadsheetBench에서 50.5%→76.6%까지 오른다.

스킬은 전이된다 — 단, 조건이 있다

개인적으로 이 논문에서 가장 실무적인 발견은 교차 모델 전이 실험이다. A 모델이 진화시킨 스킬을 B 모델에게 주면 어떻게 되는가.

되는 경우가 많고, 심지어 자기 스킬보다 낫기도 하다. Qwen 27B가 만든 스킬을 받은 9B는 ALFWorld에서 70.2%를 찍는다 — 자기가 직접 진화시킨 스킬(63.4%)보다 높다. 작은 모델이 만든 스킬이 큰 모델을 올리는 역방향도 성립한다(4B 스킬이 Gemma 31B를 LiveMath 33.9%→73.1%로).

안 되는 경우의 원인도 명확하다. 4B가 만든 SpreadsheetBench 스킬을 Gemini Flash에게 주면 50.5%→18.1%로 폭락한다. 오류 분석 결과, 작은 모델이 자기 실행 실패를 피하려고 넣은 저수준 우회책(한 줄짜리 파이썬 강제, 문자열 변환 규칙)이 강한 모델의 자연스러운 풀이를 막아 버린 것이다.

여기서 나오는 교훈: 스킬 발견과 스킬 실행은 별개의 능력이다. 스킬에는 일반적 절차 지식을 담아야 하고, 특정 모델의 약점을 덮는 우회책은 담지 말아야 한다. 담더라도 분리해서 표시해야 한다.

어블레이션 — 위키는 누구에게 줘야 하나

Gemini Flash로 위키 접근 권한을 조합별로 껐다 켠 결과가 흥미롭다.

두 가지가 보인다.

1. 스킬 제안자에게 위키를 주는 것이 결정적이다. 48.7 → 63.7, +15.0점. 누적된 지식 없이는 제안자가 복잡한 실패 모드를 풀지 못한다.
2. 추론 에이전트에게 위키를 주면 오히려 나빠진다. 63.7 → 60.9. 에이전트가 태스크 풀이 지식을 스킬이 아니라 위키에서 직접 얻어 버리면, 실행 기록이 "스킬이 실제로 얼마나 유효한지"를 반영하지 못하게 되기 때문이다. 지식층은 개발 도구이지, 런타임 치트시트가 아니다.

실무 적용 — 우리 스킬 운영에 옮기기

Claude Code든 자체 에이전트 하네스든, 스킬을 운영하는 조직이라면 이 논문에서 다섯 가지를 바로 가져갈 수 있다.

1. 회고를 스킬에 바로 쓰지 마라. 지식층을 분리하라. 에이전트가 실패할 때마다 SKILL.md를 고치면, 근거가 스킬 파일 안에서 뒤섞여 사라진다. 실패 패턴은 위키(패턴 문서)에 먼저 쌓고, 스킬은 그 위키를 근거로 고쳐라.
2. 기각된 수정도 기록하라. "이 변경은 해봤는데 검증 점수가 떨어졌다"가 남아 있어야 같은 제안이 반복되지 않는다. 스킬 수정 이력에 diff·결과·사유를 남기는 skill-impact.md 하나면 된다.
3. 스킬 갱신에 게이트를 걸어라. 대표 태스크 몇 개를 검증 세트로 고정하고, 스킬을 고칠 때마다 돌려서 점수가 오를 때만 채택하라. 점수가 없으면 스킬은 "그럴듯한 문서"에서 벗어나지 못한다.
4. 스킬은 큰 모델로 진화시키고, 작은 모델에 이식하라. 전이 실험이 보여주듯 절차 지식은 모델을 넘어 이동한다. 비싼 모델로 스킬을 다듬고 싼 모델로 실행하는 구성이 실제로 성립한다. 단, 모델 전용 우회책이 섞이지 않게 스킬 리뷰에서 걸러야 한다.
5. 런타임 에이전트에게 지식층을 열지 마라. 위키는 스킬을 만드는 쪽(제안자·관리자)만 본다. 실행하는 에이전트는 스킬만 든다. 이 경계가 무너지면 스킬의 품질 신호 자체가 오염된다.

가이드 프롬프트 — 바로 쓰는 4종 세트

아래는 WikiSkill 구조를 자기 프로젝트에 이식할 때 쓰는 프롬프트다. Claude Code 기준으로 썼지만 어떤 에이전트 하네스에서든 동작한다. 먼저 워크스페이스 구조를 만든다.

mkdir -p agent-workspace/raw agent-workspace/wiki/patterns agent-workspace/skills
touch agent-workspace/wiki/index.md agent-workspace/wiki/logs.md agent-workspace/wiki/skill-impact.md

① 위키 관리자 프롬프트 — 실행 기록이 쌓일 때마다(또는 하루 한 번) 돌린다.

너는 위키 관리자다. 에이전트의 실행 기록을 지식으로 정리하는 것이 네 역할이다.

입력:
- raw/ 아래의 최근 실행 기록 (성공 사례와 실패 사례를 모두 포함해서 골라 읽어라)
- wiki/ 아래의 기존 패턴 문서, index.md, logs.md

할 일:
1. 실패한 기록마다 근본 원인을 분석하라. 증상이 아니라 원인을 적어라.
2. 성공한 기록에서 반복 가능한 전략을 추출하라.
3. wiki/patterns/ 아래에 패턴 문서를 만들거나 고쳐라. 문서 하나 = 실패 모드
   하나 또는 성공 전략 하나. 각 문서에는 반드시 포함하라:
   - 현상: 언제 이 패턴이 나타나는가
   - 근거: 어떤 실행 기록에서 관찰됐는가 (파일명·태스크 ID)
   - 대응: 실행 가능한 구체적 해법 또는 회피법
4. 기존 문서는 통째로 다시 쓰지 말고 증분으로 고쳐라 (추가·교체·삽입).
5. 패턴을 만들거나 고쳤으면 wiki/index.md 목록을 갱신하고,
   wiki/logs.md 맨 아래에 이번 회차의 발견을 3줄 이내로 append하라.

금지:
- raw/ 파일 수정 금지 (읽기 전용)
- skills/ 수정 금지 (그건 스킬 제안자의 일이다)
- 근거 없는 일반론 금지 — 모든 패턴은 실제 기록을 인용해야 한다

② 스킬 제안자 프롬프트 — 위키가 갱신된 뒤 돌린다.

너는 스킬 제안자다. 누적된 위키 지식을 근거로 스킬을 개선하는 것이 네 역할이다.

입력:
- wiki/index.md (패턴 목록), wiki/skill-impact.md (과거 제안 이력)
- 최근 태스크 성적 요약 (무엇이 통과하고 무엇이 실패했는지)
- 필요하면 wiki/patterns/ 문서와 raw/ 원본 기록을 직접 골라 읽어라

할 일:
1. skill-impact.md를 먼저 읽어라. 이미 기각된 방향의 제안을 반복하지 마라.
2. 가장 큰 실패 묶음을 하나 고르고, 관련 패턴 문서와 원본 기록으로 원인을
   확정하라.
3. 수정안을 정확히 1건만 내라: 기존 스킬 하나에 대한 증분 패치, 또는
   새 스킬 1개 신설. 여러 스킬을 한 번에 건드리지 마라.
4. 새 스킬에는 SKILL.md와 함께 PURPOSE.md를 만들어라. PURPOSE.md에는
   이 스킬이 어떤 위키 패턴(파일명)에서 나왔는지 적어라.

스킬 작성 규칙:
- 일반적 절차 지식만 담아라. 특정 모델의 약점을 덮는 저수준 우회책
  (예: "무조건 한 줄 파이썬으로", 문자열 변환 강제)은 스킬을 다른 모델로
  옮길 때 성능을 깎는다. 꼭 필요하면 "모델 한정 주의"로 분리 표기하라.
- 안티패턴을 명시하라: "X를 하지 마라. 대신 Y를 하라" 형식이 잘 전이된다.
- 길이는 150줄 이내. 스킬은 문서가 아니라 절차다.

③ 게이팅 체크리스트 — 수정안을 받아들이기 전에 사람(또는 검증 스크립트)이 확인한다.

스킬 수정안 게이트 — 아래를 전부 통과할 때만 병합한다.

1. 검증 세트를 돌렸는가? 고정된 대표 태스크 N개(권장 10개 이상)에서
   수정 전/후 점수를 비교했는가?
2. 점수가 기존 최고치보다 올랐는가? 같거나 낮으면 롤백한다.
3. 채택이든 기각이든, wiki/skill-impact.md에 다음을 append했는가?
   - 날짜 / 대상 스킬 / 수정안 diff 요약 / 검증 점수 / 채택 여부와 사유
4. 롤백하더라도 wiki/는 건드리지 않는다. 위키는 절대 리셋하지 않는다.

④ 스킬 전이 리뷰 프롬프트 — 스킬을 다른 모델·다른 팀 에이전트로 옮기기 전에 돌린다.

아래 SKILL.md를 검토하라. 이 스킬은 다른 모델에서 실행될 예정이다.

찾아낼 것:
1. 특정 모델의 실행 약점을 덮는 저수준 우회책 — 특정 문법 강제,
   불필요하게 잘게 쪼갠 진단 절차, 도구 호출을 낭비하는 중복 확인 단계
2. 일반 절차로 승격할 수 있는 부분과, "원 모델 한정"으로 격리해야 할 부분
3. 실행 예산을 넘길 위험 — 상호작용 횟수가 제한된 환경에서 단계 수가
   과도하지 않은가

출력: 이식 가능 버전의 SKILL.md 수정안과, 제거·격리한 항목의 목록.

한계 — 논문이 스스로 적은 것

• 스킬 검색이 없다. 실험에서는 스킬 전체를 프롬프트에 통째로 주입한다. 스킬이 수십 개로 늘면 어떤 스킬을 언제 불러올지가 새 문제가 된다.
• 게이트가 엄격하다. 당장 점수를 올리는 제안만 통과시키므로, 지금은 중립이지만 다음 반복의 발판이 될 제안은 버려진다.
• 위키를 가지치기하지 않는다. 패턴과 로그가 무한정 쌓인다. 긴 운영에서는 오래된 지식을 정리하는 장치가 필요해진다.

그래도 방향은 분명하다. 에이전트를 잘 쓰는 조직과 그렇지 않은 조직의 차이는 이제 모델이 아니라, 경험을 지식으로 컴파일하는 파이프라인이 있느냐로 갈린다. 스킬 파일 몇 개를 손으로 관리하는 단계를 지나고 있다면, raw·wiki·skills 세 폴더부터 만들어 보라. AX Ops 방법론 →

참고

• Tang et al. (Google Research), "WikiSkill: Compiling Agent Experience into Persistent Knowledge for Skill Evolution", 2026년 8월 27일: https://arxiv.org/abs/2608.27454
• Karpathy, "LLM Wiki" — 논문이 출발점으로 삼은 관점: https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f
• Anthropic, "A complete guide to building skills for Claude": https://claude.com/blog/complete-guide-to-building-skills-for-claude
• 비교 대상이 된 스킬 진화 프레임워크 — EvoSkill: https://arxiv.org/abs/2603.02766 · Trace2Skill: https://arxiv.org/abs/2603.25158