당신은 AI 에이전트(AI agent)를 구축했습니다. 추론(reasoning)은 견고합니다. 당신의 평가 스위트(eval suite)는 에이전트가 각 작업에 적합한 도구를 선택하고, 논리적으로 도구들을 연결하며, 잘못된 단계에서 복구하는지 확인합니다. 점수는 높습니다. 당신은 이를 배포합니다.

3일 후, 한 고객이 에이전트가 성공적인 응답을 반환했지만 아무런 작업도 수행하지 않았다고 말합니다. 로그에는 오류가 없습니다. 하지만 당신의 모니터링 시스템은 이상 징후를 포착합니다. 입력 토큰(input tokens)은 완전히 정상적으로 보였으나 출력 토큰(output tokens)이 0으로 떨어졌습니다. 당신의 평가(evals)가 포착할 기회조차 없었던 침묵의 실패(silent failure)입니다.

이것은 당신의 평가 전략에 구멍이 난 것이 아닙니다. 이는 완전히 다른 범주의 문제입니다.

평가(Evals)는 통제된 환경에서 추론(reasoning)을 테스트합니다. 적절한 도구를 선택하는가? 도구들을 올바르게 결합하는가? 무언가 잘못되었을 때 복구하는가? 대부분 그렇습니다. 왜냐하면 에이전트가 새로운 컨텍스트(fresh context), 깨끗한 입력값(clean input), 그리고 주의를 분산시킬 다른 요소가 없는 상태에서 실행되기 때문입니다.

신뢰성 스택(reliability stack)은 동일한 에이전트가 실제 세상에 풀렸을 때 어떤 일이 발생하는지를 테스트합니다. 에이전트가 결정한 내용을 실제로 실행했는가? 출력이 모델이 주장한 내용과 일치하는가? 도구가 실패했을 때 조용히 루프(loop)를 돌았는가? 이것들은 추론(reasoning)에 관한 질문이 아닙니다. 이것들은 런타임(runtime)에 관한 질문이며, 평가(evals)는 이를 답변하기 위해 만들어진 것이 아닙니다.

평가(Evals)가 놓치는 것들

평가(Evals)는 거의 이상적인 조건 하에서 실행됩니다. 새로운 컨텍스트(fresh context), 알려진 입력값(known inputs), 당신이 모킹(mocked)한 대로 동작하는 도구들, 그리고 하나의 깨끗한 실행 경로(execution path)가 보장됩니다.

프로덕션(Production)은 이 중 그 어느 것도 보장되지 않는 환경에서 실행됩니다. API는 무작위로 타임아웃(time out)됩니다. 실행 도중에 속도 제한(Rate limits)이 발생합니다. 실제 사용자들은 당신의 학습 데이터(training data)가 한 번도 본 적 없는 것들을 보냅니다. 수백 번의 실행을 거치며 컨텍스트(Context)는 팽창합니다. 그리고 때때로 에이전트는 실패하는 도구 호출(tool call)을 오류로 로그에 남기지 않은 채, 그저 조용히 반복해서 재시도할 뿐입니다.

이에 대한 구체적인 사례는 다음과 같습니다. 당신의 평가(eval) 테스트가 API에서 사용자 데이터를 가져와 요약하는 에이전트를 테스트한다고 가정해 봅시다. 테스트는 깨끗하게 통과합니다. 하지만 프로덕션(production) 환경에서 어느 날 해당 API가 느려집니다. 타임아웃(timeout)이 발생하고, 모델은 이를 호출 실패로 읽고 재시도(retry)를 결정합니다. 그리고 또 재시도합니다. 30번의 시도와 120,000개의 토큰(token)을 소모한 끝에, 에이전트는 포기하고 아무것도 반환하지 않습니다. 하지만 기술적으로는 아무런 오류가 발생하지 않았기 때문에, 과정 내내

에이전트나 평가(Eval) 스위트를 다시 구축할 필요는 없습니다. 대신 실행(execution) 자체에 대한 가시성(visibility)이 필요합니다. 모든 실행 시 토큰(tokens), 지연 시간(latency), 비용(cost), 그리고 출력 길이(output length)를 기록할 수 있도록 LLM 클라이언트를 래핑(wrap)하세요. 기준점(baselines)을 파악할 수 있을 만큼 충분히 오래 실행하십시오. 기준점에서 벗어나는 현상이 발생하면 알림을 설정하세요. 어떤 도구(tools)가 실제로 호출되었는지, 그리고 도구 호출이 실패했을 때 어떤 일이 발생했는지를 기록하십시오.

평가(Evals)와 신뢰성 스택(reliability stack)은 서로 경쟁하는 관계가 아닙니다. 하나는 에이전트가 사고할 수 있음을 증명하고, 다른 하나는 그 사고 과정이 프로덕션(production) 환경과의 접점에서도 살아남을 수 있음을 증명합니다.