Google I/O를 시청해 주셔서 감사합니다. 주문형 콘텐츠를 확인하세요.

Google은 AI 기술을 사용하여 콘텐츠를 사용자의 기본 언어로 번역합니다. AI 번역에는 오류가 있을 수 있습니다.

다중 출처 사이트의 프로그레시브 웹 앱

멀티 출처 사이트에서 프로그레시브 웹 앱을 빌드할 때 발생하는 문제와 해결 방법

Demián Renzulli

게시일: 2019년 8월 19일

이전에는 다중 출처 아키텍처를 사용하면 몇 가지 이점이 있었습니다. 프로그레시브 웹 앱의 경우 이러한 접근 방식은 많은 문제를 야기합니다. 특히 동일 출처 정책은 서비스 워커, 캐시, 권한과 같은 항목을 공유하고 여러 출처에서 독립형 환경을 구현하는 데 제한을 적용합니다.

여러 출처의 올바른 사용과 잘못된 사용을 알아보고, 멀티 출처 사이트에서 프로그레시브 웹 앱을 빌드할 때의 문제와 해결 방법을 설명합니다.

여러 출처의 올바른 사용과 잘못된 사용

사이트에서 다중 출처 아키텍처를 사용하는 데는 몇 가지 타당한 이유가 있으며, 대부분은 독립적인 웹 애플리케이션 세트를 제공하거나 서로 완전히 격리된 환경을 만드는 것과 관련이 있습니다. 피해야 할 사용 사례도 있습니다.

좋은 예

먼저 유용한 이유를 살펴보세요.

현지화/언어: 국가 코드 최상위 도메인을 사용하여 여러 국가에 제공할 사이트를 분리하거나 (예: https://www.google.com.ar) 하위 도메인을 사용하여 여러 위치를 타겟팅하는 사이트를 분할합니다 (예: https://newyork.craigslist.org) 또는 특정 언어 (예: https://en.wikipedia.org)로 콘텐츠를 제공하는 경우에만 사용해야 합니다.
독립적인 웹 앱: 다른 하위 도메인을 사용하여 기본 출처의 사이트와 목적이 크게 다른 환경을 제공합니다. 예를 들어 뉴스 사이트에서 크로스워드 웹 앱은 기본 웹사이트와 리소스나 기능을 공유하지 않고도 의도적으로 https://crosswords.example.com에서 제공되고 독립적인 PWA로 설치 및 사용될 수 있습니다.

단점

이러한 작업을 수행하지 않는 경우 프로그레시브 웹 앱을 빌드할 때 다중 출처 아키텍처를 사용하는 것이 불리할 수 있습니다.

그럼에도 불구하고 많은 사이트가 특별한 이유 없이 또는 '기존' 이유로 이러한 방식으로 계속 구조화되고 있습니다. 예를 들어 하위 도메인을 사용하여 통합된 환경의 일부여야 하는 사이트의 일부를 임의로 분리하는 경우가 있습니다.

예를 들어 다음 패턴은 사용하지 않는 것이 좋습니다.

사이트 섹션: 하위 도메인에서 사이트의 여러 섹션을 분리합니다. 뉴스 사이트에서는 홈페이지가 https://www.example.com에 있고 스포츠 섹션은 https://sports.example.com에, 정치 섹션은 https://politics.example.com에 있는 경우가 많습니다. 이커머스 사이트의 경우 제품 카테고리에 https://category.example.com, 제품 페이지에 https://product.example.com 등을 사용합니다.
사용자 플로우: 권장되지 않는 또 다른 접근 방식은 하위 도메인의 로그인 또는 구매 흐름 페이지와 같이 사이트의 작은 부분을 분리하는 것입니다. 예를 들어 https://login.example.com 및 https://checkout.example.com를 사용합니다.

단일 출처로 이전할 수 없는 경우, 프로그레시브 웹 앱을 빌드할 때 고려할 수 있는 문제 목록과 해결 방법 (가능한 경우)은 다음과 같습니다.

다양한 출처의 PWA에 대한 과제 및 해결 방법

여러 출처에서 웹사이트를 빌드할 때 통합된 PWA 환경을 제공하는 것은 주로 여러 제약 조건을 부과하는 동일 출처 정책으로 인해 어렵습니다. 하나씩 살펴보겠습니다.

서비스 워커

서비스 워커 스크립트 URL의 출처는 register()를 호출하는 페이지의 출처와 동일해야 합니다. 즉, 예를 들어 https://www.example.com의 페이지는 https://section.example.com의 서비스 워커 URL로 register()를 호출할 수 없습니다.

또 다른 고려사항은 서비스 워커가 자신이 속한 출처 및 경로에서 호스팅되는 페이지만 제어할 수 있다는 점입니다. 즉, 서비스 워커가 https://www.example.com에서 호스팅되는 경우 해당 출처의 URL만 제어할 수 있지만(범위 매개변수에 정의된 경로에 따라) 다른 하위 도메인(예: https://section.example.com)의 페이지는 제어하지 않습니다.

이 경우 유일한 해결 방법은 여러 서비스 워커 (출처당 하나)를 사용하는 것입니다.

캐싱

Cache 객체, indexedDB, localStorage도 단일 출처로 제한됩니다. 즉, 예를 들어 https://www.section.example.com에서 https://www.example.com에 속하는 캐시에 액세스할 수 없습니다.

이와 같은 시나리오에서 캐시를 적절하게 관리하기 위해 할 수 있는 몇 가지 작업은 다음과 같습니다.

브라우저 캐싱 활용: 기존 브라우저 캐싱 권장사항을 사용하는 것이 좋습니다. 이 기법은 서비스 워커의 캐시로는 할 수 없는, 출처 간에 캐시된 리소스를 재사용하는 추가적인 이점을 제공합니다. 서비스 워커와 함께 HTTP 캐시를 사용하는 방법에 관한 권장사항은 이 게시물을 참고하세요.
서비스 워커 설치를 가볍게 유지: 여러 서비스 워커를 유지하는 경우 사용자가 새 출처로 이동할 때마다 많은 설치 비용을 지불하지 않도록 합니다. 즉, 반드시 필요한 리소스만 미리 캐시합니다.

권한

권한은 출처로 범위가 지정됩니다. 즉, 사용자가 출처 https://section.example.com에 특정 권한을 부여한 경우 https://www.example.com와 같은 다른 출처로 이전되지 않습니다.

출처 간에 권한을 공유할 방법이 없으므로, 이 경우 유일한 해결책은 특정 기능 (예: 위치)이 필요한 각 하위 도메인에서 권한을 요청하는 것입니다. 웹 푸시와 같은 경우 쿠키를 유지하여 다른 하위 도메인에서 사용자가 권한을 수락했는지 추적하여 다시 요청하지 않도록 할 수 있습니다.

설치

PWA를 설치하려면 각 출처에 자체와 관련된 start_url가 있는 자체 매니페스트가 있어야 합니다. 즉, 특정 출처 (예: https://section.example.com)에서 설치 메시지를 받은 사용자는 다른 출처 (예: https://www.example.com)에서 start_url를 사용하여 PWA를 설치할 수 없습니다. 즉, 하위 도메인에서 설치 메시지를 받은 사용자는 앱의 기본 URL이 아닌 하위 페이지의 PWA만 설치할 수 있습니다.

또한 각 하위 도메인이 설치 기준을 충족하고 사용자에게 PWA를 설치하라는 메시지를 표시하는 경우 사이트를 탐색할 때 동일한 사용자에게 여러 설치 메시지가 표시될 수 있다는 문제도 있습니다.

이 문제를 완화하려면 기본 출처에만 메시지가 표시되도록 하면 됩니다. 사용자가 설치 기준을 충족하는 하위 도메인을 방문하는 경우:

beforeinstallprompt 이벤트 수신 대기.
event.preventDefault()를 호출하여 메시지가 표시되지 않도록 합니다.

이렇게 하면 사이트의 의도하지 않은 부분에 메시지가 표시되지 않도록 하면서 기본 출처 (예: 홈페이지)에는 계속 표시할 수 있습니다.

독립형 모드

독립형 창에서 탐색하는 동안 사용자가 PWA의 매니페스트에서 설정한 범위를 벗어나면 브라우저가 다르게 작동합니다. 동작은 각 브라우저 버전 및 공급업체에 따라 다릅니다. 예를 들어 최신 Chrome 버전에서는 사용자가 독립형 모드에서 범위를 벗어나면 Chrome 맞춤 탭이 열립니다.

대부분의 경우 이 문제에 대한 해결 방법은 없지만 하위 도메인에서 호스팅되는 환경의 일부 (예: 로그인 워크플로)에 해결 방법을 적용할 수 있습니다.

새 URL인 https://login.example.com는 전체 화면 iframe 내에서 열릴 수 있습니다.
iframe 내에서 작업 (예: 로그인 프로세스)이 완료되면 postMessage()를 사용하여 iframe의 결과 정보를 상위 페이지로 다시 전달할 수 있습니다.
마지막 단계로, 기본 페이지에서 메시지를 수신하면 리스너를 등록 해제하고 iframe을 DOM에서 삭제할 수 있습니다.

결론

동일 출처 정책은 일관된 PWA 환경을 구현하려는 여러 출처를 기반으로 구축된 사이트에 많은 제한을 적용합니다. 따라서 사용자에게 최상의 환경을 제공하려면 사이트를 여러 출처로 나누지 않는 것이 좋습니다.

이미 이러한 방식으로 빌드된 기존 사이트의 경우 다중 출처 PWA가 올바르게 작동하도록 하는 것이 어려울 수 있지만 몇 가지 잠재적인 해결 방법을 살펴보았습니다. 각각 장단점이 있으므로 웹사이트에 어떤 접근 방식을 취할지 결정할 때는 신중하게 판단하세요.

장기 전략 또는 사이트 재설계를 평가할 때 다중 출처 아키텍처를 유지해야 하는 중요한 이유가 없다면 단일 출처로 이전하는 것을 고려하세요.

기술 검토와 제안을 제공해 주신 페니 맥라클란, 폴 코벨, 도미닉 응, 알베르토 메디나, 피트 르페이지, 조 메들리, 체니 차이, 마틴 쉬얼레, 안드레 반다라에게 감사의 말씀을 전합니다.