WebView 미니앱 - 토스 로그인 성공 직후 SDK Storage(persist) rehydration 타이밍으로 토큰이 덮어써지는 현상 문의

개발
,
1

이 글의 성격은 무엇인가요?

질문 / 문제 해결

내용을 설명해주세요

개발 환경: WebView 미니앱 (Next.js + @apps-in-toss/web-framework 2.5.0)
테스트 환경: 콘솔 빌드 업로드 → QR 실행 (샌드박스/실기기)
상태 관리: Zustand persist 어댑터로 SDK Storage(getItem/setItem) 사용

[증상]
토스 로그인(appLogin → 자체 BE 토큰 교환)은 성공합니다(BE 로그상 토큰 정상 발급).
그런데 로그인 직후 첫 인증 API(/me) 호출이 간헐적으로 실패하며,
재시도 화면(“정보를 불러오지 못했어요”)으로 떨어집니다.
앱을 완전 종료 후 재실행하면 정상 동작할 때가 많아, 콜드 스타트 타이밍 의존이 의심됩니다.

[구조]

  • 로그인 성공 시 Zustand store 메모리에 accessToken/refreshToken을 즉시 set
  • persist는 refreshToken만 SDK Storage에 저장 (partialize)
  • 앱 부팅 시 persist가 SDK Storage에서 비동기 rehydration

[의심하는 원인 — 확인 요청]
SDK Storage의 getItem/setItem이 Promise(비동기)이고 네이티브 브리지라 느리다 보니,
"로그인으로 막 set한 토큰"보다 "부팅 시 시작된 rehydration"이 늦게 도착해
메모리의 fresh 토큰을 과거값/null로 덮어쓰는 레이스가 의심됩니다.
local(브라우저 localStorage) 환경에선 재현되지 않고, 토스 SDK Storage 환경에서만 나타납니다.

[질문]

  1. SDK Storage(getItem/setItem)의 호출 지연/완료 순서에 대해 보장되는 동작이 있나요?
    (예: 부팅 직후 첫 getItem이 수백 ms~초 단위로 지연될 수 있는지)
  2. Zustand persist 같은 비동기 rehydration 어댑터와 함께 쓸 때,
    토스 측에서 권장하는 hydration 완료 감지/순서 보장 패턴이 있나요?
  3. WebView 환경에서 SDK Storage 접근이 hang되거나 크게 지연된 사례가 보고된 적 있나요?
    (web-framework 2.5.0 기준)

appName (선택)

ppojjak-log

2

안녕하세요 :slight_smile:
web-framework 2.5.0 기준으로 SDK Storage getItem/setItem이 일반적으로 수 초 단위로 hang되거나 크게 지연되는 이슈는 확인된 바 없습니다.
persist hydration 완료 여부를 isAuthReady 또는 isHydrated 같은 별도 상태로 관리하고, 해당 값이 true가 된 이후에 /me 같은 인증 API 호출을 시작해봐 주실 수 있을까요?

3

답변 감사합니다. 원인을 추적해보니 SDK Storage 지연 자체보다는, 로그인 직후 set한 토큰을 늦게 도착한 persist rehydration이 덮어쓰는 merge 레이스였습니다. zustand persist의 커스텀 merge에서 “메모리에 이미 인증 토큰이 있으면 persisted 값으로 덮어쓰지 않도록” 가드를 추가해 해결했고, 말씀해주신 isHydrated 게이팅도 콜드스타트 경로 안전장치로 함께 검토하겠습니다.