실패 알림만으로 상태를 판단하지 않기
자동화가 오류를 냈다는 알림은 전체 작업이 실패했다는 뜻이 아닐 수 있습니다. 여러 항목 중 일부는 이미 저장되거나 외부로 전달됐고, 나머지만 오류가 났을 수 있습니다. 실패 알림을 보고 전체를 다시 실행하면 완료 항목이 중복 등록되거나 고객에게 같은 안내가 두 번 갈 위험이 있습니다. 재시도 전에는 작업 전체와 개별 항목의 처리 상태를 확인해야 합니다.
먼저 자동화 실행 번호, 시작 시각, 마지막 정상 단계, 오류 단계, 대상 항목 수를 확보합니다. 실행 기록에서 각 항목에 성공·실패·미확인 상태가 남아 있는지 확인하고, 상태가 기록되지 않은 항목은 미처리라고 단정하지 않습니다. 외부 시스템에 반영됐을 수도 있으므로 대상 시스템의 실제 기록과 대조할 때까지 미확인으로 둡니다.
항목별 처리 대장 만들기
처리 대장에는 항목 식별값, 입력 출처, 자동화 실행 번호, 처리 결과, 결과가 확인된 위치, 확인 시각, 후속 행동을 기록합니다. 고객 이름이나 민감한 값을 식별자로 과도하게 복사하지 말고 내부 업무 번호처럼 필요한 최소 키를 사용합니다. 항목별 대장이 있어야 성공한 항목을 제외하고 실패하거나 불확실한 항목만 안전하게 재개할 수 있습니다.
AI는 로그와 작업 목록을 받아 처리 상태 후보를 분류할 수 있습니다. 다만 로그 메시지의 ‘완료’가 실제 후속 시스템에서 저장 완료를 뜻하는지 정의를 확인해야 합니다. 프롬프트에는 원문에 없는 상태를 추측하지 말고, 기록 간 충돌이나 누락은 별도 목록으로 보여 달라고 합니다. 결과에는 로그 근거와 확인 불가 항목을 함께 출력하게 합니다.
완료·실패·미확인 구분 기준
완료는 정해진 결과가 실제로 만들어졌고 이를 확인할 수 있을 때 표시합니다. 오류 메시지가 없거나 자동화가 마지막 단계까지 도달했다는 사실만으로는 충분하지 않을 수 있습니다. 미처리는 해당 항목이 목표 시스템에 반영되지 않았다는 근거가 확인된 경우에만 지정합니다. 로그가 유실됐거나 다른 서비스와 연결되지 않았다면 미확인 상태를 유지합니다.
부분 완료 상태도 필요합니다. 파일은 만들어졌지만 검토 요청이 발송되지 않았거나, 데이터가 입력됐지만 승인 절차가 남았다면 전체 업무는 아직 진행 중입니다. 단계별 완료 기준을 정의하고 각 단계의 결과를 따로 기록합니다. AI가 여러 단계를 하나의 완료로 합치지 않도록 작업 흐름과 상태 의미를 설명해 둡니다.
실제 시스템과 대조하는 순서
로그를 확인한 뒤 자동화가 입력하거나 수정했어야 하는 시스템의 실제 내역을 검색합니다. 항목 식별값, 반영 시각, 생성자, 변경 이력을 대조해 같은 실행으로 생성된 결과인지 확인합니다. 상태가 달라 보이면 시간대 차이, 지연 반영, 중복 항목을 검토합니다. 권한이 없는 시스템의 상태를 추정하지 말고 해당 시스템 소유자에게 확인을 요청합니다.
외부 서비스로 자료를 보냈다면 송신 기록과 수신 확인을 별도로 봅니다. 요청이 전송됐다는 로그가 상대 시스템의 처리를 보장하지 않을 수 있습니다. 되돌리기 어려운 작업이나 금전·계정에 영향을 주는 작업은 자동 재실행을 중단하고 승인자와 영향 범위를 검토합니다. 확인 결과와 확인자를 대장에 기록합니다.
안전한 재시도 기준
재시도 전에 해당 자동화가 반복 실행에 안전한지 문서화된 규칙을 확인합니다. 중복 방지 키나 실행 번호를 기준으로 같은 요청을 걸러내는 기능이 있는지, 일부 단계만 재실행할 수 있는지 확인하세요. 기능 여부를 모르면 전체 실행 버튼을 누르지 말고 운영 책임자에게 묻습니다. AI가 로그만 보고 재실행 가능하다고 판단하도록 해서는 안 됩니다.
재시도 대상을 미처리로 확정된 항목으로 제한하고, 이미 처리된 항목은 제외 목록으로 둡니다. 실행 전 대상 수와 제외 수를 담당자가 확인합니다. 시험이 허용된다면 영향이 없는 테스트 항목으로 동작을 확인하되 실제 고객 데이터나 운영 환경에서 검증을 무리하게 하지 않습니다. 재시도 시각과 실행 번호를 기록해 원래 실행과 구분합니다.
오류 원인과 임시 조치 기록
문제 원인을 네트워크, 인증, 입력 형식, 외부 서비스 응답, 권한, 처리 한도 등 관찰 가능한 범주로 나누어 기록할 수 있습니다. 단, 단순한 오류 코드만 보고 근본 원인을 확정하지 않습니다. AI는 로그에서 반복된 문구와 발생 시점을 묶어 후보를 정리할 수 있지만 시스템 담당자가 재현과 원인 분석을 수행해야 합니다.
수동으로 처리한 항목은 자동화 대장과 같은 식별값으로 연결합니다. 수동 조치 시각, 처리자, 결과, 이후 자동화에서 제외해야 하는지 기록하지 않으면 복구 후 자동화가 같은 항목을 다시 처리할 수 있습니다. 임시 조치가 정식 절차를 벗어나지 않았는지 권한자와 확인하고, 임시 대장만 남아 있지 않도록 공식 시스템에도 결과를 반영합니다.
복구 완료 검수와 절차 개선
복구 완료는 실패 알림이 사라졌을 때가 아니라 모든 대상 항목이 완료, 미처리, 보류, 취소 중 확인 가능한 상태를 가졌을 때 선언합니다. 미확인 항목이 남으면 복구 완료 범위를 제한해 보고하고 담당자와 다음 확인 시점을 지정합니다. 처리 결과의 합계가 원래 대상 수와 일치하는지 확인해 누락이나 중복을 찾습니다.
사후에는 처리 건수, 중복 발생 여부, 미확인 건수, 재시도 횟수, 복구 소요를 살펴 개선점을 찾습니다. 자동화에 항목별 상태 기록과 안전한 재실행 제어가 부족하다면 운영 담당자가 설계를 보완해야 합니다. AI는 점검표와 사건 요약을 정리하는 데 활용하고 실행 권한은 최소화합니다. 로그와 대장에는 업무에 필요한 정보만 보관하고 접근·보존 규칙을 적용합니다.
적용할 때 추가로 확인할 사항
재실행 전 입력 목록 자체가 변했는지도 확인합니다. 실패 이후 새 항목이 들어왔거나 취소 요청이 접수됐다면 원래 실행 목록을 그대로 재사용할 수 없습니다. 실행 시점의 입력을 고정하고 변경 건은 별도 대기 목록으로 관리합니다. AI가 만든 대조 결과에 새 항목이 섞였는지 식별 번호 범위를 확인합니다.
자동화가 외부 시스템에 요청을 전송하고 응답을 받지 못한 상황은 특히 주의가 필요합니다. 응답이 없더라도 상대 시스템은 요청을 처리했을 수 있습니다. 네트워크 오류만 보고 재전송하지 말고 수신 시스템의 상태 조회나 운영 담당자 확인을 거칩니다. 중복 방지 키가 실제로 적용되는지 문서나 테스트로 검증합니다.
실패한 실행의 로그가 일부만 남았다면 로그가 존재하는 구간과 없는 구간을 구분해 보고합니다. 실행 시작 전후의 시스템 상태, 작업 큐, 생성된 결과를 이용해 복구 범위를 추정할 수 있지만 추정은 확정과 다릅니다. 증거가 부족한 항목은 잠정 보류하고 시스템 소유자와 함께 조사합니다.
실패 원인을 고친 뒤에도 전체 작업을 바로 재실행하기보다 승인된 시험 범위에서 동작을 점검합니다. 입력 검증, 처리 단계, 오류 처리, 중복 방지, 결과 기록이 예상대로 동작하는지 확인합니다. 운영 재개 승인을 받은 뒤 실행 시간과 감시 담당자를 정하고, 이상이 다시 나타날 때 중지할 기준을 설정합니다.
복구 내용을 공유할 때는 민감한 로그 원문을 무분별하게 붙이지 말고 오류 유형, 영향 범위, 처리 현황, 남은 위험을 간결하게 적습니다. 접근 권한이 있는 사람만 상세 로그를 볼 수 있도록 하고, 임시 분석 자료의 보존과 삭제는 조직의 정책에 따릅니다. 외부 업체가 원인 분석을 맡는 경우에도 제공 자료를 최소화합니다.
운영과 유지 관리
실패 항목을 수동으로 처리한 뒤 자동화가 복구되면 처리 대장에 수동 완료 상태를 표시하고 자동 재실행 제외 목록에도 반영합니다. 두 시스템이 서로 다른 상태를 갖지 않도록 반영 후 다시 조회합니다.
재개 후 일정 시간 동안은 자동화 실행 결과를 담당자가 모니터링합니다. 평소보다 오류가 많거나 대상 수가 비정상적으로 적으면 추가 실행을 중지하고 확인합니다. 정상화 판단 기준과 감시 종료 시각을 사전에 정합니다.
복구 책임을 한 사람에게만 의존하지 않도록 실행 담당자와 승인 담당자, 서비스 문의 담당자를 정합니다. 야간이나 휴일에 장애가 반복될 수 있다면 대체 연락 체계와 인수 기준을 마련하되 개인 연락처는 승인된 범위에서 관리합니다.
오류가 반복되는 동안 업무를 수동으로 계속할지 일시 중지할지 사전에 정한 기준을 확인합니다. 데이터가 불완전한 상태로 누적될 위험이 있으면 중단 권한자와 대체 업무를 지정하고, 재개 승인 전에는 자동 실행을 다시 켜지 않습니다.
대상 목록을 확정한 뒤에는 원본 입력의 개수와 대사 결과의 개수를 비교합니다. 제외된 항목이 있다면 제외 이유와 승인자를 기록하고, 근거 없는 제외가 없는지 검토자가 확인합니다.