엔지니어에게 에이전트의 실패 모드(failure modes)를 나열해 달라고 요청하면 환각(hallucinations), 잘못된 도구 호출(tool calls), 잘못된 JSON 등에 대해 듣게 될 것입니다. 하지만 _시간_에 대해 물으면 그들은 어깨를 으쓱할 뿐입니다. 그럼에도 불구하고 프로덕션 에이전트가 잘못되었을 때 발생하는 가장 흔한 현상은 크게 실패하는 것이 아니라, 단지 너무 오래 걸리는 것입니다. 루프를 돌거나, 불안정한 도구를 재시도하거나, 첫 번째 토큰을 전혀 스트리밍하지 않는 모델 호출을 기다립니다. 그리고 결국 나타난 출력물에 대해 사후에 실행되는 여러분의 평가 스위트(eval suite)는 이를 '통과(green)'로 채점합니다.

이것이 바로 사각지대입니다. 우리는 지연 시간(latency)을 정확성과 분리된 SRE 대시보드의 문제로 취급합니다. 하지만 에이전트에게 마감 시간(deadline)을 놓치는 것은 곧 정확성 실패(correctness failure)입니다. 90초 늦게 도착한 요약은 요약이 없는 것보다 나쁜 경우가 많습니다. 사용자는 이미 떠났고, 다운스트림 작업(downstream job)은 이미 타임아웃되었으며, 재시도로 인해 사용자에게 비용이 이중으로 청구되었을 수도 있기 때문입니다. 시간은 여러분의 평가(evals)에 포함되어야 하며, 스택의 가장 밑바닥에 위치해야 합니다.

시간은 Tier 1 증거입니다

agent-eval의 티어 교리(tier doctrine)를 따라오셨다면, 증거가 비용 축이 아닌 독립성(independence) 축에 따라 순위가 매겨진다는 것을 알고 계실 것입니다. 즉, 에이전트가 위조할 수 없는 증거부터 에이전트와 동일한 기질(substrate)을 공유하는 의견까지 나뉩니다. 세 가지 티어는 다음과 같습니다:

• Tier 1 — 에이전트가 속일 수 없는 외부 관찰 가능한 증거: 유효한 JSON, 파일 존재 여부, 코드 컴파일 성공, 테스트 통과, 마감 시간 내 완료, 출력이 비어 있지 않음.
• Tier 2 — 에이전트가 작성하지 않은 기준점(baseline)에 대한 통계적 신호: 작업과의 임베딩 유사도(embedding similarity), 길이 및 반복성, diff가 실제로 무언가를 변경했는지 여부.
• Tier 3 — 모델 기반 판사(model-as-judge): 동일한 기질을 공유하는 의견. 이는 신호(signal)일 뿐, 결론(verdict)은 아닙니다.

"타임아웃 내에 완료됨(finished within the timeout)"이 어디에 위치하는지 주목하십시오. 이는 "유효한 JSON(valid JSON)" 바로 옆인 Tier 1에 있습니다. 이는 우연이 아닙니다. 벽시계 마감 시간(wall-clock deadline)은 당신이 가질 수 있는 가장 독립적인 신호입니다. 에이전트는 스톱워치와 논쟁할 수 없고, 스톱워치를 넘어서 추론할 수 없으며, 스톱워치를 조작할 수도 없습니다. 물리학이 이를 판정합니다. 당신의 전체 평가 스위트(eval suite)에서 "시간이 다 되었다"보다 더 부패할 수 없는 그라운드 트루스(ground truth)는 없습니다.

그리고 결정적으로, Tier 1+2는 당신의 **실시간 게이트(real-time gate)**입니다. 결정론적(deterministic)이며, 비용이 거의 들지 않고(~$0), 핫 패스(hot path)에 위치하여 *실행을 차단(block a run)*할 수 있을 만큼 충분히 빠릅니다. 타임아웃 체크는 그것의 가장 순수한 표현입니다. 정의상 이미 핫 패스에 포함되어 있기 때문입니다. Tier 3인 판사(judge)는 그 반대입니다. 계량화되고, 느리며, 비결정론적이고, 오프라인에서만 작동합니다. 응답이 충분히 빨랐는지 결정하기 위해 모델 기반 판사(model-as-judge)를 크리티컬 패스(critical path)에 절대 두지 않을 것입니다. 판사는 시계조차 볼 수 없습니다.

"그린 등급(graded green)"의 실제 모습

여기에 함정이 있습니다. 대부분의 평가 하네스(eval harnesses)는 (input, output)을 받아 출력값을 점수화합니다. 여기서 output은 에이전트가 최종적으로 반환한 무엇이든을 의미합니다. 따라서 구조적으로 점수 매기기가 시작되기 전에 타이밍 정보는 이미 폐기된 상태입니다. 평가는 실행이 마감 시간을 넘겼다는 사실을 문자 그대로 볼 수 없습니다. 왜냐하면 그 정보는 실행이 끝난 후에야 존재하기 때문입니다.

당신은 반환 값(return value)이 아니라 *실행(run)*을 평가해야 합니다:

type RunResult<T> =
  | { status: "ok"; value: T; elapsedMs: number }
  | { status: "timeout"; elapsedMs: number; deadlineMs: number }
...

이제 평가 게이트는 사소하고 결정론적입니다. 마이크로초 단위로 실행되는 Tier 1 체크입니다:

function tier1TimingGate(run: RunResult<unknown>): { pass: boolean; reason?: string } {
  if (run.status === "timeout") {
    return { pass: false, reason: `deadline miss: ${run.elapsedMs}ms > ${run.deadlineMs}ms` };
...

시간 초과(timed-out)된 실행은 결코 Tier 2나 3에 도달하지 못합니다. 임베딩할 것도, 판단할 것도 없습니다. 너무 늦게 도착한 정답은 정답이 아닙니다. 당신은 회로를 차단(short-circuit)하고, 실행을 차단하며, 폴백(fallback)합니다. 어떤 의견도 필요하지 않았기에, 어떤 모델에게도 의견을 묻지 않았습니다.

마감 시간은 에이전트 기준이 아니라 예산(budget) 기준입니다

그다음으로 흔히 보이는 실수는 단일한 전역 타임아웃(global timeout)을 설정하는 것입니다. 마감 시간은 맥락적(contextual)입니다. 백그라운드 재인덱싱(reindex) 작업은 10분이 걸릴 수 있지만, 대화형 채팅 턴(interactive chat turn)은 사용자가 지연을 느끼기 전까지 아마 3초 정도의 시간이 있을 것입니다. 마감 시간은 에이전트의 속성이 아니라 호출 지점(call site)의 속성입니다. 이를 작업 계약(task contract)의 일부로 스레드(thread)화하여, 모든 도구 단계(tool step)가 공유된 예산을 상속받고 차감하도록 하십시오. 그러면 예산의 80%를 사용하는 도구는 모델이 실제로 응답할 여유를 남기지 않게 되며, 이것 또한 평가 가능한(gradeable) 이벤트가 됩니다.

기록하지 않은 시간은 평가할 수 없습니다

이 모든 것은 단계별로 경과 시간(elapsed time)을 실제로 캡처했다는 것을 전제로 합니다. 여기서 평가(eval) 이야기의 절반은 나머지 절반을 필요로 합니다. 에이전트 평가(agent-eval)가 점수를 매기고 출력을 제어하려면, 무언가가 타이밍을 기록했을 때만 Tier 1 타이밍 게이트(timing gate)를 강제할 수 있습니다. 그것이 바로 트레이스 캡처(trace capture)의 역할입니다. AgentLens는 에이전트의 궤적(trajectory)—해결된 입력(resolved inputs), 가공되지 않은 출력(raw outputs), 그리고 시작/종료 타임스탬프를 포함한 모든 모델 호출 및 도구 단계—를 계측(instruments)합니다. 따라서 "마감 시간 내에 완료됨"은 누군가가 기록하기를 바라는 숫자가 아니라, 에이전트가 직접 작성할 수 없는 위조 불가능한 트레이스(trace)에서 읽어낼 수 있는 사실이 됩니다.

이러한 결합이 핵심입니다. 트레이스(trace)는 Tier 1+2 등급의 기질(substrate)이 됩니다. AgentLens는 에이전트가 자신이 수행했다고 주장하는 내용과 무관하게 각 단계가 시작되고 종료된 시점을 독립적으로 기록하기 때문에, 귀하의 타이밍 게이트(timing gate)는 실제 근거(ground truth)를 갖게 됩니다. 에이전트는 자신이 "빠르게 응답했다"라고 환각(hallucinate)할 수 있습니다. 하지만 자신이 작성하지 않은 트레이스의 타임스탬프(timestamp)를 수정할 수는 없습니다. 이것이 Tier 1+2에서 지루한 실패 사례의 80%(오래된 응답, 충돌, 빈 응답, 너무 느림)를 결정론적으로 잡아내는 평가(eval)와, 1분 늦게 결승선을 간 모든 실행을 조용히 숨겨버리는 초록색 체크표시 대시보드 사이의 차이점입니다.

주관적인 20%(톤, 유용성, "이것이 실제로 질문에 답했는가")를 위해서는 판사(judge)를 남겨두되, 이를 증거가 아닌 의견으로 분류하십시오. 하지만 스톱워치는 어떻습니까? 그것은 증거입니다. 그것을 최우선으로 두십시오.