Chrome

원활한 PWA 출처 이전: 사용자 손실 없이 도메인 변경

원문: Seamless PWA origin migration: Change domains without losing users
— Chrome Developers 원문은 CC-BY-4.0
라이선스로 제공되며, 이 글은 한국어로 번역한 2차 저작물입니다.
Progressive Web Apps(PWAs)는 앱과 같은 경험을 제공하여 웹을 혁신했습니다. 그러나 이러한 강력한 기능 중 하나는 앱의 정체성이 웹 출처에 강하게 연결되어 있다는 지속적인 과제였습니다.
리브랜딩하거나 아키텍처를 재구성할 때 (예:
www.example.com/social
에서
social.example.com
으로 이동) 사용자에게 고통스러운 딜레마가 있었습니다. 설치된 PWA를 "이동"할 방법이 없었습니다. 사용자는 수동으로 이전 앱을 제거하고 새 앱의 설치 버튼을 찾아야 했습니다.
PWA 팀은 Chrome 150에서 PWA 출처 이전을 도입하게 되어 기쁘게 생각합니다. 이 새로운 플랫폼 기능을 통해 사용자의 중단을 최소화하면서도 사용자에게 충분한 정보를 제공하면서 설치된 PWA를 새로운 동일 출처로 원활하게 전환할 수 있습니다.

출처 이전이 가능한 것

사이트 아키텍처를 사용자 경험을 해치지 않고 수정할 수 있습니다.
  • 기술 아키텍처 자유: 애플리케이션의 하위 도메인 또는 경로를 변경할 수 있습니다.
  • 분할 앱 상태 수정: 안정적인 ID 없이
    start_url
    을 변경하여 중복 앱 설치
    를 실수로 생성한 문제를 해결합니다.
사용자는 간단한 업데이트 대화 상자를 통해 앱을 이전할 수 있습니다. 이는 표준 앱 업데이트
와 유사한 방식으로 마이그레이션에 대한 정보를 받습니다. 클릭 한 번으로 이전 앱이 제거되고 새 앱이 설치 및 실행됩니다.

PWA 이전 방법

PWA를 이전하려면 다음 단계를 따르십시오. 나머지 내용은 더 자세히 설명합니다.
  1. 핸드셰이크 배포:
    • 새 앱에
      migrate_from
      을 추가합니다.
    • 이전 출처의
      /.well-known/web-app-origin-association
      파일에
      allow_migration
      필드를 추가합니다.
  2. 동작 선택:
    suggest
    (또는 비어 있음)는 사용자에게 방해를 주지 않으므로 초기 롤아웃 중에 유용할 수 있습니다.
    force
    는 사용자를 차단하고 사용자가 이전 URL을 계속 사용할 수 없는 경우 마이그레이션을 요구합니다.
  3. 이전 앱을 최신 상태로 유지: 이전 사이트가 새 사이트로 리디렉션되는 경우
    migrate_from
    블록의
    install_url
    속성을 사용하여 브라우저가 잠재적 업데이트를 위해 이전 매니페스트를 계속 찾을 수 있도록 합니다.
  4. 대상 매니페스트에
    id
    구현:
    Chrome은 대상 앱 매니페스트에
    id
    필드를 포함해야 합니다. 이렇게 하면 앱이
    id
    가 설정되지 않은 상태로
    start_url
    을 변경하여 분할 앱 생성
    이라는 일반적인 실수를 저지르는 것을 방지할 수 있습니다.

양방향 핸드셰이크: 작동 방식

보안을 보장하고 악의적인 인수를 방지하기 위해 마이그레이션에는 이전 출처와 새 출처 간의 보안 핸드셰이크가 필요합니다. 이 핸드셰이크는 두 사이트가 동일한 엔터티에 의해 제어됨을 보장합니다.

1단계: 새 앱이 이전 앱 선언 (필수)

애플리케이션의 웹 앱 매니페스트에
migrate_from
필드를 추가합니다.
// Manifest at https://fileman.google.com/manifest.json
{
  "name": "File Manager",
  "id": "/files/",
  "start_url": "/files/index.html",
  ....
  "migrate_from": [
    "https://drive.google.com/"
  ]
}

2단계: 이전 출처가 마이그레이션 확인 (필수)

새 사이트가 이전 앱을 일방적으로 가로채는 것을 방지하기 위해 이전 출처는 마이그레이션을 명시적으로 승인해야 합니다.
.well-known
구성 파일을 사용하여 이를 수행합니다.
// File at https://drive.google.com/.well-known/web-app-origin-association
{
  "https://fileman.google.com/files/": {
    "allow_migration": true
  }
}

3단계: 사전 신호 (선택 사항)

사용자가 새 사이트를 방문할 때까지 기다리지 않고 업데이트를 트리거하려면 이전 앱 매니페스트를 새 앱을 가리키도록 업데이트합니다.
// Manifest at https://drive.google.com/manifest.json
{
  "name": "Drive",
  "start_url": "/",
  "migrate_to": {
    "id": "https://fileman.google.com/files/",
    "install_url": "https://fileman.google.com/drive/installwebapp?usp=migrate"
  }
}

4단계: 리디렉션 처리 (선택 사항)

migrate_to
필드를 사용하는 대신 이전 앱 URL을 새 앱으로 리디렉션하여 마이그레이션을 신호하고
scope_extensions
를 사용하여 범위 외부 배너가 이전 앱에 표시되지 않도록
할 수 있습니다. 이는 이전 앱의 매니페스트가 절대 보이지 않으므로 업데이트할 수 없음을 의미합니다. 앱 마이그레이션이 발생하기 전에 이전 앱이 계속 업데이트되도록 허용하려면
migrate_from
내부의
install_url
을 설정하여 이전 매니페스트가 첨부된 URL을 가져오도록 브라우저에 알립니다.
// Manifest at https://fileman.google.com/manifest.json
{
  "name": "File Manager",
  "id": "/files/",
  "start_url": "/files/index.html",
  ....
  "migrate_from": [
    {
      "id": "https://drive.google.com/",
      "install_url": "https://drive.google.com/drive/installwebapp?usp=migrate"
    }
  ]
}

그게 전부입니다! UX는 앱 업데이트
에 사용되는 것과 유사하며, 사용자는 앱 창 오른쪽 상단에 알림을 받습니다.
앱 창에 앱 업데이트를 사용할 수 있음을 보여줍니다. 드롭다운에는 앱 업데이트 검토 링크가 포함되어 있습니다.
앱 업데이트 검토를 클릭하면 (매니페스트에서 변경된 내용에 따라) 다음 UX가 표시됩니다.
대화 상자가 사용자에게 로고, 이름 및 URL 업데이트를 검토하도록 요청합니다.

사용자 경험 제어

behavior
플래그를 사용하여 마이그레이션의 공격성을 선택할 수 있습니다.
  1. 제안 (기본값): 사용자는 수동 알림 (예: 앱 메뉴)을 받습니다. 업데이트, 앱 제거 또는 대화 상자를 실행하여 마이그레이션을 무시하도록 선택할 수 있습니다.
  2. 강제: 앱을 다음에 시작할 때 차단 대화 상자가 표시됩니다. 새 출처로 업데이트하거나 앱을 제거해야 합니다 (다음 스크린샷 참조).
다음 예는 이 선택을 설정하는 방법을 보여줍니다.
"migrate_from": [
  { 
    "id": "https://example.com/social/",
    "behavior": "force" // or suggest
  }
]

대화 상자가 사용자에게 앱의 새 버전이 필요하다고 알려줍니다.

결론

PWA 이전 기능은 개발자가 사용자를 뒤처지게 하지 않고 최신적이고 유연한 웹 아키텍처를 계속 구축할 수 있도록 지원합니다.