블로그 상단에 수정 이력이 길게 쌓이면 가장 최근 줄만 읽고도 현재 출입구를 알 수 있다고 생각하기 쉽습니다. 하지만 마지막 수정이 종료일만 바꾼 것이라면 시작일은 앞선 기록에 남아 있습니다. 휴대전화로 짧게 읽는 방문자에게 이 계산을 맡기지 않으려면 편집자가 같은 항목의 변경을 연결해 실제 적용 기간부터 정리해야 합니다.
정문을 사용하던 가상 장소의 이력을 보겠습니다. 9월 1일에는 공사 때문에 10일부터 20일까지 동쪽 문을 이용한다고 알렸습니다. 8일 수정에서는 시작일을 12일로 미뤘고, 15일에는 종료일을 25일까지 늘렸다고 확인했습니다. 세 기록을 합치면 동쪽 문을 쓰는 기간은 12일부터 25일까지입니다. 최신 수정일인 15일을 시작일로 쓰거나 처음 공지의 10일을 그대로 남기면 다른 답이 됩니다.
이 가정에서 11일 방문에는 기존 정문, 18일 방문에는 동쪽 문이 해당합니다. 26일부터 정문으로 돌아간다는 운영도 확인됐다면 26일 예약자에게 오늘의 동쪽 문 안내를 그대로 보내지 않습니다. 짧은 공개 문구는 “9월 12~25일 방문: 동쪽 문 / 9월 26일부터 방문: 정문”처럼 방문일과 출입구를 한 쌍으로 놓을 수 있습니다. 오늘과 다음 주라는 상대 표현보다 예약자가 자기 날짜를 대입할 수 있는 범위가 필요합니다.
편집자는 각 수정에서 바뀐 값과 유지된 값을 구별하고 기간 사이에 빈 날이나 서로 겹치는 날이 없는지 확인합니다. 이력에 종료 연장만 있고 이후 동선이 확인되지 않았다면 정문 복귀를 추정해 채우지 않습니다. 모바일에서는 미래 예약일을 넣어 필요한 구간을 찾아보게 하고, 상세 이력을 펼치지 않아도 그날의 안내를 읽을 수 있는지 봅니다. 이후 변경이 생기면 새 날짜 한 줄을 덧붙이는 데서 끝내지 않고 영향을 받는 방문 구간과 안내 메시지를 함께 고칩니다.
변경 이력을 정리할 때는 수정한 날짜와 실제 적용되는 날짜를 다른 칸에 적습니다. 공지를 고친 날이 곧 동선을 바꾸는 날은 아닐 수 있습니다. 최신 수정이라는 표시만 앞에 두면 방문자는 그 날짜부터 새 출입구를 쓰는 것으로 이해할 수 있으므로, 공개 안내에서는 자신의 방문일을 대입할 수 있는 적용 기간이 먼저 보여야 합니다. 내부 기록은 수정 시점을 보관하고 공개 문구는 적용 상태를 설명하도록 역할을 나눕니다.
같은 항목의 변경을 합칠 때는 이전 값 중 무엇이 유지됐는지 확인합니다. 시작일만 바뀐 수정에서는 종료일이 유지될 수 있고, 종료일만 연장된 수정에서는 시작일이 유지될 수 있습니다. 매번 전체 값을 새로 확인한 것인지 일부만 바꾼 것인지 이력에서 구분해야 합니다. 변경 문장에 없는 부분을 편집자가 임의로 초기값이나 최신 날짜로 채우지 않습니다.
가상의 출입구 이력에서는 기간을 일자 구간으로 펼쳐 볼 수 있습니다. 기존 정문을 사용하는 구간, 동쪽 문을 사용하는 구간, 이후 운영이 확인된 구간을 나눕니다. 이렇게 정리하면 시작일과 종료일 사이의 하루가 빠졌는지, 같은 날짜에 서로 다른 출입구가 적용되는지 확인하기 쉽습니다. 표가 편집용 검토 도구라면 공개 화면에는 더 간단한 방문일별 문구로 바꿀 수 있습니다.
종료 다음 날의 운영이 확인되지 않았다면 임시 동선이 끝났다는 사실만으로 정문 복귀를 단정하지 않습니다. 공사가 끝나는 시점과 출입구를 다시 여는 시점이 다를 수도 있기 때문입니다. 실제 운영 담당자가 확인한 범위까지만 안내하고 미확정인 이후 기간은 별도 확인 대상으로 남깁니다. 일정표의 빈칸을 보기 좋게 채우려는 이유로 새로운 동선을 만들지 않습니다.
방문일을 아직 정하지 않은 사람과 이미 예약한 사람은 확인 방식이 다를 수 있습니다. 전자에게는 현재 적용 중인 동선과 예정된 변경을 보여 줄 수 있고, 후자에게는 자신의 예약일에 해당하는 안내가 필요합니다. 오늘 기준의 공지만 예약 메시지에 그대로 복사하면 미래 방문에는 다른 출입구가 적용될 수 있습니다. 메시지 작성 시점보다 실제 방문일을 기준으로 내용을 선택합니다.
시간 단위로 적용이 달라지는 운영이라면 날짜만으로 충분한지도 확인합니다. 다만 실제로 시간별 구분이 없는데 편집자가 임의로 오전과 오후를 나누지는 않습니다. 확인된 전환 시점이 있는 경우 그 단위를 표시하고, 문의자가 필요한 정보를 어디에서 확인할 수 있는지 설명합니다. 적용 조건의 세밀함은 운영 자료가 허용하는 범위에 맞춰야 합니다.
모바일 공개 화면에서는 상세 이력을 접어도 현재 적용 안내가 남아 있어야 합니다. 과거 공지를 읽어 시작일과 종료일을 계산해야만 답을 알 수 있다면 이력과 현재 안내의 역할이 섞인 것입니다. 현재 조건을 간결하게 요약한 영역을 먼저 두고, 변경 과정을 확인하려는 사람에게 이력을 별도로 제공할 수 있습니다. 이전 값이 현재 값보다 더 크게 보이지 않는지도 살핍니다.
기존 메시지나 다른 채널의 안내도 적용 기간과 함께 찾아봅니다. 블로그를 고쳤다고 예약자에게 이미 보낸 문구가 자동으로 바뀌지는 않습니다. 운영자가 추가 안내할 수 있는 경로가 있는지 확인하고, 어느 방문 구간의 사람에게 어떤 내용이 달라졌는지 정리합니다. 실제로 전달한 범위와 아직 확인하지 못한 범위를 구별해 보고해야 합니다.
현장 표지와 온라인 문구가 같은 출입구를 가리키는지도 대조합니다. 동쪽 문이라는 설명을 써도 현장에서는 다른 이름으로 표시돼 있다면 방문자는 올바른 구간을 읽고도 길을 찾지 못할 수 있습니다. 확인된 표지 이름이나 위치 단서를 함께 사용하되 실제로 보지 않은 주변 시설을 추정해 넣지 않습니다. 기간 계산과 장소 식별은 서로 다른 검수 항목입니다.
검수자는 여러 방문일을 골라 답을 찾아봅니다. 변경 전날, 시작일, 종료일, 종료 다음 날처럼 경계에 있는 날짜를 넣으면 빠진 구간이나 겹침이 드러납니다. 미래 일정이 미확정이면 미확정이라는 상태를 제대로 읽을 수 있는지도 확인합니다. 모든 날짜에 억지로 하나의 출입구를 채우는 것이 아니라 확인된 날짜에는 하나의 정확한 답이 나오게 하는 것이 목표입니다.
후속 변경이 생기면 새 이력을 추가한 뒤 현재 요약도 다시 계산합니다. 수정 기록은 쌓였는데 상단 요약이 이전 기간을 유지하는 상황을 막기 위해서입니다. 변경한 값과 영향을 받은 방문 구간, 수정한 메시지 위치를 함께 남기면 다음 담당자가 같은 계산을 처음부터 추정하지 않아도 됩니다.