동일한 도메인 이름을 활용하여 여러 PWA 빌드 방법을 알아보고 사용자에게 동일한 조직 또는 서비스에 속해 있음을 알립니다.
멀티 출처 사이트의 프로그레시브 웹 앱 블로그 게시물에서 데미안은 여러 출처를 기반으로 빌드된 사이트가 모든 사용자를 포괄하는 단일 프로그레시브 웹 앱을 빌드하려고 할 때 직면하는 문제를 설명했습니다.
이 유형의 사이트 아키텍처의 예는 다음과 같은 전자상거래 사이트입니다.
- 홈페이지는
https://www.example.com입니다. - 카테고리 페이지는
https://category.example.com에서 호스팅됩니다. https://product.example.com의 제품 세부정보 페이지
이 도움말에서 설명한 대로 동일 출처 정책은 여러 제한사항을 적용하여 출처 간에 서비스 워커, 캐시, 권한을 공유하지 못하도록 합니다. 따라서 이러한 유형의 구성을 피하는 것이 좋으며, 이미 이러한 방식으로 사이트가 빌드된 경우 가급적 단일 출처 사이트 아키텍처로 이전하는 것이 좋습니다.
이 게시물에서는 그 반대의 경우를 살펴봅니다. 여러 출처에 단일 PWA가 있는 대신 동일한 도메인 이름을 활용하여 여러 PWA를 제공하고 사용자에게 이러한 PWA가 동일한 조직 또는 서비스에 속한다는 사실을 알리고자 하는 회사의 사례를 분석합니다.
아시다시피 Google에서는 도메인과 출처와 같이 서로 다른 용어를 사용하지만 서로 관련이 있습니다. 다음으로 넘어가기 전에 이러한 개념을 복습해 보겠습니다.
기술 용어
- 도메인: DNS(도메인 이름 시스템)에 정의된 라벨의 순서입니다.
예를 들어
com와example.com는 도메인입니다. - 호스트 이름: 하나 이상의 IP 주소로 확인되는 DNS 항목입니다. 예를 들어
www.example.com는 호스트 이름이고example.com는 IP 주소가 있으면 호스트 이름일 수 있으며com는 IP 주소로 확인되지 않으므로 호스트 이름이 될 수 없습니다. - 출처: 스키마, 호스트 이름, 포트(선택사항)의 조합입니다. 예를 들어
https://www.example.com:443은 출처입니다.
이름에서 알 수 있듯이 동일 출처 정책은 출처에 제한을 적용하므로 이 문서에서는 이 용어를 대부분 사용합니다. 하지만 다양한 '출처'를 만들기 위해 사용되는 기법을 설명하기 위해 때때로 '도메인' 또는 '하위 도메인'을 사용합니다.
관련된 여러 PWA의 경우
독립적인 앱을 빌드하되 동일한 조직 또는 '브랜드'에 속한다고 식별하려는 경우가 있습니다. 동일한 도메인 이름을 재사용하는 것이 이러한 관계를 설정하는 좋은 방법입니다. 예를 들면 다음과 같습니다.
- 전자상거래 사이트에서 판매자가 인벤토리를 관리할 수 있는 독립형 환경을 만들고 싶어 하지만, 인벤토리가 사용자가 제품을 구매하는 기본 웹사이트에 속한다는 점을 판매자가 인지하도록 해야 합니다.
- 스포츠 뉴스 사이트에서 주요 스포츠 이벤트를 위한 특정 앱을 빌드하여 사용자가 알림을 통해 좋아하는 경기의 통계를 수신하고 프로그레시브 웹 앱으로 설치할 수 있도록 하면서 사용자가 뉴스 회사에서 만든 앱으로 인식하도록 하려고 합니다.
- 회사에서 별도의 채팅, 메일, 캘린더 앱을 빌드하고 회사 이름에 연결된 개별 앱으로 작동하려고 합니다.
별도의 출처 사용
이러한 경우 권장되는 접근 방식은 개념적으로 구별되는 각 앱이 자체 출처에 있는 것입니다.
모든 사이트 내에서 동일한 도메인 이름을 사용하려면 하위 도메인을 사용하면 됩니다. 예를 들어 여러 인터넷 앱 또는 서비스를 제공하는 회사는 https://mail.example.com에서 메일 앱을 호스팅하고 https://calendar.example.com에서 캘린더 앱을 호스팅하면서 https://www.example.com에서 비즈니스의 기본 서비스를 제공할 수 있습니다. 또 다른 예는 사용자가 https://www.example.com에 호스팅된 기본 스포츠 사이트와 별개로 설치하고 사용할 수 있는 https://footballcup.example.com의 축구 챔피언십과 같은 중요한 스포츠 이벤트에 전적으로 전념하는 독립형 앱을 만들려는 스포츠 사이트입니다. 이 접근 방식은 고객이 회사의 브랜드로 자체 독립 앱을 만들 수 있는 플랫폼에도 유용할 수 있습니다.
예를 들어 판매자가 https://merchant1.example.com, https://merchant2.example.com 등에서 자체 PWA를 만들 수 있는 앱이 여기에 해당합니다.
서로 다른 출처를 사용하면 앱 간의 격리가 보장됩니다. 즉, 각 앱은 다음과 같은 여러 브라우저 기능을 독립적으로 관리할 수 있습니다.
- 설치 가능성: 각 앱에는 자체 매니페스트가 있으며 자체 설치 가능한 환경을 제공합니다.
- 저장용량: 각 앱에는 자체 캐시, 로컬 저장소, 기본적으로 모든 형태의 기기 로컬 저장소가 있으며, 이를 다른 앱과 공유하지 않습니다.
- Service Workers: 각 앱에는 등록된 범위에 대한 자체 서비스 워커가 있습니다.
- 권한: 권한도 출처별로 범위가 지정됩니다. 이를 통해 사용자는 어떤 서비스에 권한을 부여하는지 정확하게 알 수 있으며 알림과 같은 기능이 각 앱에 적절하게 기여합니다.
이러한 수준의 격리를 만드는 것은 여러 개의 독립된 PWA 사용 사례에서 가장 바람직하므로 이 접근 방식을 적극 권장합니다.
하위 도메인의 앱이 서로 로컬 데이터를 공유하려는 경우 여전히 쿠키를 통해 로컬 데이터를 공유할 수 있으며, 고급 시나리오에서는 서버를 통해 저장소를 동기화하는 것이 좋습니다.
동일한 출처 사용
두 번째 접근 방식은 동일한 출처에 서로 다른 PWA를 빌드하는 것입니다. 여기에는 다음 시나리오가 포함됩니다.
겹치지 않는 경로
동일한 출처에 호스팅되고 경로가 겹치지 않는 여러 PWA 또는 개념적 '웹 앱' 예를 들면 다음과 같습니다.
https://example.com/app1/https://example.com/app2/
중복/중첩된 경로
동일한 출처에 있는 여러 PWA 중 하나의 범위가 다른 PWA 내에 중첩된 경우:
https://example.com/('외부 앱')https://example.com/app/('내부 앱')
서비스 워커 API 및 매니페스트 형식을 사용하면 경로 수준 범위를 사용하여 위의 두 가지 작업 중 하나를 실행할 수 있습니다. 그러나 두 경우 모두 동일한 출처를 사용하면 여러 문제와 제한사항이 발생합니다. 이는 브라우저가 이를 별개의 '앱'으로 완전히 간주하지 않는다는 사실에서 비롯되므로 이 접근 방식은 권장되지 않습니다.
다음 섹션에서는 이러한 문제를 더 자세히 분석하고 별도의 출처를 사용할 수 없는 경우 취할 수 있는 조치를 살펴봅니다.
동일 출처의 여러 PWA에 대한 과제
다음은 두 동일 출처 접근 방식에 공통적인 몇 가지 실용적인 문제입니다.
- 저장용량: 쿠키, 로컬 저장소, 모든 형태의 기기 로컬 저장소가 앱 간에 공유됩니다. 따라서 사용자가 하나의 앱에 대해 로컬 데이터를 삭제하기로 결정하면 출처의 모든 데이터가 삭제됩니다. 단일 앱에 대해 이를 실행할 방법은 없습니다. Chrome 및 일부 다른 브라우저에서는 앱 중 하나를 제거할 때 사용자에게 로컬 데이터를 삭제하라는 메시지를 적극적으로 표시하며, 이로 인해 출처의 다른 앱의 데이터에도 영향을 미칩니다. 또 다른 문제는 앱이 저장용량 할당량도 공유해야 한다는 점입니다. 즉, 둘 중 하나가 너무 많은 공간을 차지하면 다른 하나에 부정적인 영향을 미칩니다.
- 권한: 브라우저 권한은 출처에 연결됩니다. 즉, 사용자가 한 앱에 권한을 부여하면 해당 출처의 모든 앱에 동시에 적용됩니다. 권한을 여러 번 요청하지 않아도 되므로 좋은 것처럼 보일 수 있지만, 사용자가 한 앱의 권한을 차단하면 다른 앱에서 해당 권한을 요청하거나 기능을 사용할 수 없게 됩니다. 브라우저 권한은 출처당 한 번만 부여하면 되지만 시스템 수준 권한은 여러 앱이 동일한 출처를 가리키는지 여부와 관계없이 앱당 한 번씩 부여해야 합니다.
- 사용자 설정: 설정도 출처별로 설정됩니다. 예를 들어 두 앱의 글꼴 크기가 서로 다른 경우 사용자가 이를 보완하기 위해 한 앱에서만 확대/축소를 조정하려고 하면 다른 앱에도 설정을 적용하지 않으면 할 수 없습니다.
이러한 어려움으로 인해 이러한 접근 방식을 장려하기가 어렵습니다. 하지만 별도의 출처 사용 섹션에서 설명한 것처럼 별도의 출처(예: 하위 도메인)를 사용할 수 없는 경우, 제공된 두 개의 동일 출처 옵션 중에서 겹치지 않는 경로를 사용하는 것이 겹치는/중첩된 경로보다 좋습니다.
앞서 언급한 바와 같이 이 섹션에서 논의하는 문제는 동일 출처 접근 방식 모두에 공통적으로 적용됩니다. 다음 섹션에서는 겹치는/중첩된 경로를 사용하는 것이 가장 권장되지 않는 전략인 이유를 자세히 알아봅니다.
중첩된/중첩된 경로의 추가 문제
겹치는/중첩된 경로 접근 방식(https://example.com/가 외부 앱이고 https://example.com/app/가 내부 앱임)의 추가 문제는 내부 앱의 모든 URL이 실제로 외부 앱과 내부 앱의 일부로 간주된다는 것입니다.
실제로는 다음과 같은 문제가 발생합니다.
- 설치 프로모션: 사용자가 내부 앱을 방문하는 경우(예: 웹브라우저에서) 외부 앱이 이미 사용자 기기에 설치되어 있으면 브라우저에 설치 프로모션 배너가 표시되지 않고 BeforeInstallPrompt 이벤트가 트리거되지 않습니다. 브라우저가 현재 페이지가 이미 설치된 앱에 속하는지 확인한 후 이미 설치된 앱에 속하는지 확인하기 때문입니다. 이 문제의 해결 방법은 '바로가기 만들기' 브라우저 메뉴 옵션을 통해 내부 앱을 수동으로 설치하거나 외부 앱보다 먼저 내부 앱을 설치하는 것입니다.
- 알림 및 배지 API: 외부 앱은 설치되었지만 내부 앱은 설치되지 않은 경우 내부 앱에서 발생한 알림 및 배지가 외부 앱(설치된 앱의 가장 가까운 닫힌 범위)에 잘못 기여됩니다. 이 기능은 사용자의 기기에 두 앱이 모두 설치된 경우 제대로 작동합니다.
- 링크 캡처: 외부 앱이 내부 앱에 속한 URL을 캡처할 수 있습니다. 이는 외부 앱은 설치되었지만 내부 앱은 설치되지 않은 경우에 특히 그렇습니다. 마찬가지로 외부 앱 내에서 내부 앱에 연결되는 링크는 외부 앱의 범위 내에 있는 것으로 간주되므로 내부 앱에 캡처를 연결하지 않습니다. 또한 ChromeOS 및 Android에서 이러한 앱이 신뢰할 수 있는 웹 활동으로 Play 스토어에 추가되면 외부 앱이 모든 링크를 캡처합니다. 내부 앱이 설치되어 있더라도 OS는 여전히 사용자에게 외부 앱에서 열지 않을지 선택할 수 있는 옵션을 제공합니다.
결론
이 도움말에서는 개발자가 동일한 도메인 내에서 서로 관련된 여러 프로그레시브 웹 앱을 빌드할 수 있는 다양한 방법을 살펴봤습니다.
요약하면 다른 출처 (예: 하위 도메인 사용)를 사용하여 독립된 PWA를 호스팅하는 것이 좋습니다. 동일한 출처에 호스팅하면 여러 가지 문제가 발생합니다. 주로 브라우저가 이를 별개의 앱으로 완전히 고려하지 않기 때문입니다.
- 별도의 출처: 권장
- 출처가 같고 경로가 겹치지 않음: 권장하지 않음
- 동일한 출처, 겹치는/중첩된 경로: 적극 권장되지 않음
다른 출처를 사용할 수 없는 경우 겹치지 않는 경로(예: https://example.com/app1/ 및 https://example.com/app2/)를 사용하는 것이 겹치거나 중첩된 경로(예: https://example.com/(외부 앱의 경우) 및 https://example.com/app/(내부 앱의 경우))를 사용하는 것보다 좋습니다.
추가 리소스
기술 검토 및 제안을 제공해 주신 조 미들리, 도미닉 응, 앨런 커터, 다니엘 머피, 페니 맥라클런, 토마스 슈타이너, 다윈 황님께 감사드립니다.