AI 코딩 PR에 실행·미실행 검증 기록하는 운영 사례
Imprint Engineering의 Will Larson은 AI 코딩 도구가 생성한 풀리퀘스트마다 검증 내역을 별도 파일로 남기도록 한 운영 방식을 설명했습니다. 구체적으로 PR 번호에 대응하는 `verifications/{pr_num}.md` 파일에 실행한 점검과 실행하지 못한 점검을 기록하고, 이 문서가 없으면 PR을 draft에서 ready로 전환하지 못하도록 한다는 것입니다.
Imprint Engineering의 Will Larson은 AI 코딩 도구가 생성한 풀리퀘스트마다 검증 내역을 별도 파일로 남기도록 한 운영 방식을 설명했습니다. 구체적으로 PR 번호에 대응하는 verifications/{pr_num}.md 파일에 실행한 점검과 실행하지 못한 점검을 기록하고, 이 문서가 없으면 PR을 draft에서 ready로 전환하지 못하도록 한다는 것입니다. 원보도·자료
작성자가 설명한 검증 순환은 변경 구현, 로컬 확인 후 PR 작성, 자동·사람의 리뷰, 피드백 반영, 검증 실패 지점의 반복 개선으로 구성됩니다. 매일 실패하거나 수행하지 못한 검증 내역을 모아 후속 개선 이슈를 만들고, 테스트와 도구 사용 지침도 갱신합니다. 작성자는 영역별로 아침마다 검토할 PR이 여러 개 준비되는 등 내부에서 긍정적인 경험을 보고했지만, 이를 다른 조직에서 재현된 생산성 향상 통계로 보도해서는 안 됩니다.
AI 코딩 에이전트는 코드를 작성했다고 해서 자동으로 테스트·린터·타입 검사와 실제 기능 검증까지 모두 수행한 것은 아닙니다. 생성된 PR만 보고 개발자가 검증 여부를 추정하면 리뷰와 CI에서 뒤늦게 기본적인 문제를 발견할 수 있습니다. 검증 기록을 강제하면 도구가 무엇을 했는지와 무엇을 생략했는지를 사람이 확인할 수 있습니다.
개발팀의 AI 도입 성과를 생성 코드량이 아니라 검증 가능성과 실패 원인의 가시성으로 평가해야 한다는 운영적 시사점입니다. 다만 에이전트가 작성한 검증 파일은 자기보고 문서이므로 테스트 실행 로그를 대체하지 않습니다. 실행 결과와 커밋을 연결하고, 권한이 있는 CI·사람의 독립 확인을 거쳐야 검증의 신뢰도를 높일 수 있습니다.
검증 기록과 실제 검증을 구분하는 이유는 GitHub의 별도 리뷰 지침에서도 드러납니다. GitHub는 AI가 만든 변경을 검토할 때 테스트 삭제·건너뛰기, 커버리지 기준 완화, CI 실행 조건 변경부터 확인하라고 권고합니다. 테스트가 통과했다는 표시만이 아니라 검사 자체가 약화되지 않았는지를 함께 보라는 뜻입니다. 이는 Imprint의 효과를 입증한 실험이 아니라 검증 기록을 읽을 때 필요한 독립적인 운영 맥락입니다. GitHub 리뷰 지침