프론트엔드 · PWA · 서비스워커
서비스워커 오프라인 UX 설계 가이드: 네트워크가 불안정해도 신뢰를 잃지 않는 화면 기준
정답부터 말하면, 서비스워커 오프라인 UX 설계의 핵심은 ‘웹앱을 무조건 오프라인에서도 작동시키는 것’이 아닙니다. 화면별로 캐시해도 되는 정보, 항상 최신이어야 하는 정보, 실패하면 반드시 복구해야 하는 사용자 행동을 나누는 일입니다. 가격, 재고, 결제, 승인, 권한 같은 정보를 오래된 캐시로 보여주면 페이지가 빨라진 것이 아니라 신뢰가 깨집니다. 반대로 도움말, 최근 열람한 보고서, 작성 중 임시저장, 현장 점검 초안은 캐시와 재시도 UX가 실제 손실을 줄입니다.
대표나 PM 입장에서 중요한 질문은 ‘PWA를 넣을까?’가 아니라 ‘우리 서비스에서 오프라인이어도 보여줘도 되는 화면은 어디까지인가?’입니다. 이 글은 사업 홈페이지, SaaS, 모바일 웹, 현장 업무용 MVP에서 서비스워커 캐시·오프라인 안내·재시도 UX를 결정하는 실무 기준을 정리합니다.
1. 오프라인 UX의 목표는 ‘전부 작동’이 아니라 ‘신뢰 가능한 상태 표시’입니다
네트워크가 불안정한 환경은 생각보다 흔합니다. 전시장 부스에서 상담 폼을 입력할 때, 물류 창고에서 QR 점검 화면을 열 때, 공공기관 행사장에서 모바일 신청서를 받을 때, B2B SaaS를 이동 중 LTE 환경에서 확인할 때 화면이 멈추면 사용자는 기능보다 ‘데이터가 날아갔는지’를 먼저 걱정합니다.
오프라인 UX의 좋은 기준은 단순합니다. 사용자가 지금 보는 데이터가 최신인지, 아니면 캐시된 이전 데이터인지 알 수 있어야 합니다. 사용자가 방금 누른 저장·제출·승인 버튼이 서버에 반영됐는지, 기기에 임시 저장됐는지, 실패했는지 구분되어야 합니다. 그리고 실패했다면 사용자가 무엇을 다시 눌러야 하는지 보여줘야 합니다.
서비스워커는 신뢰를 자동으로 만들어주지 않습니다. 신뢰는 ‘무엇을 캐시하지 않을지’와 ‘실패를 어떻게 설명할지’에서 만들어집니다.
성능 최적화와도 구분해야 합니다. 정적 자산 캐싱은 첫 화면 속도를 개선할 수 있지만, 오프라인 UX는 업무 결과의 복구 가능성까지 다룹니다. 첫 화면 성능을 함께 보고 있다면 기존 글인 Core Web Vitals 최적화 기준을 먼저 점검하고, 그 위에 서비스워커 캐시 정책을 얹는 순서가 안전합니다.
2. 서비스워커를 비즈니스 언어로 이해하기
서비스워커는 브라우저와 네트워크 사이에서 동작하는 스크립트입니다. 페이지가 요청하는 HTML, JS, CSS, 이미지, API 호출 일부를 가로채고 네트워크로 보낼지, Cache Storage에서 응답할지, 별도 fallback 화면을 줄지 결정할 수 있습니다. 그래서 기술적으로는 강력하지만, 사업 화면 관점에서는 ‘브라우저 안에 작은 요청 관리자’를 두는 것에 가깝습니다.
실무에서 자주 혼동하는 저장 위치는 네 가지입니다.
| 구분 | 주요 용도 | 주의점 |
|---|---|---|
| HTTP 브라우저 캐시 | 서버의 캐시 헤더에 따라 이미지, JS, CSS 등을 재사용 | 서비스워커 로직과 별개로 동작하므로 배포 정책과 함께 봐야 함 |
| Service Worker Cache Storage | 서비스워커가 직접 저장·조회하는 응답 캐시 | HTTP 캐시 헤더가 자동으로 모든 갱신을 해결해준다고 보면 안 됨 |
| IndexedDB | 오프라인 폼 초안, 재시도 큐, 구조화된 로컬 데이터 저장 | 브라우저 저장소 한도와 삭제 가능성을 고려해야 함 |
| 서버 데이터베이스 | 최종 업무 데이터의 원본 | 오프라인 상태의 로컬 데이터와 충돌할 수 있음 |
중요한 점은 서비스워커 캐시가 ‘서버 데이터베이스의 복제본’이 아니라는 것입니다. 브라우저 저장소는 사용자가 사이트 데이터를 삭제하거나 브라우저가 저장공간 압박을 판단하면 사라질 수 있습니다. 따라서 오프라인 기능을 업무의 원장으로 설계하면 안 되고, 임시 표시·임시 저장·재전송 대기 영역으로 설계해야 합니다.
3. 화면별 분류: 캐시 가능한 정보와 금지해야 할 정보를 먼저 나눈다
서비스워커 프로젝트가 실패하는 가장 흔한 이유는 URL 단위로만 캐시 정책을 짜기 때문입니다. 예를 들어 /api/products 응답 안에 상품명, 이미지, 가격, 재고, 프로모션 종료일이 모두 들어 있다면 어떤 필드는 캐시해도 되지만 어떤 필드는 캐시하면 위험합니다. 가능하면 캐시 가능한 읽기 데이터와 최신성이 필요한 거래 데이터를 API 또는 응답 필드 단위에서 분리해야 합니다.
| 화면·데이터 유형 | 권장 기본 전략 | 사용자에게 보여줄 상태 | 주의할 점 |
|---|---|---|---|
| 회사 소개, 도움말, 이용 가이드 | Cache First 또는 Stale While Revalidate | 필요 시 ‘업데이트된 문서가 있습니다’ 알림 | 법적 약관, 정책 변경 페이지는 별도 최신화 필요 |
| 블로그, 공지 목록 | Network First 후 캐시 fallback | ‘마지막 업데이트: 00:00’ 또는 ‘이전 저장본’ 표시 | 긴급 공지, 가격 변경 공지는 stale 표시 없이 보여주면 위험 |
| SaaS 대시보드 요약 | Network First, 짧은 타임아웃 후 캐시 fallback | ‘최신 데이터 확인 실패, 이전 데이터를 표시 중’ | 의사결정 화면이라면 필터 기준과 업데이트 시각을 함께 노출 |
| 가격, 재고, 결제, 쿠폰, 승인 | Network Only 또는 매우 제한적인 캐시 | 오프라인 시 핵심 액션 비활성화와 이유 설명 | 오래된 값으로 구매·승인·정산을 확정하게 만들면 안 됨 |
| 문의, 신청, 점검표, 설문 폼 | 로컬 초안 저장 또는 재시도 큐 | ‘기기에 임시 저장됨’, ‘연결 복구 후 전송 필요’ | 개인정보 저장 기간, 암호화, 중복 제출 방지 필요 |
| 관리자 삭제·권한 변경 | 온라인 전용 | ‘네트워크 연결 후 실행 가능’ | 충돌·중복·권한 만료 시 복구 비용이 큼 |
| AI 생성 요청, 자동화 실행 | 입력 초안만 저장, 실행은 온라인 | ‘요청 내용 저장됨, 온라인에서 실행’ | 비용 발생 API, 외부 시스템 변경 작업은 큐잉 전 승인 흐름 필요 |
이 표를 만들면 개발 범위도 명확해집니다. 모든 화면을 오프라인으로 만들겠다는 요구는 견적과 일정이 커지는 반면, ‘도움말·최근 조회·폼 초안·오프라인 안내’까지만 하겠다고 정하면 MVP에서도 충분히 실용적인 신뢰성 개선이 가능합니다.
4. 캐시 전략 선택 기준: 빠른 화면보다 위험 낮은 화면이 우선입니다
Workbox나 직접 작성한 서비스워커에서 자주 쓰는 전략은 크게 네 가지입니다. 하지만 이름보다 중요한 것은 적용 대상입니다.
| 전략 | 적합한 대상 | 장점 | 위험 |
|---|---|---|---|
| Cache First | 해시가 붙은 JS/CSS, 로고, 아이콘, 변하지 않는 이미지 | 빠르고 오프라인 가능 | 만료·버전 관리가 없으면 오래된 리소스가 남음 |
| Network First | HTML 문서, 대시보드 목록, 공지·콘텐츠 목록 | 최신성을 먼저 시도하고 실패 시 이전 데이터 제공 | 네트워크가 느릴 때 스피너가 길어질 수 있어 타임아웃 UX 필요 |
| Stale While Revalidate | 도움말, 프로필 이미지, 읽기 전용 콘텐츠 | 즉시 캐시를 보여주고 백그라운드에서 갱신 | 사용자가 오래된 데이터를 보고 있다는 사실을 모를 수 있음 |
| Network Only | 결제, 승인, 권한, 실시간 재고, 민감 API | 잘못된 stale 데이터 노출을 방지 | 오프라인 시 기능을 사용할 수 없으므로 안내와 대체 행동 필요 |
정적 자산은 해시 파일명과 프리캐시를 활용하면 효과가 큽니다. 반면 HTML 진입점과 API 응답은 배포 후 오래된 번들과 섞이는 문제가 생길 수 있으므로 더 보수적으로 접근해야 합니다. 특히 관리자 화면에서 오래된 JS가 새 API와 맞지 않으면 저장 버튼이 실패하거나 화면이 하얗게 비는 문제가 생깁니다.
캐시 만료도 정책입니다. Workbox의 ExpirationPlugin처럼 항목 수와 보관 기간을 제한하는 기능을 쓸 수 있지만, ‘30일이면 충분하다’ 같은 값은 서비스마다 다릅니다. B2B 대시보드는 하루 전 데이터도 위험할 수 있고, 도움말 이미지는 한 달 캐시해도 문제가 없을 수 있습니다. 캐시 기간은 기술팀이 임의로 정하기보다 데이터 소유자와 함께 정해야 합니다.
5. 오프라인 안내 UX: 회색 화면 하나로 끝내지 마세요
오프라인 상태 표시는 전역 배너 하나로 끝낼 수 없습니다. 사용자에게 필요한 것은 네트워크 진단 결과가 아니라 ‘지금 내가 하려는 작업이 가능한가’입니다. 같은 오프라인이라도 도움말 읽기는 가능하고, 결제는 불가능하며, 문의 폼은 임시저장만 가능할 수 있습니다.
- 전역 상태: 네트워크 문제가 서비스 전체 기능에 영향을 줄 때 상단 배너로 알립니다. 단, 단순히 회색 처리만 하지 말고 아이콘·문구·동작 버튼을 함께 제공합니다.
- 화면 상태: 대시보드에는 ‘이전 데이터 표시 중’, 공지에는 ‘최신 목록 확인 실패’, 상세 화면에는 ‘마지막 동기화 시각’을 표시합니다.
- 액션 상태: 저장 버튼은 ‘서버 저장 완료’, ‘기기에 임시 저장’, ‘전송 실패, 다시 시도’처럼 결과를 구분해야 합니다.
- 재시도 동작: 단순 새로고침보다 ‘다시 불러오기’, ‘전송 재시도’, ‘임시저장 보기’처럼 사용자의 다음 행동을 명확히 제시합니다.
navigator.onLine과 online/offline 이벤트는 참고 신호로는 유용하지만, 특정 서버가 실제로 응답 가능한지까지 보장하지는 않습니다. 사내망, 방화벽, 인증 만료, DNS 문제, API 장애는 모두 다른 문제입니다. 따라서 UX 상태는 브라우저 이벤트만 보지 말고 최근 API 실패, 짧은 health check, 요청 타임아웃, 서버 오류 코드를 함께 해석해야 합니다.
좋은 오프라인 fallback 화면은 막다른 길이 아닙니다. ‘인터넷에 연결되어 있지 않습니다’ 한 줄만 보여주는 대신, 이전에 열람한 문서, 임시 저장된 폼, 다시 시도 버튼, 고객센터 연락처, 온라인에서만 가능한 기능 목록을 제공해야 합니다. 사용자는 모든 기능이 되기를 기대하기보다, 무엇이 되고 무엇이 안 되는지 정확히 알 때 불안을 덜 느낍니다.
6. 폼 제출과 업무 액션: 큐잉보다 복구 설계가 먼저입니다
오프라인 UX에서 가장 위험한 영역은 폼 제출입니다. 사용자는 입력에 시간을 썼고, 실패하면 손실감이 큽니다. 기존의 폼 UX 최적화 기준이 입력 오류와 이탈을 줄이는 문제라면, 오프라인 폼 UX는 ‘전송 결과를 믿을 수 있는가’를 다룹니다.
폼 처리는 세 단계 중 하나를 선택해야 합니다.
- 오프라인 제출 차단: 결제, 계약, 승인, 개인정보 변경처럼 서버 확정이 중요한 액션은 오프라인에서 버튼을 비활성화하고 이유를 설명합니다.
- 로컬 초안 저장: 상담 메모, 점검표, 긴 문의 내용은 기기에 임시저장하고 사용자가 온라인에서 직접 제출하도록 합니다.
- 재시도 큐: 현장 조사, 단순 로그, 비중복 이벤트처럼 나중에 전송해도 되는 데이터는 IndexedDB 등에 큐를 만들고 연결 복구 후 재전송합니다.
Background Sync는 실패한 요청을 나중에 처리하는 데 도움이 되지만, 일부 브라우저 지원 제한이 있고 사용자가 앱을 완전히 종료했을 때 기대한 방식으로 동작하지 않을 수 있습니다. 그래서 실무에서는 자동 재시도와 함께 수동 재시도 목록을 제공하는 편이 안전합니다.
| 검토 항목 | 질문 | 설계 기준 |
|---|---|---|
| 중복 제출 | 같은 요청이 두 번 전송되면 어떻게 되는가? | idempotency key 또는 서버 측 중복 감지 필요 |
| 검증 실패 | 오프라인 작성 후 서버 규칙이 바뀌면? | 재시도 시 오류를 사용자에게 다시 보여주고 수정 가능해야 함 |
| 인증 만료 | 토큰이 만료된 뒤 큐가 전송되면? | 로그인 갱신 후 재전송, 또는 사용자가 확인 후 제출 |
| 개인정보 | 기기에 임시 저장해도 되는가? | 저장 기간, 삭제 버튼, 암호화, 접근권한 정책 검토 |
| 첨부파일 | 사진·PDF가 큰 경우 저장소 한도를 넘지 않는가? | 압축, 용량 제한, 업로드 재개, 실패 안내 필요 |
| 사용자 제어 | 대기 중인 요청을 취소할 수 있는가? | ‘전송 대기 목록’과 취소·수정 기능을 제공 |
정부지원사업 MVP나 현장 업무 SaaS에서는 ‘오프라인에서도 제출됩니다’라고 말하기 전에 위 표를 먼저 검토해야 합니다. 자동 큐잉은 사용자에게 편하지만, 중복 접수·권한 오류·개인정보 보관 리스크를 함께 만듭니다.
7. 업데이트와 캐시 무효화: 오래된 화면을 어떻게 깨울 것인가
서비스워커 운영에서 가장 많이 나오는 불만은 ‘배포했는데 사용자는 예전 화면을 본다’입니다. 서비스워커는 새 버전이 설치되어도 기존 탭이 열려 있으면 즉시 활성화되지 않을 수 있습니다. skipWaiting()과 clients.claim()으로 즉시 전환할 수 있지만, 저장 중인 작업이나 여러 탭 상태를 끊을 수 있어 UX 판단이 필요합니다.
권장되는 운영 기준은 다음과 같습니다.
- 해시가 붙은 정적 자산은 프리캐시: JS/CSS 파일명에 콘텐츠 해시를 붙여 버전 충돌을 줄입니다.
- HTML 진입점은 최신성 우선: 오래된 index.html이 새 API와 맞지 않는 상황을 줄이기 위해 Network First 또는 별도 갱신 정책을 둡니다.
- 오래된 프리캐시 정리: Workbox precaching의 정리 기능처럼 배포 후 남은 불필요한 캐시를 삭제합니다.
- 업데이트 알림 제공: 새 버전이 준비되면 ‘새 버전이 있습니다. 저장 중인 작업을 마친 뒤 새로고침하세요’처럼 사용자가 선택할 수 있게 합니다.
- 읽기 캐시 갱신 알림: Stale While Revalidate를 쓰는 화면은 캐시가 갱신됐을 때 ‘새 데이터 불러오기’ 버튼을 제공할 수 있습니다.
- 로그아웃 시 사용자별 캐시 정리: 테넌트·권한이 있는 SaaS는 로그아웃, 계정 전환, 권한 변경 시 개인화 캐시를 정리해야 합니다.
여기서 중요한 것은 배포 정책과 UX가 연결되어야 한다는 점입니다. 개발팀이 캐시 이름만 바꿔도 사용자는 이유를 모릅니다. 반대로 사용자에게 업데이트 안내를 보여주려면 서비스워커 등록 코드, 앱 상태 저장, 라우팅, 폼 초안 복구가 함께 설계되어야 합니다.
8. 출시 전 QA 체크리스트: 실제 네트워크 실패를 만들어야 합니다
오프라인 UX는 개발 환경에서 한 번 ‘Offline’ 체크박스를 켜보는 것으로 검증되지 않습니다. 특히 백그라운드 동기화나 서비스워커 fetch 흐름은 DevTools 설정만으로 실제 단말 상황을 충분히 재현하지 못할 수 있습니다. OS 네트워크 차단, 서버 중지, 느린 네트워크, 모바일 브라우저, 앱 설치 상태를 나눠 테스트해야 합니다.
| 시나리오 | 확인할 것 |
|---|---|
| 첫 방문 전 오프라인 | 캐시가 없을 때 기대치를 잘 설명하는가 |
| 두 번째 방문 후 비행기 모드 | 앱 shell, fallback, 최근 열람 데이터가 의도대로 보이는가 |
| 느린 네트워크 | 무한 스피너 대신 타임아웃·이전 데이터 표시·재시도가 있는가 |
| API 500과 네트워크 끊김 | 서버 장애와 오프라인을 다른 문구로 구분하는가 |
| 로그인 만료 | 인증 문제를 오프라인으로 오해하지 않는가 |
| 폼 제출 중 끊김 | 입력값이 보존되고 중복 전송이 방지되는가 |
| 배포 후 기존 탭 유지 | 새 버전 안내, 새로고침, 오래된 캐시 정리가 작동하는가 |
| 저장소 한도 초과 | QuotaExceededError나 캐시 삭제 상황에서도 치명적 오류가 나지 않는가 |
| 여러 탭 동시 사용 | 캐시 업데이트와 로그인 상태가 탭 간 충돌하지 않는가 |
| 목표 브라우저·웹뷰 | Android Chrome, iOS Safari, 사내 웹뷰 등 실제 대상에서 동작을 확인했는가 |
| 접근성 | 색상만으로 오프라인 상태를 전달하지 않고 스크린리더 문구가 있는가 |
QA 결과는 버그 목록만으로 끝내지 말고 운영 지표로 이어져야 합니다. 오프라인 fallback 노출 횟수, 캐시 hit 후 최신화 실패, 재시도 큐 평균 대기 시간, 재전송 성공률, 업데이트 알림 노출 후 새로고침 비율, 저장소 오류 발생 수를 관측하면 실제 사용자 환경에서 어디가 불안정한지 알 수 있습니다. 사용성 관찰까지 진행한다면 사용성 테스트 실전 가이드의 과업 기반 테스트 방식과 함께 적용하는 것이 좋습니다.
9. 대표·PM이 결정해야 할 구현 범위
오프라인 기능은 단계적으로 도입하는 편이 안전합니다. 처음부터 완전한 오프라인 업무 처리를 목표로 하면 동기화, 충돌 해결, 보안, 저장소 관리까지 한 번에 커집니다. MVP나 초기 SaaS라면 다음 순서로 범위를 잡아보는 것이 현실적입니다.
| 단계 | 목표 | 구현 예시 | 적합한 상황 |
|---|---|---|---|
| 0단계: Offline-aware | 오프라인임을 정확히 알림 | 상태 배너, 재시도 버튼, 무한 스피너 제거 | 대부분의 사업 홈페이지와 초기 SaaS |
| 1단계: Read-only 캐시 | 읽기 화면 일부를 계속 볼 수 있게 함 | 도움말, 최근 열람 문서, 정적 자산 캐시 | 영업 자료, 매뉴얼, 고객지원 화면 |
| 2단계: Draft 저장 | 입력 손실을 막음 | 문의·신청·점검표 임시저장 | 현장 상담, 설문, 정부지원사업 데모 |
| 3단계: Queue & Sync | 나중에 자동 또는 수동 전송 | 재시도 큐, idempotency key, 전송 대기 목록 | 현장 업무 SaaS, 반복 점검·수집 서비스 |
| 4단계: Conflict-aware Sync | 여러 기기·사용자 충돌 해결 | 버전 비교, 병합 UI, 감사 로그 | 오프라인 업무가 핵심 경쟁력인 제품 |
의사결정자는 ‘오프라인에서도 된다’라는 표현을 기능명으로 쓰기 전에 각 단계의 책임을 확인해야 합니다. 2단계까지만 구현한 서비스가 3단계처럼 보이면 사용자는 자동 전송을 기대합니다. 3단계를 구현했지만 충돌 해결이 없으면 현장 데이터 수집 후 운영팀이 수작업으로 정리해야 할 수 있습니다.
AgentMit 관점: 오프라인 기능은 화면 정책과 구현을 함께 봐야 합니다
AgentMit은 서비스워커를 많이 넣는 방향보다, 사업 화면별 위험도를 먼저 분류하는 접근을 권합니다. 특히 BizMit과 같은 업무형 SaaS, 관리자 대시보드, 자동화 화면, AI 서비스 개발, 정부지원사업 MVP에서는 ‘오프라인에서 보여줘도 되는 데이터’와 ‘온라인 확정이 필요한 액션’을 구분하지 않으면 데모는 좋아 보여도 실제 운영에서 신뢰 문제가 생깁니다.
구현 상담이 필요한 경우에는 단순히 PWA 적용 여부만 묻기보다 다음 자료를 준비하면 논의가 빠릅니다. 주요 화면 목록, API 목록, 캐시해도 되는 데이터, 최신성이 필요한 데이터, 실패 시 복구가 필요한 폼·업무 액션, 목표 브라우저, 배포 주기, 개인정보 저장 여부입니다. AgentMit은 이 기준을 바탕으로 서비스워커 캐시 전략, 업데이트 정책, 폼 제출 큐잉, 관리자 QA 시나리오까지 함께 검토할 수 있습니다. 필요하다면 BizMit 서비스 구조를 참고하거나 제작 문의에서 현재 서비스 화면 기준으로 상담을 요청할 수 있습니다.
FAQ
Q1. 서비스워커를 적용하면 웹사이트가 자동으로 오프라인에서 작동하나요?
아닙니다. 서비스워커는 요청을 가로채고 캐시를 제어할 수 있는 기반일 뿐입니다. 어떤 HTML, JS, 이미지, API 응답을 캐시할지와 오프라인일 때 어떤 화면을 보여줄지 별도로 설계해야 합니다. 첫 방문 전에는 캐시가 없다는 점도 고려해야 합니다.
Q2. 가격, 재고, 결제 정보도 서비스워커 캐시에 저장해도 되나요?
대부분의 경우 조심해야 합니다. 가격·재고·결제·승인처럼 최신성이 곧 신뢰인 데이터는 Network Only 또는 매우 짧은 TTL과 명확한 최신화 표시가 필요합니다. 사용자에게 오래된 값으로 구매나 승인을 확정하게 만들면 성능 개선보다 업무 리스크가 커집니다.
Q3. 오프라인 폼 제출은 Background Sync만 쓰면 해결되나요?
Background Sync는 실패한 요청을 나중에 재시도하는 데 도움이 되지만 일부 브라우저 지원 제한과 테스트 난도가 있습니다. 실무에서는 로컬 임시저장, 수동 재시도 버튼, 중복 제출 방지용 idempotency key, 인증 만료 처리, 서버 검증 실패 복구까지 함께 설계해야 합니다.
Q4. Workbox를 꼭 써야 하나요?
직접 서비스워커를 작성할 수도 있지만, Workbox는 캐시 전략, 프리캐싱, 만료 관리, 백그라운드 동기화, 업데이트 알림 같은 반복 구현을 줄여줍니다. 다만 Workbox를 도입해도 화면별 캐시 정책과 UX 문구, QA 시나리오는 제품 팀이 결정해야 합니다.
Q5. 기존 SaaS나 정부지원사업 MVP에는 어느 단계부터 적용하는 것이 좋나요?
처음부터 완전한 오프라인 업무 처리를 목표로 하기보다 1단계로 오프라인 안내와 기본 화면 fallback, 2단계로 정적 자산·도움말·최근 조회 데이터 캐시, 3단계로 작성 중 임시저장과 재시도 큐를 적용하는 방식이 안전합니다.
참고 자료
본문의 기술 판단은 아래 공식 문서를 바탕으로 서비스 기획 관점에 맞게 재구성했습니다.
- MDN Service Worker API — 서비스워커 기본 구조와 lifecycle 참고
- MDN PWA Caching Guide — PWA 캐싱 방식 참고
- Chrome Workbox Caching Strategies — 캐시 전략 비교 참고
- Chrome Workbox Background Sync — 실패 요청 큐잉과 테스트 주의사항 참고
- MDN Background Synchronization API — 백그라운드 동기화 지원 제한 참고
- Chrome Workbox Broadcast Update — stale 캐시 갱신 알림 참고
- Chrome Workbox Precaching — 프리캐시와 오래된 캐시 정리 참고
- Chrome Workbox Expiration — 캐시 만료·항목 수 제한 참고
- MDN Storage quotas and eviction criteria — 브라우저 저장소 한도와 삭제 가능성 참고
- MDN Window online event — 온라인 이벤트의 한계 참고
- web.dev Offline UX design guidelines — 오프라인 상태 표시와 UX 원칙 참고
