AQuA 운영법: 프로덕션 AI 에이전트의 조용한 실패를 찾는 품질 루프 만들기

AI 에이전트 운영에서 가장 까다로운 장애는 에러가 나지 않는 장애다. HTTP 200이 반환되고, latency budget도 지키고, tool call도 성공했는데 결과가 틀린다. 사용자의 채식 프로필을 무시하고 스테이크 식당을 추천하거나, 좌석 가능 여부를 확인하지 않고 3A를 확정했다고 말하는 식이다. 인프라 모니터링은 초록색인데 대화 품질은 떨어진다.

Google은 2026년 10월 8일 AQuA(Ambient Quality Agent)를 공개했다. AQuA는 프로덕션 에이전트 옆에서 동작하는 품질 에이전트다. 요청 경로에 끼어들지 않고, Cloud Trace, Cloud Logging, BigQuery 등에 쌓인 세션을 샘플링해 실패 패턴을 찾고, 비슷한 실패를 묶고, 원인을 진단한다. 핵심은 “에이전트를 평가하는 에이전트”를 운영 외부 루프에 둔다는 점이다.

왜 기존 모니터링으로 부족한가

일반적인 서비스 모니터링은 응답 시간, 오류율, CPU, 메모리, API 실패율을 본다. 에이전트도 이 지표가 필요하다. 하지만 이 지표만으로는 대화 품질을 알 수 없다. 사용자가 “내일 오전 회의 전까지 보고서를 요약해줘”라고 했는데 에이전트가 오늘 오후 기준으로 요약했다면, 시스템 입장에서는 성공 응답일 수 있다. 사용자 입장에서는 실패다.

사전 평가셋도 한계가 있다. 출시 전에는 예상 가능한 시나리오를 만들고, run-grade-fix 루프를 돌릴 수 있다. 이 구간에서는 품질이 빠르게 올라간다. 문제는 출시 후다. 사용자는 예상과 다른 방식으로 질문하고, 모델은 업데이트되고, 도구 스키마는 바뀌고, 프롬프트는 조금씩 수정된다. 초기 eval set은 곧 낡는다.

그래서 필요한 것이 외부 루프다. 실제 운영 트래픽에서 실패 패턴을 찾고, 반복되는 원인을 파악하고, 수정 후 다시 같은 패턴이 줄었는지 확인하는 루프다. AQuA는 이 부분을 자동화하려는 reference implementation에 가깝다.

AQuA의 5단계 파이프라인

Google 설명에 따르면 AQuA는 최근 세션을 최대 1,000개까지 샘플링한다. 비용을 예측 가능하게 유지하기 위한 cap이다. 그다음 각 세션을 리뷰한다. 이때 절차 준수, 도구 선택, 도구 인자, grounding, task completion 같은 9개 체크리스트를 기준으로 본다. 실패 세션에는 실제 결과와 기대 결과를 구조화해 기록한다.

세 번째 단계는 cluster다. 비슷한 실패 메커니즘을 가진 finding을 묶는다. 예를 들어 “사용자 프로필 제약을 마지막 응답에서 잊음”, “재고 확인 도구를 호출하지 않고 예약 확정”, “tool schema의 enum 설명 부족으로 잘못된 인자 사용” 같은 묶음이 생긴다.

네 번째는 verify다. 별도 모델이 후보 cluster를 최대 3개의 전체 transcript와 대조해 근거가 약한 cluster를 버린다. 이 단계가 중요하다. 자동 평가 시스템은 너무 쉽게 잡음을 패턴으로 착각한다. 검증 단계를 두지 않으면 팀은 의미 없는 이슈를 고치느라 시간을 쓴다.

마지막은 track이다. 살아남은 cluster를 BigQuery에 쌓고, NEW, RECURRING, RESOLVED 같은 상태로 관리한다. 14일 동안 보이지 않은 이슈는 자동 해결로 볼 수 있다. 이 방식은 버그 트래커와 비슷하지만, 소스가 사용자 세션이라는 점이 다르다.

우리 팀 스택에 맞게 바꾸는 방법

AQuA가 Google Cloud 기반 예시라고 해서 그대로 써야 하는 것은 아니다. 중요한 설계는 세 가지다. 첫째, 세션 로그와 도구 호출 로그가 구조화되어 있어야 한다. 둘째, 배포 시점의 소스 스냅샷과 프롬프트 버전을 찾을 수 있어야 한다. 셋째, 평가 결과를 이슈처럼 추적해야 한다.

AWS를 쓰는 팀이라면 CloudWatch Logs, X-Ray, S3, Athena, DynamoDB로 비슷한 구조를 만들 수 있다. 자체 서버라면 OpenTelemetry trace와 Postgres 테이블로도 가능하다. 핵심은 로그를 나중에 사람이 읽을 수 있게 남기는 게 아니라, 평가 에이전트가 읽을 수 있게 남기는 것이다.

세션 로그에는 사용자 입력, 에이전트 응답, 선택된 도구, 도구 인자, 도구 결과, 시스템 메시지 버전, 모델명, temperature, retrieval 결과, 권한 결정이 필요하다. 개인정보는 마스킹하거나 샘플링 정책을 둬야 한다. 품질 분석이 개인정보 처리 원칙을 깨면 운영 리스크가 더 커진다.

평가 체크리스트를 어떻게 만들까

처음부터 완벽한 평가 기준을 만들려고 하면 실패한다. 제품별로 6~10개 정도의 기본 실패 유형을 잡고 시작하는 편이 낫다. 예를 들어 고객지원 에이전트라면 “정책 위반 안내”, “환불 조건 누락”, “고객 식별 실패”, “불필요한 상담원 이관”, “도구 미호출”, “근거 없는 확정 표현”이 있을 수 있다.

개발자 도구 에이전트라면 기준이 다르다. “빌드 명령을 실행하지 않고 완료라고 말함”, “테스트 실패를 무시함”, “민감 파일을 읽으려 함”, “사용자 요구와 다른 파일을 수정함”, “deprecated API를 제안함”, “재현 절차 없이 수정함” 같은 항목이 더 중요하다.

평가 기준에는 반드시 expected behavior가 있어야 한다. “나쁜 답변”이라고만 적으면 모델도 사람도 일관되게 판단하기 어렵다. “사용자가 vegan이라고 명시한 경우 육류 식당을 추천하지 않고, 식단 제약을 반영한 후보를 제시해야 한다”처럼 쓰면 cluster가 선명해진다.

수정 루프까지 연결해야 효과가 난다

품질 에이전트가 실패 패턴을 찾아도 팀이 고치지 않으면 대시보드만 늘어난다. AQuA의 결과는 backlog로 들어가야 한다. 각 cluster에는 owner, 원인 가설, 수정 위치, 재현 transcript, 성공 기준이 붙어야 한다. 모델 문제인지, 프롬프트 문제인지, tool schema 문제인지, orchestration 문제인지 구분해야 한다.

수정 후에는 같은 cluster가 줄었는지 봐야 한다. 단순히 eval set 하나를 통과했다고 끝내면 안 된다. 운영 세션에서 7일 또는 14일 동안 recurrence가 줄어드는지 확인해야 한다. 반대로 새 모델 배포 후 recurring cluster가 늘어나면 rollback 또는 prompt patch 기준이 필요하다.

이 루프는 QA 팀만의 일이 아니다. 에이전트 제품에서는 개발자, PM, 데이터 엔지니어, 보안 담당자가 모두 관련된다. 도구 인자 오류는 개발자가 고치고, 정책 누락은 PM이 정의하고, 개인정보 샘플링은 보안 담당자가 검토해야 한다.

실행 체크리스트

• 에이전트 세션 로그에 user input, response, tool call, tool result, model, prompt version을 남긴다.
• 배포 시점의 소스 스냅샷과 프롬프트 버전을 trace에서 찾을 수 있게 한다.
• 최근 세션을 일정량 샘플링하는 배치 작업을 만든다.
• 제품별 실패 유형 6~10개를 정의한다.
• 각 실패 유형에 expected behavior를 문장으로 쓴다.
• 평가 에이전트가 finding을 actual/expected 구조로 남기게 한다.
• 비슷한 finding을 cluster로 묶고, 근거 transcript로 검증한다.
• NEW, RECURRING, RESOLVED 상태를 가진 품질 이슈 테이블을 만든다.
• recurring cluster는 backlog에 owner와 수정 기준을 붙인다.
• 모델·프롬프트·도구 배포 후 7일 단위로 cluster 추이를 확인한다.

AQuA가 던지는 메시지는 명확하다. 에이전트 품질은 출시 전 eval set만으로 관리할 수 없다. 실제 사용자 세션에서 조용히 실패하는 패턴을 찾아야 한다. 프로덕션 에이전트를 운영한다면 uptime 대시보드 옆에 품질 루프 대시보드가 있어야 한다. 그렇지 않으면 가장 비싼 장애는 늘 정상 응답 속에 숨어 있다.