SkillComposer: 스킬을 몇 개나 어떤 순서로 쓸지 한 번에 예측하는 LLM 에이전트 스킬 조합 방식에 대한 연구

9bow · 7월 6, 2026, 9:30오후

SkillComposer 연구 소개

여행 가방을 쌀 때를 떠올려 봅시다. 옷장에 있는 모든 옷을 다 넣을 수는 없습니다. 어떤 옷을 가져갈지 고르고, 가방 크기에 맞게 개수를 정하고, 꺼내 입을 순서까지 생각해서 차곡차곡 담아야 합니다. 세 가지 결정은 서로 얽혀 있어서 하나만 따로 정할 수 없습니다. LLM 에이전트에게 스킬(Skill)을 쥐여주는 일도 이와 똑같은 문제가 되었습니다.

이 논문 Generative Skill Composition for LLM Agents 는 LLM 에이전트가 커져가는 스킬 라이브러리에서 어떤 스킬을, 몇 개나, 어떤 순서로 불러올지를 하나의 시퀀스 생성 문제로 정식화하고, 이를 단 한 번의 디코딩으로 예측하는 초경량 모델 SkillComposer 를 제안한 연구입니다. University of North Carolina at Chapel Hill, Arizona State University, Honda Research Institute USA 연구진이 발표했으며, 학습 파라미터가 약 3.9M에 불과한 작은 모델이 600M 파라미터를 전부 미세조정(Fine-tuning)한 베이스라인을 실제 소프트웨어 엔지니어링 과제에서 +19.3 pp 차이로 앞서는 결과를 보여줍니다.

스킬 라이브러리의 성장과 조합 병목

스킬은 에이전트가 특정 작업을 수행하는 데 필요한 절차적 지식을 담은 모듈형 패키지입니다. 샌드박스 환경 구성, 테스트 스위트 실행, 여러 파일에 걸친 함수 리팩토링처럼 전문화된 하위 작업의 지침과 스크립트, 참고 자료를 하나로 묶어, 에이전트가 필요할 때 작업 문맥(context)에 동적으로 불러오는 방식으로 동작합니다. Anthropic의 Agent Skills 발표 이후 개방형 Agent Skills 표준이 자리잡으면서, 커뮤니티 곳곳에서 다양한 도메인의 스킬이 빠르게 축적되고 있습니다.

문제는 라이브러리가 커지면서 병목의 위치가 바뀌었다는 점입니다. 이제는 스킬을 만드는 것 이 아니라, 주어진 작업에 맞는 스킬 조합을 고르는 것 이 추론 시점의 핵심 병목이 되었습니다. 논문은 이 선택이 단순한 검색 문제가 아니라 구조적인 결정임을 강조합니다. 에이전트는 (1) 어떤 스킬을 활성화할지(부분집합 선택), (2) 몇 개나 필요한지(개수 결정), (3) 어떤 순서로 실행할지(순서 결정)를 동시에 정해야 하며, 이 세 차원은 서로 분리할 수 없습니다.

기존 접근법과 각각의 한계

기존의 선택적 스킬 활용 방식은 크게 두 갈래로 나뉩니다.

첫 번째는 직접 추론(Direct Reasoning) 방식으로, 에이전트에게 전체 스킬 컬렉션을 통째로 노출하고 작업을 풀면서 스스로 적절한 스킬을 골라 쓰게 하는 접근입니다. 하지만 이 방식에서 스킬 조합은 비구조화된 실행 흔적(trace) 속에 암묵적으로 묻혀버립니다. 어떤 스킬이 왜 선택되었는지 검사할 수 없고, 196개 스킬 전체를 프롬프트에 밀어 넣으면 문맥 비용도 크게 불어납니다.

두 번째는 검색(Retrieval) 기반 방식입니다. 임베딩(Embedding) 유사도나 LLM 기반 리랭커(reranker)로 작업과 관련성이 높은 스킬을 순위화하여 상위 k 개를 가져옵니다. 검색은 개별적으로 관련 있는 스킬을 찾아내는 데는 유용하지만, 순위 목록만으로는 몇 개를 써야 하는지 와 어떤 순서로 실행해야 하는지 를 알 수 없습니다. 예를 들어 "폐기 예정(deprecated) API 호출을 찾아서 코드베이스 전체에 리팩토링을 적용하고 회귀 테스트를 돌려라"라는 요청을 생각해 봅시다. 검색은 탐색, 편집, 테스트 스킬을 각각 찾아줄 수 있지만, 호출 지점 식별 후에 리팩토링을 적용하고 마지막에 테스트로 검증해야 한다는 실행 구조는 알려주지 못합니다.

그렇다면 도구(tool)나 API 호출 수준에서 실행 계획을 세우는 기존 계획(planning) 연구를 그대로 가져오면 되지 않을까요. 논문은 그것이 어려운 이유를 짚습니다. 도구 계획 기법들은 함수의 타입 시그니처와 반환값이라는 강한 구조 신호에 기대어 선택과 순서를 정하지만, 스킬은 여러 API 호출에 걸친 재사용 가능한 절차를 통째로 감싸기 때문에 그런 명시적 타입이 없습니다. 그래서 스킬 사이의 의존 관계는 타입이 아니라 작업 논리에 따라 잠재적으로 결정됩니다. 게다가 스킬 카탈로그는 규모는 작아도 서로 강하게 얽혀 있어서, 두 스킬의 순서를 바꾸거나 하나를 빼는 것만으로 과제의 성패가 뒤집힙니다. 평평한 유사도 검색도, 원자적 도구 탐색도 모두 들어맞지 않는 이유이며, 스킬 조합을 하나의 결합(joint) 예측 문제로 다뤄야 하는 근거이기도 합니다.

발상의 전환: 스킬 조합을 시퀀스 생성으로

이 연구의 핵심 발상은 스킬 조합을 닫힌 어휘(closed vocabulary)에 대한 시퀀스 생성 으로 바꾸는 것입니다. 라이브러리의 각 스킬을 하나의 토큰처럼 취급하고, 작은 자기회귀(autoregressive) 디코더가 작업 설명을 조건으로 스킬 인덱스의 순서 있는 시퀀스를 생성하게 합니다. 시퀀스가 끝나는 지점(STOP 토큰)이 곧 스킬 개수이고, 생성 순서가 곧 실행 순서이므로, 부분집합과 개수와 순서라는 세 가지 결정이 단 한 번의 디코딩 과정에서 자연스럽게 함께 결정됩니다. 마치 문장을 쓸 때 단어 선택과 문장 길이와 어순을 따로 정하지 않고 한 번에 써 내려가는 것과 같습니다.

실험 결과를 먼저 요약하면, SkillComposer는 GPT-5.2-Codex와 Gemini-3-Pro-Preview 두 프로덕션급 코딩 에이전트에서 스킬 없는 베이스라인 대비 각각 +23.1 pp, +18.2 pp의 과제 통과율 향상을 달성했습니다. 상위 3개 검색 방식을 능가하고, 정답 스킬을 알려주는 오라클 상한선에 근접하면서도 프롬프트 토큰 비용은 오히려 더 낮습니다.

문제 정식화: 작업 조건부 스킬 시퀀스 예측

논문은 먼저 스킬을 형식적으로 정의합니다. 각 스킬 s_i = (m_i, C_i, \pi_i, T_i, R_i) 는 메타데이터(이름과 한 줄 설명), 적용 조건, 절차적 정책, 종료 조건, 그리고 선택적인 호출 인터페이스나 지원 리소스로 구성됩니다. 도구(원자적 API 호출)나 일회성 계획, 정적 프롬프트 템플릿과 달리, 스킬은 작업과 세션을 넘어 지속되는 재사용 가능한 절차적 지식이라는 점이 다릅니다.

스킬 라이브러리 \mathcal{S} = (s_1, \ldots, s_K) 가 주어졌을 때(실험에서는 K = 196 ), 작업 조건부 스킬 시퀀스 예측(Task-conditioned Skill Sequence Prediction) 은 작업 설명 x 와 환경 문맥 c 를 입력받아 가변 길이의 스킬 인덱스 시퀀스를 예측하는 문제입니다:

\widehat{\mathbf{z}} = (\widehat{z}_1, \widehat{z}_2, \ldots, \widehat{z}_{\widehat{n}}, \text{STOP}) = f_\theta(x, c, \mathcal{S})

여기서 각 \widehat{z}_t \in \{1, \ldots, K\} 는 라이브러리의 스킬 하나를 가리키는 인덱스이고, STOP의 위치가 예측된 스킬 개수 \widehat{n} 을 결정합니다. 논문의 예시를 그대로 옮기면, "2025년 4월 1일부터 7일까지 홍수를 겪은 미시간주 USGS 관측소를 찾아 CSV로 저장하라"라는 작업에 대해 모델은 인덱스 시퀀스 (104, 184, 55, \text{STOP}) 을 출력하고, 이는 (nws-flood-thresholds, usgs-data-download, flood-detection)이라는 실행 가능한 스킬 계획으로 복원됩니다. 홍수 기준선을 먼저 가져오고, 데이터를 내려받고, 마지막에 탐지를 수행하는 순서까지 담겨 있습니다.

예측된 스킬들은 예측 순서대로 에이전트의 문맥에 로드되어 다운스트림 실행을 안내합니다. 출력 어휘가 라이브러리의 유효한 스킬 인덱스로 제한되므로, 예측된 계획은 항상 실행 가능하고 사람이 검사할 수 있습니다.

SkillComposer의 아키텍처와 동작 방식

SkillComposer는 세 가지 구성 요소로 이루어집니다. (1) 직렬화된 프롬프트를 밀집 작업 표현으로 변환하는 동결(frozen)된 텍스트 인코더, (2) 개수와 집합 소속을 각각 감독하는 보조 헤드가 붙은 제약 자기회귀 디코더, (3) 어휘적 유사도 사전 정보를 스킬 로짓(logit)에 융합하는 검색 증강 디코딩 단계입니다.

스킬 토큰화와 태스크 인코더

먼저 라이브러리의 각 스킬 s_i 를 정수 인덱스 i \in \{1, \ldots, K\} 로 토큰화하여, 출력 어휘 \mathcal{V} = \{1, \ldots, K\} \cup \{\text{STOP}\} 을 구성합니다. 예측 과정에서는 스킬의 간결한 메타데이터 m_i 만 사용하고, 전체 절차 지침과 리소스는 시퀀스가 확정된 뒤에야 활성화합니다. 이는 스킬 라이브러리의 점진적 공개(progressive disclosure) 관행을 그대로 반영한 설계입니다. 에이전트가 시작 시점에는 스킬 목록의 요약만 보고, 실제로 쓸 스킬의 본문만 나중에 로드하는 것과 같은 원리입니다.

태스크 인코더로는 동결된 Qwen3-Embedding-0.6B 를 사용합니다. 작업 설명, 환경 문맥, 스킬 메타데이터를 직렬화한 프롬프트를 1024차원 벡터로 풀링한 뒤 d = 256 차원으로 투영합니다. 인코더 파라미터는 학습하지 않고, 투영 행렬과 디코더, 보조 헤드만 학습합니다. 검색 목적으로 튜닝된 임베딩 모델을 그대로 얼려서 쓰는 이 선택이 나중에 분포 이동(distribution shift) 상황에서의 강건성을 뒷받침하는 핵심 요인이 됩니다.

자기회귀 디코더

디코더 D_\theta 는 3층, 256차원, 어텐션 헤드 4개짜리 작은 트랜스포머(Transformer)입니다. 각 토큰을 투영된 작업 벡터와 이전에 생성된 모든 토큰을 조건으로 예측합니다:

p_\theta(\mathbf{z} \mid x, c, \mathcal{S}) = \prod_{t=1}^{n+1} p_\theta(z_t \mid \mathbf{h}, \mathbf{z}_{<t})

중요한 설계 포인트는 스킬 후보들이 인덱스 번호가 아니라 자연어 설명으로 디코더에 노출된다는 점입니다. 디코더는 196개 스킬의 투영된 메타데이터 임베딩에 교차 어텐션(cross-attention)을 수행하므로, 각 후보를 그 의미로 구별합니다. 또한 매 단계의 예측이 이전에 선택된 스킬들을 조건으로 이루어지기 때문에, 연속된 스킬 사이의 의존 관계가 별도의 실행 순서 정보 없이도 자연스럽게 포착됩니다.

보조 헤드: 개수와 집합 소속에 전용 감독 신호를

자기회귀 헤드는 세 가지 결정의 결합 분포를 모델링하지만, 논문은 이 결합 정식화가 순서 결정에는 이상적인 반면 나머지 두 측면의 감독 신호를 희석시킨다고 지적합니다. 시퀀스 길이 신호는 STOP 토큰 하나의 위치에만 실려 있고, 관련 스킬에 대한 긍정 신호는 정답 위치에서만 나타납니다. 즉 "이 스킬이 어디에 오든 이 작업과 관련이 있다"라는 순서 무관 신호를 모델이 전혀 받지 못하는 것입니다.

그래서 SkillComposer는 작업 벡터에 두 개의 보조 헤드를 붙여 시퀀스 손실과 함께 공동 학습합니다.

개수 헤드(Cardinality Head) 는 작업 벡터 위의 선형 분류기로, 필요한 스킬 개수 \widehat{n} \in \{1, \ldots, 8\} 을 직접 예측합니다. 이는 자기회귀 헤드의 STOP 방출과 독립적인 길이 신호를 제공하며, 디코딩 시 종료 시점을 부드럽게 편향시키거나 강제로 자르는 데 쓰입니다.

집합 헤드(Set Head) 는 각 라이브러리 스킬을 작업 벡터와 독립적으로 대조하는 쌍별 매처(pairwise matcher)입니다. 작업 표현 \mathbf{h} 와 스킬 임베딩 \mathbf{e}_i 의 항등, 상호작용, 거리 정보를 이어붙인 뒤 2층 MLP로 관련성 점수 \sigma_i 를 산출합니다. 정답 시퀀스에 포함된 스킬인지 여부를 이진 교차 엔트로피로 감독하므로, 모든 관련 스킬이 시퀀스 내 위치와 무관하게 직접적인 그래디언트를 받습니다.

검색 증강 디코딩: 세 가지 신호의 융합

학습된 표현만으로는 부족한 부분이 있습니다. 스킬 라이브러리는 롱테일(long-tail) 분포를 따르기 때문에, 학습 데이터에 한두 번밖에 등장하지 않는 스킬은 학습된 표현이 구별해내기 어렵습니다. 반면 검색 점수는 라이브러리 전체 말뭉치에서 계산되므로 스킬별 학습 데이터가 필요 없습니다. 게다가 각 출력 인덱스가 고정된 메타데이터 문서에 대응하므로, 작업-스킬 관련성 점수를 작업당 한 번만 미리 계산해 모든 디코딩 단계에서 재사용할 수 있어 비용이 거의 들지 않습니다.

이에 따라 추론 시점에 매 디코딩 단계 t 에서 스킬 i 의 원시 디코더 로짓을 다음과 같이 융합된 로짓으로 대체합니다:

\widetilde{\ell}_t(i) = \ell_t(i) + \alpha \cdot \bar{r}_i + \beta \cdot \sigma_i

여기서 \ell_t(i) 는 이전 선택에 의존하는 문맥 신호, \bar{r}_i 는 TF-IDF 코사인 유사도로 계산한 위치 무관 검색 사전 정보, \sigma_i 는 집합 헤드가 학습한 소속 사전 정보입니다. 융합 가중치는 검증 셋에서 \alpha = 1.0, \beta = 0.5 로 선택했으며, 민감도 분석 결과 이 지점 주변의 성능 표면은 매끄러운 그릇 모양이어서 취약한 수동 튜닝이 아님을 확인했습니다. 최종적으로 폭 4의 빔 서치(beam search)와 중복 스킬 방지 제약으로 시퀀스를 생성합니다.

정리하면, SkillComposer는 매 디코딩 단계에서 해석 가능한 세 가지 신호(문맥, 어휘적 관련성, 집합 소속)를 결합하여, 라이브러리 구조를 최대한 활용하는 방식으로 스킬 계획을 생성합니다.

학습 데이터 구축: 실제 스킬 라이브러리에 기반한 9,872개 레코드

좋은 모델보다 어려운 것이 좋은 학습 데이터입니다. 연구팀은 SkillsBench 벤치마크와 함께 공개된, 사람이 직접 큐레이션한 196개 스킬 라이브러리를 기반으로 총 9,872개의 작업-스킬 시퀀스 레코드를 구축했습니다. 데이터는 순서 근거에 따라 세 그룹으로 나뉩니다.

실제 앵커(Real Anchors): SkillsBench의 사람이 작성한 소프트웨어 엔지니어링 작업 65개와 정답 스킬 주석 쌍입니다. 작업별 실행 순서는 에이전트 궤적 로그에서 복원하고, 로그가 없으면 Gemini 2.5 Pro로 보완했습니다.

단일 스킬 합성 데이터(2,880개): Gemini 2.5 Flash로 합성하여 196개 스킬 전체를 균일하게 커버합니다. 합성 프롬프트는 작업 설명에 스킬 이름을 직접 언급하지 못하게 하여, 컴포저가 표면적 단어가 아닌 의미로 스킬을 찾도록 강제합니다. 이 그룹은 단순한 질의에서 스킬 하나만 쓰고 멈추도록 모델을 보정하는 역할도 합니다.

다중 스킬 합성 데이터(6,927개): Gemini 2.5 Pro로 2~5개 스킬의 조합을 합성합니다. 순서의 근거가 되는 것은 196개 노드로 구성된 스킬 의존성 그래프 입니다. 상류 스킬의 출력 타입이 하류 스킬의 입력 타입과 겹치는 의존성 간선(658개)은 데이터 흐름이 강제하는 순서를, 실제 작업 궤적에서 스킬이 함께 등장한 워크플로우 간선(266개)은 공유 타입이 없을 때의 경험적 순서를 인코딩합니다. 합성 시 의존성 간선이 있으면 순서 제약을 프롬프트에 명시적으로 주입해 데이터 흐름 방향이 보존되도록 했습니다.

품질 관리도 체계적입니다. 모든 합성 레코드는 정확 문자열 일치, 문자 트라이그램 자카드 유사도 0.6 초과, 문장 임베딩 코사인 유사도 0.92 초과라는 세 단계 중복 제거를 거치고, 스킬을 추가하거나 빼거나 이름을 바꾼 응답, 순서 제약을 어긴 응답은 모두 폐기됩니다. 전체 말뭉치는 90/5/5로 학습/검증/테스트에 분할됩니다.

실험 결과 및 성능 분석

평가는 두 축으로 진행됩니다. 첫째는 예측된 계획이 정답 스킬 부분집합, 개수, 순서와 얼마나 일치하는지 측정하는 조합 품질 평가이고, 둘째는 더 나은 스킬 계획이 실제 에이전트 실행 성능으로 이어지는지 확인하는 다운스트림 과제 성능 평가입니다.

스킬 조합 예측 품질: 154배 작은 모델이 SFT를 이기다

인-분포(in-distribution) 합성 테스트(n = 494 )에서 SkillComposer는 Set F1 73.9\% 를 기록하여, 600M 파라미터 전체를 미세조정한 지도 미세조정(SFT) 베이스라인(71.1\% )을 +2.8 pp, 196개 스킬을 프롬프트 하나에 넣고 판단시킨 Gemini-2.5-Flash LLM 판정(judge) 베이스라인(61.0\% )을 +12.9 pp 앞섰습니다. 학습 파라미터는 3.9M으로 SFT의 약 \frac{1}{154} 에 불과하고, 학습 연산량은 약 25\times 적습니다. MRR과 nDCG@5에서도 같은 순위가 유지되어, SFT가 정답 시퀀스를 텍스트로 통째로 암기할 수 있는 조건에서도 자기회귀 헤드가 더 날카로운 상위 순위를 만들어냄을 보여줍니다.

주목할 부분은 두 학습 모델 모두 검색과 LLM 판정 베이스라인을 압도했다는 점인데, 여기에는 정답 스킬 개수를 미리 알려주는 오라클-k 검색 상한선까지 포함 됩니다. 검색은 정답 개수를 알아야 제 성능이 나오는 반면, 학습 모델은 "누구를 몇 개나"를 함께 예측하기 때문입니다.

개수별로 쪼개 보면 SkillComposer의 강점이 어디서 오는지 더 분명해집니다. 위 그림처럼 스킬 하나만 필요한 k = 1 구간에서 SkillComposer는 71\% 로 SFT(53\% )와 Gemini(50\% )를 크게 앞섭니다. 필요 없는 스킬을 과잉 방출하는 것이 가장 크게 벌점을 받는 구간에서 개수 보정이 잘 되어 있다는 뜻이며, 그 결과 매크로 평균 Set F1도 74\% 로 가장 높습니다.

분포 이동에서의 강건성: 작은 전문가가 큰 제너럴리스트를 이긴다

더 흥미로운 결과는 실제 작업 홀드아웃(n = 65 ) 평가입니다. 65개 실제 작업을 학습과 검증에서 전부 제거하고 합성 데이터만으로 학습한 뒤 실제 작업으로 시험하는, 분포 이동 상황을 시뮬레이션한 설정입니다.

여기서 SFT는 합성 테스트 대비 Set F1이 27.5 pp 급락한 반면, SkillComposer는 11 pp만 하락했습니다. 동일한 학습 데이터와 라이브러리에서 +19.3 pp의 격차가 벌어진 것입니다. 논문은 그 원인을 이렇게 분석합니다. SFT는 합성 템플릿의 분포를 암기했기 때문에 실제 작업의 표현 방식 앞에서 기댈 사전 지식이 없지만, SkillComposer는 검색 목적으로 튜닝된 동결 인코더가 전이(transfer)에 유리한 귀납적 편향을 공급한다는 것입니다. 반대로 검색 베이스라인들은 실제 작업의 문구가 스킬 설명과 더 가까워서 오히려 점수가 오르는데, 그럼에도 개수를 예측해야 하는 방법 중에서는 SkillComposer만이 오라클-k 상한선에 근접했습니다.

다운스트림 에이전트 성능: 예측 품질이 실행 성능으로 이어진다

상류의 조합 예측이 좋아지면 실제 에이전트 실행도 좋아질까요? 연구팀은 SkillsBench 88개 과제 중 75개를 대상으로(파일 확장자만 봐도 스킬이 정해지는 문서 처리 과제 13개는 제외), GPT-5.2-Codex와 Gemini-3-Pro-Preview 두 에이전트에서 과제당 3회씩 시도하여 통과율을 측정했습니다. 결정론적 pytest 검증기와 1,200초 타임아웃을 쓰는 Harbor 평가 프레임워크 위에서 진행된 실험입니다.

스킬 조건	Codex 통과율(%)	Codex 토큰	Gemini 통과율(%)	Gemini 토큰
Gold Skills (오라클 상한)	51.1	1.12M	48.4	1.18M
No Skills	22.2	0.94M	25.8	0.99M
All Skills (196개 전부)	29.3	1.27M	38.7	1.33M
Retrieval (top-3)	44.0	1.09M	41.8	1.14M
Retrieval (오라클, 정답 집합 내 검색)	44.0	1.13M	42.2	1.19M
SkillComposer	45.3	1.03M	44.0	1.08M

결과의 패턴은 두 에이전트에서 일관됩니다. 스킬 없이 실행하면 통과율이 22.2\% / 25.8\% 에 그치고, 정답 스킬을 공급하는 오라클 상한선까지는 약 25 pp의 개선 여지가 존재합니다. 라이브러리 196개를 통째로 프롬프트에 밀어 넣는 All Skills 조건은 이 여지의 일부만 회복하면서 Codex 프롬프트를 1.27M 토큰으로 부풀립니다. "문맥을 스킬로 가득 채우는 것만으로는 부족하다"라는 것이 수치로 확인된 셈입니다.

SkillComposer는 오라클 스킬 레이블 없이 보정된 순서 있는 쇼트리스트를 예측하여 45.3\% / 44.0\% 통과율을 달성했습니다. 이는 두 검색 베이스라인을 모두 이기고, 정답 스킬 집합 안에서만 검색하는 Retrieval (oracle) 조건(44.0\% / 42.2\% )과 대등하거나 그 이상이며, 스킬을 로드하는 조건 중 가장 적은 프롬프트 예산(Codex 기준 1.03M 토큰)을 사용합니다. 스킬 없는 조건에서 오라클 상한까지의 개선 여지 중 약 80\% 를 닫은 결과입니다.

Ablation: 모든 구성 요소가 제 몫을 한다

구성 요소별 기여도를 보면 설계의 근거가 분명해집니다. 자기회귀 헤드만 쓰면 Set F1이 69.3\% 인데, 집합 헤드를 함께 학습하면 71.8\% 로 오릅니다. 순서와 무관하게 모든 정답 스킬에 그래디언트를 흘려주는 보조 감독이 실제로 효과가 있다는 뜻입니다. 디코딩 시점의 융합도 필수적입니다. 전체 모델(73.9\% )에서 집합 융합을 끄면(\beta = 0 ) 65.0\% 로, 검색 사전 정보를 끄면(\alpha = 0 ) 67.5\% 로 떨어집니다.

디코딩 사전 정보로 무엇을 쓸지에 대한 비교도 흥미롭습니다. 희소(sparse) 검색인 TF-IDF(73.9\% )가 밀집 임베딩인 Qwen3-Embedding 코사인(68.8\% )과 BM25(70.0\% )를 모두 이겼습니다. 논문의 해석은 이렇습니다. 닫힌 라이브러리에는 짧고 구문적으로 특수한 스킬 이름 196개가 노출되어 있어 토큰 수준의 겹침이 이들을 구별하는 데 고정밀 신호가 되는 반면, 밀집 임베딩은 더 넓은 의미적 맥락을 평균 내면서 과잉 일반화한다는 것입니다. 다만 작업 표현 자체에는 여전히 밀집 인코더가 적합하므로, SkillComposer는 작업 인코딩에 Qwen3-Embedding을, 디코딩 사전 정보에 TF-IDF를 써서 양쪽의 강점을 결합합니다.

추론 지연 시간은 SFT와 같은 등급이면서 API 기반 LLM 판정보다 100배 수준으로 빠르고, 위 그림처럼 학습 파라미터 대비 정확도에서 예측-k 방법 중 파레토 최적(Pareto-optimal) 위치를 차지합니다.

사례 분석: 격차는 어디서 오는가

부록의 사례 연구 세 건은 통과율 격차의 메커니즘을 구체적으로 보여줍니다.

사례 1: top-k 절단이 결정적 스킬을 놓칠 때. 적응형 크루즈 컨트롤 시뮬레이션 과제에서 top-3 검색은 눈에 띄는 제어 스킬 세 개를 고르느라 PID 게인을 한 번에 산출해주는 imc-tuning-rules 스킬을 잘라냈고, 에이전트는 게인을 손으로 튜닝하다가 3회 중 2회 스펙을 놓쳤습니다(보상 0.33 ). 흥미롭게도 사람이 큐레이션한 Gold Skills조차 병목과 무관한 I/O 포맷 스킬 두 개를 끼워 넣은 채 0.33 에 그쳤는데, SkillComposer는 정답 키와 다른 조합을 선택하여(I/O 래퍼를 버리고 imc-tuning-rules를 추가) 만점(1.00 )을 회복했습니다.

사례 2: 더 날씬한 스킬 집합이 정답을 이길 때. 외계행성 공전 주기 검출 과제에서 SkillComposer는 전처리, Lomb-Scargle, TLS로 이어지는 최소 레시피에 수렴해 매 시도 성공한 반면, 정답 팩은 중복 추정기와 무거운 워크플로우 래퍼까지 포함해 에이전트를 더 긴 파이프라인으로 끌고 갔고 결국 0.00 에 그쳤습니다. 전체 라이브러리를 쏟아붓는 All Skills 조건이 통과율을 떨어뜨리는 것과 일관된 결과로, 잘 고른 작은 집합이 큰 큐레이션 집합을 이길 수 있음을 보여줍니다.

사례 3: 긴 체인에서의 과소 방출. 반대로 Lean 4 증명 과제에서는 SkillComposer가 스킬 하나만 방출하고 멈추는 바람에 귀납 단계에 필요한 정리 증명 스킬을 놓쳤습니다(0.67, 3개를 모두 유지한 검색은 1.00 ). 이 "한 슬롯 부족" 패턴은 정답 시퀀스가 2~3개 이상일 때 반복되는데, 합성 말뭉치가 3개 이하 조합에 치중되어 있다는 데이터 구축상의 원인을 논문 스스로 지목합니다. 가장 실행 가능한 개선 여지가 긴 시퀀스 학습 레코드 구축에 있다는 진단입니다.

한계점 및 시사점

논문이 밝히는 한계는 명확합니다. 연구는 텍스트 전용 작업 설명과 코드 중심 스킬 라이브러리에 집중했으며, 스크린샷이나 음성 같은 멀티모달 작업 명세, 스킬 라이브러리가 온라인으로 갱신되는 장기 상호작용 설정, 과학 워크플로우나 로보틱스처럼 이종 도구와 물리 액추에이터로 조합 그래프가 확장되는 도메인은 향후 과제로 남겼습니다. 또한 SkillComposer는 소형 LM과 임베딩 백본의 특성(사전 학습 말뭉치의 언어적 편향과 작업 커버리지)을 그대로 물려받으므로, 더 강한 백본과 더 큰 큐레이션 라이브러리로 조합 정확도를 끌어올리는 것도 남은 방향입니다. 위 사례 3에서 본 긴 체인 과소 방출 역시 데이터 구축 개선이 필요한 지점입니다.

그럼에도 이 연구가 주는 메시지는 실용적입니다. 스킬 생태계가 커질수록 "스킬을 어떻게 고르고 배열할 것인가"는 모든 에이전트 개발자가 마주칠 문제인데, 이 논문은 그 결정을 프롬프트 엔지니어링이나 범용 검색에 맡기는 대신, 라이브러리 구조를 활용하는 3.9M짜리 전용 컴포저로 풀 수 있음을 보였습니다. 결론의 표현을 빌리면, "닫힌 에이전트 스킬 라이브러리에서는, 라이브러리의 구조를 활용하는 작은 전문가가 제너럴리스트 LM을 키우는 것보다 더 믿을 만한 컴포저"라는 것입니다. 스킬 라우팅 계층을 자체 운영하려는 팀이라면, 프론티어 API 호출 없이 로컬에서 밀리초 단위로 도는 이런 경량 컴포저 접근이 비용과 지연 시간 양쪽에서 매력적인 선택지가 될 수 있습니다.

Generative Skill Composition for LLM Agents 논문

SkillComposer 프로젝트 홈페이지

더 읽어보기

이 글은 GPT 모델로 정리한 글을 바탕으로 한 것으로, 원문의 내용 또는 의도와 다르게 정리된 내용이 있을 수 있습니다. 관심있는 내용이시라면 원문도 함께 참고해주세요! 읽으시면서 어색하거나 잘못된 내용을 발견하시면 덧글로 알려주시기를 부탁드립니다.

파이토치 한국 사용자 모임이 정리한 이 글이 유용하셨나요? 회원으로 가입하시면 주요 글들을 이메일로 보내드립니다! 텔레그램(Telegram)이나 Slack/Discord/Teams/Dooray/GoogleChat 등으로도 새 글 알림을 받으실 수 있습니다.

아래쪽에 좋아요를 눌러주시면 새로운 소식들을 정리하고 공유하는데 힘이 됩니다~