재실행 자격
현재 사용자의 권한, 해당 업무의 승인 상태와 외부 결과를 확인합니다. 자동화 관리 화면에 접근할 수 있다는 이유만으로 고객 메시지나 결제 작업을 다시 보낼 권한까지 있다고 가정하지 않습니다. 실행의 부작용이 큰 항목은 실제 운영 규칙에 맞는 검토를 거칩니다.
가정한 실행 기록
아래 기록은 복구 내역의 예시입니다. 실제 고객 자료를 포함하지 않고 원장과 필요한 증거를 권한 범위 안에서 연결합니다.
{
"replay_batch": "demo-replay-003",
"original_run": "demo-failure-021",
"precheck": "external_action_not_completed",
"replay_scope": "notification_only",
"business_record_recreation": false,
"requested_by_role": "authorized_operator",
"result": "awaiting_execution"
}
부분 재실행
접수 저장은 성공했고 메일만 실패했다면 전체 폼 처리부터 다시 돌릴 필요가 없는지 봅니다. 가정한 예로 전체 흐름을 재실행하면 새 접수와 메일이 모두 중복될 수 있습니다. 단계별 입력·출력과 재진입 지점을 정해 필요한 작업만 안전하게 수행합니다.
검증 순서
- 원본 상태와 외부 처리 사실을 확인합니다.
- 재실행 범위와 예상 결과를 기록합니다.
- 시험 또는 제한된 한 건으로 실행을 검증합니다.
- 원장·외부 결과·후속 알림을 대조합니다.
자동 재시도가 아직 예약돼 있는지도 확인합니다. 수동 실행과 자동 실행이 동시에 발생하면 중복 방지의 효과를 검수해야 합니다. 결과가 불확실한 상태에서 추가 재실행을 반복하지 않고 보류와 조사로 전환합니다.
완료와 감사
재실행의 대상·시각·담당·원본과 결과 증거를 연결합니다. 성공 뒤 미처리 상태가 닫혔는지 확인하고 원본 오류 이력은 필요한 범위에서 남깁니다. 복구 버튼이 있다는 사실보다 담당자가 어떤 상황에 눌러도 되는지 알고 결과를 추적할 수 있는 상태가 완료 기준입니다.
자주 묻는 질문
- 실패 목록을 전부 선택해 다시 실행해도 되나요?
- 이미 외부 작업이 끝난 결과 불명 항목이 섞일 수 있습니다. 상태와 오류 유형을 나누고 검증된 범위부터 처리해야 중복 메일과 CRM 생성 위험을 줄일 수 있습니다.
- 원본 요청을 수정해 재실행해도 같은 작업인가요?
- 수정 내용에 따라 새 업무가 될 수 있습니다. 원본과 수정본, 변경 이유와 실행 책임을 구분하고 과거 요청을 조용히 덮어쓰지 않습니다.
공식 참고자료와 작성 기준
공식 문서는 도구·검색 기능의 근거이며, 위의 점검 순서와 완료 기준은 현랩의 실무 설계 제안입니다. 예시를 실제 고객의 성과나 검색엔진의 보장으로 해석하지 않습니다.