에이전트 경험을 위키로 모아 스킬을 키웁니다 | DAKER 커뮤니티
2026년 8월 27일 Liyan Tang 연구팀이 에이전트 실행 경험을 위키에 모아 스킬을 같이 키우는 WikiSkill을 arXiv에 공개했습니다. 에이전트 스킬은 지식과 작업 순서를 묶어 다시 쓰는 자원입니다. 그 스킬을 키우는 단서는 대개 최적화 기록 안에 흩어져 있어, 다음 라운드에서 다시 쓰기 어렵습니다. WikiSkill은 날것 실행 경험과 쌓인 지식과 실행 가능한 스킬을 나누고, 경험을 위키에 모은 뒤 그 위키 위에서 스킬을 고칩니다.
논문은 2026년 8월 27일 arXiv에 올라왔습니다. 초록은 arXiv:2608.27454에서 확인할 수 있습니다. 저자는 Liyan Tang, Cyrus Rashtchian, Chun-Sung Ferng, Andrew Tomkins, Da-Cheng Juan, Tu Vu입니다. PDF는 같은 번호의 pdf입니다. 오늘 본문은 초록이 적은 범위만 옮깁니다. 초록에 없는 벤치 이름과 퍼센트는 쓰지 않습니다.
스킬과 위키를 같이 키웁니다
에이전트 스킬은 특정 지식과 작업 순서를 재사용 자원으로 포장합니다. 최근 연구는 에이전트 경험에서 그런 스킬을 자동으로 찾아, 상호작용을 거듭하며 적응하게 합니다. 문제는 스킬을 고치는 통찰이 최적화 기록 여기저기에 남는다는 점입니다. 한 라운드에서 배운 이유가 다음 라운드의 스킬 파일에 붙지 않으면, 같은 실패를 다시 밟습니다. 해커톤 팀에서도 같은 일이 납니다. 에이전트가 고친 패치와 실패한 호출은 로그에 남아 있고, 다음 제출용 스킬 문서에는 그 이유가 빠져 있습니다.
WikiSkill은 스킬과 지속 위키를 같이 키우는 틀입니다. 위키는 실행이 끝난 뒤에 지워지는 메모가 아닙니다. 이후 스킬 갱신이 밟고 올라가는 지식 자리입니다. 초록은 경험을 위키에 계속 모으고, 그 위키를 다음 스킬 갱신의 바탕으로 둔다고 적습니다. 스킬만 고치고 지식 자리를 비우면, 다음 라운드는 다시 날것 로그만 보게 됩니다. 위키만 쌓고 실행 파일로 옮기지 않으면, 에이전트는 읽기만 하고 일을 끝내지 못합니다. 두 줄을 같이 키우는 설계가 이 논문의 출발입니다.
DACON 코드 제출 대회나 DAKER 해커톤처럼 며칠 안에 에이전트를 여러 번 돌리는 자리에서는, 이 구분이 바로 제출 품질로 이어집니다. 첫날 로그를 둘째 날 스킬에 붙이지 못하면 같은 오류를 반복합니다. 반대로 위키에 실패 이유와 성공 순서를 남기면, 다음 제출은 그 문장을 읽고 시작합니다. 오늘 글이 팀에 남기는 한 줄은 이것입니다. 스킬 파일과 위키를 한 저장소에 두고, 실행이 끝날 때마다 위키부터 고치십시오.
경험과 지식과 실행 파일을 나눕니다
초록이 적은 분리는 세 층입니다. 첫째는 날것 실행 경험입니다. 호출, 도구 결과, 실패 스택, 성공 패치가 여기 들어갑니다. 둘째는 쌓인 지식입니다. 경험을 정리한 위키 문장이 여기 들어갑니다. 셋째는 실행 가능한 스킬입니다. 에이전트가 실제로 불러 쓰는 절차와 규칙이 여기 들어갑니다. 세 층을 한 파일에 섞으면, 다음에 무엇을 고쳐야 하는지 가려내기 어렵습니다. 로그를 스킬로 바로 복사하면 중복과 위험한 단계가 같이 들어갑니다.
WikiSkill은 경험을 위키로 모은 뒤, 그 위키를 이후 스킬 갱신에 씁니다. 순서가 중요합니다. 실행이 끝나면 먼저 위키를 고치고, 위키가 안정된 뒤에 스킬을 고칩니다. 스킬을 먼저 고치면 한 번의 성공이 과하게 일반화됩니다. 위키를 건너뛰면 다음 모델이나 다음 과제에서 같은 경험을 다시 모아야 합니다. 해커톤 저장소에서는 이 세 층을 폴더로 나누는 편이 안전합니다. raw 로그, wiki 문서, skills 실행 파일을 같은 커밋에 올리되, 서로 덮어쓰지 마십시오.
이 분리는 사람 팀의 인수인계와도 같습니다. 누가 어떤 오류를 봤는지는 경험입니다. 그 오류가 왜 났고 다음에 무엇을 피해야 하는지는 지식입니다. 다음 사람이 그대로 실행할 체크리스트는 스킬입니다. 세 문장을 한 채팅에 섞어 두면 다음 주 팀이 읽을 수 없습니다. 위키는 사람이 읽고, 스킬은 에이전트가 실행합니다. 둘 다 공개 링크로 남겨야 제출이 됩니다.
큰 모델과 작은 모델 모두에 쓰입니다
초록은 여러 벤치와 여러 모델에서 WikiSkill이 최신 스킬 진화 방법보다 앞섰고, 스킬이 없는 기준선보다도 대부분의 모델·벤치 조합에서 나아졌다고 적습니다. 벤치 이름과 퍼센트는 초록에 없습니다. 오늘 본문에도 넣지 않습니다. 팀이 받아갈 문장은 방향입니다. 스킬을 같이 키우는 쪽이, 스킬 없이 모델만 키우는 쪽보다 이 실험에서 앞섰습니다.
스킬 진화는 모델 크기 확대와 같이 갑니다. 큰 모델이 진화한 스킬에서 이득을 더 크게 봅니다. 동시에 작은 모델이 스킬을 가지면, 스킬이 없는 훨씬 큰 모델을 이길 수 있습니다. 이 두 문장은 같이 읽어야 합니다. “큰 모델만 쓰면 된다”는 요약이 아닙니다. “작은 모델은 스킬이 필요 없다”는 요약도 아닙니다. 해커톤에서 큰 API만 고집할 이유가 이 초록만으로는 서지 않습니다. 작은 로컬 모델에 위키와 스킬을 붙인 뒤, 큰 모델 기준선과 같은 과제로 비교하는 실험이 이 논문이 가리키는 자리입니다.
DACON 코드 대회처럼 제출 횟수와 시간이 정해진 자리에서는, 모델 교체보다 스킬 정리가 더 싼 경우가 많습니다. 큰 모델로 하루를 다 쓰기 전에, 작은 모델로 위키를 먼저 채우십시오. 위키가 쌓이면 큰 모델은 그 문장을 읽고 시작합니다. 초록이 말한 “보완”이 여기 있습니다. 모델 크기와 스킬은 서로 대신하는 선택이 아니라, 같이 올리는 두 축입니다.
다른 모델이 만든 스킬도 옮깁니다
진화한 스킬은 모델과 모델 가족 사이로 옮겨집니다. 다른 모델이 키운 스킬이, 자기 모델이 키운 스킬보다 나을 수 있습니다. 이 문장은 팀에 바로 쓰입니다. 우리 모델만의 로그로 스킬을 만들어야 한다는 가정이 깨집니다. 다른 팀이 공개한 스킬과 위키를 받아, 우리 과제에 맞게 고치는 실험이 성립합니다. 반대로 우리 위키를 공개하면 다른 모델 위의 제출에도 쓰일 수 있습니다.
옮긴다는 말은 파일을 복사하고 끝이라는 뜻이 아닙니다. 위키가 없으면 스킬만 넘어가고 이유는 빠집니다. 초록의 제거 실험은 지속 위키가 스킬 진화에 핵심이라고 확인합니다. 위키를 빼면 이 틀의 이득이 줄어듭니다. 따라서 이전 팀의 스킬을 받을 때는 위키도 같이 받으십시오. 위키 없이 스킬만 받는 복사는, 이 논문이 핵심이라고 한 층을 버린 복제입니다.
DAKER와 DACON처럼 여러 팀이 비슷한 과제를 나누어 푸는 자리에서는, 스킬 이전 실험이 공개 기록으로 남기 좋습니다. 한 모델이 키운 스킬을 다른 모델에 붙여 같은 과제를 다시 돌리고, 위키를 같이 붙인 경우와 스킬만 붙인 경우를 나란히 적으십시오. 승패를 퍼센트로 과장하지 않습니다. 초록도 퍼센트를 주지 않았습니다. 무엇이 옮겨졌고 무엇이 빠졌는지를 한 표에 남기는 것이 오늘 할 일의 핵심입니다.
위키를 공개 기록으로 남깁니다
지속 위키가 핵심이라면, 위키는 채팅이 아니라 주소가 있는 문서여야 합니다. 최적화 기록에만 남기면 초록이 지적한 흩어짐이 다시 납니다. 해커톤 기간이 짧을수록 이 습관이 빨리 무너집니다. 밤에 고친 이유를 아침에 다른 팀원이 못 읽으면, 그 이유는 없는 것과 같습니다. 위키 문장은 짧게 쓰되, 실패 이유와 다음 행동과 쓰지 말 도구를 빠뜨리지 마십시오. 세 항목이 한 페이지에 보이면 다음 스킬 갱신이 그 페이지를 밟을 수 있습니다.
스킬 이전 실험을 공개할 때도 같은 주소를 씁니다. 다른 모델이 키운 스킬이 자기 스킬보다 나을 수 있다는 문장은, 파일이 열려 있을 때만 검증됩니다. 비공개 드라이브에만 두면 이전이 재현되지 않습니다. DAKER와 DACON 제출은 다른 사람이 열 수 있는 링크를 요구합니다. 위키와 스킬과 비교 표를 한 저장소에 두고, 커밋 해시에 날짜를 남기십시오. 오늘 본문은 퍼센트를 짓지 않습니다. 무엇이 옮겨졌는지만 적으면 됩니다.
사람 리뷰를 위키에 붙이는 일도 이 틀과 맞습니다. 에이전트가 모은 경험은 날것이고, 사람이 고친 문장은 지식입니다. 그 문장이 실행 파일로 내려가면 스킬이 됩니다. 세 층을 한 커밋에 올리되, 누가 위키를 고쳤는지를 한 줄로 남기십시오. 자동 로그만 쌓고 사람 문장이 없으면 위키는 비어 있는 폴더입니다. 비어 있는 위키 위에서 스킬을 고치는 일은, 제거 실험이 약한 이유로 든 바로 그 운영입니다.
위키 문장을 쓸 때는 한 번의 성공을 일반 규칙으로 올리지 마십시오. 날것 경험은 그 실행에만 참입니다. 지식으로 올리려면 같은 실패가 한 번 더 보이거나, 사람이 이유를 확인한 뒤에 올리십시오. 확인 없이 올린 규칙은 다음 스킬을 잘못된 방향으로 고칩니다. 해커톤처럼 시간이 짧은 자리일수록 이 절제가 필요합니다. 빠른 커밋이 잘못된 지식을 고정합니다. 위키에 날짜와 확인자를 남기면, 나중에 그 문장을 되돌릴 수 있습니다.
실행 파일을 고칠 때는 위키의 어느 문장을 반영했는지 주석 한 줄을 남기십시오. 주석이 없으면 스킬과 위키가 다시 어긋납니다. 어긋난 상태는 최적화 기록에 통찰이 흩어진 상태와 같습니다. 이 논문이 피하려는 바로 그 상태입니다. 공개 저장소에서는 주석이 다음 기여자의 읽기 시작점입니다. 내부 채팅에만 남긴 이유는 제출이 아닙니다.
모델 가족 사이로 스킬을 옮길 때도 같은 절제를 유지하십시오. 다른 모델이 키운 스킬이 더 나을 수 있다는 문장은, 우리 과제에서 한 번 확인한 뒤에야 운영 규칙이 됩니다. 확인 없이 외부 스킬을 기본값으로 두면, 우리 위키가 비게 됩니다. 빈 위키 위의 외부 스킬은 제거 실험이 약한 이유로 든 구성입니다. 외부 스킬을 받더라도 위키는 우리 과제로 다시 쓰십시오.
오늘 팀이 위키를 비우고 스킬만 고치면, 내일 다른 사람이 그 스킬을 읽어도 이유를 모릅니다. 이유를 모르는 스킬은 다시 최적화 기록 속으로 들어갑니다. 그 순환을 끊는 일이 이 글을 읽는 이유입니다. 위키를 먼저 고치십시오.
위키를 먼저 고치는 순서를 오늘부터 적용하십시오.
이 글이 아닌 것입니다
특정 벤치 점수표가 아닙니다. 초록은 여러 벤치와 여러 모델에서 앞섰다고 적되, 벤치 이름과 숫자를 적지 않습니다. 오늘 본문에 벤치 이름을 지어내지 않습니다. “우리 대회 점수와 같다”고 바꾸어 쓰지 않습니다.
퍼센트 이득을 숫자로 준 글도 아닙니다. 큰 모델이 이득을 더 보고, 작은 모델이 스킬을 가지면 훨씬 큰 모델을 이길 수 있다는 방향만 있습니다. 없는 비율을 README에 넣지 않습니다.
위키 없이 스킬만 키우면 된다는 처방이 아닙니다. 제거 실험은 지속 위키가 핵심이라고 확인합니다. 스킬 파일만 커밋하고 위키를 비우는 운영은 이 논문의 주장이 아닙니다.
특정 회사 제품 출시 공지가 아닙니다. 연구 논문입니다. 에이전트 플랫폼이 오늘 이 기능을 켰다고 적힌 글이 아닙니다. 제품 로드맵에 이 제목을 그대로 옮기지 않습니다.
사람 없이 에이전트만 돌리면 끝나는 이야기도 아닙니다. 위키는 사람이 읽고 고치는 지식 자리로 쓰입니다. 로그를 자동 저장만 하고 문장을 정리하지 않으면, 다음 스킬 갱신이 밟을 바탕이 없습니다.
오늘 할 일
첫째, 초록과 PDF를 직접 여십시오. arXiv:2608.27454와 pdf를 같은 탭에 둡니다. 요약 카드만 보고 스킬 폴더를 만들지 않습니다. 저자 여섯 이름과 제출일 2026-08-27을 메모 첫 줄에 적습니다.
둘째, 저장소를 raw·wiki·skills 세 폴더로 나누십시오. 날것 로그, 정리한 지식, 실행 파일을 한 디렉터리에 섞지 않습니다. 오늘 실행이 끝나면 wiki 문장부터 고치고, 그다음에 skills를 고칩니다. 순서를 바꾸면 한 번의 성공이 스킬에 과하게 들어갑니다.
셋째, 해커톤 과제 하나를 골라 위키 뼈대를 만드십시오. DAKER 월간 해커톤이나 DACON 코드 제출 과제 가운데 하나를 고릅니다. 실패 이유, 성공 순서, 쓰지 말 도구를 위키에 세 문장으로 남깁니다. 채팅에만 남긴 문장은 다음 라운드에 사라집니다.
넷째, 작은 모델에 스킬을 붙인 실행과 큰 모델 기준선을 같은 과제로 비교하십시오. 초록은 작은 모델이 스킬을 가지면 훨씬 큰 모델을 이길 수 있다고 적습니다. 우리 과제에서 그런지 확인하는 표가 필요합니다. 없는 퍼센트를 채워 넣지 않습니다. 승패와 실패 유형만 적습니다.
다섯째, 다른 모델이 키운 스킬을 받아 우리 모델에 붙여 보십시오. 위키를 같이 받은 경우와 스킬만 받은 경우를 나란히 돌립니다. 초록의 제거 실험이 가리키는 층이 위키입니다. 위키를 뺀 복제가 약해지는지 기록합니다.
여섯째, 스킬 진화 라운드를 날짜와 커밋으로 고정하십시오. 어느 위키 문장이 어느 스킬 갱신을 만들었는지 한 줄로 남깁니다. 최적화 기록에만 남기면 이 논문이 지적한 흩어짐이 다시 납니다.
일곱째, 만든 위키와 스킬을 공개 링크로 올리십시오. DAKER와 DACON에는 빌더와 대회 기록이 쌓여 있습니다. 배포가 제출입니다. 올린 링크가 제출입니다.