안녕하세요! 크로스플랫폼 앱을 만들다 보면 한 번쯤 "굳이 앱스토어 심사 받고 iOS/안드로이드 따로 개발해야 하나?"라는 고민에 빠지게 됩니다. 저도 그랬어요. 그러다 만난 게 바로 PWA, 즉 프로그레시브 웹앱이었습니다. 웹 기술만으로 네이티브 앱 같은 경험을 줄 수 있다는 게 처음엔 반신반의했는데, 직접 몇 개 프로젝트에 적용해 보니 생각보다 강력하더라고요. 오늘은 제가 실제로 PWA를 구축하면서 겪은 경험을 솔직하게 풀어보려 합니다.
목차
PWA란 무엇인가, 왜 쓰는가
프로그레시브 웹앱의 정의
PWA(Progressive Web App)는 쉽게 말해 '앱처럼 동작하는 웹사이트'입니다. 브라우저에서 접속하는 일반 웹페이지지만, 홈 화면에 아이콘으로 설치할 수 있고, 오프라인에서도 열리며, 푸시 알림까지 받을 수 있습니다. 사용자 입장에서는 앱스토어를 거치지 않고도 네이티브 앱과 거의 구분이 안 되는 경험을 하게 되죠. 저는 처음 이걸 시연했을 때 동료가 "이거 진짜 웹이야?"라고 묻던 표정을 아직도 기억합니다.
네이티브 앱과의 차이
네이티브 앱은 Swift나 Kotlin으로 플랫폼별로 따로 만들어야 하고 심사 과정도 거쳐야 합니다. 반면 프로그레시브 웹앱은 HTML, CSS, JavaScript 한 벌로 모든 기기를 커버합니다. 트위터, 스타벅스, 핀터레스트 같은 글로벌 서비스가 PWA를 적극 도입한 이유도 바로 이 효율성 때문입니다. 스타벅스의 경우 PWA 도입 후 주문 페이지 용량이 네이티브 앱의 1/100 수준으로 줄었다는 사례는 유명하죠.
PWA 핵심 기술 세 가지
서비스 워커(Service Worker)
PWA의 심장이라고 할 수 있는 게 바로 서비스 워커입니다. 브라우저와 서버 사이에서 동작하는 일종의 프록시 스크립트인데, 네트워크 요청을 가로채서 캐시된 데이터를 돌려주거나 백그라운드 작업을 처리합니다. 덕분에 인터넷이 끊겨도 앱이 멈추지 않죠. 처음 서비스 워커를 다룰 때 가장 헷갈렸던 건 '생명주기'였어요. install, activate, fetch 이벤트가 언제 발생하는지 이해하지 못하면 캐시가 갱신되지 않는 문제로 며칠을 날릴 수 있습니다(제 얘기입니다).
웹 앱 매니페스트(Manifest)
manifest.json 파일은 앱의 이름, 아이콘, 배경색, 화면 방향 같은 메타데이터를 담습니다. 이 파일이 있어야 브라우저가 "이 사이트는 설치할 수 있어요"라고 판단하고 홈 화면 추가 배너를 띄웁니다. 작성 자체는 어렵지 않지만, 다양한 해상도의 아이콘(192x192, 512x512는 필수)을 빠뜨리면 설치 프롬프트가 아예 안 뜨니 주의해야 합니다.
HTTPS와 보안
서비스 워커는 보안상 반드시 HTTPS 환경에서만 동작합니다. localhost는 예외로 허용되니 개발 단계에서는 걱정 없지만, 배포 시 SSL 인증서는 필수입니다. 요즘은 Let's Encrypt나 호스팅 서비스의 무료 인증서로 손쉽게 해결할 수 있어 큰 장벽은 아닙니다.
실전 구축 가이드와 꿀팁
기본 구축 흐름
구축 순서는 의외로 단순합니다. 먼저 기존 웹앱에 manifest.json을 연결하고, 서비스 워커를 등록한 뒤, 캐싱 전략을 설계하면 됩니다. 저는 처음엔 모든 걸 직접 짜려다 머리가 터질 뻔했는데, 구글의 Workbox 라이브러리를 쓰니 캐싱 로직이 절반으로 줄었습니다. 프로그레시브 웹앱을 처음 만든다면 무조건 Workbox부터 추천합니다.
실제로 써먹은 꿀팁 세 가지
- 팁 1 — 캐싱 전략을 구분하라: 정적 파일(CSS, JS, 이미지)은 Cache First, API 응답은 Network First로 나누세요. 무작정 전부 캐싱하면 사용자가 항상 옛날 데이터를 보게 됩니다.
- 팁 2 — Lighthouse를 친구로: 크롬 개발자도구의 Lighthouse 탭에서 PWA 점수를 측정하세요. 설치 가능 여부, 오프라인 동작 등을 체크리스트로 짚어줘서 디버깅 시간을 크게 줄여줍니다.
- 팁 3 — 캐시 버전 관리: 서비스 워커 캐시 이름에 버전 번호(v1, v2…)를 붙이고 activate 이벤트에서 오래된 캐시를 삭제하세요. 이걸 안 하면 배포해도 사용자에게 업데이트가 반영 안 되는 악몽을 겪습니다.
- 팁 4 — 푸시는 신중하게: 알림 권한 요청을 접속 즉시 띄우면 거부율이 높습니다. 사용자가 가치를 느낀 시점에 요청하세요.
흔히 겪는 함정
가장 자주 만나는 문제는 'iOS의 제한적 지원'입니다. 애플은 PWA에 대해 다소 인색해서, 푸시 알림이 비교적 최근에야 지원되기 시작했고 일부 기능은 여전히 제약이 있습니다. 그래서 iOS 사용자 비중이 높은 서비스라면 사전에 기능 호환성을 반드시 테스트해야 합니다.
장단점 비교와 추천 대상
장단점 한눈에 비교
| 구분 | 장점 | 단점 |
|---|---|---|
| 개발 비용 | 하나의 코드로 전 플랫폼 대응, 유지보수 간편 | 고급 네이티브 기능 구현 시 별도 작업 필요 |
| 배포 | 앱스토어 심사 불필요, 즉시 배포·업데이트 | 스토어 노출 효과를 누리기 어려움 |
| 성능 | 가볍고 빠른 로딩, 오프라인 동작 지원 | 복잡한 그래픽·연산은 네이티브보다 불리 |
| 호환성 | 모든 최신 브라우저에서 동작 | iOS에서 일부 기능 제약 존재 |
이런 분께 추천합니다
솔직히 PWA가 만능은 아닙니다. 게임처럼 GPU를 쥐어짜거나 블루투스·고급 센서를 깊게 쓰는 앱이라면 네이티브가 정답입니다. 하지만 다음에 해당한다면 프로그레시브 웹앱은 정말 매력적인 선택입니다. 첫째, 적은 예산과 인력으로 빠르게 멀티 플랫폼 서비스를 내고 싶은 스타트업과 1인 개발자. 둘째, 뉴스·커머스·예약처럼 콘텐츠 중심이고 접근성이 중요한 서비스. 셋째, 기존 웹 서비스에 앱 같은 사용자 경험을 더하고 싶은 팀입니다.
저는 작은 사이드 프로젝트를 PWA로 전환한 뒤 설치 전환율과 재방문율이 눈에 띄게 올라가는 걸 직접 봤습니다. 서비스 워커 개념만 한번 제대로 익혀두면 이후 프로젝트마다 두고두고 써먹을 수 있는 자산이 됩니다. 부담 없이 작은 페이지부터 manifest와 서비스 워커를 붙여보세요. 생각보다 훨씬 가까이에 '앱 같은 웹'이 있다는 걸 느끼실 겁니다. 여러분의 다음 프로젝트에 PWA가 좋은 무기가 되길 바랍니다!