SkillOpt, SkillAdam, SkillRefiner, skill-up. 이름과 접근 방식은 조금씩 다르지만, 이 프로젝트들이 던지는 질문은 비슷합니다. 에이전트가 자신의 작업 과정을 돌아보고, 그 안에서 얻은 교훈을 다음 작업에 활용할 수 있는 지침으로 바꿀 수 있을까 하는 질문이예요.

하지만, 아시다시피 규칙을 계속 덧붙인다고 해서 곧바로 ‘학습’이 되는 것은 아닙니다. 중요한 것은 지침의 양이 아니라 교훈의 질이니까요. 에이전트는 스스로의 경험으로부터 무엇을 남겨야 할까요? 그 교훈은 지침, 테스트, 도구, 모델 등 다양한 영역 중에 어디에 담아내야 할까요? 그리고 한 에이전트에게 효과가 있었던 방법을 다른 에이전트와 새로운 과제에도 안전하게 적용할 수 있을까요?

이 글에서 말하는 자기개선(Self-Improvement)은, 에이전트가 어느 순간 갑자기 더 똑똑해지는 신비한 과정이 아닙니다. 한 번의 작업에서 다시 활용할 만한 교훈을 찾아내고, 그 교훈을 지침·테스트·도구·모델 중 가장 알맞은 곳에 남긴 뒤, 다른 에이전트가 처음 만나는 과제에서도 실제로 도움이 되는지 검증하는 ‘엔지니어링 과정’입니다. 즉, 한 번의 ‘좋았던 경험’을 다음 실행(run)에서도 통하는 ‘시스템’으로 바꾸는 일이라는 겁니다.

그렇다면 가장 기본적인 질문부터 시작해 보죠.

코딩 에이전트라고 한다면, 작업을 마친 뒤에 무엇을 남겨야 할까요? 우선 무엇보다도, ‘제대로 작동하는 코드’와 그 사실을 입증할 ‘테스트나 실행 결과’가 필수겠죠.

하지만 그게 전부일까요? 작업 세션을 자세히 들여다보면, 최종 결과물에는 드러나지 않지만 다음 과제에 다시 활용할 수 있는 정보가 남아 있는 경우가 많습니다. 어떤 접근 방법이 효과적이었는지, 어디에서 시행착오를 겪었는지, 다음에는 무엇을 먼저 확인하거나 자동화해야 하는지 같은 것들이죠.

에이전트가 자신의 작업 경험을 직접 검토하고, 이를 바탕으로 작업 환경의 개선점을 제안하게 할 수도 있습니다. Matt Pocock의 /retro 스킬이 바로 이런 일을 하죠. 그리고 이 사례가 바로 이 주제를 더 깊이 살펴보게 된 계기이기도 하구요.

Matt의 지침에는 특히 기억해 둘 만한 원칙이 하나 있습니다. 기계적으로 탐지할 수 있는 실수는 자동 검사로 바꾸고, 사람의 판단이 필요한 결정만 글로 된 지침으로 남기라는 겁니다.

이 원칙이 바로 최근에 ‘스킬(Skill)’에 대한 관심이 빠르게 커지는 이유를 이해하기 위한 좋은 출발점이라고 생각합니다. 왜냐하면, 에이전트의 경험에서 무엇을 추출하고, 그것을 절차·테스트·도구·환경 구성의 변화 등 여러 가지 방식 가운데 어떤 형태로 남길지 결정하려면 생각보다 많은 엔지니어링 판단이 필요하기 때문이예요.

최근에는 이런 판단의 일부, 특히 작업 기록과 평가 결과에서 재사용할 만한 교훈을 찾아내고 스킬의 지침을 수정하는 ‘회고의 과정’을 자동화하려는 움직임이 많이 보이는데, Microsoft의 SkillOpt, 중국인민대학교와 Tencent의 SkillAdam, OpenHands의 SkillRefiner가 이런 접근을 탐구하고 있고, Alibaba의 skill-up은 스킬을 비교하고 평가할 수 있는 도구를 제공합니다.

제가 주목하는 것은, 회고 그 자체보다는 그 과정에서 얻은 교훈이 다른 에이전트도 활용할 수 있는 형태로 바뀌는 방식입니다. 예를 들어서 “이 파일을 먼저 확인했더니 문제의 원인을 빠르게 찾을 수 있었다”는 경험을, 다음 작업에서도 적용할 수 있는 검사 순서나 자동화 도구로 만드는 것 등이요.

그런데 여기에 까다로운 문제가 하나 있습니다 - 모든 경험이 다른 작업에도 통하는 교훈은 아닐 테니까요. 그렇다면, 수많은 시행착오 가운데 어떤 것을 재사용할 만한 교훈으로 남겨야 할까요? 특정한 상황에서는 효과적이었던 수정 사항이 다른 상황에서는 새로운 실수를 일으킬 수도 있는 문제를 어떻게 막을 수 있을까요?

그 질문을 염두에 두고, 다음 내용을 차례로 살펴보겠습니다.

이 과정을 구체적으로 이해하기 위해서, 이 글에서 ‘에이전트의 경험을 스킬로 바꾸고 개선하는 것을 도와주는 여러 연구와 도구’ - Microsoft의 SkillOpt, 중국인민대학교와 Tencent의 SkillAdam, OpenHands의 SkillRefiner, Alibaba의 skill-up - 를 살펴볼 겁니다. 그리고 스킬을 프로그램 탐색과 모델 학습으로 확장하는 ShinkaEvolve와 SKILL0도 함께 다뤄보겠습니다.

이들은 모두 ‘스킬’을 다루지만 같은 일을 하는 도구는 아닙니다. SkillOpt와 SkillAdam은 수정한 지침으로 과제를 다시 실행하고, 결과가 좋아졌는지를 확인하면서 스킬을 개선합니다. SkillRefiner는 과제를 다시 실행하는 대신, 이미 끝난 작업의 실행 기록과 실제 결과를 분석해 개선할 지침을 찾아냅니다. Alibaba의 skill-up은 스킬을 사용한 경우와 사용하지 않은 경우를 비교해, 수정된 스킬이 처음 보는 과제에서도 효과가 있는지 평가합니다. SKILL0는 한 단계 더 나아가서, 외부 스킬에 적힌 절차를 모델 학습에 활용한 뒤 그 지침 없이도 같은 행동을 수행할 수 있는지 탐구합니다.

따라서 개별 프로젝트의 내용을 따로 생각해보는 것을 넘어서, 경험에서 교훈을 찾고 → 적절한 형태로 저장하고 → 새로운 과제에서 검증하고 → 다음 실행에 활용하는 전체 흐름을 이해하는 편이 중요하다고 생각합니다.

자, 그럼 오늘의 이야기를 시작해 보겠습니다.

자, 그럼 먼저 Skill이라는게 무엇일까요?

Skill은 단순한 SKILL.md 파일 하나가 아니라, instructions와 supporting files를 함께 담을 수 있는 디렉토리 형태의 묶음입니다. 이 디렉토리의 중심에는 SKILL.md가 있습니다. 파일 상단의 YAML frontmatter에는 필수 메타데이터인 name과 description이 들어가고, 두 번째 --- 아래의 Markdown body에는 에이전트가 실제로 따라야 할 instructions가 들어갑니다.

여기서 description은 단순한 소개 문구가 아닙니다. 이 skill이 무엇을 하는지 뿐 아니라 언제 사용해야 하는지를 알려주는 라우팅 정보입니다. 모델은 먼저 가용한 스킬의 name과 description을 보고 현재 요청에 맞는 skill을 선택합니다. 해당 skill이 선택되면 전체 SKILL.md를 읽고, body에 적힌 워크플로우를 수행합니다.

필요하다면 skill 디렉토리에 references/, scripts/, assets/를 추가할 수도 있습니다. 배경 자료와 평가 기준은 references/에, 반복해서 실행할 검사는 scripts/에, 출력 템플릿이나 예제 파일은 assets/에 둡니다. SKILL.md는 이 파일들을 언제, 어떤 목적으로 사용해야 하는지 설명합니다.

예를 들어 머신러닝 실험을 검토하는 skill은 다음처럼 구성할 수 있습니다.

SKILL.md의 내용은 다음과 같이 구성할 수 있구요.

이 예시에서 YAML frontmatter에 들어 있는 것은 name과 description뿐입니다. # Instructions, ## Workflow, ## Output은 특별한 스키마 필드가 아니라 Markdown body 안의 일반적인 헤딩입니다. 에이전트가 읽기 쉽도록 instructions를 구분한 것이죠.

또, 자동 검사를 수행하는 Python 스크립트 자체가 skill은 아닙니다. review-ml-experiment가 skill이고, script와 rubric, template은 그 skill이 워크플로우를 수행할 때 사용하는 보조 파일들입니다.

예를 들어서, 에이전트에게 “이 머신러닝 실험이 제대로 설계됐는지 검토해 줘”라고 요청했다고 해보죠. 모델은 Python도 알고 실험 설계라는 작업의 기본 원칙도 알고 있습니다. 하지만 이 프로젝트에서 어떤 데이터셋을 기준으로 삼는지, 어떤 script를 실행해야 하는지, 어느 metric을 비교해야 하는지까지 저절로 알 수는 없습니다. Skill은 바로 이런 작업 환경의 지식과 절차를 에이전트에게 제공합니다.

여기서 skill의 역할은 두 가지로 나뉩니다. 하나는 모델이 잘 모르는 분야의 지식이나 작업 방법을 보완하는 것이고, 다른 하나는 모델도 아는 게 있지만, 팀이 원하는 특정한 방식으로 일하게 만드는 것입니다. 예를 들어 “데이터 누출을 검사하라”는 일반적인 원칙을 알려줄 수도 있고, “결과를 승인하기 전에 우리 팀의 evaluation script를 실행하라”는 내부 워크플로우를 지정할 수도 있죠.

Anthropic의 현재 skill-creator에는 skill이 실제로 도움이 되는지 비교하는 evaluation workflow가 포함되어 있습니다. 다만 skill-creator가 좋은 결과의 기준을 스스로 정하는 것은 아닙니다. 작성자가 먼저 테스트 케이스를 만들고, 각 결과에서 확인할 expectation을 정의해야 합니다. 그러면 같은 과제를 with_skill과 without_skill 조건에서 실행한 뒤, grader가 각 expectation의 충족 여부를 근거와 함께 판정합니다. 이렇게 얻은 expectation pass rate와 실행 시간, token 사용량을 비교하면 skill을 적용했을 때 정해 둔 성공 조건을 더 자주 충족하는지, 그 대가로 시간과 token이 얼마나 더 필요한지 살펴볼 수 있습니다.

수정 전후의 skill을 같은 방식으로 비교하면, 변경 사항이 기존 문제를 해결했는지 또는 다른 테스트 케이스에서 새로운 실패 현상이 나타나지 않았는지도 확인할 수 있죠. 다만 이 결과는 어디까지나 작성자가 선택한 테스트 케이스와 expectation 범위 안에서만 유효합니다.

이런 점에서 instructions만 들어 있는 skill은 본질적으로 재사용 가능한 프롬프트 패키지에 가깝습니다. 모델 자체를 학습시키거나 모델의 파라미터를 바꾸는 것이 아니라, 특정한 작업을 시작할 때 필요한 instructions를 불러와 컨텍스트에 추가하는 방식이기 때문이죠. 하지만 skill에는 instructions뿐 아니라 참고자료, 검사 스크립트, 템플릿, 작업 예시와 tool 사용 절차도 함께 넣을 수 있습니다. 에이전트는 필요할 때 이 자료를 읽고 script를 실행하고, 정해진 절차에 따라서 결과를 확인할 수 있습니다. 따라서 이런 요소까지 결합된 skill은 단순히 여러 번 꺼내 쓰는 프롬프트를 넘어서, 반복해서 실행하고 평가하며 개선할 수 있는 워크플로우에 가까워집니다.

Skill에는 적용 범위가 서로 다른 정보가 함께 들어갈 수 있습니다. 예를 들어 “평가에 사용한 데이터가 학습 데이터에 포함되어 있지 않은지 확인하라”는 원칙은 특정한 파일 경로나 저장소 구조에 의존하지 않을 테니, 다른 모델이나 데이터셋을 평가할 때도 같은 원칙을 적용할 수 있죠. 반면에 “experiments/eval/ 폴더에 있는 script를 실행하라”는 instruction은 그 폴더와 스크립트가 존재하는 특정 저장소에서만 작동합니다. 좋은 skill은 이렇게 다른 환경에서도 유효한 원칙과 현재 작업 환경에만 해당하는 실행 방법을 구분해서 설명해야 합니다.

MCP와 비교하면 그 역할이 더 분명해집니다. MCP connection은 에이전트가 실험 기록이나 database를 조회하거나, 외부 tool을 호출할 수 있게 해 줍니다. Skill은 주어진 작업을 처리하기 위해 그 기능을 언제 호출하고 어떤 순서로 사용해야 하는지, 마지막에는 무엇을 확인해야 하는지 설명합니다. MCP가 에이전트에게 사용할 수 있는 기능을 연결한다면, skill은 그 기능을 조합해 작업을 수행하는 절차를 제공하는 셈입니다.

그런데 skill의 내용이 아무리 잘 작성되어 있어도, 필요한 순간에 선택되지 않으면 소용이 없겠죠. 그래서 에이전트는 사용할 수 있는 여러 skill 가운데 현재의 요청과 관련된 것을 먼저 찾아내야 합니다.

에이전트는 지금 어떤 skill이 필요한지 어떻게 판단할까요?

코드 리뷰, 실험 검토, 보고서 작성, 데이터셋 검사를 위한 skill이 하나의 library에 들어 있다고 생각해 봅시다. 각 skill의 description이 충분히 구체적이지 않다면, “검색 pipeline을 검토해 달라”는 하나의 요청이 여러 skill과 관련된 것으로 판단될 수 있겠죠. 코드의 문제를 찾는 일인지, 실험 설계를 점검하는 일인지, 사용한 데이터셋을 검사하는 일인지가 저 요청 만으로는 분명하지 않으니까요.

문제는 skill의 개수 자체가 아니라, 서로 다른 skill이 비슷한 요청에 반응하도록 작성되어 있다는 것입니다. 관련 없는 skill까지 불러오면 에이전트는 실제 작업에 필요하지 않은 instructions까지 함께 읽게 됩니다. 서로 다른 절차나 성공 조건이 섞여 있다면 어느 지침을 따라야 하는지도 불분명해질 수 있구요. 따라서 skill library가 커질수록, 무엇을 담고 있는지만큼 어떤 요청에서 어떤 skill을 선택할 것인지가 중요해집니다.

OpenAI의 skill 작성 가이드도 description에 skill이 수행하는 워크플로우와 활성화 조건을 분명히 적으라고 권합니다. 하나의 skill은 식별 가능한 하나의 목표에 집중하고, 활성화 조건이나 입력, 성공 기준이 다르다면 별도의 skill로 나누라는 것이죠. 세부 정책과 예시, 템플릿, 스크립트 같은 보조 자료는 SKILL.md에 모두 넣기보다 references/, assets/, scripts/로 분리해서 필요한 단계에서만 사용하도록 할 수 있습니다. 예를 들어 database migration skill이라면 database와 관련된 모든 요청이 아니라, schema를 변경하거나 migration file을 작성·검토하는 요청에만 반응하도록 범위를 정해야 합니다.

그런데, 이 문제는 description을 잘 쓰는 것만으로 완전히 해결되지는 않습니다. 일반적인 SKILL.md에는 skill을 언제 선택해야 하는지, 선택한 뒤 어떤 순서로 작업해야 하는지, 각 단계에서 어떤 tool과 resource를 사용하는지가 모두 자연어로 함께 적혀 있어서예요. 에이전트는 이 긴 문서에서 서로 성격이 다른 정보를 다시 구분해 내야 합니다.

Qiliang Liang 등 연구진의 논문 From Skill Text to Skill Structure가 바로 이 문제를 다룹니다. 논문이 제안한 Scheduling–Structural–Logical, 즉 SSL 표현 방식은 하나의 skill 문서에 섞여 있을 수 있는 정보를 다음 세 층으로 나눕니다.

즉, 사람이 읽기 편한 하나의 문서를 그대로 두는게 아니라, 에이전트가 skill을 찾고 실행하고 검토하는 데 필요한 정보를 구조적으로 분리하자는 접근입니다.

물론 구조를 바꾼다고 부실한 skill이 좋아지는 것은 아닙니다. SSL의 normalizer는 원문에 있는 정보를 정리할 뿐이지, 빠진 호출 조건이나 실행 절차를 만들어내지는 않습니다. 다만 어떤 정보가 없거나 서로 모순되는지를 구조적으로 드러내서, 더 쉽게 검색하고 검토할 수 있습니다. 결국 출발점은 여전히 잘 작성된 SKILL.md입니다.

SSL에는 흥미로운 역사적 배경이 있습니다. 이 접근법에서는 Roger Schank와 Robert Abelson이 연구한 ‘script’ 개념을 가져옵니다. 식당에 들어가서 주문하고 계산하는 것처럼, 익숙한 활동에는 일정한 순서와 조건, 다음 단계로 넘어가는 기준이 있다는 생각이죠. 에이전트가 복잡한 절차를 일관되게 해석해야 하는 지금, 오래된 이 아이디어가 다시 활용되고 있는 셈이예요.

SSL을 직접 구현하지 않더라도, 이런 구분은 skill을 설계하는 데 유용합니다. 이 skill은 언제 사용해야 하는지, 어떤 순서로 작업하는지, 어떤 tool과 파일을 다룰 수 있는지, 시작 전에 무엇이 준비되어 있어야 하는지를 분명히 적으라는 것이니까요.

특히 작업을 시작하기 전에 필요한 조건인 preconditions를 분명히 해야 합니다. 예를 들어서 두 가지의 실험을 비교하려면, 우선 같은 평가 기준으로 실행한 결과가 두 개 있어야 합니다. 비교할 결과가 하나 뿐이거나 설정과 로그가 빠져 있다면, instructions가 아무리 자세해도 제대로 된 비교는 안 될 테니까요.

그래서 좋은 skill은 ‘작업 순서’만 알려주지는 게 아닙니다. 작업에 필요한 자료가 모두 준비되어 있는지 먼저 확인하고, 부족하다면 실행을 멈춘 뒤 무엇이 더 필요한지 요청하도록 해야 좋은 skill이라고 할 수 있습니다.

자, 그럼 이제 어떤 skill을 언제 사용할지 정하는 문제에서 한 걸음 더 나아가 보겠습니다. 선택된 skill의 instructions는 어떻게 개선할 수 있을까요?

가장 단순한 방법은, 에이전트에게 실패 사례를 보여주고 “같은 실수를 반복하지 않도록 skill을 고쳐라”라고 요청하는 것이겠죠.

한두 번은 효과가 있을 수 있습니다. 하지만 실패할 때마다 예외 규칙을 추가하면 skill은 점점 길어지고 복잡해집니다. 어떤 규칙이 언제 필요한지도 불분명해지구요. 실패를 모두 기록했지만, 그 실패들 사이의 공통된 원인은 설명하지 못하는 지침서가 나올 수 있습니다.

Microsoft의 SkillOpt는 이런 수정 작업을 을 일정한 절차를 거쳐가면서 진행합니다. 먼저 에이전트가 현재 skill로 여러 과제를 수행해 가면서 baseline을 측정합니다. 그 다음 optimizer가 실행 기록과 결과를 분석해 가면서, 문장을 추가·삭제·교체하는 제한된 수정안을 만드는 거죠.

이 수정안이 곧바로 채택되는 건 아닙니다. 수정 과정에 사용하지 않은 validation set에서 성능을 다시 측정하고, 기존 skill보다 결과가 좋아졌을 때만 받아들이게 되죠. 개선되지 않은 수정 사항은 버리고, 실패 원인은 다음 번 수정 작업에 참고합니다. 대상 모델의 weight는 그대로 두고, 모델이 읽는 skill만 반복해서 개선하는 방식이라고 하겠습니다.

핵심은, 에이전트가 자신의 지침을 고친다는 게 아닙니다. 수정된 지침이 새로운 과제에서도 실제로 더 나은 결과를 만들어 내는지 검증한 뒤에야 채택한다는 것입니다. 이 때의 ‘자기개선’은 단순한 회고나 문서 편집이 아니라 ‘측정 가능한 최적화’ 과정이 됩니다.

이 작업을 하려면 네 가지 요소가 필요합니다.

표현이 매끄러워지거나 규칙이 많아졌다는 사실만으로는 성능이 개선되었다고 할 수 없고, 같은 조건에서 결과가 실제로 나아졌는지를 확인해야 합니다.

그런데, 이런 검증을 거치더라도 수정 작업이 반복되면 새로운 문제가 생깁니다. 이번에 해결한 문제가 다음 수정 단계에서 다시 나타나거나, 일부 과제에 도움이 된 변경 내용이 다른 과제에는 문제가 될 수도 있을 테니까요. 그리고, 중국인민대학교와 Tencent가 2026년 9월 공개한 SkillAdam이 바로 이 문제를 다룹니다.

SkillAdam이라는 이름은, 신경망 학습에 널리 쓰이는 Adam optimizer에서 따온 것이긴 하지만, 문장을 미분하거나 gradient를 계산하는 것은 아닙니다. Adam이 이전 update의 방향과 변화량을 참고하듯이, SkillAdam도 과거 수정 사항의 결과를 기억하고 다음 수정 사항의 방향과 크기를 조절한다는 기능적인 비유라고 보는 것이 더 맞겠습니다.

이 작업 과정에서 SkillAdam은 두 가지 정보를 관리합니다. 먼저 어떤 문제가 발견되었고, 이를 해결하기 위해 무엇을 바꿨는지, 그리고 결과가 어땠는지를 optimization memory에 기록합니다. 이미 해결한 문제가 다시 나타나면 새 문제로 취급하지 않고 기존 기록을 다시 엽니다.

동시에 한 iteration에서 바꿀 수 있는 범위인 edit budget도 조절합니다. 최근 수정 사항이 대부분의 사례에서 고르게 효과를 냈다면 더 넓게 수정할 수 있게끔 허용합니다. 반대로 어떤 사례는 좋아지고 다른 사례는 나빠지는 등 결과가 불안정했다면, 다음에는 적은 수의 instruction만 바꾸도록 제한합니다.

코드 리뷰 skill을 예로 들어볼께요. 에이전트가 dependency 변화를 놓쳤다면 “주변 코드까지 조사하라”는 instruction을 추가할 수 있습니다. 그런데 그 결과로 모든 리뷰가 지나치게 오래 걸린다면, 다음에는 “조사 범위를 줄이라”는 수정 방향이 나올 수 있죠. 두 수정 방향 모두 개별적인 실패에는 대응하지만, 그대로 반복하면 skill이 넓게 조사하라는 방향과 빠르게 끝내라는 방향 사이를 오가게 됩니다.

그래서, 중요한 건, 둘 중 하나를 선택하는 것이 아니라 적용 조건을 분명히 하는 일입니다. 예를 들어 dependency file이나 외부 호출 경로가 바뀌었을 때는 주변 코드를 넓게 살펴보고, 독립적인 문구 수정이라면 조사를 줄이게 만들 수 있습니다. SkillAdam의 기록은 이전 수정 사항이 해결한 문제를 다음 수정 사항이 다시 망가뜨리지 않도록 돕고, edit budget은 근거가 불안정할 때 skill 전체가 크게 바뀌는 것을 막습니다.

공개되어 있는 SkillAdam 구현체는 Codex, Claude Code, Cursor Agent, GitHub Copilot을 지원하고, 한 번에 하나의 기존 SKILL.md를 최적화합니다. 다만 test run은 임시 작업 공간에서 실행되어서, 원래 저장소의 파일이나 skill에 포함된 보조 자료를 자동으로 사용할 수는 없습니다. 평가에 필요한 정보와 입력 파일을 test case에 직접 포함해야 한다는 뜻입니다.

이 방법은 현재 skill과 수정한 skill을 같은 과제에서 실행하고, 그 결과를 비교할 수 있을 때는 유용하겠구나 짐작하실 수 있을 겁니다. 그런데, 작업이 이미 끝났거나, 실행 비용이 너무 크거나, 같은 환경을 다시 만들 수 없는 경우에는 어떻게 해야 할까요?

Pull request 리뷰를 예로 들어보죠. 리뷰가 제출되는 순간에는 그 지적이 정말 유용했는지 판단하기가 어렵습니다. 며칠 뒤에 개발자가 지적받은 문제를 수정할 수도 있고, 리뷰가 잘못되었다는 근거를 제시할 수도 있습니다. 리뷰의 품질을 판단할 정보가 작업이 끝난 일정 시간 뒤에 생기는 것이죠.

이때 필요한 건, 같은 코드 리뷰를 다시 실행하는 게 아닙니다. 당시에 에이전트가 어떤 지적을 했는지와, 이후 개발자가 그 지적에 어떻게 대응했는지를 연결해서 살펴봐야 합니다. 개발자가 실제로 반영한 지적은 유지할 만한 행동으로, 반복해서 무시되거나 반박된 지적은 고쳐야 할 행동으로 볼 수 있기 때문이죠.

OpenHands 프로젝트의 SkillRefiner는 이렇게 이미 축적된 trajectory와 결과를 이용해서 skill을 개선합니다. 여기서 trajectory란 에이전트가 어떤 파일을 읽고, 어떤 tool을 사용하고, 어떤 과정을 거쳐 결론에 도달했는지를 담은 실행 기록입니다.

SkillRefiner는 먼저 각각의 trajectory를 요약한 뒤에, 성공 사례와 실패 사례를 따로 묶어서 반복되는 pattern을 찾습니다. 성공 사례에서는 계속 유지할 행동을, 실패 사례에서는 고쳐야 할 행동을 찾아서 skill 수정안을 만듭니다. 실패 사례로부터에서 얻은 수정안은 evidence gate, 즉 실제 기록이 그 문제를 뒷받침할 때만 수정안에 포함하는 장치를 거치게 됩니다.

단, evidence gate가 수정안의 효과까지 입증하는 것은 아닙니다. 새로운 skill로 과제를 다시 실행하는 건 아니기 때문에, ‘문제 진단에 근거가 있는지까지’만 확인할 뿐입니다. 제안한 해결책이 실제로 효과적인지는 별도의 held-out test에서 확인해야 합니다.

이 논문은 spreadsheet 작업, 수학적 추론, 실제 pull request 리뷰 같은 작업에 대해서 이 방법을 평가했습니다. 과거 trajectory로 skill을 만든 뒤, refinement에 사용하지 않은 별도의 과제에서 최종 성능을 측정했습니다. 즉, skill을 만드는 동안에는 새로운 run을 실행할 필요가 없지만, 완성된 skill의 효과를 검증하려면 별도의 평가가 필요합니다

여기서 다시 한 번 꼭 구분해야 할 것이 있습니다. ‘수정안을 제안하는 일’과 그 ‘결과를 검증하는 일’은 서로 다른 작업이라는 겁니다.

과거 기록만으로도 “이런 지침을 추가해 보면 좋겠다”는 가설은 만들 수 있고, 개선안을 작성할 때 원래 작업을 전부 다시 실행할 필요는 없죠. 하지만 그 가설이 정말 도움이 되는지는 수정된 스킬을 새로운 과제에 적용해 봐야 알 수 있어요. 과거의 증거는 왜 이런 변경을 제안했는지를 설명하는 것 뿐이고, 새로운 과제에서의 성능을 봐야만 그 변경 사항이 다른 상황에도 통하는지 보여줄 수 있다는 겁니다.

SkillOpt가 앞으로 수행할 새로운 run의 실행 과정에서 수정안을 시험한다면, SkillRefiner는 이미 끝난 작업이 남긴 기록에서 개선 후보를 찾는 겁니다. 하나는 새로운 실험에서 배우고, 다른 하나는 축적된 과거의 경험으로부터 배웁니다. 출발점은 다르지만 두 접근법 모두 결과적으로는 제안된 수정 방안이 처음 보는 별도의 과제에서도 도움이 되는지는 확인을 해야 합니다.

Microsoft의 Coding-Agent Skill Distillation(CASD)은 코딩 에이전트를 이용해서 과거의 run 실행을 분석하고, 반복되는 패턴을 찾아낸 뒤, 새 지침을 작성하기 전에 구체적인 사례를 조사합니다.

다만 여러 실패에서 같은 모습이 반복된다고 해서, 그것이 곧 실패의 원인이라는 뜻은 아닙니다. 실패한 코드를 리뷰해 보니까 검색이 유난히 많았다고 해도 “검색을 많이 해서 실패했다”고 단정할 수는 없으니까요. 어디를 살펴봐야 하는지 몰라서 같은 내용을 반복해서 찾았을 수도 있고, 애초에 까다로운 과제라 더 많은 조사가 필요했을 수도 있으니까요.

반복해서 나타나는 패턴은 원인을 찾기 위한 단서일 뿐이지, 원인 자체를 증명하지는 않습니다. 그럴듯한 설명과 실제로 확인된 원인을 구분해야 합니다.

그래서 에이전트의 작업 과정뿐 아니라, 그 작업이 어떤 결과로 이어졌는지도 함께 기록해야 합니다. 에이전트가 스스로 “성공했다”고 판단한 것만으로는 부족합니다. 테스트를 통과했는지, 개발자가 리뷰 내용을 실제로 반영했는지처럼 결과를 밖에서 확인할 수 있는 증거가 필요합니다.

한 번의 실패로부터 얻은 교훈을 곧바로 규칙으로 만들기 전에는 성공한 사례도 함께 살펴봐야 합니다. 실패한 작업에서 문제라고 생각한 행동이 성공한 작업에서도 반복되었다면, 그 행동이 진짜 원인이 아닐 가능성이 있기 때문입니다.

이런 다양한 과정을 거치면, 어느 정도 근거가 있는 교훈을 추려낼 수 있습니다. 하지만 근거가 있다는 이유만으로 그 교훈을 다른 에이전트라든가 새로운 과제에도 그대로 적용해도 될까요?

지난 9월 30일 공개된 논문 Do Self-Evolving Skills Generalize to Held-Out Tasks?에서 바로 이 질문을 다룹니다.

결과는 꽤 흥미롭습니다. 연구진이 6개 benchmark에서 여러 방법을 비교한 결과, 학습 과제에서 성능이 좋아진 skill은 모두 21개였습니다. 하지만 이 skill들을 최적화 과정에서 한 번도 사용하지 않은 test 과제에 적용하니까 결과가 달라졌습니다. 학습 과제에서 얻은 향상 폭을 그대로 유지한 skill은 5개뿐이었고, 13개는 일부만 유지했고, 나머지 3개는 개선 효과를 전혀 이어가지 못했습니다.

따라서, 이미 본 과제를 더 잘 해결하게 된 것과, 처음 보는 과제에도 도움이 되는 skill을 만든 것은 전혀 같은 일이 아닙니다.

skill의 진짜 가치는 이전에 발생했던 실패한 경우를 다시 보여줬을 때 같은 실수를 피하는 데서 끝나는게 아니라, 파일명이나 표현, 데이터 구조가 달라져도 그 안에서 같은 문제를 알아볼 수 있어야 합니다. 반대로 비슷해 보이지만 실제로는 관련이 없는 과제라면, 불필요한 규칙을 적용하지 않아야 하죠. 과거 사례의 해결 방법을 기억하는 데 그치지 않고, 그 안에서 배운 원칙을 새로운 상황에 맞게 적용해야 한다는 뜻입니다.

일반화에 실패한 skill에서는 몇 가지 공통된 문제가 발견됐습니다. 특정 column 이름이나 output file처럼 해당 과제에만 있던 정보를 그대로 규칙에 넣거나, 한 번의 실패를 막기 위한 해결책을 모든 과제에서 지켜야 할 절대적인 조건으로 바꾸는 경우였습니다.

LLM은 완성된 skill 여러 개 가운데 어느 쪽이 더 나은지를 비교적 잘 가려냈습니다. 실제 test 성능에 따른 순위와도 대체로 일치했죠. 하지만 특정 문장을 추가하거나 바꾸었을 때 성능이 어떻게 달라질지는 제대로 예측하지 못했습니다. 따라서 LLM의 평가는 완성된 skill을 검토하는 참고 자료로는 사용할 수 있지만, 개별 수정안을 채택하는 근거로 삼기에는 부족합니다. 수정의 효과는 결국 새로운 과제에서 직접 실행해 확인해야 합니다.

결국 수정안이 그럴듯해 보인다는 이유만으로 채택해서는 안 됩니다. 새로운 과제에서 직접 실행해보고, 그 결과가 실제로 좋아지는지 확인해야 합니다.

예를 들어 코드 리뷰 에이전트가 전처리 문제를 한 번 놓쳤다고 해보죠. “항상 전처리 과정을 검사하라”는 규칙을 추가하면 같은 실수는 막을 수 있습니다. 하지만 문서나 로그만 바뀐 작업에서도 전처리 pipeline 전체를 살피게 된다면, 시간과 token을 낭비하게 되겠죠.

더 나은 규칙은 ‘적용 조건’까지 알려줍니다. “변경 사항이 example, label, feature에 영향을 줄 가능성이 있을 때 전처리를 검사하라”는 식이죠. 좋은 skill은 무엇을 할지 뿐 아니라 언제 하지 않아도 되는지도 설명해야 합니다.

평가할 때도 에이전트가 필요한 상황에서 규칙을 적용하고, 관련 없는 상황에서는 건너뛰는지 함께 확인해야 합니다. 같은 validation set으로 수정안을 계속 고르면 특정한 사례에 과적합될 수 있으니, 최종 test set은 모든 수정 작업이 끝난 뒤에만 사용합니다.

Alibaba의 skill-up은 평가 사례를 실행하고, skill을 사용한 결과와 사용하지 않은 결과를 비교해서 report를 만듭니다. skill-upper는 실패 원인을 분석하고 skill이나 평가 사례를 수정한 뒤에 다시 평가하도록 도와줍니다.

다만 에이전트에게 평가 항목까지 고치게 할 때는 주의해야 합니다. 평가 방식이 잘못됐다면 바로잡아야 하지만, skill이 통과하기 쉽도록 기준을 느슨하게 바꿔서는 안 됩니다. 따라서 skill 수정과 평가 기준 변경은 구분하고, 평가 기준을 바꿀 때는 사람이 확인해야 합니다.

그런데여, 과연 모든 교훈을 skill의 새로운 규칙으로만 남겨야 할까요? 자동으로 확인할 수 있는 실수는 검사 script나 test로 만들고, 반복되는 작업은 tool로 구현하는 편이 더 낫지 않을까요? 그렇다면 어떤 교훈을 skill에 남기고, 어떤 교훈은 다른 형태로 옮겨야 할까요?

다시 Matt Pocock의 /retro로 돌아가 보죠. 작업에서 얻은 교훈을 모두 자연어 instructions로 남길 필요는 없습니다. 기계적으로 찾아낼 수 있는 실수라면 자동 검사로 만드는 편이 훨씬 확실하죠.

예를 들어서, 필수 필드 누락, 잘못된 파일 형식, 테스트 미실행 같은 문제는 SKILL.md에 “주의하라”고 적어두는 것보다 script가 즉시 오류를 내도록 만드는 편이 낫습니다. 그러면 다음 에이전트는 놓칠 수도 있는 주의사항 한 문단이 아니라, 무엇이 잘못됐는지 분명히 알려주는 실패 신호를 받게 됩니다.

문제의 성격에 따라서 더 적합한 해결책이 달라질 수도 있죠. 필요한 파일을 계속 찾지 못한다면 자연어 instructions를 추가하기보다 저장소의 index를 개선하는게 답일 수 있습니다. 여러 tool을 같은 순서로 반복해서 호출하느라 시간과 token을 낭비하는 것보다는, 그 과정을 하나의 helper function이나 tool로 묶는 편이 더 효과적일 수 있구요.

결국, 무엇을 배웠는지만큼 중요한 게, 그 교훈을 어디에 남겨서 어떻게 해결하는게 좋겠느냐 하는 질문이라는 겁니다.

정답을 기계적으로 판정할 수 있다면 코드나 테스트가 적합합니다. 반복되는 작업을 줄이는 것이 목적이라면 tool이나 helper function이 더 낫습니다. 상황에 따라서 다른 판단이 필요하고, 나중에 쉽게 수정해야 하는 절차라면 skill에 남기는 편이 좋구요. 반대로 여러 가지 환경에서 오랫동안 반복되는 안정적인 행동이라면, 충분한 검증을 거쳐서 모델 학습 과정에 반영하는 방법도 생각해 볼 수 있겠죠.

즉, 자기개선은 instructions를 계속 늘리는 게 아니라, 경험에서 얻은 교훈을 가장 효과적으로 작동할 수 있는 형태로 옮기는 일이라고 봐야 한다는 겁니다.

이런 관점에서 보면, 최근의 자기개선 연구는 단순히 SKILL.md를 잘 고치는 방법만 다루는 것이 아니라, 수정 사항을 instructions, code, tool, 작업 환경, 모델 가운데 어디에 두어야 하는지 탐색하는 과정에 가깝습니다.

4월에 발표된 The Last Harness You’ll Ever Build는 agent를 둘러싼 prompt, tool, 실행 흐름, 평가 방식 등을 하나의 harness로 보고, 작업 결과에 따라 이 harness를 자동으로 개선하는 방법을 제안합니다. 더 나아가서 harness를 개선하는 방법 자체도 다시 개선하는 구조를 다룹니다.

From Skills to Talent는 skill, tool, runtime 설정을 하나로 묶어서, 필요에 따라 팀에 배치하고 재사용할 수 있는 에이전트 구성 단위인 ‘Talent’를 제안합니다. 개별 skill을 개선하는 것을 넘어서, 서로 다른 능력을 지닌 에이전트를 조직 안에서 어떻게 구성하고 운영할 것인지 살펴보는 연구라고 하겠습니다.

교훈의 출처가 반드시 같은 agent의 과거 경험일 필요도 없습니다. 다른 프로젝트의 code와 문서에서 검증된 작업 방법을 추출할 수도 있습니다.

9월에 발표된 Repo-To-Skill은 여러 가지 머신러닝 저장소에 흩어져 있는 실행 방법과 주의사항을 agent가 사용할 수 있는 skill로 정리합니다. 이 연구에서 공개한 DisCo와 AREX-Skill Library에는 1,000개 머신러닝 저장소에서 추출하고 검증한 5,000개 이상의 skill이 담겨 있습니다. Agent는 이 거대한 자료를 한꺼번에 읽는 대신에, 현재 작업에 필요한 skill과 참고자료만 골라서 불러옵니다.

여기서는 역할이 분명하게 나뉩니다. 한 agent가 익숙하지 않은 머신러닝 tool의 설치 방법, 실행 절차, 검증 방법을 조사해 skill로 정리합니다. 그러면 다음 agent는 같은 설정 과정을 처음부터 다시 찾아보지 않고 실제 실험에 집중할 수 있습니다.

다만 이런 skill에는 어느 버전의 software를 기준으로 만들었는지 기록해야 합니다. 원본 software가 바뀌면 기존 절차도 다시 확인해야 하기 때문입니다. 한 번 검증됐다는 사실이 앞으로도 계속 유효하다는 뜻은 아닙니다.

Sakana의 ShinkaEvolve는 skill의 또 다른 쓰임새를 보여줍니다. 이 시스템에서 skill은 agent가 여러 후보 프로그램을 만들고 평가하면서 더 나은 답을 찾아가도록 안내합니다. 예를 들어 검색 ranking 함수를 개선한다면, agent가 새로운 함수를 만들고 evaluator가 관련성, 지연 시간, 정확성을 확인하는 과정을 반복할 수 있습니다.

하지만 지금까지 살펴본 skill은 모두 ‘모델 외부’의 것들이죠. 에이전트가 작업할 때마다 외부에 저장된 skill을 찾아 읽고 따라하는 것들이라는 겁니다.

그렇다면 충분히 검증된 절차는 모델이 아예 내재화해서 익히게끔 할 수 있을까요? 매번 instructions를 불러오지 않고도 수행할 수 있도록 말입니다.

Anthropic은 skill을 크게 두 종류로 나눠서 설명합니다. 하나는 모델이 아직 잘하지 못하는 일을 보완하는 skill이고, 다른 하나는 조직이 원하는 업무 방식이나 규칙을 전달하는 skill입니다.

이 두 종류의 skill은 수명(lifecycle)이 다른 유형의 것들이라고 생각합니다. 구형 모델의 약점을 보완하기 위해 만든 우회 방법은 더 뛰어난 모델이 나오면 필요 없어질 수 있습니다. 반면에 평가 데이터를 함부로 변경하지 말아야 한다는 팀의 규칙은 모델이 좋아져도 그대로 남을 가능성이 큽니다. OpenAI도 이전 모델을 기준으로 만든 오래된 instructions가 최신 모델의 행동을 불필요하게 제한할 수 있다고 지적하기도 하죠.

4월에 공개된 SKILL0는 외부 skill을 모델의 능력으로 옮기는 과정을 연구합니다. 강화학습 초기에는 agent에게 skill을 제공합니다. 이후 학습이 진행될수록 skill의 도움을 점차 줄이고, 현재 모델에 여전히 도움이 되는 instructions만 제한적으로 남깁니다. 마지막에는 agent가 실행 중에 skill을 불러오지 않고도 작업하도록 학습합니다.

이런 방식은 지금까지 살펴본 SkillOpt나 SkillRefiner와는 근본적으로 다릅니다. SkillOpt와 SkillRefiner는 모델은 그대로 둔 채 외부의 instructions를 개선하지만, SKILL0는 학습을 통해 모델의 parameters를 바꾸는게 목적입니다.

처음에는 모델이 매번 읽어야 했던 외부 checklist가 학습을 위한 발판이 되고, 나중에는 문서가 없어도 수행할 수 있는 행동으로 자리 잡는 건데, 이런 의미에서 skill은 영구적인 매뉴얼이 아니라, 모델이 새로운 작업 방식을 익힐 때 사용하는 임시 교재가 될 수도 있습니다.

물론 모든 skill을 모델에 학습시키는 것이 정답은 아닙니다. 자주 바뀌는 정책, 팀마다 다른 규칙, 특정 저장소의 경로나 명령은 계속 수정할 수 있는 외부 instructions로 두는 편이 안전합니다.

반대로 여러 환경에서 오랫동안 반복해서 사용되고, 효과를 객관적으로 측정할 수 있는 절차라면 모델에 내재화하기 위해 학습시켜볼까 검토할 수 있습니다. 외부 skill은 수정하기 쉽지만 실행할 때마다 context를 차지하니까요. 대신, 모델 weights에 들어간 능력은 매번 불러올 필요가 없지만 잘못 학습됐을 때 고치기가 훨씬 어렵습니다.

아마도 대부분의 팀에는 외부 skill이 더 현실적인 출발점일 겁니다. 모델을 다시 학습하지 않고도 instructions를 고치고, 효과를 측정하고, 문제가 생기면 이전 버전으로 되돌릴 수 있으니까요.

지금까지 살펴본 내용을 하나의 구체적인 사례에 적용해 보면 좋을 것 같습니다.

검색 시스템을 바꾼 뒤에는 기존 버전과 새 버전의 성능을 비교합니다. 그런데 두 버전을 서로 다른 query 집합으로 평가했다면 점수를 그대로 비교할 수 없습니다. 에이전트가 이 차이를 놓치고 잘못된 비교를 승인했다고 가정해 보죠. 같은 실수를 반복하지 않도록 하려면, 이 경험을 어떤 skill로 만들어야 할까요?

전체 과정은 다음과 같습니다.

Skill이 매력적인 이유 중 하나는 그 내용을 우리가 직접 확인하고 바꿀 수 있다는 점입니다.

모델을 다시 학습하지 않아도 instructions를 열어보고, 특정 규칙이 왜 들어갔는지 확인하고, 문장을 수정한 뒤에 실제 결과가 좋아졌는지 시험할 수 있습니다. 문제가 생기면 이전 버전으로 되돌리기도 쉽죠. 이런 특성 때문에 skill은 agent가 과거 작업에서 얻은 지식을 어떻게 저장하고 재사용하는지 연구하기에 좋은 수단입니다.

동시에, 최근의 연구는 ‘경험에서 배운다’는 짧은 말 안에 얼마나 많은 판단이 들어 있는지도 보여줍니다. 모든 실패가 교훈은 아니고, 모든 교훈을 새로운 규칙으로 만들 필요도 없습니다.

먼저 수많은 작업 기록 가운데 어떤 경험이 중요한지 찾아야 합니다. 반복해서 나타난 원인과 우연히 함께 나타난 세부 사항도 구분해야 하구요. 그런 다음 얻은 교훈을 자연어 instructions, test, code, tool, 작업 환경, 모델 가운데 어디에 둘지 결정해야 합니다. 마지막으로 그 수정 사핳ㅇ이 처음 보는 과제에서도 실제로 도움이 되는지 확인해야 합니다.

그리고 이런 판단을 다른 에이전트가 맡는 경우가 점점 늘고 있습니다.

제가 흥미롭게 보는 것도 바로 이 지점입니다. 에이전트가 작업을 마칠 때마다 자기 매뉴얼에 규칙을 한 줄씩 덧붙이는 모습이 아니라, 작업이 끝날 때마다 다음 실행에 도움이 되는 더 나은 방법을 남기는 별도의 시스템이 있는 모습이죠.

그 결과물은 새로운 테스트일 수도 있고, 검증된 작업 절차로 나타날 수도 있습니다. 더 명확한 tool interface나 자동 검사일 수도 있고, 충분한 학습을 거친 모델의 능력으로 남을 수도 있습니다.

앞으로 에이전트의 경쟁력은 한 번의 과제를 얼마나 잘 해결하는지만으로 결정되지 않을 겁니다. 작업을 마친 뒤에 어떤 교훈을 남겼는지, 그리고 다음 에이전트가 그 교훈을 얼마나 안전하게 활용할 수 있는지도 중요한 차이가 될 겁니다.

좋은 에이전트는 결과물을 남깁니다. 그리고 좋은 에이전트 시스템은 그 결과를 만든 방법 가운데 실제로 효과가 확인된 부분까지 조직의 역량으로 남깁니다.

그러면 다음 run의 실행은 처음부터 다시 시작하지 않아도 되는 겁니다. 어떤 검사에서 실제 문제를 발견했는지, 어떤 탐색 경로가 막다른 길이었는지, 어떤 조건에서는 예외가 필요했는지에 대한 지도를 물려받을 수 있을 테니까요.

물론 그 지도를 절대적인 규칙으로 받아들여서는 안 됩니다. 다음 에이전트가 더 나은 출발을 할 수 있도록 돕는, 근거가 확인된 안내도로만 사용해야 합니다. 그래야 프로젝트가 바뀌거나 기반 모델이 업그레이드된 뒤에도 과거의 경험이 사라지지 않고 계속 축적될 수 있습니다.

SkillOpt, SkillAdam, SkillRefiner를 비롯해서 이 글에서 살펴본 프로젝트들은 이 과정의 서로 다른 부분을 연구하고 있습니다. 그리고 앞으로도 비슷한 프로젝트가 계속 등장하겠지만, 그 가치는 결국 하나의 질문으로 판단할 수 있습니다.

“다음 에이전트는 이전 run의 실행에서 한 번도 나타나지 않은 문제에서도 실제로 더 나은 결과를 내는가?”하는 질문 말이예요.

지금까지 살펴본 다양한 접근 방법을 간단히 정리하면서 글을 마무리하겠습니다.

읽어주셔서 감사합니다.

읽어주셔서 감사합니다. 친구와 동료 분들에게도 뉴스레터 추천해 주세요!