Google, Agents CLI 평가 순환을 설명하며 요약 점수의 함정을 경고

Google 개발자 블로그는 2026년 10월 28일 AI 에이전트 구축 도구 Agents CLI의 평가 명령을 설명하는 글을 냈다. 작은 시연용 에이전트로 테스트 사례를 실행하고, 결과를 채점하고, 실행을 비교하고, 차이에 따라 행동하는 순환을 보여 준다. 핵심 경고는 요약 점수가 오해를 부를 수 있으니 사례별 결과를 읽어야 한다는 것이다. 글의 점수 비교는 네 개 사례로 된 시연 결과이며 실제 제품의 벤치마크가 아니다. 별도로 Google 자체 연구도 인용한다.

eval 네임스페이스에는 명령이 다섯 개 있고 각자 역할이 다르다. eval generate는 데이터셋의 사례에 에이전트를 실행한다. eval grade는 생성된 트레이스를 채점한다. eval compare는 두 결과 파일을 나란히 비교한다. eval analyze는 실패를 주제별로 묶는다. eval optimize는 에이전트의 프롬프트를 자동으로 개선한다. 저자들은 이 과정 전체를 힐 클라이밍이라 부른다. 에이전트를 바꾸고 사례를 다시 돌려, 점수가 오르면 유지하고 내리면 되돌린다.

시연은 Agents CLI v1.8.0에 들어 있는 LangChain 템플릿을 쓴다. gemini-3.8-flash로 동작하는 맞춤 평가 지표가 각 답변을 정확성, 관련성, 명확성으로 1에서 5까지 채점한다. 저자들은 사례가 하나뿐인 기본 데이터셋을 인사, 날씨 질문 두 개, 주제와 무관한 질문의 네 개로 늘렸다. 기준 평균은 5점 만점에 4.0, 표준편차는 1.41이었다. 전부 5.0이면 에이전트가 완벽하거나 데이터셋이 너무 쉬워 차이가 드러나지 않는다는 뜻이므로, 저자들은 이 편차를 건강하다고 본다.

다음으로 현실적인 실수를 심는다. 개발자가 요리사 페르소나를 날씨 에이전트의 시스템 프롬프트에 잘못 붙여 넣는다. 린트, 단위 테스트, 타입 검사는 통과하고 에이전트도 계속 동작한다. 평균은 2.75로 떨어졌다. 사례별 비교는 피해 위치를 보여 준다. 인사는 어조에서 1점, 주제 무관 질문은 범위 이탈로 2점, sf_weather 사례는 에이전트가 날씨 도구를 부르지 않고 값을 지어내서 2점을 잃었다. 맥락 속의 행동을 채점하는 종단 간 평가만이 이런 결함을 찾는다는 것이 저자들의 주장이다.

두 번째 실험은 에이전트 모델을 gemini-3.8-flash에서 gemini-2.5-flash로 바꾼다. 글에 적힌 대로 평균은 다시 4.00에서 2.75가 되지만 사례별 모습은 다르다. 더 싼 모델은 인사와 날씨 질문 하나에서는 같았고 다른 날씨 질문에서 1점을 잃었으며, 눈에 띄는 하락은 주제 무관 질문에서 나왔다. 그 모델이 사건이 아직 일어나지 않았다는 둘러대기로 답을 거부했기 때문이다. 저자들은 한 모델에 맞춘 프롬프트가 다른 모델에서는 성능을 잃을 수 있고, 비교가 공정하려면 평가 모델을 고정해야 한다고 주의를 준다.

글은 일정 실행과 한계도 다룬다. Agents CLI에는 스케줄러가 없으므로 cron이나 Cloud Scheduler로 밤마다 generate와 grade를 돌리고, 평균이 기준 이상 떨어지면 0이 아닌 값으로 끝나는 스크립트를 붙일 수 있다. eval optimize는 GEPA 프레임워크를 통해 ADK 프로젝트에서 동작하고 LangChain 확장은 지원하지 않는다. 바꾸는 것은 프롬프트뿐이며 지표의 문구에 과적합해 점수를 올릴 수 있으므로 사람이 후보를 검토한다. Google은 자체 대조 연구도 언급한다. 이 도구를 쓴 코딩 에이전트는 평가를 네 배 많이 실행했지만 평가 뒤에 에이전트를 바꾸는 빈도는 기준과 비슷했다는 것이다. 이는 Google의 주장이며 글에 데이터는 없다.

저자들이 정리한 교훈은 다섯 가지다. 작고 대표적인 데이터셋으로 시작할 것, 점수가 아니라 결과 파일을 저장할 것, 데이터셋과 기대치를 분리해 둘 다 버전 관리에 넣을 것, 요약 지표를 의심할 것, 평가를 더 많이 한다고 수정이 늘어나지는 않으므로 결과에 따라 행동할 것이다. 네 개 사례는 1분 안에 돌지만 300개 사례는 한 시간이 걸려 출시 관문이나 방치된 자산이 되기 쉽다고 한다.

실용적인 교훈은 소박하다. 매일 쓰는 데이터셋은 변경 때마다 돌릴 수 있을 만큼 작게 유지하고, 점수만이 아니라 전체 결과 파일을 저장하고, 평균을 믿기 전에 사례별 차이를 읽는다. 어떤 사례가 중요한지에 대한 판단은 도구가 주지 못하며 팀이 직접 내놓아야 한다.