저는 한동안 에이전트형 AI (agentic AI) 시스템을 구축해 왔는데, 마침내 글을 쓰게 만들 정도로 저를 괴롭혔던 점은 우리의 전체 스택이 에이전트가 무엇을 했는지는 정말 잘 알려주지만, 그것이 맞았는지에 대해서는 거의 쓸모가 없다는 사실입니다.

관측성 (Observability) 도구는 트레이스 (trace), 모든 도구 호출 (tool call), 그리고 모든 토큰 (token)을 제공하며, 이는 무언가 고장 난 후 무슨 일이 일어났는지 파악하는 데 매우 유용합니다. 평가 (Evals)는 과거 어느 시점에 실행했던 테스트 세트에 대한 점수를 제공합니다. 하지만 프로덕션 (production) 환경에서, 그 순간에, 여러분의 에이전트가 자신감 있고, 잘 형성되었으며, 스키마가 유효한(schema-valid) 200을 반환할 때, 그 파이프라인 내의 그 어떤 것도 그 안의 답변이 실제로 정확한지 확인하지 않습니다. 200 응답은 자신만만하게 틀린 답변을 감쌀 수 있으며, 여러분의 대시보드는 여전히 초록색으로 빛날 것입니다.

이 문제가 실제로 얼마나 심각한지 확인하기 위해 작은 실험을 진행했습니다. 저는 저렴하고 약한 모델을 가져와서 정답을 확인할 수 있는 실제 구조화된 작업 (structured task)에 적용했습니다. 그 결과 모델은 실제로는 69%의 확률로만 정답을 맞혔지만, 겉보기에 맞은 것처럼 보이는 빈도는 그보다 훨씬 높았습니다. 그 다음, 각 출력을 단순히 그렇게 보이는 것이 아니라 실제로 제약 조건을 충족하는지 묻는 근거 기반 확인 (grounded check)으로 감싸고, 실패한 것들을 다시 생성 (re-roll)하게 했습니다. 결과는 100%로 올라갔습니다. 제가 계속 곱씹게 되는 부분은 모델이 결코 더 똑똑해지지 않았으며, 검증 (verification)이 모든 일을 해냈다는 점입니다.

그래서 제가 계속 되돌아오게 되는 결론은 일관성 (consistency)이 곧 정확성 (correctness)은 아니라는 것입니다. 스키마가 유효하고, 유창하며, 로그가 잘 남은 답변이라도 여전히 완전히 틀릴 수 있으며, 현대의 에이전트 스택 중 그 일이 일어나는 동안 이를 알아차리도록 설계된 것은 거의 없습니다.

저는 런타임 인증 레이어 (runtime certification layer)가 어떤 모습일지 고민해 왔습니다. 이는 200 로그가 남는 시점과 오프라인 평가 (offline evals)를 통과하는 시점 사이에 존재하며, 아무도 묻지 않는 것 같은 단 하나의 질문, 즉 '지금 이 특정 출력이 실제로 맞는가?'에 답하는 레이어입니다.

만약 여러분이 프로덕션에서 에이전트를 운영하고 있다면, 여러분은 이 문제를 어떻게 다루고 있는지, 아니면 그저 초록색 대시보드와 타협하며 지내고 있는지 진심으로 궁금합니다.