파일 하나만 추가하면 블로그가 앱처럼 바뀐다는 말, 믿으셨나요? 저도 그렇게 믿었습니다. 실제로 해보니 그 파일 하나가 시작이 아니라 끝이었고, 진짜 작업은 그다음부터였습니다. 재방문율을 올려보려고 시작한 PWA 전환이 어디서 막히고, 어떻게 풀렸는지 솔직하게 정리했습니다.
manifest.json, 정말 파일 하나로 끝날까요?
PWA(Progressive Web App)라는 말을 처음 들었을 때 저는 꽤 단순하게 생각했습니다. 여기서 PWA란 웹사이트를 마치 네이티브 앱처럼 설치하고 사용할 수 있게 만드는 기술 규격으로, 별도의 앱스토어 없이 브라우저 주소창만으로 배포가 가능한 방식입니다. "이거면 블로그 재방문율 올릴 수 있겠다"는 생각으로 시작했는데, 첫 관문인 manifest.json부터 예상보다 손이 많이 갔습니다.
manifest.json은 앱 이름, 테마 색상, 시작 URL, 아이콘 경로 등을 브라우저에 알려주는 설정 파일입니다. 문제는 아이콘이었습니다. 192×192, 512×512 등 최소 두 가지 해상도를 준비해야 하는데, 저는 처음에 한 가지 크기만 올렸다가 Lighthouse 감사에서 경고를 받았습니다. display 속성도 standalone으로 맞춰야 브라우저 상단 주소창 없이 앱처럼 보이는데, 이 속성 하나를 빠뜨렸더니 홈 화면에 추가해도 일반 웹페이지처럼 열렸습니다.
Add to Home Screen(A2HS), 즉 홈 화면 추가 프롬프트가 뜨려면 manifest.json이 올바르게 연결돼 있어야 하고, HTTPS 환경이어야 하며, 서비스워커까지 등록돼 있어야 합니다. 세 조건이 동시에 맞아야 한다는 점을 몰랐던 초반에는 왜 배너가 안 뜨는지 한참 헤맸습니다. 제가 직접 써봤는데, 조건 하나라도 빠지면 브라우저는 아무 안내도 없이 프롬프트를 숨겨버립니다.
- 아이콘: 192×192, 512×512 두 가지 해상도 필수
- display 속성: standalone 설정 (브라우저 UI 제거)
- start_url: 슬래시(/) 하나라도 틀리면 Lighthouse 감점
- HTTPS 환경 + 서비스워커 등록: A2HS 프롬프트 노출 필수 조건
서비스워커, 잘못 짜면 독이 됩니다
솔직히 이건 예상 밖이었습니다. 서비스워커(Service Worker)는 브라우저와 네트워크 사이에서 동작하는 백그라운드 스크립트로, 오프라인 상태에서도 캐시된 콘텐츠를 보여줄 수 있게 해주는 핵심 기술입니다. 문제는 이 스크립트가 한번 브라우저에 등록되면 개발자가 지우기 전까지 계속 살아있다는 점입니다.
처음에 캐싱 전략을 Cache First로 설정했습니다. Cache First란 네트워크 요청 전에 캐시를 먼저 확인하는 방식으로, 속도는 빠르지만 캐시가 갱신되지 않으면 오래된 데이터를 계속 보여주는 치명적인 부작용이 있습니다. 실제로 새 글을 발행했는데 일부 방문자 브라우저에서는 이전 글 목록이 계속 표시되는 상황이 생겼습니다. 독자 입장에서는 업데이트가 없다고 느끼는 거라 블로그 신뢰도에 직접 영향을 줄 수 있는 문제였습니다.
출처: MDN Web Docs - Progressive Web Apps에 따르면 서비스워커는 등록·설치·활성화 세 단계를 거치며, 이전 버전 서비스워커가 활성화된 상태에서는 새 버전이 바로 교체되지 않습니다. 이 생명주기를 이해하지 못하고 무작정 배포했던 게 문제의 원인이었습니다. 제 경험상 이건 좀 다릅니다 — 공식 문서만 읽어서는 실제 캐시 꼬임 현상을 체감하기 어렵고, 직접 구버전 캐시가 남아있는 상황을 만들어봐야 감이 옵니다.
Workbox로 캐싱 전략을 바꾼 뒤 달라진 것
캐시 문제를 해결하기 위해 Google이 만든 서비스워커 라이브러리인 Workbox를 도입했습니다. Workbox란 서비스워커에서 반복적으로 구현해야 하는 캐싱 전략·라우팅·백그라운드 동기화 등을 미리 모듈로 만들어둔 라이브러리로, 직접 코드를 짤 때 생기는 실수를 줄여주는 역할을 합니다(출처: Workbox 공식 문서).
핵심은 stale-while-revalidate 전략으로 바꾼 것이었습니다. 이 전략은 캐시에 저장된 응답을 즉시 반환하면서 동시에 네트워크에서 최신 데이터를 가져와 캐시를 갱신하는 방식입니다. 사용자는 빠르게 화면을 보고, 다음 방문 시에는 이미 갱신된 최신 콘텐츠를 받게 됩니다. Cache First처럼 구버전을 계속 보여주는 문제 없이, 속도와 최신성을 동시에 잡을 수 있는 절충안이었습니다.
추가로 캐시 버전 관리 로직도 넣었습니다. 서비스워커 파일에 버전 문자열을 넣고, 배포 시마다 이를 바꿔 브라우저가 새 서비스워커를 강제로 설치하도록 했습니다. 이 두 가지를 적용하고 나서야 "새 글이 안 보인다"는 상황이 사라졌습니다. Workbox 덕분에 직접 캐시 로직을 전부 짜지 않아도 됐고, 코드 양도 눈에 띄게 줄었습니다.
Lighthouse 100점, 그런데 설치율은 왜 낮을까요?
Lighthouse PWA 감사는 크롬 개발자 도구에 내장된 점검 도구로, PWA 요건 충족 여부를 자동으로 검사해 점수를 매겨줍니다. HTTPS 강제 적용, 오프라인 폴백 페이지, manifest 유효성 등 항목별로 통과·실패 여부를 알려주기 때문에 어디서 막혔는지 찾기가 수월합니다. 저는 이 도구를 보면서 빠진 요건을 하나씩 채워나갔고, 결국 PWA 항목 100점을 달성했습니다.
안드로이드 크롬에서 A2HS 배너가 처음 뜨던 순간은 솔직히 꽤 뿌듯했습니다. 몇 주를 씨름한 결과가 화면에 나타나는 거라 감회가 달랐습니다. 그런데 실제 데이터를 보니 설치까지 이어지는 사용자 비율이 예상보다 훨씬 낮았습니다. 배너는 뜨지만 대부분은 그냥 닫아버렸습니다.
여기서 제 경험상 느낀 현실적인 한계가 있습니다. iOS 사파리는 PWA 지원 범위가 안드로이드 크롬에 비해 여전히 제한적입니다. A2HS 프롬프트 자체가 없고, 푸시 알림 기능도 일부 버전에서만 동작합니다. 블로그 방문자 중 iOS 비율이 높다면 PWA의 체감 효과는 절반 이하로 떨어질 수 있습니다. 또한 개인 블로그 규모에서는 이 모든 작업의 투자 대비 효과가 생각보다 작다는 점도 솔직히 인정해야 합니다. 재방문율을 높이고 싶다면 이메일 뉴스레터나 RSS 같은 더 간단한 채널을 먼저 정비하는 것이 비용 효율 면에서 유리할 가능성이 있습니다.
자주 묻는 질문
Q. 블로그에 PWA 적용하면 SEO에도 도움이 되나요?
A. 직접적인 검색 순위 상승보다는 간접 효과에 가깝습니다. 페이지 로드 속도 개선과 오프라인 지원으로 이탈률이 낮아지면 체류 시간 지표에 긍정적인 영향을 줄 수 있습니다. 다만 PWA 적용 자체가 검색 알고리즘에서 직접 가점으로 처리된다는 근거는 없으니 과도한 기대는 피하는 게 좋습니다.
Q. 서비스워커 캐시 때문에 새 글이 안 보이면 어떻게 해결하나요?
A. 가장 빠른 해결책은 stale-while-revalidate 전략으로 전환하는 것입니다. 이 방식은 캐시된 내용을 즉시 보여주면서 동시에 백그라운드에서 최신 데이터를 가져와 다음 방문 시 반영합니다. 여기에 서비스워커 파일의 버전 문자열을 배포 때마다 바꾸는 캐시 버전 관리 로직을 추가하면 구버전 캐시가 남는 문제를 근본적으로 예방할 수 있습니다.
Q. 아이폰에서는 PWA 설치 배너가 왜 안 뜨나요?
A. iOS 사파리는 A2HS 자동 프롬프트 기능을 지원하지 않습니다. 아이폰에서 홈 화면에 추가하려면 사용자가 직접 공유 메뉴를 열어 '홈 화면에 추가'를 탭해야 합니다. 이 점에서 안드로이드 크롬과 사용자 경험이 크게 갈리기 때문에, iOS 방문자 비율이 높은 블로그라면 PWA의 실질적 효과가 제한될 수 있습니다.
Q. Workbox 없이 서비스워커를 직접 짜도 되나요?
A. 가능하지만 상당한 시간과 노력이 필요합니다. 캐싱 전략, 캐시 만료 처리, 오프라인 폴백 페이지 등을 처음부터 직접 구현해야 하는데, 실수 하나가 사용자에게 오래된 콘텐츠를 계속 보여주는 부작용으로 이어집니다. Workbox는 이런 반복 작업을 모듈로 추상화해줘서, 개인 블로그 수준이라면 Workbox를 쓰는 쪽이 관리 부담이 훨씬 적습니다.
결론
PWA 전환은 기술적으로 분명히 배울 게 많은 작업입니다. manifest.json 구성부터 서비스워커 생명주기, Workbox 캐싱 전략, Lighthouse PWA 감사까지 직접 해보면서 웹 동작 방식을 훨씬 깊게 이해하게 됐습니다. 오프라인 폴백 페이지가 실제로 작동하는 걸 보는 경험도 나쁘지 않았습니다.
그렇지만 재방문율을 높이겠다는 원래 목적으로 돌아오면, 솔직히 이 투자가 가장 효율적인 선택이었는지는 확신하기 어렵습니다. 특히 iOS 방문자가 많다면 효과는 더 제한적입니다. 아직 뉴스레터나 RSS를 정비하지 않으셨다면, PWA보다 그쪽을 먼저 챙기는 것이 현실적인 순서일 수 있습니다. PWA는 그다음 단계로 시도해도 늦지 않습니다.
참고: MDN Web Docs - Progressive Web Apps / web.dev - Service Workers / Workbox 공식 문서