논문을 읽고 "좋다"로 끝나는 경우가 대부분이다. 구글 리서치가 8월 27일 공개한 WikiSkill 논문도 그렇다. 구조는 명쾌하고 수치는 인상적이다. 그런데 이 구조를 내가 운영하는 에이전트의 메모리 시스템에 어떻게 옮길지는 논문에 적혀 있지 않다. 논문은 5개 벤치마크를 돌리기 위한 인프라이고, 내 프로젝트는 그게 아니기 때문이다.
이 글은 그 간극을 프롬프트 하나로 메운다. Claude Code에 붙여 넣으면 논문 PDF를 읽고, 내 코드의 메모리 관련 모듈을 분석하고, 적용 포인트를 우선순위별로 뽑아 확인을 받은 뒤, 승인한 항목만 구현하고, 커밋·푸시·릴리즈 노트까지 쓴다. 프롬프트 전문, 문장마다 넣은 이유, 2단계에서 어떤 결과가 나오는지 예시, 그리고 다른 논문에 재사용하는 법까지 정리했다.
WikiSkill 논문 자체의 구조와 수치, 실험 결과는 지난 글에서 다뤘다. 이 글은 그 다음 단계, 즉 논문을 내 코드에 반영하는 파이프라인에 집중한다.
WikiSkill이 바꾸는 것 — 30초 요약
WikiSkill의 핵심은 "에이전트의 경험을 어디에, 어떻게 쌓느냐"다. 논문은 이를 디렉터리 세 개로 물리적으로 분리한다.
- raw/ — 실행 기록 원본. 추론·도구 호출·결과가 전부 남고, 한 번 쓰면 수정하지 않는다.
- wiki/ — 기록에서 뽑은 패턴과 진화 로그. 절대 리셋하지 않고 복리로 쌓인다.
- skills/ — 에이전트가 실제로 드는 절차 지침서. 검증 게이트를 통과할 때만 갱신되고, 성능이 떨어지면 롤백된다.
이 구조 하나로 Gemini 3.5 Flash 기준 평균 정확도가 48.7%에서 63.7%로 올랐다. 더 중요한 발견은 어블레이션에 있다. 위키를 스킬 제안자에게 주면 15점이 오르지만, 태스크를 실행하는 에이전트에게 열어 주면 오히려 떨어진다. 지식층은 개발 도구이지 런타임 치트시트가 아니다. 메모리 시스템을 설계하는 사람이라면 이 한 줄이 가장 큰 시사점이다.
이 대응표는 어디까지나 예시다. 실제로 내 시스템의 어떤 파일이 어느 층에 해당하는지를 찾아내는 것이 프롬프트 1단계의 일이다.
프롬프트가 하는 일 — 5단계, 그리고 한 번의 정지
프롬프트는 에이전트를 다섯 단계로 굴린다. 핵심은 2단계에서 반드시 멈춘다는 점이다.
- 현재 상태 파악 — 논문을 읽고, 내 시스템의 핵심 구조와 메모리 관련 코드를 읽은 뒤, 시스템이 어떻게 동작하는지 5줄 내외로 요약한다. 이 요약이 틀리면 뒤가 전부 틀리므로 여기서 한 번 읽어 볼 가치가 있다.
- 적용 포인트 도출 — 논문의 아이디어를 우선순위별로 정리한다. 항목마다 논문의 어떤 개념인지, 내 시스템의 어떤 파일에 해당하는지, 기대 효과·난이도·리스크, 메모리 영역인지 그 외 영역인지를 적는다. 여기서 멈추고 확인을 받는다.
- 구현 — 승인한 항목만 반영한다. 테스트가 있으면 돌리고, 없으면 최소 동작을 확인한다.
- 커밋 & 푸시 — 변경 단위별로 커밋하고 현재 브랜치에 푸시한다.
- 릴리즈 노트 — CHANGELOG.md에 버전·날짜, 사용자 관점의 변경 요약, 참고 논문 출처, 마이그레이션 안내를 적는다.
사용 순서
| 순서 | 할 일 | 비고 |
|---|---|---|
| 1 | arXiv에서 논문 PDF를 받는다 | https://arxiv.org/abs/2608.27454 |
| 2 | 메모리 시스템이 있는 프로젝트에서 새 브랜치를 판다 | git checkout -b paper/wikiskill |
| 3 | Claude Code를 열고 PDF를 프로젝트 폴더에 넣거나 채팅창에 드래그한다 | Claude Code는 PDF를 직접 읽는다 |
| 4 | 아래 프롬프트의 [논문 제목/파일명]을 실제 파일명으로 바꿔 붙여 넣는다 |
예: wikiskill.pdf |
| 5 | 2단계에서 멈추면 적용 포인트를 읽고 승인할 번호만 답한다 | "1, 2, 4만 진행" |
| 6 | 끝나면 CHANGELOG.md와 git log를 확인한다 |
마음에 안 들면 브랜치를 버리면 된다 |
프롬프트 전문
첨부한 논문 [논문 제목/파일명]을 읽고, 이 시스템에 적용할 만한 개선 포인트를
찾아 반영해줘.
## 관심사
메모리 관리(저장·검색·갱신·요약 방식)를 우선적으로 보되, 논문에서 그 외
영역(에이전트 협업, 컨텍스트 처리, 평가 방식 등)에도 적용 가치가 있는 내용이
있으면 함께 제안해줘.
## 진행 순서
1. 현재 상태 파악: 핵심 구조와 메모리 관련 코드를 먼저 읽고, 시스템이
어떻게 동작하는지 5줄 내외로 요약.
2. 적용 포인트 도출: 논문의 아이디어를 우선순위별로 정리. 각 항목마다
- 논문의 어떤 개념인지
- 현재 시스템의 어떤 파일/모듈에 해당하는지
- 기대 효과 / 구현 난이도 / 리스크
- 메모리 관련인지, 그 외 영역인지
여기서 한 번 멈추고 나한테 확인받아.
3. 구현: 내가 승인한 항목만 반영. 기존 동작을 깨지 않도록 테스트가 있으면
실행, 없으면 최소 동작 확인.
4. 커밋 & 푸시: 변경 단위별로 커밋 후 현재 브랜치에 push.
5. 릴리즈 노트: CHANGELOG.md(없으면 생성)에
- 버전/날짜
- 변경 요약(사용자 관점)
- 참고 논문 출처
- 마이그레이션 필요 시 안내
## 제약
- 논문 개념을 그대로 이식하지 말고 이 시스템 규모에 맞게 단순화.
- 대규모 리팩토링 금지. 구조를 바꿔야 한다면 이유를 먼저 설명.
문장마다 막으려는 실패가 있다 — 설계 원칙 3가지
이 프롬프트는 짧지만, 각 줄은 에이전트에게 논문을 넘겼을 때 실제로 겪은 실패를 하나씩 막는다.
| 프롬프트의 문장 | 막는 실패 | 왜 |
|---|---|---|
| "이 시스템 규모에 맞게 단순화" | 논문 인프라를 통째로 복제 | 논문은 5개 벤치마크 × 5개 모델용 구조다. 메모리 파일 수십 개짜리 프로젝트에 위키 관리자·스킬 제안자·게이트를 전부 세우면 유지비가 이득을 넘는다. |
| "여기서 한 번 멈추고 확인받아" | 혼자 달려 대규모 리팩토링 | 에이전트는 적용 포인트를 뽑는 순간 구현으로 넘어가려 한다. 정지 지점을 명시하지 않으면 승인 없이 디렉터리 구조까지 바꾼다. |
| "메모리 관리를 우선적으로 보되 … 함께 제안" | 관심사 누락 또는 과잉 확장 | 관심사를 하나로 고정하면 논문의 다른 쓸 만한 발견(전이 리뷰, 평가 게이트)을 놓친다. 열어 두되 우선순위를 준다. |
| "변경 단위별로 커밋" | 되돌릴 수 없는 한 덩어리 커밋 | 항목 3개를 승인했다면 커밋도 3개여야 한다. 하나가 문제일 때 그것만 revert할 수 있다. |
| "구조를 바꿔야 한다면 이유를 먼저 설명" | 조용한 구조 변경 | 에이전트는 종종 "이게 더 깔끔해서" 폴더를 옮긴다. 설명을 강제하면 근거 없는 변경이 사라진다. |
2단계에서 어떤 표가 나오는가 — 예시
파일 기반 메모리(디렉터리 안에 사실 하나당 마크다운 파일 하나, 인덱스 파일이 매 세션 로드되는 구조)를 가진 프로젝트에 이 프롬프트를 돌리면 대략 아래와 비슷한 표가 나온다. 실제 결과는 시스템마다 다르지만, 어떤 수준의 제안을 기대해야 하는지 기준으로 삼기 좋다.
| 우선순위 | 논문 개념 | 내 시스템의 해당 위치 | 기대 효과 / 난이도 / 리스크 | 영역 |
|---|---|---|---|---|
| 1 | wiki는 절대 리셋하지 않는다 | 메모리 압축·정리 루틴 | 오래된 메모리를 삭제 대신 archive/로 이동. 효과 큼 / 난이도 낮음 / 리스크 낮음 | 메모리 |
| 2 | skill-impact.md — 기각된 제안도 기록 | 규칙 파일(CLAUDE.md) 변경 이력 | "해봤는데 안 됐다"를 남겨 같은 제안 반복 차단. 효과 중 / 난이도 낮음 / 리스크 없음 | 메모리 |
| 3 | 검증 게이트 통과 시만 skills 갱신 | 규칙·스킬 파일 수정 절차 | 대표 태스크 5~10개를 고정해 규칙 변경 전후 비교. 효과 큼 / 난이도 중 / 리스크: 검증 세트 유지비 | 평가 |
| 4 | raw는 불변 | 세션 로그 저장 방식 | 요약본으로 원본을 덮어쓰지 않도록 분리. 효과 중 / 난이도 낮음 / 리스크: 저장 용량 | 메모리 |
| 5 | 런타임 에이전트에게 wiki를 열지 않는다 | 세션 시작 시 로드되는 컨텍스트 | 인덱스만 로드하고 본문은 필요 시 검색. 이미 그렇게 동작하면 "변경 없음"으로 표시 | 컨텍스트 |
| 6 | 스킬 전이 리뷰 | 모델 교체·팀 간 스킬 공유 시 | 모델 전용 우회책 분리 표기. 효과 중 / 난이도 낮음 / 리스크 낮음 | 협업 |
이 표를 받으면 답은 짧게 한다. "1, 2, 4 진행. 3은 검증 세트를 먼저 만든 뒤 다음에. 5는 변경 없음 확인." 이 한 줄이 3단계의 입력이 된다.
끝나면 이렇게 남는다 — CHANGELOG 예시
5단계가 끝나면 CHANGELOG.md에 아래 형태의 항목이 생긴다. 사용자 관점 요약과 논문 출처가 같이 남는 것이 중요하다. 반년 뒤에 "이 archive 폴더는 왜 있지?"라는 질문에 파일 하나로 답할 수 있어야 한다.
## [0.4.0] - 2026-09-02
### Changed
- 메모리 정리 시 오래된 항목을 삭제하지 않고 memory/archive/로 이동
- 규칙 파일 변경 이력을 memory/rule-impact.md에 기록 (채택·기각 모두)
- 세션 로그 원본을 요약본과 분리 저장 (logs/raw/, logs/summary/)
### Reference
- Tang et al., "WikiSkill: Compiling Agent Experience into Persistent
Knowledge for Skill Evolution", arXiv:2608.27454 (2026-08-27)
### Migration
- 기존 삭제된 메모리는 복구되지 않음. 이후 정리분부터 archive/에 누적.
커밋 로그도 함께 확인한다. 승인한 항목 수와 커밋 수가 같아야 정상이다.
이 프롬프트는 WikiSkill 전용이 아니다
[논문 제목/파일명]만 바꾸면 어떤 논문이든 된다. "관심사" 단락을 바꾸면 메모리가 아니라 다른 영역에도 쓸 수 있다. 자주 쓰는 변형 세 가지다.
| 관심사 | 바꿔 넣을 문장 | 어울리는 논문 유형 |
|---|---|---|
| 평가 방식 | "에이전트 산출물의 평가·게이팅 방식(검증 세트 구성, 채택·롤백 기준)을 우선적으로 보되…" | 스킬 진화, 자기 개선 루프 |
| 컨텍스트 처리 | "컨텍스트 예산 관리(무엇을 언제 로드하고 무엇을 요약하는지)를 우선적으로 보되…" | 장문 맥락, 압축, 검색 |
| 에이전트 협업 | "역할 분리와 정보 격리(어떤 역할이 무엇을 볼 수 있는지)를 우선적으로 보되…" | 멀티 에이전트, 오케스트레이션 |
나머지 진행 순서와 제약은 그대로 둔다. 논문이 바뀌어도 "2단계에서 멈춘다"와 "규모에 맞게 단순화한다"는 바뀔 이유가 없다.
실행 전 확인 세 가지
- 새 브랜치에서 시작한다. 작업 중인 브랜치에서 돌리면 되돌리기가 어렵다. 브랜치를 버리는 것이 revert 세 번보다 싸다.
- 숫자를 그대로 믿지 않는다. 48.7%에서 63.7%는 논문의 벤치마크·모델 조합에서 나온 수치다. 내 시스템에서 같은 폭의 개선이 나온다는 보장은 없다. 3번 항목(검증 게이트)을 먼저 만들어야 내 숫자가 생긴다.
- 1단계 요약을 읽는다. 에이전트가 내 시스템을 잘못 이해한 채로 2단계 표를 만들면, 그럴듯하지만 엉뚱한 제안이 나온다. 5줄 요약이 틀리면 거기서 바로잡고 다시 돌린다.
논문을 읽는 습관보다, 논문을 내 코드에 반영하는 파이프라인이 중요하다. 이 프롬프트는 그 파이프라인의 최소 형태다. 조직의 에이전트 메모리·스킬 운영 체계를 설계하고 싶다면 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
- AX LABS, "WikiSkill 논문 리뷰 — 에이전트 경험을 위키로 쌓아 스킬을 자동 진화시키는 법": /blog/wikiskill-paper-review-agent-skill-evolution
- 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
