PWA 실습 마스터: 크롬 Application 탭 검증과 서비스 워커 대청소 코드의 비밀
PWA 실습 마스터: 크롬 Application 탭 검증과 서비스 워커 대청소 코드의 비밀
사파리 브라우저의 UI 한계로 인해 잠시 미궁에 빠졌던 캐시 보관함의 실체를 구글 크롬(Chrome) 브라우저를 통해 마침내 완벽하게 포착했습니다. 더불어 서비스 워커의 생명 주기 중 가장 중요한 세대교체 단계인 activate 이벤트를 소스 코드 레벨에서 분석하며 발견한 반전의 버그 원인까지 상세히 기록합니다.
💡 핵심 요약: PWA가 오프라인에서 작동하기 위해 얼려둔 정적 파일들은 크롬 개발자 도구의 Application 탭에서 시각적으로 검증할 수 있습니다. 또한, 캐시 이름을 커스텀할 때는 서비스 워커 내부의 청소 필터 조건문도 함께 수정해 주어야 과거의 쓰레기 파일들이 정상적으로 삭제됩니다.
1. 크롬 Application 탭에서 찾아낸 진짜 'ssm-cache-v5'
브라우저 환경을 크롬으로 전환한 뒤 [Application] ➡️ [Storage] ➡️ [Cache Storage] 트리 구조를 샅샅이 뒤진 결과, 마침내 감격스러운 실체를 대면했습니다.- 커스텀 캐시명 적중: 제가 소스 코드를 통해 직접 수정한 진짜 이름인
ssm-cache-v5 - http://127.0.0.1:8443보관함이 당당하게 생성되어 있었습니다. - 26개의 얼려진 에셋 확인: 오프라인 상태에서도 화면 레이아웃과 이미지가 깨지지 않았던 이유가 눈앞에 펼쳐졌습니다. 보관함 우측 테이블 뷰에
/css/gih.css(디자인 뼈대),/events.json(이벤트 데이터),/img/logo-header.png(호텔 로고) 등 오프라인 구동을 위한 필수 정적 자원 26개가 복사본 형태로 신선하게 사전 캐싱(Pre-caching)되어 상주하고 있음을 직접 눈으로 검증했습니다.
2. 141번 줄 장막 뒤에 숨겨진 'activate' 대청소 코드 해독
VS Code 편집기에서 접혀 있던 141번 줄의self.addEventListener('activate', ...) 구역을 펼쳐 자바스크립트 소스 코드의 진짜 동작 원리를 분석했습니다.
이 구역은 새 비서가 출근하여 통제실을 장악하는 순간(활성화), 기기의 용량 낭비를 막기 위해 과거의 낡은 냉장고(구버전 캐시)들을 추적해서 쓸어버리는 '대청소 영역'이었습니다.
caches.keys()로 브라우저 내 모든 캐시 이름을 수집한 뒤, Promise.all()과 map() 배열 메서드를 연동하여 비동기식으로 청소를 단행하는 고난도 로직이 심겨 있었습니다.
3. 이름 변경이 불러온 소스 코드 내부의 반전 (버그 원인 발견)
하지만 코드를 한 줄씩 뜯어보던 중, 왜 예전 캐시들이 자동으로 청소되지 않고 남아있었는지 치명적인 원인을 발견했습니다. 범인은 바로 146번 줄의 하드코딩된 조건문이었습니다.
if (CACHE_NAME !== cacheName && cacheName.startsWith("gih-cache"))
저자가 예전 냉장고를 파기할 때 "그 냉장고 이름이 반드시 'gih-cache'라는 글자로 시작해야 한다"는 좁은 필터를 걸어둔 것이 화근이었습니다. 제가 나만의 멋진 이름인
ssm-cache-v5로 네임스페이스를 통째로 커스텀해 버리는 바람에, 이 청소 필터를 통과하지 못하고 삭제 명령(caches.delete)이 무시되었던 것입니다. 소스 코드 레벨에서 예외 버그를 역추적해 낸 짜릿한 순간이었습니다.
📝 이번 실습 대장정의 결론
깃허브 클라우드 워크스페이스와 데스크톱 VS Code 연동을 시작으로 무한 폭주하던reservation-details.json 좀비 데이터의 은신처(IndexedDB) 검거, 실제 스마트폰(아이폰 8) 오프라인 실험, 그리고 크롬 Application UI를 통한 26개 에셋의 시각적 검증과 생명 주기 코드 해독까지 완료했습니다.
화면 뒤편의 코드 원리와 눈앞의 브라우저 UI 변화를 연결해 보며, PWA의 가장 거대한 산인 서비스 워커의 핵심 메커니즘을 완벽하게 내 손으로 통제하고 이해할 수 있게 되었습니다!
댓글
댓글 쓰기