Repo-To-Skill을 읽고: 에이전트에게 부족한 건 모델이 아니라 운영 지식이다

노시욱 (Patrick Rho) · AI 연구 해설

이 글은 arXiv 논문 「Repo-To-Skill: Distilling GitHub Repositories Into AI4AI Skills」을 읽고 정리한 글입니다. 원문 링크는 제목 바로 아래에 붙여 두었으니, 요약이 끌리면 논문을 먼저 펼쳐 보셔도 좋습니다.

논문의 주장은 한 문장으로 정리됩니다. 잘 관리된 GitHub 저장소를 기계가 읽고 '스킬'이라는 재사용 가능한 지식 단위로 바꾸면, 에이전트는 같은 예산으로 더 멀리 간다. 실제 연구를 수행하는 에이전트의 가장 큰 병목은 모델 성능이 아니라, 어떤 패키지를 어떻게 쓰는지 같은 운영 지식이 시스템 밖에 있다는 진단에서 출발합니다. 이 글에서는 그 주장이 어디에서 나오는지, DisCo라는 증류 프레임워크가 어떻게 동작하는지, 그리고 실험이 실제로 무엇을 보여주는지를 따라갑니다.

에이전트가 기계학습 연구를 처음부터 끝까지 수행한다는 이야기를 들을 때마다 저는 같은 질문을 하게 됩니다. 모델은 계속 좋아지고, 실행 환경도 정교해지는데, 정작 그 일을 해본 사람이 당연하게 아는 노하우는 어디에 있는 걸까 하는 겁니다. 어떤 패키지를 쓰고, 설정을 어떻게 잡고, 어디에서 흔히 망하는지 같은 지식 말입니다.

이번 Repo-To-Skill 논문은 그 질문을 정면으로 다룹니다. 빠진 계층에 이름을 붙이고, 그 계층을 자동으로 만드는 방법까지 제시합니다. 이름하여 운영 지식, 그리고 그것을 스킬로 증류하는 DisCo라는 프레임워크입니다.

모델과 하네스 사이에 비어 있는 칸

에이전트 시스템을 보통 두 요소로 설명합니다. 이해하고 계획하고 실행하는 모델, 그리고 그 과정을 조율하고 기억하고 검증하는 하네스입니다. 두 요소는 각자 발전해 왔습니다. 모델은 세대가 바뀔 때마다 강해지고, 하네스 엔지니어링도 계속 정교해집니다.

그런데 운영 지식은 둘 다 주지 않습니다. 모델의 사전 지식은 넓지만 고정돼 있고, 하네스는 절차를 통제할 뿐 도메인 내용을 공급하지 않습니다. 논문은 이 빈칸을 수식으로까지 적습니다. 연구 에이전트는 모델과 하네스에 운영 지식 K를 더한 형태여야 한다는 겁니다.

저는 이 문제 제기가 마음에 들었습니다. 연구 현장에서 시간을 가장 많이 먹는 건 우아한 아이디어가 아니라 지루한 시행착오이기 때문입니다. 패키지 동작을 시행착오로 추론하다가 예산을 쓰고, 한 번 알아낸 것도 다음 과제에서는 다시 처음부터 찾습니다. 이 비용이 구조적으로 어디에 속하는지를 짚은 것만으로도 읽을 가치가 있습니다.

증류는 방향이 두 가지다

DisCo의 증류는 닻을 어디에 내리느냐에 따라 두 형태가 됩니다. 하나는 task-agnostic, 즉 미리 만들어 두는 방식입니다. 널리 쓰이는 저장소와 도구를 가져다가 어떤 과제에도 쓸 수 있는 스킬로 응축합니다. 다른 하나는 task-oriented, 즉 필요할 때 만드는 방식입니다. 구체적인 과제를 분해해서 에이전트가 갖지 못한 능력을 찾고, 그 빈틈을 메우는 스킬을 만듭니다.

어떤 닻이든 과정은 네 단계로 같습니다. 다룰 능력을 정하고(scope), 근거를 모으고(ground), 스킬 그래프로 조립하고(construct), 검증합니다(verify). 검증이 핵심입니다. 출처가 좋다는 이유만으로 스킬이 받아들여지지 않고, 남은 빈틈은 기록으로 남습니다. 요약을 증류라고 부르지 않겠다는 선언에 가깝습니다.

스킬이라는 그릇을 고른 이유

운영 지식을 담는 그릇으로 논문이 고른 건 스킬입니다. SKILL.md라는 지식 인터페이스, references라는 지식 기질, scripts라는 실행 인터페이스의 세 겹입니다. SKILL.md만 먼저 읽고 나머지는 필요할 때 펼치는 점진적 공개 방식입니다.

저는 이 선택이 실용적이라고 봅니다. 에이전트에게 이미 익숙한 형식이라 모델도 하네스도 바꿀 필요가 없습니다. 수천 개를 들고 있어도 실제로 읽는 건 몇 개뿐이니 콘텍스트 예산도 감당됩니다. 형식이 좋아서가 아니라, 지식을 명령 가능한 형태로 만드는 조건을 만족해서 고른 겁니다.

하나의 소스는 보통 스킬 하나로 안 들어가서 그래프가 됩니다. 진입 스킬이 범위를 설명하고, 컴포넌트 스킬로 연결됩니다. 에이전트는 라우터를 따라 필요한 가지만 엽니다.

도서관의 규모와 라우터

미리 만드는 방식을 생태계 규모로 돌리면 AREX-Skill 라이브러리가 나옵니다. 1,000개의 저장소에서 5,353개의 검증된 스킬을 뽑아 20개 영역과 178개 capability family로 정리하고 라우터로 엮었습니다. 저장소 하나당 평균 40달러 정도의 구축 비용이 들었다고 합니다.

라우터 만드는 과정도 대충하지 않았습니다. 저장소 요약을 고정하고 분류 체계를 먼저 확정한 뒤에 배치하고, 배치에는 근거와 확신도를 요구합니다. 키워드만 맞거나 의존성만 걸린 배치는 탈락입니다. 분류가 검색 정밀도를 좌우한다는 걸 아는 접근입니다.

예산을 맞춰 놓고 본 결과

이제 숫자입니다. 평가는 Codex 하네스와 GPT-5.5 백본을 고정하고 스킬 유무만 바꿨습니다. 스킬 구축 예산은 실행 예산과 분리돼 있습니다. 이 조건을 먼저 기억해야 합니다. 구축비를 빼고 실행비만 맞춘 비교입니다.

MLE-bench 75개 과제에서 Any-Medal 점수가 31.11%에서 72.89%로 올랐습니다. 41.78포인트 상승, 상대 기준으로 134.3%입니다. 어려운 과제에서 상승이 특히 큽니다. High 등급은 13.33%에서 62.22%로, 4.67배입니다.

저는 이 패턴을 이렇게 읽습니다. 쉬운 과제는 맨몸으로도 답을 찾습니다. 어려운 과제는 라이브러리와 구현 선택의 공간이 넓어서 길 잃는 비용이 큽니다. 스킬은 그 공간에서 생산적인 영역으로 빨리 들어가게 합니다.

PaperBench 20개 논문 재현에서는 평균 29.45%에서 39.59%로 올랐습니다. 18개 과제에서 오르고 2개에서 떨어졌습니다. 떨어진 두 개가 흥미롭습니다. 검색 정밀도의 문제로 보입니다. 가져온 스킬이 과제에 안 맞으면, 맨몸이었으면 찾았을 해법을 오히려 놓칠 수 있습니다. 스킬이 항상 이득이라는 이야기가 아니라서, 저는 이 대목이 논문의 솔직한 부분이라고 봅니다.

토큰을 더 쓴 게 아니다

FrontierCS 188개 과제에서는 70.63점에서 77.14점으로 올랐습니다. 9.2% 상승입니다. 여기서 제가 가장 오래 본 건 토큰 사용량과의 관계입니다. 스킬을 쓰면 토큰과 스텝이 늘어나는데, 과제별 이득과 추가 사용량의 상관관계가 거의 없습니다. 더 쓴다고 좋아진 게 아니라는 뜻입니다.

비교선도 재미있습니다. 같은 조건에서 스킬을 단 Codex는 토큰을 Claude Code 설정들의 3분의 1 이하로 쓰면서도 점수가 더 높습니다. 효율 프론티어에서 앞선다는 표현이 과장이 아닙니다.

PassNet에서는 집계 점수가 1.343에서 1.5313으로 올랐고, 실패 샘플이 14개에서 5개로 줄었습니다. 정확도도 81.35%에서 90.76%로 올랐습니다. 컴파일러 패스를 만드는 과제에서 실패 감소는 스킬 그래프의 절차와 거부 기준, 복구 동작이 작동했다는 뜻입니다.

비용은 한 번 내고 여러 번 쓴다

이 구조에서 제가 제일 실용적이라고 본 건 비용 비대칭입니다. 만드는 쪽은 소스당 한 번 내고, 쓰는 쪽은 과제가 실제로 여는 만큼만 냅니다. 라이브러리는 오프라인에서 넓히고, 과제는 물려받기만 하면 됩니다.

그래서 확장 주장이 설득력이 있습니다. 증류는 소스 생태계가 허용하는 대로 넓히고, 실행 에이전트는 다시 유도하지 않고 물려받습니다. 물론 1,000개 저장소에 개당 40달러면 라이브러리 하나에 4만 달러입니다. 공짜 확장은 아닙니다. 다만 한 번 낸 뒤에는 과제마다 재사용되니, 과제 수가 늘어날수록 단가가 내려가는 구조입니다.

조심해서 읽을 대목들

좋게 봤다고 해서 그대로 믿으면 안 되는 부분도 있습니다.

첫째, 모든 평가의 하네스가 Codex 하나입니다. 같은 스킬이 다른 하네스에서도 통하는지는 보이지 않았습니다. 논문 주장대로라면 통해야 하지만, 검증은 안 됐습니다.

둘째, 구축 예산이 실행 비교에서 빠져 있습니다. 공정한 분리이긴 한데, 총비용 관점에서는 스킬 쪽이 더 쓴 겁니다. 과제 수가 적으면 이 계산이 뒤집힐 수 있습니다.

셋째, 저장소는 드리프트합니다. 릴리스마다 바뀌고, 빠진 함정이 메워지기도 합니다. 한 번 증류한 스킬이 얼마나 오래 유효한지, 누가 다시 검증하는지는 열려 있습니다.

넷째, PaperBench의 두 개 퇴보는 라우팅 정밀도가 실전 변수라는 뜻입니다. 관련 없는 스킬을 열면 오히려 해가 됩니다. 맞지 않으면 열지 않는 판단, 혹은 못 찾았을 때 맨몸 추론으로 돌아가는 폴백이 필요합니다.

앞으로 보고 싶은 것

규모입니다. 백본이 훨씬 커지면 반복 패턴을 다시 만드는 비용의 비중이 달라집니다. 스킬이 더 유리해질 수도 있고, 큰 백본이 그 일을 너무 쉽게 해서 상대 이점이 줄 수도 있습니다.

하네스 일반화도 궁금합니다. Codex가 아닌 실행 환경에서 같은 라이브러리가 통하는지 봐야 합니다. 이게 안 되면 운영 지식층이라는 주장보다 Codex용 프롬프트 모음에 가까워집니다.

유지보수도 봐야 합니다. 저장소가 바뀌면 스킬 그래프를 다시 검증해야 합니다. 5,353개 규모에서 이걸 어떤 주기로 돌릴 수 있는지, 비용은 누가 내는지가 보이지 않습니다.

한국어 생태계 같은 다른 영역에서도 보고 싶습니다. 라우터와 분류 체계가 영어 중심 저장소로 짜여 있습니다. 다른 언어와 도구의 저장소에서도 같은 품질로 증류되는지는 별개 문제입니다.

남는 생각 하나

연구 에이전트 이야기를 하면 보통 모델을 키우거나 하네스를 다듬는 쪽으로 갑니다. 둘 다 중요합니다.

이 논문이 남긴 건 세 번째 칸입니다. 과제를 푸는 데 필요한데 모델에도 하네스에도 없는 지식, 즉 무엇을 알고 시작하는지의 문제입니다. 스킬이라는 그릇에 담고, 검증 없이 들이지 않고, 한 번 만들어 여러 번 쓰는 구조입니다.

앞으로 에이전트 시스템을 평가할 때 저는 백본과 하네스 옆에 세 번째 질문을 덧붙이게 될 것 같습니다. 이 에이전트는 일을 시작할 때 무엇을 알고 시작하는가, 그리고 그 지식은 어디서 와서 얼마나 믿을 만한가 말입니다.