AI가 일을 하며 겪은 실수와 성공을 정리해 두고, 다음번에 쓸 작업 안내서를 계속 고치는 방법을 제안한 논문입니다.

AI가 일을 하며 겪은 실수와 성공을 정리해 두고, 다음번에 쓸 작업 안내서를 계속 고치는 방법을 제안한 논문입니다.

무엇이 문제였나 — AI의 성공과 실패 기록은 되어도, 다음 작업 안내서에는 잘 이어지지 않았습니다. 어떻게 풀었나 — 실행 기록에서 반복되는 문제와 효과적인 방법을 위키에 모은 뒤 안내서를 고치고, 검증 점수가 좋아질 때만 새 안내서를 채택합니다. 그래서 뭐가 좋아졌나 — 다섯 과제와 다섯 모델에서 기존 방법보다 평균 성능이 높았고, 작은 모델이 더 큰 모델의 기본 성능을 넘기도 했으며, 다른 모델이 만든 스킬이 자기 모델의 스킬보다 잘 맞기도 했습니다.

새 일을 할 때마다 이전 담당자의 작업 일지와 실수 기록을 읽고 더 나은 안내서를 만드는 팀과 비슷합니다. 새 안내서가 시험 점수를 높이지 못하면 되돌리지만, 일지와 배운 내용은 남겨 다음 개선에 씁니다.

논문 정보

Liyan Tang, Cyrus Rashtchian, Chun-Sung Ferng, Andrew Tomkins, Da-Cheng Juan, Tu Vu · Google Research, Virginia Tech · arXiv preprint · 2026

왜 중요한가

사람이 매번 같은 실수를 다시 발견하지 않도록 업무 기록을 남기듯, AI도 실행 경험을 다음 작업에 활용할 수 있습니다. 모델 자체를 다시 훈련하지 않고 작업 안내서만 바꾸므로, 시험해 본 스킬을 다른 모델에도 적용할 가능성이 있습니다.

핵심 지표

어떻게 동작하나

WikiSkill은 경험을 원시 실행 기록, 구조화된 위키 지식, 실행 가능한 스킬의 세 층으로 나눈다. 각 반복에서 추론 에이전트는 현재 스킬을 사용해 훈련 과제를 풀되 위키에는 접근하지 않고, 위키 관리자는 성공·실패 표본 기록을 분석해 반복 패턴과 대응책을 위키에 누적한다. 스킬 제안자는 갱신된 위키와 해당 반복의 훈련 결과를 살펴 필요할 때 원본 기록을 직접 읽어 한 번에 하나의 스킬만 바꾸는 변경안을 만든다. 변경안은 검증 점수가 기존 최고점보다 높을 때만 채택되며, 거부되어도 위키와 변경 이력은 유지된다. 평가는 5개 벤치마크와 5개 모델에서 수행했고, 결과는 전체 진화 파이프라인을 3번 독립 실행한 테스트 성능의 평균이다. paired bootstrap 검정은 1,000회 반복과 p < 0.05 기준으로 적용했다. 최적화 단계는 전체 훈련 세트를 한 번에 처리하며, 반복당 최적화 API 호출은 1+T_ReAct회로 N_train과 무관한 O(1)이다.

핵심 수식:

τ_i ∼ π(x_i; S_{k−1})
W′_k ← M_WM(W_{k−1}, T^{sample,k})
P_k ← M_P(W′_k, S_{k−1}, T^{train,k})
S′_k ← Apply(S_{k−1}, P_k)
S_k ← S′_k if R(T^{val,k}) > R_best; S_{k−1} otherwise
W_k ← Update(W′_k, P_k, R(T^{val,k}), a_k)

S_k는 활성 스킬 집합, P_k는 단일 스킬을 대상으로 하는 원자적 제안, R은 분할 실행 점수의 평균, M_WM과 M_P는 각각 위키 관리자와 스킬 제안자이다. W′_k는 위키 관리자가 만든 중간 위키이고 W_k는 변경 이력까지 기록된 최종 위키이다. T^{train,k}, T^{sample,k}, T^{val,k}는 각각 훈련 기록, 표본 기록, 검증 기록이며 a_k는 Accepted 또는 Rejected 결과다. R_best는 빈 스킬의 검증 점수로 초기화되고 변경이 채택되면 갱신된다. 스킬이 거부되어도 W_k는 되돌리지 않는다.

한계와 주의할 점

• 활성 스킬을 추론 에이전트 프롬프트에 직접 주입하므로, 스킬 수가 늘어날 때 필요한 검색·호출·선택 성능은 평가하지 않았습니다.
• 검증 점수가 엄격히 개선될 때만 변경을 채택해, 당장의 점수는 같지만 다음 반복의 기반이 될 수 있는 중립적 변경을 놓칠 수 있습니다.
• 위키 패턴과 제안 이력이 계속 쌓이지만 자동 정리·삭제 기능은 없어 장기 실행에서 규모와 관리 비용이 커질 수 있습니다.
• 수백 단계 또는 수 시간 지속되는 장기 작업과 한 번의 실행 중 온라인 스킬 적응은 평가 범위에 포함되지 않았습니다.
• 작은 검증 분할은 채택 판단에 변동성을 줄 수 있으며, 논문은 이를 독립 실행 반복과 paired bootstrap으로 다루지만 운영 환경의 분포 변화까지 검증하지는 않습니다.
• 모델별 임시 우회책이 스킬에 굳어지면 다른 모델로 옮겼을 때 유용한 절차를 막는 부정적 전이가 생길 수 있습니다. 예를 들어 Qwen-3.5-4B의 SpreadSheet 스킬은 Gemini-3.5-Flash 점수를 50.5에서 18.1로 낮췄습니다.
• 세부 단계가 지나치게 많거나 반복적이면 도구 호출 예산을 소진해 작업을 끝내지 못할 수 있습니다. 논문은 분절된 진단 절차가 Gemini-3.5-Flash의 상호작용 예산을 소모한 사례를 보고합니다.
• 긴 문서 환경에서 모델이 상세한 검색 절차를 따르지 않고 기본 읽기 방식으로 돌아가면 스킬의 효과가 줄어들 수 있습니다.
• 검증 집합의 점수 변동으로 유망한 변경이 거부되거나 일시적으로 좋은 변경이 채택될 가능성이 있습니다.

시스템 적용 아이디어

논문의 기법을 비슷한 구조를 가진 시스템에 옮길 때의 적용 지점이다.

교차 모델 검증을 통과한 절차만 공용 스킬로 승격

WikiSkill의 위키 기반 제안과 검증 후 채택을 유지하되 제안 스킬을 배포 대상 모델 여러 종류에서 함께 평가합니다. 특정 모델에서 점수가 오르더라도 다른 모델에서 크게 떨어지면 공용 스킬로 승격하지 않고 모델 한정 스킬로 표시합니다. 논문은 SpreadSheet에서 Qwen-3.5-4B 스킬이 Gemini-3.5-Flash 성능을 50.5%에서 18.1%로 낮춘 반면, Qwen-3.6-27B 스킬을 적용한 Gemini-3.5-Flash는 63.4%를 기록한 사례를 보여줍니다.

적용 지점 — 스킬 변경의 검증·배포 게이트

기대 효과 — 논문 수치로 정량화된 추가 이득은 없으며, 모델 간 부정적 전이를 배포 전에 발견하는 효과를 기대할 수 있습니다.

스킬 절차에 반복 호출·상호작용 예산 검증 추가

WikiSkill의 단일 스킬 변경 검증 단계에 반복 행동과 상호작용 예산 점검을 추가합니다. ALFWorld 사례처럼 같은 물건에 같은 작업을 반복하는 패턴을 위키에 기록하고 Skill Proposer가 이를 구체적인 행동 규칙으로 바꾸도록 합니다. 제안 스킬은 검증 과제에서 성공 여부와 반복 루프 발생 여부를 함께 확인해 채택합니다. 논문은 구체적인 반복 방지 규칙이 추상적 제안 뒤에 채택된 사례를 제시합니다.

적용 지점 — 다단계 도구 에이전트의 실행 종료·반복 행동 검사

기대 효과 — 논문 수치로 정량화된 추가 이득은 없으며, 반복 행동으로 인한 작업 미완료와 도구 호출 낭비를 줄이는 효과를 기대할 수 있습니다.

위키 패턴에 근거·적용 범위와 오래된 정보 표시

WikiSkill의 패턴 페이지마다 근거가 된 실행 기록, 모델·과제 범위, 마지막 확인 시점을 연결합니다. 위키 관리자가 새 흔적을 반영할 때 기존 패턴을 갱신하고 중복 패턴을 표시하며 Skill Proposer는 관련 근거가 있는 패턴을 우선 읽도록 합니다. 이는 논문에서 위키 정리 기능이 없고 장기 누적 시 자동 가지치기가 필요하다고 밝힌 한계를 직접 보완합니다.

적용 지점 — 장기 에이전트 기억의 패턴 저장·회수

기대 효과 — 논문 수치로 정량화된 추가 이득은 없으며, 위키 장기 확장 시 오래되거나 중복된 절차가 스킬 제안에 섞이는 위험을 줄이는 효과를 기대할 수 있습니다.

단계별 도입 로드맵

원문 PDF: 2026-08-28-wikiskill-compiling-agent-experience-into-persistent-knowledge-for-skill.pdf