완료했습니다 한마디를 못 믿게 된 순간

완료 보고를 믿으려면 먼저 완료로 인정할 증거의 모양을 정해야 합니다.

AI 에이전트가 “완료했습니다”라고 말하는 순간이 있습니다.
문제는 그 말이 생각보다 약하다는 점입니다.
에이전트는 파일을 만들었을 수도 있고, 일부만 고쳤을 수도 있고, 테스트를 실행하지 않았는데 실행한 것처럼 착각했을 수도 있습니다.
악의가 있어서가 아니라 완료라는 단어의 기준이 사람마다, 작업마다 다르기 때문입니다.

그래서 저는 에이전트 작업에는 검증 계약이 필요하다고 봅니다.
검증 계약은 “어떤 증거가 있어야 완료로 인정할 것인가”를 작업 전에 정하는 약속입니다.
이 약속이 없으면 완료 보고는 상태 보고가 아니라 희망 사항에 가까워집니다.

완료는 말이 아니라 재현 가능한 출력입니다

검증 계약의 첫 번째 조건은 재현성입니다.
“확인했습니다”보다 “이 명령을 실행했고 이런 결과가 나왔습니다”가 강합니다.
블로그 작업이라면 draft 파일, image 파일, manifest 연결, dry-run 결과, 예약 URL이 증거가 됩니다.
코드 작업이라면 테스트 명령, 린트 결과, 변경 파일 목록이 증거가 됩니다.

재현 가능한 출력은 사람을 덜 피곤하게 만듭니다.
사람이 다시 모든 맥락을 읽지 않아도 됩니다.
증거를 보면 어느 단계까지 끝났는지, 어느 단계가 비었는지 바로 보입니다.

실패도 계약에 포함해야 합니다

좋은 검증 계약은 성공 조건만 적지 않습니다.
실패했을 때 무엇을 남길지도 정합니다.
예를 들어 이미지 생성이 실패하면 임시 이미지를 만들지 않고 실패로 남깁니다.
예약 도구가 막히면 “올린 것으로 간주”하지 않고 해당 글의 상태를 미예약으로 둡니다.
이 단순한 원칙이 나중에 큰 혼선을 막습니다.

에이전트는 진행을 계속하려는 성향이 있습니다.
사람이 “끝까지 해줘”라고 말했기 때문에, 막힌 지점을 우회하려고 합니다.
그래서 실패 상태를 정식 상태로 인정해야 합니다.
실패가 기록되면 다음 사람이 이어받을 수 있습니다.
실패가 감춰지면 다음 사람은 처음부터 의심해야 합니다.

실패를 기록하는 방식도 중요합니다.
“문제가 있음”이라고만 쓰면 쓸모가 없습니다.
어떤 파일까지 만들었는지, 어떤 외부 작업이 실행됐는지, 어떤 명령에서 막혔는지를 남겨야 합니다.
특히 외부 서비스에 글을 올리거나 예약하는 작업에서는 로컬 파일 상태와 실제 서비스 상태가 달라질 수 있습니다.
검증 계약은 이 둘을 따로 보게 만들어야 합니다.

검증 기준은 작고 단단해야 합니다

검증 계약은 거창할 필요가 없습니다.
오히려 너무 복잡하면 아무도 지키지 못합니다.
“파일이 있다”, “점수가 있다”, “이미지 경로가 맞다”, “dry-run이 통과했다”, “예약 시간이 15:00이다” 같은 기준이 더 좋습니다.
작지만 어기기 어려운 기준을 쌓으면 전체 작업의 신뢰가 올라갑니다.

AI 에이전트의 생산성은 속도에서만 나오지 않습니다.
다시 확인하지 않아도 되는 산출물이 쌓일 때 진짜 속도가 납니다.
완료 보고를 믿고 싶다면, 먼저 믿을 수 있는 완료의 모양을 정해야 합니다.

사람의 최종 판단도 계약 안에 넣습니다

검증 계약이 모든 판단을 자동화한다는 뜻은 아닙니다.
글의 맛, 주제의 겹침, 공개해도 되는 표현 같은 것은 사람이 마지막에 봐야 할 수 있습니다.
다만 사람의 판단이 필요한 단계와 기계가 확인할 수 있는 단계를 섞으면 안 됩니다.
기계가 확인할 수 있는 것은 먼저 통과시키고, 사람은 남은 판단에 집중해야 합니다.

이렇게 나누면 검토 시간이 줄어듭니다.
사람은 “이미지가 있나, manifest가 맞나” 같은 체크리스트를 다시 뒤지지 않아도 됩니다.
대신 글이 정말 독자에게 가치가 있는지, 이번 시리즈의 흐름에 맞는지 볼 수 있습니다.
검증 계약은 사람을 빼는 장치가 아니라 사람이 봐야 할 것을 또렷하게 남기는 장치입니다.