완료라고 말하기 전에 검증한 단계를 나누기
구현·로컬 검사·실제 조작·CI·배포·공개 확인의 증거를 구분하는 나의 완료 기준.
이 글의 목차
완료라고 말하기 전에 검증한 단계를 나누기

완료 상태와 그 상태를 뒷받침하는 증거를 하나씩 대응시킨 개념도.
내가 겪은 상황
2026년 7월 Claude로 사이트를 수정했을 때 로컬 빌드와 화면 검증을 먼저 마쳤다. 그 단계의 기록은 커밋·배포를 하지 않았다고 명시했고, 이후 별도 배포 요청이 들어온 뒤 커밋·푸시·배포 출력과 공개 주소 확인이 이어졌다. 10월 Codex의 일부 작업도 타입 검사와 단위 테스트만 실행한 범위를 분명히 남겼다.
내가 선택한 방법
완료 보고의 각 문장에 대응하는 증거를 둔다.
| 상태 | 내가 남기는 증거 |
|---|---|
| 구현 | 실제 diff와 변경 파일 |
| 로컬 검증 | 실행한 검사·빌드와 결과 |
| 실제 조작 | 브라우저·기기에서 수행한 흐름과 결과 |
| CI | 검사한 커밋 SHA와 해당 run 결과 |
| 배포·제출 | 전달한 산출물·버전과 서비스의 접수 결과 |
| 공개 확인 | 실제 도메인 또는 스토어에서 확인한 버전·동작 |
다음에도 쓸 기준
한 단계의 증거로 다음 단계를 완료했다고 말하지 않는다. 타입 검사가 통과해도 버튼의 실제 동작은 따로 확인한다. 빌드·CI가 통과해도 운영에 올라간 것은 아니다. 스토어 제출이 접수되어도 사용자가 공개 버전을 받을 수 있는지는 별도 상태다.
적용 한계
모든 작업에 모든 검사를 실행하는 규칙은 아니다. 변경의 위험과 승인 범위에 맞는 검증을 선택하되 실행하지 않은 것은 미검증으로 남긴다. 다음 작업은 그 경계부터 이어간다.
관련: 배포 후 실제 주소에서 내용과 버전을 다시 확인하기 · 결제창 도달과 구매 완료를 따로 검증하기 · Toris의 작업 기록에서 정리한 암묵지