'잘 되는 것 같은데요'에서 벗어나기: 에이전트 평가·관측 데이터를 BigQuery에 쌓기

데모 다음 날 받은 질문

에이전트를 사내에 공개하고 나면 반응은 대체로 좋습니다. 그리고 며칠 뒤 누군가 이렇게 묻습니다.

"그래서 이거 얼마나 잘 돼요?"

여기에 숫자로 답하기가 의외로 어렵습니다. "잘 되는 것 같다"는 느낌은 있습니다. 써본 사람들이 칭찬도 합니다. 하지만 몇 퍼센트의 질문에 제대로 답했는지, 어떤 질문에서 실패했는지는 모릅니다.

웹 서비스라면 에러율과 응답 시간을 봅니다. 에이전트는 HTTP 200을 돌려주면서 틀린 답을 합니다. 기존 모니터링 지표로는 실패가 보이지 않습니다.

발표에서 본 '개선 루프'

Next '26의 Gemini Enterprise Agent Platform 발표에는 이 문제를 다루는 기능이 네 개 묶여 있었습니다.

• Agent Analytics 플러그인: ADK와 LangGraph 에이전트의 상호작용을 BigQuery에 기록합니다.
• Agent Simulation: 가상 사용자와 가상화된 도구로 에이전트를 시험하고, 과제 성공률과 안전성을 점수로 매깁니다.
• Agent Evaluation & Observability: 다중 턴 대화를 자동 채점(autorater)하고, 실제 트래픽을 실시간으로 평가하며, 추론 과정을 추적합니다.
• Agent Optimizer: 실제 실패 사례를 군집으로 묶고, 개선된 시스템 지시문을 제안합니다.

순서대로 놓으면 하나의 루프가 됩니다. 기록하고, 채점하고, 실패를 묶고, 고칩니다. 그리고 고친 버전을 시뮬레이션으로 다시 확인합니다.

이 중 데이터 엔지니어에게 가장 반가운 건 첫 번째였습니다. 에이전트 로그가 BigQuery 테이블로 떨어진다면, 나머지는 우리가 익숙한 SQL의 영역이 되니까요.

로그를 쌓았다면 먼저 볼 세 가지

실제 플러그인이 만드는 테이블 스키마는 버전에 따라 다를 수 있습니다. 아래 쿼리는 이벤트 단위로 쌓인 일반적인 형태를 가정한 예시입니다. 중요한 건 컬럼 이름보다 무엇을 물어보는가입니다.

첫 번째 질문은 "어떤 도구가 가장 자주 실패하는가"입니다. 에이전트 품질 문제의 상당수는 모델이 아니라 도구에서 시작됩니다.

SELECT
  tool_name,
  COUNT(*) AS calls,
  ROUND(COUNTIF(status = 'ERROR') / COUNT(*), 3) AS error_rate,
  APPROX_QUANTILES(latency_ms, 100)[OFFSET(95)] AS p95_latency_ms
FROM `my_project.agent_logs.events`
WHERE event_type = 'TOOL_CALL'
  AND DATE(event_ts) >= DATE_SUB(CURRENT_DATE(), INTERVAL 7 DAY)
GROUP BY tool_name
ORDER BY error_rate DESC;

두 번째는 "도구를 한 번도 부르지 않고 끝난 세션"입니다. 앞선 ADK 글에서 다룬, 검색을 건너뛰고 자기 지식으로 답한 경우가 여기에 걸립니다.

SELECT session_id, ANY_VALUE(user_query) AS first_query
FROM `my_project.agent_logs.events`
WHERE DATE(event_ts) = CURRENT_DATE() - 1
GROUP BY session_id
HAVING COUNTIF(event_type = 'TOOL_CALL') = 0;

세 번째는 "같은 질문을 다시 묻는 사용자"입니다. 짧은 시간 안에 비슷한 질문을 반복했다면, 첫 답이 만족스럽지 않았다는 신호일 가능성이 큽니다. 명시적인 좋아요·싫어요 버튼보다 훨씬 많은 신호를 줍니다.

실패 묶기는 LLM에게 맡겨도 된다

실패 세션을 찾고 나면 수백 건의 대화가 남습니다. 하나씩 읽기에는 너무 많습니다.

Agent Optimizer가 하는 일 중 하나가 실패를 군집으로 묶는 것입니다. 같은 생각을 BigQuery 안에서도 해볼 수 있습니다. 실패한 세션의 마지막 응답을 AI.CLASSIFY로 몇 가지 유형에 나눠 담는 겁니다.

SELECT
  AI.CLASSIFY(
    final_answer,
    categories => ['근거 문서 없음', '권한 부족', '질문 오해', '도구 오류', '기타']
  ) AS failure_type,
  COUNT(*) AS sessions
FROM `my_project.agent_logs.failed_sessions`
GROUP BY failure_type
ORDER BY sessions DESC;

이렇게 묶어 보면 "질문 오해"가 압도적으로 많은 주가 있고, "도구 오류"가 튀는 날이 있습니다. 앞쪽은 지시문 문제이고, 뒤쪽은 인프라 문제입니다. 고치는 사람이 다릅니다.

로그에는 질문이 그대로 남는다

에이전트 로그를 쌓기 시작할 때 꼭 짚어야 할 게 있습니다. 이 로그에는 사용자의 질문 원문과 에이전트가 읽은 문서 내용이 그대로 들어 있습니다.

일반 애플리케이션 로그보다 훨씬 민감합니다. 누군가 인사 정보를 물었다면 그 질문이, 에이전트가 기밀 문서를 읽었다면 그 문단이 로그에 남습니다.

그래서 처음부터 보존 기간과 접근 범위를 정해 둡니다.

ALTER TABLE `my_project.agent_logs.events`
SET OPTIONS (partition_expiration_days = 30);

질문 원문 컬럼은 정책 태그로 접근을 제한하고, 집계 분석은 원문 없이 돌아가도록 뷰를 따로 만듭니다. 분석가 대부분은 원문이 아니라 숫자만 있으면 됩니다.

평가는 기능이 아니라 습관

시뮬레이션이나 자동 채점 같은 기능은 분명 도움이 됩니다. 그래도 가장 먼저 필요한 건 도구보다 습관이라고 생각합니다.

매주 실패 세션 스무 개를 사람이 직접 읽는 것. 지시문을 고치기 전에 지난주 실패 유형 분포를 먼저 보는 것. 고친 뒤에는 같은 질문들로 다시 돌려보는 것.

이 습관이 있는 팀에게 Next '26의 평가 도구들은 손을 덜어주는 자동화가 됩니다. 습관이 없는 팀에게는 아무도 열어보지 않는 대시보드가 하나 더 생길 뿐입니다.