// verification_ladder_definition

검증 사다리란 무엇인가

에이전트와 사람이 함께 일할 때, 누가 무엇을 확인할지 미리 정하는 협업 방식입니다. AI 에이전트에게 일을 맡기고 "완료했습니다"라는 말만 받으면, 정작 무엇을 확인했는지는 모호하게 남습니다. 검증 사다리는 이 확인 작업을 4단계로 나눠, 에이전트가 맡을 부분과 사람이 맡을 부분을 명확히 구분합니다.

⏱ 15초 요약

검증 사다리(Verification Ladder)는 에이전트와 사람이 확인 작업을 나눠 맡는 협업 구조입니다. 4단계(실행→결정적 검증→시나리오 검증→사람 검증) 중 앞의 세 단계는 에이전트가 매번 스스로 처리하고, 마지막 한 단계만 사람이 결정적 순간에 판단합니다. feature_list.jsonverification 칸이 이 역할 분담을 데이터로 구현한 형태입니다.

누구를 위한 개념인가 — PM 출신 창업자·1인 SaaS 창업자처럼, 개발팀 없이 AI 에이전트와 함께 일하며 "누가 무엇을 확인하는지"를 명확히 정하고 싶은 사람.

// 01 · metaphor주방에서 라인쿡과 헤드셰프가 일하는 방식과 같습니다

// METAPHOR

레스토랑 주방은 한 사람이 처음부터 끝까지 요리하지 않습니다

라인쿡이 재료를 준비하고, 레시피대로 조리하고, 접시에 담아 "나갑니다!"라고 외칩니다 — 여기까지가 라인쿡의 역할입니다. 그 다음, 헤드셰프가 접시를 한 번 훑어보고 손님 테이블로 보낼지 판단합니다. 라인쿡이 게을러서가 아니라, 애초에 두 역할이 다르기 때문입니다. 검증 사다리도 같은 구조입니다 — 에이전트가 0~2단계(재료 준비부터 맛까지)를 매번 스스로 확인하고, 사람은 3단계(손님에게 나가기 직전 최종 판단)만 맡습니다. 사람이 0단계까지 매번 확인하면 시간 낭비고, 에이전트가 3단계까지 혼자 결정하면 손님 앞에서 사고가 납니다.

// 02 · ladder검증은 사다리입니다 — 아래는 에이전트, 위는 사람

↓ 아래일수록 자주·에이전트가, 위일수록 드물게·사람이 확인합니다

0 실행 — 일단 켜지는가? (라인쿡: 재료 준비)
1 결정적 검증 — 정해진 규칙대로 됐는가? (라인쿡: 레시피대로 조리)
2 시나리오 검증 — 진짜 써보면 끝까지 되는가? (라인쿡: 직접 맛보고 플레이팅)
3 사람 검증 — 사람이 보고 "이거 맞다"고 하는가? (헤드셰프: 테이블로 보내도 될지 최종 판단)
단계쉽게 말하면누가 맡나요
0 — 실행앱이 켜지는가, 페이지가 열리는가npm run dev, 브라우저 새로고침에이전트매번
1 — 결정적 검증정해진 규칙대로 스스로 채점린트, 타입 체크, 자동 테스트에이전트매번
2 — 시나리오 검증진짜 사용자처럼 끝까지 눌러봄Playwright, 결제 테스트 카드에이전트매번
3 — 사람 검증디자인·톤·매출처럼 사람만 판단 가능한 것사람결정적 순간에

핵심 원칙: 0~2단계는 에이전트가 매번, 3단계는 사람이 결정적 순간에. 사람이 0단계까지 매번 확인하는 건 시간 낭비고, 에이전트가 3단계까지 혼자 결정하는 건 사고의 시작입니다. 역할을 명확히 나누는 것이지, 에이전트를 못 믿어서가 아닙니다.

"You can't delegate what you can't verify."

— Eugene Yan 현재 Anthropic Technical Staff. 이전에는 Amazon에서 Principal Applied Scientist로 추천 시스템·검색·요약 AI를 만들었고, Alibaba/Lazada에서는 VP of Machine Learning으로 일했습니다. LLM과 추천 시스템, 엔지니어링 실무를 다루는 글을 씁니다.

// 03 · comparison역할을 나누기 전과 후, 무엇이 달라지나요

차원역할 분담 없이 일할 때검증 사다리로 역할을 나눌 때
완료의 뜻 "됐어요" — 에이전트도 사람도 순간마다 다르게 해석 4단계 중 몇 단계까지가 에이전트 몫인지 미리 합의
문제 발견 시점 친구 앞 시연에서, 또는 배포하고 나서 — 사람이 뒤늦게 발견 기능을 마치기 전, 에이전트가 스스로 먼저
반복되는 부담 매번 사람이 처음부터 끝까지 다시 확인 검증 명령이 feature_list.json에 남아 에이전트가 다음에도 재사용
사람이 하는 일 0단계부터 3단계까지 전부 사람이 눈으로 확인 3단계, 진짜 판단이 필요한 순간에만 집중

// 04 · cases실제로 무너진 사례 3개

  • Lovable — "버튼 추가 완료": 데스크톱에서는 멀쩡했지만, AI는 한 번도 모바일 폭으로 자기 결과를 본 적이 없어 모바일에서 버튼이 화면 밖으로 밀려났습니다.
  • Cursor — "테스트 통과": 모든 테스트가 통과했다고 배포했는데, 프로덕션 첫 사용자 로그인에서 바로 깨졌습니다. 원인은 로컬에만 있던 환경변수였습니다.
  • Claude Code — "결제 흐름 구현 완료": 결제는 성공하고 DB에도 기록됐지만, 영수증 이메일이 발신 도메인 인증 미비로 스팸함에 빠졌습니다.

// 05 · rules에이전트와 사람이 나누는 3가지 역할 약속

  • 에이전트에게 일을 시키기 전에, 검증 명령부터 함께 적어두기. feature_list.jsonverification 칸이 비어 있는 기능은 아직 역할 분담이 안 된 기능입니다.
  • 에이전트가 통과시켰을 때만 state를 passing으로 인정하기. "완료"라는 말이 아니라, 검증 명령이 실제로 통과했는지가 기준입니다.
  • 사람 몫인 항목은 미리 표시해두기. 외부 발송, 라이브 모드 전환처럼 에이전트가 통과시켜도 사람이 마지막으로 봐야 하는 일은 처음부터 구분해둡니다.
근데 말이죠

검증 사다리를 4단계 다 안 밟아도 되는 때도 있어요

  • 사이드 프로젝트로 나만 쓰는 도구 — 사용자 노출이 없으면 3단계(사람 검증)는 생략해도 됩니다.
  • 한 번 쓰고 버리는 스크립트 — 1회성 작업은 검증 명령을 미리 적는 비용이 실행 비용보다 클 수 있습니다.
  • 이미 팀에 QA·코드리뷰 프로세스가 있는 경우 — 이 사다리는 그 프로세스가 없는 1인·소규모 팀을 위한 대체재입니다.

// 06 · faq자주 묻는 질문

AI가 완료했다고 하면 정말 믿어도 되나요?
대부분 '완료'는 코드를 생성했다는 뜻이지 동작을 확인했다는 뜻이 아닙니다. 검증 4단계 중 AI는 가장 아래 단계만 보고 완료를 선언하는 경우가 많습니다.
검증 사다리의 4단계는 무엇인가요?
0단계 실행, 1단계 결정적 검증, 2단계 시나리오 검증, 3단계 사람 검증입니다. 0~2단계는 기계가 매번, 3단계는 사람이 결정적 순간에 확인합니다.
feature_list.json과 검증 사다리는 어떤 관계인가요?
feature_list.json의 verification 칸이 검증 사다리 개념을 데이터로 구현한 형태입니다. 검증 명령이 실제로 통과해야만 state가 passing으로 바뀝니다.

지금 바로 해볼 수 있는 것

최근 1주일 안에 AI가 "완료했다"고 답한 작업 1개를 고르고, 그 검증 명령 한 줄을 사후라도 적어보세요. 한 줄이 안 나온다면, 그 작업은 아직 완료된 게 아닙니다.