AI 코딩 에이전트가 깔끔한 테스트 로그를 반환하며 작업이 완료되었다고 말합니다.

그 로그는 진짜일 수 있습니다. 명령어가 통과했을 수도 있습니다. 하지만 그 결과가 당신에게 수락을 요구하는 주장(claim)을 뒷받침하기에는 여전히 불충분할 수 있습니다.

문제는 로그가 쓸모없다는 것이 아닙니다. 문제는 로그가 보통 완료를 주장하는 것과 동일한 워크플로우(workflow)에 의해 제공된다는 점입니다. 독립적인 검토(Independent review)는 두 번째 사람이 해당 출력을 현재의 아티팩트(artifact)와 연결하고 중요한 부분을 재현(reproduce)할 수 있을 때 시작됩니다.

로그는 하나의 좁은 질문에만 답한다

테스트 로그는 특정 명령어가 특정 출력을 생성했음을 보여줄 수 있습니다. 하지만 로그 자체만으로는 다음을 보여주지 못할 수 있습니다:

• 어떤 리비전(revision)이 테스트되었는지;
• 실행 후 파일이 변경되었는지;
• 어떤 환경(environment)이나 설정(configuration)이 활성화되었는지;
• 명령어가 요청된 동작을 수행했는지;
• 출력이 잘렸는지(truncated);
• 검토자가 동일한 체크를 실행할 수 있는지.

이러한 공백들이 구현이 잘못되었다는 것을 증명하지는 않습니다. 다만 로그가 뒷받침할 수 있는 범위를 제한할 뿐입니다.

증거 체인 재구성하기

다음 다섯 가지 필드를 사용하십시오:

1. 주장 (Claim) — 당신이 수락하도록 요청받은 정확한 동작.
2. 아티팩트 (Artifact) — 변경된 파일, 패치(patch), 빌드(build) 또는 기타 전달된 항목.
3. 실행 (Execution) — 명령어, 출력, 종료 상태(exit status) 및 타임스탬프(timestamp).
4. 출처 (Provenance) — 리비전, 워크스페이스 상태, 환경 및 설정.
5. 커버리지 (Coverage) — 체크가 수행한 내용과 범위 밖에 남겨진 내용.

만약 하나의 필드가 누락되었다면, 판결을 좁게 유지하십시오. "테스트 로그가 제공되었다"는 것은 "요청된 동작이 현재 리비전에서 독립적으로 재현 가능하다"는 것과는 다릅니다.

예시: 잘못된 시점의 실제 로그

특정 테스트가 10:14에 통과했다고 가정해 봅시다. 10:19에 에이전트는 락파일(lockfile)과 설정을 업데이트합니다. 10:22에 에이전트는 이전 로그를 반환하며 전달 준비가 되었다고 말합니다.

10:14의 결과는 실제일 수 있습니다. 하지만 영향을 받는 체크가 다시 실행될 때까지 최종 워크스페이스 기준으로는 오래된(stale) 정보입니다.

가장 작고 유용한 요청은 "모든 것을 증명하라"가 아닙니다. 그것은 다음과 같습니다:

이 명령을 최종 리비전(final revision)에 대해 다시 실행하고, 종료 상태(exit status)와 현재 리비전 식별자(revision identifier)를 반환하십시오.

해당 요청은 단 한 번의 재실행이 보안, 배포 또는 프로덕션 준비 상태(production readiness)를 보증한다고 가장하지 않으면서, 결과를 아티팩트(artifact)에 결합합니다.

재현(Reproduction)은 리뷰 액션이다

리스크가 낮은 변경 사항의 경우, 차이점(diff)을 읽고 하나의 집중된 명령을 다시 실행하는 것만으로도 충분할 수 있습니다. 데이터, 보안, 과금 또는 릴리스 동작의 경우, 리뷰어는 추가적인 점검과 인간 소유자(human owner)가 필요할 수 있습니다.

중요한 차이점은 제공된 증거(supplied evidence)와 재현된 증거(reproduced evidence) 사이의 구분입니다:

• 제공된 증거 (Supplied evidence): 무엇을 검사할지 결정하는 데 도움을 줍니다.
• 재현된 증거 (Reproduced evidence): 사용자가 제어한 점검으로부터 결과를 제공합니다.

둘 다 유용할 수 있습니다. 이들은 서로 다른 수준의 신뢰도를 뒷받침합니다.

좁은 판결도 여전히 유용한 판결이다

다음 네 가지 결과 중 하나를 사용하십시오:

• 지원됨 (Supported) — 현재 아티팩트와 재현된 점검이 정확한 주장을 뒷받침합니다.
• 미검증 (Unverified) — 증거가 누락되었거나, 오래되었거나(stale), 너무 좁거나, 재현되지 않았습니다.
• 차단됨 (Blocked) — 액세스, 환경 또는 권한 문제로 인해 다음 점검을 진행할 수 없습니다.
• 충돌함 (Conflicted) — 아티팩트 간의 내용이 일치하지 않습니다.

이를 통해 “아직 이것을 검증할 수 없다”가 “코드가 나쁘다”로 변질되는 것을 방지하는 동시에, 녹색 로그(green log)가 조용히 광범위한 릴리스 결정으로 이어지는 것을 방지합니다.

재사용 가능한 리뷰 프롬프트

AI 코딩 핸드오프(handoff)를 수락하기 전에 다음과 같이 질문하십시오:

• 이 로그가 뒷받침하는 정확한 주장은 무엇인가?
• 어떤 리비전(revision)이 이를 생성했는가?
• 실행 후에 무엇이 변경되었는가?
• 중요한 점검을 재현할 수 있는가?
• 증거 경계(evidence boundary) 밖에 남아 있는 것은 무엇인가?

저는 이러한 리뷰를 구조화하기 위한 수동 워크시트로 'AI Completion Evidence Auditor Lite'라는 무료 도구를 만들었습니다. 이 도구는 테스트를 실행하거나 제공된 로그를 인증하지는 않습니다:

https://frankster8205.gumroad.com/l/ai-completion-evidence-auditor-lite?src=devto_us_article3_log_provenance_v1&utm_source=devto&utm_medium=organic_content&utm_campaign=reliable_ai_delivery_wave1&utm_content=devto_us_article3_log_provenance_v1