AI 에이전트 스킬 평가(eval) 만들기: 구글 딥마인드가 말하는 스킬 검증 실전 가이드

핵심 메시지

• 대부분의 팀이 스킬을 쓰지만 평가(eval)를 두지 않는다 — 에이전트는 비결정적이라 실패가 스킬 탓인지 과제 난도 탓인지 구분하려면 평가가 필수다.
• 스킬은 progressive disclosure(제목·설명 → 본문 → 참조 파일) 구조이며, 모델이 스스로 능력을 키우면 버리는 능력형 스킬과 팀 규칙을 담아 오래 유지하는 선호형 스킬로 나뉜다.
• 내가 쓰는 에이전트와 내가 만들어 고객에게 주는 에이전트는 다르다 — 고객은 스킬이 무엇인지 모르므로 설명(description)만으로 자동 호출돼야 한다.
• 좋은 스킬 작성 팁: 왜·언제·어떻게를 담은 강한 설명, 에세이가 아닌 지시문, 정보 계층화, 고정 워크플로는 스크립트로, 부정 사례와 no-op 제거, 조기 테스트.
• 구글 딥마인드는 모든 스킬 옆에 평가를 두고 변경마다 회귀 테스트를 돌려, 평가를 개선하지 못하는 스킬 변경은 병합하지 않는다.

쉽게 이해하기

구글 딥마인드에서 Gemini API와 에이전트를 담당하는 필립 슈미트는 AI Engineer 발표에서 "평가 없이 스킬을 배포하지 말라"는 한 문장을 강조했다. 청중 대부분이 코딩 에이전트와 스킬을 쓰지만 그에 대한 평가를 가진 사람은 거의 없었고, 공개 벤치마크 SkillBench가 색인한 5만여 개 스킬 중 평가를 갖춘 것은 드물었다. 에이전트는 비결정적이라 과제가 실패해도 스킬이 나쁜 탓인지, 과제가 모델에게 너무 어려운 탓인지 평가 없이는 알 수 없다는 것이 출발점이다.

그는 "내가 쓰는 에이전트"와 "내가 만들어 고객에게 주는 에이전트"를 구분한다. 전자는 개발자가 스킬 맥락을 알기에 자동 호출이 안 되면 바로 알아채 다시 지시하거나 슬래시 명령으로 부를 수 있다. 반면 고객용 에이전트의 사용자는 스킬이 무엇인지 모르므로 "환불 스킬을 써서"처럼 프롬프트를 쓰지 않는다. 따라서 모델이 설명만 보고 스스로 스킬을 호출해야 하며, 이 지점이 평가가 특히 중요한 영역이다.

스킬은 skill.md 파일과 부속 자산이 담긴 폴더로, 점진적 공개(progressive disclosure) 원리로 작동한다. 항상 맥락에 올라가는 제목·설명이 첫 층, 더 자세한 본문이 둘째 층, 깊은 세부는 참조 파일에 두는 셋째 층이다. 슈미트는 스킬을 두 종류로 본다. 로그 추적처럼 모델이 아직 일관되게 못 하는 일을 가르치는 능력형 스킬은 모델이 좋아지면 은퇴시킬 수 있는 임시 자산이고, 팀 고유 워크플로·스타일을 담은 선호형 스킬은 오래 유지되며 평가로 보호해야 한다.

실전 예로 그는 Gemini Interactions API 스킬을 들었다. 이 API는 모델 학습 이후 공개돼 모델이 알지 못했기에, 실제 사용자 데이터·합성 사례·피드백으로 117개 테스트 케이스를 만들었다. 자산은 프롬프트·언어·트리거 여부·기대 검증을 담은 JSON 테스트 파일과 코딩 에이전트(Gemini CLI)를 돌려 결과를 확인하는 간단한 파이썬 스크립트뿐이었다. 올바른 SDK·모델·메서드를 썼는지 정도는 값싼 정규식(regex) 검증으로 충분했고, 그 결과 최신 모델로 유효한 코드를 생성하는 비율을 약 90%까지 끌어올렸다.

구글 딥마인드는 내부적으로 모든 스킬 옆에 평가를 두고, 스킬 파일이 바뀔 때마다 평가를 자동 실행한다. 정규식 검증과 함께 필요하면 LLM을 심사자로 두며, 평가 점수를 개선하지 못하는 변경은 병합하지 않는 회귀 테스트 체계를 갖췄다. 발표는 코딩 에이전트로 자신의 가장 많이 쓰는 스킬에 테스트 프롬프트 다섯 개를 붙여보라는 실습 과제로 마무리된다.

주요 인사이트

• SkillBench 1.1 기준 스킬은 약 100개 과제에서 평균 15%가량 성능을 높였지만, 사람이 쓴 스킬이 가장 좋았고 AI가 자동 생성한 스킬은 오히려 성능을 떨어뜨릴 수 있었다 — skill.md는 500줄을 넘기지 않는 것이 좋다.
• 설명(description)은 모든 모델 호출마다 맥락에 실리는 고정 비용이므로 짧고 명확해야 하고, 실패의 절반가량은 설명이 약해 스킬이 제때 호출되지 않은 데서 비롯된다.
• 워크플로가 항상 똑같다면 스킬이 아니라 스크립트로 만들어야 토큰과 모델 호출을 아낄 수 있다 — 스킬에는 단계가 아니라 목표와 제약을 적는다.
• 테스트는 경로가 아니라 결과를 봐야 한다: 스킬을 첫 턴에 불렀는지가 아니라 과제를 해냈는지를 측정하고, 비결정성 때문에 케이스당 5~6회 시행하며 여러 하네스에서 검증한다.
• 스킬은 영원하지 않다 — 스킬을 켠 경우와 끈 경우를 모두 평가하는 절제(ablation) 테스트로, 모델이 스킬 없이도 성능을 내면 스킬을 은퇴시키되 평가는 남겨 회귀를 감시한다.

자주 묻는 질문

관련 AI 소식