출발점 — 스킬이 해로울 수 있다
Agent Skills Can Be Harmful: An Empirical Study of Skill-Induced Failures (8월 12일)
재사용 가능한 스킬이나 지침을 추가하면 항상 좋아지는지 검증했다.
SkillsBench와 SWE-Skills-Bench에서 스킬 때문에 발생한 실패 307건을 찾아냈다.
- 125건 — 기능 실패
- 182건 — 비용·시간 악화
특히 문제가 된 것은 엉뚱한 스킬이 아니라 겉보기에 관련 있어 보이는 스킬이었다. 과도한 검증, 지나치게 무거운 구현 절차가 오히려 성능을 떨어뜨렸다.
Skills, MCP 지침, 플레이북을 계속 붙이면 강해질 것 같지만 실제로는 지침이 많아질수록 행동이 경직되고 실패할 수 있다.
그렇다면 어느 문장이 문제인가
SkillShapley (8월 13일)는 다음 질문으로 넘어간다. 스킬을 덩어리로 평가하지 않고, 스킬 안의 각 지시 단계가 성공에 얼마나 기여했는지 Shapley value로 계산한다. 성능에 중요한 단계와 거의 도움이 안 되는 단계를 식별할 수 있음을 보였다.
스킬을 통째로 추가·제거하는 게 아니라 단계별로 측정 → 제거 → 개선할 수 있게 된다.
언제 꺼내 쓸 것인가
SkillGate: Training In-Policy Skill Selection (8월 19일)은 수천 개 스킬 중 어떤 스킬을 읽을지 선택하는 행위 자체를 RL로 학습시킨다.
기존 방식은 긴 실행에서 스킬 선택 토큰에 보상이 거의 전달되지 않는
selector credit starvation 문제가 있다고 분석하고, 선택과 실행에 별도 보상 경로를 뒀다.
16개 후보 스킬 조건에서 9B 모델의 성공률을 40.8% → 53.2%로 높였다.
AUSO: Action-Level Unified Skill Optimization (8월 21일)은 전 과정을 하나로 묶는다. 처음에는 교사처럼 배우고, 모델이 성장하면 내부 능력으로 흡수하고, 마지막에는 각 행동마다 그 스킬이 실제 도움이 될 때만 사용한다. 같은 실행 안에서도 도움이 된 행동은 강화하고 방해가 된 행동은 억제한다.
한 달 흐름이 이렇게 이어진다.
스킬이 해로울 수 있다 → 어느 문장이 문제인가 → 언제 고를 것인가 → 언제 배우고 언제 꺼낼 것인가
도구를 호출했다고 쓴 것은 아니다
The Illusion of Visual Tool-Use: A Causal Audit of Thinking with Images (8월 6일)는 이미지 확대·크롭 같은 도구를 쓰는 모델이 정말 그 결과를 활용하는지 인과적으로 검사했다. 도구를 호출했지만 반환된 이미지가 최종 답에 사실상 영향을 주지 않는 Calling Without Looking 현상이 발견됐다.
"도구를 많이 호출하니 더 에이전트답다"는 평가에 제동을 건다. 호출 횟수가 아니라 그 결과가 실제 판단을 바꿨는지를 봐야 한다.
도구가 망가졌을 때
Retry, Switch, or Abstain? Learning Strategy-Aware Tool-Use Policies (8월 12일)
현실에서 API는 일시적으로 실패하거나, 계속 고장 나거나, 조용히 잘못된 값을 돌려준다.
기존 벤치마크는 이런 상황을 거의 다루지 않는다.
BENCH2ROBUST는 실패를 인위적으로 주입해 재시도할지, 도구를 바꿀지, 포기할지 판단하게 만든다.
Bayesian Tool Memory만 추가해도 일부 과제에서 견고성이 최대 16.8%p 올랐다.
실제 업무에서 중요한 능력은 "도구를 쓸 줄 안다"가 아니라 도구가 망가졌을 때 어떻게 복구하느냐다.
자유를 줄이는 게 나을 때도 있다
OpenCodeReview: Determinism over Non-Determinism (8월 10일)은 코딩 에이전트에게 모든 탐색 자유를 주는 대신 파일 선택·도구 사용·검증 일부를 의도적으로 결정론적으로 만들었다.
200개 실제 PR로 구성된 벤치마크에서 기존 방식보다 최대 2.17배 높은 점수를 내면서 토큰은 5~15배 줄였다.
Routing Is Least Learnable Where It Is Most Valuable (8월 6일)도 같은 결이다. 웹 에이전트가 텍스트·화면 이미지·결합 중 어떤 표현을 쓸지 자동 선택하면 좋아질 것이라는 가정을 검증했더니, 현재 수준에서는 하나의 좋은 방식을 고정하는 편이 대부분 더 안정적이었다. 같은 조건을 다시 실행하는 것만으로 결과가 12~14% 달라질 만큼 변동성이 컸다.
플레이북은 옮겨 쓰기 어렵다
When Do Prompt-Side Agent Playbooks Transfer? (8월 6일)는 한 환경에서 만든 지침을 다른 작업에 그대로 가져갔을 때를 시험했다. 도움이 된 경우도 있었지만 환경이 바뀌면 반복 검색, 종료 지연, 비용 폭증이 나타났다.
"좋은 프롬프트를 한번 만들어두면 어디서나 재사용 가능하다"는 생각이 위험할 수 있다.
지시는 한 군데에만 있지 않다
Harness-IF: Evaluating Instruction Following Across Instruction Surfaces (8월 12일)는 시스템 프롬프트, 프로젝트 지침 파일, 사용자 지시, 도구 설명, 스킬 설명 등 서로 다른 위치의 규칙을 얼마나 지키는지 측정했다.
12개 최신 모델의 일반 정확도는 72.185.9%였지만,
**모델의 기본 행동과 반대되는 지시는 66.178.6%**로 떨어졌다.
"에이전트가 프로젝트 규칙을 읽었다"와 "그 규칙 때문에 행동을 바꿨다"는 다르다.
검색을 언제 멈출 것인가
- HALT (8월 3일) — 모델의 자신감이 아니라 주장마다 증거가 확보됐는지 확인한 뒤 멈춘다
- CAS (8월 21일) — Conformal Prediction으로 질문마다 필요한 검색 결과 수를 정하고, 확신이 낮은 실행에는 학습 시 페널티를 준다
- CodeGrep (8월 6일) — 코딩 에이전트가 "어디를 고칠지 찾는" 데 쓰는 토큰을 분리해 전문 에이전트에게 맡긴다. 해결률 유지하면서 토큰 19% 절감
셋 다 방향이 같다. 증거가 충분하면 멈추고, 불확실하면 더 찾는다.
그래서 무엇을 다르게 할 것인가
1. 지침 파일을 늘리기 전에 지운다
프로젝트 지침이 길어질수록 지켜지는 비율은 오히려 떨어진다. 관련 있어 보이지만 이 작업에는 불필요한 절차가 가장 해롭다.
2. 규칙은 모델 기본 행동과 싸우지 않게 쓴다
기본 습관과 반대되는 지시는 준수율이 눈에 띄게 낮다. 꼭 필요하면 짧고 분명하게, 여러 군데 흩어 놓지 말고 한 곳에 쓴다.
3. 도구를 붙일 때 실패 경로를 같이 정한다
이 API가 죽으면 어떻게 할 것인가. 재시도인가, 다른 방법인가, 사람에게 넘기는가. 이걸 안 정해두면 에이전트가 알아서 이상한 선택을 한다.
4. 잘 되던 프롬프트를 다른 업무에 그대로 옮기지 않는다
옮기고 나면 결과를 다시 확인한다. 같은 지침이 다른 환경에서 비용만 늘리는 경우가 흔했다.