스킬은 고칠수록 나빠질 수 있다 — EviSkill은 재연으로 거른다

스킬을 경험으로 고치면 오히려 퇴보하기 쉽다. EviSkill은 문제가 됐던 장면만 다시 실행해, 효과가 확인된 수정만 반영한다.
日本語  ·  한국어
← 목록으로
온
온틀 리서치
2026년 10월 07일 수정 2026.10.16 읽기 13분 조회 2

일을 오래 한 사람일수록 "예전에 이렇게 했더니 되더라" 하는 요령이 많다. 그런데 그 요령이 딱 한 번의 성공에서 나온 것이라면, 비슷해 보이는 다음 일에 그대로 들이댔다가 오히려 망치기도 한다. 한 번의 경험을 규칙으로 착각한 탓이다.

AI 에이전트도 똑같다. 모델을 다시 학습시키지 않고도, "이 앱은 이렇게 쓴다", "이 실험은 이 순서로 한다" 같은 요령을 글로 적어주면 일을 더 잘한다. 이 요령 문서를 스킬(skill)이라 부른다. 모델 바깥에 두고 필요할 때 꺼내 보는 절차서 같은 것이다. 그리고 에이전트가 경험을 쌓아 이 절차서를 한 번 손보는 주기를 에폭(epoch)이라 한다. 에폭을 거듭할수록 스킬이 좋아지리라는 게 상식적인 기대다.

문제는 그 기대가 자주 어긋난다는 데 있다. 실패에서 배워 고칠수록 좋아져야 할 것 같지만, 실제로는 손대기 전보다 나빠지는 일이 흔하다. 위의 베테랑처럼, 에이전트도 한 번의 경험을 섣불리 규칙으로 박아 넣기 때문이다. 그렇다면 이걸 우리 일에 옮기면 어떤 의미일까 — 이 질문은 뒤에서 온틀의 사례로 다시 짚겠다.

지린대학교 연구진(Yan Zhou 외)이 내놓은 EviSkill은 여기에 간단한 규칙을 세운다. 스킬을 고칠 때마다 문제가 됐던 바로 그 장면을 수정안으로 다시 실행해보고, 실제로 행동이 나아질 때만 반영한다는 것이다. 세 벤치마크·여섯 종 LLM에서 검증했더니 대부분의 조합에서 가장 높은 성공률을 냈다. 특히 눈길을 끄는 건, 다른 자동 수정 방법들이 같은 조건에서 오히려 초기 스킬보다 성능이 떨어지는 퇴보를 보일 때, EviSkill은 그 자리에서 가장 높은 점수를 냈다는 점이다.

해법: 근거를 세우고, 재연으로 거른다

EviSkill은 기존 자동 수정 방식의 두 가지 구멍을 겨냥한다. 하나는 수정의 근거가 사라지는 것, 다른 하나는 거부된 수정 묶음을 통째로 버리는 것이다. 아래 세 단계가 각각 이 구멍을 어떻게 막는지 따라가 보면, 기존 방식이 왜 퇴보했는지도 자연스럽게 드러난다.

1단계 — 증거 카드로 근거를 붙든다. 기존 방식은 관찰을 곧바로 "이렇게 고쳐라"로 바꾼다. 그러면 왜 이 문장을 바꿨는지, 어떤 상황이 그 변경을 정당화했는지가 사라진다. 반년 뒤 "이 단계는 왜 들어갔나"를 물으면 답할 길이 없다. EviSkill은 관찰을 먼저 증거 카드로 정리한다. 카드 한 장에는 추적용 식별자, 이 수정을 뒷받침하는 실행 구간(어느 과제의, 어느 에폭의, 몇 번째 스텝부터 몇 번째까지인지), 그리고 제안된 교정이 담긴다. 수정을 만들 때는 그 수정이 어떤 카드에 기대는지 링크를 걸어둔다. 근거가 수정과 함께 남는 것이다. 카드가 끝없이 쌓이지는 않는다. 쓰임이 다한 카드는 수명이 차면 밀려나고, 반복해서 거부된 카드는 새 수정을 만들 때 제외된다.

2단계 — 문제 장면만 재연해 검증한다. 여기서 EviSkill은 다른 방법과 갈라진다. 다른 연구들은 실행 기록에서 그럴듯한 교훈을 뽑아 곧장 스킬에 반영한다. 하지만 경험에서 나온 수정이라고 늘 개선을 보장하지는 않는다. 논문의 사전 연구가 이걸 실측으로 보여준다. 경험에서 뽑은 수정을 원래 스킬에 적용하고 그 과제를 다시 돌렸더니, 성능이 오르는 것도 있었지만 그대로이거나 오히려 떨어뜨리는 것도 있었다. 그래서 EviSkill은 반영 전에 한 단계를 끼운다. 카드의 구간 정보로 그 장면 직전까지의 상태와 대화 이력을 복원한 뒤, 수정된 스킬 아래에서 그 구간만 다시 실행한다. 전체 과제를 처음부터 돌리는 게 아니라, 막혔던 장면만 콕 집어 재연하는 것이다. 그런 다음 평가자(판정을 맡은 LLM)가 원래 장면과 재연 장면을 비교해 셋 중 하나로 판정한다. 새 실패 없이 의도한 교정이 성립하면 수용, 결함이 보이지만 다듬을 만하면 보류, 그 외는 거부. 보류된 수정은 한 번 손본 뒤 다시 재연·재평가한다.

3단계 — 에폭을 넘겨 다시 따진다. 재연을 통과했다고 바로 확정하지는 않는다. EviSkill은 스킬을 두 벌로 굴린다. 하나는 검증 성능이 오를 때만 갱신하는 보수적인 확정 스킬, 다른 하나는 재연으로 뒷받침된 수정을 잠정적으로 얹어 여러 에폭에 걸쳐 지켜보는 시험 스킬이다. 깨끗한 정본과, 아직 실험 중인 초안을 따로 두는 셈이다.

이 두 벌 구조가 두 번째 구멍, 곧 묶음 폐기를 막는다. 기존 방식은 한 라운드에서 거부된 수정 묶음을 통째로 버린다. 그 안에 쓸 만한 교정이 섞여 있어도 함께 사라진다. 그러나 논문의 사전 연구를 보면, 묶음 전체가 거부됐더라도 그 안의 일부 수정만 골라 남기면 이전에 통과한 스킬보다 성능이 올랐다. 그래서 EviSkill은 묶음이 거부돼도 그 안의 수정을 하나씩 따로 재연해, 다른 잠정 수정에 기대지 않고 그것만으로도 효과가 있는지 확인한 뒤 통과한 것만 건진다. 정해진 에폭이 끝나면 확정 스킬만 얼려 실제 사용에 쓰고, 끝내 확정되지 못한 잠정 수정은 뺀다.

경험 주도 방식 중 가장 가까운 SkillOpt는 "검증 점수가 오르는 수정만 받아들인다"는 하나의 관문만 둔다. EviSkill은 그 관문은 그대로 두되, 그 앞에 재연 점검과 거부된 수정의 재심의라는 층을 더 깐 셈이다.

실험은 이렇게 설계됐다

평가 무대는 상호작용형 벤치마크 세 개다. 앱 API로 과제를 수행하는 AppWorld(168개 과제), 과학 실험을 다루는 ScienceWorld(211개), 텍스트 환경에서 가사 과제를 푸는 ALFWorld(134개). 세 데이터셋 모두 학습·검증·테스트를 겹치지 않게 나눠, 학습셋으로 스킬을 고치고 검증셋으로 채택 여부를 정하며 테스트셋으로 최종 평가한다. 지표는 과제 성공률(%) 하나다.

에이전트의 행동을 실제로 만들어내는 LLM, 곧 백본은 GPT 계열과 Qwen 계열 여섯 종을 썼다. 비교 대상은 두 묶음이다. 스킬을 안 쓰는 NoSkill과 초기 스킬을 고정으로 쓰는 LLM Skill이 '진화하지 않는' 기준선이고, Trace2Skill·EvoSkill·SkillGrad·SkillOpt가 '스킬을 고쳐 나가는' 경쟁 방법이다.

결과: 똑똑한 수정이 많은 수정을 이긴다

첫 번째 메시지는 EviSkill이 대체로 가장 잘했다는 것이다. 18개 모델-데이터셋 조합 중 14개에서 최고, 16개에서 상위 2위 안에 들었고, 모든 조합에서 NoSkill을 앞섰다(NoSkill 대비 평균 +17.93%p). 다만 이 평균은 출발점이 제각각인 조합을 묶은 값이라 단일 설정의 성과로 읽으면 안 된다. 우위가 두드러진 예로, ScienceWorld·Qwen3.5-9B에서 EviSkill은 37.91%로 그 설정의 최강 기준선(SkillOpt 22.27%)을 15.64%p 앞섰다.

두 번째 메시지가 더 무겁다. 스킬을 고친다고 초기 버전보다 나아진다는 보장이 없다는 것이다. 한 최신 GPT 계열 모델을 ScienceWorld에 돌린 결과를 보면, 초기 스킬이 76.78%인데 Trace2Skill은 65.40%, EvoSkill은 54.50%, SkillGrad는 67.30%로 오히려 떨어졌다. 아무것도 안 고친 쪽만도 못한 결과다.

왜 이런 일이 벌어질까. 한 번의 실행에서 뽑은 교훈은, 그 상황에만 있었던 우연한 사정까지 '규칙'으로 오해하기 쉽다. 그 교훈이 절차서에 박히면 이후 모든 과제가 그 편향된 규칙을 거쳐 풀린다. 한 사례의 특수성이 전체의 기본값이 되는 것이다. 이미 답을 아는 사람이 초심자가 어디서 막히는지 상상하지 못하는 '지식의 저주'처럼, 한 장면에서 배운 스킬은 그 장면 바깥을 보지 못한 채 시스템 전체에 잘못된 편향을 주입한다. 섣부른 학습일수록 손해가 더 깊어지는 이유다. 같은 설정에서 EviSkill이 83.41%에 도달하고, 전체적으로 초기 스킬 대비 17개 설정에서 개선·1개에서 동률을 낸 것은, 수정을 행동으로 검증하고 확정은 보수적으로 가져가는 관문이 바로 이 함정을 걸러내기 때문이다.

두 장치가 각자 제 몫을 한다는 것도 확인됐다. GPT 백본 3종 평균 기준으로, 재연 검증을 빼면 세 벤치마크에서 평균 정확도가 각각 2.49·4.56·2.85%p 내려갔다. 에폭을 넘는 재심의를 없앤 조건에서도 성능이 내려갔다. 논문은 이 결과를 두 장치가 서로 겹치지 않고 독립적으로 기여한다는 근거로 제시한다.

한계와 남은 질문

저자들이 직접 인정한 부분부터. AppWorld에서는 경쟁 방법 대비 우위가 덜 일관적이다. 앞서 본 최신 GPT 모델을 AppWorld에 돌리면 EviSkill 94.64%는 LLM Skill 94.05%와 큰 차이가 없고, Qwen3.5-9B·AppWorld에서는 EviSkill 43.45%가 SkillOpt 47.62%에 뒤진다. 방법 자체의 결함이라기보다, API를 조합해 푸는 과제처럼 "행동 재연으로 교정 효과를 깔끔히 분리하기 어려운" 환경이 있다는 신호로 읽는 게 타당하다. 이건 내 해석이다.

측정 범위도 짚어둘 필요가 있다. 지표가 테스트 과제 성공률이므로, "수정이 실제로 작동하는 절차 개선인가"는 잘 재지만, 그 개선이 벤치마크가 다루지 않은 전혀 다른 유형의 과제로까지 번지는 범용성은 이 숫자만으로 단정하기 어렵다. 학습·검증·테스트를 겹치지 않게 나눴으니 테스트 과제 자체를 미리 보는 일은 없지만, 그것과 '배운 적 없는 유형으로의 확장'은 별개의 질문이다.

비용도 실무 도입 전 따로 따져야 할 대목이다. EviSkill은 수정마다 장면을 재연하고, 에폭을 비교하며, 거부된 수정까지 다시 돌려본다. 한 번 추정으로 끝내는 방식보다 재실행이 많다. 논문은 효율 분석을 포함하나, 실제 비용은 쓰는 환경에 따라 달라질 수 있다. 끝으로 평가자·추출자·편집기가 모두 LLM이라는 점은, "이 재연이 교정을 성립시켰는가"를 LLM이 판정하는 구조라는 뜻이어서, 평가자 자신의 편향이 어디까지 걸러지는지는 이 지표만으로 알기 어렵다.

온틀이라면: 거래처 등록 한 장면

처음 던진 질문 — "이게 우리 일에는 무슨 의미일까" — 으로 돌아와 보자. 온틀의 AI PM이 "신규 거래처 등록" 절차를 돌리다, 어느 고객사에서 사업자번호 검증 단계에 막혔다고 하자.

경험 주도 방식이라면 "이 단계 앞에 사업자번호 형식 확인을 넣어라"는 교훈을 바로 절차서에 박는다. 그런데 그 실패가 사실은 그 고객사만의 입력 양식 탓이었다면, 이 수정은 다른 고객에게 불필요한 단계를 강요하고, 그 위에 또 다른 수정이 쌓인다. 한 고객의 특수한 사정이 전사 기본값이 되는 것이다.

EviSkill식은 네 걸음을 밟는다. 먼저 막힌 장면을 증거로 남긴다 — 어느 고객, 어느 작업, 몇 번째 스텝에서 무엇이 막혔는지. 다음으로 절차서 전체를 뜯어고치기 전에 그 장면만 수정 절차로 재연한다. 고친 절차로 돌렸더니 새 문제 없이 통과하면, 수정안 자체는 일단 '그 장면에서는' 성립한 것이다.

그러나 여기서 멈추지 않는 게 핵심이다. 이 통과는 한 고객의 장면을 재연한 결과일 뿐, 그 수정이 전 거래처에 좋은지는 아직 모른다. 그래서 다른 고객 사례까지 포함한 검증셋으로 다시 돌려본다. 여기서 '그 고객만의 사정이었는지' '모두에게 통하는 공통 개선인지'가 갈린다. 국소 재연(막힌 한 장면 되돌리기)과 적용 범위 검증(여러 고객에 걸쳐 따지기)은 이렇게 다른 단계다. 마지막으로, 이 검증에서 지표가 오를 때만 정식 절차로 승격한다.

이 과정에서 눈으로 확인되는 효용은 두 가지다. 한 고객의 특수한 상황에서 나온 수정이 전 거래처 절차로 곧장 번지기 전에 별도 검증이라는 한 겹을 거치게 된다는 것(완전히 막아준다기보다, 통과해야 올라간다는 쪽에 가깝다), 그리고 "왜 이 단계가 들어갔나"를 물으면 언제든 원래 장면으로 답할 수 있다는 것이다.

맺음말

EviSkill이 던지는 물음은 기술보다 태도에 가깝다. 실패가 보일 때마다 절차서에 한 줄씩 덧대며 수정의 '양'을 쌓는 일은 쉽다. 하지만 그 한 줄이 정말 효과가 있는지 문제의 장면에서 되돌려 확인하고, 어디서 나온 수정인지 근거를 함께 남기며, 한 번 부결됐더라도 알맹이만 다시 심의하는 일 — 그렇게 '질'을 담보하는 수정은 번거롭다. EviSkill의 실험이 보여준 건, 그 번거로움을 건너뛴 많은 수정이 아무것도 고치지 않은 것만 못한 자리로 자주 미끄러진다는 사실이다. 고치는 횟수가 아니라, 그 고침이 검증을 통과했는지가 스킬의 운명을 가른다.

참고자료