원고를 입력한 뒤 참고 탭을 읽고 돌아왔을 때 내용이 남아 있어야 한다. 하지만 탭 이동 중 보존과 앱 재시작 후 복구, 사이트 서버의 임시저장은 같은 기능이 아니다. 나는 이 차이를 확인하며 원고를 지킨다는 약속의 범위를 더 구체적으로 쓰게 됐다.
주소가 돌아왔다고 원고가 돌아온 것은 아니다
재시작 후 탭 ID와 URL이 복원돼도 페이지 안의 미전송 원고는 비어 있을 수 있다. 원래 서버에 저장하지 않은 새 편집기는 같은 주소에서 다른 빈 문서를 만들기도 한다. 탭 목록 비교만으로 문서 복구를 완료했다고 볼 수 없다.
나는 실제 입력값과 로컬 복구 자료, 서버에 남은 임시저장을 나눠 봤다. 정상 탭 이동에서 입력이 유지됐다는 시험은 그 범위의 근거다. 앱을 닫았다가 다시 연 뒤 같은 원고를 읽는 시험은 별도로 필요하다. 표면의 복원과 내용의 복원을 한 성공으로 합치지 않았다.
로컬 수집은 적격 필드와 변경 기록을 본다
page-drafts의 고정 연산은 일반 텍스트 입력과 textarea, 일부 contenteditable을 대상으로 한다. 인증 폼과 민감한 이름, 숨긴·비활성 필드 등은 제외한다. 사용자가 바꾼 값을 dirty 기록으로 남기고 지운 내용도 빈 값으로 반영한다.
이것은 사이트 전용 문서 모델을 통째로 직렬화하는 기능이 아니다. 필드 키에는 태그와 ID, 이름·라벨·종류와 경로 단서가 들어간다. HTML 구조가 바뀌면 같은 필드로 찾지 못할 수 있다. 텍스트를 보관했다는 사실을 사진·서식·매체 순서까지 완전 보존한 것으로 확대하지 않는다.
다른 내용이 있는 곳에는 복구를 밀어 넣지 않는다
일반 복원은 같은 전체 프레임 URL과 필드 식별을 찾고 이미 사용자가 바꾼 값은 건드리지 않는다. 현재 내용이 다른 값이면 그것을 보존한다. 한 번 적용한 복구본을 계속 다시 넣지 않는 기록도 둔다.
중복 URL의 프레임은 어느 문서인지 모호해 자동 복구를 피한다. 특정 블로그의 단순 텍스트 원고는 읽기 전용 복사로 다루고 보이는 프록시 DOM을 고쳐 복원하지 않는 경로가 있다. 복원 편의가 사이트 문서 모델을 깨뜨리거나 다른 원고를 덮는 위험을 만들지 않으려는 제한이다.
수집 시간이 지났다는 말과 새 자료를 얻었다는 말
captureDrafts는 진행 중 수집을 기다리고 필요할 때 새 수집을 이어 간다. 각 탭에서는 제한 시간 안에 새 자료를 못 얻으면 이전 복구본을 유지하는 경로가 있다. 오래된 사본을 보존한 결과를 방금 입력까지 새로 저장한 성공이라고 표시해서는 안 된다.
휴면·로딩·파괴된 탭과 비공개 프로필 등도 조건에서 제외한다. 정상 종료 전 수집과 강제 전원 종료의 마지막 입력 보존은 같은 보장이 아니다. 사이트 자체 임시저장이 필요한 이유도 여기에 있다. 나는 수집 시점과 내용, 실제 서버 기록을 함께 봐야 복구의 범위를 설명할 수 있다고 생각한다.
실패한 카페 복구도 기록에 남긴다
과거0.1.82의 카페 시험은 입력 시점에 실제 값 일치를 확인했지만 창을 다시 열었을 때 새 원고가 초기화됐고 로컬 복구본에서도 찾지 못했다. 그 기록을 숨기거나 나중의 다른 블로그 복원 성공으로 대신 완료 처리하지 않는다.
이 글은 그 역사 기록과 현재 텍스트 수집·복원 코드를 대조했다. 일반 HTTPS fixture의 복구 시험과 실제 특정 편집기의 성공 범위는 다르다. 현재 사용자의 원고를 닫아 새 시험을 수행한 것이 아니며 과거 실패가 모든 현재 편집기에서 그대로 난다고 단정하지도 않는다. 해당 경로의 후속 검증이 있어야 더 넓은 결론을 낼 수 있다.
보존의 약속은 실제 자료 단위로 한다
고객에게 “다 저장된다”고 말하는 것은 쉽다. 하지만 어떤 텍스트와 매체를 어느 위치에 남겼고 어떤 방식으로 다시 읽었는지 설명해야 실제 보존이 된다. 로컬 사본과 서비스 임시저장을 함께 쓰되 같은 근거라고 합치지 않는 것이 중요했다.
나는 탭 이동의 편의와 원고 복구를 계속 별도 확인으로 남기려 한다. 프로그램을 다시 실행하는 것과 문서를 복원하는 것도 다르며 복구가 자동 게시나 재전송을 뜻해서는 안 된다. 그 경계를 명시해야 사용자가 업무를 이어 갈 때 무엇을 믿고 무엇을 더 확인해야 하는지 알 수 있다.