주간 보고 실패 알림이 왔어요. 알림만 보면 다시 수집하고 보고서를 재생성해야 할 것 같았어요. 그런데 실제 산출물은 이미 만들어져 있었어요. 보고서를 만드는 단계가 아니라 결과를 확인하는 기준이 오래된 상태였어요.
반대로 사람에게는 잘 읽히는 보고서가 다음 자동 작업에서 막힌 경우도 있었어요. 그때는 파일이 있다는 이유만으로 정상이라고 말할 수 없었어요. 실패 알림과 실제 공백을 구분하려면 ‘무엇이 실패했는가’를 결과 파일보다 넓게 확인해야 했어요.
현재의 정상 결과를 예전 목록으로 검사하고 있었어요
일부 원본 산출물은 보안 기준을 정리하면서 더 이상 만들지 않게 되었어요. 하지만 예전 확인 목록은 그 파일을 계속 필수로 요구했어요. 현재 기준으로는 정상인 결과를 과거 기준으로 읽어 실패라고 판단한 거예요.
이때 없어진 파일을 되살려 알림을 없애지 않았어요. 안전한 결과의 현재 범위를 정리하고, 그 범위를 확인하는 쪽으로 검증을 맞췄어요. 예전 원본이 다시 들어오는 경우에는 오히려 문제로 읽도록 했어요. 알림을 잠재우는 편의가 이미 정한 정보 보호의 기준을 되돌리지 않게 했어요.
확인 기준을 만든 뒤에도 그대로 오래 두면 다시 어긋날 수 있었어요. 후속 작업에서는 현재 보고서 생성기가 실제로 내보내는 결과와 맞춰 재검토했어요. 특정 자료가 없는 정상 실행과 필수 결과가 빠진 실행을 구분했어요. 다만 이 확인 도구가 운영 흐름에 완전히 통합된 것은 아니었고 별도 변경 단계에 남아 있었어요.
현재의 정상 기준을 맞추는 일은 생성기만 고치는 것보다 넓었어요. 만드는 쪽이 바뀌었는데 읽는 쪽이 예전 기준을 유지하면 같은 파일도 다른 상태로 판단돼요. 결과의 이름과 역할, 필요한 내용이 두 단계에서 같은 의미인지 확인해야 했어요.
단순한 수동 수정 대신 생성하는 흐름을 살핀 이유도 여기에 있어요. 이번 파일만 고쳐 통과시키면 다음 주에는 같은 문제가 다시 생길 수 있어요. 검토본을 같은 원천으로 다시 만들어 다음 단계에서 읽히는지 봐야 변경의 목적과 맞았어요.
과거 실패 메일에서는 실제 변경이 필요 없다는 결론도 해결의 일부였어요. 이미 성공한 현재 상태를 확인하고 과거 실행은 이력으로 남겼어요. 어떤 문제든 코드를 바꿔야 한다고 가정하지 않고, 현재 사용자에게 남은 장애가 있는지부터 판단했어요.
읽는 단계가 요구하는 형식도 함께 맞췄어요
다른 사건에서는 주간 후보를 만드는 작업이 보고서의 역할 표시와 입력 형식을 제대로 읽지 못했어요. 문서의 한 표현을 수동으로 고치면 끝날 것처럼 보였지만, 다음 생성에서도 같은 문제가 반복될 수 있었어요.
보고서를 만드는 쪽과 읽는 쪽이 어떤 역할과 내용을 주고받는지 확인했어요. 기존 근거로 다시 만든 검토본이 다음 단계에서 읽히는지 시험했어요. 그 결과 검토 후보를 만들 수 있는 상태는 확인했지만 실제 예약 작업을 다시 실행해 최종 장부까지 남기는 것은 후속 일이었어요.
여기에 과거 배포 실패 메일을 현재 장애처럼 읽은 경우도 있었어요. 메일의 실행 시각과 해당 변경, 이후 성공 실행, 지금 공개 경로를 차례로 대조하니 이미 복구된 과거 이력이었어요. 이때는 코드를 고치거나 옛 실행을 다시 돌리지 않았어요. 현재 정상이라는 근거를 확인하는 것으로 진단을 마쳤어요.
이 글은 서로 다른 세 유형의 실패 판단을 함께 기록한 것이에요. 보고서가 없던 문제를 한 번에 복구한 사례로 묶지 않았어요. 오래된 검사 기준, 다음 단계가 읽지 못하는 입력, 이미 지나간 실패 알림은 각각 필요한 조치가 달랐어요.
사용자에게 필요한 변화는 실패 메시지가 줄어드는 것만이 아니었어요. 현재 결과를 읽을 수 있는지, 아직 처리할 공백이 있는지, 과거 이력인지 구분할 수 있어야 했어요. 잘못된 재실행이나 예전 자료의 복원을 줄이려면 먼저 실패 표시가 어떤 시점과 기준을 설명하는지 알아야 했어요.
자동 보고를 관리할 때는 생성과 검증이 같은 현재를 말하고 있는지 살펴야 했어요. 파일이 생겼다는 성공도, 실패 알림이 왔다는 사실도 혼자서는 최종 상태를 설명하지 못했어요.
