Agents CLI의 eval로 에이전트 품질을 지속적으로 개선하는 방법

이 글의 주제는 Agents CLI v1.8.0에 포함된 LangChain 템플릿이다. 데이터셋 4개를 준비하고, gemini-3.8-flash를 심사자로 삼은 커스텀 LLM-as-judge 지표로 1~5점을 매긴다. 기준선 평균은 4.0, 표준편차는 1.41이었다. 시스템 프롬프트를 실수로 셰프 페르소나로 바꾸면 평균은 2.75로 떨어졌다. eval compare로 케이스별로 보면, sf_weather는 get_weather 도구를 호출하지 않고 날씨를 지어내서 4.0에서 2.0으로 떨어졌다. greeting은 5.0에서 4.0으로, off_topic은 5.0에서 3.0으로 내려갔다. 코드는 정상 동작하므로 단위 테스트로는 찾을 수 없는 변화를 평가가 수치로 보여준 것이다. 모델을 gemini-2.5-flash로 바꾼 실험에서도 평균은 4.00에서 2.75로 떨어져, 프롬프트 실수와 같은 하락 폭이었다. 그러나 내역을 보면 하락의 대부분은 off_topic(5.0에서 1.0)에 집중되었고, 다른 케이스는 거의 유지되었다. 평균만 보면 판단을 그르칠 수 있다는 사례다. 다만 프롬프트와 모델은 서로 영향을 주고받으며, 심사 모델을 고정해야 한다는 점도 주의사항으로 제시하고 있다. 운영 측면에서는 cron이나 Cloud Scheduler로 eval generate와 eval grade를 정기 실행하고, 평균 점수가 기준에서 임계값 이상 떨어지면 0이 아닌 값으로 종료하는 Python 스크립트로 알림을 보내는 예를 소개한다. ADK 프로젝트에서는 eval optimize가 GEPA 프레임워크로 프롬프트를 자동 개선하지만, LangChain 확장은 아직 지원하지 않으며, 지표에 과적합되는 것을 피하려면 사람의 검토를 전제로 해야 한다. 얻은 교훈으로는 작고 대표적인 데이터셋으로 시작할 것, 점수뿐 아니라 결과 파일을 저장할 것, 데이터셋과 기대값 설정을 분리할 것을 꼽았다. 또한 agents-cli를 사용하는 코딩 에이전트는 eval 실행 횟수가 4배로 늘었지만, eval 이후 에이전트를 수정하는 빈도는 거의 변하지 않았다는 자체 조사 결과도 언급하고 있다.

Google Developers Blog 발췌