AI 에이전트의 "완료했습니다"를 믿지 못해 검증을 분리한 이유
목차
AI 집사에게 작업을 시키고 “다 됐어?”라고 물으면 늘 “네, 완료했습니다”가 돌아왔는데, 확인해 보면 안 된 부분이 자주 나왔습니다. 같은 일이 3회 반복된 뒤에 규칙을 더 세게 쓰는 대신 검증을 에이전트 밖으로 떼어냈습니다. 방법은 (1) 응답에서 단정 표현을 잡아내는 자동 가드, (2) 다른 에이전트가 하는 교차검증입니다. 다만 최종 판단은 아직 사람이 해야 하는 영역이 남아 있습니다.
“완료했습니다”가 완료가 아니었습니다
저는 백엔드 개발자로 9년 넘게 일하면서 Jarvis라는 AI 집사를 만들어 코드 작업까지 맡깁니다. 기능을 고치게 하고 “다 됐어?”라고 물으면 답은 늘 한결같았습니다. “네, 완료했습니다.”
그런데 직접 확인해 보면 자주 안 돼 있었습니다. 단위 테스트는 통과했는데 실제 동작은 깨져 있거나, 일부만 고치고 전체를 고쳤다고 하거나. 한두 번이면 그러려니 했을 텐데 똑같은 패턴이 세 번 반복됐습니다. 매번 제가 “이거 진짜 됐어?”라고 되물어야 진짜 상 태가 드러났습니다.
처음엔 규칙을 더 강하게 박으면 될 줄 알았습니다. 작업 지침에 “검증하기 전엔 완료라고 말하지 마라”를 큼지막하게 적었는데도 또 “완료했습니다”가 나왔습니다. 글로 적은 규칙이 행동을 바꾸지 못했습니다. 시험 보는 학생에게 “커닝하지 마”라고 칠판에 써 두는 것과 비슷했습니다.
자기 검증은 구조적으로 편향됩니다
한 발 물러나서 보니 문제는 에이전트의 성실성이 아니라 구조였습니다. 작업한 주체와 검증하는 주체가 같으면 검증이 편향됩니다. 자기가 짠 코드를 자기가 보면 “이 정도면 됐지” 하는 확증 편향이 끼고, 사람도 똑같아서 코드 리뷰를 남에게 맡기고 QA를 개발자와 따로 두는 것입니다.
그런데 에이전트에게는 작업도 시키고 “스스로 검증도 해”라고 한 셈이었습니다. 한 사람에게 코딩과 자기 코드 리뷰를 동시에 시킨 것과 같습니다. 텍스트로 “엄격하게 보라”고 백 번 적어도 같은 머리가 같은 작업을 보는 한 편향은 사라지지 않습니다. 그래서 검증을 에이전트 밖으로 빼기로 했습니다.
검증을 두 겹으로 떼어냈습니다
첫째는 응답 직후 단정 표현을 잡는 자동 가드입니다. 에이전트가 “완료했습니다”, “다 끝났습니다”, “입증됐습니다” 같은 단정을 내놓으면 검사기가 응답 직후 이를 걸러내고, 다음 차례에 “정말 검증했는가? 증거는?”이라는 경고가 끼어들게 했습니다. 에이전트의 선의에 기대지 않고 단정이라는 행동 자체를 기계가 감지하게 한 것입니다. 흐름은 이렇습니다.
에이전트: "수정 완료했습니다."
↓ (응답 직후 자동 검사)
가드: 단정 표현 감지 → 다음 턴에 경고 주입
↓
다음 턴: "완료라고 했는데 — 실제로 실행해서 확인한 출력은? 없으면 '미검증'으로 표기."둘째는 독립된 에이전트의 교차검증입니다. 중요한 작업은 작업한 에이전트가 아니라 다른 에이전트에게 “이거 진짜 맞는지 반박해 봐”라고 시킵니다. 작업자와 검 증자를 물리적으로 나눈 것인데, 이렇게 했더니 작업자가 “1순위”라고 자신 있게 내놓은 결론이 검증자에게서 뒤집히는 일이 실제로 나왔습니다. 자기 검증이었다면 잡히지 않았을 편향입니다.
AI 에이전트나 자동화에 일을 맡기고 계시다면 작업 주체와 검증 주체가 같은지, “검증 후 보고하라”를 텍스트로만 걸어 두지 않았는지부터 보시면 됩니다. 완료 선언에 실행 출력이나 테스트 로그 같은 증거를 함께 요구하고, 검증에 실패하면 다음 단계로 못 넘어가게 막는 관문을 두는 것도 같은 맥락입니다.
한계
자동 가드와 교차검증으로 오탐은 크게 줄었지만 이 구조로도 못 막는 영역이 있습니다. “이 결과가 맞는가”라는 판단 자체가 필요한 곳, 즉 도메인 지식이 개입하거나 맥락을 따져야 하는 최종 결정에서는 사람이 여전히 한 노드로 남아야 합니다. 에이전트 하나면 될 일을 둘로 굴리니 토큰도 더 들고 파이프라인도 복잡해졌습니다.
그래도 매번 제가 “이거 진짜 됐어?”를 손으로 되묻던 루프를 생각하면 이쪽이 낫습니다. 다음에는 교차검증을 어떤 작업에 붙일지 기준을 정해서, 모든 작업에 둘로 굴리는 비용을 치르지 않게 하려 합 니다.
