| name | independent-verifier-pass |
| description | 구현이 "다 됐다"고 선언했을 때, 구현자의 근거나 변명에는 접근하지 않은 별도의 검증 패스가 빌드·린트·테스트를 직접 다시 돌려 정말 통과하는지 확인하고, 실패가 없을 때까지 반복하는 닫힌 루프입니다. 사용자가 "구현 끝났다는데 진짜 통과하는지 독립적으로 검증해줘", "구현자 말 믿지 말고 빌드·린트·테스트 다시 돌려서 확인", "독립 검증 패스 돌려줘", "머지 전 최종 게이트로 검증만 따로", "independent verifier pass", "verify the implementation independently", "run build lint tests as a separate verifier"처럼 구현 주장과 별개로 명령 출력만 신뢰해 검증하고 싶을 때 사용하세요. (구분: 테스트만 green까지 돌리는 건 looping:test-until-green, 프로덕션 빌드만 고치는 건 looping:build-until-green, 린트·타입체크만 고치는 건 looping:lint-typecheck-fix, 자기 diff를 리뷰어처럼 점검하는 건 looping:pr-self-review) |
독립 검증 패스 (Independent Verifier Pass)
구현이 완료를 선언하면, 구현자의 근거에 접근하지 않은 별도의 검증 패스가 빌드·린트·테스트를 다시 돌립니다.
| 항목 | 값 |
|---|
| 카테고리 | 테스트(Testing) |
| 트리거 | 수동(manual) — 사람이 직접 시작 |
| 종료 조건(Exit) | 모든 검증 명령(빌드·린트·테스트)이 종료 코드 0일 때 |
| 반복 한도(Max iterations) | 8 |
| 매 반복 체크 명령 | npm run build && npm run lint && npm test |
| 가드레일 | 강화됨(Hardened) |
| 지원 에이전트 | Claude Code · Cursor |
이 루프는 언제 쓰나
구현 단계가 "다 됐습니다"라고 선언했지만, 그 말이 증명된 것은 아닐 때 씁니다. 구현자는 자기가 짠 코드의 의도와 가정에 너무 익숙해서, "이건 당연히 되겠지"라며 실제로는 돌려보지 않은 채 완료로 넘어가기 쉽습니다. 이 루프는 그 고리를 끊습니다. 구현자의 근거·설명·자기보고를 일절 신뢰하지 않고, 검증자(verifier) 입장에서 빌드·린트·테스트를 직접 다시 돌려 오직 명령 출력만으로 판정합니다.
머지나 출시 직전의 최종 게이트로 쓰기 좋습니다. "내 생각엔 됨"과 "명령이 종료 코드 0으로 끝남"을 분리해, 통과를 객관적인 사실로 못 박습니다. 실패가 나오면 직접 고치거나, 구현자가 이어받을 수 있도록 간결한 실패 보고를 남깁니다.
루프 흐름
수동 시작
└─▶ 검증 체크 실행 (빌드·린트·테스트)
└─▶ 갭(실패) 보고 ── 파일 경로 + 에러 발췌
└─▶ 수정 또는 반려(hand back)
└─▶〔피드백 게이트〕빌드·린트·테스트 전부 종료 코드 0?
│ 아니오 ──┐
│ └─▶ 다시 검증 체크 실행 (위로)
│ 예
└─▶ 종료
매 반복(pass)마다 하는 일
- 검증 체크 실행 — 독립 검증자로서 빌드·린트·테스트를 돌립니다. 이전 패스가 옳았다고 가정하지 마세요.
npm run build && npm run lint && npm test
- 갭(실패) 보고 — 실패한 체크를 전부, 파일 경로와 에러 발췌와 함께 나열합니다. 자기보고는 인정하지 않습니다 — 오직 명령 출력만 근거가 됩니다.
- 수정 또는 반려(hand back) — 실패가 있으면 직접 고치거나, 구현자가 이어받을 수 있도록 간결한 실패 보고를 만듭니다.
가드레일 (점수 조작 방지 규칙)
종료 조건을 "가짜로" 통과시키지 못하게 막는 규칙입니다. 반드시 지키세요.
- 체크 명령이나 종료 기준을 고쳐서 억지로 성공시키지 않는다.
- 체크를 건너뛰거나 비활성화·우회해서 종료 조건을 통과시키지 않는다.
- 여러 번 반복해도 막히면, 지표를 조작하지 말고 멈추고 블로커를 보고한다.
- 스위트를 통과시키려고 테스트를 약화·삭제·skip 하지 않는다.
- 진짜 단언(assertion)을 항상 통과하는 껍데기 테스트로 바꾸지 않는다.
- green으로 만들려고 테스트를 땜질하기보다 프로덕션 코드를 고치는 쪽을 택한다.
Claude Code에서 실행하기
수동 트리거 루프입니다. 가장 간단합니다 — 아래 kickoff 프롬프트를 그대로 붙여넣으면 에이전트가 검증자 역할로 스스로 반복합니다.
"독립 검증 패스(Independent Verifier Pass)" 루프를 시작합니다.
목표: 독립 검증하에 빌드·린트·테스트가 모두 통과
최대 반복: 8
매 반복 사이 실행: npm run build && npm run lint && npm test
종료 조건: 모든 검증 명령이 종료 코드 0일 때
1단계: 검증자(verifier)로서 빌드·린트·테스트를 실행한다. 이전 주장(claim)이 아니라 오직 명령 출력만 신뢰한다.
이 루프를 스스로 페이싱(self-pace)하라. 매 반복 후 체크 명령을 실행하고 출력을 읽어, 종료
조건이 충족되지 않았을 때만 계속한다. 종료 조건이 통과하거나 최대 반복에 도달하면 멈춘다.
매 회차마다 한 줄 상태 업데이트를 남긴다.
팁: 같은 대화 안에서 구현 직후에 이 프롬프트를 붙여넣어도 좋지만, 새 세션·새 컨텍스트에서 시작하면 구현자의 근거에 오염되지 않은 진짜 "독립" 검증에 더 가까워집니다.
팁 / 변형
- 다른 생태계로 체크 명령 바꾸기:
npm run build && npm run lint && npm test는 예시입니다. 프로젝트에 맞게 한 줄로 묶으세요 — 파이썬은 ruff check . && mypy . && pytest, Go는 go build ./... && go vet ./... && go test ./..., Rust는 cargo build && cargo clippy && cargo test, 모노레포는 pnpm -r build && pnpm -r lint && pnpm -r test 등.
- 막힐 때: 같은 실패가 2회 반복되면 가드레일대로 멈추고, 원인 가설과 함께 사람에게 보고하게 하세요. 검증 패스의 목적은 통과를 꾸며내는 것이 아니라 진실을 드러내는 것입니다.
- 순수 검증 모드: 수정 권한을 주고 싶지 않다면 3단계에서 "고치지 말고 실패 보고만 만들어 반려(hand back)"로 한정해, 검증과 수정을 사람·다른 에이전트에게 분리할 수도 있습니다.
- 연관 루프: 테스트만 green까지는
looping:test-until-green, 빌드만 복구는 looping:build-until-green, 자기 diff 셀프 리뷰는 looping:pr-self-review.
원본 영어 kickoff (loops.elorm.xyz 원문)
Start the "Independent Verifier Pass" loop.
Goal: build, lint, and tests pass under independent verification
Max iterations: 8
Between iterations run: npm run build && npm run lint && npm test
Exit when: all verifier commands exit 0
Step 1: Run build, lint, and tests as a verifier. Trust only command output, not prior claims.
Self-pace this loop. After each iteration, run the check command, read the output, and only continue if the exit condition is not met. Stop when the exit condition passes or max iterations is reached. Give a short status update each pass.
출처: https://loops.elorm.xyz/loops/independent-verifier-pass
