일일 브리핑이 어제에 멈췄을 때, 그리고 첫 화면만 돌아왔을 때

보고서는 만들어졌는데 화면은 어제 자료를 읽고 있었어요

7월 말, 일일 보고서를 만드는 작업은 돌아가는데 수집 품질과 브리핑 화면은 이전 날짜에 멈춰 있었어요. 화면이 어느 날짜를 읽는지부터 확인하고 현재 실행이 쓰는 코드와 발행 경로를 살펴보니, 최신 코드가 준비돼 있어도 오래된 실행 환경이 계속 쓰이고 있었어요. 실행 기준을 맞춘 뒤에는 일일 집계, 읽는 문서, 발행과 화면 반영이 이어지는지 차례로 봤어요. 로컬에서 최신 파일을 찾는 데서 멈추지 않고, 화면이 읽는 목록도 같은 날짜를 가리키는지, 배포 뒤 공개 접근이 정상인지까지 확인했어요.

복구 직후 최신 확인 시점이 잠깐 늦게 보였을 때는 바로 정상이나 새 장애로 정하지 않고 다음 실제 실행에서 회복되는지 지켜봤어요. 후속으로 특정 시간 구간의 수집이 빠졌는지 확인하는 기능도 붙였는데, 실제 정시 실행으로 이어지는 과정에서 조회가 오래 대기하는 문제가 나왔어요. 실행을 멈추고 범위를 좁혀 고친 뒤, 수동 실행과 실제 정시 실행 모두에서 자료를 판정해 남기는 것을 확인했어요. 결과에 실제 누락이 포함된 것은 자료의 문제를 찾아낸 결과로 읽었어요.

빈 브리핑을 다시 만들기 전에 실행의 출발점부터 바꿨어요

8월 11일에는 일일 브리핑에 며칠의 공백이 생겼어요. 원인은 오래된 실행 환경에 섞여 있던 미완료 변경이었고, 발행 과정은 준비되지 않은 상태를 감지하고 스스로 멈추고 있었어요. 저는 미완료 변경을 강제로 지우거나 발행 조건을 느슨하게 하는 대신, 그 작업은 보존하고 보고서 실행만 확인된 기준에서 출발하도록 정리했어요. 알 수 없는 상태에서 멈추는 기준을 지키는 편이 잘못된 자료를 조용히 받는 것보다 낫다고 봤어요.

그 뒤 빠진 날짜의 자료를 복구하면서 문서와 원본 결과, 보관한 결과와 발행한 결과가 서로 맞는지 대조했어요. 화면에서 최신 자료를 찾는 목록도 복구된 마지막 날짜를 가리키도록 이었어요. 실제 실행을 한 번 돌려 끝까지 성공하는지, 변경이 반영된 운영 배포, 실행 설정에 적힌 내용과 실제 등록된 실행이 같은 경로와 시점을 가리키는지도 확인했어요.

그보다 앞서, 첫 화면 복구와 업무 복구를 단계별로 나눠 적었어요

7월 20일 무렵에는 배포 중 서버 전체가 외부에서 보이지 않는 일이 있었어요. 화면도 관리 접속도 닿지 않았고, 앱 변경과 서버 환경 변경이 함께 묶여 있어 밖에서는 시작점을 가리기 어려웠어요. 그래서 확인한 사실과 추정을 나눠 서버 담당자가 이어받을 수 있게 정리했어요. 대체 환경에서는 첫 실행에서 앱이 시작되지 않아 공개 연결보다 실행 문제를 먼저 풀었고, 첫 화면이 열린 뒤에도 로그인과 보호된 자료가 연결되지 않은 단계가 있었어요.

단계마다 남은 일을 적은 기록이 복구의 실제 진행표가 됐어요. 첫 화면이 열렸을 때는 자료와 인증 연결이, 자료가 전달됐을 때는 실제 사용자 진입과 다음 자동 실행이 남았어요. 후속 배포에서는 앱을 바꾸는 범위와 서버 기반을 바꾸는 범위를 분리했고, 문서에 남은 옛 주소와 이전 절차도 현재 기준에 맞췄어요.

각 사건이 닫힌 지점은 달라요. 일일 브리핑은 한 번의 수동 실행이 끝까지 성공했지만, 기록 시점에는 첫 무인 예약 실행이 같은 결과를 내는지 관찰할 일이 남아 있었어요. 시간 구간 확인도 지나간 실행 공백을 모두 복원하지는 못했고, 실행하지 못한 구간을 나중에 확인하는 작업과 전날 전체 기록을 대조하는 작업이 남았어요. 날짜가 최신이라는 표시만으로 그 하루의 자료가 완전하다고 말할 수는 없어요. 서버 복구에서는 운영 화면, 자료 전달, 자동 주기의 성공이 기록에 있지만, 실제 사용자가 비밀번호 입력부터 마지막 행동까지 거치는 과정을 끝까지 관찰하지는 않았고, 재구축 뒤 새 예약 체인의 첫 무인 실행도 그 시점에는 남은 일이었어요.