BABY DAY를 PWA로 운영하면서 “배포는 성공했는데 내 휴대폰에서는 예전 화면이 보인다”는 상황을 만났다. 서버가 이전 파일을 보내고 있다고 생각하기 쉽지만, 실제 원인은 브라우저에 남아 있는 Service Worker와 캐시일 수 있었다.
시크릿 창에서 최신 화면이 보였다
문제를 확인할 때 일반 Chrome 창에서는 이전 UI가 남아 있었지만 시크릿 창에서는 최신 화면이 바로 보였다. 같은 URL, 같은 서버인데 결과가 달랐다면 서버 배포 자체보다 브라우저 로컬 상태를 먼저 의심할 근거가 된다.
Service Worker가 활성 상태로 페이지 요청을 제어하고 있으면 새 번들이 서버에 올라와도 사용자는 기존 worker가 관리하는 캐시를 계속 사용할 수 있다.
BABY DAY에서 실제로 바꾼 업데이트 정책
처음에는 새 버전이 있으면 가능한 한 빨리 적용되는 쪽이 편하다고 봤다. 하지만 실제 사용자가 기록을 입력하는 PWA에서는 사용 중인 화면이 갑자기 교체되는 것도 위험할 수 있었다.
그래서 업데이트 전략을 다음처럼 바꿨다.
- Service Worker 등록 방식을 자동 적용 중심에서 업데이트 감지 후 적용 방식으로 변경
- Workbox의
skipWaiting을 항상 강제하지 않도록 설정 - 새 버전을 발견하면 사용자가 전환 시점을 알 수 있는 흐름을 우선
- 신규 방문 브라우저와 이미 설치된 PWA를 별도 시나리오로 테스트
핵심은 “최신 버전이 존재한다”와 “현재 사용자가 최신 버전을 보고 있다”를 같은 상태로 취급하지 않는 것이었다.
새 Service Worker가 설치됐다고 바로 활성화되는 것은 아니다
Service Worker는 일반적으로 설치된 뒤 기존 worker가 사용 중이면 waiting 상태에 머물 수 있다. 여러 탭이나 설치된 PWA 창이 기존 worker를 사용하고 있으면 업데이트 적용 시점이 더 늦어질 수 있다.
skipWaiting을 무조건 호출하면 최신 버전 전환은 빨라지지만, 사용자가 입력 중인 상태나 서로 다른 버전의 자산이 섞이는 문제를 고려해야 한다. 그래서 BABY DAY에서는 자동 즉시 전환보다 업데이트를 발견했을 때 사용자에게 새 버전 적용을 안내하는 방향을 택했다.
업데이트 전략을 바꿀 때 이전 버전도 생각해야 한다
운영 중에 자동 업데이트 방식에서 사용자 확인 방식으로 바꾸면 새로운 코드만 올바르게 작성했다고 끝나지 않는다. 이미 사용자 브라우저에 설치되어 있는 “이전 업데이트 로직”이 새 Service Worker를 어떻게 처리할지도 봐야 한다.
새 버전의 UI는 waiting worker를 감지하고 업데이트 버튼을 보여주더라도, 이전 버전의 JavaScript에는 그 UI 자체가 없다. 이때 기존 창이 오래 살아 있으면 최신 버전으로 넘어가는 연결 고리가 부족할 수 있다.
배포 확인은 새 브라우저 상태와 기존 브라우저 상태를 나눠서 한다
PWA 배포 후에는 최소한 다음을 따로 확인하는 편이 좋다.
- 처음 방문하는 브라우저에서 최신 버전이 정상 로드되는지
- 기존 사용자가 페이지를 새로 열었을 때 업데이트가 감지되는지
- 여러 탭이 열려 있을 때 전환이 어떻게 되는지
- 브라우저를 완전히 종료했다 다시 열면 정상 전환되는지
- 필요한 경우 사이트 데이터 초기화 후 최신 버전이 로드되는지
BABY DAY에서 이 문제를 겪고 나서는 배포 성공과 사용자에게 업데이트가 전달되는 것을 별개의 기능처럼 보기 시작했다.
운영 배포 자체의 체크리스트와 승인 기준은 BABY DAY 운영 배포에 승인 게이트를 둔 이유에 따로 정리했다.