항상 Claude에게 자신의 작업을 검증할 수 있는 방법을 제공하세요. 테스트든, 빌드든, 스크린샷 비교든 상관없습니다. 세션은 엔지니어가 보기 전에 스스로 작업을 확인하고 실수를 수정합니다.
피드백 루프는 검증자 서브에이전트(3단계: 빌드)와 혼동해서는 안 됩니다. 피드백 루프는 작업에 필요한 만큼 전체 작업을 반복해서 실행합니다. 반면 검증자 서브에이전트는 세션이 작업이 완료되었다고 판단한 후 새로운 컨텍스트 윈도우를 실행하여 최종 점검을 패키징하는 한 가지 방법입니다. 이렇게 하면 판정이 코드를 생성한 가정에 의해 영향을 받지 않습니다.
달라지는 점
| 기존 방식 | AI 네이티브 |
|---|---|
| 코드가 작동한다는 신호는 늦게 도착합니다. CI는 몇 분 후, 테스터는 며칠 후, 프로덕션은 몇 주 후에나 신호를 줍니다. 에이전트가 코드를 생성하는 경우, 신호가 늦다는 것은 사람이 모든 출력을 확인해야 한다는 의미이며, 그 사람이 병목 지점이 됩니다. | 세션에게는 사람이 보기 전에 스스로 작업을 확인할 수 있는 방법이 주어집니다. 테스트를 실행하고, 빌드를 실행하고, 스크린샷을 찍습니다. Claude는 점검을 통과할 때까지 반복하므로, 엔지니어에게 도달하는 결과물은 이미 점검을 통과한 것입니다. 루프를 설정하는 것은 세션을 실행하는 엔지니어의 몫이며, 아래 단계는 그들을 위해 작성되었습니다. |
시작하기
- 전제 조건: 없음.
- 인프라: 각각 하나의 명령으로 로컬에서 실행되는 테스트 스위트와 빌드. UI 작업의 경우, Claude가 결과를 볼 수 있는 방법이 중요하며, 브라우저 도구나 MCP를 통해 연결된 스크린샷 유틸리티가 필요합니다.
실행 방법
- 오늘날 작업을 확인하는 데 일련의 명령과 약간의 환경 지식이 필요하다면, 실패 시 0이 아닌 값을 반환하는
make test나npm test와 같은 단일 타겟으로 묶으세요. CLAUDE.md의 Commands 섹션에, 정상적인 출력 예시와 함께 각 명령을 나열하세요.- 목표를 명시하고 정량화하여 Claude가 여러분에게 묻지 않고도 작업을 확인할 수 있도록 하세요. 예를 들어: "
test_status.py의 모든 테스트가 통과한다," "스크린샷이 첨부된 목업과 일치한다," 또는 "엔드포인트가 새 필드와 함께 200을 반환한다"와 같이 작성하세요. - 버그 수정의 경우, 실패하는 테스트를 먼저 작성하세요. Claude에게 버그를 테스트로 재현하고, 실행하고, 예상한 이유로 실패하는지 확인하도록 요청하세요. 그 테스트를 커밋하세요. 그런 다음에야 Claude에게 테스트를 수정하지 않고 통과시키도록 요청하며, 마지막 단계의 테스트 파일 훅이 이 제약을 강제합니다. 수정 전에 존재했고 에이전트가 다시 작성할 수 없었던 테스트는 버그가 사라졌다는 증거입니다.
- UI 작업의 경우, 시각적 확인으로 루프를 마무리하세요. Claude에게 브라우저나 스크린샷 도구를 제공하고, 목업을 주고, 반복하게 하세요. 구현하고, 스크린샷을 찍고, 비교하고, 조정합니다. 두세 번의 반복이 일반적이며, 결과는 매번 개선되어야 합니다.
- 검증을 "완료"의 일부로 만드세요. 이 지침은
CLAUDE.md에 있습니다: "작업 완료를 보고하기 전에 테스트를 실행하고 출력을 보여주세요." - 마지막으로, 루프 자체를 보호해야 합니다. 코드를 수정하는 에이전트가 그 코드에 대한 점검을 약화시킬 수 없어야 하기 때문입니다. 수정 작업 중 테스트 파일에 대한 편집을 차단하는 훅이 이를 수행합니다. 대안은 리뷰에서 diff를 확인하고 테스트를 건드리는 모든 변경을 거부하는 것입니다.
실제 모습
CLAUDE.md 검증 블록:
markdown
## Verifying your work
- Build: make build (must finish with "Build succeeded")
- Test: make test (all green; never skip or delete a failing test)
- Lint: make lint (zero warnings)
Run all three before reporting any task complete, and paste the output.
If a test fails, fix the code, not the test.거버넌스 고려 사항
- 강제되는 것: 작업 완료가 보고되기 전의 검증, 그리고 수정 작업 중 에이전트가 테스트 파일을 편집하는 것에 대한 차단이며, 조직이 이를 보장하고자 하는 경우 둘 다 훅으로 구현됩니다.
- 증거가 되는 것: Claude가 실행하고 붙여넣은
make test의 실제 출력, 빌드 로그, 또는 스크린샷 비교이며, 따라서 증거는 툴체인에서 나옵니다. - 기록되는 위치: OpenTelemetry 내보내기가 조직의 관측 가능성 스택으로 전달하는 세션 트랜스크립트, 그리고 리뷰어와 이후의 감사자가 모두 확인할 수 있는 PR의 체크 실행 기록입니다.
- 승인자: PR을 검토하는 코드 소유자이며, 기계적 증거가 이미 첨부되어 있으므로 의도와 위험에 집중할 수 있습니다.
측정 방법
- 선행 지표: 에이전트가 작성한 변경 사항에 대한 첫 시도 CI 성공률이며, CI 시스템이 이미 이를 지원합니다.
- 후행 지표: PR당 리뷰 시간(PR 메타데이터 기준)이며, 테스트가 리뷰어가 이전에 잡아내던 문제를 잡아내기 시작하면 감소해야 하고, 인시던트 트래커에서 나온 변경 실패율입니다.