Plan-C localStorage 스키마 검증 이유

플래너 localStorage 스키마 검증은 데이터를 지키려는 욕심보다 화면을 지키려는 장치에 가까워요. 플랜씨(plan-c)처럼 로그인 없이 쓰는 작은 도구는 브라우저 저장이 편하지만, 깨진 값 1개가 탭 전환과 입력 카드, 요약 화면까지 같이 흔들 수 있거든요.

직접 만들어보니 재정 플래너는 한눈에 보기와 7개 시나리오가 같은 상태를 같이 써요. 그래서 로컬 상태를 그대로 믿으면 특정 카드만 비는 게 아니라, 소득 입력부터 결과 요약까지 흐름 전체가 어색해지기 쉬웠어요.

왜 그냥 읽지 않았을까요

저는 저장값을 바로 쓰지 않고 state와 version 두 칸이 있는 형태로만 읽게 했어요. 저장소도 4개 묶음으로 나눴고, 플래너 키 plan-c-planner-v2만 현재 버전 1로 관리해요.

돌려 보니 손상된 배열을 통째로 버리면 사용감이 더 나빠졌어요. 그래서 계산기 저장 목록은 최근 100개까지만 살리고, 히스토리는 50개, 월간 체크인은 24개월까지만 복구하게 잡았어요. 화면이 완벽히 예전과 같지 않아도, 최소한 다시 입력할 수 있는 상태는 남겨 두고 싶었어요.

localStorage 읽기→state·version 확인→스키마 검증→복구 가능한 값만 병합

버전 업그레이드는 UX 작업이었어요

플래너 스토어는 버전 0 데이터를 만나면 초기 상태와 먼저 합친 뒤 다시 파싱해요. 적용해 봤더니 새 필드가 추가돼도 빈 화면 대신 기본값으로 이어져서, 사용자는 왜 갑자기 폼이 깨졌는지 고민하지 않아도 됐어요.

지출은 최대 20개, 대출은 10개, 저축 목표는 5개로 잘라 둔 것도 같은 이유예요. 프런트에서 감당 가능한 범위를 먼저 정해 두니 카드 높이와 스크롤, 비교 화면이 훨씬 안정됐어요.

localStorage 실패도 화면에서 흡수해야 해요

테스트해 보면 localStorage 쓰기가 막힌 환경도 있어요. 이때 예외를 바로 던지면 입력창이 멈추지만, 세션 메모리 fallback으로 한 번 받아 두면 사용자는 계속 흐름을 이어갈 수 있어요.

저는 이 지점이 프론트엔드 구현에서 꽤 중요하다고 봐요. 로컬 상태는 빠르지만 영원히 맞는 값은 아니에요. 그래서 플래너처럼 화면 조각이 많은 UI일수록, 저장보다 검증과 복구를 먼저 붙여 보세요. 관련해서 Zustand persist의 첫 렌더 이슈는 이 글과 같이 보면 흐름이 더 잘 잡혀요.