🧩 16. 운영: Eval Skills 실전

스킬을 개선할 때 가장 흔한 착각은 “이번 버전이 더 좋아 보인다”는 감각을 성과로 착각하는 것입니다. 실제 운영에서는 좋아 보이는 답변보다, 같은 입력에서 같은 품질을 내는지가 더 중요합니다. 그래서 Eval은 선택이 아니라 운영 기본기입니다.

OpenAI의 Testing Agent Skills Systematically with Evals가 던지는 메시지도 명확합니다. 스킬 품질은 느낌으로 관리하는 게 아니라, 실행 흔적(trace), 점검 규칙(check), 비교 점수(score)로 닫아야 합니다.

안내: 이 문서는 생성형 AI를 활용해 초안을 작성했고, 공개된 공식 자료를 교차 확인해 실무 운영 관점으로 보강했습니다.

이 글의 근거 자료

OpenAI Blog: Testing Agent Skills Systematically with Evals
- https://developers.openai.com/blog/eval-skills
OpenAI Codex Skills 문서
- https://developers.openai.com/codex/skills
Evaluation Best Practices
- https://platform.openai.com/docs/guides/evaluation-best-practices

핵심 요약

평가는 “좋은 답변”을 뽑는 과정이 아니라 “퇴행(regression)을 빨리 잡는 장치”입니다.
작은 프롬프트셋(10~20개)만 있어도 회귀를 상당 부분 막을 수 있습니다.
deterministic check(확정 규칙)와 rubric check(정성 평가)를 함께 써야 안정적입니다.

flowchart LR
A[프롬프트셋] --> B[에이전트 실행]
B --> C[trace/artifacts 저장]
C --> D[deterministic check]
D --> E[rubric check]
E --> F[점수 비교]
F --> G[개선/퇴행 판정]

🧠 칠판 치트시트

스킬 개선은 감이 아니라 점수로 닫는다

먼저 deterministic, 그다음 rubric

실패 케이스는 CSV에 즉시 추가한다

로그 없는 평가는 재현이 안 된다

좋은 평가셋은 작아도 강하다

평가가 없을 때 실제로 생기는 문제

운영팀이 겪는 실패는 생각보다 비슷합니다.

같은 스킬인데 어떤 날은 잘 되고 어떤 날은 발동이 안 됨
출력은 나왔는데 필수 단계가 누락됨
기능은 추가됐는데 이전 기능이 조용히 깨짐

이 문제는 대부분 “측정이 없어서” 생깁니다. 그래서 Eval의 첫 목적은 완벽한 점수가 아니라, 이상 징후를 빠르게 감지하는 것입니다.

성공 기준을 먼저 나누면 평가가 쉬워진다

원문에서 제안하는 분류가 실무에서도 잘 먹힙니다.

Outcome: 결과물이 실제로 완성됐는가
Process: 의도한 단계와 도구를 따랐는가
Style: 요청한 포맷/컨벤션을 지켰는가
Efficiency: 불필요한 실행/토큰 낭비 없이 끝났는가

이 네 축으로 보면 “왜 실패했는지”가 설명 가능해집니다. 팀 회고도 훨씬 빨라집니다.

작은 프롬프트셋으로 시작하는 이유

큰 벤치마크를 만들다가 시작도 못 하는 경우가 많습니다. 실무에서는 오히려 작은 셋이 더 강합니다.

deterministic 체크로 기반을 먼저 만든다

초기에는 사람이 읽고 판단하기보다, 규칙으로 확정 가능한 항목부터 잡는 게 좋습니다.

예시:

npm install 실행 이벤트가 있었는가
package.json이 생성됐는가
필수 파일이 존재하는가

이 단계에서 중요한 건 JSONL trace입니다. 실행 흔적이 남아야 실패 원인을 재현할 수 있습니다.

정성 평가는 output schema로 고정한다

deterministic만으로는 “구조/설명 품질”을 다 잡기 어렵습니다. 그래서 2차로 rubric 평가를 붙입니다.

핵심은 자유 문장이 아니라 스키마 고정입니다.

{
  "overall_pass": true,
  "score": 86,
  "checks": [
    {"id": "tailwind_setup", "pass": true, "notes": "vite plugin configured"}
  ]
}

스키마를 고정해두면 버전 간 비교가 쉬워지고, CI 리포트로도 바로 연결할 수 있습니다.

미니 사례 3가지

사례 A) 스킬 발동률이 들쭉날쭉하던 팀

name/description을 명확히 바꾸고 프롬프트셋에 negative 케이스를 추가한 뒤, 과발동/미발동 문제를 빠르게 줄였습니다.

사례 B) 결과는 그럴듯한데 필수 단계 누락이 많던 팀

deterministic 체크(필수 명령/필수 파일) 2개만 붙였는데도 누락률이 크게 줄었습니다.

사례 C) 리뷰는 길지만 개선이 느리던 팀

rubric를 schema로 고정한 뒤, “좋다/나쁘다” 논쟁이 줄고 점수 기반 우선순위가 생겼습니다.

30분 도입 루틴

10분: must-pass 3개 정의 (결과/과정/효율 중에서)
10분: 프롬프트셋 10개 작성 + negative 1개 포함
10분: deterministic 2개 체크 구현

여기까지 하면 다음 주부터는 점수 비교 기반으로 개선할 수 있습니다.

적용 체크리스트

스킬별 must-pass 3개를 문서화했다
프롬프트셋 CSV를 만들고 negative 케이스를 포함했다
trace(JSONL) 저장 경로를 고정했다
deterministic 체크 2개 이상을 자동화했다
rubric 결과를 schema 고정 JSON으로 남긴다

일하는 ai

탐색기