수집 작업이 오늘 오전에 끝났다는 표시만 보고 자료도 오늘 바뀌었다고 생각하기 쉽습니다. 그러나 오늘 접속해 어제의 값을 받아온 것일 수 있습니다. 데이터 수집 주기를 정하려면 작업이 성공했는지와 의사결정에 쓸 값이 어느 시점의 정보인지를 먼저 구별해야 합니다. 접속 횟수를 늘려도 원본이 갱신되지 않는 동안에는 이 두 시각의 차이가 줄어들지 않습니다.
오후 회의 전에 매일 공개되는 현황 자료를 받는 가상의 업무를 생각해 보겠습니다. 수집기는 오전에 여러 번 정상 작동했지만 원본에는 아직 전날 기준 자료가 있습니다. 보고서에 마지막 수집 시각만 크게 표시하면 회의 참석자는 당일 현황을 받은 것으로 오해할 수 있습니다. 화면에는 실제로 받아온 자료의 기준일과 마지막으로 접속해 확인한 시각이 각각 무엇을 뜻하는지 보여 줘야 합니다. 원본이 기준일을 제공하지 않으면 수집기가 그 날짜를 만들어 붙이지 않습니다.
원본 페이지의 수정 시각도 살펴볼 대상입니다. 페이지 아래의 안내문이 바뀌었거나 파일의 다른 항목이 수정되어 전체 자료의 변경 시각이 움직였을 수 있습니다. HTTP 표준 RFC 9110의 Last-Modified 역시 서버가 선택된 표현이 마지막으로 수정됐다고 판단한 시각을 뜻합니다. 그것이 보고 싶은 개별 수치가 바뀐 시각인지는 별도로 확인해야 합니다. 문서 전체의 수정 정보와 특정 값의 갱신 정보를 한 칸에 합치지 않는 이유입니다.
이전과 같은 값을 정상적으로 받았다면 ‘이번 확인에서도 같은 값이 관찰됨’이라고 설명할 수 있습니다. 반면 연결이 끊기거나 필요한 항목을 읽지 못했다면 이번 값은 확인하지 못한 상태입니다. 이때 마지막 성공 결과를 화면에 남길 수는 있어도, 실패한 실행 시각으로 그 결과의 확인 날짜를 새로 고쳐서는 안 됩니다. 빈 응답을 값이 없어졌다는 뜻으로 해석할지 여부도 원본의 정의를 알아야 결정할 수 있습니다.
이 구분이 생긴 다음에 수집 일정을 조정합니다. 원본의 공개 안내와 실제 관찰에서 갱신이 주로 언제 이루어졌는지, 회의나 알림이 언제 그 값을 필요로 하는지 나란히 봅니다. 원본이 늦게 공개되는 날에는 더 자주 접속했다는 기록보다 필요한 시점까지 새 자료를 확보하지 못했다는 사실이 중요합니다. 정해진 횟수를 채우는 대신 사용할 자료의 시점이 목적에 맞는지 판단하고, 늦어지는 경우의 표시와 확인 경로를 마련합니다.
조회 사이에 어떤 일이 있었는지는 조회 결과만으로 전부 알 수 없습니다. 두 번 같은 값이 나왔다고 그 사이에도 한 번도 바뀌지 않았다고 단정하지 않습니다. 짧은 변화까지 보존해야 하는 업무라면 원본이 제공하는 변경 이력이나 공식 전달 방식이 있는지 알아봐야 합니다. 수집 주기의 적절성은 중복 저장이 줄었는지뿐 아니라 필요한 변화가 의사결정 전에 발견됐는지로 살피되, 제공자의 이용 조건과 요청 제한도 지켜야 합니다.
마지막 성공 확인, 원본이 밝힌 자료 시점, 이번 수집 상태를 분리해 보면 오래된 값에 새 날짜를 붙이는 착시를 줄일 수 있습니다. 원본의 나이를 알 수 없다는 표시도 중요한 정보입니다. 그 불확실성을 숨기지 않아야 담당자가 추가 확인이 필요한지, 현재 확보한 자료로 어느 범위까지 말할 수 있는지 결정할 수 있습니다.
수정 시각의 의미를 확인한 표준 자료는 IETF RFC 9110의 8.8.2절입니다: https://www.rfc-editor.org/rfc/rfc9110.html#name-last-modified (2026년 10월 4일 확인).