Don't Ship Skills Without Evals — Philipp Schmid, Google DeepMind

한 줄 핵심

스킬은 강력하지만, 평가 없이 배포하면 성능 저하·오탐·비용 낭비를 구분할 수 없으므로 반드시 실전형 eval로 검증하고 유지·폐기까지 관리해야 한다.

시간별 요약

1. 0:01
   스킬은 대부분 쓰지만 평가 없이 받아들이는 경우가 많고, 에이전트의 비결정성 때문에 실패 원인이 스킬 문제인지 과제 난이도인지 구분하기 어렵다. 따라서 먼저 ‘우리가 쓰는 에이전트’와 ‘우리가 만드는 에이전트’의 사용 맥락이 다르다는 점을 분리해 이해해야 한다.
2. 3:00
   스킬은 capability skill과 preference skill로 나뉘며, 전자는 모델이 아직 일관되게 못하는 일을 보완하는 임시 자산이고 후자는 팀·도메인 고유의 선호와 워크플로를 장기적으로 담는 자산이다. 두 경우 모두 eval이 있어야 유지 여부와 성능 저하를 판단할 수 있다.
3. 6:00
   좋은 스킬은 짧은 설명, 명확한 지시, 필요한 경우에만 호출되도록 하는 경계 조건, 그리고 상세 내용은 참조 파일로 넘기는 계층적 구조를 가진다. 워크플로가 항상 같다면 스킬보다 script가 더 적절하고, 모델이 과도하게 불리는 오탐을 막기 위해 부정 사례까지 포함한 테스트가 필요하다.
4. 12:01
   Gemini Interactions API용 스킬 사례에서는 117개의 테스트 케이스와 간단한 JSON·Python 기반 harness로 유효한 코드 생성률을 거의 90%까지 끌어올렸다. 핵심은 regex 기반의 저비용 assert와 필요할 때만 LLM as a judge를 쓰는 방식으로, 스킬 변경마다 회귀 테스트를 돌려 품질을 통제하는 것이다.
5. 17:02
   실무적으로는 설명문을 더 선명하게 쓰고, negative test를 넣고, 결과가 아닌 경로가 아니라 outcome을 평가하며, 격리된 환경에서 여러 번 반복 실행해야 한다. 또한 skill을 없애더라도 eval은 남겨 모델 업데이트로 인한 성능 저하를 다시 감지하고, no-op를 줄여 토큰 비용도 함께 관리해야 한다.

실무 인사이트

• 스킬 도입 시 가장 먼저 할 일은 5~10개의 happy path와 negative test를 만들어 오탐과 미탐을 동시에 확인하는 것이다.
• 스킬이 잘 동작해도 eval을 남겨두면, 모델 개선으로 스킬을 폐기할 수 있는 시점을 객관적으로 판단하고 재퇴행을 빠르게 잡을 수 있다.
• 설명문이 길어질수록 매 호출마다 비용이 누적되므로, 지시문은 짧고 강하게 쓰고 세부 지식은 참조 파일로 분리하는 편이 효율적이다.