AI 에이전트 스킬에는 통과율이 아니라 행동 감사가 필요해요
AI 에이전트 스킬은 평가하기 쉬워 보이다가도, 통과율이 거의 움직이지 않는 순간 이야기가 달라져요.
반사실 실행 기록 감사 연구는 한 벤치마크 설정에서 스킬이 평균 작업 성공률을 +0.3%포인트 높였다고 보고했어요. 그런데 같은 감사에서는 49개 작업에서 스킬이 에이전트 행동을 바꾼 구체적인 방식 522가지를 찾아냈어요.1 통과율 대시보드라면 거의 아무 변화도 없다고 봤을 거예요. 실행 기록 감사는 실제 변화를 봅니다.
AI 에이전트 스킬에는 통과율이 아니라 행동 감사가 필요해요. 스킬은 최종 작업 결과가 달라 보이지 않는 동안에도 에이전트가 어떤 도구를 선택하는지, 어떤 경로를 읽는지, 어떤 증거를 건너뛰는지, 어떤 위험을 무시하는지, 어떤 부작용을 만드는지 바꿀 수 있어요.
핵심 요약
AI 에이전트 스킬은 통과율만으로 신뢰를 얻어서는 안 돼요. 통과율은 벤치마크 채점 기준에서 최종 작업이 성공했는지를 알려줘요. 행동 감사는 스킬이 팀이 의도한 방식으로 에이전트의 행동을 바꿨는지를 묻습니다.
최근 연구는 이 차이를 무시하기 어렵게 만들어요. 반사실 실행 기록 감사는 스킬이 있을 때와 없을 때의 에이전트 실행 기록을 비교해, 일반적인 성공 지표가 놓치는 스킬 유발 패턴을 드러내요.1 행동 무결성 검증은 스킬이 한다고 주장하는 일과 실제로 하는 일을 비교한 뒤, 대규모 스킬 모음에서 설명과 행동이 널리 어긋난다는 점을 보고해요.2 SkillsBench는 엄선된 스킬이 에이전트 성능을 높일 수 있음을 보여주지만, 자체 생성 스킬은 도움이 되지 않을 수 있고 일부 작업은 스킬 때문에 더 나빠질 수 있다는 점도 보여줘요.3
실무 원칙은 이렇습니다. 벤치마크 점수가 올랐다는 이유만으로 스킬을 설치하지 마세요. 실행 기록이 그 행동이 들어와도 된다는 점을 보여준 뒤에 설치하세요.
핵심 포인트
에이전트 스킬을 사용하는 팀에게: - 파일에 Markdown만 들어 있어도 모든 스킬을 행동을 바꾸는 코드로 다루세요. - 프로젝트 전체에 스킬을 공유하기 전에 실행 기록 변화, 부작용, 실패 양상을 감사하세요.
스킬 작성자에게: - 기대 행동, 허용 도구, 금지 행동, 증거 의무를 선언하세요. - 최종 작업 결과만 보지 말고, 짝지은 실행 기록으로 스킬을 테스트하세요.
보안 검토자에게: - 선언된 기능과 관찰된 기능을 비교하세요. - 숨은 범위 확장, 외부 접근, 파괴적 행동, 정책 우회를 스킬 결함으로 표시하세요.
평가 팀에게: - 통과율, 행동 변화량, 부작용 변화량, 검토 부담을 따로 보고하세요. - 통과율이 그대로여도 위험한 행동 변화는 숨어 있을 수 있어요.
왜 통과율은 스킬 위험을 놓칠까요?
통과율은 잘못된 대상을 압축해요.
스킬은 작업이 시작되기 전에 에이전트를 바꿔요. 도메인 절차, 도구 선호, 형식 규칙, 검토 단계, 확신을 표현하는 방식, 복구 행동을 추가할 수 있어요. 벤치마크 채점기는 보통 최종 산출물만 봅니다. 맞았는지, 틀렸는지만 보는 거예요.
그래서 사각지대가 생깁니다.
| 스킬 영향 | 통과율이 보는 것 | 행동 감사가 보는 것 |
|---|---|---|
| 더 나은 도구 순서 | 성공일 수도 있음 | 어떤 호출이 왜 더 앞당겨졌는지. |
| 추가 파일 읽기 | 성공일 수도 있음 | 어떤 파일이 맥락에 들어왔는지. |
| 더 공격적인 패치 | 성공일 수도 있음 | diff 크기, 소유권, 롤백 위험. |
| 검증 생략 | 성공일 수도 있음 | 완료 전에 빠진 증거. |
| 숨은 외부 접근 | 성공일 수도 있음 | 네트워크 또는 MCP 경계 확장. |
| 낮은 검토 부담 | 성공일 수도 있음 | 더 작은 실행 기록, 더 명확한 증명, 더 적은 미해결 주장. |
최종 답은 맞아 보이지만 스킬 때문에 실행을 덜 신뢰하게 될 수 있어요. 반대도 가능합니다. 스킬이 실패한 결과를 내더라도, 더 나은 검색이나 복구 패턴을 가르쳤다면 삭제가 아니라 수리가 필요할 수 있어요.
통과율은 감사 안에 들어가야 해요. 하지만 통과율이 감사 그 자체가 될 수는 없어요.
반사실 실행 기록 감사는 무엇을 더했나요?
반사실 실행 기록 감사는 두 실행을 비교해요. 하나는 스킬이 있는 실행이고, 하나는 스킬이 없는 실행입니다.1
이 논문이 설득력 있는 이유는 보고된 WebArena 설정에서 핵심 통과율 상승폭이 아주 작기 때문이에요. 벤치마크가 스킬을 사용할 때 평균 작업 성공률은 겨우 +0.3%포인트 올라요.1 그런데 저자들은 49개 작업에서 검증 단계, 양식 상호작용, 오류 복구, 페이지 탐색, 오용 패턴 같은 변화까지 포함해 스킬이 유발한 행동 패턴 522가지를 찾아냈어요.1
이 차이가 이 글의 핵심이에요.
전체 작업 성공률이 거의 움직이지 않아도 스킬은 행동에 영향을 줬어요.
CTA는 실행 기록을 단계별로 정렬하고 스킬이 유발한 패턴을 식별하는 방식으로 작동해요. 감사는 작업이 통과했는지만 묻지 않아요. 스킬이 어느 지점에서 경로를 바꿨는지, 그 변화가 도움이 됐는지 해가 됐는지, 어떤 스킬 지시가 원인으로 보이는지를 묻습니다.1
이 방법은 팀에 더 나은 검토 대상을 줘요.
| 감사 질문 | 중요한 이유 |
|---|---|
| 어떤 단계가 바뀌었나요? | 행동을 실행 기록 위치와 연결해요. |
| 어떤 지시가 그 변화를 일으켰나요? | 행동을 스킬 텍스트와 연결해요. |
| 변화가 도움이 됐나요, 해가 됐나요, 아니면 비용만 옮겼나요? | 통과율만 보고 안심하는 평가를 막아요. |
| 변화가 부작용을 만들었나요? | 성공 뒤에 숨은 위험을 잡아내요. |
| 변화가 여러 작업에 일반화되나요? | 운 좋게 맞은 한 번의 실행과 유지할 가치가 있는 스킬을 구분해요. |
팀은 스킬을 로컬 실험에서 공유 절차로 올리기 전에 이런 검토 대상을 확보해야 해요.
행동 무결성 검증은 무엇을 더했나요?
행동 무결성 검증은 다른 질문을 던져요. 스킬이 설명에 적힌 대로 행동하나요?2
BIV 논문은 대규모 스킬 저장소를 연구했고, 분석한 스킬의 80% 이상에서 어떤 형태로든 설명과 행동의 차이가 나타났다고 보고해요.2 저자들은 대부분의 차이를 악의적이라기보다 부주의에서 온 것으로 분류하지만, 악의적 사례와 여러 단계로 이어지는 위험 패턴도 발견해요.2
이 발견이 중요한 이유는 설명이 활성화를 좌우하기 때문이에요.
에이전트 시스템에서는 스킬 설명이 그 스킬을 맥락에 넣을지 결정하는 경우가 많아요. 설명은 에이전트가 언제 스킬을 불러와야 하는지 말해요. 설명이 기능을 축소해서 말하거나, 부작용을 숨기거나, 도구 접근을 언급하지 않으면 에이전트와 사용자 모두 작업별 추론이 시작되기 전에 잘못된 경로 선택을 하게 됩니다.
BIV는 스킬에 빠져 있는 명세 계층을 가리켜요.
| 선언된 표면 | 행동 감사가 확인해야 하는 것 |
|---|---|
| 활성화 조건 | 스킬이 명시된 작업 범주에서만 실행되나요? |
| 기능 | 관찰된 행동이 주장 범위 안에 머무르나요? |
| 도구 사용 | 스킬이 어떤 도구, 명령, MCP 서버, 파일을 유발하나요? |
| 부작용 | 스킬이 읽기, 쓰기, 삭제, 전송, 지출, 게시, 배포를 하나요? |
| 외부 접근 | 스킬이 네트워크, 브라우저, 제3자 이동을 만들나요? |
| 안전 주장 | 스킬이 약속한 점검을 실제로 추가하나요? |
| 거부 경계 | 스킬이 차단된 행동을 계속 차단하나요? |
무서운 버전은 거짓말하는 악성 스킬이에요. 흔한 버전은 진실을 제대로 말하지 않는 허술한 스킬입니다.
두 경우 모두 감사가 필요해요.
SkillsBench는 무엇을 더했나요?
SkillsBench는 팀이 과하게 반응해서 스킬은 쓸모없다고 결론 내리면 안 되는 이유를 보여줘요.
이 벤치마크는 86개 작업과 7,308개 실행 경로에서 에이전트 스킬을 평가해요.3 논문은 엄선된 스킬이 스킬 없는 기준선보다 평균 통과율을 16.2%포인트 높였다고 보고하지만, 자체 생성 스킬은 평균적으로 이득을 주지 못했다고 말해요.3 또 일부 작업에서는 음의 변화량도 보고해요. 즉 스킬이 특정 작업을 더 나쁘게 만들 수 있다는 뜻이에요.3
이 결과가 균형 잡힌 관점을 줍니다.
스킬은 도움이 될 수 있어요. 스킬 품질도 중요해요. 작업 적합성도 중요해요. 출처도 중요해요. 평가 방법도 중요해요.
도입 교훈은 “스킬을 피하라”가 아니에요. 도입 교훈은 “스킬을 기능 패키지처럼 검토하라”입니다.
쓸모 있는 스킬은 다음 질문에 답해야 해요.
| 질문 | 필요한 답 |
|---|---|
| 스킬이 어떤 일을 개선하나요? | 구체적인 작업 범주와 독자/사용자. |
| 어떤 행동이 바뀌어야 하나요? | 도구 선택, 증거 점검, 형식, 검토, 복구 패턴. |
| 어떤 행동은 바뀌면 안 되나요? | 금지 도구, 경로, 부작용, 권한 경계. |
| 스킬이 도움이 됐다는 증거는 무엇인가요? | 실행 기록 변화량, 통과율, 검토 노력, 부작용 프로필. |
| 팀은 스킬을 어떻게 제거할 수 있나요? | 버전, 소유자, 롤백, 대체 경로. |
관찰된 행동이 이 답들과 일치할 때만 스킬은 승격될 수 있어요.
행동 감사는 어떤 모습이어야 하나요?
행동 감사는 기대한 스킬 행동과 관찰된 에이전트 행동을 비교해요.
최소 감사는 4번의 검토로 구성됩니다.
| 감사 단계 | 증거 |
|---|---|
| 선언 감사 | 스킬 설명, 활성화 조건, 기능, 도구, 금지 행동. |
| 반사실 실행 기록 감사 | 같은 작업 집합에서 스킬이 있을 때와 없을 때의 짝지은 실행. |
| 부작용 감사 | 파일, 명령, 네트워크 호출, 외부 쓰기, 승인, 롤백 상태. |
| 실패 감사 | 실패한 실행, 아슬아슬한 실패, 복구된 오류, 반복되는 수리 패턴. |
출력물은 순위표보다는 검토 패킷에 가까워야 해요.
각 작업마다 다음을 기록하세요.
- 작업 이름과 위험 구간.
- 스킬 버전과 출처.
- 기준 실행 기록.
- 스킬 실행 기록.
- 바뀐 단계.
- 바뀐 도구 호출.
- 바뀐 부작용.
- 얻거나 잃은 증거.
- 최종 결과.
- 검토자 결정: 유지, 수정, 범위 제한, 차단, 폐기.
이 패킷은 사람 검토자가 한 번의 벤치마크 실행을 넘어 유지될 수 있는 판단을 내리게 해줘요.
스킬 계약은 어디에 맞을까요?
ContractSkill은 더 엄격한 행동이 필요한 스킬에 더 깔끔한 형태를 제시해요.4
이 논문은 자연어로 작성된 웹 에이전트 스킬이 모호하고, 쉽게 깨지고, 디버깅하기 어렵다고 주장해요. 그래서 명시적인 작업 정의, 전제 조건, 사후 조건, 단계별 절차를 갖춘 계약 기반 스킬을 제안합니다. 이렇게 하면 시스템은 전체 스킬을 다시 쓰는 대신 실패를 특정 위치로 좁히고 영향을 받은 부분만 수리할 수 있어요.4
이 계약 관점은 행동 감사와 잘 맞아요.
| 자유 형식 스킬 | 계약 형태 스킬 |
|---|---|
| “게시할 때 주의하세요.” | “게시 전에 출처 URL, 경로 렌더링, 스키마, 롤백을 검증하세요.” |
| “페이지를 확인하세요.” | “경로를 가져오고, 상태 200을 확인하고, 변경 표식을 확인하고, 대체 문구가 없는지 확인하세요.” |
| “위험한 명령을 피하세요.” | “삭제, 강제 푸시, 외부 POST, 소유 경로 밖 쓰기를 차단하세요.” |
| “자연스럽게 번역하세요.” | “URL과 인용을 보존하고, 보이는 제목을 번역하고, 영어 잔여 표현을 기준으로 걸러내세요.” |
계약 형태의 스킬은 모호함을 줄여요. 기대 행동이 검토자가 실행 기록과 비교할 수 있는 구조 안에 있으므로 감사 비용도 낮춰요.
계약이 모든 스킬을 거대하게 만들어서는 안 돼요. 위험이 낮은 글쓰기 형식이나 체크리스트 작업에는 평범한 스킬도 여전히 작동합니다. 계약이 중요해지는 때는 스킬이 외부 시스템, 공개 콘텐츠, 데이터, 돈, 보안 태세, 공유 프로젝트 행동을 바꿀 수 있을 때예요.
나쁜 스킬은 어떻게 수리하나요?
한 번의 실행이 실패했다고 유용한 스킬을 삭제하지 마세요. 먼저 행동이 어디서 깨졌는지 찾아야 해요.
AgentRx는 실행 경로에서 핵심 실패 단계를 찾고, 제약을 생성하고, 감사 가능한 로그를 기준으로 수리를 검증하는 방식으로 에이전트 실패 수리에 집중해요.5 이 논문은 스킬 파일 자체가 아니라 에이전트 행동 전반을 다루지만, 수리의 형태는 스킬에도 잘 들어맞아요. 실패 단계를 찾고, 제약을 도출하고, 수리된 행동을 테스트하고, 증거를 보존하는 흐름입니다.
스킬 수리는 같은 순서를 따라야 해요.
| 실패 | 수리 |
|---|---|
| 스킬이 너무 넓게 활성화됨 | 설명과 트리거 예시를 좁히세요. |
| 스킬이 잘못된 도구 선택을 바꿈 | 도구 선택 규칙과 반례를 추가하세요. |
| 스킬이 검증을 건너뜀 | 완료 전에 멈추는 조건을 추가하세요. |
| 스킬이 diff를 너무 많이 만듦 | 소유권과 변경 경로 제한을 추가하세요. |
| 스킬이 네트워크 이동을 일으킴 | 외부 송신 규칙과 승인 요구사항을 추가하세요. |
| 스킬이 한 작업은 개선하지만 다른 작업을 해침 | 스킬을 나누거나 성공한 작업 범주로 범위를 제한하세요. |
수리는 자신감 있는 커밋 메시지가 아니라 새 감사로 끝나야 해요.
수리 후에도 실행 기록이 여전히 잘못된 행동을 보여준다면 스킬을 폐기하세요.
최소 기준
팀이 AI 에이전트 스킬을 공유하기 전에 행동 감사 패킷 1개를 요구하세요.
| 필드 | 필요한 증거 |
|---|---|
| 출처 | 저장소, 작성자, 버전, 설치 경로. |
| 목적 | 스킬이 개선한다고 주장하는 작업 범주. |
| 활성화 | 스킬을 불러와야 하는 정확한 조건. |
| 허용 행동 | 스킬이 영향을 줄 수 있는 도구, 파일, 리소스, 행동. |
| 금지 행동 | 스킬이 확장해서는 안 되는 도구, 경로, 부작용, 권한. |
| 반사실 실행 기록 | 같은 작업에서 스킬이 있을 때와 없을 때의 실행 기록. |
| 결과 변화량 | 통과율, 실패율, 검토 노력, 실행 비용. |
| 행동 변화량 | 바뀐 단계, 도구 호출, 부작용, 증거. |
| 위험 결정 | 유지, 수정, 범위 제한, 차단, 폐기. |
| 롤백 | 팀이 스킬을 제거하고 이전 행동으로 돌아가는 방법. |
이 패킷은 올바른 질문을 강제해요.
질문은 “스킬이 한 번 도움이 됐나요?”가 아니에요. 질문은 “스킬이 팀이 원하는 방식으로 행동을 안정적으로 바꾸나요?”입니다.
가치 있는 기준
스킬은 에이전트가 빠르게 더 나아진 것처럼 느끼게 해요. 그 속도 때문에 팀은 절차 파일, 명령, 에이전트, 훅, 프롬프트를 쌓아가고 싶어져요. 하나하나가 싸 보이기 때문입니다.
값싼 맥락도 행동을 바꿔요.
가치 있는 스킬은 전체 작업 흐름을 개선함으로써 자기 자리를 얻어요. 검토 부담을 줄이거나, 증거를 더 선명하게 만들거나, 위험을 좁히거나, 에이전트가 없이는 안정적으로 수행하지 못하던 절차를 가르쳐야 해요. 에이전트가 더 자신 있게 말하게만 만드는 스킬은 사라져야 합니다. 통과율을 높이면서 숨은 부작용을 넓히는 스킬은 검토를 통과하면 안 돼요.
기준은 단순해야 해요.
- 스킬이 무엇을 바꿔야 하는지 선언하세요.
- 실행 기록이 그 방식으로 바뀌었음을 증명하세요.
- 무엇이 바뀌면 안 되는지 이름 붙이세요.
- 실행 기록이 그 경계를 지켰음을 증명하세요.
- 그 행동이 존재할 가치가 있을 때만 스킬을 유지하세요.
AI 에이전트 스킬은 마법의 메모가 아니에요. 행동 패치입니다. 코드처럼 다루세요.
빠른 정리
AI 에이전트 스킬에는 행동 감사가 필요해요. 통과율이 너무 많은 것을 숨기기 때문입니다. 반사실 실행 기록 감사는 전체 성공률이 거의 움직이지 않아도 스킬이 수백 개의 실행 기록 패턴을 바꿀 수 있음을 보여줘요.1 행동 무결성 검증은 스킬 설명이 실제 기능과 자주 어긋난다는 점을 보여줘요.2 SkillsBench는 엄선된 스킬이 도움이 될 수 있지만, 자체 생성 스킬과 작업 불일치는 실패하거나 해를 끼칠 수 있음을 보여줘요.3
운영 원칙은 분명해요. 점수만 보지 말고 행동을 평가하세요. 스킬은 선언, 실행 기록, 부작용, 실패, 수리, 롤백 경로가 모두 맞아떨어질 때 신뢰받을 자격이 있어요.
FAQ
AI 에이전트 스킬의 행동 감사란 무엇인가요?
행동 감사는 스킬이 에이전트의 실제 실행을 어떻게 바꾸는지 확인해요. 도구 호출, 파일 접근, 부작용, 검증 단계, 복구 행동, 최종 결과를 봅니다. 그리고 관찰된 행동을 스킬의 선언된 목적과 경계와 비교해요.
스킬 평가에 통과율만으로는 왜 부족한가요?
통과율은 채점 기준에서 작업이 성공했는지를 보여줘요. 하지만 스킬이 도구 접근을 넓혔는지, 증거를 건너뛰었는지, 부작용을 늘렸는지, 팀이 의도하지 않은 방식으로 행동을 바꿨는지는 보여주지 못해요.
반사실 실행 기록 감사란 무엇인가요?
반사실 실행 기록 감사는 스킬이 있을 때와 없을 때의 에이전트 실행 경로를 비교하고, 실행 기록 단계를 정렬하며, 스킬이 유발한 행동 패턴을 식별해요. 팀이 전체 성공 지표로는 놓칠 수 있는 행동 변화를 볼 수 있게 해줍니다.1
행동 무결성 검증이란 무엇인가요?
행동 무결성 검증은 스킬 설명과 실제 스킬 행동을 비교해요. 스킬의 명시된 기능, 활성화 조건, 안전 주장이 관찰된 행동과 맞지 않을 때 이를 탐지합니다.2
팀은 스킬을 공유하기 전에 무엇을 감사해야 하나요?
팀은 스킬 출처, 활성화 조건, 선언된 기능, 허용 행동과 금지 행동, 짝지은 실행 기록, 부작용, 실패 사례, 수리 경로, 롤백 계획을 감사해야 해요.
참고 문헌
-
Xuanyu Zhang, Yiding Liu, Chengsong Huang, Ensheng Shi, Weizhi Ma, Yifei Zhang, Qun Liu, Shumin Deng, Jiahang Shen, and Shiqi Wang, “Counterfactual Trace Auditing of LLM Agent Skills,” arXiv:2605.11946v1, submitted May 13, 2026. 짝지은 실행 기록 비교, 스킬 유발 패턴 탐지, 단계 정렬, WebArena 스킬 평가, 전체 통과율 +0.3%포인트 상승, 49개 작업의 행동 패턴 522가지에 대한 출처. ↩↩↩↩↩↩↩↩
-
Ning Liu, Meng Fang, Youtao Zhang, Dominik T. Matt, Stanislav Pletnev, Hongzhi Wang, and Erwin Schoitsch, “Behavioral Integrity Verification for Agentic AI Skills,” arXiv:2605.11770v1, submitted May 13, 2026. 선언된 스킬 기능과 실제 기능의 검증, 저장소 규모 스킬 분석, 설명과 행동의 차이 발견, 부주의 및 악의적 차이 범주, 여러 단계 위험 패턴에 대한 출처. ↩↩↩↩↩↩
-
Lingkai Kong, Xiangliang Zhang, and Jiamou Liu, “SkillsBench: Can LLMs Learn from Their Own and Other Agents’ Skills for Reliable Task Execution?,” arXiv:2602.12670v1, submitted February 17, 2026. 86개 작업, 7,308개 실행 경로로 구성된 SkillsBench 평가, 엄선된 스킬의 통과율 개선, 자체 생성 스킬 결과, 작업별 음의 변화량에 대한 출처. ↩↩↩↩↩
-
Meiyi Ma, Fengan Xia, Canran Xu, Wenqi Li, Aranya Roy, Zhaopeng Tu, Ranveer Chandra, and Dongmei Zhang, “ContractSkill: Contract-based Skill Design for LLM-powered Web Agents,” arXiv:2603.20340v1, submitted March 25, 2026. 계약 기반 스킬 정의, 전제 조건, 사후 조건, 단계별 절차, 결정론적 검증, 오류 위치 특정, 최소 로컬 수리에 대한 출처. ↩↩
-
Cunxiang Wang, Ruoxi Sun, Yidong Wang, Piji Li, and Yue Zhang, “AgentRx: Scalable Automated Failure Diagnosis and Repair for LLM Agents,” arXiv:2602.02475v1, submitted February 3, 2026. LLM 에이전트 실패의 핵심 단계 위치 특정, 제약 생성, 실행 기록 검증, 감사 가능한 수리 로그에 대한 출처. ↩