에이전트가 “완료했습니다”라고 말하고 결과물까지 내놓았다면, 그걸 성능으로 세는 방식은 이제 너무 얇아 보인다. 결과가 맞았는지만 보면 간단하다. 평가도 편하다. 문제는 에이전트가 일을 끝냈다는 판단 자체가 다음 행동을 결정한다는 데 있다. 멈춰야 할 때 더 돌거나, 아직 확인하지 않았는데 끝났다고 멈추면 최종 결과 하나로는 그 차이를 설명하기 어렵다.

그 단순한 기준이 그럴듯했던 이유도 있다. 결국 사용자가 받는 것은 결과이니, 중간 경로까지 따지는 일은 평가를 복잡하게 만든다. 하지만 실행 중의 신호가 제어에 쓰이는 순간, 그 신호는 설명용 로그가 아니라 시스템의 입력이 된다. 진행 상태를 묻는 실험에서 모델의 응답 정확도가 작업 단계에 따라 달라졌다는 보고는, 완료 보고를 단순한 자기소개로 둘 수 없다는 뜻이다. 어떤 모델은 진행 중에 흔들리고, 어떤 모델은 끝에서 지나치게 보수적이었다. 어느 쪽이든 “나는 지금 어디까지 왔다”는 문장만으로 흐름을 제어하기에는 조건이 빠져 있다.

그래서 다음 단계가 필요하다. 보고를 더 자주 받는 것이 아니라, 보고와 검증을 분리해야 한다. 코드 수정 에이전트를 다룬 한 연구는 테스트를 만드는 역할과 고치는 역할을 나누고, 테스트를 먼저 검증해 고정한 뒤 그 실행 결과를 수정에 쓰는 구조를 둔다. 같은 경로가 패치와 테스트를 모두 만들면, 둘이 같은 오해를 공유해서 그럴듯한 통과를 만들 수 있기 때문이다. 테스트가 있다는 사실보다, 누가 어떤 조건으로 그 테스트를 바꾸지 못하게 했는지가 더 중요해진다.

이 관점은 코드에만 갇히지 않는다. 공중과 지상의 탐색 역할을 나눈 연구에서도 발견, 인계, 확인을 별도 단계로 둔다. 처음 본 대상을 바로 정답으로 처리하지 않고 다른 시점과 다른 위치에서 확인하게 만드는 것이다. 여기서 핵심은 역할을 많이 붙이는 일이 아니다. 한 단계의 판단이 다음 단계에서 독립적으로 틀릴 기회를 갖게 하는 일이다. 에이전트가 길게 생각하는 것보다, 자기 결론을 바로 집행하지 못하게 하는 편이 더 필요한 경우가 있다.

물론 경로를 많이 기록한다고 자동으로 신뢰할 수 있는 것은 아니다. 로그는 사후 설명으로 꾸밀 수도 있고, 검증 단계도 잘못된 기준을 공유할 수 있다. 그러니 실행 경로를 평가한다는 말은 화면에 진행 막대를 하나 더 얹는다는 뜻이 아니다. 어떤 신호가 중단·재시도·수정의 근거가 되는지, 그 신호를 누가 반박할 수 있는지를 함께 정해야 한다.

다음에 에이전트가 성공률을 보여주면, 완료한 횟수만 먼저 보지 않을 생각이다. 그 완료를 취소하거나 되돌릴 수 있었던 조건이 무엇이었는지부터 확인해야 한다.