작업 완료라는 말은 코드 작성, 테스트 통과, 운영 반영 가운데 어느 단계인지 먼저 구분해야 한다. 파일을 수정했어도 빌드하지 않았을 수 있고, 테스트가 통과해도 실제 로그인이나 외부 서비스 연동은 확인하지 않았을 수 있다. 에이전트에게 완료 단계와 남은 검증을 각각 적게 하면 인수인계가 명확해진다.
작은 수정은 문제가 발생하는 조건을 재현하고 수정 후 결과를 비교한다. 로그인이나 결제처럼 상태가 바뀌는 기능은 성공 경로뿐 아니라 비로그인, 잘못된 입력, 권한이 없는 계정, 중복 요청도 확인한다. 테스트가 구현 내용을 그대로 반복하기보다는 사용자가 기대하는 동작을 검증하도록 요청한다.
커밋 전에는 변경 파일 목록과 차이를 읽는다. 여러 사람이 같은 폴더에서 작업한다면 다른 사람의 미완성 변경이 함께 들어가지 않도록 별도 브랜치나 작업 폴더를 사용한다. 설정 파일의 비밀값, 임시 로그, 생성된 대용량 파일이 포함되지 않았는지도 확인한다.
배포 완료는 운영 주소의 응답과 실행 버전으로 확인한다. 새 화면에 필요한 CSS와 JavaScript가 별도 호스트에 있다면 WAR만 교체해서는 충분하지 않다. 리허설 결과, 운영 파일 체크섬, 주요 경로 응답, 복구 파일 위치를 한 기록에 남겨 두면 다음 작업자가 상태를 이어받기 쉽다.
실습: 에이전트에게 작은 버그 수정을 맡기고 “변경 이유, 재현 방법, 실행한 검증, 검증하지 못한 부분, 배포 여부를 분리해서 보고해 줘”라고 요청해 보자. 결과에서 주장만 있고 근거가 없는 항목을 찾아 추가 검증 대상으로 정리한다.