당신의 에이전트 기술은 정말로 유용한가? Microsoft의 이중 논문을 통한 기술 평가 및 자기 진화 최적화 심층 분석

아무도 묻고 싶어 하지 않는 질문: 당신의 기술(Skill)이 실제로 도움이 되고 있는가?

당신은 에이전트(Agent)를 위해 정교하게 구조화된 기술(Skill)을 만드는 데 오후 시간을 보냈습니다. 명확한 단계, 철저한 예외 상황(edge-case) 노트, 잘 정해진 출력 요구 사항까지 갖추었습니다. 몇 번의 수동 테스트를 거쳤고, 출력 결과는 훌륭해 보였습니다. 그래서 당신은 이를 배포했습니다.

3주 후, 당신은 기술(Skill)이 존재하기 전과 비교했을 때 일부 작업 성공률이 오히려 떨어졌다는 사실을 발견합니다.

이것은 가설이 아닙니다. 2026년 5월, Microsoft Research는 SkillLens ("From Raw Experience to Skill Consumption")와 SkillOpt ("Executive Strategy for Self-Evolving Agent Skills")라는 두 편의 동시 논문을 발표하여 이러한 실패 모드(failure mode)를 대규모로 측정했습니다. 그들의 연구 결과에 따르면, 부정적 전이(negative transfer)가 사례의 25%에서 발생하며, 단순히 텍스트를 읽는 것만으로는 나쁜 기술을 안정적으로 식별할 수 없습니다.

한 논문은 "왜 기술이 때때로 역효과를 내는지"에 대해 답합니다. 다른 논문은 "어떻게 기술을 체계적으로 더 좋게 만들 것인지"에 대해 답합니다. 이 두 논문은 함께 에이전트 능력 향상을 위한 새로운 패러다임을 그려냅니다.

제1부: SkillLens — 전체 기술 생애주기(Skill Lifecycle) 매핑

기술(Skill)은 점이 아니라 파이프라인(Pipeline)이다

대부분의 실무자들은 기술(Skill)을 "에이전트를 위한 텍스트 명령 블록"으로 생각합니다. SkillLens는 이를 **3단계 생애주기(three-stage lifecycle)**로 분해합니다.

1단계: 경험 생성 (Experience Generation)
    대상 모델(Target model) M이 훈련 작업을 실행하여 궤적(trajectories, 성공과 실패 모두 포함)의 경험 풀(experience pool)을 생성함
...

이 체인에는 두 가지 뚜렷한 역할이 있음에 주목하십시오: 추출기(Extractor) (궤적에서 지식을 추출함)와 대상(Target) (작업 성능을 향상시키기 위해 지식을 소비함)입니다. SkillLens의 핵심 통찰은 이 두 역할이 독립적이라는 것입니다. 즉, 강력한 작업 실행기(task executor)가 반드시 강력한 추출기(extractor)인 것은 아니며, 그 반대도 마찬가지입니다.

두 가지 새로운 지표: EE와 TE

이 두 가지 효과를 분리하기 위해, 논문은 두 가지 상호 보완적인 지표를 도입합니다:

Extraction Efficacy (EE, 추출 효능): 추출기 (Extractor)를 고정합니다. 이 추출기가 서로 다른 타겟 모델 (Target models)들에 대해 얼마나 신뢰성 있게 유용한 기술 (Skills)을 생성해내는가?

$$\text{EE}(E, \mathcal{D}) = \frac{1}{|\mathcal{M}|} \sum_{M \in \mathcal{M}} \Delta(E, M, \mathcal{D})$$

Target Evolvability (TE, 타겟 진화 가능성): 타겟 모델 (Target model)을 고정합니다. 서로 다른 추출기들이 해당 모델 자신의 경험으로부터 기술을 증류 (Distill)할 때, 모델이 얼마나 개선되는가?

$$\text{TE}(M, \mathcal{D}) = \frac{1}{|\mathcal{E}|} \sum_{E \in \mathcal{E}} \Delta(E, M, \mathcal{D})$$

유용한 비유를 들자면, EE는 "한 명의 교사가 얼마나 많은 다양한 학생들을 잘 가르치는가"를 측정하고, TE는 "한 명의 학생이 얼마나 많은 다양한 교사들로부터 배울 수 있는가"를 측정합니다. 두 차원 모두 높은 것이 이상적입니다.

실험 규모: 대규모 교차 매트릭스 (Cross-Matrix)

본 연구는 매우 포괄적입니다:

5개 도메인 (Domains): 체화된 계획 (Embodied planning, ALFWorld), 생산성 (Productivity, SpreadsheetBench), 소프트웨어 엔지니어링 (Software engineering, SWE-bench-Verified), 웹 검색 (Web search, SEAL-0), 도구 호출 (Tool calling, BFCL-v4)
6개 타겟 모델 (Target models): GPT-5.4, GPT-5.4-mini, Gemini-3.1-Pro, Gemini-3.1-Flash-Lite, Qwen3.5-35B, Qwen3.5-9B
5개 추출기 모델 (Extractor models): 동일한 세트 (단, Qwen3.5-9B는 구조화된 추출 프로토콜을 신뢰성 있게 따르지 못하여 추출기로서 제외됨)

핵심 설계 원칙은 **최소한의 스캐폴딩 (Minimal scaffolding)**입니다. 추출 프레임워크는 도메인 특화 휴리스틱 (Heuristics), 필터링 규칙, 최적화 기법들을 의도적으로 제거합니다. 오직 기본적인 2단계 "궤적별 분석 (Per-trajectory analysis) $\rightarrow$ 계층적 통합 (Hierarchical consolidation)" 파이프라인만이 남게 되며, 이를 통해 성능 차이가 파이프라인 엔지니어링이 아닌 추출기의 본질적인 능력 (Intrinsic capability)을 반영하도록 보장합니다.

핵심 발견 1: 75%의 긍정적 효과, 그러나 25%의 부정적 전이 (Negative Transfer)

표 1 (Table 1)은 극명한 모습을 보여줍니다:

모델이 생성한 기술은 항목의 75%에서 다운스트림 성능 (Downstream performance)을 향상시킵니다. 하지만 부정적 전이 (Negative transfer) 또한 흔하게 나타납니다: 항목의 25%에서 $\Delta < 0$을 기록했습니다.

부정적 전이 (Negative transfer) 비율은 도메인에 따라 상당히 다르게 나타납니다. SpreadsheetBench와 SWE-bench-Verified는 가장 낮은 비율(~13%)을 보인 반면, ALFWorld는 47%에 달했습니다. 즉, 이 도메인에서는 기술을 추가하는 것이 도움이 되기보다 거의 절반의 확률로 오히려 해가 됩니다.

훨씬 더 직관에 어긋나는 사실은 다음과 같습니다: 더 강력한 작업 실행 (Task-execution) 모델이라고 해서 추출 품질 (Extraction quality)을 보장하지는 않습니다. SpreadsheetBench에서 경량 모델인 Gemini-3.1-Flash-Lite가 가장 높은 EE를 달성한 반면, 해당 벤치마크 자체에서 가장 강력한 성능을 보인 GPT-5.4는 추출기 (Extractor)로서 최하위를 기록했습니다. 타겟 모델이 실제로 사용할 수 있는 절차적 가이드 (Procedural guidance)로 타겟 특화 궤적 (Target-specific trajectories)을 변환하는 것은 작업을 해결하는 것과는 별개의 능력입니다.

핵심 발견 2: 형식은 중요하지 않으며, 내용이 중요하다

순서가 있는 목록 (Ordered-list) 형태의 기술 (Skill)이 산문 (Prose) 형태의 기술보다 성능이 더 좋을 것이라고 추측할 수도 있습니다. SkillLens는 이를 직접 테스트했습니다:

동일한 기술을 네 가지 표준 형식(순서가 있는 목록, 순서가 없는 목록, 체크리스트, 산문)으로 다시 작성하고, Friedman test를 사용하여 특정 형식이 일관되게 더 높은 순위를 차지하는지 확인한다.

결과: 형식은 어떤 타겟에도 감지 가능한 영향을 미치지 않았습니다 (모든 p > 0.34). 반면, 추출기 (Extractor)를 교체하는 것은 6개 타겟 중 5개에서 유의미한 영향을 미쳤습니다 (p < 0.005).

이것이 시사하는 바는 명확합니다: 기술의 형식을 구성하는 데 집착하는 것은 헛된 노력입니다. 기술이 _어떻게 배치되어 있는지_보다 기술이 _무엇을 말하는지_가 훨씬 더 중요합니다.

핵심 발견 3: 그럴듯해 보이는 기술은 유용성을 예측하지 못한다

이것은 가장 놀라운 발견입니다. 실험에서는 GPT-5.4에게 심판 역할을 맡겼습니다: 동일한 (타겟 모델, 도메인) 쌍에서 추출된 두 개의 기술이 주어졌을 때, 다운스트림 작업 (Downstream tasks)에서 더 나은 성능을 보일 기술을 선택하게 합니다.

가이드가 없는 경우: 가이드가 없는 심판은 단 46.4%의 정확도만을 달성했습니다. 이는 무작위 추측(50%)과 구별할 수 없는 수준입니다. 실제 성능 차이가 δ ≥ 5%인 쌍(명확하게 더 나은 경우)에서, 심판이 실제로 성능이 더 높은 기술을 선택하는 경우는 단 **15.8%**에 불과했습니다. 이는 실제 유용성과 명백히 _역전_된 결과입니다.

다시 말해, 더 유창하고 일관성 있게 읽히는 기술일수록 실제 다운스트림(downstream) 작업에서는 더 낮은 성능을 보이는 경향이 있습니다. 텍스트의 그럴듯함(Textual plausibility)이 실제 유용성(actual utility)과 분리된 것입니다.

이는 직접적인 실무적 함의를 갖습니다: LLM에게 텍스트를 판단하도록 요청하는 방식으로는 기술을 신뢰성 있게 선별할 수 없다는 점입니다. 품질의 격차는 표면적인 형태보다 더 깊은 곳에 존재합니다.

각 단계별 심층 분석: 무엇이 실제로 기술 품질을 결정하는가?

1단계 (경험 생성, Experience Generation): 성공/실패 비율이 한계치를 결정한다

추출기(extractor, GPT-5.4-mini)를 고정한 상태에서, 연구진은 동일한 궤적(trajectories)으로부터 성공 비율이 0%/25%/50%/75%/100%인 경험 풀(experience pools)을 샘플링하여 결과로 나타난 기술들을 비교했습니다.

핵심 발견: 경험의 구성이 기술 품질을 강력하게 형성하며, 최적의 성공/실패 비율은 도메인(domain)마다 다르다는 것입니다.

SpreadsheetBench는 대부분 성공적인 경험을 선호함
SWE-bench는 대부분 성공적인 풀에서 정점을 찍음
ALFWorld는 실패가 많은 풀에서 가장 좋은 성능을 보임 (실패를 통해 유효하지 않은 행동과 막다른 상태(dead-end states)를 파악할 수 있음)

하나의 보편적인 규칙: 모든 사례가 실패인 풀은 일관되게 최악의 기술을 생성한다. 성공적인 궤적은 기술 추출의 토대입니다. 성공적인 궤적은 단순히 피해야 할 것을 나열하는 것이 아니라, 에이전트의 행동 공간(action space)을 좁혀주는 긍정적인 절차적 신호(positive procedural signals)를 제공합니다.

2단계 (기술 추출, Skill Extraction): 미학이 아닌 깊이가 중요하다

"왜 그럴듯해 보이는 기술들이 실패하는가?"라는 질문에서 시작하여, 높은 Δ(High-Δ) 기술 쌍과 낮은 Δ(Low-Δ) 기술 쌍을 질적으로 검사한 결과 실제 차이점이 드러났습니다.

높은 Δ 기술은 구체적이고 실행 가능한 해결책을 제공합니다 (예: "호스트 엔진이 수식 문자열을 평가하지 못할 경우, 정적 값을 미리 계산하여 셀에 직접 작성하십시오"). 반면 낮은 Δ 기술은 일반론적인 격언만을 제공합니다 (예: "코딩하기 전에 계약을 해결하십시오").

생생한 비유를 들자면, 고품질의 기술은 특정 맥락에서의 구체적인 실패 모드(failure modes)와 그에 대한 구체적인 해결책을 기록하는 **실무자의 디버깅 일지 (practitioner's debugging journal)**처럼 읽힙니다. 반면 저품질의 기술은 베스트 프랙티스(best practices)에 대해 "우리 모두 이미 알고 있는 내용"이라고 말하는 강의처럼 읽힙니다.

3단계 (기술 소비 (Skill Consumption)): 동일한 기술, 대상에 따라 매우 다른 효과

동일한 기술을 서로 다른 모델에 주입하면 매우 상이한 결과가 나타날 수 있습니다. SpreadsheetBench에서 강력한 풀(strong-pool) 기술은 GPT-5.4의 성능을 +9.0만큼 향상시키지만, 일부 Qwen3.5-9B 조건에서는 부정적 전이(negative transfer)를 일으킵니다.

행동 분석(Behavioral analysis)은 그 이유를 설명합니다. 기술 소비는 새로운 명시적 도구 호출(explicit tool calls)을 트리거하기보다는 **대상 모델의 기본 정책(default policy)을 재형성(reshapes)**합니다. GPT-5.4의 경우, 이 기술은 모델이 스프레드시트 수식을 작성하는 대신 Python으로 결과를 계산하고 정적 값을 다시 쓰는 방향으로 유도하며, 이는 수식 안정성 문제를 해결하기 위한 정확한 전략 수정입니다. Qwen3.5-9B의 경우, 동일한 가이드가 모델을 더 복잡한 통합 문서 네이티브(workbook-native) 워크플로로 밀어붙여 시트 수준 작업의 구조적 정확성은 향상시키지만, 미세한 작업(fine-grained operations)에서는 더 많은 실행 실패를 초래합니다.

진단에서 개입으로: 메타 기술 가이드 추출 (Meta-Skill Guided Extraction) (RQ3)

분석 결과, 기술의 품질은 표면적으로는 보이지 않는 숨겨진 차원(hidden dimensions)에 의해 결정된다는 사실이 드러났습니다. RQ3는 다음과 같이 질문합니다: 이러한 발견을 추출 프로세스 자체에 즉시 적용 가능한 구체적인 개선 사항으로 전환할 수 있는가?

1단계: 어떤 차원이 실제로 유용성을 예측하는지 발견하기

논문은 완전히 자동화된 루브릭 발견(rubric-discovery) 파이프라인을 설계했습니다:

기술 격차(high-gap)가 큰 기술 쌍을 GPT-5.4에 입력하여, 쌍별 차이 특징(per-pair difference features)을 추출합니다.
이를 반복적으로 병합하고 통합하여 7개의 후보 차원(원시 루브릭 (raw rubric))을 만듭니다.
각 차원의 "더 나은 비율(better-rate)"을 측정합니다. 즉, 해당 차원으로만 점수를 매겼을 때 Δ(델타) 값이 더 높은 기술이 얼마나 더 유리한 판단을 받는지를 측정합니다.

오직 3개의 차원만이 유용성과 일관되게 일치하며, 이를 통해 **검증된 루브릭 (validated rubric)**이 형성됩니다:

차원 (Dimension)	포착하는 내용 (What It Captures)
실패 메커니나 인코딩 (Failure Mechanism Encoding)	해당 기술이 특정 실패 모드 (failure modes)와 그 트리거 (triggers)를 인코딩하는가?
...

2단계: 루브릭의 변별력 검증 (Verify the rubric's discriminating power)

3차원으로 검증된 루브릭 (validated rubric)을 판사 (judge)의 가이드로 사용했을 때, 151개의 격차가 큰 (high-gap) 쌍에 대해 전체 정확도가 46.4%에서 73.8%로 상승했습니다. 가이드가 없던 판사가 15.8%의 확률로 명백히 틀렸던 가장 어려운 쌍들 (δ ≥ 5%)에서도, 가이드가 있는 판사는 이제 대부분의 경우 올바르게 선택합니다.

3단계: 메타 기술로의 운영화 (Operationalize it as a Meta-Skill)

검증된 루브릭은 압축된 **메타 기술 (meta-skill)**로 패키징됩니다. 즉, 추출기 (extractor)의 시스템 프롬프트 (system prompt)에 직접 주입되는 생성 시점의 사전 지식 (generation-time prior)입니다. 세 가지 조건에 대해 테스트를 진행했습니다:

가이드가 없는 원래의 추출 (Original unguided extraction)
7차원 "개연성 루브릭 (plausibility rubric)"에 의해 가이드된 추출
3차원 검증된 루브릭에 의해 가이드된 추출

결과는 명확합니다:

개연성 루브릭은 평균 성능을 저하시킵니다 (−0.59pp, 9개 셀 중 6개 퇴보). 반면, 검증된 루브릭은 9개 셀 모두를 개선하며 (+평균 1.55pp), SpreadsheetBench에서 가장 큰 이득(+2.3 ~ +3.7pp)을 보였습니다.

"합리적으로 보인다 (seems reasonable)"라는 기준을 사용하는 것은 추출 성능을 적극적으로 손상시킵니다. 오직 경험적으로 검증된 차원만이 성능을 신뢰성 있게 향상시킵니다.

제2부: SkillOpt — 신경망처럼 기술 문서 학습시키기

핵심 비유: 기술 (Skill) ≈ 모델 가중치 (Model Weights)

SkillLens는 기술이 체계적으로 평가되고 개선될 수 있음을 알려줍니다. SkillOpt는 다음과 같이 질문합니다: 가중치 공간 최적화 (weight-space optimization)를 재현 가능하게 만드는 것과 동일한 규율을 기술 문서 자체에 적용하여 최적화 루프 (optimization loop)를 적용할 수 있는가?

이 비유는 논문에 명시적으로 기술된 SkillOpt 전체 설계의 기초입니다:

딥러닝 (Deep Learning)	SkillOpt 대응 요소
파라미터 (가중치) (Parameter (weights))	기술 문서 (Skill document)
...

이는 단순히 장식적인 프레임워크가 아니라 **운영적 (operational)**인 것입니다. 배치 크기 (Batch size), 학습률 (learning rate), 검증 (validation), 모멘텀 (momentum) — 모든 개념은 SkillOpt에서 그에 상응하는 텍스트 공간 (text-space) 구현체를 가집니다.

SkillOpt 루프 (The SkillOpt Loop)

최적화 파이프라인 (optimization pipeline)은 두 가지 시간 척도(timescales)에서 작동합니다: 스텝별 업데이트 (per-step updates)와 에포크 단위 통합 (epoch-wise consolidation)입니다.

순방향 패스 (Forward Pass): 롤아웃 증거 (Rollout Evidence)

각 최적화 스텝에서, 동결된 타겟 모델 (frozen target model)은 현재 기술 (skill)을 사용하여 일련의 훈련 태스크 (training tasks)를 실행하고 점수가 매겨진 궤적 (scored trajectories)을 생성합니다. 작은 배치 (small batches)는 빠르게 업데이트되지만 노이즈가 많으며, 큰 배치 (larger batches)는 더 안정적인 패턴을 드러냅니다. SkillOpt는 또한 누적 (accumulation)을 지원합니다. 즉, 여러 롤아웃 배치 (rollout batches)를 별도로 반영한 후 하나의 업데이트로 병합할 수 있어, 실행 처리량 (execution throughput)과 업데이트 빈도 (update frequency)를 분리할 수 있습니다.

역방향 패스 (Backward Pass): 미니배치 성찰 (Minibatch Reflection)

옵티마이저 모델 (optimizer model) (별도의 최첨단 LLM)은 궤적을 구조화된 기술 편집 (structured skill edits)으로 변환합니다. 결정적으로, 이 모델은 실패 및 성공 궤적 (both failure and success trajectories)을 모두 처리합니다:

실패 미니배치 (Failure minibatches) → 누락되었거나 교정이 필요한 규칙을 제안
성공 미니배치 (Success minibatches) → 이미 잘 작동하며 보존되어야 할 행동을 식별