원활한 PWA 출처 이전: 사용자를 잃지 않고 도메인 변경

Dibyajyoti Pal
Dibyajyoti Pal
Dan Murphy
Dan Murphy
Marijn Kruisselbrink
Marijn Kruisselbrink

게시일: 2026년 6월 3일

프로그레시브 웹 앱 (PWA)은 앱과 유사한 환경을 제공하여 웹에 혁신을 가져왔습니다. 하지만 가장 큰 강점 중 하나가 지속적인 문제이기도 했습니다. 앱 ID가 웹 출처와 긴밀하게 연결되어 있기 때문입니다.

리브랜딩하거나 아키텍처를 재구성 (예: 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와 유사하며, 앱 창의 오른쪽 상단에 사용자에게 알림이 표시됩니다.

앱 창에 앱 업데이트가 제공된다고 표시됩니다. 드롭다운에는 '앱 업데이트 검토' 링크가 포함되어 있습니다.

앱 업데이트 검토를 클릭하면 매니페스트에서 변경된 사항에 따라 다음 UX가 표시됩니다.

대화상자에서 사용자에게 로고, 이름, URL 업데이트를 검토하도록 요청합니다.

사용자 환경 관리

behavior 플래그를 사용하여 마이그레이션의 공격성을 선택할 수 있습니다.

  1. 제안 (기본값): 사용자에게 수동 알림이 표시됩니다 (예: 앱 메뉴). 대화상자를 실행하여 앱을 업데이트하거나, 앱을 제거하거나, 이전을 무시할 수 있습니다.
  2. 강제: 다음 앱 실행 시 사용자에게 차단 대화상자가 표시됩니다. 새 출처로 업데이트하거나 앱을 제거해야 합니다(다음 스크린샷 참고).

다음 예에서는 이 선택사항을 설정하는 방법을 보여줍니다.

"migrate_from": [
  { 
    "id": "https://example.com/social/",
    "behavior": "force" // or suggest
  }
]

대화상자에는 새 버전의 앱이 필요하다고 사용자에게 안내합니다.

결론

PWA 이전 기능을 사용하면 개발자가 사용자를 소외시키지 않고도 최신 유연한 웹 아키텍처를 계속 빌드할 수 있습니다.