PWA(Progressive Web App) 알아보기

더모먼트 스터디에서 PWA 라는 주제를 맡아 발표하게 되었다.
발표 준비를 하며 공부했던 내용을 정리해 보겠다.

1. 들어가며

PWA를 처음 알아보았을 때 "반응형 웹이랑 다를게 뭐지?" 라고 생각했었다. 허지만 공부를 하며 단순 UI만 앱처럼 작동하는것이 아닌 앱처럼 작동하기 위해서 여러가지 기능이 있다는 것을 알게 되었다.

2. 웹과 앱?

웹은 다음과 같이 작동하며 다음과 같은 특징이 있다.

• 설치 불필요 — URL 하나로 바로 접근 가능
• 접근성 좋음 — 플랫폼 상관없이 브라우저만 있으면 됨
• 서버 의존 — 네트워크가 없으면 동작하지 않음

사용자 → 브라우저 → 서버 → HTML, CSS → 렌더링

이와 반면에 앱은

• 빠름 — 리소스가 기기에 저장되어 있어 로딩이 빠름
• 오프라인 일부 가능 — 네트워크 없이도 기본 기능 동작
• PUSH 알림 — 앱을 열지 않아도 알림 수신 가능

앱 설치 → 기기에 저장 → 실행 → 필요 시 서버와 통신

3. PWA란

그렇다면 웹의 접근성과 앱의 성능, 이 둘의 장점을 합칠 수는 없을까? 그 해답이 바로 PWA다.

PWA(Progressive Web App)는 웹 기술을 사용하면서도 앱과 유사한 사용자 경험을 제공하는 기술이다.

PWA는 웹이지만 앱의 장점을 사용하기 위해 사용하는 기술이라고 생각하면 된다.

4. PWA의 핵심 기술

PWA가 앱처럼 동작하기 위해서는 세 가지 핵심 기술이 필요하다.

4-1. HTTPS

PWA는 반드시 HTTPS 환경에서만 동작한다.

서비스 워커는 브라우저의 네트워크 요청을 가로채는 강력한 기능을 가지고 있다. 만약 HTTP 환경에서 이를 허용한다면 악의적인 스크립트가 요청을 조작하는 중간자 공격(MITM)에 취약해진다. 그렇기 때문에 브라우저는 HTTPS 환경에서만 서비스 워커 등록을 허용한다. (개발 편의를 위해 localhost는 예외다)

4-2. Service Worker

서비스 워커는 PWA의 핵심이라고 할 수 있다.

일반 자바스크립트와 달리 브라우저의 메인 스레드와 완전히 분리된 백그라운드에서 실행되는 스크립트다. 덕분에 앱이 꺼져 있거나 브라우저가 열려 있지 않아도 동작할 수 있다.

서비스 워커의 가장 중요한 역할은 네트워크 요청을 가로채는 것이다. 사용자가 어떤 리소스를 요청하면 서비스 워커가 중간에서 이를 가로채 캐시에 저장된 응답을 돌려줄 수 있다. 이것이 오프라인 동작을 가능하게 하는 원리다.

사용자 요청 → 서비스 워커 → 캐시 확인
                              ├─ 캐시 있음 → 캐시된 응답 반환 (오프라인 가능)
                              └─ 캐시 없음 → 서버에 요청 → 응답 캐시 후 반환

서비스 워커는 다음 라이프사이클로 동작한다.

• install: 서비스 워커가 처음 등록될 때 실행. 주로 캐시할 파일을 지정한다.
• activate: 설치 완료 후 활성화. 이전 버전의 캐시를 정리한다.
• fetch: 네트워크 요청이 발생할 때마다 실행. 캐시 or 서버 응답을 결정한다.

4-3. Web App Manifest

manifest.json 파일 하나로 "이 웹사이트는 앱처럼 설치될 수 있다"고 브라우저에게 알려주는 역할을 한다.

{
  "name": "My PWA App",
  "short_name": "MyApp",
  "start_url": "/",
  "display": "standalone",
  "background_color": "#ffffff",
  "icons": [
    {
      "src": "/icons/icon-192.png",
      "sizes": "192x192",
      "type": "image/png"
    }
  ]
}

• display: "standalone" 으로 설정하면 브라우저 주소창 없이 앱처럼 실행된다.
• 조건을 충족하면 브라우저가 자동으로 "홈 화면에 추가(A2HS)" 배너를 띄워준다.

5. PWA의 장단점

PWA가 만능 해결책은 아니다. 장단점을 명확히 알고 사용해야 한다.

장점

• 앱스토어 심사 없이 바로 배포 가능
• 설치 용량이 네이티브 앱에 비해 매우 작음
• 웹과 앱 코드를 하나의 코드베이스로 관리 가능
• URL로 공유 가능 — 네이티브 앱은 스토어 링크가 필요하지만 PWA는 URL 하나면 충분

단점

• iOS Safari의 서비스 워커 지원이 제한적 (Android Chrome 대비 기능 차이 존재)
• 블루투스, NFC 등 일부 네이티브 기기 API 접근 불가
• 앱스토어에 등록되지 않아 검색 노출이 어려움

6. 실제 사례

PWA는 이미 많은 기업들이 실제 서비스에 도입하여 유의미한 성과를 거두고 있다.

Twitter Lite
Twitter는 저사양 기기와 느린 네트워크 환경의 사용자를 위해 PWA 버전인 Twitter Lite를 출시했다. 그 결과 데이터 사용량이 70% 감소했고, 세션당 페이지 방문 수는 65% 증가했다.

Starbucks
Starbucks PWA는 오프라인 상태에서도 메뉴 탐색과 주문이 가능하다. 네이티브 앱 대비 앱 크기가 99.84% 절감되었고, 이를 통해 저사양 기기 사용자층까지 서비스를 확대했다.

Pinterest
Pinterest는 모바일 웹을 PWA로 전환한 후 가입 전환율이 60% 증가했고, 핵심 참여 지표도 크게 개선되었다.

이처럼 PWA는 특히 느린 네트워크 환경이나 저사양 기기 사용자가 많은 서비스에서 큰 효과를 발휘한다.

7. 마무리

PWA는 네이티브 앱을 완전히 대체하는 기술이 아니다. 블루투스나 NFC 같은 고급 하드웨어 기능이 필요하거나, 앱스토어 노출이 중요한 서비스라면 여전히 네이티브 앱이 적합하다.

하지만 "웹의 접근성을 유지하면서 앱에 가까운 경험을 제공한다"는 측면에서 PWA는 분명히 웹이 나아가는 방향 중 하나라고 생각한다. 앞으로 브라우저의 API 지원이 더 넓어질수록 PWA의 가능성도 함께 커질 것이다.