Alibaba Cloud 연구자 Xueping Gao가 LLM 에이전트가 큰 도구 카탈로그에서 필요한 스킬을 고르고 조합하도록 돕는 연구 프레임워크 SkillWeaver를 제시했다. 2026년 6월 16일 arXiv에 제출된 이 논문은 소비자용 제품 출시가 아니다. 에이전트 플랫폼이 재사용 가능한 기능을 계속 늘릴수록 더 중요해지는 문제를 다룬다.

논문은 이 문제를 “compositional skill routing”이라고 부른다. 여러 단계가 필요한 요청이 들어오면 에이전트는 일을 더 작은 작업으로 나누고, 각 작업에 맞는 스킬을 찾고, 의존 관계를 지키는 실행 계획을 만들어야 한다. 동시에 전체 스킬 라이브러리를 모델 컨텍스트에 모두 밀어 넣지 않아야 한다.

AI 생성형 게임에서는 이 문제가 바로 드러난다. 제대로 된 게임 제작 에이전트는 프로젝트를 만들고, 에셋을 불러오고, 브라우저 자동화를 실행하고, 스크린샷을 검사하고, 물리나 충돌 문제를 디버깅하고, UI 문구를 현지화하고, 빌드를 배포해야 할 수 있다. 결과물의 품질은 기본 모델이 코드를 쓸 수 있느냐만으로 결정되지 않는다. 필요한 기능을 알맞은 순서로 호출할 수 있느냐가 중요하다.

왜 지금 스킬 라우팅이 중요해졌나

Agent Skills는 SKILL.md 파일을 중심으로 한 이식 가능한 지침 폴더다. Agent Skills 공식 개요는 스킬을 전문 지식, 워크플로, 스크립트, 참고 자료, 템플릿을 묶어 에이전트가 필요할 때 읽을 수 있게 하는 가벼운 형식으로 설명한다. Model Context Protocol 문서에도 MCP 서버 개발을 위한 “Build with Agent Skills” 가이드가 있으며, 서버 설계, 대화형 앱 위젯, MCP 번들 패키징으로 에이전트를 안내하는 조합형 스킬을 예로 든다.

MCP는 에이전트가 도구와 데이터 소스에 연결되는 공통 방식을 제공한다. 스킬은 전문 기능을 언제 어떻게 써야 하는지에 대한 절차 지식을 담는다. 두 흐름이 결합하면 새로운 운영 문제가 생긴다. 스킬 카탈로그가 커질수록 선택지는 늘어나지만, 그만큼 올바른 실행 경로를 찾기는 어려워진다.

SkillWeaver 논문은 단일 도구 선택과 다중 스킬 라우팅을 구분한다. 하나의 의도에 하나의 API를 고르는 것과 “데이터셋을 내려받고, 변환하고, 시각 보고서를 만들어라” 같은 요청을 처리하는 것은 다르다. 후자는 순서 있는 조합이 필요하다. 에이전트가 작업을 너무 넓게 나누면 필요한 기능을 놓친다. 너무 잘게 나누면 불필요한 단계가 생기고, 컨텍스트를 낭비하고, 실행 계획도 더 복잡해진다.

SkillWeaver가 카탈로그를 좁히는 방식

프레임워크는 세 단계로 구성된다.

첫째, LLM이 사용자 요청을 원자적 하위 작업으로 나눈다. 둘째, bi-encoder 검색기가 각 하위 작업에 맞는 후보 스킬을 찾는다. 이때 FAISS 인덱싱을 이용해 스킬 메타데이터와 본문을 검색한다. 셋째, compose 단계가 각 단계를 따로 보지 않고 전체 작업 흐름 안에서 의존 관계를 고려한 계획을 만든다.

가장 눈에 띄는 부분은 Skill-Aware Decomposition, 줄여서 SAD다. SkillWeaver는 먼저 일반적인 작업 분해를 수행하고, 그 결과로 후보 스킬을 찾은 뒤, 후보 이름을 힌트로 다시 넣어 모델이 실제 스킬 라이브러리의 어휘에 맞게 작업 분해를 고치도록 한다. 쉽게 말해 에이전트는 “이 일의 단계는 무엇인가”만 묻지 않는다. “내가 실제로 가진 도구에 잘 맞는 단계는 무엇인가”를 함께 묻는다.

이는 일반적인 계획 언어가 검색에 잘 걸리지 않는 경우가 많기 때문에 중요하다. 모델은 “파일을 처리한다”고 말할 수 있지만 카탈로그에는 OCR, PDF 파싱, CSV 정규화, 벡터 인덱싱, 데이터베이스 적재 스킬이 따로 있을 수 있다. SkillWeaver는 전체 카탈로그를 보여주지 않고도 계획을 카탈로그에 가까운 언어로 끌어당기려 한다.

CompSkillBench가 측정한 것

논문은 CompSkillBench라는 벤치마크도 제시한다. 이 벤치마크는 공개 MCP 생태계에서 수집한 고유 스킬 2,209개를 기능 범주 24개로 나누고, 300개 복합 질의를 만든다. 쉬운 문제 150개는 스킬 2개, 중간 문제 100개는 스킬 3개, 어려운 문제 50개는 스킬 4개 또는 5개가 필요하다.

보고된 수치는 가능성과 한계를 동시에 보여준다. Qwen2.5-7B-Instruct를 주 분해 모델로 쓴 실험에서 일반 분해는 엄격한 분해 정확도 51.0%, top-1 범주 재현율 34.2%를 기록했다. SAD를 더하면 엄격한 분해 정확도는 67.7%, 완화된 분해 정확도는 84.3%로 오른다. 하지만 top-1 범주 재현율은 37.0%에 그친다.

의미 있는 개선이지만 완성된 에이전트 시스템이라고 보기는 어렵다. top-10 범주 재현율은 약 70% 수준이다. 맞는 범주가 후보 목록 어딘가에는 자주 있지만, 가장 위에 안정적으로 올라오지는 않는다는 뜻이다. 논문도 다음 개선 지점으로 reranking을 든다. Qwen2.5-7B listwise reranker 파일럿은 top-1 범주 재현율을 37.1%에서 40.9%로 높였고, encoder 점검에서는 45.1%까지 올라갔다.

컨텍스트 창을 줄이는 효과는 제품 관점에서도 중요하다. 논문은 스킬 2,209개를 모두 노출하면 약 884,000토큰이 필요하다고 추정한다. top-10 검색은 이를 약 4,000토큰으로 줄인다. SkillWeaver의 평균 라우팅 계획은 약 2.9개 스킬, 즉 실행 시점 약 1,160토큰만 노출한다. 논문의 계산으로는 작업 실행 단계의 스킬 컨텍스트를 99.9% 줄이는 셈이다.

논문이 아직 보여주지 못한 것

SkillWeaver를 Alibaba Cloud가 자율 소프트웨어 개발이나 게임 제작 문제를 해결했다는 증거로 읽으면 안 된다. 논문도 한계를 분명히 적는다. 벤치마크 질의는 실제 스킬 항목 위에 만든 합성 조합이다. 통제된 평가는 검색과 범주 일치를 측정하며, 실제 도구 실행, 오류 복구, 인증, 권한, 부작용까지 검증하지는 않는다. compose 단계는 아키텍처에 포함되어 있지만, 이를 따로 평가하려면 현재 벤치마크에는 없는 호환성 정답 주석이 필요하다.

동명이의 연구도 구분해야 한다. 2025년에도 SkillWeaver라는 별도 논문이 있었다. 그 논문은 웹사이트에서 연습한 뒤 재사용 가능한 API형 스킬을 발견하고 정제하는 웹 에이전트를 다뤘다. Alibaba Cloud의 2026년 6월 SkillWeaver는 다르다. 이미 큰 카탈로그 안에 있는 에이전트 스킬을 검색하고 조합하는 문제를 다룬다.

이 차이는 중요하다. 한쪽 연구는 에이전트가 스킬을 어떻게 만들 수 있는지를 묻는다. Alibaba Cloud 논문은 라이브러리가 이미 커졌을 때 에이전트가 스킬을 어떻게 찾고 결합할 수 있는지를 묻는다. 실제로 성숙한 에이전트 플랫폼에는 둘 다 필요할 가능성이 크다.

게임 제작자가 주목할 이유

생성형 게임은 라우팅 문제를 빠르게 드러낸다. 게임은 하나의 산출물이 아니다. 플레이 가능한 빌드는 코드 생성, 에셋 배치, 입력 처리, 장면 검사, 브라우저 실행, 오디오 점검, 현지화, 안전성 검토, 성능 예산, 배포 규칙을 함께 요구할 수 있다. 많은 실패는 텍스트만으로 보이지 않는다. 에이전트는 코드, 런타임 증거, 스크린샷, 플레이테스트 결과 사이를 오가야 한다.

그래서 스킬 라우팅은 단순한 벤치마크 문제가 아니라 제품 문제다. 게임 에이전트가 물리 버그를 일반 코드 수정 스킬로만 보내고 런타임 검사 스킬을 건너뛰면 잘못된 층을 고칠 수 있다. 에셋 불러오기를 하면서 위치와 접지 검사를 건너뛰면 화면에 보이는 오브젝트와 충돌 박스가 어긋날 수 있다. 배포를 라우팅하면서 빌드나 브라우저 스모크 테스트를 빠뜨리면 그럴듯한 로컬 초안이 깨진 상태로 나갈 수 있다.

SkillWeaver는 모델이 모든 가능한 기능을 기억해야 한다는 접근에서 벗어난다. 더 큰 스킬 세계에서 현재 작업에 필요한 작은 계획을 만들고, 그 계획에 필요한 스킬만 모델에 제공하는 구조를 보여준다.

남은 질문은 이 라우팅이 선택된 스킬이 실제로 실행되고, 실패하고, 권한을 요구하고, 복구가 필요한 상황에서도 믿을 만한가다. 논문의 수치는 첫 번째 병목이 작업 분해와 순위화에 있음을 보여준다. 큰 스킬 라이브러리가 제작 현장에서 안정적으로 쓰이려면 이 두 문제가 먼저 더 나아져야 한다.

이 한국어 기사는 영어 원문을 번역한 것이며, 번역 과정에서 오류가 있을 수 있습니다. 이 글은 Wonder Bricks AI Agent의 도움을 받아 작성했으며 SunnyLabs가 편집했습니다.