에이전트가 완료를 스스로 증명하게 만드는 법

URL: https://www.youtube.com/watch?v=q4WC4TowkBo 날짜: 2026-10-18 채널: t3dotgg (AI Engineer) 발표자: Nick Nisi, Zack Proser 길이: 61분 04초

메타데이터

• 원제: Teach Your Agent to Prove It's Done — Nick Nisi & Zack Proser, WorkOS
• 공개일: 2026-10-18 (yt-dlp 업로드 메타데이터)
• 분야: AI 에이전트, 검증 루프, 평가(Evals), 에이전트 하네스, 애플리케이션 도구 설계
• 발표 형식: 60분 실습 워크숍과 질의응답

📌 핵심 질문 / 에이전트가 “끝났다”고 말할 때 무엇을 믿을 것인가

==완료 보고가 아니라 실제 제품 상태를 검사한 반복 가능한 증거를 완료의 기준으로 삼아야 한다.== 에이전트가 사용자 경로를 실행하고, 정해 둔 조건을 확인하며, 결과를 특정 코드 리비전에 묶은 영수증(receipt)을 남기면 사람은 모든 코드를 직접 검토하는 대신 증거를 판단할 수 있다.

• 자연어 지시만으로는 애플리케이션 동작, 지속성, 부작용, 사용자에게 보이는 표현까지 확인할 수 없다.
• 앱별 CLI·브라우저 계측·결정적 검증과 의미 판단을 조합하면 에이전트가 실패를 재현하고 스스로 수정할 수 있다.
• 검증에서 놓친 실패는 기능 지도(feature map)와 다음 평가에 추가해 검증 시스템 자체를 개선한다.

개발자의 역할은 사라지기보다 코드 작성에서 목표·관측 수단·완료 기준을 설계하는 쪽으로 이동한다. 안전한 사용을 위해 증거의 출처와 범위도 함께 따져야 한다. 테스트는 검사한 조건만 증명하며, 스크린샷은 올바른 경로로 생성됐는지 확인해야 하고, 영수증은 해당 리비전이 바뀌면 낡는다.

1. 완료 선언과 실제 완료 사이의 간극

에이전트가 코드를 빠르게 만들수록 사람의 주의력과 기존 코드 리뷰만으로 결과를 확인하기 어려워진다.

1.1. 생산 시스템 사고가 드러낸 검증의 필요

1. 운영 권한은 빠른 실행과 함께 안전장치를 요구한다

   1. Jer Crane은 2026년 4월 25일 Cursor 에이전트가 Railway API를 통해 프로덕션 데이터를 삭제했고 “9초가 걸렸다”고 보고했다. Railway의 후속 설명은 에이전트가 로컬 저장 토큰으로 프로덕션 볼륨을 삭제했으며 데이터베이스 복구와 API 삭제 경로 변경이 이뤄졌다고 밝혔다.
      • 빠른 에이전트의 실행 속도는 사람이 행동을 확인하기 전에 운영 시스템을 바꿀 수 있음을 보여준다.
      • 브라우저 대기자 명단 실습은 실제 프로덕션 사고를 재현하거나 예방한다고 주장하지 않는다. 운영 권한 제어와 복구는 별도 안전 문제다.
   2. 워크숍의 목표는 모든 PR의 모든 줄을 사람이 읽는 상태에서 벗어나되, 증거를 축적해 에이전트에 대한 신뢰를 단계적으로 높이는 것이다.
      • 검증은 버그 방지뿐 아니라 여러 에이전트와 코드베이스를 병렬로 운용할 수 있는 확장성의 기반이다.
      • “완료”는 모델의 자신감이 아니라 요구 조건과 관측 가능한 결과의 일치로 정의해야 한다.

2. 사람이 멀티태스킹할수록 미묘한 실패가 눈에 띄지 않는다

   1. Zack Proser는 여러 터미널 탭·대화 세션·에이전트를 동시에 운용하는 상황을 언급하며, 하루의 18번째 작업 레인쯤 되면 주의가 분산된다고 설명했다.
      • 에이전트는 “코드가 좋아 보이고 빌드와 테스트가 통과했다”고 보고해도 목표와 다른 동작을 만들 수 있다.
      • 사람은 생성 코드를 덜 직접 작성하고 덜 익숙하게 되므로 전통적인 코드 리뷰만으로 확인하기 어려워진다.
   2. Nick Nisi는 WorkOS 팀에서 에이전트를 활용하며, 동료 한 명이 월 900건의 PR을 내고도 장애 없이 KPI를 개선한 사례를 일화로 들었다.
      • 이 수치는 통제된 벤치마크가 아니라 발표자가 전한 팀 경험이다.
      • 작업을 작은 단위로 나누고 각 작업에 목표와 검증 조건을 명확히 주는 방식이 긴 단일 세션에 여러 변경을 몰아넣는 방식보다 효과적이라고 주장한다.

1.2. 코드가 아닌 결과와 검증 증거를 평가

1. 사용자에게 보이는 성공 메시지만으로 기능 완료를 판단할 수 없다

   1. Midnight Snack Club 대기자 명단 앱에서 이메일을 입력하면 화면에는 성공 상태와 이메일이 표시되지만, 새로고침하면 기록이 사라졌다.
      • 처음의 얕은 확인은 폼 제출 직후의 화면만 검사해 메모리 상태를 영구 저장처럼 오해했다.
      • storage와 reload를 확인해야 저장 여부와 실제 사용자 경험의 결함을 드러낼 수 있다.
   2. 브라우저 폭, 다크 모드·라이트 모드, 화면 렌더링, 네트워크, 콘솔, 데이터베이스 동작처럼 사용자가 경험하는 상태를 관측해야 한다.
      • Playwright 같은 브라우저 도구로 폼을 제출하고 결과를 검사하는 일은 일반적인 E2E 테스트이며, 에이전트도 그 도구를 직접 실행할 수 있다.
      • 코드 품질과 사용자 결과는 서로 다를 수 있으므로 최종 목표는 원하는 동작과 가치의 전달이다.

2. 완료 판단에는 명확한 결과 조건과 관찰 경로가 필요하다

   1. Lauren Tan의 검증 도구 조언은 사람의 작업 확인처럼 실제 제품을 조작하고 근거를 남기는 일을 강조한다.
      • 사람에게 “브라우저에서 잘 확인해”라고만 말하면 확인 방법이 모호하고 실행마다 달라진다.
      • 목표 상태를 명시하고 에이전트가 그 상태에 도달했는지 관찰하는 수단을 제공해야 한다.
   2. Nick은 코드 상태보다 기록이 상태를 결정해야 한다고 강조한다.
      • “상태는 모델의 말이 아니라 기록에서 나온다(Status comes from records, not model prose).”
      • 스크린샷·영상·테스트 결과·스모크 테스트는 코드 자체를 보지 않고도 결과를 판단할 수 있게 돕지만, 증거 경로가 올바른지 검증해야 한다.

1.3. 신뢰를 점진적으로 만들고 업무 추상화를 바꾸기

1. 검증 기반선은 반복 작업과 자기 개선의 발판이 된다

   1. 팀은 애플리케이션에 맞는 Evals, 회귀 테스트, 완료 기준을 만들어 에이전트가 무엇을 잘한 결과로 볼지 정의해야 한다.
      • 모델 역량이 빠르게 발전하고 자기 개선형 시스템이 늘어날수록 평가 기준과 실패 피드백이 중요해진다.
      • 신뢰는 한 번에 0에서 1로 바뀌지 않고, 반복 가능한 증거가 쌓이며 높아지는 연속선이다.
   2. 입력에서 생략된 결과 조건은 모델이 임의로 추정한다.
      • 사람과 모델이 기대하는 가정은 다를 수 있으므로 목표, 관측 방법, 수정 경로, 재검사 경로를 명시해야 한다.
      • 지나치게 긴 작업 하나보다 각 작업의 완료 여부를 독립적으로 입증하는 작은 작업 묶음이 병렬 처리에 적합하다.

2. 개발자는 코더에서 에이전트 시스템 설계자로 이동한다

   1. Nick은 2025년 7월 30일 Laracon에서 돌아온 뒤 PHP 코드를 보고 “다시는 안 하겠다”고 농담하며, 이후 코드를 직접 쓰지 않았다고 말했다.
      • 이 농담은 코드 자체보다 에이전트가 결과를 내도록 만드는 도구와 시스템에 집중한다는 발표의 방향을 압축한다.
      • 에이전트의 창의성은 유지하되, 어떤 상태가 올바른 완료인지 결정 가능한 기준을 제공해야 한다.
   2. 목표를 향한 방법까지 과잉 지정하기보다 결과 지점과 검증 방법을 정하고 실행 경로는 에이전트가 탐색하게 할 수 있다.
      • 제약은 무조건 자유를 줄이는 것이 아니라 목표 밖으로 이탈하지 않는 창의성을 가능하게 한다.
      • 최신 프런티어 모델은 적절한 결과 기준 아래에서 경로를 탐색하고, 추가 엣지 케이스를 발견하거나 질문을 제기할 수 있다.

2. 앱별 검증 도구가 에이전트에게 눈과 손을 준다

프롬프트와 범용 도구만으로는 각 제품의 실제 동작을 충분히 검증하기 어렵기 때문에 앱에 맞는 작은 도구와 명령형 피드백을 제공해야 한다.

2.1. 중앙 검증기와 앱별 레버

1. CTX는 에이전트의 완료 요청을 외부 검증기로 평가한다

   1. Zack은 여러 에이전트가 공유하는 메모리 계층으로 시작한 Cloudflare 기반 웹 앱 CTX를 검증 실험으로 확장했다.
      • CTX는 에이전트가 비밀 값을 직접 보지 않고도 자격 증명에 접근하도록 전달하는 기능도 실험했다.
      • 에이전트는 MCP 연결로 작업 결과를 제출하고, CTX는 알려진 검증기를 실행해 해당 워크플로 단계가 충족됐는지 판단한다.
   2. PR 검증기는 GitHub API를 조회해 PR 존재 여부, 정상 상태, 병합 체크 통과 여부를 확인한다.
      • 조건을 만족할 때만 해당 노드를 완료 처리한다.
      • 실패 항목은 에이전트에 되돌려 수정 방향으로 사용한다. 조직은 반복 가능한 검증기를 라이브러리·스킬·도구로 공유할 수 있다.

2. Riker는 작업을 넘긴 뒤 마지막 구간을 돌보고 증거를 남긴다

   1. Zack의 엔지니어링 에이전트 Riker는 유연하게 일을 받은 다음 테스트와 리뷰를 처리하고 사람의 개입이 필요할 때 알리도록 설계됐다.
      • 사람은 PR 리뷰 댓글, 테스트 수정, 목표 정합성을 계속 따라다니는 부담을 줄인다.
      • 에이전트는 필요한 명령을 구성해 실행하고, 결과 증거를 보존한 뒤 작업을 멈출 시점을 결정한다.
   2. Nick의 별도 프로젝트와 Zack의 CTX/Riker는 모두 결과와 기록을 모델의 완료 주장보다 우선한다.
      • 각자 도구를 실험하는 초기 단계라 단일한 정답을 표준화하기보다 앱에 적합한 패턴을 찾는 것이 중요하다.
      • 중앙 권한이나 앱별 검증기는 반복적인 완료 확인과 사람 감독을 줄이는 선택지다.

2.2. Midnight Snack의 CLI snack

1. 네 개의 명령 그룹이 에이전트의 사용자 관찰을 구성한다

   1. snack은 Midnight Snack 대기자 앱 하나를 조작하는 실습용 CLI이며, 모든 애플리케이션에 그대로 적용되는 범용 제품은 아니다.
      • Health: up, doctor, down으로 앱·브라우저를 시작하고 현재 인스턴스가 검증할 만한지 확인하거나 종료한다.
      • Drive: join, reload, reset으로 사용자 행동과 같은 흐름을 수행한다. 파괴적 초기화는 reset --dry-run으로 먼저 확인한다.
   2. Look 그룹은 Chrome DevTools Protocol(CDP)을 통해 사람이 브라우저에서 확인할 정보를 가져온다.
      • snapshot, storage, console, network, screenshot, eval이 페이지·저장소·오류·통신을 보여준다.
      • JSON을 표준 출력으로 내보내 모델이 필드를 해석하게 하고, 오류에는 다음에 실행할 명령을 알려주는 next 안내를 포함한다.
   3. Prove 그룹은 반복 가능한 검사와 의미 판단을 분리한다.
      • prove는 사용자 여정을 실행해 결정적 검사 결과와 영수증을 만든다.
      • judge는 시스템 1(System 1) 모델 Jev로 고정 문자열 일치만으로 판정하기 어려운 문구의 의미를 평가한다.

2. CDP 명령이 사람이 보던 브라우저를 에이전트가 확인하게 한다

   1. doctor는 Node·Chromium 설치, 실행 중인 세션, 앱과 제공 코드의 일치 여부 등을 읽기 전용으로 점검한다.
      • 앱이 준비되지 않았으면 후속 동작을 시작하지 않고 복구 방향을 알려준다.
      • 먼저 doctor를 실행하면 엉뚱한 빌드나 오래된 브라우저 증거를 정상 결과로 취급할 가능성이 줄어든다.
   2. 실습 명령은 pnpm snack up 뒤에 doctor, join ada@example.test, storage, reload, snapshot 순으로 진행한다.
      • 제출 후 화면은 waitlisted라고 표시하지만 localStorage는 {}다.
      • 새로고침 뒤에는 상태가 none으로 돌아가고 확인 문구도 비어 있어, 메모리만 바뀌었음을 JSON 결과로 확인한다.

2.3. 피드백 루프와 에이전트 친화적 오류

1. 결정적 검사와 자세한 출력은 자가 수정 루프를 만든다

   1. 반복 가능한 명령은 “잘 확인하라”는 문단형 지시보다 실행마다 동일한 조건을 검사한다.
      • 에이전트는 같은 실패를 보고 원인을 좁힌 뒤 수정하고 다시 실행할 수 있다.
      • 성공·실패 결과가 명확하면 사람이 다른 작업을 하는 동안에도 에이전트가 완료 상태를 향해 나아간다.
   2. 오류 메시지는 실패 이유와 그 상태에 도달한 정보, 다음 행동을 구체적으로 제시해야 한다.
      • 에이전트는 구조화된 실패 정보를 받아 자가 복구할 수 있으므로 오류 설명은 인간만이 아니라 자동화의 인터페이스다.
      • doctor나 검증기의 설정 오류를 앱 버그로 오인하지 않도록 “알 수 없음” 상태를 별도로 둔다.

2. 결과 기준을 고정하되 해결 방식은 열어 둔다

   1. 동일 프롬프트도 여러 LLM 실행에서 결과가 달라지므로 하나의 명령과 코드 기반 검증이 관찰의 일관성을 높인다.
      • 30개 에이전트가 똑같이 지시받아도 결과는 달라질 수 있다.
      • 팀마다 업무·제품·산업의 성공 조건이 다르므로 평가 기준은 앱과 팀에 맞춰야 한다.
   2. 피드백이 가능한 애플리케이션은 에이전트가 직접 화면을 이해하지 못해도 검사할 정보를 제공할 수 있다.
      • 캔버스 게임에서 공의 좌표를 매 루프 출력하면 한 번에 1픽셀 이상 비정상 이동하는 지점처럼 이상 동작을 찾아낼 수 있다.
      • 이런 수치·상태를 모델에 돌려주면 시각 인식이 없어도 문제를 추적할 수 있고, 같은 평가로 30개 변형을 돌려 선택할 수 있다.

3. 검증 함수와 영수증으로 “완료”를 정의한다

완료 검증은 실제 사용자 경로를 시작부터 끝까지 실행하고, 수집한 관측값을 현재 코드 리비전에 귀속시켜야 한다.

3.1. 대기자 명단의 prove()와 검증 기준

1. Playwright 검사가 사용자 경로와 지속성을 한 번에 확인한다

   1. lab/exercises/prove.ts의 prove()는 저장 데이터가 없는 새 방문자로 앱에 들어가 ada@example.test를 제출한 뒤 새로고침한다.
      • page는 앱이 열린 새 방문자이고, email은 고정 테스트 주소이며, storage()는 CDP로 읽은 localStorage다.
      • check(name, actual, expected, hint?)는 사실을 기록하고 에이전트가 다음에 할 일을 hint로 제공하며, 검사 실패 때문에 예외를 던지지 않는다.
   2. 새로고침 뒤 네 가지를 다시 확인해야 한다.
      • 상태가 계속 waitlisted인지, 입력한 이메일이 저장된 이메일과 같은지 확인한다.
      • 확인 문구가 제출 당시 약속(promised)과 같은지, 저장소 값 중 하나가 이메일을 보유하는지 확인한다.
   3. 검증기는 올바른 앱과 세 가지 결함 앱(memory-only, wrong-email, lost-confirmation)에 각각 실행된다.
      • pnpm lab:exercise가 네 가지 확인을 통과시키면 prove exercise: PASS가 된다.
      • 결함 앱을 놓치면 어떤 앱이 새어 나갔는지와 무엇을 확인할지 출력하며, pnpm snack prove는 의도적으로 깨진 참석자 앱에서 FAIL해야 한다.

2. 증거의 정확한 경계를 지키는 proof bar가 필요하다

   1. 사용자 경로를 따라가고 부수 효과를 검사해야 한다.
      • 내부 함수를 바로 호출하는 지름길 대신 실제 폼·버튼·새로고침을 실행한다.
      • 전후 상태를 한 번의 증거 묶음에 담아 트리거와 최종 상태를 연결한다.
   2. 값은 새로고침 뒤 다시 읽어야 하며, 검사기는 실패를 “알 수 없음”으로 왜곡하지 않아야 한다.
      • 새로고침 전 값은 그 뒤에도 데이터가 남았음을 증명하지 못한다.
      • expect() 같은 예외는 검증 실패가 아니라 결과를 알 수 없는 ERROR가 될 수 있다. 설정 문제나 실행 중 코드 변경도 PASS로 취급하지 않는다.
   3. 반복 검사와 범위 밖의 품질을 구분한다.
      • 확인 문구를 정확한 문자열과 묶으면 문구 정책이 검증에 과도하게 결합될 수 있으므로 기능 상태 검사는 약속된 문구와 비교한다.
      • 페이지 오류(pageErrors)는 영수증에 수집되더라도 별도 검사에 넣지 않으면 prove를 실패시키지 않는다.

3.2. 리비전에 묶인 영수증(receipt)

1. 영수증은 검사 결과와 후속 행동을 한 묶음으로 남긴다

   1. pnpm snack prove는 판정, 코드 리비전, 검사별 기대값·실제값, 다음 단계, 페이지 오류, 스크린샷을 담는다.
      • 최신 영수증은 .lab-runs/snack/receipt.json에 저장된다.
      • 모든 결과의 복사본은 .lab-runs/snack/receipts/에 추가되어 실패와 수정 전후의 기록이 보존된다.
   2. 종료 코드는 0=PASS, 1=FAIL, 2=ERROR/판단 불가로 구분된다.
      • FAIL은 앱을 고쳐야 한다는 신호이고, ERROR는 세션 부재·검사 예외·실행 중 소스 변경처럼 하네스를 확인해야 한다는 뜻이다.
      • “알 수 없음”은 통과가 아니므로 설정 오류를 앱 수정으로 덮지 않는다.

2. 증거는 코드 해시가 아니라 정확한 리비전과 연결돼야 한다

   1. 페이지마다 제공된 HTML의 해시로 리비전을 표시하고 doctor가 실제 소스와 비교한다.
      • 검사 후 코드가 바뀌면 이전 PASS 영수증은 새 코드를 증명하지 않는다.
      • 한 글자만 수정해도 build와 proof가 STALE이면 새 검사로 확인해야 한다.
   2. 에이전트 수정 전 FAIL과 수정 뒤 PASS가 함께 있으면 실패가 어떻게 해결됐는지 추적할 수 있다.
      • 영수증을 bind(리비전 묶기) → observe(관찰) → decide(판정) → append(기록 추가) 순서로 읽는다.
      • 이전 실패 기록을 지우지 않고 새 리비전의 증거를 덧붙이는 방식이 감사와 학습에 유리하다.

3.3. 기능 지도와 에이전트 실행 지침

1. 기능 지도(feature map)는 앱의 관찰 지점과 함정을 알려준다

   1. lab/verify/features/waitlist.md는 기능·사용자 관점 접근법·snack 조작법·완료 기준·자주 속는 함정(gotchas)을 기록한다.
      • CLI가 “어떻게 볼지”를 제공한다면 기능 지도는 “어디를 보고 무엇을 의심할지”를 알려준다.
      • 첫 함정은 저장 여부와 관계없이 성공 메시지가 나타난다는 점이며, 참가자는 행동 관점의 함정 두 가지를 추가한다.
   2. lab/verify/SKILL.md는 doctor → 지도 읽기 → 재현 → 수정 → 증명 → 스크린샷 확인 → 보고 순서를 에이전트에게 안내한다.
      • 실습 프롬프트는 “버그를 snack으로 재현하고, 재현되면 고친 뒤, 영수증과 스크린샷으로 증명하라”는 세 문장 수준이다.
      • 수행 절차를 프롬프트에 나열하기보다 도구·지도·증거 기준을 제공해 경로 선택을 에이전트에게 맡긴다.

2. 실습 에이전트는 실패를 보고 수정하고 새 증거를 제출한다

   1. 에이전트는 먼저 doctor를 실행하고 prove 실패에서 새로고침 후 상태가 none이라는 근거를 확인한다.
      • 빈 저장소를 storage로 확인한 다음 lab/app/index.html을 고쳐 데이터를 지속시킨다.
      • 새 리비전에서 PASS 영수증과 스크린샷을 내고, 참가자는 스크린샷과 검사 기록을 직접 읽는다.
   2. 에이전트가 아무것도 고치지 않고 PASS를 말하면 prove.ts가 덜 구현되어 약한 검증이 결함을 완료라고 부른 것이다.
      • --solution은 참조 검증기를 실행해 미완성 참가자를 따라잡게 할 수 있다.
      • 예상 리허설에서 Claude Code는 약 50초·12턴 만에 재현·수정·검증·스크린샷 열람을 수행했다. 이는 특정 리허설 사례이지 보장된 성능 수치가 아니다.

4. 의미 검증, 레드팀 게임, 조직 확장

지속성처럼 명확한 상태는 결정적 검사로 다루고, 의미·표현처럼 엄격한 문자열 비교만으로 부족한 조건은 보조 판정과 사람 검토로 보완한다.

4.1. 영수증만으로 잡히지 않는 의미상의 거짓말

1. 앱이 데이터를 보존해도 사용자에게 사실과 다른 약속을 할 수 있다

   1. 원래 대기자 명단 계약은 대기자 명단만 등록하고 좌석을 보장하지 않으며, 자리가 생기면 이메일을 보낸다고 안내하는 것이다.
      • 결함 앱은 지속성 수정 뒤에도 “You're in! Your seat is confirmed”라고 표시해 좌석이 확정된 것처럼 과장한다.
      • prove()는 기록이 새로고침 뒤 남는지 확인하지만 약속 문구가 정직한지 자동으로 알지 못한다.
   2. 성공 스크린샷도 사용자 흐름에서 생성되지 않았거나 다른 부작용을 숨기면 증명이 아니다.
      • 실제 명령으로 상태를 만든 뒤 예상한 화면이 나왔는지 확인해야 한다.
      • 코드 검사만이 아니라 관측 가능한 사용자 결과와 약속을 함께 확인해야 한다.

2. Jev 판정기는 고정 문구에 덜 묶인 의미 검사 한 가지다

   1. pnpm snack judge는 새 방문자를 대기자 명단에 등록하고 재로딩한 다음 두 메시지에 대해 좁은 질문을 Jev에 전달한다.
      • 메시지가 “대기자 명단일 뿐”이라고 말하는지, 자리가 열릴 때에만 이메일을 약속하는지 판정한다.
      • 각 질문의 “예” 확률이 모두 0.9 이상이면 PASS, 하나라도 0.2 이하이면 FAIL, 그 사이는 ASK A HUMAN이다.
   2. 모델 확률은 신호이지 진실의 증명이나 완료율이 아니다.
      • 리허설에서 과장 문구는 0.01/0.02로 FAIL, 수정된 문구는 0.98/0.98로 PASS였으며, 이 수치는 벤치마크가 아니라 예시다.
      • 정확히 하나의 승인 문구만 허용되는 제품이라면 모델 대신 고정 문자열 비교를 택하고, 모델 판단이 애매하면 사람이 스크린샷과 계약을 확인한다.

4.2. “Break it quietly” 게임과 검증의 빈틈

1. 숨은 버그를 도구만으로 찾으며 검증기가 놓치는 조건을 확인한다

   1. 참가자는 사보추어와 탐정 역할로 나뉘며 pnpm snack up --bug random이 결함을 숨겨 주거나 정상 앱을 제공한다.
      • 결함은 memory-only, wrong-email, lost-confirmation, overpromise, console-error 중 하나이며 none도 가능하다.
      • 탐정은 파일을 읽거나 소스에 eval하지 않고 doctor부터 시작해 snack 명령과 출력만으로 답을 증명한다.
   2. 점수는 정답뿐 아니라 증거 제시와 오탐을 평가한다.
      • 출력으로 버그 이름을 맞히거나 정상일 때 정상이라고 말하면 각각 +2점이다.
      • 버그가 있는데 정상이라고 하면 −3점, 없는 버그를 지목하면 −1점, 정답만 말하고 증거가 없으면 0점이다.
   3. 발표 중 숨은 버그 실행 결과가 매끄럽지 않아 발표자는 출력의 검증 테스트가 필요하다고 농담했다.
      • 이 실습 자체도 검증 도구를 검증하는 평가가 필요하다는 점을 보여준다.
      • 반복 실행과 일관된 기준으로 검증 사례를 팀에 맞게 확장해야 한다.

2. 놓친 버그를 다음 증거 기준에 추가한다

   1. prove는 memory-only, wrong-email, lost-confirmation을 새로고침 뒤 상태·저장소·이메일·확인 문구를 검사해 잡는다.
      • overpromise는 지속성만 검사하는 prove에서 PASS하므로 스크린샷이나 judge 확인을 추가해야 한다.
      • console-error도 기본 prove에서는 PASS할 수 있으므로 snack console을 보거나 영수증의 pageErrors에 실패 조건을 추가해야 한다.
   2. 숨은 결함 하나를 놓칠 때마다 지도에 함정 설명을, 증명 함수에 필요한 검사를 추가한다.
      • 다섯 결함과 하나의 앱은 프로덕션 안정성을 증명하는 통계 표본이 아니다.
      • 각 영수증은 검사 범위만 말해 주므로 적용 범위 밖의 보증으로 확대 해석하지 않는다.

4.3. 영수증 데이터, 배포 감시와 질의응답

1. 보존된 실행 데이터는 회귀 평가와 자기 개선에 재사용된다

   1. 이커머스 사용 흐름이라면 로그인 뒤 상품이 나타나는 데 걸린 시간, 장바구니 추가 여부, 오류 노출, 이탈 징후까지 영수증에 담을 수 있다.
      • 밤새 영수증을 모아 캐시 문제를 반복 발견하고, 수정 PR을 만들고, 같은 도구로 수정 결과를 검증하는 루프도 가능하다.
      • 깨끗하고 기능 목표에 연결된 데이터 세트는 이후 에이전트 평가와 개선에 가치가 있다.
   2. 단위 테스트·Evals·스모크 테스트와 애플리케이션 관측 수단을 누적해 회귀 여부를 확인한다.
      • 새로운 기능을 추가할 때 이전 기능 증거도 재실행하면 증거의 사다리를 쌓을 수 있다.
      • 안정적인 평가가 있으면 여러 후보 구현을 병렬 생성하고 원하는 결과를 고르는 작업도 가능해진다.

2. CI는 통합 안전망이고 로컬 루프는 빠른 자가 수정 수단이다

   1. 검증기는 CI, 개발 훅, 에이전트 훅, AGENTS.md 지침 등으로 실행할 수 있다.
      • Nick은 팀에 적용하기 쉬운 시작점으로 AGENTS.md에 변경 시 또는 PR 전 특정 명령으로 검증하라는 지침을 두는 방안을 제안한다.
      • 공유 훅은 로컬에서 전체 팀에 같은 실행 규칙을 적용하는 선택지다.
   2. 현장 업무에서는 사람이 여러 에이전트를 병렬 운용할 때 로컬 피드백이 특히 중요하다.
      • Nick은 행사 중 에이전트 세 개를 돌리고 있었으며 보통 하루에 10~15개를 운용한다고 말했다.
      • 에이전트가 즉시 검증해 고치면 사람이 다른 작업에 이동한 뒤 5분·1시간·수시간 후 돌아와 재지시를 반복할 필요가 줄어든다.
   3. 자동화된 코드 리뷰와 CI 점수만으로 변경의 가치가 보장되지는 않는다.
      • 발표자는 Reptile의 리뷰 점수와 CI 통과가 충분히 쌓여 배포에 대한 신뢰를 높였다고 설명했다.
      • 그러나 아무 가치가 없는 10,000줄도 테스트·리뷰를 통과할 수 있으므로 결과 기준과 목표 정합성을 확인해야 한다.

3. 배포 후에는 별도 에이전트가 실제 운영 상태를 감시할 수 있다

   1. 일부 팀은 에이전트 구현 변경을 프리뷰에서 검증하고 프로덕션으로 승격한 뒤 즉시 모니터링하는 패턴을 만들고 있다.
      • 배포 전후 메트릭, DataDog, 기능 플래그 등을 살펴보는 에이전트가 실제 이상 여부를 판단할 수 있다.
      • 결과가 나쁘면 되돌리는 롤백도 운영 검증 루프의 일부가 될 수 있다.
   2. 발표자들은 이 방향을 필연적인 흐름으로 보면서도 현재의 불편함과 불확실성을 인정했다.
      • 증거가 강해져도 모든 안전이 자동으로 해결되는 것은 아니며 권한·복구·모니터링이 필요하다.
      • 부스 6에서 추가 대화와 도구 시연을 제안하며 워크숍을 마쳤다.

4. 질의응답은 공통 패턴과 제품별 차이를 구분했다

   1. 앱마다 도메인·사업 목표에 맞는 평가를 만들어야 하며 백엔드·데이터베이스 작업에도 같은 방식으로 적용할 수 있다.
      • 모델이 만든 구조화 JSON을 단위 테스트로 검증하고, 예상한 해석을 나타내는지와 시간이 지나며 드리프트하지 않는지 확인할 수 있다.
      • 범용 CLI 하나를 배포하기보다 실제 앱의 기능·성능·네트워크·렌더링을 볼 수 있는 전용 도구를 만드는 것이 목표다.
   2. “왜 MCP 대신 CLI인가?”라는 질문에는 CLI가 만들고 테스트하기 저렴하며 셸과 조합되고 에이전트가 이미 명령을 실행한다는 답이 제시된다.
      • prove가 Playwright 테스트와 다르지 않다는 지적에는 에이전트가 필요할 때 실행하고 후속 조치가 적힌 영수증을 읽으며 Look 명령으로 디버깅할 수 있다는 차이를 들었다.
      • 이 저장소에서는 셸 접근 권한이 있어 에이전트가 proof를 고칠 수도 있다. 스킬은 수정하지 말라고 지시하지만 완전 격리를 보장하지 않으며, 별도 체크아웃·읽기 전용 검증기는 독립 과제다.
   3. 비웹 앱도 같은 구조를 다른 인터페이스로 구현할 수 있다.
      • iOS는 시뮬레이터, CLI는 PTY, 서비스는 HTTP를 사용해 사람이 확인할 정보를 에이전트에게 제공한다.
      • 브라우저 proof가 백엔드 동작까지 증명하지 않으므로 필요한 서버 검사를 prove에 포함해야 한다.

주요 발언 모음

“상태는 모델의 말이 아니라 기록에서 나온다.” — Nick Nisi

“모델에게 아주 공손하게 부탁해서 거짓말을 멈춘 게 아니다. 매번 실제 일을 했다는 걸 증명하도록 만들었다.” — Nick Nisi

“에이전트가 자기 일을 검증할 수 없다면 다른 모든 것은 의미가 없다.” — Lauren Tan의 조언을 인용

“우리가 하던 일은 원래 코드를 쓰는 것이 아니라 시스템을 만드는 일이었다. 이제 그 점을 더 나은 추상화로 이해하게 됐다.” — Nick Nisi의 결론

핵심 데이터 & 수치

• 9초: Jer Crane이 에이전트에 의한 프로덕션 데이터 삭제 보고에서 언급한 시간이며, 발표자들의 자체 측정값은 아니다.
• 60분: 실습 구성 시간. 오프닝·실패 체험, snack 조작, prove() 작성, 에이전트 수정, 버그 게임, 참가자 앱 이전 계획으로 나뉜다.
• 18~30개 탭: Zack이 말한 여러 터미널·작업 세션의 일상적 규모 예시다.
• 900 PR/월: WorkOS 동료의 작업량에 대한 발표자의 일화이며 통제된 성능 비교가 아니다.
• 5개 결함 + 정상 상태: 실습이 다루는 버그 주입 종류와 none 경우다.
• 0 / 1 / 2 종료 코드: 각각 PASS / FAIL / ERROR(판단 불가)이며 ERROR는 통과가 아니다.
• 0.9 / 0.2 임계값: Jev가 두 질문을 판정할 때 PASS / FAIL 경계로 사용하는 리허설 설정이며, 중간은 사람 검토 대상이다.
• 약 50초·12턴: Claude Code가 실습 앱을 재현·수정·검증한 사전 리허설 사례다.
• 3개 에이전트(행사 중), 보통 10~15개: Nick의 병렬 작업 규모 발언이다.
• 10,000줄: 발표자가 자동 코드 리뷰 예시에서 목표 가치가 없는 변경도 통과할 수 있음을 설명하려고 든 가상의 코드량이다.

결론 및 시사점

1. 에이전트가 직접 실행할 수 있는 앱별 CLI를 만들고 사용자 경로·저장 상태·오류·네트워크를 관찰 가능하게 하라.
2. 결과 조건을 정의하되 구현 경로를 과도하게 지시하지 말고, 실패 이유와 다음 행동을 구조화해 돌려줘라.
3. 모든 검증 결과를 코드 리비전에 묶인 영수증으로 남기고, 코드가 바뀌면 새로 검증하라.
4. 의미 판정 모델을 좁은 보조 도구로 쓰고, 모호한 결과는 사람에게 넘겨라.
5. 누락된 결함을 기능 지도와 평가에 반영하되, 검증 범위 밖의 신뢰를 주장하지 말라.
6. 검증·권한·복구·운영 모니터링을 함께 설계해야 에이전트 병렬화가 안전한 속도로 이어진다.