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

이 페이지는 Cloud Translation API를 통해 번역되었습니다.

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

멀티 오리진 사이트에서 프로그레시브 웹 앱을 빌드할 때의 문제점과 해결 방법

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가 올바르게 작동하도록 하는 것이 어려울 수 있지만 몇 가지 잠재적인 해결 방법을 살펴봤습니다. 각 방법에는 장단점이 있으므로 웹사이트에 어떤 접근 방식을 사용할지 신중하게 결정하세요.

장기 전략이나 사이트 디자인 변경을 평가할 때는 멀티 오리진 아키텍처를 유지해야 하는 중요한 이유가 없는 한 단일 오리진으로 이전하는 것이 좋습니다.

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