[논문 리뷰] The Regression Tax — agent skill은 추가할수록 좋아질까

한 줄 요약

LLM agent에 procedural skill을 붙이면 평균 성공률은 올라갈 수 있지만, 그 뒤에는 원래 풀던 작업을 skill 때문에 망치는 regression tax가 숨어 있다. 이 논문의 메시지는 꽤 실용적이다. skill library를 “기능 추가”로만 보면 안 되고, runtime dependency처럼 평가·ablation·rollback해야 한다.

왜 지금 중요한가

요즘 coding agent나 업무 agent를 만들 때 AGENTS.md, skill file, MCP tool description, workflow recipe를 계속 붙인다. 처음에는 당연히 좋아 보인다. 모델이 매번 시행착오하지 않고, 검증된 절차를 재사용하고, 도메인별 명령을 기억하게 만들 수 있으니까.

문제는 skill이 context에 들어가는 순간 agent의 행동 분포가 바뀐다는 점이다. skill은 단순한 참고 문서가 아니다. agent에게는 실행 정책에 가까운 신호다. 그래서 잘못 설계된 skill은 다음 같은 일을 만든다.

• 원래 입력을 잘 해석하던 agent가 skill의 절차에 끼워 맞춘다.
• 원래 하던 검증 단계를 생략한다.
• 호출하지도 않은 skill 설명이 전체 행동을 오염시킨다.
• 평균 점수는 올랐는데 특정 업무군에서는 조용히 성능이 떨어진다.

이건 블로그용 추상론이 아니라 실제 운영 이슈다. 팀이 agent skill을 늘릴수록 “더 똑똑해졌다”와 “더 예측 불가능해졌다”가 동시에 발생할 수 있다.

논문이 보는 평가 방식

논문은 skill이 있는 agent와 없는 agent를 비교해 두 종류의 실패를 분리한다.

• regression: skill 없이 풀던 작업을 skill 추가 후 실패한 경우
• residual failure: skill이 있든 없든 둘 다 실패한 경우

이 구분이 중요하다. 평균 성공률만 보면 어떤 skill set이 좋아 보일 수 있다. 하지만 실제 운영자는 평균보다 regression을 더 싫어한다. 이미 되던 작업이 깨지는 건 신규 작업을 못 푸는 것보다 신뢰를 더 빨리 갉아먹는다.

논문은 5,832개의 task-condition run, 두 개의 office automation benchmark, 세 개의 model-harness stack에 걸쳐 skill 유무를 비교했다. 핵심은 pass-rate 차이를 하나의 평균 숫자로 보지 않고, “skill이 새로 고친 실패”와 “skill 때문에 새로 만든 실패”로 paired decomposition했다는 점이다. 좋은 skill은 단순히 더 많은 gain을 만드는 skill이 아니라 regression을 덜 만드는 skill이었다.

이 관찰은 coding agent 운영에도 그대로 적용된다. 예를 들어 repo에 “테스트는 항상 전체 suite로 돌려라”라는 skill을 넣으면 안전해 보인다. 하지만 작은 문서 수정에서도 무거운 테스트를 반복하다 timeout을 만들거나, 빠르게 확인해야 할 lint failure를 놓칠 수 있다. 반대로 “빠른 smoke test 우선” skill은 배포 경계가 있는 변경에서 과소 검증을 만들 수 있다. 절차는 맥락 없이 항상 선하지 않다.

세 가지 regression mode

논문이 제시한 regression 원인은 세 가지로 정리된다.

1. Skill description osmosis

skill이 실제로 호출되지 않았는데도, description이 context에 있는 것만으로 agent 행동을 바꾸는 현상이다.

이건 LLM agent에서는 자연스럽다. 모델 입장에서 context 안의 skill 설명은 “사용 가능한 문서”이면서 동시에 “이 작업에서 중요해 보이는 prior”다. 그래서 agent가 특정 skill을 명시적으로 선택하지 않아도, 그 skill의 용어·절차·우선순위가 planning에 섞인다.

운영 관점의 결론은 간단하다. skill registry를 무조건 많이 주입하면 안 된다. 지금 작업에 관련 있는 skill만 좁혀서 로드하고, description은 짧고 오해 여지가 적어야 한다. “언제 쓰면 안 되는지”도 description에 넣는 편이 낫다.

2. Grounding displacement

skill의 prescribed procedure가 입력 해석을 덮어버리는 현상이다. agent가 현재 task의 실제 요구사항을 먼저 읽는 대신, skill이 알려준 절차에 문제를 맞춰버린다.

예를 들어 고객지원 agent에 “환불 요청 처리 절차” skill이 있다고 하자. 사용자는 단순히 환불 가능 여부를 묻고 있는데 agent가 곧장 환불 실행 workflow로 들어가면 문제가 된다. coding agent도 마찬가지다. “DB migration 수정 절차” skill이 있다고 해서 모든 schema 관련 diff가 migration 실행을 요구하는 건 아니다.

좋은 skill은 절차보다 grounding checkpoint를 먼저 둬야 한다.

• 현재 입력이 이 skill의 적용 대상인가?
• 사용자가 요청한 것은 정보 제공인가, 실제 mutation인가?
• 필요한 권한과 근거가 있는가?
• skill 적용 전 확인해야 할 task-specific constraint는 무엇인가?

3. Verification displacement

skill 절차가 agent가 원래 수행하던 검증을 밀어내는 현상이다. 절차를 따랐다는 사실이 검증을 대체해버리는 경우다.

이게 제일 위험하다. agent가 “정해진 단계를 완료했다”는 이유로 결과가 맞는지 확인하지 않으면, skill은 reliability layer가 아니라 confidence theater가 된다. 특히 tool-use agent에서는 최종 답변보다 중간 tool result, 파일 diff, 권한 변경, 외부 side effect 검증이 더 중요할 때가 많다.

skill에는 실행 단계만 넣지 말고 verification contract를 같이 넣어야 한다.

• 어떤 artifact를 확인해야 하는가?
• 어떤 command나 test가 통과해야 하는가?
• 실패 시 rollback 또는 escalation 기준은 무엇인가?
• 검증이 불가능하면 agent가 멈춰야 하는가?

실무 설계로 바꾸면

이 논문을 agent harness 설계로 번역하면 네 가지 체크리스트가 나온다.

1. Skill 추가는 feature flag처럼 다룬다

새 skill을 추가할 때 “좋아 보인다”로 끝내면 안 된다. 최소한 다음 비교가 필요하다.

• baseline agent
• skill enabled agent
• skill description만 주입한 agent
• skill 호출은 가능하지만 자동 선택은 막은 agent

이렇게 나눠야 skill 자체의 gain, description osmosis, routing failure를 분리할 수 있다.

2. 평균 성공률 대신 regression budget을 본다

전체 성공률이 3%p 올랐더라도 기존 주요 workflow에서 10% regression이 생기면 운영에서는 실패다. 특히 팀 내부 agent는 long-tail 작업보다 매일 반복되는 핵심 workflow 안정성이 더 중요하다.

추천 metric은 이런 식이다.

• net gain: skill 추가 후 새로 성공한 task 비율
• regression rate: 기존 성공 task 중 실패로 바뀐 비율
• affected task cluster: regression이 몰린 작업군
• recovery rate: verification/grounding 보강 후 회복 가능한 비율

3. Skill 본문은 절차보다 경계를 먼저 쓴다

나쁜 skill은 “1단계, 2단계, 3단계”만 있다. 좋은 skill은 앞부분에 적용 조건과 금지 조건이 있다.

예시는 이렇다.

Use this skill when:
- the task requires editing database migration files
- the user explicitly asks for schema or migration changes
 
Do not use this skill when:
- the user only asks for explanation
- the diff touches model types but not persisted schema
 
Before acting:
- inspect current migration state
- identify whether mutation is required
- confirm rollback path

절차는 그 다음이다. agent에게는 “무엇을 할지”보다 “언제 하지 말아야 할지”가 더 부족하다.

4. Verification을 skill 밖 runtime에도 둔다

skill 내부에 검증 단계를 넣는 것만으로는 부족하다. skill 자체가 verification displacement를 만들 수 있기 때문이다. 중요한 작업은 harness/runtime 레벨에서 별도 gate를 둬야 한다.

• 파일 변경 후 typecheck/build 강제
• DB mutation 전 dry-run 또는 transaction wrapper
• 외부 전송 전 human approval
• MCP tool call 전 policy check
• 결과 요약과 실제 diff/tool trace 비교

skill은 agent의 지식을 늘리는 계층이고, gate는 agent의 행동을 제한하는 계층이다. 둘을 섞으면 안전해 보이지만, 실제로는 둘 다 약해질 수 있다.

내 의견

나는 이 논문의 관점이 꽤 맞다고 본다. agent skill ecosystem은 지금 “더 많이 설치하면 더 잘한다”는 플러그인 마켓식 사고로 가기 쉽다. 하지만 agent에서 skill은 VS Code extension보다 위험하다. extension은 보통 명시적으로 실행되지만, skill은 context에 있는 것만으로 추론을 바꾼다.

그래서 skill library의 핵심은 양이 아니라 hygiene다.

• 오래된 skill을 폐기할 수 있어야 한다.
• skill별 regression report가 있어야 한다.
• skill routing 근거가 trace에 남아야 한다.
• skill description은 짧고, 적용 조건이 선명해야 한다.
• verification은 skill 작성자의 선의에만 맡기면 안 된다.

특히 개인 비서나 coding agent를 오래 운영할수록 이 문제는 커진다. 기억, 선호, skill, repo guidance가 계속 쌓이면 agent는 더 유능해지지만 동시에 더 편향된다. “나를 잘 아는 agent”와 “나를 잘못 확신하는 agent” 사이의 차이는 regression을 측정하느냐에 달려 있다.

한계와 더 확인할 점

논문이 보여주는 방향은 선명하지만, 운영에 적용할 때는 몇 가지를 조심해야 한다.

• 두 office automation benchmark의 작업 분포가 coding agent나 MCP-heavy workflow와 완전히 같지는 않다.
• 세 model-harness stack의 차이가 regression mode에 얼마나 영향을 주는지는 팀별로 다시 봐야 한다.
• skill이 prompt snippet인지, callable procedure인지, tool wrapper인지에 따라 osmosis와 routing failure의 비중이 달라질 수 있다.
• 논문이 말하는 grounding/verification 보강을 실제 runtime gate로 옮기려면 trace schema와 rollback 정책이 필요하다.

그래도 운영 관점의 결론은 충분히 선명하다. agent skill은 평균 점수로만 평가하면 안 된다. gain과 regression을 분해하고, grounding과 verification을 별도 설계해야 한다.

참고 자료

• The Regression Tax: Decomposing Why Skills Help and Hurt LLM Agents — arXiv
• arXiv PDF