데모에서는 멀쩡했던 에이전트가 문서 품질 0.33점을 받았습니다, Google Cloud 에이전트 클리닉의 60분 평가법으로 오늘은 트레이스부터 남깁니다 | DAKER 커뮤니티

에이전트를 만들어 본 분이라면 데모 화면에서는 멀쩡하게 돌아가던 에이전트가 다른 입력을 받자마자 엉뚱한 결과를 내는 장면을 한 번쯤 겪어 보셨을 것입니다. Google Cloud Tech 채널이 9월 30일 공개한 26분짜리 영상 Why Your AI Agent Fails in Production (And How to Catch It)은 이 문제를 정면으로 다룹니다. Google Cloud 엔지니어 Dani Zamora와 Merge의 개발자 애드버킷 Matthew Feroz가 오픈소스 LangGraph 에이전트 DocsHound를 놓고 60분 안에 평가 파이프라인을 처음부터 세우는 과정을 보여 줍니다. 결론부터 말씀드리면, 만든 사람이 눈으로 보고 괜찮다고 판단한 결과물이 자동 채점표에서는 문서 품질 0.33점을 받았습니다. 해커톤에서 에이전트를 만드는 참가자가 오늘 바로 가져갈 수 있는 교훈은 명확합니다. 지표를 고르기 전에 에이전트가 무엇을 했는지 기록한 트레이스부터 남겨 두는 것입니다.

평가 리포트 화면의 빨간 네모를 바라보는 개발자를 그린 만화풍 생성 이미지와 제목 데모는 멀쩡했는데 0.33점, 에이전트 평가는 트레이스부터, Google Cloud 공식 로고
설명용 생성 이미지입니다.

Google Cloud 에이전트 클리닉이 보여 준 4단계 평가 흐름

이번 영상은 Google Cloud의 AI Agent Clinic 시리즈 중 평가만 다룬 회차입니다. 진행자 Dani Zamora는 영상 첫머리에서 평가를 네 단계로 나눕니다. 첫째, 코딩 에이전트 Antigravity에게 평가할 에이전트의 소스 코드를 읽혀 내부 동작을 파악하게 합니다. 둘째, Google Cloud 팀이 만든 오픈소스 평가 도구로 준비 기간을 몇 주에서 한 시간으로 줄입니다. 셋째, 좋은 결과가 무엇인지 Antigravity에게 알려 주고 평가 지표를 함께 다듬습니다. 넷째, 실제로 평가를 돌려 다음 버전에서 무엇을 고칠지 숫자로 방향을 얻습니다.

평가 대상인 DocsHound는 GitHub 저장소의 열린 이슈와 병합된 풀 리퀘스트를 읽고, 공식 문서에서 빠진 내용을 찾아 문서 수정 풀 리퀘스트 초안까지 만들어 주는 에이전트입니다. 영상 속 시연에서는 이 에이전트가 이슈 50개와 풀 리퀘스트 30개를 살펴본 뒤 오디오 스트림 지원 관련 문서 공백을 찾아냈고, 그 내용이 실제로 병합된 풀 리퀘스트와도 연결되었습니다. 겉으로 보기에는 이미 잘 돌아가는 에이전트였다는 점이 이 영상의 출발점입니다.

흥미로운 점은 DocsHound가 Google의 에이전트 개발 키트(ADK)가 아니라 LangGraph로 만들어졌다는 사실입니다. Dani Zamora는 ADK가 아닌 에이전트도 Google Cloud에서 평가하고 배포할 수 있다는 것을 보여 주고 싶었다고 말합니다. 대회 참가자 입장에서는 어떤 프레임워크로 에이전트를 만들었든 같은 평가 방식을 적용할 수 있는지가 핵심 질문이고, 영상은 그 답을 트레이스 표준화에서 찾습니다.

눈대중 검사가 놓친 문서 품질 0.33점

영상에서 가장 기억에 남는 장면은 마지막 리포트입니다. 자동 채점 결과 DocsHound의 문서 품질 점수는 0.33으로 나왔고, 영상 설명란은 이를 결과를 눈으로 훑어볼 때는 처음에 놓쳤던 사각지대라고 소개합니다. DocsHound를 만든 Matthew Feroz 본인도 문서 품질이 이렇게 낮다는 점에 놀랐다고 말합니다. 그는 시스템 프롬프트를 고치거나 하네스 자체를 바꿔야겠다며, 이 부분이 자신에게 완전한 사각지대였다고 털어놓습니다.

Dani Zamora는 이 상황을 바이브 체크라는 말로 설명합니다. 에이전트를 만든 사람은 결과가 맞는지 감으로 알 수 있지만, 다른 사람이 기여하거나 내가 버전을 바꿨을 때 그 감이 그대로 통한다는 보장은 없습니다. 그래서 만든 사람 머릿속에 있는 품질 기준을 실행 가능한 숫자로 옮겨야 개선과 회귀를 모두 측정할 수 있다는 것이 영상의 주장입니다.

머릿속에 있는 품질 기준을 실제 숫자로 바꿔 두어야, 누가 무엇을 바꾸든 개선과 회귀를 측정할 수 있습니다.

해커톤에서도 같은 일이 자주 일어납니다. 마감 직전에 프롬프트 한 줄이나 모델을 바꾸고 나면, 데모에 쓰는 대표 입력 몇 개만 다시 돌려 보고 제출하는 경우가 많습니다. 영상 속 0.33점은 그런 확인 방식이 놓칠 수 있는 영역이 생각보다 크다는 점을 보여 주는 사례입니다. 다만 Dani Zamora도 점수가 낮을 때 원인이 에이전트 코드일 수도 있고 평가 방식일 수도 있다고 덧붙입니다. 지표 역시 고칠 수 있는 대상이라는 뜻입니다.

트레이스가 먼저입니다: OpenTelemetry와 OpenInference

영상이 평가 지표보다 먼저 다루는 것은 트레이스입니다. 트레이스는 에이전트가 한 번 실행되는 동안 모델 입력, 응답, 도구 호출을 시간 순서대로 남긴 기록입니다. Google Cloud의 Gemini Enterprise Agent Platform Agent evaluation 문서도 트레이스를 에이전트 행동에 대한 사실 그대로의, 바뀌지 않는 기록이라고 정의합니다. 지표는 이 기록 위에서 계산됩니다.

문제는 프레임워크마다 트레이스 모양이 다르다는 점입니다. Dani Zamora는 LangGraph 에이전트와 ADK 에이전트가 스트리밍하는 방식, 스팬과 인자 구조가 서로 다를 수 있다고 설명합니다. 로그 표준인 OpenTelemetry만으로는 이 차이를 다 메우기 어렵기 때문에, 에이전트 트레이스용 표준인 OpenInference를 함께 씁니다. Matthew Feroz는 DocsHound를 처음부터 이 형식에 맞춰 트레이스를 남기도록 만들어 두었고, 덕분에 에이전트 내부 구현을 바꾸더라도 평가 쪽 작업을 다시 하지 않아도 된다고 말합니다.

트레이스에는 품질 판단에 필요한 정보 말고도 운영 지표가 함께 들어 있습니다. 영상에서는 ADK 트레이스에서 지연 시간, 토큰 사용량, 캐시된 토큰 같은 메타데이터를 얻는다고 설명합니다. Matthew Feroz가 더 강한 모델로 바꿔 보자고 제안하자, Dani Zamora는 지금의 작은 모델로 어떤 성능이 나오는지 기록이 있어야 어느 모델을 쓸지 판단할 수 있다고 답합니다. 모델 교체가 잦은 대회 환경에서 특히 쓸모 있는 조언입니다.

지표는 적게 시작하고, 사람이 품질을 정의합니다

평가 지표를 어떻게 고르느냐는 질문에 Dani Zamora는 단순하게 시작하라고 답합니다. 처음부터 지표를 2,000개씩 쓰겠다고 하면 무엇이 가장 중요한지 알 수 없다는 이유입니다. 그가 먼저 권하는 것은 관리형 지표 가운데 도구 사용 품질과 궤적(trajectory) 품질입니다. 에이전트가 기대한 순서대로 움직이는지, 도구를 올바르게 부르는지부터 보라는 뜻입니다.

지표는 단순하게 시작하고, 에이전트를 만든 사람과 쓰는 사람이 품질을 무엇으로 보는지 함께 앉아서 확인하는 것이 가장 중요합니다.

영상 후반에 Antigravity가 만든 eval_config.yaml에는 세 종류의 지표가 섞여 있습니다. 하나는 Vertex AI API가 제공하는 관리형 지표로, 영상에서는 질문 응답 품질이 예로 나옵니다. 둘째는 DocsHound에 맞춰 새로 만든 LLM 심사(LLM-as-a-judge) 지표로, 구조와 서식, 실행 가능성, 기술적 정확성 같은 기준이 들어갔습니다. Matthew Feroz는 필요한 곳에 코드 블록을 넣는지 보는 기준을 특히 반가워합니다. 셋째는 결정론적으로 판정하는 Python 함수 검사기입니다. 사람의 감이 필요한 부분은 LLM 심사에 맡기고, 규칙으로 확인할 수 있는 부분은 코드로 확인하는 조합입니다.

대회 참가자에게 이 구성이 유용한 이유는 심사 기준과 바로 연결되기 때문입니다. 공모전 기획서나 발표에서 우리 에이전트가 잘 동작한다고 말할 때, 어떤 기준으로 몇 개의 시나리오를 돌려 몇 점이 나왔는지 함께 보여 줄 수 있으면 설득력이 달라집니다.

agent-eval 도구의 세 명령과 공식 문서가 밝힌 제약

영상에서 쓴 도구는 Google Cloud Professional Services 저장소에 공개된 agent-eval입니다. README에 따르면 사용 흐름은 세 명령으로 정리됩니다. agent-eval setup은 셸마다 한 번 실행해 gcloud 인증, 프로젝트와 리전 선택, Vertex AI API 활성화, 자동 채점기 권한 연결을 처리합니다. agent-eval init은 에이전트마다 한 번 실행해 에이전트를 자동으로 찾고, 지표를 고르고, tests/eval/dataset.jsonl 데이터셋을 만듭니다. agent-eval run은 반복할 때마다 실행하며 수집, 채점, 분석을 거쳐 report.html을 엽니다.

README는 지표 선택지도 구체적으로 적어 둡니다. Vertex AI 카탈로그의 관리형 지표 18개와 AI가 초안을 잡는 맞춤 지표를 고를 수 있고, eval_config.yaml에서는 managed, custom_llm_judge, multiturn_trajectory_judge, python_function 등 6가지 kind를 지원합니다. 리포트는 LLM 심사 지표를 한 축에 모은 레이더 차트와 이전 실행 결과를 겹쳐 보여 줍니다. 제작팀은 그 이유를 이렇게 설명합니다. general_quality가 0.8로 올랐다는 숫자 하나가 같은 변경으로 tool_use_quality나 환각 지표가 떨어진 사실을 가릴 수 있다는 것입니다. 비용과 지연 시간 타일을 따로 둔 이유도 적혀 있습니다. 매 턴 10달러가 들고 90초가 걸린다면 general_quality 0.95는 큰 의미가 없다는 설명입니다.

제약도 분명히 밝힙니다. Python은 3.10에서 3.12까지 지원하며, 3.13 이상에서는 의존성 설치가 실패할 수 있다고 안내합니다. 평가 지표가 비지 않으려면 GOOGLE_API_KEY가 아니라 Vertex AI를 써야 하므로 Google Cloud 프로젝트가 필요합니다. 또 기본으로 지원하는 프레임워크는 ADK뿐이고, 다른 프레임워크는 트레이스 수집 계층을 따로 맞춰야 한다고 적혀 있습니다. 영상에서 LangGraph 에이전트를 위해 OpenInference 트레이스 변환기를 만든 이유가 바로 이것입니다. 실제로 영상 마지막 리포트에서도 프롬프트 렌더링 오류가 보였고, Dani Zamora는 변환기에 아직 손볼 부분이 있다고 인정합니다.

공식 문서가 정리한 평가 순서: 설계, 실행, 채점, 개선

Google Cloud의 Agent evaluation 문서는 같은 흐름을 네 단계 표로 정리합니다. 설계 단계에서 에이전트의 과제와 기대 결과를 담은 평가 사례(eval case)를 정의하고, 실행 단계에서 실제 또는 시뮬레이션된 대화 트레이스를 만들고, 채점 단계에서 자동 채점기로 지표를 계산하고, 개선 단계에서 지시문이나 도구 수정안을 제안하고 검증합니다. 평가 사례에 대화 계획이 들어 있으면 추론 중에 사용자 응답을 시뮬레이션한다는 설명도 있습니다.

문서에는 대회 참가자가 눈여겨볼 기능이 하나 더 있습니다. 환경 시뮬레이션으로 특정 도구 호출을 가로채 가짜 데이터나 HTTP 503 오류, 지연 급증 같은 상황을 주입해 볼 수 있다는 내용입니다. 외부 API에 기대는 에이전트라면 심사 당일 네트워크나 외부 서비스가 불안정할 때 어떻게 행동하는지 미리 확인해 둘 수 있습니다. Google Cloud를 쓰지 않더라도, 도구 함수 하나를 일부러 실패하게 만들어 에이전트 반응을 기록해 보는 방식으로 같은 점검을 흉내 낼 수 있습니다.

해커톤 참가자가 오늘 해 볼 한 가지: 시나리오별 트레이스 남기기

60분 안에 영상 속 파이프라인 전체를 따라 하기는 쉽지 않습니다. Google Cloud 프로젝트 설정이 필요하고, ADK가 아니라면 트레이스 변환 작업도 해야 합니다. 그래서 오늘 해 볼 일은 하나로 좁히는 편이 현실적입니다. 지금 만들고 있는 에이전트에 대표 입력 몇 개를 정해 두고, 실행할 때마다 모델 입력, 도구 호출과 인자, 결과, 지연 시간, 토큰 사용량을 파일로 남기는 것입니다. 영상에서도 평가의 첫 재료는 이미 실행해 둔 시나리오 하나였고, Antigravity에게 그 시나리오를 바탕으로 비슷한 시나리오를 더 만들게 했습니다. 실제로 DocsHound는 Pi, T3 Code, Opencode 세 저장소에서 다시 실행되어 평가 데이터를 얻었습니다.

트레이스가 쌓이면 다음 순서는 자연스럽게 이어집니다.

  1. 대표 시나리오 몇 개를 정하고, 같은 입력으로 반복 실행해 트레이스를 파일로 저장합니다.
  2. 팀원끼리 좋은 결과의 기준을 문장 두세 개로 적습니다. 이 문장이 나중에 LLM 심사 지표의 채점 기준이 됩니다.
  3. 도구 호출 순서나 필수 필드처럼 규칙으로 판정할 수 있는 항목은 Python 함수 하나로 먼저 검사합니다.
  4. 프롬프트나 모델을 바꿀 때마다 같은 시나리오를 다시 돌려 이전 기록과 비교합니다.

이 정도만 갖춰도 마감 직전에 프롬프트를 고쳤을 때 무엇이 좋아지고 무엇이 나빠졌는지 감이 아니라 기록으로 확인할 수 있습니다. 나중에 agent-eval이나 다른 평가 도구로 넘어가더라도, 트레이스와 품질 기준 문장은 그대로 재료가 됩니다.

평가는 모두에게 필요할까요

영상 마지막에 Dani Zamora가 평가는 모두를 위한 것이냐고 묻자, Matthew Feroz는 그렇기도 하고 아니기도 하다고 답합니다. 혼자 개발하는 입장에서 보면 모델이 내일 더 좋아지거나 하네스가 바뀔 수도 있으니, 평가는 에이전트를 실제 운영 환경에서 제대로 돌려야 할 때 특히 필요하다는 의견입니다. 그러면서도 평가 결과를 직접 보고 나니 시스템 프롬프트와 모델을 다시 바꿔 보고 싶어졌다고 말합니다.

대회는 그 중간 어딘가에 있습니다. 운영 서비스만큼 무거운 평가 체계는 필요 없지만, 심사위원 앞에서 처음 보는 입력을 받는 순간은 작은 운영 환경과 비슷합니다. 영상에서 60분이 다 지나 버저가 울리는 장면이 나오듯, 평가 체계를 한 번에 완성하기는 어렵습니다. 그래서 오늘은 트레이스를 남기는 일부터 시작하고, 지표는 그 위에 하나씩 얹는 방식을 권합니다.

출처

여러분이 만든 에이전트는 지금 어떤 방식으로 확인하고 계십니까? 데모 입력을 몇 번 돌려 보는 방식인지, 따로 정해 둔 시나리오와 기준이 있는지 댓글로 나눠 주시면 다른 참가자에게도 좋은 참고가 될 것 같습니다.