8월에 보고서 묶음은 만들어져 전달됐는데 운영 화면은 필요한 결과가 없다고 판단했어요. 실제 실행과 파일이 남아 있으니 같은 작업을 다시 돌려야 하는지부터 헷갈렸어요. 이번에는 생성 쪽보다 그 결과를 찾는 쪽에서 날짜를 잘못 읽고 있었어요.
사용자에게 보이는 실패는 실제 작업 중단과 비슷해요. 하지만 파일이 도착했는데 상태만 실패라면 재실행이 답인지 확실하지 않아요. 이미 끝난 일을 반복하기 전에 결과가 어디에 있고 어떤 날짜의 실행에서 왔는지 확인해야 했어요.
성공한 실행을 먼저 남겨 두기
기록에는 보고 묶음의 생성과 전달이 통과한 실행이 남아 있었어요. 이를 새 실행으로 덮기보다 현재 근거로 살폈어요. 결과가 있다고 주장하는 쪽과 없다고 말하는 쪽이 같은 파일을 보고 있는지 대조하면 불일치를 좁힐 수 있었어요.
확인 과정에서 날짜를 실제 파일 위치로 해석하는 규칙이 맞지 않았어요. 결과를 찾을 때 날짜가 의도한 형태로 연결되지 않아 엉뚱한 위치를 확인하고 있었어요. 파일은 정상적으로 만들어졌지만 읽는 과정에서는 존재하지 않는 것처럼 보였어요.
생성 날짜와 보고 대상 날짜가 다른 작업에서는 이런 차이가 더 중요해요. 파일이 최신이라는 사실만으로 어느 실행의 결과인지 알 수는 없어요. 이번에는 해당 날짜의 실제 결과를 검사 기준과 맞춰 어떤 부분이 어긋났는지 확인했어요.
같은 결과를, 같은 날짜로 읽도록 하기
수정 대상은 이미 성공한 생성 작업이 아니라 이를 찾는 날짜 처리였어요. 실제 결과 위치를 찾도록 기준을 고치고 그 위치를 사용하는 검사를 추가했어요. 추상적으로 날짜를 잘 처리한다는 확인보다 그날의 결과를 찾아야 한다는 질문에 가까웠어요.
생성 작업이나 원격 자료 묶음을 다시 돌리지 않은 채 상태를 재수집했어요. 이후 현재 상태와 대시보드, 아침 요약이 같은 회복 결과를 읽는 것을 확인했어요. 생성 재시도 없이도 관측 오류를 바로잡았다는 근거가 됐어요.
이 과정을 보면 재실행을 하지 않는 것도 문제를 다루는 선택이 될 수 있어요. 이미 정상인 생산을 반복하면 새 결과가 생겨 처음 무엇이 잘못됐는지 비교하기 어려워질 수 있어요. 원인과 처리의 관계를 남기려면 성공한 실행을 보존한 채 잘못 읽은 부분을 고치는 편이 맞았어요.
그렇다고 전체 운영이 아무 문제 없는 상태가 된 것은 아니었어요. 다른 품질 경고와 지난 사건의 이력은 남아 있었어요. 이번 결과는 보고 묶음을 없는 것으로 판단하던 오류를 수정하고 관련 화면을 정렬한 범위예요. 다른 경고까지 같은 복구에 넣지 않았어요.
한 가지 설명과 구현의 차이도 별도 과제로 남았어요. 같은 결과를 다시 사용하는 것과 추가 전달까지 생략하는 것은 다를 수 있어요. 현재 결과를 찾는 문제가 해결됐다고 재사용과 반복 전송의 모든 의미까지 정리됐다고 쓰지는 않았어요.
이전 성공을 남겨 둔 채 확인 기준만 바꾸면 수정의 효과를 비교하기 쉬워요. 새로운 결과가 아니라 같은 결과를 찾게 됐다는 점을 설명할 수 있었어요. 재시도 횟수보다 무엇을 관측하게 됐는지가 이번 회복의 근거였어요.
화면마다 다른 상태를 읽는 문제도 함께 볼 수 있었어요. 현재 상태가 바뀌어도 아침 요약이 이전 실패를 전달하면 사용자는 다시 확인해야 해요. 그래서 한 화면의 표시만 보지 않고 같은 결과가 다음 요약에서도 이어지는지 대조했어요.
날짜 처리를 고친 것은 보고 내용을 고친 작업과 달랐어요. 이미 있던 결과를 제대로 찾게 된 변화예요. 내용의 유용성이나 원천의 완전성까지 이 수정으로 설명하지 않아야 이후 다른 경고가 나타나도 원인을 다시 구분할 수 있어요.
사용자에게 필요했던 것은 정상이라는 말보다 도착한 결과와 운영 화면이 같은 이야기를 하는 상태였어요. 이번에는 어느 작업을 다시 돌릴지 묻기 전에 결과가 실제로 있는지, 확인하는 쪽이 그 결과를 같은 날짜로 읽는지 살폈어요. 반복 실행보다 관측을 바로잡는 판단이 앞선 사건이었어요.
