일일 보고서를 만드는 작업은 돌아가고 있었어요. 그런데 사용자가 보는 수집 품질과 브리핑 화면은 이전 날짜에 멈춰 있었어요. 자료가 없어서 빈 것이 아니라 자료를 만들고 전달하고 보여 주는 단계가 같은 상태를 바라보지 못하고 있었어요.
생성 성공이라는 기록만 확인하면 사용자가 최신 보고서를 읽고 있다고 생각하기 쉬워요. 실제로는 파일이 생긴 시점과 화면에서 사용할 수 있게 된 시점이 달랐어요. 이 사이가 연결되지 않으면 자동 보고가 정상이라는 설명도 사용자에게는 맞지 않아요.
생성과 화면 반영을 하나씩 이어서 봤어요
먼저 화면이 어느 날짜의 자료를 읽고 있는지 확인했어요. 이어서 현재 실행이 이용하는 코드와 발행 경로를 살폈어요. 최신 코드가 준비되어 있어도 오래된 실행 환경이 계속 쓰이면 화면에 필요한 자료가 같은 흐름으로 만들어지지 않을 수 있었어요.
실행 기준을 맞추고 일일 집계, 읽는 문서, 발행과 화면 반영이 이어지는지 확인했어요. 로컬에서 최신 파일을 찾는 것으로 끝내지 않았어요. 화면이 읽는 목록도 같은 날짜를 가리키는지 보고, 배포 뒤 공개 접근의 정상 상태를 확인했어요.
복구 직후에는 최신 확인 시점이 잠깐 늦게 보인 경우도 있었어요. 이를 바로 정상이라고 덮거나 또 다른 장애라고 단정하지 않았어요. 다음 실제 실행에서 회복되는지를 보면서 생성과 전달의 상태를 나눠 읽었어요.
같은 흐름에서 즉시 상태를 읽는 것과 특정 시간 구간의 수집이 빠졌는지 확인하는 것도 구분했어요. 현재 화면에 자료가 있다는 사실만으로 지나간 모든 구간이 충족됐다는 뜻은 아니에요. 운영자가 현재의 정상과 과거의 공백을 같은 것으로 읽지 않도록 별도의 확인 기록이 필요했어요.
최신 날짜가 바뀐 결과도 그 날짜 안의 완전성을 모두 설명하지 않았어요. 당일 자료를 볼 수 있는 것과 시간별 전달이 빠짐없이 이루어진 것은 다른 질문이었어요. 현재 조회와 구간별 확인을 나눈 것은 서로 다른 사용자 판단을 지원하기 위한 선택이었어요.
실제 정시 실행에서 발견한 대기 문제는 시험 결과를 부정하는 사건으로 보지 않았어요. 시험으로 확인한 범위 밖에서 실제 자료와 실행 조건이 만난 문제였어요. 그 사실을 남기고 범위를 좁혀 고친 뒤 자연 실행에서 다시 확인했어요.
이후 빠진 구간을 확인하는 기능도 공백을 없애 보이기 위한 것으로 만들 수는 없었어요. 그때 실행되지 않은 사실과 나중에 자료를 읽은 사실은 다른 시점이에요. 앞으로 보완하더라도 두 시점을 구분해야 과거 운영을 사실대로 읽을 수 있어요.
시험이 통과해도 실제 실행에서 다시 배웠어요
시간 구간을 확인하는 후속 작업은 시험과 구현을 마친 단계에서 운영 반영 대기로 남아 있었어요. 이후 실제 실행으로 이어지는 과정에서 조회가 오래 대기하는 문제가 나타났어요. 이때 계속 기다리며 성공을 기대하기보다 실행을 멈추고 확인 범위를 다시 좁혔어요.
수정 후 수동 실행뿐 아니라 실제 정시 실행이 자료를 판정해 남기는 것을 확인했어요. 확인 결과에 실제 누락이 포함됐다고 실행 자체를 고장으로 보지는 않았어요. 자료의 문제를 발견한 결과와 검증 실행의 실패는 다른 뜻이었어요.
여기까지 확인했다고 지나간 실행 공백을 모두 복원한 것은 아니었어요. 실행하지 못한 구간을 나중에 확인하는 작업과 전날 전체 기록을 대조하는 작업은 남아 있었어요. 날짜가 최신이라는 표시만으로 그 하루의 모든 자료가 완전하다고 설명하지 않았어요.
이 글에는 보고서 날짜를 복구한 흐름과 시간 구간 확인을 운영에 연결한 후속 작업을 함께 담았어요. 서로 다른 목적을 가진 단계라 하나의 성공으로 압축하지 않았어요. 사용자가 읽는 최신 자료의 위치를 바로잡는 일과 그 자료가 말하는 범위를 정확하게 만드는 일이 이어졌어요.
자동 보고에서 사용자에게 도착해야 하는 것은 생성 완료 표시가 아니었어요. 지금 읽는 자료가 언제까지의 사실을 담고 있는지 알 수 있는 결과였어요. 파일을 만든 시점부터 화면에 나타난 시점까지 연결해 봐야 그 경험을 확인할 수 있었어요.
