새로고침을 견디는 풀이 상태와 다시 들어올 수 있는 경기 기록

교육 플랫폼에서는 새로고침 뒤에도 풀이 상태를 유지해야 했다. 배구 기록판에서는 저장한 뒤 브라우저를 나가면 기존 경기로 다시 들어올 수 없다는 문제가 있었다. 서로 다른 프로젝트지만, 돌아보면 같은 질문으로 이어진다. 사용자가 말하는 “저장”은 어디까지일까.

저장소에 값이 있다는 것만으로는 부족했다

교육 플랫폼에서는 Zustand의 persist와 sessionStorage를 연결해 새로고침에 대응했다. 이 선택은 현재 탭의 작업을 이어 가는 요구와 잘 맞았다. 하지만 탭을 닫고 나중에 다른 기기에서 이어 하는 요구까지 해결하는 것은 아니다. 저장 범위를 설명하지 않으면 개발자와 사용자가 같은 단어로 다른 기능을 생각하게 된다.

배구 기록판의 경우에도 사용자가 원한 것은 저장 완료 표시가 아니라 기존 경기를 다시 여는 길이었다. 당시 점검 기록은 데이터 저장과 재진입 경로를 분리해서 살펴봐야 한다는 방향을 보여 주었다. 데이터를 복원할 열쇠가 화면에서 사라지면, 사용자에게는 데이터가 사라진 것과 비슷하다.

복원 시나리오를 먼저 적는다면

사용자 행동	확인해야 할 것
같은 탭에서 새로고침	상태 직렬화와 초기 복원
브라우저를 닫고 재방문	경기 목록 또는 다시 열기 링크
다른 기기에서 접속	계정·권한에 연결된 조회 경로
오래된 기록 열기	변경된 데이터 형식과의 호환성

이 표의 기능을 모두 구현해야 한다는 뜻은 아니다. 지원할 범위를 먼저 정하고, 지원하지 않는 범위를 UI와 설계에서 혼동하지 않는 것이 중요하다. 초대 링크를 사용하는 구조라면 링크를 잃었을 때의 복구와 링크를 가진 사람의 권한도 함께 생각해야 한다.

완료 기준을 바꾸게 된 경험

지금이라면 저장 버튼을 누른 직후의 응답만으로 검증을 끝내지 않겠다. 페이지를 떠났다가 실제로 돌아와 같은 기록을 여는 데까지 확인하겠다. 저장된 값과 화면에 복원된 값이 일치하는지도 그 흐름 안에서 살펴보겠다.

이 경험은 저장 기술보다 사용자 여정을 먼저 보게 만들었다. 데이터가 남는 것은 시스템의 조건이다. 사용자가 그 데이터로 다시 일을 할 수 있는 것이 제품의 조건이다. 둘을 따로 적어야 빠진 경로가 보였다.

기술 참고: MDN sessionStorage