워크이마트 걸음수 전체 구조

쉽게 말하면, 위젯과 미션 페이지가 같은 걸음수 측정기를 함께 조작합니다. 위젯이 측정기를 끄면, 미션 페이지가 그 사실을 즉시 모를 수 있습니다.

0. 핵심 결론

새 미션 페이지 진입 시 API 에러가 먼저 나면 안전합니다.
미션 API 에러 → 게이트 이동 → startWalk 실행 안 됨.

가장 위험한 것은 미션 페이지가 이미 열린 상태에서 위젯이 stopWalk하는 경우입니다.
화면은 이전 걸음수를 계속 보여주지만 실제 측정은 멈춥니다. 나중에 다시 시작하면 새 세션의 작은 걸음수가 이전 누적값을 덮을 수 있습니다.

1. 정상 진입 흐름

게이트 진입
→
GET /gate
→
이용 가능?
→
QR 확인
→
getWalkStatus
→
startWalk
→
POST /start
→
미션 페이지

2. 미션 페이지의 걸음수 처리

네이티브 setStepCount 콜백 → updateStepCount(steps) → 화면 숫자 변경 → localStorage 저장: walkEmart_stepCount_{eventId} → walking-log 전송(throttle 20초) → 목표 걸음수 이상이면 WALKING 미션 버튼 활성화

stop 시 네이티브 내부 걸음수는 0으로 초기화되지만, stop 순간 기존 JS 콜백에 0을 보내지는 않습니다. JS 콜백 연결도 끊지 않습니다.

3. 진행 불가 상태의 신규 진입

안전미션 페이지 직접 진입

미션 API 에러가 startWalk보다 먼저 발생합니다.

GET /main 또는 /missions 에러 → initializeMission 중단 → resumeOrStart 실행 안 함 → startWalk 실행 안 함 → 게이트로 이동

안전started=true 게이트 진입

게이트에서 미션 페이지로 이동해도, 미션 API가 다시 검증합니다. 운영시간 외면 에러 후 게이트로 돌아갑니다.

주의started=false 시작 플로우

네이티브 startWalk가 서버 POST /start보다 먼저 실행됩니다. 네이티브가 허용했는데 서버가 거부하면 네이티브 측정만 남을 수 있습니다. 현재 start API 실패 시 stop 롤백이 없습니다.

4. 위젯이 백그라운드에서 stopWalk한 경우

미션 페이지: 화면 8,000걸음 / 네이티브 measuring / JS 콜백 연결 → 앱 백그라운드 → 위젯 API: 진행 불가 → 위젯 stopWalk → 네이티브: idle + 내부 걸음수 0 → 기존 JS 콜백에는 0 미전달 → 앱 포그라운드

포그라운드 직후의 확정 상태

영역상태
프론트 화면8,000걸음 유지
localStorage8,000걸음 유지
네이티브idle, 내부 걸음수 0
JS 콜백연결 유지
실제 측정중지

현재 미션 페이지는 Foreground를 처리하지 않습니다. Active에서도 EMART_PAY 미션만 재조회합니다. 따라서 포그라운드 직후 자동 startWalk나 상태 재검증은 없습니다.

5. 포그라운드 뒤 다시 startWalk가 실행되면

화면: 8,000걸음 → 어떤 경로로든 startWalk 실행 → 네이티브는 0부터 재측정 → 첫 콜백 20걸음 수신 → updateStepCount(20) → 화면 8,000 → 20 → localStorage 8,000 → 20 → walking-log 20 전송 가능
stop 순간에 화면이 바로 0으로 바뀌는 것은 아닙니다.
0은 기존 콜백으로 전달되지 않습니다. 다시 startWalk한 뒤 첫 새 걸음수 콜백이 도착할 때 작은 값으로 바뀝니다.

6. 백그라운드 → 포그라운드 케이스

상황현재 동작결과
미션 페이지 유지Foreground 처리 없음이전 걸음수 고정, 실제 측정 중지
미션 페이지 유지 후 재시작새 콜백을 기존 값에 그대로 대입8,000 → 20처럼 급감, 저장·로그도 새 값으로 변경
웹뷰 재생성 + 진행 불가 APIAPI 에러 후 게이트 이동startWalk 실행 안 됨
웹뷰 재생성 + API 성공idle 확인 후 startWalk0부터 재측정, 첫 콜백이 기존 값을 덮음
게이트 화면 유지Foreground 재조회 없음오래된 accessible/started/button 상태 유지

7. API 에러 흐름

게이트 API

운영시간 외·비운영 요일·대상 점포 아님 등은 게이트 안내를 표시합니다. measuring이면 stopWalk를 호출합니다.

메인·미션 목록 API

게이트 리다이렉트 코드이면 예외 처리 후 router.replace(Gate)합니다. 이 에러가 발생하면 미션 페이지의 startWalk까지 가지 않습니다.

부가 API

랭킹·배너·건강 다이어리·추천상품은 병렬 호출됩니다. 일부 응답은 게이트 이동 직전까지 남을 수 있습니다.

8. 현재 코드에서 중요한 빈틈

9. 권장 방어 흐름

  1. Foreground/Active 복귀 시 서버 이용 가능 여부를 재조회합니다.
  2. 진행 불가면 기존 화면 값은 보존하되 측정 중지 상태를 표시하고 로그 전송을 막습니다.
  3. 진행 가능하면 getWalkStatus로 실제 네이티브 상태를 확인합니다.
  4. idle이면 새 세션을 시작하되, 기존 당일 누적값과 새 세션 값을 분리합니다.
  5. stop과 start를 위젯·프론트가 동시에 호출하지 않도록 네이티브에서 직렬화합니다.
  6. 서버는 같은 이벤트·당일의 감소값을 최신 누적값으로 덮지 않도록 방어합니다.
  7. POST /start 실패 시 네이티브 측정을 롤백하거나, 네이티브가 서버 가능 여부를 확인한 뒤 시작합니다.
한 줄 결론: 신규 진입은 API 에러가 startWalk보다 먼저 막아주므로 비교적 안전합니다. 진짜 문제는 이미 열린 미션 페이지에서 위젯이 stop한 뒤, 화면은 이전 값으로 남고 실제 측정만 멈추는 상태입니다. 이후 재시작하면 새 세션의 작은 걸음수가 이전 누적값을 덮을 수 있습니다.