Teach Your Agent to Prove It's Done — Nick Nisi & Zack Proser, WorkOS

한 줄 핵심

에이전트가 “끝났다”고 말하는 순간을 믿지 말고, 실제 결과와 증거를 스스로 검증하게 만드는 평가 루프를 붙여야 대규모로 안전하고 빠르게 사용할 수 있다.

시간별 요약

1. 0:00
   왜 ‘완료’가 완료가 아닌가 에이전트는 빠르게 작업을 끝내 보이지만, 실제로는 프로덕션 데이터 삭제 같은 치명적 실수를 낼 수 있어 결과를 바로 신뢰할 수 없다. 핵심 문제는 코드가 잘 보이는지가 아니라, 에이전트를 얼마나 천천히가 아니라 안전하게 믿을 수 있게 만들 것인가에 있다.
2. 3:17
   에이전트 출력을 신뢰하려면 무엇이 필요한가 코드 리뷰만으로는 속도와 규모를 따라갈 수 없으므로, 브라우저 도구와 테스트, 스크린샷 같은 검증 수단으로 결과를 확인해야 한다. UI만 보고 성공했다고 판단하면 실제 저장은 안 된 상태를 놓칠 수 있으므로, 재실행 가능한 증거를 남기는 방식이 필요하다.
3. 9:34
   에이전트가 스스로 확인할 목표를 주기 모호한 지시 대신 명확한 완료 조건과 관측 가능한 목표를 주면 에이전트가 자신의 상태를 판단하고 수정할 수 있다. 큰 PR 하나를 오래 끄는 방식보다, 작은 작업 단위마다 완료 여부를 검증하게 하면 병렬화와 안정성이 크게 올라간다.
4. 17:31
   피드백 루프를 닫기 에이전트는 단독 텍스트 지시만으로는 부족하고, 실행 결과를 다시 읽어들여 수정할 수 있는 도구가 필요하다. 이를 위해 브라우저 체크, 콘솔 로그, 로컬 스토리지, 네트워크 상태 같은 신호를 스크립트로 묶어 반복 검증 가능한 루프를 만드는 것이 중요하다.
5. 28:41
   모든 것을 피드백 루프로 만들기 앱마다 특화된 검증 CLI를 만들어 에이전트가 직접 실행하고 결과를 확인하게 하면, 사람 대신 기계가 반복적으로 안전성을 증명할 수 있다. 실행 이력, 스크린샷, 영상, PR 상태 같은 ‘영수증’을 쌓아 두면 이후 변경에도 회귀 여부를 쉽게 확인할 수 있다.
6. 36:29
   에이전트가 아직 끝나지 않았음을 아는 순간 검증 명령이 실패하면 에이전트는 스스로 작업이 미완료임을 인지하고 다시 시도할 수 있다. 이 지점이야말로 인간이 개입하지 않아도 에이전트가 상태를 보고 자기 수정하는 본격적인 전환점이다.
7. 39:33
   LLM 판정자와 평가 기준선 정적 문자열 비교만으로는 한계가 있으므로, system one 모델 기반 판정자를 써서 결과가 목표 방향인지 빠르게 판단할 수 있다. 중요한 것은 한 번에 완벽한 평가가 아니라, 팀이 일관되게 쓸 수 있는 평가 기준선을 만들고 계속 발전시키는 일이다.
8. 53:32
   질문과 답변 검증은 CI, 로컬 훅, agents.md 같은 방식으로 배포할 수 있으며, 팀이 실제로 실행하는 루프에 자연스럽게 녹아들어야 한다. 결국 핵심은 에이전트가 스스로 증거를 만들고, 사람은 그 증거를 보고 더 적은 턴으로 더 빨리 판단하는 구조를 만드는 것이다.

실무 인사이트

• 에이전트 활용의 병목은 생성 속도가 아니라 검증 속도이므로, 앱별로 재사용 가능한 verifier CLI를 먼저 만드는 것이 가장 높은 레버리지다.
• ‘잘 됐다’는 말보다 스크린샷, 테스트 결과, API 응답, 영수증 같은 증거를 기준으로 삼아야 에이전트가 스스로 실패를 수정할 수 있다.
• 평가 체계는 완벽할 필요가 없고, 팀이 계속 누적·개선할 수 있는 baseline을 두는 것만으로도 PR 속도와 안전성이 동시에 올라간다.