Service Worker 생명주기와 Cache Storage의 버전 관리

Service Worker는 범위(scope)에 속한 페이지의 요청·기능 이벤트를 처리할 수 있는 worker입니다. 등록 뒤 설치 단계에서 install 이벤트를 받고, waitUntil()에 연결한 Promise의 성공 여부가 설치 완료에 영향을 줍니다. 새 worker가 설치되더라도 기존 worker가 제어 중인 client가 남아 있으면 대기 상태에 머무를 수 있습니다. 기본 lifecycle은 서로 다른 사이트 버전이 동시에 동작할 때의 충돌을 줄이려는 설계입니다. Cache Storage는 응답을 저장하는 API이며, 어떤 자원을 언제 캐시하고 갱신할지는 개발자가 구현해야 합니다. 브라우저 HTTP cache와 자동으로 일치하거나 자동 갱신되지 않습니다.

전문가 관점: 브라우저 엔지니어 Jake Archibald의 lifecycle 분석

Jake Archibald의 lifecycle 해설은 새 worker가 준비된 뒤 기존 worker가 더는 client를 제어하지 않을 때 활성화되는 기본 동작을 설명합니다. skipWaiting()은 대기 단계를 건너뛰게 하고, clients.claim()은 활성 worker가 범위 내 기존 client를 제어하게 할 수 있습니다. 두 기능은 오래된 페이지와 새 worker가 함께 동작할 수 있어 자원·API 호환성 문제를 만들 수 있습니다. 저자는 이 동작을 개발 중 단순히 켜는 상용구로 취급하지 말라고 경고합니다. 새 worker에서 즉시 제어권을 가져올 필요가 있는지와 페이지의 이전 버전 호환성을 먼저 검토하세요.

설치·활성화와 캐시 정리 전략

필수 오프라인 자원은 설치 중 캐시하고, Promise를 waitUntil()에 전달해 설치가 성공하기 전에 worker가 활성화되지 않도록 구성할 수 있습니다. 설치 실패 시 현재 활성 worker는 유지되고 새 worker는 폐기됩니다. 캐시 이름에 애플리케이션 식별자와 버전을 포함하면 활성화 단계에서 자신이 관리하는 이전 캐시만 정리하기 쉽습니다. 같은 origin에서 여러 앱이 Cache Storage를 공유할 수 있으므로 이름이 다르지 않은 캐시를 무차별 삭제하지 마세요. activate 작업이 완료되기 전 fetch 처리와 자원 이동이 어긋나지 않도록 lifecycle 이벤트에 작업 Promise를 연결합니다.

저장 공간·캐시 정합성·실제 브라우저 테스트

Cache Storage의 데이터는 브라우저가 관리하는 origin 저장 공간을 사용하며, 무기한 보존을 보장하지 않습니다. 저장 공간이 부족하면 데이터가 퇴출될 수 있고, 사용자나 브라우저 설정으로 삭제될 수도 있습니다. 캐시만으로 중요한 사용자 데이터를 보존하지 말고, 네트워크 실패·캐시 누락·스키마 변경 시 복구 경로를 제공하세요. Service Worker script는 HTTPS 같은 secure context에서 사용하며 scope를 점검해야 합니다. 두 개 이상의 열린 탭, 새 버전 대기, skipWaiting() 중 업데이트, 오프라인 설치 실패, 구버전 캐시 제거를 대상으로 지원 브라우저에서 검증하세요.

가상 상황: 호환되지 않는 새 캐시 형식이 대기 중일 때

구버전 결제 페이지가 열린 상태에서 새 Service Worker가 설치됐지만, 새 캐시 형식은 구버전 페이지와 호환되지 않는다고 가정해 보세요. 이 경우 업데이트를 서두르려고 skipWaiting()을 호출하지 않고, 기존 탭이 닫힌 뒤 새 worker가 활성화되도록 기다리는 편이 안전합니다. 기대 결과는 열린 페이지가 기존 worker와 캐시를 계속 사용하고, 대기 중인 업데이트는 구버전 클라이언트가 사라진 뒤 적용되는 것입니다. 즉시 전환이 필요하다면 두 버전의 호환성을 먼저 확인하고 실제 대상 브라우저에서 전환을 시험하세요. 이는 동작 원리를 설명하는 가상 사례이며, 특정 앱에서 실행한 결과가 아닙니다. ( W3C Service Workers )

참고 자료