AX LABS
← 블로그 AX Ops 방법론

에이전트도 빌드를 깨야 한다

평가는 대시보드가 아니라 배포 조건이다

AX LABS 6분 읽기

현장에서 에이전트 PoC가 운영으로 넘어갈 때 가장 자주 보이는 장면이 있다. 데모는 통과했다. 사용자 반응도 나쁘지 않다. 그런데 배포 직전에는 여전히 사람이 감으로 판단한다. “이번 프롬프트 수정은 괜찮겠죠”라는 말로 merge가 된다.

그 순간 에이전트는 소프트웨어가 아니라 문서가 된다. 코드에는 테스트가 있는데, 에이전트에는 평가표만 있다. 운영 장애는 여기서 시작한다.

평가는 리포트가 아니라 merge 조건이다

에이전트 평가는 별도 회의에서 보는 품질 점검표가 아니다. CI/CD가 읽을 수 있는 pass/fail 신호여야 한다.

GitHub의 required status check는 보호 브랜치에 merge되기 전 특정 check가 성공해야 한다. 또 특정 GitHub App이 만든 status만 신뢰하도록 설정할 수 있다. 이 구조를 에이전트 평가에도 그대로 써야 한다. 평가 결과가 녹색이면 merge되고, 빨간색이면 멈춘다. 공식 문서: https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches

OpenAI도 AgentKit에서 datasets, trace grading, automated prompt optimization, third-party model support를 평가 기능으로 확장했다고 밝혔다. Agent workflows 평가 문서 역시 traces, graders, datasets, eval runs를 품질 개선의 축으로 둔다. 이는 평가가 모델 비교표가 아니라 실행 흐름의 일부가 됐다는 뜻이다. 공식 문서: https://openai.com/index/introducing-agentkit/ / https://developers.openai.com/api/docs/guides/agent-evals

에이전트 변경은 프롬프트 변경이 아니다. 운영 경로를 바꾸는 배포다.

Gate는 하나가 아니라 단계별로 걸린다

에이전트는 단위 테스트 하나로 막을 수 없다. 실패가 출력, 도구 호출, 메모리, 권한, 비용, 지연시간에 흩어져 나타난다. 그래서 gate를 단계별로 쪼갠다.

단계 막아야 할 실패 Gate 신호
PR 생성 명백한 회귀 golden set, rule assertion
Merge queue 병합 후 충돌 full regression, tool order
Staging 배포 환경 의존 실패 sandbox tool call, 권한 검사
Production 이후 실제 사용 편차 trace sampling, human feedback

LangChain은 2025년 12월 deep agent 평가 글에서 agent trajectory, final message, state에 대해 데이터포인트별 bespoke assertion이 필요하다고 정리했다. 같은 글은 clean, reproducible test environment의 중요성도 강조한다. 공식 글: https://blog.langchain.com/evaluating-deep-agents-our-learnings/

이 관점이 중요하다. 에이전트 평가는 “정답 문장과 비슷한가”만 보지 않는다. 올바른 도구를 불렀는지, 불필요한 외부 호출을 하지 않았는지, 메모리를 잘못 갱신하지 않았는지, 실패했을 때 사람에게 넘겼는지를 본다.

AX Ops의 평가 파이프라인은 운영 계약이다

AX Ops에서 gate는 기술팀의 취향이 아니라 운영 계약이다. 현업, 보안, 개발, 운영이 “무엇이면 배포 가능한가”를 같은 문장으로 합의해야 한다.

우리는 평가 파이프라인을 네 덩어리로 설계한다.

  1. Dataset 계약: 대표 업무, 금지 업무, 경계 업무를 분리한다.
  2. Evaluator 계약: rule, LLM judge, human review의 역할을 나눈다.
  3. Threshold 계약: 어떤 실패는 경고, 어떤 실패는 merge block으로 둔다.
  4. Trace 계약: 실패한 실행의 입력, tool call, 상태 변화를 재현 가능하게 남긴다.

LangChain의 GTM Agent 사례 글은 rule-based assertion과 LLM judge를 함께 쓰고, 전체 eval suite를 CI에서 실행한다고 설명한다. 이 패턴은 특정 영업 에이전트 사례를 넘어 대부분의 업무 에이전트에 적용된다. 공식 글: https://www.langchain.com/blog/how-we-built-langchains-gtm-agent

Claude Code GitHub Actions 문서도 GitHub Actions 안에서 Claude Code를 실행하고, CLAUDE.md 기준과 프로젝트 표준을 따르게 하며, secrets와 권한을 제한하라고 안내한다. 이 문서는 에이전트 자체도 CI/CD 안의 행위자로 들어왔다는 신호다. 공식 문서: https://code.claude.com/docs/en/github-actions

참고와 다음 행동

요약하면 단순하다. 에이전트 평가를 잘하는 조직은 더 많은 평가표를 만들지 않는다. merge를 막는 평가를 만든다. 운영에서 문제가 된 trace는 dataset으로 돌아가고, dataset은 다음 배포의 gate가 된다. 이것이 에이전트를 운영 자산으로 만드는 최소 루프다.

참고:

AX LABS는 이 gate를 PoC 말미가 아니라 킥오프 때 설계한다. 평가 기준 없이 에이전트를 배포하지 않는 조직으로 바꾸는 일이 AX Ops의 출발점이다. AX Ops 방법론 →