AI 에이전트의 '완료' 정의: Paperclip 라이브니스 모델과 검증 설계

핵심 메시지

• 에이전트가 테스트를 통과하고 '완료'라고 표시해도, 병합·배포·고객 공지에 충분한 '완료'인지는 전혀 다른 문제다.
• '완료'는 참/거짓의 불리언이 아니라 산출물·근거·검증 기준·책임자·다음 단계·남은 위험을 담은 하나의 객체로 다뤄야 한다.
• 에이전트는 인간이 검증할 수 있는 속도보다 빠르게 작업을 만들어내므로, 사람이 전부 확인하면 결국 '검증 연극'에 그친다.
• 좋은 제어 평면은 생산적 작업의 지속, 실제 블로커만 작업 중단, 무한 루프의 제한이라는 세 불변식을 강제해야 한다.
• 저자와 검증자를 분리하고(예: Claude로 작성하면 Codex로 검증), 에이전트에 스크린샷·브라우저 같은 실제 증거 수집 도구를 줘야 한다.

쉽게 이해하기

발표자 도타(Dotta)는 에이전트가 풀 리퀘스트를 열고 테스트를 통과시키고 문서를 갱신한 뒤 '완료된 것 같다'고 댓글을 다는 상황을 예로 든다. 하지만 그것이 병합할 만큼, 배포할 만큼, 고객에게 알릴 만큼 완료됐는지는 근본적으로 다른 주장들이다. 대부분의 에이전트 시스템은 이 모두를 하나의 초록색 체크 표시로 뭉개 버린다.

그는 '프로그래밍은 사실상 해결됐고', 이제 에이전트가 사람이 검증할 수 있는 속도보다 더 많은 코드와 문서를 만들어내는 새로운 실패 양식이 생겼다고 말한다. 따라서 에이전트가 스스로 체크박스를 누르는 것 이상으로 '정말 끝났는지'를 검증할 방법이 필요하다. '완료'라는 말은 산출물이 만들어졌고, 완료를 뒷받침할 증거가 있으며, 그것을 대조할 기준(루브릭)이 있고, 다음 단계의 책임자와 그 다음 할 일이 명확하다는 여러 주장의 묶음이다.

핵심 긴장은 '작업을 계속 진행시키는 것(라이브니스)'과 '검증'을 함께 지키는 데 있다. 사람이 검증하면 정확성은 보장되지만 작업이 멈춘다. 반대로 승인 없이 무한정 진행만 하면 품질 관리가 없는 이른바 'AI 슬롭'이 쌓이고, 그렇다고 모두 동료 검토를 걸면 사람이 손으로 감당할 수 없는 거대한 검토 대기열이 생긴다.

Paperclip은 이 문제를 다루는 여러 장치를 갖췄다. 모든 작업에는 다음 상태로의 명확한 전이가 있고, 작업 간 블로커를 일급 개념으로 두어 제어 평면이 이를 강제한다. 명시적으로 검토자와 승인자를 지정할 수 있고, 사람의 선택은 감사 추적으로 남는다. 또 '워치독'이라는 최대화 모드 에이전트가 목표가 달성될 때까지 다른 에이전트들이 계속 일하도록 강제하는데, 이 워치독은 Pi·Claude Code·Codex 등 어떤 하니스에도 얹을 수 있도록 하니스 비의존적으로 설계됐다.

발표자의 결론은 '완료를 불리언이 아니라 객체로 다루라'는 것이다. 작업마다 완료의 정의를 명확히 하고, 검증자를 저자와 분리하며(종종 다른 모델 사용), 에이전트에게 '끝났냐'고 묻는 대신 브라우저 하니스·스크린샷·커스텀 도구 같은 증거 수집 수단을 제공하라. 그리고 각 에이전트가 끝난 뒤 누구에게 일을 넘길지 아는 명확한 인수인계 사슬을 갖추라고 조언한다.

주요 인사이트

• '완료'를 단일 초록 체크로 뭉개는 순간, 병합 가능·배포 가능·공지 가능이라는 서로 다른 운영상 주장이 구분 불가능해진다.
• 에이전트가 검증 가능한 속도보다 빠르게 산출물을 만들면, 사람이 전부 사인오프하는 방식은 실질적 품질 보증이 아니라 형식적 '검증 연극'이 된다.
• 라이브니스(멈춤 없는 진행)와 검증(정확성 보장)은 상충하므로, 둘의 균형을 강제하는 제어 평면·프로토콜이 for 루프식 단순 반복보다 필요하다.
• 저자와 검증자를 다른 모델로 분리하면(작성은 Claude, 검증은 Codex 등) 자기 확신 편향을 줄일 수 있다.
• 에이전트에게 결과를 말하게 하지 말고 증거를 만들게 하라. 브라우저로 직접 버튼을 눌러 보게 하는 등 검증 도구를 코드로 제공하는 것이 핵심이다.

자주 묻는 질문

관련 AI 소식