Progressive Web Apps (PWA) 소개

우리는 지금까지 프론트엔드와 백엔드 핵심 기술을 익히고, 데이터베이스, 보안, 성능, 개발 도구까지 폭넓게 다뤘습니다.

이제 기본 웹 애플리케이션을 기획하고 배포할 수 있는 기반이 갖춰졌습니다.

다음 질문은 앞으로 무엇을 더 준비해야 하는가입니다.

웹 기술은 빠르게 바뀌고, 오늘의 선택이 내일의 기본이 되기도 합니다.

15장에서는 이런 변화 속에서 실제로 영향력이 큰 흐름을 살펴봅니다.

첫 주제는 PWA(Progressive Web App)입니다.

PWA는 웹 앱을 네이티브 앱에 가까운 경험으로 끌어올리는 접근입니다.

설치, 오프라인 지원, 푸시 알림처럼 웹의 활용 범위를 넓히는 기술을 중심으로 구성됩니다.

PWA (Progressive Web App)란?

PWA (Progressive Web App)는 웹 기술(HTML, CSS, JavaScript)을 사용하여 개발되었지만, 네이티브 애플리케이션(iOS, Android 앱)과 유사한 사용자 경험을 제공하는 웹 애플리케이션입니다.

PWA는 웹의 장점(설치 필요 없음, URL 기반 접근 용이성, 빠른 개발 및 배포)과 네이티브 앱의 장점(오프라인 지원, 푸시 알림, 홈 화면 아이콘, 시스템 자원 접근)을 결합하여 사용자에게 더욱 풍부하고 편리한 경험을 제공하는 것을 목표로 합니다.

• 설치 장벽 낮춤: 사용자는 앱 스토어 방문, 다운로드, 설치 과정 없이 웹사이트 방문만으로 PWA를 사용하고, 필요하면 홈 화면에 추가할 수 있습니다. 이는 사용자 유입 장벽을 크게 낮춥니다.
• 연결 불안정에 대응: 미리 저장한 공개 콘텐츠와 복구 정책이 있는 범위에서 오프라인 이용을 지원할 수 있습니다. 푸시는 대상 환경의 지원과 사용자 권한이 있어야 하며, 설치만으로 이 기능들이 생기는 것은 아닙니다.
• 개발 및 유지보수 효율: 웹 코드와 배포 흐름을 여러 환경에서 재사용할 수 있습니다. 설치 UI·푸시·백그라운드 기능의 지원 범위와 권한은 플랫폼별로 확인해야 하므로 하나의 코드베이스가 모든 기능의 동일 동작을 보증하지는 않습니다.
• 웹 검색으로 발견 가능: 공개 URL과 검색 엔진이 읽을 수 있는 콘텐츠를 유지할 수 있습니다. PWA라는 이름이나 설치 기능만으로 색인·상위 노출이 보장되지는 않습니다. Google의 페이지 경험 안내도 좋은 성능 점수만으로 상위 순위가 보장되지 않는다고 설명합니다.

PWA의 핵심 구성 요소

앞 장의 HTTPS·캐시·배포 흐름을 알고 있다면, 이번에는 “파일을 서버에 올렸는가”와 “현재 클라이언트가 어느 버전의 응답을 쓰는가”를 나누어 봅니다. 설치 가능성, 오프라인 화면, 알림은 각각 필요한 기능을 선택하며 한 기능의 성공으로 나머지를 검증하지 않습니다.

이 장에서는 매니페스트로 설치 정보를 선언하고, 서비스 워커로 필요한 오프라인·백그라운드 기능을 구현하며, HTTPS로 전달합니다. 설치 안내처럼 서비스 워커는 설치 가능성 자체의 보편적인 필수 조건은 아닙니다. 브라우저가 제공하는 설치와 오프라인 구현을 구분합니다.

서비스 워커 (Service Worker)

• 이벤트 기반 실행 계층: 서비스 워커는 페이지와 분리된 워커에서 실행되며 DOM을 직접 조작하지 않습니다. 요청·푸시 등의 이벤트를 처리하고 캐시를 제어할 수 있지만 항상 실행 중인 서버나 타이머가 아닙니다. 브라우저는 유휴 워커를 중단할 수 있으므로 중요한 상태는 메모리 변수에만 두지 않습니다.

• 주요 기능
  • 오프라인 지원 (Offline-first): 네트워크 연결이 없거나 불안정한 환경에서도 캐시된 콘텐츠를 제공하여 웹 앱이 동작하도록 합니다.
  • 빠른 로딩: 적절한 캐시 적중은 네트워크 대기를 줄일 수 있습니다. 미캐시 요청·오래된 데이터·저장소 한도도 고려해야 하며 모든 페이지가 자동으로 빨라지는 것은 아닙니다.
  • 푸시 알림 (Push Notifications): 사용자가 웹 앱을 닫은 상태에서도 서버로부터 푸시 메시지를 받아 알림을 표시할 수 있게 합니다.
  • 백그라운드 동기화: 지원 환경에서는 미뤄 둔 작업을 저장하고 재시도할 수 있습니다. 실행 시점·권한·배터리·브라우저 지원에 제약이 있으며, 재전송 중복과 서버 승인도 설계해야 합니다.
• 동작 방식 (간략)

  웹 페이지에서 서비스 워커를 등록(Register)합니다.

  브라우저는 서비스 워커 파일을 다운로드하고 설치(Install)합니다.

  이 단계에서 필요한 에셋들을 캐시에 저장할 수 있습니다.

  활성 서비스 워커가 scope 안의 client를 제어하면 그 client의 요청을 fetch 이벤트로 처리할 수 있습니다. 첫 등록 직후 현재 페이지가 바로 제어되는 것은 아니며, 캐싱은 작성한 핸들러가 결정합니다.

웹 앱 매니페스트 (Web App Manifest)

• PWA의 신분증: 웹 앱 매니페스트는 JSON 형식의 파일로, PWA의 메타데이터(이름, 아이콘, 시작 URL, 표시 방식 등)를 정의합니다.
• 주요 기능
  • 홈 화면 아이콘: 사용자가 PWA를 홈 화면에 추가했을 때 표시될 아이콘을 정의합니다.
  • 시작 화면 정보: 이름·아이콘·배경색 등의 메타데이터를 제공합니다. 브라우저나 OS가 이를 사용해 시작 화면을 구성할 수 있으며, 매니페스트가 임의의 스플래시 화면을 모든 기기에 지정하는 것은 아닙니다.
  • 표시 모드 (Display Mode): PWA가 브라우저 UI 없이 독립적인 앱처럼 실행될지(standalone), 최소한의 UI를 가질지(minimal-ui), 아니면 일반 웹 페이지처럼 보일지(browser) 등을 설정합니다.
  • 시작 URL: PWA를 실행했을 때 로드될 초기 URL을 지정합니다.

이름과 표시 모드를 선언했다고 설치·시작 화면의 모습이 모든 브라우저에서 같아지는 것은 아닙니다. 아래 예제는 해당 크기의 실제 /icons/icon-192.png, /icons/icon-512.png와 나머지 공개 파일을 먼저 준비했다고 가정합니다. sizes는 이미지 파일의 실제 해상도를 설명하며 파일을 변환하는 명령이 아닙니다.

• index.html에 연결: <link rel="manifest" href="/manifest.json"> 형태로 HTML 파일에 연결합니다.

HTTPS

• PWA의 필수 조건: PWA는 서비스 워커의 보안 및 무결성 문제 때문에 반드시 HTTPS 환경에서 호스팅되어야 합니다. 로컬 개발 환경(localhost)에서는 예외적으로 HTTP가 허용됩니다.
• 보안과 신뢰: HTTPS는 전송 중 도청·변조 위험을 줄입니다. 악성 코드·잘못된 권한 검사·개인 정보의 캐시 저장까지 해결하지는 않으므로 애플리케이션 보안도 필요합니다.

PWA의 주요 특징 및 장점

PWA는 네이티브 앱의 장점을 웹으로 가져오면서도 웹 본연의 장점을 유지합니다.

PWA 구현의 간단한 흐름 (예시)

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

<head>
    <link rel="manifest" href="/manifest.json">
    <meta name="theme-color" content="#000000">
    <link rel="apple-touch-icon" href="/logo.png">
    <meta name="apple-mobile-web-app-capable" content="yes">
    <meta name="apple-mobile-web-app-status-bar-style" content="black">
</head>

// sw.js: 이 목록은 로그인 상태와 무관한 공개 파일이어야 합니다.
const CACHE_PREFIX = 'my-pwa-public-';
const CACHE_NAME = `${CACHE_PREFIX}v1`;
const urlsToCache = [
  '/', '/index.html', '/styles.css', '/script.js',
  '/icons/icon-192.png', '/icons/icon-512.png',
];
const publicPaths = new Set(urlsToCache);

self.addEventListener('install', event => {
  event.waitUntil(
    caches.open(CACHE_NAME).then(cache => cache.addAll(urlsToCache))
  );
});

self.addEventListener('fetch', event => {
  const url = new URL(event.request.url);
  if (event.request.method !== 'GET'
      || url.origin !== self.location.origin
      || url.search !== ''
      || !publicPaths.has(url.pathname)) {
    return; // 개인 API·POST·외부 요청은 기본 네트워크 처리로 둡니다.
  }

  event.respondWith((async () => {
    const cache = await caches.open(CACHE_NAME);
    const cached = await cache.match(event.request);
    if (cached) return cached;

    try {
      const response = await fetch(event.request);
      if (response.status === 200 && response.type === 'basic') {
        try {
          await cache.put(event.request, response.clone());
        } catch (error) {
          console.warn('공개 파일을 저장하지 못했습니다');
        }
      }
      return response;
    } catch (error) {
      if (event.request.mode === 'navigate') {
        return new Response('오프라인입니다. 연결 후 다시 시도하세요.', {
          status: 503,
          headers: { 'Content-Type': 'text/plain; charset=utf-8' },
        });
      }
      return Response.error(); // CSS·JS 요청에 HTML을 대신 보내지 않습니다.
    }
  })());
});

self.addEventListener('activate', event => {
  event.waitUntil(
    caches.keys().then(names => Promise.all(
      names.filter(name => name.startsWith(CACHE_PREFIX) && name !== CACHE_NAME)
        .map(name => caches.delete(name))
    ))
  );
});

if ('serviceWorker' in navigator) {
  window.addEventListener('load', () => {
    navigator.serviceWorker.register('/sw.js')
      .then(registration => {
        console.log('Service Worker registered: ', registration);
      })
      .catch(error => {
        console.error('Service Worker registration failed: ', error);
      });
  });
}

참고: 빌드 도구나 프레임워크가 설치·푸시·오프라인을 모두 자동으로 구현하지는 않습니다. 도구가 제공하는 매니페스트·서비스 워커 통합 방식과 필요한 플러그인을 확인합니다. 예를 들어 Next.js 공식 PWA 안내는 매니페스트와 서비스 워커를 각각 구성하는 과정을 설명합니다.

PWA는 구현 후에도 캐시 갱신, 설치 가능성, 오프라인 동작을 실제 기기에서 점검해야 합니다. 예제는 사이트 루트 배포와 공개 정적 파일만 다룹니다. 같은 경로가 로그인 사용자마다 다른 HTML을 반환한다면 이 목록에 넣으면 안 됩니다. 주문·결제 API와 개인 정보는 캐시 대상에서 제외했고, 저장소를 열거나 읽는 오류·저장소 삭제·버전 호환성은 여전히 별도로 확인합니다.

코드를 따라갈 때 install의 waitUntil()과 fetch의 respondWith()를 구별하세요. 전자는 설치 작업 완료를 기다리고, 후자는 요청에 돌려줄 응답 Promise를 정합니다. 이 예제는 그 Promise 안에서 cache.put()까지 기다립니다. 저장이 실패해도 온라인 응답은 반환하므로 “응답을 받음”만으로 캐시 저장 성공을 단정하지 않습니다. 미캐시 탐색의 네트워크 실패는 503 안내 응답으로, CSS·JS 실패는 네트워크 오류로 처리하며 거래 성공으로 바꾸지 않습니다.

이 예제는 이름으로 연 cache.match()로 현재 버전만 조회합니다. CacheStorage.match는 여러 캐시를 검색하는 다른 API입니다. activate에서는 이 앱에만 할당한 접두사로 시작하는 이전 캐시만 삭제합니다. 또 Cache API는 HTTP 캐시 헤더를 자동으로 따르지 않으므로 Cache-Control: no-store만으로 코드의 cache.put()을 막을 수 있다고 생각하면 안 됩니다. 공개 파일 허용 목록과 서버의 응답 계약을 함께 관리합니다.

제어 중인 클라이언트가 허용 목록의 공개 GET 파일을 쿼리 없이 요청한다고 정합니다. 현재 버전 캐시에 있으면 오프라인이어도 반환합니다. 캐시가 없고 네트워크도 실패하면 탐색은 503 안내, 다른 자원은 오류가 됩니다. 온라인 basic 200 응답은 복제본의 저장 완료 또는 저장 실패 처리를 기다린 뒤 원 응답을 반환하고, basic 404는 저장하지 않고 반환합니다. 이는 예제 분기의 설명이며 실제 기기에서 서비스 워커를 등록해 관측한 결과는 아닙니다.

캐시가 비어 있을 때 네트워크가 실패한 경우와 basic 404를 반환한 경우를 구별해 보세요. 응답을 이미 받았다는 사실만으로 다음 오프라인 요청도 성공한다고 말할 수 있나요? 새 버전의 설치 작업이 실패했거나 기존 버전이 제어 중인 탭이 남아 있다면 적용 시점을 어떻게 확인해야 하나요?

PWA 핵심 정리

핵심은 서비스 워커, 매니페스트, HTTPS를 기능 체크리스트가 아니라 배포 전략으로 함께 다루는 것입니다.

이번 장에서는 웹의 한계를 넘어 네이티브 앱과 같은 사용자 경험을 제공하는 PWA(Progressive Web App)에 대해 학습했습니다.

PWA의 개념과 서비스 워커(Service Worker), 웹 앱 매니페스트(Web App Manifest), HTTPS의 역할을 정리했습니다.

이 요소들이 오프라인 지원, 푸시 알림, 홈 화면 추가 기능과 어떻게 연결되는지도 함께 확인했습니다.

PWA는 오프라인 동작, 설치 가능성, 푸시 알림처럼 웹 앱의 사용성을 높이는 선택지입니다.

모든 웹 애플리케이션에 필요한 것은 아니므로, 서비스 특성과 사용자 환경에 맞춰 적용 여부를 판단해야 합니다.

지원하지 않거나 사용자가 권한을 거부한 경우에도 일반 웹 화면의 핵심 작업이 가능한 대체 경로를 정합니다. 오프라인에 보일 공개 정보와 최신 서버 승인이 필요한 결제·권한 변경을 구별하고, 캐시된 화면만으로 거래 성공을 선언하지 않습니다.

PWA 흐름은 설치 가능성, 서비스 워커 요청 처리, 캐시 갱신을 배포 후 점검 루틴으로 연결해야 안정적으로 유지됩니다.

직접 연습: 캐시 범위와 갱신 시점을 추적한다

1. 같은 출처에서 GET /styles.css, POST /api/orders, GET /api/me, GET /styles.css?v=2를 요청합니다. 위 허용 목록과 조건에서 서비스 워커가 응답 Promise를 지정하는 요청은 무엇인가요? 주문 API 실패를 캐시된 성공 화면으로 대신해도 되나요?

2. 저장소에 my-pwa-public-v0, my-pwa-public-v1, other-app-cache-v3가 있고 v1이 활성화됩니다. 어떤 이름을 삭제하나요? /styles.css가 v0에만 있어도 v1 코드의 cache.match()가 그 파일을 찾나요?

3. 기존 v1이 탭 두 개를 제어합니다. v2의 install이 성공했고 skipWaiting()·clients.claim()은 호출하지 않았습니다. 배포 직후 두 탭이 자동으로 v2를 쓰나요? install의 addAll이 실패한 경우와 어떻게 다른가요?