핵심 요약

Sentient Labs의 Darshan Tank와 Baran Nama는 “The Regression Tax: Decomposing Why Skills Help — and Hurt — LLM Agents”(arXiv:2607.22520)에서 LLM 에이전트 스킬의 양면성을 해부했다. 스킬 라이브러리를 추가하면 평균 패스율은 오르지만, 이미 풀리던 작업을 망가뜨리는 회귀(regression)가 전체 이득의 59%를 상쇄한다.

5,832개의 task-condition 실행, 3개의 모델–하네스 스택(OpenCode·MiniMax-M2.7, Codex·GPT-5.4-mini, Claude Code·Sonnet 4.6), 2개의 오피스 자동화 벤치마크(OfficeQA-Pro, SpreadsheetBench)를 통해 세 가지 회귀 메커니즘을 정확히 분리해 냈다.

Figure 1: 에이전트 작업의 세 단계 — 그라운딩(입력 읽기), 메서드(절차), 검증(출력 확인). 기존 스킬은 주로 메서드 단계를 지원하지만, 회귀와 잔존 실패는 그라운딩과 검증에서 집중된다.

스킬이 회귀를 일으키는 세 가지 방식

1. 스킬 설명 삼투 (Skill-Description Osmosis)

가장 놀라운 발견. 스킬 본문이 한 번도 실행되지 않았는데도, 시스템 프롬프트에 스킬의 이름과 설명이 존재하는 것만으로 에이전트의 행동이 바뀐다.

예시: UID0096 작업(관세율 이동평균 계산)에서 Sonnet 4.6은 스킬 없이 정답 37.708%를 냈다. 스킬 라이브러리를 추가하자 — 스킬이 단 한 번도 호출되지 않았는데 — 세 라이브러리 모두 동일하게 38.757%라는 잘못된 값을 냈다. 스킬 설명에 포함된 “revised”와 “customs”라는 단어가 에이전트의 입력 해석을 바꿔버린 것이다.

SpreadsheetBench에서도 마찬가지. “마지막 날의 번호를 추출하라”는 지시에 대해, 스킬 없이는 10(일자)을 정확히 반환했지만, 스킬 설명이 컨텍스트에 있자 Excel 일련번호 45301을 반환했다. 스킬 본문은 단 한 줄도 읽히지 않았다.

이 채널은 호출 기반 선택 메서드(retrieval, masking)로는 절대 감지할 수 없다. 설명이 항상 컨텍스트에 남아있기 때문이다.

2. 그라운딩 전위 (Grounding Displacement)

스킬 본문이 실행되면, 스킬이 제시하는 절차가 에이전트가 올바르게 읽고 있던 입력을 덮어쓴다.

OfficeQA-Pro 회귀 81건 중 59건(72.8%)이 그라운딩 전위였다. UID0025 작업(1934년과 1946년 공공지출 차이)에서 베이스라인은 정확히 549와 407을 읽어 정답 142를 냈다. 하지만 스킬을 추가하자 네비게이션 스킬이 잘못된 수치(949)로 에이전트를 유도해 542라는 틀린 값을 반환했다. 산술은 맞았지만, 입력이 스킬에 의해 전위된 것이다.

3. 검증 전위 (Verification Displacement)

스킬이 에이전트가 원래 수행하던 출력 검증을 억제하거나 대체한다.

UID0086 작업(절대 백분율 변화)에서 스킬 없이는 +4.815를 정확히 반환했다. 스킬을 추가하자 부호가 바뀐 -4.816을 반환했다. 크기는 정확했지만 “절댓값”이라는 요구사항에 대한 검증이 스킬 절차에 의해 생략된 것이다.

SpreadsheetBench에서 이 효과는 더 결정적이다. 663개의 실패한 formula 작업 중 226개(34%)가 이미 정답이었지만 value-only 채점기가 평가하지 못한 것이었다. 실행 기반 재채점으로 GPT-5.4-mini의 패스율이 67%대에서 78%대로 뛰었다.

왜 이것이 중요한가

평균의 함정

기존 스킬 평가는 “스킬 추가 전후의 평균 성공률 변화”만 본다. 하지만 같은 +5% 개선이라도:

  • 라이브러리 A: 새로 10개 작업을 풀고, 0개를 망가뜨림 → 순수 이득
  • 라이브러리 B: 새로 15개 작업을 풀고, 10개를 망가뜨림 → 위험한 거래

이 논문의 데이터에서 후자가 훨씬 흔하다. Sonnet 4.6의 OfficeQA-Pro에서 Anthropic 라이브러리는 가장 적은 이득(10개)을 냈지만 가장 적은 회귀(2개)로 **가장 큰 순효과(+8)**를 기록했다. 반면 더 많은 작업을 푼 다른 라이브러리들은 더 많이 망가뜨렸다.

그라운딩과 검증이 병목, 메서드가 아니다

Figure 1이 보여주듯, 에이전트 파이프라인은 입력(그라운딩) → 처리(메서드) → 출력(검증)으로 이어진다. 기존 스킬은 압도적으로 메서드 단계를 지원하지만, 실제 실패는 양 끝단에 집중된다.

잔존 실패(스킬이 있든 없든 실패하는 작업)를 분석하면:

  • OfficeQA-Pro: 24개 중 거의 모든 실패가 입력 단계 — 잘못된 표, 잘못된 연도, 잘못된 정의를 읽은 것이다. 산술은 정확히 수행됐다.
  • SpreadsheetBench: 663개 formula 실패 중 226개가 이미 정답. 검증(실행 기반 체크)만 있었으면 통과했을 작업들이다.

메서드(절차)는 스킬이 가장 잘 지원하는 단계이면서, 동시에 가장 적게 실패하는 단계다. 이것이 스킬의 효과가 제한되는 근본 원인이다.

실험 설계의 정교함

3개 스택, 4개 조건, 5,832회 실행

각 스택(OpenCode·MiniMax-M2.7, Codex·GPT-5.4-mini, Claude Code·Sonnet 4.6)마다 4개 조건(스킬 없음, Anthropic 생성 스킬, OpenAI 생성 스킬, 연구진 자체 스킬)을 비교했다. 스킬 라이브러리 크기는 3개부터 23개까지 다양했다.

스킬 생성 파이프라인

모든 스킬은 동일한 4단계로 만들어졌다: (1) 베이스라인 실행 → (2) 궤적 분석으로 실패 신호 추출 → (3) 메타 스킬 크리에이터로 스킬 생성 → (4) 스킬을 넣고 재평가. 세 크리에이터(Anthropic의 측정 기반 루프, OpenAI의 단일 패스, 연구진의 셀프비평+재사용)는 같은 신호에서 출발하지만 전혀 다른 라이브러리를 만들어낸다.

통계적 엄격함

18개 동시 비교에 Bonferroni 보정(α/18=0.0028)을 적용했다. 보정 후 살아남은 유의미한 효과는 Claude Code·Sonnet 4.6의 SpreadsheetBench 3건뿐(p<.001). 대부분의 겉보기 개선은 노이즈와 구분되지 않는다.

실질적 시사점

1. 스킬 평가는 이득과 회귀를 분리해서 보고해야 한다. 평균 패스율만 보면 두 라이브러리가 같아 보여도, 회귀 패턴은 완전히 다를 수 있다.

2. 설명-전용 조건을 별도로 테스트해야 한다. 스킬 본문 없이 설명만 컨텍스트에 넣은 조건을 포함해야 삼투 효과를 측정할 수 있다. retrieval mask나 invocation 기반 방법으로는 절대 잡을 수 없다.

3. 스킬은 절차보다 그라운딩 정보와 검증 로직을 담아야 한다. 절차는 이미 에이전트가 잘하는 단계다. “어떤 표를 읽어야 하는지”, “출력을 어떻게 검증해야 하는지”가 훨씬 더 가치 있다.

4. 실행 가능한 출력 검증을 스킬에 포함시켜라. SpreadsheetBench의 226개 회복 가능한 실패가 보여주듯, 구체적인 체크 하나가 퍼센트 포인트 단위의 회복을 가져온다.

더 실습해보고 싶은 분들께

에이전트 스킬 설계와 하네스 엔지니어링은 단순히 “도구를 많이 넣는 것”이 아니다. 이 논문이 보여주듯, 컨텍스트에 무엇을 넣느냐가 에이전트의 인지 경로 자체를 바꾼다. 이 영역을 더 깊이 실습하고 싶다면:

결론

스킬은 무조건 좋은 것이 아니다. 이 논문은 5,832회의 실험을 통해 스킬의 부작용을 정량화하고, 세 가지 메커니즘으로 분해하고, 설계 원칙을 도출했다. 핵심 통찰은 단순하다: 신뢰성은 절차의 정교함이 아니라, 입력을 정확히 읽고(그라운딩) 출력을 검증할 수 있는 능력에 달려 있다. 스킬 설계도 같은 원칙을 따라야 한다.


Paper: “The Regression Tax: Decomposing Why Skills Help — and Hurt — LLM Agents”, Darshan Tank & Baran Nama, Sentient Labs, arXiv:2607.22520, July 2026.