WikiSkill: 에이전트 실행 경험을 위키에 모아 스킬을 함께 키우는 방법 | DAKER 커뮤니티
에이전트를 여러 번 돌리다 보면, 잘된 실행보다 왜 실패했고 무엇을 고쳤는지가 더 중요해지는 순간이 옵니다. 문제는 이런 통찰이 대개 로그와 최적화 기록 곳곳에 흩어져 남는다는 점입니다. 다음 라운드에서 다시 써야 할 이유와 맥락이 스킬 파일에 붙지 않으면, 같은 실수를 반복하기 쉽습니다.
2026년 8월 27일 Liyan Tang 연구팀이 arXiv에 공개한 WikiSkill은 바로 이 지점을 다룹니다. 날것의 실행 경험, 그 경험을 정리한 지식, 실제로 실행 가능한 스킬을 나누고, 경험을 지속 위키에 모은 뒤 그 위키를 바탕으로 스킬을 갱신하는 틀입니다. 이 글은 arXiv:2608.27454의 초록 범위 안에서만 정리합니다.
논문은 2026년 8월 27일 arXiv에 올라왔습니다. 저자는 Liyan Tang, Cyrus Rashtchian, Chun-Sung Ferng, Andrew Tomkins, Da-Cheng Juan, Tu Vu입니다. PDF는 같은 번호의 pdf에서 볼 수 있습니다.
스킬만이 아니라 위키도 함께 자랍니다
에이전트 스킬은 특정 지식과 작업 순서를 묶어 재사용 가능한 자원으로 만든 것입니다. 최근 연구는 에이전트 경험에서 이런 스킬을 자동으로 찾아내고, 상호작용을 거듭하며 적응시키는 방향으로 발전해 왔습니다. 다만 스킬을 고치는 데 필요한 통찰은 대개 최적화 기록 안에 흩어져 남습니다. 한 라운드에서 배운 이유가 다음 라운드의 스킬에 연결되지 않으면, 에이전트는 같은 실패를 다시 밟게 됩니다.
WikiSkill은 날것 실행 경험과 쌓인 지식과 실행 가능한 스킬을 나누고, 경험을 위키에 모은 뒤 그 위키 위에서 스킬을 고칩니다.
이 틀에서 위키는 실행이 끝난 뒤 사라지는 메모가 아닙니다. 이후의 스킬 갱신이 밟고 올라가는 지식의 자리입니다. 스킬만 고치고 지식 자리를 비워 두면 다음 라운드는 다시 로그를 처음부터 읽어야 합니다. 반대로 위키만 쌓고 실행 파일로 옮기지 않으면, 에이전트는 읽을 수는 있어도 실제 작업을 끝내기 어렵습니다. 그래서 이 논문은 스킬과 위키를 함께 키우는 구조를 출발점으로 둡니다.
경험, 지식, 실행 파일을 분리합니다
초록이 제시하는 핵심 분리는 세 층입니다. 첫째는 날것의 실행 경험입니다. 호출 기록, 도구 결과, 실패 스택, 성공 패치가 여기에 들어갑니다. 둘째는 쌓인 지식입니다. 경험을 정리한 위키 문장이 이 층을 이룹니다. 셋째는 실행 가능한 스킬입니다. 에이전트가 실제로 불러 쓰는 절차와 규칙이 여기에 해당합니다.
이 세 층을 한 파일에 섞어 두면, 다음에 무엇을 고쳐야 하는지 구분하기 어려워집니다. 로그를 곧바로 스킬로 옮기면 중복이나 우연한 성공 사례까지 함께 굳어질 수 있습니다. WikiSkill은 먼저 경험을 위키로 모으고, 그 위키를 이후의 스킬 갱신에 활용합니다. 이 순서가 중요합니다. 실행이 끝나면 위키를 먼저 고치고, 그다음에 스킬을 다듬는 방식입니다.
실행이 끝나면 먼저 위키를 고치고, 위키가 안정된 뒤에 스킬을 고칩니다.
이 분리는 사람 팀의 인수인계와도 닮아 있습니다. 누가 어떤 오류를 봤는지는 경험이고, 그 오류가 왜 났으며 다음에 무엇을 피해야 하는지는 지식입니다. 다음 사람이 그대로 실행할 수 있는 체크리스트는 스킬입니다. 셋을 한데 섞어 두면 다음 기여자가 읽기 어려워집니다.
큰 모델과 작은 모델 모두에 의미가 있습니다
초록에 따르면 WikiSkill은 여러 벤치와 여러 모델에서 최신 스킬 진화 방법보다 앞섰고, 스킬이 없는 기준선보다도 대부분의 모델·벤치 조합에서 더 나은 결과를 보였습니다. 다만 초록에는 벤치 이름과 퍼센트가 제시되지 않으므로, 여기서도 그 범위를 넘지 않습니다.
중요한 점은 방향입니다. 스킬을 함께 진화시키는 접근이, 스킬 없이 모델 자체에만 의존하는 방식보다 이 실험들에서 더 나았다는 것입니다. 또한 스킬 진화의 이득은 큰 모델에서 더 크게 나타났고, 동시에 작은 모델도 스킬을 갖추면 스킬이 없는 훨씬 큰 모델을 이길 수 있다고 초록은 설명합니다.
모델 크기와 스킬은 서로를 대신하는 선택지가 아니라 함께 올릴 수 있는 두 축입니다.
이 문장은 큰 모델만 쓰면 된다는 뜻도 아니고, 작은 모델에는 스킬이 필요 없다는 뜻도 아닙니다. 오히려 모델의 크기와 별개로, 잘 정리된 위키와 스킬이 성능을 끌어올리는 중요한 자원이 될 수 있다는 점을 보여줍니다.
다른 모델이 만든 스킬도 옮길 수 있습니다
초록은 진화한 스킬이 모델과 모델 가족 사이에서 이전될 수 있다고 말합니다. 더 나아가 다른 모델이 키운 스킬이, 자기 모델이 직접 키운 스킬보다 더 나을 수도 있다고 설명합니다. 이는 스킬을 반드시 같은 모델의 로그로만 만들어야 한다는 가정을 흔듭니다.
다만 여기서도 핵심은 위키입니다. 스킬만 복사하면 절차는 옮겨갈 수 있어도, 왜 그런 절차가 생겼는지에 대한 이유는 빠질 수 있습니다. 초록의 제거 실험은 지속 위키가 스킬 진화에 핵심이라는 점을 확인합니다. 따라서 스킬 이전은 단순한 파일 복사가 아니라, 위키와 함께 맥락을 옮기는 일에 가깝습니다.
위키를 빼고 스킬만 옮기면 이 틀의 핵심 층이 빠집니다.
지속 위키는 공개된 기록이어야 합니다
지속 위키가 핵심이라면, 위키는 채팅창에 흘러가는 메모가 아니라 주소가 있는 문서여야 합니다. 최적화 기록에만 남겨 두면 초록이 지적한 흩어짐이 다시 생깁니다. 특히 짧은 기간에 반복 실행이 많은 환경일수록, 밤에 고친 이유를 다음 사람이 아침에 읽을 수 있어야 위키가 실제로 기능합니다.
위키 문장은 길지 않아도 됩니다. 다만 실패 이유, 다음 행동, 피해야 할 도구나 절차 같은 정보는 빠지지 않는 편이 좋습니다. 사람이 읽고 정리한 문장이 지식이 되고, 그 지식이 실행 파일로 내려가면 스킬이 됩니다. 이 세 층이 연결되어 있어야 다음 갱신이 같은 자리를 다시 밟을 수 있습니다.
또한 위키 문장을 곧바로 일반 규칙으로 올리는 데에는 주의가 필요합니다. 한 번의 성공은 그 실행에만 해당할 수 있습니다. 같은 실패가 반복되거나 사람이 이유를 확인한 뒤에 지식으로 올려야, 다음 스킬이 잘못된 방향으로 굳어지는 일을 줄일 수 있습니다.
이 글이 다루지 않는 범위
이 글은 특정 벤치의 점수표를 정리한 글이 아닙니다. 초록에는 여러 벤치와 여러 모델에서 앞섰다는 설명이 있지만, 벤치 이름과 숫자는 제시되지 않습니다. 따라서 없는 수치를 덧붙이지 않습니다.
또한 퍼센트 이득을 숫자로 소개하는 글도 아닙니다. 큰 모델이 더 큰 이득을 보고, 작은 모델도 스킬을 갖추면 훨씬 큰 모델을 이길 수 있다는 방향만 초록에 있습니다.
무엇보다 위키 없이 스킬만 키우면 된다는 처방도 아닙니다. 초록의 제거 실험은 지속 위키가 핵심이라고 말합니다. 스킬 파일만 남기고 위키를 비워 두는 운영은 이 논문의 주장과 거리가 있습니다.
참고 자료
여러분은 에이전트 실험 기록을 로그, 위키, 스킬 가운데 어디에 가장 많이 남기고 계신가요?