WebPiki
it

PWA 2026: 프로그레시브 웹 앱 아직도 유효할까?

PWA의 현재 위치, 네이티브 앱과의 차이, 2026년 기준 PWA가 적합한 경우와 한계를 정리했다.

PWA가 처음 주목받던 2016~2018년쯤에는 "네이티브 앱을 대체할 것"이라는 기대가 컸다. 그로부터 거의 10년이 지난 지금, 현실은 어떨까. 앱스토어에서 네이티브 앱은 여전히 건재하고, PWA가 세상을 지배하지는 않았다. 그렇다고 PWA가 죽은 것도 아니다. 오히려 특정 영역에서는 더 실용적인 선택지가 됐다.

PWA가 뭔지 빠르게 복습

Progressive Web App. 웹 기술(HTML, CSS, JavaScript)로 만들면서 네이티브 앱처럼 동작하는 웹 애플리케이션이다. 핵심 특성은 세 가지.

설치 가능. 홈 화면에 추가해서 독립 앱처럼 실행할 수 있다. 브라우저 주소창 없이, 전체 화면으로.

오프라인 동작. Service Worker가 리소스를 캐싱해서, 네트워크가 없어도 최소한의 기능은 동작한다.

푸시 알림. 앱이 닫혀있어도 서버에서 알림을 보낼 수 있다.

이 세 가지를 가능하게 하는 기술적 요소가 manifest.json과 Service Worker다.

manifest.json

앱의 메타데이터를 정의하는 JSON 파일이다. 이름, 아이콘, 시작 URL, 테마 색상, 화면 방향 등을 지정한다.

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

display: "standalone"으로 설정하면 브라우저 UI 없이 독립 앱처럼 보인다. fullscreen은 상태바까지 숨긴다. 게임 같은 데 적합하다.

HTML에서 링크하는 건 간단하다:

<link rel="manifest" href="/manifest.json">

Service Worker

PWA의 핵심. 브라우저와 네트워크 사이에서 프록시 역할을 하는 JavaScript 워커다. 메인 스레드와 별개로 동작하며, 네트워크 요청을 가로채서 캐시된 리소스를 반환하거나, 백그라운드 동기화를 처리하거나, 푸시 알림을 받는다.

// sw.js — 기본적인 Service Worker
const CACHE_NAME = "v1";
const ASSETS = ["/", "/offline.html", "/styles.css", "/app.js"];

// 설치 시 핵심 리소스 캐싱
self.addEventListener("install", (event) => {
  event.waitUntil(
    caches.open(CACHE_NAME).then((cache) => cache.addAll(ASSETS))
  );
});

// 네트워크 요청 가로채기
self.addEventListener("fetch", (event) => {
  event.respondWith(
    caches.match(event.request).then((cached) => {
      // 캐시에 있으면 캐시 응답, 없으면 네트워크 요청
      return cached || fetch(event.request);
    })
  );
});

캐싱 전략은 여러 가지가 있다:

  • Cache First — 캐시 우선. 정적 리소스(이미지, 폰트, CSS)에 적합
  • Network First — 네트워크 우선. API 응답 같은 동적 데이터에 적합
  • Stale While Revalidate — 캐시된 걸 일단 보여주면서 백그라운드에서 업데이트. 뉴스 피드 같은 데 적합

Workbox(구글 라이브러리)를 쓰면 이런 전략을 선언적으로 설정할 수 있어서 직접 Service Worker를 처음부터 짜는 것보다 훨씬 편하다.

2026년 브라우저 지원 현황

PWA의 가장 큰 걸림돌이었던 iOS가 많이 개선됐다.

Chrome/Edge/Samsung Internet — PWA 지원이 완벽하다. 설치, 오프라인, 푸시 알림 전부 지원.

Safari (iOS) — 오랫동안 PWA에 소극적이었던 사파리가 많이 따라왔다. 푸시 알림은 iOS 16.4(2023년)부터 지원 시작됐고, 홈 화면 추가도 된다. 그래도 몇 가지 제약이 남아있다:

  • Web Bluetooth, Web USB 같은 하드웨어 접근 API 미지원
  • 백그라운드 동기화 제한적
  • 앱 배지(Badge API) 부분 지원
  • PWA 스토리지가 일정 기간 사용하지 않으면 정리될 수 있음

iOS의 이런 제약 때문에 "PWA로 네이티브를 완전 대체"하기는 여전히 어렵다. 하지만 기본적인 기능(오프라인, 설치, 푸시)은 모든 주요 브라우저에서 동작하니까, 대부분의 유스케이스에서는 충분하다.

PWA vs 네이티브 vs 하이브리드

앱을 만들겠다고 결정했을 때 선택지가 여러 개다. 각각의 특성을 비교해보자.

네이티브 (Swift/Kotlin)

  • 성능 최상. 하드웨어 접근 완벽
  • 앱스토어 배포. 사용자에게 "앱"으로 인식됨
  • iOS와 Android를 각각 따로 개발해야 함. 비용 2배
  • 업데이트할 때마다 스토어 심사 필요

크로스 플랫폼 (React Native, Flutter)

  • 하나의 코드베이스로 iOS + Android
  • 네이티브에 가까운 성능과 UX
  • 네이티브 모듈 필요 시 결국 플랫폼별 코드 작성
  • 앱스토어 배포

PWA

  • 웹 기술만으로 개발. 웹 개발자가 바로 시작 가능
  • 설치 없이 URL로 접근. 설치도 가능
  • 업데이트가 즉시 반영됨. 스토어 심사 불필요
  • 하드웨어 접근 제한. 성능 한계
  • 앱스토어에 없음 (TWA로 래핑해서 올릴 수는 있음)

어느 게 무조건 낫다고 말할 수 없다. 프로젝트 성격에 따라 다르다.

PWA가 적합한 경우

콘텐츠 중심 서비스. 뉴스, 블로그, 커머스 카탈로그 같은 서비스. 복잡한 네이티브 기능이 필요 없고, 콘텐츠 접근성이 중요한 경우. 트위터(현 X)의 PWA, 스타벅스 PWA가 대표적 성공 사례다.

이머징 마켓 타겟. 저사양 기기, 불안정한 네트워크 환경이 흔한 시장. PWA는 앱 크기가 작고 오프라인 지원이 되니까 이런 환경에서 유리하다. 이 점 때문에 인도, 아프리카 시장을 타겟하는 서비스에서 PWA를 많이 채택했다.

B2B/사내 도구. 사내 직원만 쓰는 도구를 앱스토어에 올릴 이유가 없다. URL로 공유하고, 필요하면 홈 화면에 추가하면 된다. 업데이트도 배포 즉시 반영되니까 관리가 편하다.

프로토타이핑. 아이디어를 빠르게 검증할 때. 앱스토어 심사 기다릴 필요 없이 URL 하나로 배포. 반응이 좋으면 네이티브로 전환하면 된다.

예산이 제한적일 때. 웹 개발 팀만 있어도 만들 수 있다. iOS + Android 각각의 네이티브 개발자를 고용하는 것 대비 비용이 크게 절감된다.

PWA의 한계

솔직히 한계도 분명하다.

성능. 그래픽이 많은 게임이나 영상 편집 같은 고성능 앱은 PWA로 만들기 어렵다. WebGL, WebGPU 등으로 많이 좋아졌지만 네이티브와의 차이는 존재한다.

하드웨어 접근. NFC, 블루투스, 생체 인증 같은 하드웨어 기능이 필요하면 PWA로는 한계가 있다. Web Bluetooth API 같은 것들이 있긴 하지만 브라우저 지원이 제한적이다.

앱스토어 부재. 사용자들이 앱을 찾는 주요 경로인 앱스토어에 없다. 마케팅 채널 하나를 잃는 셈이다. Google Play에는 TWA(Trusted Web Activity)로 래핑해서 올릴 수 있지만, App Store는 정책이 더 까다롭다.

iOS 제약. 앞서 언급한 Safari의 제약들. 특히 백그라운드 동작과 특정 API 지원 부분에서 네이티브와 차이가 크다.

사용자 인식. "앱을 설치하세요"와 "홈 화면에 추가하세요"는 사용자에게 다르게 느껴진다. PWA 설치 과정이 직관적이지 않아서 설치 전환율이 낮은 편이다.

실제 성공/실패 사례

성공 사례:

  • Twitter Lite (현 X) — PWA로 전환 후 데이터 사용량 70% 감소, 페이지 로드 30% 빨라짐
  • Starbucks — 오프라인에서도 메뉴 브라우징 가능한 PWA. 네이티브 앱 대비 99.84% 작은 크기
  • Pinterest — 모바일 웹을 PWA로 전환 후 사용자 체류시간 40% 증가
  • Trivago — PWA 전환 후 사용자 참여도 150% 증가

애매한 사례:

일부 기업은 PWA를 시도했다가 네이티브로 돌아가기도 했다. 대체로 "네이티브 수준의 UX가 필요한데 PWA로는 부족했다"는 이유다. 결제 처리, 카메라 활용, 위치 기반 기능이 핵심인 서비스에서 이런 경향이 있다.

Next.js에서 PWA 적용하기

Next.js 프로젝트에 PWA를 적용하는 건 어렵지 않다. next-pwa 패키지가 Service Worker 생성을 자동화해준다.

npm install next-pwa

// next.config.js
const withPWA = require("next-pwa")({
  dest: "public",
  disable: process.env.NODE_ENV === "development",
});

module.exports = withPWA({
  // 기존 Next.js 설정
});

manifest.json을 public/ 폴더에 넣고, _document.tsx에 링크를 추가하면 기본 세팅은 끝이다. 개발 모드에서는 Service Worker를 비활성화하는 게 캐싱 때문에 생기는 혼란을 방지하는 데 좋다.

2026년에 PWA를 선택해야 할까

결론부터 말하면, 상황에 따라 다르다.

웹 기술 스택이 이미 있고, 네이티브 수준의 하드웨어 접근이 필요 없고, 빠른 배포와 접근성이 중요하다면 PWA는 여전히 좋은 선택이다. iOS의 지원이 개선되면서 실용적으로 쓸 수 있는 범위도 넓어졌다.

반면 앱스토어 노출이 중요하거나, 복잡한 네이티브 기능이 필수라면 React Native나 Flutter가 더 적합하다. 예산과 시간이 충분하면 네이티브도 당연히 고려 대상이다.

PWA가 네이티브를 대체하지는 못했지만, 그게 PWA의 실패를 의미하지는 않는다. 웹의 강점(접근성, 링크 공유, 즉시 업데이트)과 앱의 장점(설치, 오프라인, 알림)을 결합한 실용적인 선택지로 자리를 잡았다. 모든 프로젝트에 맞는 건 아니지만, 맞는 프로젝트에는 확실히 효율적이다.

#PWA#웹앱#Service Worker#오프라인#모바일

관련 글

it멀티모달 AI란? 텍스트·이미지·음성을 동시에 이해하는 AIitFine-tuning vs RAG: 언제 어떤 방식을 선택해야 할까itAI 편향과 윤리: 2026년 개발자가 알아야 할 것들