동일한 도메인에 여러 프로그레시브 웹 앱 구축

동일한 도메인 이름을 활용하여 여러 PWA를 빌드하여 사용자가 동일한 조직 또는 서비스에 속해 있음을 알 수 있도록 하는 방법

Chase Phillips

Demián Renzulli

Matt Giuca

다중 출처 사이트의 프로그레시브 웹 앱 블로그 게시물에서 데미안은 모든 출처를 포함하는 단일 프로그레시브 웹 앱을 빌드하려고 할 때 다중 출처로 빌드된 사이트가 직면하는 문제에 관해 설명했습니다.

이러한 유형의 사이트 아키텍처의 예는 다음과 같은 전자상거래 사이트입니다.

• 홈페이지는 https://www.example.com에 있습니다.
• 카테고리 페이지는 https://category.example.com에서 호스팅됩니다.
• https://product.example.com의 제품 세부정보 페이지

이 도움말에서 설명한 것처럼 동일 출처 정책은 여러 제한사항을 적용하여 출처 간에 서비스 워커, 캐시, 권한을 공유하지 못하도록 합니다. 따라서 이러한 유형의 구성을 피하고 이미 이러한 방식으로 사이트를 구축한 경우 가능한 한 단일 출처 사이트 아키텍처로 이전하는 것이 좋습니다.

이 게시물에서는 반대의 경우를 살펴봅니다. 서로 다른 출처에서 단일 PWA를 사용하는 대신 동일한 도메인 이름을 활용하여 여러 PWA를 제공하고 이러한 PWA가 동일한 조직 또는 서비스에 속한다는 사실을 사용자에게 알리려는 회사의 사례를 분석합니다.

도메인, 출처와 같이 서로 관련이 있지만 다른 용어를 사용하고 있습니다. 계속하기 전에 이러한 개념을 검토해 보겠습니다.

기술 용어

• 도메인: 도메인 이름 시스템 (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를 만들 수 있는 앱

다른 출처를 사용하면 앱 간에 격리가 보장됩니다. 즉, 각 앱이 다음을 비롯한 다양한 브라우저 기능을 독립적으로 관리할 수 있습니다.

• 설치 가능성: 각 앱에는 자체 매니페스트가 있으며 자체 설치 가능 환경을 제공합니다.
• 저장소: 각 앱에는 자체 캐시, 로컬 저장소, 기본적으로 모든 형태의 기기 로컬 저장소가 있으며 다른 앱과 공유하지 않습니다.
• 서비스 워커: 각 앱에는 등록된 범위에 대한 자체 서비스 워커가 있습니다.
• 권한: 권한도 출처별로 범위가 지정됩니다. 이를 통해 사용자는 권한을 부여하는 서비스를 정확히 알 수 있으며 알림과 같은 기능이 각 앱에 적절하게 표시됩니다.

이러한 수준의 격리를 만드는 것이 여러 독립 PWA 사용 사례에서 가장 바람직하므로 이 방법을 적극 권장합니다.

하위 도메인의 앱이 서로 로컬 데이터를 공유하려면 쿠키를 통해 공유할 수 있으며, 고급 시나리오의 경우 서버를 통해 스토리지를 동기화하는 것을 고려할 수 있습니다.

동일한 출처 사용

두 번째 접근 방식은 동일한 출처에 서로 다른 PWA를 빌드하는 것입니다. 여기에는 다음 시나리오가 포함됩니다.

겹치지 않는 경로

동일한 출처에 호스팅되고 경로가 중복되지 않는 여러 PWA 또는 개념적 '웹 앱' 예를 들면 다음과 같습니다.

• https://example.com/app1/
• https://example.com/app2/

중복/중첩된 경로

동일한 출처에 있는 여러 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/)를 사용하는 것보다 훨씬 좋습니다.

추가 리소스

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

기술 검토와 제안을 제공해 주신 조 메들리, 도미닉 응, 앨런 커터, 다니엘 머피, 페니 맥라클란, 토마스 스타이너, 다윈 후앙께 감사드립니다.

사진: 팀 모숄더(Unsplash 제공)