타임아웃이 나면 같은 명령을 한 번 더 누르고 싶어진다. 여러 실행 환경에 같은 AI 에이전트 기능 묶음을 배포하는 자동화에서는 그 습관이 상태를 더 망가뜨릴 수 있다. 시간 제한이 알려 주는 것은 제어 명령의 응답이 늦었다는 사실뿐이다. 작업이 어디까지 진행됐는지는 말해 주지 않는다.
제어 연결이 끊기기 전에 파일 교체나 버전 기록이 끝났을 수 있다. 반대로 준비 단계에서 아무 변화 없이 멈췄을 수도 있다. 두 상황에 같은 재시도를 적용하면 이미 만들어진 릴리스를 중복 생성하거나, 배포 계보를 두 번 움직이거나, 되돌릴 기준을 잘못 잡게 된다.
실제 사례에서도 화면에 남은 결과는 타임아웃이었다. 하지만 상태를 다시 읽자 새 패키지 버전은 정본에 반영됐고 배포 계보도 그 버전을 가리켰다. 실행 프로세스는 사라졌고 잠금은 풀려 있었다. 끝나지 않은 것은 작업 전체가 아니라 ‘검증 중’에 멈춘 인계 기록이었다.
복구는 재실행 대신 상태 재구성부터 시작했다. 프로세스, 잠금, 승인된 패키지 버전, 완료 영수증을 따로 확인하고 멈춘 인계 기록을 실패 상태로 정리했다. 그 다음 같은 입력을 반복해도 최종 상태가 달라지지 않는 절차로 남은 단계를 실행했다. 테스트 10개가 모두 통과했고 실제 사용 위치의 파일도 일치했으며, 두 번째 감사에서는 추가 변경이 없었다.
타임아웃 뒤의 첫 질문은 “다시 돌릴까?”가 아니다. “이미 무엇이 바뀌었나?”다. 이 순서를 거꾸로 하면 통신 실패 하나가 상태 변경 두 개로 늘어난다.