PWA(Progressive Web App)

0) 한 문장 정의

PWA는 ‘웹으로 만든 앱’이지만 설치·오프라인·푸시 등 네이티브급 경험을 제공하는 앱 형태이다. 브라우저에서 접근하되, 홈 화면 설치(A2HS), 캐시 기반 빠른 구동, 웹 푸시, 백그라운드 동기화 등 핵심 기능을 갖추면 사용자는 ‘앱’처럼 느낀다.

---

1) 왜 PWA인가? (비즈니스 관점)

1.1 설치 장벽 최소화 → 초기 전환 개선

• 앱스토어를 거치지 않고 브라우저에서 바로 설치(홈 화면 추가) 가능
• 다운로드/로그인 이전의 첫 사용 진입률을 높이기 용이

1.2 배포·업데이트 민첩성

• 심사 없이 서버 배포만으로 즉시 반영 → 릴리즈 주기 단축, 실험 속도↑
• 긴급 이슈 대응(카피 수정, 플로우 조정)이 빠름

1.3 비용 효율 & 멀티플랫폼

• 하나의 코드베이스로 모바일·데스크톱·태블릿 동시 대응
• 소규모 팀/신시장 검증, 기능별 롤아웃에 유리

1.4 저사양/저속 네트워크 시장 대응
오프라인/저대역폭 전략으로 신흥시장(3G/불안정 네트워크) 사용자 확보

• 적합한 케이스: 콘텐츠 소비/커머스/예약/유틸리티/사내 시스템의 모바일 접근성 강화
• 신중할 케이스: 고사양 실시간 그래픽, 카메라·센서에 강하게 의존하는 헤비 네이티브 기능

---

2) 핵심 UX/기능 요소

2.1 설치 경험(A2HS: Add to Home Screen)

• 조건: HTTPS, 유효한 Web App Manifest, Service Worker 등록, 아이콘 등
• UX: 맞춤형 설치 시점이 중요. 예: 2~3회 재방문 또는 핵심 과업 1회 완료 후 소프트 프롬프트(상단 배너/모달) → 과도한 강요 금지
• 카피: “앱 설치 없이 홈 화면에서 바로 열기”, “데이터 절약, 더 빠른 실행”

2.2 오프라인/약한 네트워크 대응

• 앱 셸(App Shell) 아키텍처: 네비게이션·헤더·푸터·기본 CSS/JS를 캐시에 상주시켜 즉시 렌더
• 오프라인 화면(친절한 Empty State): “오프라인입니다. 최근에 본 콘텐츠를 표시합니다.” + 재시도 버튼
• 읽기 중심 서비스는 캐시 우선(Cache-first), 입력·거래는 네트워크 우선(Network-first) 등 시나리오별 전략 분리

2.3 웹 푸시 알림 (지원 플랫폼에서)

• Opt-in 시점 설계: 가치 제안 → 사전 안내(soft ask) → 브라우저 권한 요청 2단계 구조
• 세그먼트: 장바구니 이탈, 관심 카테고리, 가격하락/재입고, 배송 업데이트
• 남발 방지: 빈도 캡핑, 사용자 통제 UI(알림 설정 페이지) 제공

2.4 백그라운드 동기화(Background Sync)

• 사용자가 오프라인일 때 작성한 폼/메시지/리뷰를 네트워크 복귀 시 자동 전송
• UX: 전송 상태 토스트, 실패 시 복구(‘다시 시도’) 제공

2.5 설치형 앱 같은 외형

• 전체 화면(Display: standalone/fullscreen), 스플래시 이미지, 맞춤 아이콘
• URL 노출 최소화(standalone)와 기본 내비게이션 일관성 확보.

---

3) 기술 구성요소를 기획 언어로 이해하기

3.1 Web App Manifest (앱의 메타정보)

• 주요 필드: name, short_name, icons(다양한 사이즈), start_url, display, background_color, theme_color, categories
• 기획 포인트: 브랜드 컬러·앱명·시작 화면·스플래시 일관성. 지역/언어별 다국어 manifest 고려

예시 (요지)

{
  "name": "Acme Shop",
  "short_name": "Acme",
  "start_url": "/?source=a2hs",
  "display": "standalone",
  "background_color": "#FFFFFF",
  "theme_color": "#111111",
  "icons": [
    {"src": "/icons/icon-192.png", "sizes":"192x192", "type":"image/png"},
    {"src": "/icons/icon-512.png", "sizes":"512x512", "type":"image/png"}
  ]
}

3.2 Service Worker (오프라인·캐시·푸시의 엔진)

• 라이프사이클: install → activate → fetch/notification/sync
• 기획 체크: 업데이트 전략, 캐시 만료 정책, 오프라인 UX 존재 여부
• 실무는 보통 Workbox(구글 OSS)로 정책별 캐싱을 선언적으로 관리

3.3 App Shell 패턴

• 앱 UI 뼈대(헤더/탭바/레이아웃) 선캐시 → 빠른 First Paint
• 동적 데이터는 네트워크 또는 캐시 백업에서 채움

---

4) 오프라인/캐시 전략(의사결정 표준안)

• 정적 리소스(JS/CSS/폰트/아이콘): Cache-first with versioning

→ 빌드 버전(파일명 해시)로 교체, 오래된 캐시 정리.
상품 목록/뉴스피드 같은 읽기 데이터: Stale-while-revalidate
→ 즉시 캐시 응답 + 백그라운드 최신화.
거래성 API(결제/포인트/재고): Network-first with fallback
→ 최신성 보장, 실패 시 오프라인 메시지.
사용자 작성(폼/업로드): Background Sync + Retry Queue.

---

5) 성능·품질 지표(측정·개선 계획)

5.1 핵심 지표

• LCP(주요 콘텐츠 표시): ≤ 2.5s 목표
• INP(상호작용 반응성): ≤ 200ms
• CLS(레이아웃 이동): ≤ 0.1
• 오프라인 성공 비율: 오프라인 화면 노출 대비 작업 완료율
• 설치 전환율: 설치 프롬프트 노출→수락 비율
• 재방문/재실행 간격: PWA 아이콘 진입 비중, 홈화면 실행 빈도
• 푸시 Opt-in율 / 해지율, 푸시→세션 전환율

5.2 도구/프로세스

• Lighthouse/PWA Audit로 자동 점검(Installable, Best Practices)
• RUM(실사용자 모니터링)로 Core Web Vitals 수집
• 배포 전 네트워크 시뮬레이션(저속/오프라인) QA 필수

---

6) 동의·보안·정책 (리스크 최소화)

• HTTPS 의무: 서비스 워커/푸시/센서 API는 보안 컨텍스트에서만 동작
• 개인정보/쿠키 정책: 웹 푸시, 로컬 저장소 사용 고지 및 동의 관리(쿠키 배너/설정)
• 콘텐츠 보안 정책(CSP): 제3자 스크립트 최소화, 출처 화이트리스트
• 스토리지 쿼터/삭제 정책: 브라우저가 저장 공간 회수할 수 있으므로 복원 UX(재동기화) 준비
• 알림 가이드라인 준수: 과도한 권한 요청 금지, 간격 제한, 설정 경로 제공

---

7) iOS/Android 브라우저 특성

플랫폼별 지원 기능 차이는 상존
예: 설치 UX, 푸시/백그라운드 처리, 파일 시스템 접근, Web Share/Payment API 지원 범위

기획적으로는 플래그십 기능을 공통지원으로 제한하고, 플랫폼 특화 기능은 선택적 보완(조건부 UI, 대체 흐름) 전략으로 설계

포인트
어디서나 반드시 동작해야 하는 사용자 시나리오”를 최우선으로 정의하고, 대체 플로우(푸시 미지원 시 이메일/인앱 알림 등)를 함께 마련한다.

---

8) 배포 옵션과 스토어 전략

• 웹 직접 배포: URL 접근 + A2HS. 가장 민첩, 마케팅 랜딩과 연계 최적
• Play 스토어 노출(TWA: Trusted Web Activity): PWA를 안드로이드 앱 껍데기로 감싸 스토어 유통. 검색·평가·리뷰 생태계 활용
• 앱스토어 전략: iOS는 네이티브 래퍼(웹뷰)로 배포 시 정책 이슈(웹결제/사설 마켓 유도 등) 검토 필요→ PWA는 ‘웹’이 강점이므로, ‘네이티브 유통’의 필요성이 명확할 때만 래핑 고려

---

9) 데이터·실험 설계 (PRD에 들어갈 항목 예시)

9.1 이벤트·파라미터

• install_prompt_shown, install_accepted, install_dismissed
• offline_view_shown, offline_action_retry
• push_optin_shown, push_optin_accepted, push_clickthrough
• background_sync_success/failure

9.2 A/B 테스트 아이디어

• 설치 프롬프트 타이밍: 첫 방문 vs 3회차 vs 과업 완료 후
• 오프라인 화면 카피: 정보량/위로 메시지/재시도 버튼 위치
• 초기 로딩 전략: App Shell만 먼저 vs 핵심 리스트 프리패치

---

10) 정보 구조(IA) & 네비게이션 (PWA 친화 설계)

• 경로가 URL로 표현되어야 딥링크/공유/SEO가 유효
• 주요 페이지는 SSR/프리렌더링 고려(초기 페인트 확보 + 검색 노출 강화)
• 하단 탭(Home/탐색/장바구니/마이) + 상단 검색의 익숙한 패턴 유지(Jakob’s Law)

---

11) 접근성·국제화

• 접근성: 키보드 포커스, 스크린리더 레이블(ARIA), 대비, 터치 타겟 ≥ 44px, 애니메이션 감소 옵션
• 다국어: 언어별 lang/dir 설정, 단위·날짜 포맷, LTR/RTL 고려
• 저시력/저대역폭 모드: 이미지 해상도 스텝, 텍스트 우선 모드 옵션

---

12) PRD 샘플 구조 (요약 템플릿)

1. 목표/배경: 설치 장벽 제거, 초회 재방문율 +X%
2. 핵심 기능: 설치(A2HS), 오프라인, 푸시, 백그라운드 동기화
3. 사용자 시나리오

• S1: 비로그인 사용자가 기사 1건 읽고 설치 유도 노출
• S2: 오프라인 시 저장글 읽기 + 온라인 복귀 동기화

4. 요건

• Manifest 필수 필드, 아이콘 사이즈, display: standalone
• SW 캐싱 정책(정적/동적), 오프라인 스크린 카피

5. 비기능 요건: LCP ≤2.5s, CLS ≤0.1, Lighthouse PWA 90+
6. 권한·정책: HTTPS, 알림 soft ask, 설정 페이지
7. 데이터/실험: 이벤트 스키마, A/B 가설, 통계 기준
8. QA 시나리오: 오프라인 탐색, 캐시 무효화, 설치/삭제/재설치

---

13) 운영·릴리즈 플랜

• 점진적 롤아웃: 트래픽 10%→30%→100% 전환. 성능/오류 모니터링
• 버전 관리: 캐시 버전(예: app-v2025.08.13) 명시, 이전 캐시 제거 루틴
• 장애 대응: 서비스 워커 강제 비활성화 플래그(서버 헤더/버전 핀) 준비
• 로그·모니터링: 푸시 실패율, 백그라운드 동기화 큐 길이, 스토리지 에러 수집

---

14) 제한사항·리스크와 대안

• 플랫폼 기능 편차: 일부 브라우저의 푸시/백그라운드 제약 → 대체 알림 채널 제공(이메일/인앱)
• 스토리지 해제 위험: 브라우저가 캐시 삭제 가능 → 복원 동기화 UX
• SEO 이슈: CSR만으로는 노출 약함 → SSR/프리렌더 하이브리드
• 결제·인앱 정책: 웹 결제는 브라우저·PG 지원 범위 확인, 스토어 정책 충돌 주의
• 보안: 오프라인 캐시에 민감정보 저장 금지(토큰/개인정보)

---

15) 체크리스트 (기획 마감 전)

1. Manifest: 이름/아이콘/시작 URL/디스플레이/테마 색상 확정
2. 설치 UX: 타이밍·카피·거절 시 재노출 정책
3. 오프라인: 캐시 범위/만료/대체 화면/재시도 버튼
4. 푸시: opt-in 흐름, 주제/빈도, 설정 페이지, 해지 루트
5. 성능 목표: Core Web Vitals 기준 수치와 측정 방법 정의
6. 데이터: 이벤트 스키마/대시보드 정의(설치·오프라인·푸시)
7. 접근성/다국어: 최소 요건 충족 확인
8. QA: 저속/오프라인/스토리지 회수/업데이트/재설치 시나리오ㅡ