Alibaba SkillWeaver 해설: 에이전트 도구 선택은 긴 프롬프트보다 스킬 검색·DAG·실패 복구 예산을 먼저 설계해야 하는 이유

AI 에이전트가 실제 업무를 맡기 시작하면 문제는 모델이 말을 잘하느냐에서 끝나지 않습니다. 수백 개의 API, MCP 도구, 사내 자동화 스킬 중 무엇을 어떤 순서로 써야 하는지가 병목이 됩니다. Alibaba 연구진이 공개한 SkillWeaver는 이 문제를 “모든 도구를 프롬프트에 넣기”가 아니라 “작업 분해, 스킬 검색, DAG 실행 계획”으로 풀려는 시도입니다.

1. 한 줄 문제 정의

핵심 한 줄: 에이전트 도구 선택의 현실 문제는 도구가 부족한 것이 아니라, 너무 많은 도구를 컨텍스트와 운영 예산 안에서 정확히 고르는 일입니다.

초보 개발자 기준으로 스킬은 “AI가 호출할 수 있는 작업 카드”라고 보면 됩니다. 예를 들어 파일 다운로드, CSV 변환, 차트 생성, Slack 알림, Supabase 쿼리 같은 기능이 각각 하나의 스킬이 될 수 있습니다. 도구가 10개일 때는 프롬프트에 모두 적어도 버틸 수 있지만, 200개를 넘으면 모델은 이름이 비슷한 도구를 헷갈리고 컨텍스트 비용도 급격히 커집니다.

이 글은 사내 자동화 에이전트, MCP 서버, 업무용 AI 어시스턴트, 노코드/로우코드 에이전트 빌더를 운영하려는 개발자와 기획자를 대상으로 합니다. 범위는 SkillWeaver 논문의 구조를 실무 운영 기준으로 해석하는 것입니다. 반대로 도구 5개 이하의 단순 챗봇이나 정해진 단일 워크플로만 실행하는 봇이라면 이 구조는 과할 수 있습니다.

2. 먼저 결론

핵심 한 줄: SkillWeaver의 핵심 메시지는 “더 큰 모델을 쓰자”가 아니라 “도구 선택을 검색 문제와 실행 계획 문제로 분리하자”입니다.

arXiv에 2026년 6월 16일 공개된 논문은 SkillWeaver를 Decompose, Retrieve, Compose의 3단계 프레임워크로 설명합니다. 복합 요청을 작은 하위 작업으로 나누고, 각 작업에 맞는 스킬을 검색한 뒤, 의존성을 고려해 DAG 형태의 실행 계획으로 조합합니다. DAG는 방향성 비순환 그래프라는 뜻으로, “먼저 끝나야 하는 작업”과 “병렬로 해도 되는 작업”을 선으로 연결한 작업 지도입니다.

제가 보는 실무 결론은 명확합니다. 에이전트 도구가 50개를 넘는 팀은 이제 프롬프트 안에 도구 설명을 계속 붙이는 방식에서 벗어나야 합니다. 스킬 카탈로그, 검색 인덱스, 재순위화, 실행 계획 검증, 실패 복구 정책을 별도 계층으로 설계해야 합니다. 다만 SkillWeaver도 아직 오류 복구가 약하므로, 운영 도입은 “계획 생성”과 “실행 승인”을 분리해서 시작하는 편이 안전합니다.

3. 핵심 구조 분해

핵심 한 줄: SkillWeaver는 에이전트에게 모든 도구 목록을 외우게 하지 않고, 필요한 순간에 적절한 스킬 후보를 찾아 조립하게 만듭니다.

첫 번째 층은 Decompose입니다. 사용자의 큰 요청을 원자적인 하위 작업으로 나눕니다. “데이터를 내려받아 변환하고 시각화 보고서를 만들어줘”라는 요청은 데이터 다운로드, 데이터 변환, 차트 생성, 보고서 작성으로 나뉩니다. 이 단계의 품질이 낮으면 이후 검색도 틀어집니다.

두 번째 층은 Retrieve입니다. 논문은 bi-encoder 스킬 검색기와 FAISS 인덱싱을 사용한다고 설명합니다. 쉽게 말하면 각 스킬 설명을 벡터로 저장해 두고, 하위 작업과 의미가 가까운 스킬 후보를 빠르게 찾는 방식입니다. 모든 도구 설명을 LLM 프롬프트에 밀어 넣는 방식보다 컨텍스트 사용량을 크게 줄일 수 있습니다.

세 번째 층은 Compose입니다. 검색된 스킬을 작업 순서와 의존성에 맞게 DAG로 구성합니다. 데이터 변환은 다운로드 뒤에 와야 하지만, 요약 통계 계산과 차트 생성은 같은 데이터가 준비된 뒤 병렬로 돌릴 수 있습니다. 이 구조가 있어야 긴 업무를 한 줄짜리 도구 호출 목록이 아니라 실행 가능한 계획으로 볼 수 있습니다.

4. 설계 의도 해설

핵심 한 줄: 설계 의도는 모델 지능을 늘리는 것이 아니라, 모델이 실제 도구 체계에 맞춰 생각하도록 보정하는 데 있습니다.

SkillWeaver가 흥미로운 이유는 작업 분해 자체를 고정된 프롬프트 능력으로 보지 않는다는 점입니다. 논문은 Iterative Skill-Aware Decomposition, 줄여서 SAD를 제안합니다. 먼저 LLM이 작업 계획을 만들고, 그 계획으로 후보 스킬을 검색한 뒤, 검색된 스킬 정보를 다시 참고해 작업 계획을 수정합니다. 즉 “계획을 세우고, 실제 가능한 도구를 확인하고, 다시 계획을 고치는” 피드백 루프입니다.

이 설계가 얻는 것은 현실 정합성입니다. 모델이 “데이터 정제”라고 추상적으로 말해도 실제 카탈로그에는 csv-normalize, dedupe-records, schema-validate처럼 더 구체적인 스킬만 있을 수 있습니다. SAD는 모델의 표현을 실제 스킬 이름과 범주에 맞춰 좁혀 줍니다.

대신 포기하는 것도 있습니다. 한 번에 프롬프트로 끝내는 방식보다 검색 인덱스, 스킬 메타데이터, 재순위화, 계획 검증 계층이 추가됩니다. 운영 복잡도는 늘어납니다. 그래서 이 접근은 도구가 적은 팀보다, 도구가 많고 업무 조합이 자주 바뀌는 팀에 더 잘 맞습니다.

5. 근거 및 비교

핵심 한 줄: SkillWeaver의 근거는 토큰 절감 수치보다 “작업 분해 품질이 도구 선택의 선행 조건”이라는 분석에 있습니다.

접근	바꾸는 대상	장점	한계	추천 상황
LLM-Direct	모든 도구 설명을 프롬프트에 포함	구현이 단순함	도구가 많아지면 토큰 비용과 혼동이 급증	도구 10개 이하, 단기 실험
ReAct식 반복 호출	추론과 행동을 번갈아 실행	탐색형 문제에 익숙함	복합 요청을 안정적으로 하위 작업으로 나누기 어려움	소수 도구의 탐색형 작업
정적 라우팅 규칙	키워드나 메뉴로 도구 선택	예측 가능하고 감사가 쉬움	새 업무 조합에 약함	규정 업무, 승인 흐름이 고정된 조직
SkillWeaver식 검색 라우팅	작업 분해, 스킬 검색, DAG 조합	대규모 스킬 카탈로그에 적합하고 컨텍스트 비용을 줄임	스킬 메타데이터와 실패 복구 체계가 필요함	50개 이상 도구, MCP/사내 자동화 플랫폼

논문은 공개 MCP 생태계에서 수집한 2,209개 실제 스킬과 24개 기능 범주를 기반으로 CompSkillBench를 만들고, 300개 복합 질의를 평가했습니다. 표준 LLM 작업 분해는 단계 수준 카테고리 리콜이 34.2%에 머물렀고, SAD는 분해 정확도를 51.0%에서 67.7%로 끌어올렸습니다. 논문은 이 개선을 +32.7%로 보고하며 통계적으로도 유의하다고 설명합니다.

AI타임스 보도는 효율성 수치도 소개했습니다. 모든 도구 목록을 넣는 LLM-Direct 방식은 약 88만4,000 토큰을 사용한 반면, SkillWeaver는 평균 약 1,160 토큰으로 필요한 정보만 활용했습니다. 이는 컨텍스트 토큰을 99.9% 줄였다는 주장으로 이어집니다. 다만 수치는 특정 벤치마크와 스킬 카탈로그 조건에서의 결과이므로, 실제 사내 도구 이름과 설명 품질에 따라 달라질 수 있습니다.

6. 실제 동작 흐름 / 단계별 실행 방법

핵심 한 줄: 제품팀은 SkillWeaver 전체를 복제하기보다 스킬 카탈로그와 라우팅 평가 세트부터 만들어야 합니다.

1. 스킬 카탈로그를 표준화합니다. 각 스킬에 이름, 설명, 입력 스키마, 출력 스키마, 권한 등급, 실패 코드, 예시 질의를 붙입니다. 설명은 140자 안팎의 짧은 검색용 설명과 긴 문서용 설명을 분리하는 편이 좋습니다.
2. 복합 업무 30개를 평가 세트로 만듭니다. “고객 CSV 정리 후 세그먼트별 리포트 생성”처럼 실제 업무에서 자주 나오는 요청을 모읍니다. 각 요청에는 기대 하위 작업과 허용 스킬 후보를 사람이 표시합니다.
3. 분해와 검색을 분리해 측정합니다. 최종 성공만 보면 어디가 문제인지 모릅니다. 분해 단계 수, 올바른 카테고리 포함 여부, 상위 5개 후보 내 정답 포함 여부를 따로 봅니다.
4. DAG 실행 전에 정책 검사를 넣습니다. 결제, 배포, 외부 전송, 개인정보 접근 스킬은 자동 실행하지 말고 승인 단계로 보냅니다.
5. 실패 복구를 별도 설계합니다. SkillWeaver 논문도 파일럿 실행에서 단계 성공률 86.9%, 전체 체인 완료율 76.7%를 보고했습니다. 한 단계 실패가 전체 체인을 끊는 문제를 반드시 다뤄야 합니다.

skill:
  id: csv-normalize-v2
  category: data_transform
  short_description: Normalize CSV headers, date formats, and numeric columns.
  input_schema:
    file_url: string
    date_format: string
  output_schema:
    normalized_file_url: string
    validation_report: object
  permission: internal_file_read_write
  retry_policy:
    max_attempts: 2
    fallback_skill: csv-normalize-basic

처음부터 복잡한 재순위화 모델을 붙일 필요는 없습니다. 1차 버전은 임베딩 검색으로 top-10 후보를 뽑고, LLM에게 하위 작업과 후보 10개만 보여줘 하나를 고르게 하는 방식이면 충분합니다. 중요한 것은 모든 도구를 보여주는 습관을 끊고, 후보를 좁힌 뒤 검증하는 루프를 만드는 것입니다.

7. 실수/함정(Pitfalls)

핵심 한 줄: 도구 라우팅 실패는 대부분 모델 문제가 아니라 카탈로그, 권한, 복구 설계 부족에서 시작됩니다.

1. 함정: 스킬 설명이 사람용 문서처럼 길고 추상적이다.
   예방: 검색용 설명에는 입력, 출력, 동사를 명확히 넣습니다.
   복구: 실패 로그에서 잘못 선택된 스킬 쌍을 뽑아 설명을 1문장씩 다시 씁니다.
2. 함정: 작업 분해를 너무 잘게 쪼갠다.
   예방: 쉬운 업무는 2~3단계, 어려운 업무는 4~5단계처럼 허용 범위를 둡니다.
   복구: 불필요한 중간 스킬 호출이 늘어나는 질의를 별도 bucket으로 만들고 분해 프롬프트를 조정합니다.
3. 함정: 검색 정확도만 보고 운영 배포한다.
   예방: CatR@k 같은 후보 포함 지표와 실제 체인 완료율을 함께 봅니다.
   복구: 실패한 체인은 어떤 단계에서 끊겼는지 기록하고 retry, fallback, human approval로 나눕니다.
4. 함정: 권한이 큰 도구를 일반 도구처럼 라우팅한다.
   예방: 외부 전송, 결제, 삭제, 배포 스킬은 정책 태그를 달고 자동 실행을 막습니다.
   복구: 위험 스킬 호출은 승인 큐로 돌리고, 실행 전 사용자에게 변경 요약을 보여줍니다.
5. 함정: 새 스킬을 추가해도 평가 세트를 갱신하지 않는다.
   예방: 스킬 추가 PR에는 최소 3개 예시 질의와 반례 1개를 요구합니다.
   복구: 최근 2주 라우팅 실패를 기준으로 CompSkillBench식 내부 미니 벤치마크를 갱신합니다.

8. 강점과 한계

핵심 한 줄: SkillWeaver는 도구가 많은 에이전트의 비용과 혼동을 줄이는 데 강하지만, 실행 안정성까지 자동으로 해결하지는 않습니다.

강점은 분명합니다. 첫째, 컨텍스트 예산을 줄입니다. 둘째, 도구 선택을 사람이 감사할 수 있는 단계로 쪼갭니다. 셋째, DAG 구조를 통해 병렬 실행 가능성과 의존성을 명확히 보여 줍니다. 넷째, 더 큰 모델이 항상 낫다는 단순한 결론에서 벗어나 스킬 구조와 검색 품질을 개선 대상으로 만듭니다.

한계도 뚜렷합니다. 논문은 실행 계획과 도구 선택에 초점을 맞추며, 실제 서비스 운영에 필요한 오류 복구는 아직 포함하지 않았다고 설명합니다. 파일럿 실행에서도 단계 성공률 86.9%에 비해 전체 체인 완료율은 76.7%였습니다. 여러 단계 업무에서는 한 단계만 실패해도 전체가 멈추는 복합 실패가 생깁니다.

제가 보는 반례는 규제가 강한 업무입니다. 예를 들어 결제 승인, 의료 판단, 법무 문서 제출처럼 한 번의 잘못된 도구 선택이 큰 피해를 만드는 업무라면 자동 라우팅보다 정적 워크플로와 사람 승인이 먼저입니다. SkillWeaver식 라우팅은 추천과 초안 계획에는 유용하지만, 고위험 실행은 별도 게이트를 둬야 합니다.

9. 더 깊게 공부할 포인트

핵심 한 줄: 이 주제를 더 배우려면 에이전트 프레임워크 이름보다 검색 품질, 스킬 스키마, 실행 계획 검증을 먼저 봐야 합니다.

• bi-encoder 검색과 cross-encoder 또는 LLM 재순위화의 차이
• FAISS 같은 벡터 인덱스에서 스킬 설명을 어떻게 갱신하고 버전 관리할지
• DAG 실행기에서 병렬 실행, 재시도, 롤백, 승인 노드를 어떻게 표현할지
• MCP 서버의 도구 설명을 검색 친화적으로 짧게 정리하는 방법
• CatR@1, CatR@5, ChainCat, chain completion rate 같은 라우팅 지표를 내부 제품 지표로 바꾸는 방법

추천 학습 순서는 세 단계입니다. 먼저 arXiv 초록과 Figure 1을 읽어 Decompose, Retrieve, Compose 흐름을 잡습니다. 다음으로 AI타임스 기사에서 주요 수치와 한계를 빠르게 확인합니다. 마지막으로 사내 스킬 20개만 골라 미니 카탈로그를 만들고, 실제 요청 10개에 대해 사람이 기대 스킬을 라벨링해 보십시오. 이 작은 실험이 제품 도입 여부를 가장 빨리 알려 줍니다.

10. 실행 체크리스트 + 작성자 관점

핵심 한 줄: 에이전트 도구 선택의 완료 기준은 “도구를 많이 붙였다”가 아니라 “잘못 고른 이유를 추적하고 복구할 수 있다”입니다.

Definition of Done: 사용자의 복합 요청이 하위 작업으로 분해되고, 각 단계의 후보 스킬과 선택 이유가 로그에 남으며, 실패 시 retry/fallback/approval 중 하나로 이동하고, 내부 평가 세트에서 목표 체인 완료율을 넘을 때 1차 도구 라우팅 체계가 완성된 것으로 봅니다.

작성자 관점에서 SkillWeaver는 “새 에이전트 프레임워크 하나”보다 운영 방식의 변화로 보는 편이 맞습니다. 에이전트가 쓸 수 있는 도구가 많아질수록 프롬프트는 사용설명서가 아니라 라우팅 정책의 일부가 됩니다. 저는 도구가 50개를 넘는 팀이라면 바로 거대한 에이전트 플랫폼을 사기보다, 먼저 스킬 카탈로그와 라우팅 평가 세트를 만드는 쪽을 추천합니다. 그 기반이 없으면 어떤 모델을 붙여도 실패 이유를 설명하기 어렵습니다.

11. 참고자료

• AI타임스 - 알리바바, 에이전트 도구 선택 프레임워크 ‘스킬위버’ 공개 (발행일: 2026-07-03, 확인일: 2026-07-03)
• arXiv - Compositional Skill Routing for LLM Agents: Decompose, Retrieve, and Compose (제출일: 2026-06-16, 확인일: 2026-07-03)
• arXiv HTML - SkillWeaver 논문 본문 (확인일: 2026-07-03)
• Model Context Protocol 공식 소개 (확인일: 2026-07-03)
• FAISS Documentation (확인일: 2026-07-03)