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

푸시 알림 FAQ

Matt Gaunt

브라우저를 닫으면 푸시가 작동하지 않는 이유는 무엇인가요?

이 질문은 상당히 자주 등장합니다. 주로 추론하고 이해하기 어려운 몇 가지 시나리오가 있기 때문입니다.

Android부터 시작해 보겠습니다. Android OS는 푸시 메시지를 수신 대기하도록 설계되었으며, 메시지를 수신하면 앱이 닫혀 있는지와 관계없이 적절한 Android 앱을 깨워 푸시 메시지를 처리합니다.

이는 Android의 모든 브라우저와 정확히 동일합니다. 푸시 메시지가 수신되면 브라우저가 깨어나고 브라우저가 서비스 워커를 깨워 푸시 이벤트를 전달합니다.

데스크톱 OS에서는 더 미묘한 차이가 있으며, Mac OS X에서는 다양한 시나리오를 설명하는 데 도움이 되는 시각적 표시기가 있으므로 가장 쉽게 설명할 수 있습니다.

Mac OS X에서는 도크의 앱 아이콘 아래에 있는 표시를 통해 프로그램이 실행 중인지 여부를 알 수 있습니다.

다음 도크의 두 Chrome 아이콘을 비교해 보면 왼쪽 아이콘은 아이콘 아래의 표시로 알 수 있듯이 실행 중인 반면 오른쪽 Chrome은 실행되지 않으므로 아래에 표시가 없습니다.

데스크톱에서 푸시 메시지를 수신하는 맥락에서 브라우저가 실행 중일 때(즉, 아이콘 아래에 표시가 있을 때) 메시지가 수신됩니다.

즉, 브라우저에 열려 있는 창이 없어도 브라우저가 백그라운드에서 실행되므로 서비스 워커에서 푸시 메시지를 계속 수신할 수 있습니다.

푸시가 수신되지 않는 유일한 경우는 브라우저가 완전히 닫혀 있는 경우, 즉 전혀 실행되지 않는 경우 (마킹 없음)입니다. Windows에서도 마찬가지이지만 Chrome이 백그라운드에서 실행 중인지 확인하는 것은 조금 더 까다롭습니다.

푸시에서 홈 화면 웹 앱이 전체 화면으로 열리도록 하려면 어떻게 해야 하나요?

Android용 Chrome에서는 웹 앱을 홈 화면에 추가할 수 있으며, 웹 앱이 홈 화면에서 열리면 아래와 같이 URL 표시줄 없이 전체 화면 모드로 실행될 수 있습니다.

이 환경을 일관되게 유지하기 위해 개발자는 클릭한 알림이 웹 앱도 전체 화면으로 열기를 원합니다.

Chrome에서는 이를 '어느 정도' 구현했지만 신뢰할 수 없고 추론하기 어려울 수 있습니다. 관련 구현 세부정보는 다음과 같습니다.

즉, 사용자가 홈 화면 아이콘을 통해 사이트를 자주 방문하지 않는 한 알림이 일반 브라우저 UI에서 열립니다.

이 문제는 추가로 작업 중입니다.

웹 소켓보다 이 방법이 더 나은 이유는 무엇인가요?

서비스 워커는 브라우저 창이 닫힐 때 활성화될 수 있습니다. 웹 소켓은 브라우저와 웹페이지가 열려 있는 동안만 유지됩니다.

GCM, FCM, 웹 푸시, Chrome의 관계는 무엇인가요?

이 질문에는 여러 측면이 있으며 가장 쉽게 설명하는 방법은 웹 푸시 및 Chrome의 역사를 살펴보는 것입니다. 걱정하지 마세요. 짧은 내용입니다.

2014년 12월

Chrome에서 웹 푸시를 처음 구현할 때는 Google Cloud Messaging (GCM)을 사용하여 서버에서 브라우저로 푸시 메시지를 전송했습니다.

이는 웹 푸시가 아닙니다. 초기 Chrome 및 GCM 설정이 '실제' 웹 푸시가 아니었던 데는 몇 가지 이유가 있습니다.

GCM을 사용하려면 개발자가 Google Developers Console에서 계정을 설정해야 합니다.
Chrome과 GCM은 메시지를 올바르게 설정할 수 있도록 웹 앱에서 공유할 특별한 발신자 ID가 필요했습니다.
GCM 서버가 웹 표준이 아닌 맞춤 API 요청을 수락했습니다.

2016년 7월

7월에 웹 푸시의 새로운 기능인 애플리케이션 서버 키 (또는 사양으로 알려진 VAPID)가 출시되었습니다. Chrome에서 이 새 API에 대한 지원을 추가할 때 메시지 서비스로 GCM 대신 Firebase 클라우드 메시징 (FCM)을 사용했습니다. 이는 다음과 같은 몇 가지 이유로 중요합니다.

Chrome 및 애플리케이션 서버 키는 Google 또는 Firebase에서 설정할 때 어떤 종류의 프로젝트도 필요하지 않습니다. 자동으로 작동합니다.
FCM은 모든 웹 푸시 서비스에서 지원하는 API인 웹 푸시 프로토콜을 지원합니다. 즉, 브라우저에서 사용하는 푸시 서비스에 관계없이 동일한 종류의 요청을 하면 메시지가 전송됩니다.

오늘은 왜 혼란스러운가요?

웹 푸시 주제에 관한 콘텐츠가 작성되면서 많은 혼란이 발생하고 있으며, 그중 상당수가 GCM 또는 FCM을 언급합니다. 콘텐츠에서 GCM을 참조하는 경우 이는 오래된 콘텐츠이거나 Chrome에 너무 집중하고 있다는 신호로 간주해야 합니다. (저도 이전 게시물에서 이 짓을 한 적이 있습니다.)

대신 웹 푸시는 푸시 서비스를 사용하여 메시지 전송 및 수신을 관리하는 브라우저로 구성되어 있다고 생각하면 됩니다. 여기서 푸시 서비스는 '웹 푸시 프로토콜' 요청을 수락합니다. 이러한 관점에서 생각하면 어떤 브라우저와 푸시 서비스를 사용하는지 무시하고 바로 작업을 시작할 수 있습니다.

이 가이드는 웹 푸시의 표준 접근 방식에 중점을 두고 작성되었으며 다른 모든 것은 의도적으로 무시합니다.

Firebase에는 JavaScript SDK가 있습니다. 무엇을, 왜

Firebase 웹 SDK를 발견하고 JavaScript용 메시지 API가 있는 것을 확인한 경우 웹 푸시와 어떻게 다른지 궁금할 수 있습니다.

메시지 SDK (Firebase 클라우드 메시징 JS SDK라고 함)는 웹 푸시를 더 쉽게 구현할 수 있도록 백그라운드에서 몇 가지 트릭을 실행합니다.

PushSubscription 및 다양한 필드에 관해 걱정할 필요 없이 FCM 토큰 (문자열)에만 신경을 쓰면 됩니다.
각 사용자의 토큰을 사용하여 독점 FCM API를 통해 푸시 메시지를 트리거할 수 있습니다. 이 API는 페이로드를 암호화할 필요가 없습니다. POST 요청 본문에서 일반 텍스트 페이로드를 전송할 수 있습니다.
FCM의 독점 API는 FCM 주제와 같은 맞춤 기능을 지원합니다(문서가 제대로 작성되어 있지는 않지만 웹에서도 작동함).
마지막으로 FCM은 Android, iOS, 웹을 지원하므로 일부 팀의 경우 기존 프로젝트에서 더 쉽게 작업할 수 있습니다.

이는 백그라운드에서 웹 푸시를 사용하지만 이를 추상화하는 것이 목표입니다.

이전 질문에서 말씀드렸듯이 웹 푸시를 브라우저와 푸시 서비스로만 간주한다면 Firebase의 Messaging SDK를 웹 푸시 구현을 간소화하는 라이브러리로 간주할 수 있습니다.