“확인하겠습니다”가 0.4초 만에 떠도, 필요한 답변이 언제 완성될지는 아직 알 수 없다. AI 에이전트의 속도를 비교하려면 첫 표시까지의 시간과, 정한 검증을 통과한 결과를 사용할 수 있을 때까지의 시간을 나눠 재야 한다. 완료한 요청의 p95만 보면 끝내지 못한 요청이 통계에서 사라질 수도 있다.
이번 AI Agent Fast Learning은 검증된 완료 1건의 비용에 이어, 그 완료를 얼마나 기다렸는지 다룬다. 목표는 측정 경계를 정하고, p95와 시간 내 완료율을 함께 읽는 것이다. 아래 두 방식과 모든 숫자는 계산을 설명하기 위한 합성 예시이며 실제 제품의 성능 측정이 아니다.
시계를 어디서 시작하고 멈출까
가상의 업무를 “공개 제품 문서를 읽고, 질문의 답과 근거 위치를 제시하는 내부 검토용 답변 만들기”로 정하자. 완료 조건은 답변의 필수 항목과 근거 일치 검사를 통과하고, 그 결과가 화면에서 사용 가능한 상태다. 외부 발송이나 주문처럼 상태를 바꾸는 작업은 이 예시에서 다루지 않는다.
| 기록할 시점 | 이 글에서의 정의 |
|---|---|
| 요청 시작 | 사용자가 제출한 시점. 전송·대기열 시간을 포함 |
| 첫 표시 | 접수 안내나 스트리밍 문자 등 첫 내용이 화면에 나타난 시점 |
| 검증된 완료 | 필수 검사를 통과한 결과가 화면에서 사용 가능해진 시점 |
| 관찰 종료 | 완료·오류·사용자 취소 또는 정해 둔 관찰 마감. 종료 이유를 별도 기록 |
첫 표시 시간은 “첫 표시 시점 − 요청 시작 시점”, 검증된 완료 시간은 “검증된 완료 시점 − 요청 시작 시점”이다. 둘은 같은 출발점을 쓰지만 도착점이 다르다. 모델 API의 첫 토큰 수신 시간도 유용한 하위 지표다. 다만 그 토큰이 도구 호출 인자라면 사용자 화면에 보이지 않을 수 있고, 접수 안내를 먼저 띄웠다면 화면의 첫 표시와도 일치하지 않는다.
Google SRE는 사용자에게 중요한 동작부터 지표를 정하고, 서버 측 시간만 보면 브라우저에서 겪는 지연을 놓칠 수 있다고 설명한다. 이 글은 그 원칙을 에이전트의 화면 표시와 검증 완료에 적용한다. 이 글의 시점 이름은 특정 SDK의 표준 필드가 아니라 측정 설계 제안이다. Google SRE: Service Level Objectives
접수 안내는 기다림을 설명해 주지만 질문에 답하지는 않는다. 첫 표시가 빨라졌다는 이유로 검증 완료 시간까지 줄었다고 쓰지 않는다. 사람이 검토해야 끝나는 업무라면 검토 대기와 수정 시간도 전체 경과 시간에 포함하고, 자동 처리 구간은 따로 보여 준다. 서버 완료 시각만 확보했다면 “사용자가 결과를 본 시간”으로 이름을 바꾸지 않는다.
p95는 어떤 표본의 95번째 백분위인가
완료 시간을 짧은 순서로 정렬했을 때, 표본의 95% 이상이 그 값 이하에 놓이도록 고른 경계를 p95라고 읽을 수 있다. 이 글은 nearest-rank 방식을 쓴다. 표본 수 N에 0.95를 곱해 올림한 순위의 값을 고른다. 순위는 1부터 센다. p50도 같은 방식으로 계산한다.
20건이면 p95는 올림(20 × 0.95) = 19번째 값이다. 따라서 p95가 8초여도 가장 느린 20번째 요청은 18초일 수 있다. p95는 최대값도, 앞으로 들어올 요청의 95%가 반드시 그 시간 안에 끝난다는 보장도 아니다. 20건은 계산을 눈으로 확인하기 위한 작은 표본이다. 실제 비교에는 표본 수·관찰 기간·업무 구성을 함께 보고, 반복 관측에서 분포가 유지되는지 확인해야 한다.
계산 도구마다 보간 방법이 다를 수 있다. 같은 원자료여도 선택한 방식에 따라 p95가 달라질 수 있으므로 계산법을 적는다. 히스토그램으로 추정했다면 버킷 경계와 해상도도 영향을 준다. 또한 서버별 p95를 평균 내서 전체 p95로 만들 수는 없다. 같은 정의의 원자료나 합칠 수 있는 분포를 먼저 모아야 한다. Prometheus: Histograms and summaries
합성 예시: 완료한 건만 보면 A가 더 빠르다
같은 질문 20개를 A와 B에 각각 주었다고 가정하자. 문서 버전·완료 기준·요청 조건은 같고, 각 요청은 시작 후 30초까지 관찰한다. 첫 표시는 A의 모든 요청에서 0.4초, B에서 1.2초다. A는 18건이 6초에 검증된 완료가 되고, 나머지 2건은 30초에 클라이언트 대기가 끝났지만 최종 결과를 확인하지 못했다. B는 19건이 8초, 1건이 18초에 검증된 완료가 된다.
| 항목 | A 방식 | B 방식 |
|---|---|---|
| 대상 요청 수 | 20건 | 20건 |
| 첫 표시 p95 | 0.4초 · N=20 | 1.2초 · N=20 |
| 검증된 완료 시간 원자료 | 6초 × 18건 | 8초 × 19건, 18초 × 1건 |
| 완료 시간 p50 | 6초 · N=18 | 8초 · N=20 |
| 완료 시간 p95 | 6초 · N=18 | 8초 · N=20 |
| 30초 관찰 종료까지 검증된 완료 | 18/20 = 90% | 20/20 = 100% |
| 30초에서 결과 미확인 | 2건 | 0건 |
| 10초 이내 검증된 완료 | 18/20 = 90% | 19/20 = 95% |
A의 완료 시간 p95는 올림(18 × 0.95) = 18번째 값인 6초다. B는 20건의 19번째 값인 8초다. 이 두 숫자만 읽으면 A의 완료 시간이 더 짧다. 그런데 A의 시간 표본에는 최종 결과가 없는 2건이 들어 있지 않다. 이는 완료를 확인한 요청에 한정한 분포다. 전체 요청이 빠르게 처리됐다는 뜻으로 확대할 수 없다.
A의 미확인 2건에 30초라는 완료 시간을 넣으면 안 된다. 확인한 사실은 30초에 기다리기를 멈췄다는 것뿐이다. 내부 작업의 완료·취소 여부는 별도 조회가 필요하다. 반대로 이 2건을 요청 집계에서도 지워 버리면 비교가 유리해진다. 완료 시간 통계에서는 값 없음으로 두고, 전체 대상 수와 미확인 건수에는 남긴다. 오류 종료 시간도 성공 완료 시간과 분리한다.
시간 안에 끝냈는지는 전체 요청으로 계산한다
이 예시에서는 “요청 후 10초 이내에 검증된 결과를 사용할 수 있었는가”를 별도로 묻는다. 시간 내 검증 완료율 = 10초 이내 검증된 완료 건수 ÷ 미리 정한 대상 요청 수다. A는 18/20 = 90%, B는 19/20 = 95%다. B의 18초 완료는 최종 완료에는 포함되지만 10초 이내 완료에는 들어가지 않는다.
10초와 30초는 설명을 위한 가정이다. 특정 서비스의 권장 응답 시간이나 업계 기준이 아니다. 실제 목표 시간은 사용자가 결과를 쓰는 상황에 맞춰 정하고, 관찰 마감과도 구분한다. 조회 화면에서 기다리는 요청과 다음 날까지 끝내면 되는 보고서에 같은 목표를 적용할 이유는 없다.
대상 요청은 결과를 보기 전에 정한다. 사용자 취소·입력 오류·대상 외 요청을 어떤 기준으로 포함하거나 제외할지 기록하고, 제외 건수도 남긴다. 아직 10초의 관찰 기회조차 지나지 않은 새 요청을 목표 시간만큼 관찰이 끝난 요청과 섞어 판정하지 않는다. 데이터 수집이 끊겨 결과를 모르는 경우에는 그 미확인 비중을 표시하며, 미확인을 곧바로 실패로 단정하지 않는다. 다만 확인되지 않은 요청을 시간 내 완료의 분자에 넣을 근거도 없다.
느린 구간은 분포를 본 뒤 좁힌다
요청별 시간이 준비되면 쉬운 질문·긴 문서·검색이 필요한 질문처럼 의미 있는 유형별로 분포를 나눠 볼 수 있다. 후보에 쉬운 질문이 더 많이 배정됐거나 한쪽만 캐시가 준비돼 있었다면, 전체 p95 차이를 모델 개선 효과로 단정하기 어렵다. 같은 조건의 요청을 비교하고 동시 요청량과 대기열 상태도 기록한다.
Anthropic의 에이전트 평가 안내는 고정된 작업 묶음에서 지연·토큰 사용·작업당 비용·오류를 추적하는 접근을 제시한다. 비용과 품질 조건을 함께 고정해야 속도 변화의 의미도 읽을 수 있다. Anthropic: Demystifying evals for AI agents
오래 걸린 요청의 위치를 찾을 때는 Trace와 Span으로 나눈 실행 기록을 연다. 대기열이 긴지, 도구 응답이 늦는지, 검증 단계가 반복되는지 확인한 뒤 한 가지를 바꾼다. 병렬 구간의 시간을 더하거나 단계별 p95를 더해 전체 p95를 만들지 않는다. 전체 요청의 시작과 검증 완료 경계에서 다시 측정해야 한다.
다음 비교에 남길 여섯 가지
- 시간의 경계: 요청 시작·첫 표시·검증 완료·관찰 종료의 정의와 측정 위치
- 표본: 대상 요청 수, 완료 시간 표본 수, 오류·취소·미확인·제외 건수
- 조건: 모델·프롬프트·도구·문서·검증 기준 버전, 동시 요청량과 캐시 조건
- 분포: p50·p95·최대값, 시간 단위와 백분위 계산법
- 업무 기준: 목표 시간 내 검증 완료율, 전체 완료율, 같은 요청 묶음의 비용
- 계측 품질: 누락 기록, 시계 기준, 수집 범위. 본문·개인정보 대신 필요한 식별자와 수치만 기록
짧은 경과 시간은 같은 계측 지점의 단조 시계로 재는 방법을 검토하자. 여러 기계의 벽시계를 빼야 한다면 시계 차이를 확인해야 한다. UI·서버·검토자의 시각을 출처 없이 섞으면 병목처럼 보이는 차이가 계측 오차일 수 있다. 관찰 가능한 경계를 정확히 이름 붙이는 것부터 시작하면 된다.
A와 B 가운데 무엇을 채택할지는 이 작은 예시가 결정해 주지 않는다. 대신 다음 보고서의 문장은 더 정확해질 수 있다. “A의 완료 표본 p95는 6초이고, 20건 중 18건이 10초 안에 검증됐다. 2건은 30초에 결과 미확인이다.” 속도 수치 옆에 남은 요청을 적으면, 무엇을 개선해야 하는지도 함께 보인다.
자료와 검증 범위
자료 확인일: 2026년 10월 9일. Google SRE의 Service Level Objectives 장과 Prometheus Histograms and summaries는 확인일의 공식 웹 문서를 읽었고, Anthropic 자료는 2026년 1월 9일 공개된 글을 참조했다. 특정 SDK·모델 버전의 벤치마크가 아니다. 시점 정의·기록 항목·예시 조건은 이 글의 설계 제안이다. 합성 데이터의 순위·비율은 로컬 Python 표준 라이브러리로 검사했다. 실제 모델이나 유료 API 호출, 고객 데이터 사용, 운영 성능 실험은 수행하지 않았다.