현장에서 에이전트 프로젝트를 보면 이상한 순서가 반복된다. 데모는 빠르다. PoC도 그럴듯하다. 그런데 운영 반영 직전에는 “이번 모델이 더 나은가”, “tool 호출이 위험하게 바뀌지 않았나”, “기존 업무 예외를 깨지 않았나”를 회의실에서 다시 묻는다. 그 질문을 사람이 매번 회의로 푸는 순간, 에이전트는 제품이 아니라 실험으로 남는다.
평가는 승인 문서가 아니라 배포 조건이다
에이전트는 일반 소프트웨어보다 변경면이 넓다. 코드만 바뀌지 않는다. system prompt, tool schema, retrieval corpus, memory 정책, 모델 버전, MCP 서버 권한이 모두 동작을 바꾼다.
그래서 평가는 QA 막판 산출물이 아니다. CI/CD gate다. PR이 열릴 때, 프롬프트가 바뀔 때, 모델 라우팅이 바뀔 때, 지식베이스가 갱신될 때 자동으로 평가가 돌아야 한다.
운영 에이전트의 기준은 “잘 대답했다”가 아니라 “배포를 막을 실패를 자동으로 잡았다”다.
OpenAI는 2025년 AgentKit 발표에서 dataset, trace grading, human annotation, third-party model support를 agent eval의 핵심 기능으로 묶었다. Google Vertex AI도 Gen AI evaluation service에서 agent trace와 response quality를 평가 대상으로 다룬다. 시장의 방향은 명확하다. 평가는 실험실 기능이 아니라 릴리즈 통제 기능으로 이동했다.
게이트는 네 겹으로 나눠야 작동한다
에이전트 평가를 하나의 점수로 만들면 운영에서 무너진다. 임원 보고에는 단일 점수가 편하지만, 배포 차단에는 쓸모가 약하다. 무엇이 깨졌는지 알아야 고친다.
| Gate | 막아야 할 실패 | 평가 방식 |
|---|---|---|
| Contract gate | JSON 형식, 필수 필드, tool argument 오류 | deterministic test, schema validation |
| Trajectory gate | 잘못된 tool 순서, 불필요한 권한 사용 | trace/trajectory match |
| Quality gate | 답변 누락, 업무 기준 위반, 근거 부족 | rubric, LLM-as-judge, human review |
| Risk gate | 개인정보, 금지 행위, 과도한 실행 권한 | policy check, allowlist, HITL 조건 |
LangSmith의 AgentEvals 문서는 trajectory match와 LLM-as-judge를 구분한다. OpenAI graders 문서도 string check, text similarity, score model grader, Python code execution처럼 평가기를 유형화한다. 핵심은 도구 선택이다. 형식 오류를 LLM judge에게 맡기지 않는다. 업무 품질을 정규식으로 끝내지도 않는다.
CI/CD gate는 작은 데이터셋에서 시작한다
많은 조직이 평가 파이프라인을 만들 때 처음부터 거대한 benchmark를 만들려 한다. 그 접근은 늦다. 먼저 운영에서 자주 깨지는 케이스를 작은 golden set으로 고정한다. 그리고 PR마다 돌린다.
AX Ops에서는 에이전트 gate를 다음 순서로 설계한다.
- 업무 owner가 실패 유형을 먼저 정의한다.
- 개발팀은 실패 유형별 최소 dataset을 만든다.
- evaluator는 rule, code, LLM judge, human review로 분리한다.
- CI/CD는 통과 기준을 branch protection에 연결한다.
- 운영 trace에서 실패 케이스를 dataset으로 되돌린다.
LangSmith는 GitHub Actions, offline evaluation, preview deployment, quality-gated production release를 한 파이프라인으로 설명한다. Anthropic의 Claude Code GitHub Actions도 CLAUDE.md, repository secrets, claude_args, workflow trigger를 통해 에이전트를 GitHub workflow 안에 넣는 방식을 공식화했다. 이제 문제는 도구 존재 여부가 아니다. 조직이 어떤 실패를 배포 차단 기준으로 선언하느냐다.
참고한 최근 1차 자료는 이렇게 남긴다
- OpenAI, “Introducing AgentKit”, 2025-10-06: https://openai.com/index/introducing-agentkit/
- OpenAI, “How evals drive the next chapter in AI for businesses”, 2025-11-19: https://openai.com/index/evals-drive-next-chapter-of-ai/
- OpenAI API Docs, “Graders”, 2026년 확인: https://platform.openai.com/docs/guides/graders/
- Google Cloud, “Gen AI evaluation service overview”, last updated 2026-05-01: https://docs.cloud.google.com/vertex-ai/generative-ai/docs/models/evaluation-overview
- LangChain Docs, “Implement a CI/CD pipeline using LangSmith Deployment and Evaluation”, 2026년 확인: https://docs.langchain.com/langsmith/cicd-pipeline-example
- Anthropic Docs, “Claude Code GitHub Actions”, 2026년 확인: https://docs.anthropic.com/en/docs/claude-code/github-actions
게이트가 없으면 운영은 다시 수작업이 된다
에이전트 운영에서 가장 위험한 상태는 실패가 없는 상태가 아니다. 실패가 어디서 잡히는지 모르는 상태다. 회의에서 감으로 승인하는 배포는 결국 현장 리더에게 검수 부담을 넘긴다.
CI/CD gate는 속도를 늦추는 장치가 아니다. 반복 검수를 제거하는 장치다. 작은 golden set, 명확한 evaluator, branch protection, 운영 trace feedback loop만 연결해도 조직의 대화가 바뀐다. “이번 배포 괜찮습니까”가 아니라 “어느 gate에서 막혔습니까”로 바뀐다.
AX는 모델 도입이 아니라 운영 통제의 재설계다. 에이전트를 운영 자산으로 만들려면 평가 파이프라인부터 배포 라인에 걸어야 한다. AX Ops에서 이 설계를 한 사이클로 다룬다: AX Ops 방법론 →