페이지 넘기면 초기화되는 데이터? 기획 단계에서 잡는 글로벌 상태 체크리스트
페이지 넘기면 초기화되는 데이터? 기획 단계에서 잡는 글로벌 상태 체크리스트
개발자와 회의하다 보면 이런 말을 듣곤 합니다. “그건 전역 상태(Global State)로 관리해야 해서 공수가 좀 들어요.” 혹은 “페이지 이동하면 데이터가 날아가는 게 기본 동작입니다.”
기획자 입장에서는 “당연히 유지돼야 하는 정보”인데, 개발에서는 왜 별도 설계가 필요할까요? 결론부터 말하면, 유지 범위를 정의하지 않으면 서비스는 “기억력 3초짜리 금붕어 모드”가 됩니다 🐟 오늘은 React 기반 프로젝트에서 데이터 유실 버그를 미리 차단하는 글로벌 상태 체크리스트를 핵심만 정리합니다.
1. 전역 상태(Global State), 왜 기획자가 알아야 할까?
React는 기본적으로 컴포넌트 단위로 상태가 존재합니다. 특정 페이지(화면)에서만 쓰는 데이터는 그 페이지를 떠나는 순간 “자연 소멸”이 기본값입니다. 그래서 페이지 이동/라우팅이 일어나면, 개발 관점에서는 상태를 어디에 둘지를 다시 결정해야 합니다.
하지만 서비스 흐름상 페이지가 바뀌어도 살아남아야 하는 데이터가 있습니다. 예를 들면:
- 로그인 세션(인증 토큰, 사용자 기본정보)
- 장바구니 담긴 상품과 헤더 배지 숫자
- 검색 필터/정렬, 페이지네이션, 스크롤 위치
- 작성 중인 임시저장 폼(문의/리뷰/게시글)
이걸 기획 단계에서 정의하지 않으면, 유저는 뒤로가기 한 번에 필터가 풀리고, 새로고침 한 번에 작성 중인 내용이 증발하는 경험을 하게 됩니다. 결국 CS는 “데이터 사라졌어요”로 폭죽처럼 터집니다 🎇
기획자가 최소로 결정해야 하는 3가지
- 무엇을 유지할 것인가 (유지 대상)
- 언제까지 유지할 것인가 (페이지 이동까지? 탭 닫기까지? 재접속까지?)
- 어떤 사건에 초기화할 것인가 (로그아웃, 결제 완료, 권한 변경, 만료 등)
2. 기획자가 챙겨야 할 3대 글로벌 상태 체크리스트
① 로그인 및 사용자 인증(Auth)
가장 기본이지만 놓치면 치명적입니다. “로그인 유지”는 구현이 아니라 정책입니다.
- 새로고침해도 로그인이 유지되는가?
- 탭을 닫았다가 다시 열면 로그인은 유지되는가?
- 마이페이지 진입 시 매번 서버에서 유저 정보를 새로 불러올 것인가, 일부는 브라우저가 기억하게 할 것인가?
- 권한(관리자/일반)이 바뀌었을 때 UI는 즉시 반영되는가?
- 로그아웃 시 어떤 데이터까지 즉시 삭제되는가?
팁: 인증 관련 상태는 “편의”보다 “안전”이 먼저입니다. 유지 범위를 과하게 잡으면 보안 이슈가 납니다.
② 장바구니 및 위시리스트(Cart)
커머스 서비스라면 장바구니는 ‘전역 상태의 교과서’입니다. 장바구니는 화면 하나의 기능이 아니라, 헤더/상세/목록/결제까지 전 구간에서 참조합니다.
- 상품 상세에서 ‘담기’ 후 목록으로 돌아가면 헤더 배지 숫자가 즉시 업데이트되는가?
- 페이지 이동을 반복해도 담긴 상품이 유지되는가?
- 비로그인 장바구니를 허용하는가? 허용한다면 로그인 시 병합 규칙은?
- 품절/가격 변경 시 장바구니는 어떤 메시지/규칙으로 보정되는가?
③ 검색 필터 및 정렬 조건(Filter)
UX에서 가장 자주 터지는 버그 구간입니다. 필터는 “있으면 좋음”이 아니라, “없으면 화남” 쪽입니다 😈
- 목록에서 3페이지 보다가 상세를 보고 뒤로가면 여전히 3페이지인가?
- 적용했던 ‘가격 낮은 순’ 정렬이 풀리지 않는가?
- 필터/검색어가 URL로 공유될 필요가 있는가? (공유/딥링크 요구)
- 필터 초기화 버튼은 어떤 범위까지 초기화하는가? (카테고리만? 가격 범위까지?)
3. “유지 범위”를 한 줄로 못 박는 프레임
개발자에게 “잘 부탁드려요” 대신, 기획서 하단이나 피그마 코멘트에 아래처럼 데이터 유지 조건을 명시하면 커뮤니케이션 비용이 확 줄어듭니다.
데이터 유지 조건 표(기획서에 그대로 붙여도 되는 버전)
| 유저 시나리오 | 기대 동작(Status) | 유지 범위 | 초기화 트리거 | 비고 |
|---|---|---|---|---|
| 목록 → 상세 → 뒤로가기 | 이전 목록의 스크롤 위치, 페이지네이션, 필터값 유지 | 라우팅 이동(뒤로가기)까지 | 필터 초기화 버튼, 카테고리 변경 | UX 핵심 구간 |
| 상품 담기 → 페이지 이동 | 헤더 장바구니 배지 즉시 갱신, 담긴 목록 유지 | 세션 종료까지(또는 로그인 전환 시 병합) | 결제 완료, 장바구니 비우기 | 전역 상태 필수 |
| 로그인 후 새로고침 | 로그인 유지, 사용자 기본정보 재로딩 정책 적용 | 정책에 따름(예: N일) | 로그아웃, 만료, 비밀번호 변경 | 보안/정책 합의 필요 |
| 로그아웃 | 브라우저 내 개인 정보 및 개인화 데이터 즉시 초기화 | 즉시 | 로그아웃 클릭 | 토큰/캐시/로컬 데이터 포함 |
| 폼 작성 중 화면 이탈 | 임시저장/복원 여부 정책 적용 (선택) | 탭 유지 또는 재접속까지(선택) | 제출 완료, 취소, 만료 | 문구/알림 필요 |
추가로 붙이면 강해지는 문장 템플릿
- “해당 값은 페이지 이동에도 유지되어야 하며, 로그아웃 시 즉시 삭제한다.”
- “뒤로가기는 브라우저 히스토리 기준이며, 목록 복원에는 스크롤 위치 포함한다.”
- “필터는 URL 공유가 가능해야 한다/없어도 된다(선택).”
4. 전역 상태 설계에서 자주 터지는 함정 6가지
1) “페이지 이동”의 정의가 서로 다르다
기획은 “상세 갔다가 뒤로가기”를 말했는데, 개발은 “라우트 변경”을, QA는 “새로고침”을 끼워 넣는 순간… 데이터가 증발합니다. 문서에 라우팅/뒤로가기/새로고침/탭 종료를 각각 분리해 적어두면 깔끔합니다.
2) 유지 범위를 ‘영원히’로 잡아버린다
전역 상태는 편하지만, 과도하면 부작용이 큽니다. 오래 유지되는 값은 만료 규칙이 반드시 필요합니다. (예: 30분 미활동 시 만료)
3) URL vs 전역 상태 vs 저장소의 역할이 섞인다
공유해야 하는 검색 조건은 URL이 더 적합한 경우가 많고, 새로고침에도 유지돼야 하면 Web Storage(세션/로컬)를 고려합니다. “한 군데에 다 넣자”는 발상은 보통 디버깅 지옥의 문을 엽니다 🔥
4) 캐시(서버 데이터)와 UI 상태를 구분하지 않는다
예: “유저 정보”, “상품 목록” 같은 서버 데이터는 캐싱 전략(재요청/만료)이 중요하고, “모달 열림”, “선택된 탭”, “필터 UI 값” 같은 UI 상태는 UX 정책이 중요합니다. 둘을 같은 표에 섞어두면 우선순위가 꼬입니다.
5) ‘초기화 트리거’를 빼먹는다
로그아웃, 결제 완료, 권한 변경, 계정 전환, 쿠폰 적용 실패 등 상태를 리셋해야 하는 사건을 목록으로 뽑아두면 버그가 급감합니다.
6) 에러/빈 상태(Empty) 플로우에서 무너진다
네트워크 실패, 품절, 세션 만료 같은 예외 상황에서 “필터는 유지할지”, “토스트는 보여줄지”, “어디로 리다이렉트할지”가 빠지기 쉽습니다. 전역 상태 체크리스트는 예외 케이스까지 포함할 때 진짜 힘을 냅니다.
5. 마치며: 기획이 탄탄하면 버그가 줄어듭니다
데이터가 어디까지 유지되어야 하는지 결정하는 건 “개발 디테일”이 아니라 서비스 정책입니다. 페이지 이동 시 데이터가 초기화되는 현상을 “그럴 수도 있지”로 넘기면, 오픈 후에는 유저가 “그럴 수도 없지”로 돌려줍니다 😵💫
오늘의 핵심은 단 하나입니다. 유지 대상 + 유지 범위 + 초기화 트리거를 기획서에 명시하세요. 그 한 줄이, 릴리즈 후 밤샘 버그픽스를 한 번은 줄여줍니다.
참고 링크(공식 문서)
FAQ
Q “전역 상태”는 무조건 Redux 같은 걸 써야 하나요?
A 기획 단계에서는 “어떤 라이브러리”보다 무엇을 어디까지 유지할지가 핵심입니다. 구현 도구(Redux/Zustand/Context 등)는 팀의 선택 영역이고, 기획은 정책과 기대 동작을 명확히 써주는 쪽이 가장 큰 기여입니다.
Q 뒤로가기 시 스크롤 위치 유지가 왜 이렇게 까다롭죠?
A 스크롤 위치는 단순 숫자가 아니라, 목록 재렌더링/데이터 재요청/이미지 로딩 등과 얽힙니다. 그래서 “상세 → 뒤로가기”에서 목록 데이터 캐시와 UI 상태(스크롤/페이지)를 함께 복원해야 자연스럽게 보입니다. 기획서는 최소한 “유지 대상(스크롤 포함)”을 못 박아주면 됩니다.
Q 필터는 URL로 넣는 게 좋나요, 전역 상태가 좋나요?
A “공유/딥링크/새로고침 복원” 요구가 강하면 URL이 유리한 경우가 많고, “개인적인 UI 편의”면 전역 상태나 저장소가 더 간단할 수 있습니다. 기획 관점에서는 “필터 공유 필요 여부”와 “새로고침 복원 필요 여부”를 먼저 결정하면 선택이 쉬워집니다.
Q 로그아웃 시 어떤 것까지 초기화해야 하나요?
A 원칙은 “개인 식별 가능한 것(PII) + 개인화된 것 + 권한에 따라 달라지는 것”은 싹 초기화입니다. 예: 토큰, 사용자 정보, 관심/위시, 최근 본 상품(정책에 따라), 개인화 추천 캐시 등. 기획서에 “로그아웃 시 브라우저 내 개인 정보 즉시 초기화”를 명시하고, 구체 항목은 체크리스트로 붙이면 QA에서 강력한 기준점이 됩니다.
Q ‘임시저장’은 전역 상태로 보면 되나요?
A 네, “페이지를 떠나도 살아남아야 하는 작성 데이터”라면 전역 상태 후보입니다. 다만 임시저장은 UX 문구(나가기 경고/복원 안내)와 만료 정책(예: 7일 보관)이 붙는 순간 구현 난도가 달라지므로, 기획 단계에서 “복원 범위”와 “만료”를 반드시 정의해두면 좋습니다.