AI 에이전트 성공률·오류율 모니터링 방법
- 성공률은 사전에 정한 최종 작업 목표를 기준으로 계산합니다.
- 도구 호출 오류와 최종 작업 실패는 분모를 구분해 추적합니다.
- 실시간 추적과 정기적인 온라인·오프라인 평가를 함께 운영합니다.
AI 에이전트의 성공률은 답변이 자연스러운지가 아니라, 사용자가 맡긴 작업을 정한 완료 조건에 따라 끝냈는지로 계산할 수 있습니다. 성공률과 오류율에는 모든 서비스에 통용되는 단일 분모가 있는 것이 아니므로, 먼저 평가 단위와 제외 조건을 정의해야 합니다. 도구 호출 오류와 최종 작업 실패를 분리하면 원인을 찾기 쉽습니다. 운영 추적과 테스트 평가를 함께 활용하세요.
성공률과 오류율, 무엇을 세야 할까
작업 단위 성공률을 정의합니다
이 글에서는 한 번의 사용자 요청을 하나의 작업으로 보고, 사전에 정의한 완료 조건을 충족한 작업 수를 평가 가능한 전체 작업 수로 나눠 작업 성공률을 계산합니다. 예를 들어 예약 변경 에이전트라면 요청을 이해한 것만으로 성공 처리하지 말고, 필요한 권한 확인과 실제 변경 결과까지 완료 조건에 포함할 수 있습니다. 사용자 취소나 입력 부족으로 보류된 건은 성공·실패 또는 평가 제외 중 어디에 해당하는지 미리 정하고, 제외 건수도 따로 기록해야 기간별 비교가 가능합니다.
작업 성공률(%) = 완료 조건을 충족한 작업 수 ÷ 평가 가능한 작업 수 × 100입니다. 작업 하나에 재시도가 여러 번 있어도 작업 단위 성공률에서는 해당 작업을 한 번만 셉니다. 시도와 재시도는 별도 지표로 기록합니다.
응답이 생성됐다는 사실만으로 작업 성공으로 세지 마세요. 실제 도구 실행 결과와 최종 완료 조건을 확인해야 합니다.
오류 사건과 작업 결과를 나눕니다
한 작업에서 API 오류가 여러 번 발생한 뒤 복구될 수 있습니다. 따라서 실패한 도구 호출 수를 전체 도구 호출 수로 나눈 도구 호출 오류율과, 최종 실패 작업 수를 평가 가능한 작업 수로 나눈 작업 실패율을 구분하세요. 아래 지표는 운영에 적용할 수 있는 정의의 예시입니다. 조직의 평가 단위와 제외 기준에 맞게 정하고, 지표 이름과 분모를 일관되게 유지해야 합니다.
| 지표 | 계산 기준 예시 | 읽는 법 |
|---|---|---|
| 작업 성공률 | 완료 조건을 충족한 작업 ÷ 평가 가능한 작업 | 목표 달성 정도 |
| 작업 실패율 | 최종 실패 작업 ÷ 평가 가능한 작업 | 사용자 요청 미완료 정도 |
| 도구 호출 오류율 | 실패한 도구 호출 ÷ 전체 도구 호출 | 연동·권한·응답 문제 |
| 재시도율 | 재시도한 작업 ÷ 전체 평가 대상 작업 | 재시도 발생 빈도와 복구 부담 |
운영 모니터링을 설정하는 5단계
1단계: 성공 판정 기준과 제외 조건을 정합니다
업무 담당자와 함께 완료 조건, 필수 도구, 허용 가능한 부분 완료, 사람에게 넘겨야 하는 상황을 문서화합니다. 결과물의 필수 필드는 코드로 확인하고, 사실성이나 맥락 적합성처럼 판정에 해석이 필요한 항목은 평가 기준표와 표본 검토를 병행하세요. 보류·취소·무효 요청의 처리 규칙과 건수도 함께 기록합니다.
2단계: 작업 전체를 추적할 식별자를 남깁니다
요청 식별자와 에이전트·모델·프롬프트 버전, 도구 이름, 단계별 시작·종료 시각, 성공·실패 상태, 재시도 횟수, 최종 결과를 하나의 작업 기록으로 연결합니다. 추적(trace)은 한 요청에서 일어난 모델 호출과 도구 실행을 시간 순서로 연결하는 기록입니다. OpenTelemetry의 GenAI 관측 규약은 도구 호출과 토큰 사용량 등 기록 항목을 일관되게 구성할 때 참고할 수 있습니다. 입력 메시지와 도구 인수·결과에는 민감정보가 포함될 수 있으므로, 수집 범위를 점검하고 필요한 경우 마스킹·필터링하며 접근 권한과 보관 기간을 관리하세요. OpenTelemetry GenAI 속성 문서는 일부 기록 필드에 민감정보가 포함될 수 있다고 안내합니다.
3단계: 오류 분류와 실패 지점을 기록합니다
최소한 모델 타임아웃·출력 형식 오류, 검색 실패, 도구/API 실패, 권한 거부, 잘못된 최종 결과, 안전 정책 차단, 사용자 중단으로 분류합니다. 오류가 발생한 단계와 재시도 후 회복 여부도 함께 남기면 “실행은 완료됐지만 결과가 기준을 충족하지 못함”과 “도구가 응답하지 않음”을 구별할 수 있습니다.
4단계: 대시보드와 경보를 운영합니다
전체 평균만 보지 말고 업무 유형, 에이전트 버전, 도구, 시간대별로 성공률과 실패율을 나누세요. 표본이 적은 구간은 비율이 크게 흔들릴 수 있으므로 분모와 평가 건수를 함께 표시합니다. 경보 기준은 평상시 기준선과 테스트 결과를 참고해 정하고, 연속 하락이나 특정 오류 급증처럼 조치할 수 있는 조건에 연결하세요. 응답 시간, 토큰 사용량, 비용도 함께 보면 성공률 변화와 지연·비용 변화가 동반되는지 확인할 수 있습니다.
5단계: 표본을 평가하고 개선을 검증합니다
운영 로그에서 무작위 표본과 실패 사례를 골라 사람이 판정하고, 반복 실패 사례를 평가 데이터에 추가합니다. 코드 기반 평가는 필수 필드나 도구 호출 여부처럼 명확한 조건에 활용하고, 모델 평가자(LLM-as-a-judge)는 정답 적합성 등 판단이 필요한 항목에 보조적으로 사용할 수 있습니다. 평가자도 오판할 수 있으므로 정기적으로 사람의 판정과 대조하세요. 배포 전에는 고정된 사례 집합으로 버전 간 회귀를 확인하고, 배포 후에는 실제 트래픽을 표본 평가해 기준선과 비교합니다. LangSmith 문서는 배포 전 오프라인 평가와 운영 중 온라인 평가를 구분해 설명합니다. LangSmith 평가 유형 문서를 참고할 수 있습니다.
- 실패 추적에서 빈도가 높거나 영향이 큰 유형을 고릅니다.
- 프롬프트, 도구 설명, 권한, 데이터 중 원인 후보를 좁힙니다.
- 수정 버전을 기존 사례와 신규 실패 사례로 다시 평가합니다.
- 성공률뿐 아니라 오류율·지연·비용의 변화도 비교합니다.
- 검증된 변경을 단계적으로 적용하고 결과를 관찰합니다.
수치 해석에서 자주 놓치는 점
- 분모와 제외 기준을 고정하세요. 중단·무효 요청을 제외했다면 기준과 건수를 함께 기록해야 전후 비교가 가능합니다.
- 평균만으로 판단하지 마세요. 특정 도구나 업무 유형의 실패가 전체 평균에 가려질 수 있습니다.
- 재시도 성공을 별도 표시하세요. 최종 작업은 성공했더라도 재시도가 늘면 운영 부담이 커질 수 있습니다.
- 버전 변경을 기록하세요. 모델, 프롬프트, 검색 인덱스, 도구 권한 변경 시점을 남겨야 지표 변화의 원인을 추적할 수 있습니다.
단일 성공률 목표치를 모든 에이전트에 똑같이 적용하기보다 업무 위험도와 실패 비용에 따라 기준을 정하세요. 금융 거래나 외부 시스템 변경처럼 되돌리기 어려운 작업에는 사람 승인과 안전 차단 조건을 별도로 두고, 단순 정보 안내와 같은 기준으로 평가하지 않는 편이 적절합니다.
운영 대시보드에는 성공률만 두지 말고 분모, 작업 실패율, 도구 호출 오류율, 재시도율, 평가 표본 수를 함께 표시하세요.
자주 묻는 질문
Q. 성공률은 모델 답변이 맞는 비율인가요?
항상 그렇지는 않습니다. 에이전트가 실제 업무를 수행한다면 답변 품질뿐 아니라 도구 실행과 최종 목표 완료 여부를 포함해 작업 단위로 판정할 수 있습니다.
Q. 재시도에 성공하면 처음 실패는 기록하지 않아도 되나요?
최종 작업 결과에서는 성공으로 집계할 수 있지만, 실패한 호출과 재시도 이력은 별도로 남겨야 합니다. 재시도율의 변화가 운영 부담을 보여줄 수 있습니다.
Q. 모든 작업을 사람이 검토해야 하나요?
필수 필드나 도구 성공 여부는 자동 판정할 수 있습니다. 사실성·업무 적합성처럼 맥락 판단이 필요한 항목은 사람 검토 표본과 대조해 자동 평가의 품질을 확인하세요.
Q. 트래픽이 적어도 모니터링할 수 있나요?
가능합니다. 다만 표본이 적으면 비율이 크게 흔들릴 수 있으므로 평가 건수와 기간을 함께 표시하고, 대표 시나리오를 포함한 사전 평가 데이터로 보완하세요.
