알리바바의 Qwen 팀은 2026년 7월 arXiv 학술지에 논문(2607.22529)을 발표했는데, 그 핵심은 ‘스킬 라이브러리(skill library)‘를 LLM의 자체 게임 트레이닝 커리큘럼 엔진으로 만드는 것입니다. 이 논문은 전문 용어를 많이 사용하지 않지만, 무엇을 해결했는지, 어떻게 해결했는지, 시간을 투자할 가치가 있는지 여부에 대해서는 분명히 설명하고 있습니다.
1. 문제의 진짜 고난: 자율 게임 트레이닝이 ‘다양성’과 ‘검증 가능성’이라는 난관에 직면하였습니다.
지난 2년 동안, LLM 트레이닝 패러다임은 ‘수동 태그ing + SFT’에서 ‘자체 진화(self-evolution)‘로 전환되었습니다. 핵심 아이디어는 모델이 스스로 트레이닝 데이터를 생성하고 스스로 자신을 평가하는 것입니다. 그러나 2026년까지 이 방식은 매우 구체적인 모순에 직면하였습니다.
- 환경 바인딩(environment-bound) 경로(예: LLM이 코드를 쓰고, 유니트 테스트를 실행하게 하는): 피드백은 정확하지만, 실행할 수 있는 작업 영역은 매우 제한적입니다. 기본적으로 프로그래밍 및 수학 증명과 같이 기계가 검증할 수 있는 시나리오입니다.
- 오픈 엔드 자동 생성(open-ended self-generation) 경로(LLM에게 질문을 쓰게 하고, LLM이 스스로 평가하게 하는): 작업 영역은 넓지만, 보상 신호는 신뢰할 수 없습니다. 모형은 ‘심사관을 속이는’ 것을 쉽게 배우고, 보상이 해킹되면 트레이닝이 무너집니다.
이 두 가지 문제는 산업계에서 실패 사례의 절반을 차지합니다. Skill Self-Play(이하 Skill-SP)의 접근 방법은 다음과 같습니다.기술(skill)은 기본적으로 중간 영역입니다. 기술은 재사용 가능한 ‘구조화된 실행 능력’이며, 특정 작업에 대해서는 실행 깊이가 충분하고 검증 가능하며, 다른 작업으로 전환하면 동적 경로 확장을 통해 적용 범위를 확장할 수 있습니다.
이 논문을 읽은 후 제 가장 큰 인상은 그것이 ‘기술은 중간 영역이다’라는 철학적 주장이 아니라는 것입니다. 이 논문은 기술을 실행 가능한 객체로 직접 다溜하며, RL 프레임워크에서 업데이트, 경로 변경, 또는 제거할 수 있는 동적 라이브러리로 만듭니다. 이러한 ‘추상적인 개념을 실현 가능한 엔지니어링 객체로 바꾸는’ 접근 방식은 논문 제목에서 암시된 ‘기술의 최전방’보다 훨씬 더 실용적입니다.
- 세 가지 역할: 제안자 / 해결사 / 기술 제어자
Skill-SP의 아키텍처는 매우 간단하며, 3개의 역할이 RL 루프 내에서 공동 진화하는 것이 핵심입니다.
제안자는 매우 집중적인 작업을 수행합니다. 기술 데이터베이스 S에서 랜덤으로 선택된 기술 s를 주어받고, (프롬프트 x, 검증 계약 c)를 합성합니다. c는 기계가 읽을 수 있어야 합니다. 논문에서 제시된 예는 단위 테스트와 참조 답변입니다. 제안자는 작업의 난이도에 따라 보상을 받는 것이 아니고, 제한된 교과과정 보상을 받습니다. 작업 계약 (x,c)이 구조적으로 합법인 경우에만 ‘난이도가 0.5에 가깝게’ 점수를 받고, 그렇지 않은 경우에는 0점을 받습니다. 이 단계는 논문에서 강조된 핵심 설계입니다. 이는 ‘보상 해킹의 기회’를 명시적으로 차단하며, 제안자는 ‘매우 어려운 질문을 만들었다고 가장할 수 없습니다’. 이는 난이도 평가가 계약 검증 전에 이루어지기 때문입니다.
Solver는 더 전통적인 작업을 수행합니다. 주어진 (x, c)를 받고, 답 y를 생성하며, 환경에서 c를 검증하고, R_solve를 반환합니다. Solver의 교육 목표는 Proposer가 제시한 질문을 통해 교육받는 것입니다. 그러나 Proposer는 랜덤으로 질문을 제시하지 않고, 교과과정 점수에 의해 안내되어 Solver의 현재 ‘학습 전방’으로 이동합니다(이 점수는 논문에서는 중간 난이도 점수라고 불리며, 수식은 1 - 2|v_solve - 0.5|입니다. 목표는 Solver의 성공률이 0.5에 가깝게 만들는 것입니다. 이는 모형이 ‘조금 더 노력하면 성공할 수 있는’ 범위입니다).
Skill Controller는 이 논문에서 가장 흥미로운 엔지니어링 디자인입니다. 이것은 정적인 skill 목록이 아니고, 동적으로 유지되는 라이브러리입니다. 세 가지 종류의 작업이 있습니다:
1.업데이트: Solver가 특정 스킬의 실행 경로에 기반하여, 해당 스킬의 검증 로직을 조금 더 정교화 시킵니다(예: 새로운 경계 사례 테스트 추가). 2.보관: 특정 스킬이 여러 라운드 동안 트리거되지 않았을 경우, 만료된 것으로 표시하고 마스터 라이브러리에서 제거합니다. 3.유도: 오픈 생성 흐름에서 새로운 재사용 가능한 구조를 발견하고, 이를 자동으로 새 스킬로 패키지화하여 라이브러리에 추가합니다.
실제 테스트 결과: 5번의 반복 후, 유효한 스킬 수(샤노 엔트로피 가중치)는 1에서 46으로 증가했고, 활성 스킬 수는 86으로 증가했습니다. 이는 제안자가 몇몇 고정된 스킬에만 집중하는 것이 아니라, 트레이닝 과정에서 스킬 세트가 실제로 확장되고 있음을 의미합니다.
3. 가장 중요한 엔지니어링 디자인: 기술 라이브러리가 ‘패턴 붕괴’에 의해 방해받지 않는 방법
게임 트레이닝의 전형적인 실패 패턴은모드 붕괴(mode collapse)라고 합니다. 제안자는 특정 기술로 제시된 질문에 대해 해결자가 매우 안정적인 피드백을 제공하는 것을 발견하고 그 기술을 계속 사용하여, 트레이닝 데이터 분포가 몇몇 고주파 기술로 좁혀집니다. Skill-SP은 이 점에서 3개의 보호 조치를 취했습니다.
3.1 듀얼 스트림 샘플링 (dual-stream)
100% 스킬 라이브러리에서 작업을 가져오는 것이 아닙니다. 논문의 실제 비율(그림 4의 용해 실험에서 나온 것):
- 기술 스트림: 기술 데이터베이스 S에서 기술 s를 선택하고, 제안자는 그 기술을 기반으로 작업을 생성합니다. 이 부분은 ‘Solver의 최전방에서 난이도를 안정적으로 유지’할 책임이 있습니다.
- 탐색 스트림: 기술에 제한되지 않고, 제안자는 자유롭게 작업을 생성합니다. 이를 통해 작업의 다양성을 유지하고 붕괴를 방지합니다.
실제 테스트 비율에 대한 정확한 수치는 논문에서 찾을 수 없었지만, 실험 결과에 따르면 순 스킬 전용 트레이닝(100% 스킬 스트림)은 평균 4.1 점 하락했고, 순 언가이드 SP 트레이닝(0% 스킬 스트림)은 평균 2.6 점 하락했습니다. 오직 하이브리드 스트림(비율은 공개되지 않았지만, 제목에서 두 스트림이 공존한다는 것을 암시합니다)만이 안정적으로 향상되었습니다. 이것은 스킬-SP가 오픈 세계의 자동 생성을 제거하는 것이 아니고, 스킬을 작업의 난이도와 다양성을 제어하는 ‘조정 밸브’로 사용한다는 것을 의미합니다.
3.2 난이도 점수의 게이팅(curriculum reward 게이팅)
이것은 논문에서 가장 중요한 수학 부분이고, 따로 분리해 두어야 합니다.
제안자의 보상 함수 R_propose는 단순히 ‘어려움 = 좋음’이 아니고, 다음과 같습니다:
첫 번째 항 𝟙{(x,c) is valid}은 이진 필터입니다. 작업 계약(x,c)이 구조적으로 유효해야 점수가 부여되며, 그렇지 않은 경우 전체 R_propose = 0입니다. 두 번째 항은 중간 난이도 점수이며, |v_solve - 0.5|가 작을수록 점수가 높아집니다. 즉, Proposer가 제시한 질문은 Solver의 현재 성공률이 0.5에 가깝게 만들어야 합니다.
왜 0.5인가? 0.1(매우 어렵다)이나 0.9(매우 쉽다)가 아닌가? 이유는:
- 너무 어렵다(v_solve ≈ 0): 학습자는 학습 신호를 받지 못하며, 보상은 불확실하다.
- 너무 쉽다(v_solve ≈ 1): 학습자는 아무것도 배우지 못하며, 이는 마치 문제를 반복적으로 풀는 것과 같다.
- 0.5은 ‘조금만 노력하면 할 수 있다’는 최적의 수준이며, RL은 가장 빠르게 수렴한다.
게이트는 매우 중요합니다. 게이트가 없으면, 제안자는 ‘복잡해 보이지만 c가 비어있는 문제’를 만들게 되고, 보상이 바로 0으로 설정되어 실제 문제를 만들어야 합니다. 이것이 논문 제목의 Co-Evolving Skills입니다. 단순히 기술 라이브러리가 진화하는 것 그 이상입니다. 제안자, 기술, 해결자의 세 당사자가 서로 상호 교육하며 발전하고 있습니다.
3.3 Skill Controller의 구체적인 구현
페이퍼(Paper)는 전체 코드를 제공하지 않았습니다(Qwen 팀 특허 보호), 하지만 세 가지 작업의 개요를 제공했습니다.
- 업데이트: 스킬 패키지 = (실행 가능한 템플릿, 검증기 코드, 여러 예제) 3개의 구성 요소. Controller는 이 스킬에서 Solver가 제공한 트라젝토리를 받고, 만일 실패 패턴이 특정 경계에 집중되어 있는 경우, 자동으로 테스트 케이스를 추가합니다.
- 보관: “쿨링 큐"를 유지하며, N 라운드(제가 N의 정확한 값을 찾지 못했습니다) 동안 Proposer에서 샘플링되지 않은 스킬은 보관되어 메인 라이브러리 용량을 확보합니다.
- 유도: 이 단계가 가장 흥미롭습니다. Controller는 가벼운 클러스터링을 실행하며(all-MiniLM-L6-v2 + PCA를 사용하였습니다, 그림 5b에서 설명되어 있습니다), 탐사 스트림에서 생성된 고주파의 “프로그래밍 구조”(예: “항상 리스트를 정렬한 후 중복을 제거하라”)를 새로운 스킬 패키지로 자동으로 클러스터링합니다.
이 인듀스(Induce) 링크는 기술적으로 ‘자동으로 데이터 분포에서 재사용 가능한 이전 정보를 발견하는 것’을 실현합니다. 이는 전통적인 RL의 옵션 발견(Hierarchical RL)과 같은 개념입니다. 하지만 LLM 데이터 합성에 적용되어, 2026년의 새로운 관점입니다.
- 실험 데이터: 누가 보너스를 받았고, 누가 받지 못했는가?
Paper는 두 분야에서 평가를 합니다: 도구 호출(API-Bank + BFCL 4개의 카테고리)과 논리적 추론(ZebraLogic 네 가지 난이도). 표 1은 핵심 데이터이며, 저는 ‘베이스 모델 규모’에 따라 그것을 재구성할 것입니다:
8B 이상의 강한 베이스 (Qwen3-8B)
8B 미만의 약한 베이스 (Ministral-3-8B는 원래 훈련하기 어려운 모델입니다)
이 표에서 가장 읽을 가치가 있는 것은Ministral-3-8B행입니다. 베이스는 20.7 점만 (- 기본적으로 도구를 조정하는 데 능숙하지 못함), Unguided SP는 완전히 무용지물 (+0.1), 하지만 Skill-SP은 63.6 (+42.9)로 바로 올라갑니다. 이는 弱ベース인 Ministral은 무엇을 물어야 할지 모르기 때문에, Unguided SP는 그것을 자유롭게 하게 해주고 = 쓰레기 질문을 내보냅니다. Skill-SP의 스킬 라이브러리는 그것에게 ‘어떤 도구 호출 질문을 내야 할지’ 에 대한 사전 지식을 제공하며, 이는 커리큘럼의 추가 계층과 같습니다.
Qwen3-8B와 같은 강력한 베이스에 비해, Skill-SP도 (+2.8) 증가할 수 있지만, 그 증가율은 분명히 적습니다. 이것은 산업 직관을 입증합니다.자율 학습 트레이닝의 한계 이익은 베이스와 반비례합니다- 약한 베이스는 더 많은 커리큘럼 지원이 필요하고, 강한 베이스는 더 독립적입니다. Qwen 팀은 Skill-SP의 진정한 강점을 ‘작은 모형의 빠른 사용 가능성’에 두었고, 이것은 우연이 아닙니다.
5. 용해 실험: 어떤 부품을 제거하면 무너질까요?
페이퍼(Paper)는 네 가지 주요 영역에서 상당히 제한적인 접근 방식을 취하고 있습니다.
해킹 1: 완전히 스킬 없는 루팅 (UnGuided SP)
이것은 기준 비교입니다. 이전에 우리는 작은 모형 시나리오에서는 거의 변동이 없다는 것을 보았습니다(Ministral-3-8B +0.1), 그리고 큰 모형 시나리오에서는 약간 증가합니다 (+1.6). 결론: 스킬 라우팅이 핵심 가치이며, 이를 완전히 제거하면 일반적인 자체 게임으로 되돌아갑니다.
채트 2: 스킬 만(100% 스킬 스트림, 채트 탐사)
모든 기반에서 기술 전용 트레이닝은 점수를 줄이며, 평균 4.1점을 줄입니다. 직관적인 설명: 만일 기존 기술만 기반으로 질문을 한다면, 태스크 분포는 몇몇 고발생 기술로 점차 좁혀질 것이고, 솔버는 이러한 기술에 대해 매우 능숙해질 것이지만, 일반적인 능력은 오히려 약해질 것입니다(일반적으로 트레이닝 분포에 대한 과적합 현상).
3. 자동 스킬 데이터베이스(동결된 스킬)
동결된 스킬 목록(스킬은 트레이닝 중에 동적으로 변화하지 않습니다)은 평균 2.3점을 받았습니다. 이는 Skill Controller의 update/archive/induce 세 가지 기능이 단순히 장식이 아니라 실제로 작동하고 있다는 것을 의미합니다.
4. 평등한 경로 선택(동적 경로 선택은 성능 피드백에 기반하지 않음)
유니폼 라우팅은 1.9점을 평균으로 받았습니다. 이는 동적 라우팅(컨트롤러가 서로 다른 스킬에서 솔버의 실제 성능에 따라 어떤 스킬을 더 연습해야 할지 결정하는 것)이 정적 할당보다 더 효과적이라는 것을 의미합니다.
네 가지 해결책을 하나의 문장으로 요약하자면,Skill-SP의 각 레이어는 필수적으로 설계되어야 하며, 어떤 레이어를 제거하더라도 성능이 저하될 것이며, 특히 작은 모델의 경우에는 더욱 그러할 것입니다.
6. 제가 논문을 읽은 후 알려드릴 가치가 있다고 생각하는 몇 가지 사항
(아래는 제가 논문의 내용을 바탕으로 한 판단입니다. 모두 논문 자체가 그렇게 말한 것은 아닙니다.)
1. 훈련 비용이 상당하다
논문에서는 GPU 시간을 구체적으로 언급하지 않았지만, 5번의 반복 + 5개의 서로 다른 규모의 베이스 + 두 가지 태스크 도메인을 트레이닝 하려면 최소 수천 시간의 GPU 시간이 필요할 것입니다. 이는 개인 개발자가 직접 재현할 수 있는 일이 아닙니다. 만일 스스로 해보고 싶다면, 7B 등급 모델로 1~2번의 테스트 러닝을 하여 스킬 세트가 안정적으로 성장하는지 확인해 보시기 바랍니다.
2. 스킬 라이브러리의 초기 시드가 매우 중요합니다
논문은 기술 데이터베이스의 초기 시드가 어떻게 생성되는지 자세히 설명하지 않습니다(Qwen 팀이 수백 개를 수동으로 표기했나요? 아니면 Induce 링크가 몇 번의 부트스트랩을 통해 생성했나요?). 그러나 Qwen 같은 팀은 수동 시드를 사용할 가능성이 매우 높습니다. 만약 여러분이 스스로 하려는 경우,가장 투자할 가치가 있는 것은 RL 알고리즘이 아니고, 기술 데이터베이스의 초기 품질입니다.이것은 산업 프로젝트에서 ‘데이터 회전식 모형’의 일반적인 패턴입니다. 초기에는 수동 시드가 상한을 결정하고, 후기에서는 자동 진화가 지속적인 개선을 담당합니다.
3. 애플리케이션 시나리오에는 제한이 있습니다
논문에서 검증된 두 도메인(도구 호출 + 논리적 추론)은 모두명확한 기계 검증 가능한 계약이 있는 시나리오입니다. 만일 당신이 오픈 대화 / 창의적인 글쓰기 같이 C가 없는 시나리오에 관심이 있다면, Skill-SP은 직접적으로 적용되지 않습니다. 하지만 원리는 참고할 수 있습니다: ‘작업 품질’을 기계가 검사할 수 있는 프록시(예: 길이, 다양성 점수, 스타일 임베딩)로 분해하고, 게이트드 리워드를 적용하면, 본질적으로 같습니다.
4. 이는 RLHF가 아니지만, RLHF와 보완적입니다.
해당 논문은 GRPO 같은 RL 알고리즘을 사용하여 Proposer + Solver를 교육합니다(특정 논문은 언급되어 있지 않지만, 코드 참조에 의하면 버ล(Verl) 프레임워크의 방식을 따르고 있습니다). 이는 RLHF의 ‘보상 모형 학습’과는 다른 개념입니다. 스킬-SP의 보상은 인간의 선호 모형 없이도 환경에서 직접 제공되기 때문에, ‘보상이 검증 가능한’ 상황에서는 RLHF보다 안정적입니다. 하지만 ‘보상을 인간이 평가해야 하는’ 상황에서는 RLHF에 여전히 의존해야 합니다. 두 패러다임은 대체 관계가 아닙니다.
7. 한 문장으로 요약하기
Skill Self-Play의 엔지니어링 철학은 다음과 같습니다:LLM이 자유롭게 생성하는 것은 신뢰할 수 없지만, 그것의 활용 범위를 완전히 제한하지는 않습니다. — 검증 가능하고, 확장 가능하며, 진화할 수 있는 기술 라이브러리 안에서 그것을 자유롭게 작동하게 하십시오.이 개념은 LLM 트레이닝을 하는 사람들에게 필독할 만하며, Agent 시스템을 만드는 사람들에게도 적용됩니다. — 당신은 완전한 Skill-SP 프레임워크가 필요 없지만, ‘기술 라이브러리를 동적으로 유지보수하는 것’이라는 추상적인 개념은 당신의 프로젝트에서 확실히 유용할 것입니다.
원문 논문: arXiv:2607.22529, 코드와 모델 무게는 Qwen 팀의 관행에 따라 HuggingFace에 오픈 소스로 제공되며, Qwen 리포지토리에서 향후 릴리스를 확인하세요.
참조 링크
- arXiv 논문: https://arxiv.org/abs/2607.22529
- Qwen 팀 HF 페이지: https://huggingface.co/Qwen
