05. 증거로 검증 루프 돌리기

목표

검증 실패를 단순 재시도로 소비하지 않고, 원인을 분류해 다음 변경을 선택하며 멈출 조건을 정합니다.

핵심 설명

검증 루프는 같은 요청을 여러 번 보내는 과정이 아닙니다. 상태 확인 → 최소 변경 → 검증 → 증거 해석을 거치며, 매번 새 근거가 다음 판단을 바꾸어야 합니다.

검증은 위험에 맞게 층을 나눕니다. 문법과 정적 검사는 빠른 오류를 찾고, 단위·통합 테스트는 동작 계약을 확인하며, 빌드는 실제 산출 가능성을 봅니다. 브라우저 확인은 레이아웃, 키보드 조작, 로딩·실패 상태처럼 코드만으로 놓치기 쉬운 결과를 확인합니다. 마지막으로 diff를 읽어 범위와 안전 경계를 검토합니다.

실패를 발견하면 제품 코드 문제, 테스트 기대값 문제, 환경 문제, 요구의 모호함으로 먼저 분류합니다. 근거 없이 같은 수정을 반복하지 않습니다. 성공 조건이 모두 충족되면 완료 후보가 됩니다. 권한이나 정책 판단이 필요하면 사람 판단 필요, 검증할 환경이 없으면 미완료입니다. 루프가 멈췄다는 사실과 작업 성공은 다릅니다.

체크리스트

• 각 검증이 어떤 완료 조건을 확인하는지 알고 있습니다.
• 정상뿐 아니라 실패와 재시도 경로를 확인했습니다.
• UI 작업은 실제 화면과 키보드 조작을 확인했습니다.
• 실패 원인을 코드, 테스트, 환경, 요구 중 하나로 우선 분류했습니다.
• 수정 전후의 증거가 남아 있습니다.
• 성공, 안전한 중단, 사람 승인 필요를 구분했습니다.
• 같은 실패가 반복되면 새 근거 없이 계속 시도하지 않습니다.

직접 해보기

관찰한 상태:
실행한 검증:
결과와 근거:
원인 가설:
다음 최소 변경:
멈출 조건:

문의 폼 예시에서는 첫 요청이 끝나기 전에 submit 이벤트를 두 번 발생시키고 모의 API 호출 횟수를 확인합니다. 실패 응답 뒤 입력값과 잠금 상태를 확인한 다음 다시 제출해 새 요청이 한 번 발생하는지도 봅니다.

완료 근거

• 작업 브리프의 모든 완료 조건에 대응하는 결과가 있습니다.
• 실행한 명령과 실제 화면 확인을 다시 재현할 수 있습니다.
• 부정 경로와 복구 동작을 확인했습니다.
• diff 검토에서 범위 밖 변경과 비밀값 노출이 없습니다.
• 남은 위험과 사람이 판단할 항목이 분리되어 있습니다.

Prompt, Context, Harness, Loop가 한 시스템으로 연결되는 예시는 프롬프트에서 루프까지에서도 확인할 수 있습니다.

다음은 검증에서 얻은 결정을 보존하는 06. 결정과 학습 남기기입니다.