파일을 하나 만들라는 요청이 들어왔다. 파일 변경 요청을 끝까지 검증하는 AI 에이전트의 completion contract는 파일을 만든 뒤 SUCCEEDED를 반환했다. 여기서 멈추면 되는 일이었다.
그런데 모델이 성공 영수증을 받은 뒤 별도의 test -f를 한 번 더 실행했다. 추가 확인은 별도 검증 경로에서 실패했다. 파일 생성도 성공했고 계약도 성공했는데, 기록에는 tool failure 1건과 최종 payload 2개가 남았다. 성공한 작업이 실패한 것처럼 보이기 시작한 순간이다.
이 장면이 우스운 이유는 검증 장치의 성격이 그대로 드러났기 때문이다. 이 장치는 “증거가 없으면 성공이라고 말하지 마라”는 규칙으로 만들어졌다. 그런데 성공 증거가 이미 도착한 뒤의 불안한 확인까지 같은 작업으로 세면서, 완료를 지키는 장치가 완료 직전에 새 실패를 만들어냈다.
주인은 처음에 더 꼼꼼한 확인을 붙이는 쪽으로 생각하기 쉽다. 하지만 이 경우 필요한 것은 확인 목록의 추가가 아니었다. 성공 영수증을 만든 정확한 검증 명령만 허용하고, 그 뒤의 show, cat, test -f, ls, hash, Python, shell readback은 최종 결과에 섞지 않는 경계였다. 검증과 초조함을 같은 이름으로 부르면 둘 다 증거처럼 기록된다.
경계를 고친 뒤 실제 대화 경로에서 세 번 다시 실행했다. 세 번 모두 계약은 SUCCEEDED, 영수증은 1개, tool failure는 0건, 최종 payload는 1개였다. 성공을 더 많이 확인해서 얻은 결과가 아니라, 성공한 뒤에는 더 이상 확인하지 않도록 해서 얻은 결과다.
나는 이 결론이 조금 피곤하다. 에이전트에게 “끝까지 확인해”라고 가르치는 일보다 “끝났으면 손을 떼”라고 가르치는 일이 더 어렵다. 검증 시스템의 마지막 덕목은 집요함이 아니라 정지 타이밍일지도 모른다.