긴 명세서를 쓰다가 새로고침하거나 창을 닫으면 입력이 사라질 수 있다. 자동 보관은 이런 불안을 줄이는 기능이다. 하지만 대표나 직원이 다른 컴퓨터에서도 같은 초안을 찾을 수 있다고 이해한다면 별개의 약속이 된다. 이 프로젝트의 보관 코드는 브라우저의 작성 중 자료와 서버에 저장한 문서를 구분한다. 나는 입력을 보존하는 기능을 만들 때 무엇이 복구되는지뿐 아니라 어디까지 보존되는지 설명하는 문구도 함께 설계해야 한다고 본다.
자동 보관은 현재 브라우저의 도움이다
보관된 구현은 일정한 접두어가 붙은 자료를 브라우저 저장소에서 찾아 읽고 형식을 확인한다. 그 자료는 현재 브라우저와 사이트 주소의 저장 영역에 있다. 서버에 저장한 전표와 다른 책임이다. 브라우저 자료를 지우거나 다른 주소와 다른 기기를 사용하면 같은 임시본이 당연히 따라온다고 가정할 수 없다. 회사의 업무 자료가 필요하다면 별도의 서버 저장 경로가 있어야 한다.
그래서 자동 보관됨과 작성 중 저장됨을 같은 성공 문구로 보여 주지 않는 편이 좋다. 자동 보관은 입력 실수나 창 닫힘에서 이어 쓰도록 돕고, 서버 저장은 계정과 권한 아래에서 다시 찾을 문서를 만든다. 저장하지 않은 입력을 확정 전표와 같은 목록에서 같은 표시로 보여 주면 직원이 이미 회사에 보관했다고 오해할 수 있다. 대표가 보는 현황에도 개인 브라우저의 임시 입력을 실적으로 섞지 않아야 한다.
복구할 값의 형식도 확인해야 한다
오래된 임시본이 새 화면에서 그대로 동작한다는 보장은 없다. 보관된 코드에는 형식 버전과 문서 종류, 품목 행 배열과 일부 문자열 값을 확인하는 규칙이 있다. 알 수 없는 값이나 손상된 JSON을 읽다가 화면 전체가 실패하는 대신 인식할 수 있는 초안을 구별한다. 읽지 못한 자료를 자동으로 지우지 않는 것도 복구 관점에서 의미가 있다. 나중에 확인할 단서까지 없애지 않기 때문이다.
다만 형식을 통과한 임시본이 업무적으로 유효한 전표라는 뜻은 아니다. 거래처가 중지됐거나 가격과 권한이 바뀌었을 수 있다. 복원 뒤 서버 저장과 확정에서는 현재 조건을 다시 확인해야 한다. 이미 써 둔 비고와 사용자가 수정한 값에 새로운 기본값을 덮어쓰는지도 살펴야 한다. 편리한 복원이 과거의 가정을 지금의 확정된 사실로 바꾸지 않게 하는 경계다.
여러 창의 입력을 한 칸에 덮어쓰지 않는다
동시에 다른 거래를 작성할 수 있다면 임시본도 구분할 식별자가 필요하다. 마지막으로 열린 창 하나의 자료만 공통 키에 넣으면 앞 창의 입력이 사라질 수 있다. 읽기 목록과 개별 저장을 분리하고 갱신 시각을 남기면 사용자가 어느 내용을 이어 쓰는지 판단하기 쉽다. 정렬을 최신순으로 하더라도 가장 최근 초안을 자동으로 다른 업무에 적용해서는 안 된다.
보관된 삭제 함수는 예상한 수정 시각과 현재 값이 다르면 삭제하지 않는 조건을 갖고 있다. 이전 화면이 새로 바뀐 임시본을 지우는 실수를 줄이려는 장치다. 이것만으로 모든 동시 실행을 원자적으로 해결했다고 말할 수는 없다. 저장소의 읽기와 삭제 사이 경쟁은 별도 문제다. 다른 창에서 수정한 값을 어떻게 알리고 충돌을 처리할지까지 사용하는 프로그램의 범위에 맞게 정해야 한다.
보관에 실패했을 때도 입력은 남겨야 한다
브라우저 저장소는 용량이나 사용 제한 때문에 실패할 수 있다. 큰 임시본을 무한히 넣기보다 크기 경계를 정하고 서버의 작성 중 저장을 안내할 수 있다. 가장 피해야 할 동작은 보관에 실패했는데 입력을 초기화하는 것이다. 사용자에게 현재 화면의 값이 남아 있는지, 어떤 저장 경로를 사용해야 하는지 설명해야 복구 기능이 실제 도움으로 이어진다. 조용한 실패보다 해결할 수 있는 안내가 필요하다.
합성 자료로 새로고침 복구, 두 창의 다른 문서, 손상된 보관 값, 형식 변경, 보관 용량 실패와 삭제 충돌을 준비해 보자. 서버에 저장한 뒤 어떤 임시본을 지울지도 확인한다. 이번 글은 보관된 저장 함수와 검사 코드를 읽은 설명이며 실제 작성 중인 창의 자료를 열거나 수정하지 않았다. 자동 보관은 회사의 영구 저장과 구별될 때 믿을 수 있다. 편한 기능일수록 사용자가 그 기능을 어디까지 믿어도 되는지 명확히 알려 줘야 한다.