Google DeepMind에서 Gemini API와 에이전트를 담당하는 필립 슈미트(Philipp Schmid)가 aiDotEngineer 컨퍼런스에서 발표한 세션. 핵심 메시지는 단순하다 — "다들 스킬(skill)을 쓰지만, 아무도 스킬을 평가(eval)하지 않는다."
1. 핵심 주장
- 스킬은 효과가 있지만, 검증 없이는 오히려 성능을 해칠 수 있다. 스킬(에이전트에게 특정 작업 수행법을 알려주는 폴더+문서 형태의 컨텍스트 확장 메커니즘)은 평균적으로 성능을 개선하지만, AI가 대충 만든 스킬은 오히려 성능을 떨어뜨린다.
- "우리가 쓰는 에이전트"와 "우리가 만드는 에이전트"는 완전히 다른 문제다. 코딩 에이전트(Cursor, Claude Code, Antigravity 등)를 쓸 때는 엔지니어 본인이 스킬의 존재를 알고 트리거가 안 되면 즉시 알아채고 재프롬프트한다. 반면 고객을 위해 만드는 에이전트의 사용자는 스킬이라는 개념 자체를 모른다 — 따라서 스킬 트리거를 순전히 모델의 판단(model-invoked)에 맡겨야 하고, 이 지점에서 실패가 집중된다.
- 스킬 성능은 감(feel)이 아니라 데이터로 판단해야 한다. 에이전트는 본질적으로 비결정적(non-deterministic)이라서, 태스크 실패가 "스킬이 나빠서"인지 "과제 자체가 모델에게 너무 어려워서"인지 evals 없이는 구분할 수 없다.
- 스킬에는 두 종류가 있고 관리 방식이 다르다. Capability 스킬(모델이 아직 일관되게 못 하는 것을 가르침, 일시적 — 모델이 좋아지면 은퇴시켜야 함)과 Preference 스킬(팀 고유의 워크플로우/스타일/도메인 지식을 인코딩, 더 오래 지속됨 — foundation 모델은 회사 고유 맥락을 알 수 없으므로).
- evals 없는 스킬 출시는 곧 "출시 후 방치"다. 스킬을 만들 때 최소 10~20개 테스트 프롬프트만 있어도 상당한 문제를 발견할 수 있다.
2. 근거/데이터
- SkillBench: GitHub 등에서 5만 개 이상의 스킬을 인덱싱한 유명 벤치마크. 조사 결과 거의 모든 스킬에 eval이 없었고, 대부분 AI가 작성했으며, 제대로 테스트되지 않은 상태였다.
- SkillBench v1.1 업데이트: 다양한 오픈/클로즈드 모델과 여러 하네스를 대상으로 코딩+생산성 관련 약 100개 태스크를 평가한 결과, 스킬 사용 시 평균 약 15% 성능 향상이 확인됨. 오픈소스로 공개되어 있고 리더보드와 커뮤니티 기여를 받고 있음.
- AI 생성 스킬 분석: 같은 벤치마크팀의 2차 분석에서 사람이 직접 작성한 스킬이 가장 성능이 좋고, AI가 생성한 스킬은 오히려 성능을 저하시킬 수 있음이 확인됨. 또한 skill.md 파일은 500줄 미만이어야 한다는 기준도 제시됨.
- 스킬 미트리거 실패율: 발표자 팀의 경험상 **실패의 약 50%가 "스킬 설명(description)이 충분히 구체적이지 않아 트리거가 안 됨"**에서 발생. 특히 타인을 위해 만든 에이전트의 사용자는 스킬 설명 자체를 모르기 때문에 얕은 프롬프트를 입력하는 경우가 많음.
- Gemini Interactions API 스킬 실전 사례: 117개 테스트 케이스로 검증한 결과, 최신 모델로 유효한 Interactions API 코드를 생성하는 성공률이 약 90%까지 개선됨.
3. 구체 사례
스킬의 구조 (progressive disclosure)
스킬은 기본적으로 SKILL.md 파일 + 추가 에셋으로 구성된 폴더이며, 3단계로 점진적 공개(progressive disclosure)된다.
- 1층: 제목 + 설명(description) — 모델 컨텍스트에 항상 포함되어 매 호출마다 토큰 비용을 지불함
- 2층: 스킬 본문(더 자세한 지침, 외부 파일 참조)
- 3층: 딥 레퍼런스 파일 — 예를 들어 멀티클라우드 배포 스킬이라면 AWS/GCP/Azure 배포 방법을 각각 별도 레퍼런스 파일로 분리해, 모델이 필요한 것만 탐색하게 함
Gemini Interactions API 스킬 구축 사례
Gemini Interactions API는 Gemini 3/3.1/3.5의 학습 마감 이후 출시되어 모델이 전혀 모르는 API였다. 그래서 팀은 실제 사용자 데이터 + 합성 생성 케이스 + 실제 피드백(예: "모델이 3.0인데도 여전히 Gemini 2.0을 쓰려고 함")을 기반으로 117개 테스트 케이스를 만들었다. 필요한 자산은 단 두 가지뿐이었다:
- JSON 테스트 케이스 파일 —
prompt(사용자 입력),language(TypeScript/Python 검증용),should_trigger(스킬이 트리거되어야 하는지 여부),expected_checks(정규식 기반 단순 assert) - 코딩 에이전트(Gemini CLI)를 실행하고 결과를 검사하는 간단한 Python 스크립트
대부분의 스킬 eval은 정규식만으로 충분하다 — 올바른 SDK/모델/메서드를 썼는지, 오래된 패턴을 쓰지 않았는지 확인하는 수준. 저렴하게 자주 돌릴 수 있고, 새 모델이 나오면 assert의 모델 ID만 갱신하면 된다. 더 복잡한 스킬(전체 트레이스/단계를 봐야 하는 경우)은 LLM-as-judge(간단한 rubric 기반 pass/fail)를 쓴다.
Google DeepMind 내부 프로세스
모든 스킬에는 eval이 함께 딸려 있다. 각 테스트는 여러 케이스로 구성되고, 격리된 워크스페이스(환경/파일/시작 커맨드 정의 가능)에서 실행되며, 정규식 기반 스크립트 eval과 LLM-as-judge를 함께 사용한다. 스킬 파일에 변경(diff)이 생길 때마다 eval이 자동 실행되고, eval 성능이 개선되지 않으면 머지되지 않는 회귀 테스트 게이트가 걸려 있다.
4. 실행 포인트
스킬 작성 시 (8가지 팁):
- Description이 가장 중요하다 — "왜(why)" 써야 하는지와 "어떻게(how)" 써야 하는지를 모두 명시. 너무 약하면 과소/과대 트리거로 이어짐
- 에세이가 아니라 지시문(directive)으로 작성 — "이 상황이면 이렇게 하라"는 명령형으로
- 스킬은 lean하게, 정보는 계층화 — description은 매 호출마다 토큰 비용이 드니 짧게, 세부 지침은 레퍼런스 파일로 분리
- 적절한 자유도(freedom) 설정 — 단계별 워크플로우(1단계 이거, 2단계 저거)를 스킬에 쓰지 말 것. 그건 스크립트로 만들어야 함. 스킬에는 목표와 제약만 정의하고 실행은 모델에게 맡길 것
- 부정 케이스(negative case)를 빠뜨리지 말 것 — 스킬을 "언제 쓰지 않아야 하는지"도 명시해 과잉 트리거 방지
- 일찍부터 테스트 — happy path 5개 + negative case 5개, 총 10~20개로 시작. 실제 프로덕션/고객 트레이스가 있다면 반드시 포함
- No-op 제거 (Matt의 공로) — "구현을 읽기 쉽게 만들어라" 같이 모델이 어차피 하는 행동을 지시하는 무의미한 문구를 스킬에서 제거해 토큰 비용 절감
- 스킬 은퇴 시점 파악 — 스킬 있음/없음으로 eval을 돌려서, 없어도 성능이 같다면 그 스킬은 은퇴시킬 것 (토큰/유지보수 비용 절감)
Eval 운영 시 (추가 실행 포인트):
- 경로(path)가 아니라 결과(outcome)를 테스트할 것 — 스킬이 1턴 만에 로드됐는지가 아니라, 결국 태스크를 달성했는지가 중요
- 격리된 실행 환경 사용 — 에이전트가 이전 대화나 다른 실행 기록을 훔쳐보고 "치팅"하지 못하게 할 것
- 케이스당 4~6회 이상 반복 실행 — 모델은 비결정적이므로 신뢰도를 측정하려면 여러 트라이얼 필요
- 여러 하네스(Claude, Antigravity, Cursor, Codex 등)에서 테스트 — 하네스/모델마다 스킬 성능이 다를 수 있음
- 스킬을 은퇴시키더라도 eval은 남겨둘 것 — 나중에 모델 성능이 퇴화하면 그 시점에 스킬을 재도입할 신호로 활용
숙제(발표자가 제안):
- 가장 많이 쓰는 스킬 하나를 골라 테스트 프롬프트 5개를 작성해볼 것 (코딩 에이전트에게 자신의 trajectory를 분석시켜 가장 많이 쓰는 스킬을 찾게 해도 됨)
- 스킬에서 no-op 제거해보기
- Ablation 테스트 실행 — 스킬 있음/없음 두 경우 모두 eval을 돌려서 실제로 스킬이 도움이 되는지, 언제 은퇴시킬 수 있는지 확인
메모
- 참고 자료(No-op 제거 관련 스킬)는 발표자가 언급한 AI 교육자 Matt의 GitHub 스킬 레포지토리에 있음 (발표 중 블로그 포스트로 추가 공유 예정이라고 언급)
- SkillBench 리더보드/벤치마크는 오픈소스로 커뮤니티 기여를 받고 있음