Declarative Web Push 자세히 알아보기

저는 Brady Eidson입니다 WebKit Architecture팀의 엔지니어죠 웹 푸시 알림의 이번 개선 사항을 소개할 생각에 정말 기대됩니다

푸시 알림은 최신 웹 환경에서 필요한 부분일 뿐 아니라 다른 최신 플랫폼에서도 중요한 역할을 하죠

저희는 푸시 알림을 2009년에 iPhone OS 3으로 Apple 플랫폼에 구축하기 시작했죠 저희가 선구자이긴 했지만 푸시 알림은 모든 최신 플랫폼에 필요한 기능이었죠 곧 macOS를 비롯해 다른 데스크톱 플랫폼과 모바일 플랫폼에도 추가됐습니다 거의 하룻밤만에 푸시 알림 기능이 플랫폼에 기본적으로 들어가게 된 거죠

초기에는 네이티브 앱에서 푸시 작동 방식을 계속 조정해 개발자와 사용자 모두에게 완벽한 지점을 찾으려 했죠 웹에 푸시가 꼭 필요하단 걸 처음부터 알고 있었기에 세부 사항까지 신중히 검토했습니다 저희는 Safari 7에 Safari 푸시 알림을 추가했습니다 개발자들은 Safari 푸시를 적극 도입했고 사용자 반응도 좋았죠 좋은 신호였습니다 Safari 푸시는 Apple 시스템과 긴밀히 통합돼야 해서 다른 브라우저에 구현 가능하도록 표준화할 수는 없었습니다 물론, 모든 브라우저엔 푸시 알림이 필요했죠 웹 표준 커뮤니티는 웹 푸시 알림 작업에 바빴습니다 푸시를 지원하는 첫 브라우저는 1~2년 후에야 출시됐죠

그때는 웹 표준 분야가 JavaScript 기능에 집중하던 때였습니다 원래의 웹 푸시는 매우 유연한 시스템으로 설계됐죠 100% 직접 작성한 JavaScript 코드로 제어됐습니다 저희는 JavaScript 실행 시 가능한 모든 성능을 끌어내려 최선을 다하지만 소프트웨어 개발자라면 모두 알듯 직접 작성해 유지 보수하는 코드는 언제든 오류가 생길 수 있죠

최고의 효율성을 자랑하는 JavaScript 엔진에서 실행돼도 코드를 실행하는 행위는 언제나 비효율적입니다

이 방식의 또 다른 단점은 개인정보 보호입니다 웹사이트 데이터는 사용자의 탐색을 추적할 수 있어 Intelligent Tracking Prevention은 기존 웹 푸시가 필요로 하던 JavaScript 유효 기간을 제한합니다

iOS, macOS 및 Safari 푸시 알림에는 푸시 메시지 자체에 사용자가 보는 알림에 대한 표준화된 설명이 포함됩니다 알림을 표시하기 위해 특정 코드를 개발하거나 실행할 필요가 없죠

네이티브 앱은 코드 없이도 기기에서 푸시 알림을 표시할 수 있습니다 iOS에서 오프로드된 앱도 알림이 잘 표시됩니다

브라우저에 원본 웹 푸시를 추가하는 과정에서 저희는 흥미로운 것을 발견했습니다 표준이 유연성을 제공하는데도 많은 웹사이트가 간단히 파싱할 수 있는 JSON으로 푸시 메시지를 보낸다는 거였죠 Service Worker JavaScript도 알림을 표시하는 API 호출로 변환하는 역할만 수행했습니다 저희가 iOS, macOS, Safari 푸시 알림을 다룬 역사를 생각하면 당연한 일입니다 저희는 꽤나 직관적인 아이디어를 얻을 수 있었죠 알림을 JSON으로 미리 선언하는 방식이 일반적이라면 사용 패턴에 맞게 웹 푸시를 발전시키면 됩니다

코드를 작성해야 하는 단계를 제거하면 네이티브 앱이 누린 모든 혜택을 똑같이 누릴 수 있게 되는 거죠

선언적 웹 푸시는 사용 편의성과 효율성, 투명성을 갖췄습니다 표준화된 형식으로 푸시 메시지를 보내듯이 간단히 사용할 수 있죠 설정 시에 코드도 거의 필요 없습니다

저희는 오픈 웹을 염두에 두고 설계했습니다 표준 커뮤니티와도 협력해서 만들었죠 아직 이런 기능을 제공하지 않는 브라우저와도 호환되도록 설계됐습니다 선언적 웹 푸시는 기존 구조를 유지하며 웹에 기능을 더합니다 이미 기존 웹 푸시에 익숙하다면 그 개념을 그대로 적용할 수 있습니다

확립된 표준을 기반으로 구축되므로 기존 웹 푸시의 일부를 다시 보면서 선언적 웹 푸시의 새로운 기능을 함께 살펴보겠습니다 기존 웹 푸시의 전체적인 개요부터 시작하죠

기존 웹 푸시는 설치된 Service Worker의 형태로 거의 JavaScript에 의존합니다 Service Worker에는 ‘푸시’ 이벤트 처리 코드가 포함돼 알림을 표시합니다

그리고 푸시 구독이 필요하죠 서버가 사용자 브라우저에 도달하기 위해 필요한 푸시 메시지용 URL 등의 필수 정보가 들어갑니다 JavaScript가 사용자 제스처에 따라서 푸시 구독을 요청하고 나중에 사용하기 위해 서버로 보냅니다

알림을 보낼 때는 구독의 URL을 사용해 푸시 메시지를 보내죠 WebKit 브라우저에서도 네이티브 앱을 구동하는 동일한 Apple Push Notification Service로 보내게 됩니다 Apple Developer 계정이 없어도 구독을 사용할 수 있습니다

메시지가 브라우저에 도착하면 브라우저는 메시지를 처리할 Service Worker를 찾아 실행합니다 브라우저가 푸시 이벤트를 Service Worker에 전송하는데 여기에는 푸시 메시지로 보낸 모든 데이터가 포함됩니다

Service Worker는 메시지를 파싱하고 showNotification API에 JavaScript 호출을 구성해 알림을 표시합니다

이후 사용자가 알림을 탭하거나 클릭했을 때 Service Worker가 실행 중이 아니라면 브라우저는 다시 실행하고 notificationclick 이벤트를 전달합니다 이제 핸들러가 쓸모 있는 일을 할 차례입니다 대개는 URL을 통해 창을 여는 일이죠

기존 웹 푸시의 작동 방식도 같습니다 설명된 대부분의 단계는 JavaScript로 처리됩니다 직접 써야 하고 브라우저가 실행해야 하죠

선언적 웹 푸시가 JavaScript를 완전히 제거하지는 않지만 비슷한 수준까지는 갈 수 있죠 선언적 웹 푸시에서는 JavaScript가 푸시 구독을 생성할 때만 필요하며 Service Worker도 필요 없습니다

선언적 푸시 메시지를 보내면 브라우저는 이전처럼 수신하고 파싱하여 유효한 JSON을 찾습니다

JSON이 사용자에게 보이는 유효 알림을 설명하는지 확인하고 확인된 알림을 자동으로 표시합니다

또한 브라우저는 알림을 탭하거나 클릭했을 때 자동으로 처리하는 방법도 알죠 브라우저가 동작을 결정하는 방법도 곧 살펴볼 테지만 우선 푸시 구독을 얻는데 필요한 JavaScript로 돌아가 보겠습니다 기존 웹 푸시에서는 코드가 어떻게 보였는지 그리고 선언적 웹 푸시를 사용하는 지금은 어떻게 보이는지 살펴보죠

기존 웹 푸시를 사용한 적 있다면 익숙하실 겁니다

아까 언급했듯, 기존 웹 푸시는 설치된 Service Worker가 있어야 진행이 가능합니다 Service Worker를 등록하고 나면 사용자의 제스처에 반응해 PushManager 객체에 접근하여 푸시를 구독을 요청할 수 있습니다

선언적 웹 푸시로 푸시 구독을 받기 위한 코드는 이전과 거의 동일하지만 Service Workers가 필요하지 않기 때문에 윈도우 객체에서도 PushManager를 사용할 수 있죠

놀라운 점을 알려 드릴게요 순수한 선언적 웹 푸시 사용 시 작성해야 할 코드는 이것 뿐입니다 선언적 웹 푸시는 푸시 메시지용 표준 JSON 형식을 정의합니다 이건 최소한의 유효 메시지 예시로 저희 팀의 핵심 인프라 도구인 Browser Pets 웹 앱에서 사용하죠

여기엔 표시되는 알림을 설명하는 필수 항목이 포함됩니다

해당 알림에는 사용자가 알림을 탭하거나 클릭하여 이동하기 위한 제목 텍스트와 URL이 포함됩니다

하지만 이 최상단 항목은 선언적 푸시 메시지를 위한 특별한 값이죠 웹 푸시 키는 항상 값으로 8-0-3-0을 가져야 합니다

8030은 웹 푸시 메시지에 대한 Internet Engineering Task Force RFC의 표준 번호로 누군가 우연히 포함할 확률은 매우 희박한 번호라고 판단했죠

앞서 선언적 푸시 메시지가 브라우저를 통해 처리되는 방법을 알아봤는데요

식별용 키를 찾는 것도 여기에 포함됩니다

브라우저가 푸시 메시지에서 JSON을 파싱하려다 실패하면 어떻게 될까요? 그런 경우엔 기존의 웹 푸시로 돌아가 Service Worker로 메시지를 처리하죠

JSON에 식별용 키가 없는 경우에도 기존 웹 푸시로 돌아갑니다

푸시 메시지에 JSON이 포함되고 식별용 키도 있지만 유효 알림을 설명하지 않는다면 어떻게 될까요?

그런 경우, 브라우저는 아무것도 하지 않고 메시지를 바닥에 떨어뜨립니다 푸시 메시지가 모든 조건을 충족하는 경우에는 브라우저가 자동으로 알림을 전송합니다

알림 제목과 탐색 URL은 유효 알림을 위한 최소한의 요구사항입니다 기존 웹 푸시를 사용한 경험이 있다면 JavaScript의 생성 옵션이 더 많다는 걸 알고 있을 겁니다 선언적 웹 푸시는 이 모든 것을 지원합니다

여기서 메시지의 본문과 알림 태그를 지정하고 가능하다면 플랫폼에서 기본 알림음을 재생하도록 요청합니다 이건 전부 예시일 뿐이며 W3C 표준의 NotificationOptions 사전의 지원 항목은 모두 사용 가능합니다

아직 끝이 아닙니다 안 읽은 메시지 수 등의 애플리케이션 배지는 일반적으로 알림과 함께 나타나기 때문에 선언적 푸시 메시지는 앱 배지의 기본 업데이트도 지원합니다

브라우저가 이렇게 많은 알림을 자동으로 표시할 수 있단 건 아주 신선한 변화입니다 하지만 더 구체적인 요청을 처리하는 경우에는 브라우저에만 의지할 수는 없죠

iOS와 macOS의 네이티브 푸시를 통해 배운 교훈으로 UserNotifications 프레임워크를 사용하는 앱에는 한동안 이런 기능이 포함되었습니다 푸시 메시지는 항상 눈에 보이는 알림을 설명하지만 조금 다듬으면 앱에서 더 유용하게 사용할 수 있죠

이것도 선언적 웹 푸시가 지원하는 항목입니다 Service Worker의 선택적 처리 형태로 지원하죠 이게 왜 중요할까요? 알림 정확도에 대해 아주 높은 기준을 가지고 있을 때 매우 유용하기 때문입니다 예를 들어, Browser Pets Server는 사용자에게 읽지 않은 메시지가 7개 있다는 알림을 보낼 수 있죠 그 중 3개를 이미 읽었다는 걸 모른 채로요 클라이언트 기기의 JavaScript는 알림을 업데이트해 사용자를 돕죠

가끔 수학적으로 알림 텍스트를 포함하지 못하기도 합니다 Browser Pets 사용자는 최고 수준의 종단간 암호화를 기대하며 개인 메시지를 서로 주고받는데, 클라이언트 기기의 키가 있어야 알림을 디코딩할 수 있습니다 어떤 모습인지 보겠습니다 일반적인 Browser Pets의 개인 메시지 알림에 사용되는 JSON의 모습입니다

JSON에는 보낸 사람의 기기에서 암호화된 데이터가 포함되죠 사용자 기기의 키를 통해 해당 데이터 복호화가 가능한데 선택적으로 Service Worker를 사용하면 됩니다

JSON에는 ’mutable’이 true임을 지정하는 항목도 포함됩니다 대부분의 선언적 푸시 메시지는 자동으로 처리되죠 하지만 이 항목은 특정 알림이 Service Worker를 통해 처리돼야 한다고 브라우저에 알려 줍니다

Browser Pets이 개인 메시지 복호화에 쓰는 JavaScript입니다

저희는 Service Worker에 푸시 이벤트 핸들러를 등록했는데 기존 웹 푸시에서 필수적이었던 작업과 동일합니다

새롭게 추가된 기능은 브라우저가 이벤트를 전송할 때 푸시 메시지가 수정 가능하게 설정됐다면, 선언적 JSON이 정의한 알림의 사본을 포함합니다

알림을 확인해서 개인 메시지인지 식별하고 암호화된 데이터에 접근하는 방법을 알아봅니다

선언적 웹 푸시의 플로 차트 기억하세요? 알림 설명을 검증한 후에 브라우저는 ’변경 가능’ 항목을 찾습니다

항목이 없거나 false면 브라우저는 자동으로 알림을 표시합니다

항목이 true이고 Service Worker가 대체 알림을 표시한다면 브라우저는 일반 텍스트 대신 대체 텍스트를 사용해 푸시 메시지를 보냅니다

만약 Service Worker가 개인 메시지를 무사히 복호화하고 제안된 알림을 대체했다면 브라우저는 복호화 된 해당 메시지를 표시할 겁니다

하지만 복호화에 실패하면 대체 텍스트를 제공할 수 없어 기존의 일반 텍스트 알림이 대신 사용됩니다

선언적 알림은 다음과 같은 경우에도 사용됩니다 개인정보 보호 기능이 Service Worker를 삭제해서 실행할 수 없는 경우나 기기의 리소스가 부족한 경우가 해당되죠 선언적 웹 푸시가 선택적 Service Worker JavaScript를 사용하는 방법은 기존 웹 푸시와 동일합니다 이제 제가 가장 좋아하는 부분으로 이어지는데요 하위 호환성을 살펴볼 차례입니다

대부분의 주요 브라우저 엔진이 현재 기존의 웹 푸시를 지원해 이미 많은 웹사이트가 이를 사용 중입니다 하지만 선언적 웹 푸시를 널리 도입하면 더 나은 경험을 제공하죠 모든 브라우저에서 기존 알림이 정상 작동하게 유지하면서도 도입하기 쉽도록 만들었습니다 기존 웹 푸시를 사용하고 간단한 JSON 파싱으로 알림을 표시하던 많은 개발자의 푸시 메시지 형태는 구현하려는 기능이 커지고 복잡해지며 조금씩 발전해 왔을 겁니다 Browser Pets가 수년에 걸쳐 발전된 방식과 마찬가지로요 WebKit 팀이 선언적 웹 푸시를 구현한 이후 Browser Pets가 이 기능을 활용해 가장 효율적이고 정확한 알림을 구현하도록 돕고자 했죠 물론 푸시는 모든 브라우저에서 작동해야 합니다 저희가 푸시를 업데이트한 방식을 살펴볼까요

Browser Pets 알림용 JSON은 시간이 지나며 자연스레 성장했죠

처음에는 그냥 제목 텍스트를 알림에 포함했습니다

기존에는 알림을 클릭하면 항상 메인 Browser Pets 앱이 열렸죠 저희는 여기에 clickURL 항목을 추가해 알림 클릭 시 이동할 위치를 설정했습니다

그리고 몇몇 엔지니어가 알림 본문 텍스트가 중요하다는 걸 알아냈죠

다음 내용은 제 아이디어였으니 제가 책임을 지겠습니다 가능하다면 알림이 시스템 알림 소리를 재생하게 했습니다

다음 엔지니어는 저희가 사실상 웹 표준인 NotificationOptions 사전으로 알림을 구성한다는 점을 인지하고 해당 내용을 명시적으로 코드에 넣기로 결정했죠 물론 돌아가서 이전 옵션을 업데이트한 건 아닙니다

임시 JSON 형식이지만 이름과 구조만 다를 뿐 showNotification API 호출을 구성하는 모든 요소를 담고 있죠

선언적 표준 형식에 맞게 재구성하는 건 간단했습니다

NotificationOptions 사전에서 찾은 표준 이름으로 각 속성의 이름을 바꾸는 것 역시 간단했죠

브라우저에 식별용 키를 추가해서 선언적 푸시 메시지임을 알린 후엔 이를 지원하는 최신 브라우저에서 자동 알림이 제공됩니다

임시 JSON으로 돌아가 보죠 기존 웹 푸시에서 푸시 메시지는 그저 일부분에 불과했습니다 Service Worker가 처리해야 했죠 기존 Browser Pets Service Worker는 이렇습니다 JSON에 넣은 각 인자는 이름으로 추출해야 했고 결국 NotificationOptions 사전을 구성하여 showNotification을 호출해야 했습니다

이제 선언적 푸시 메시지가 어떻게 생겼는지 떠올려 보세요

설계상, 알림을 설명하는 선언적 메시지의 핵심 항목은 그 자체로 유효한 NotificationOptions 사전입니다 저희가 푸시 메시지를 유효한 선언적 JSON으로 재포맷하면 매우 직관적으로 서비스 워커를 다시 작성해 처리할 수 있죠

JSON에서 ’알림’ 항목을 꺼내 제목을 추출한 뒤 showNotification에 그대로 전달합니다

푸시 메시지 JSON, Service Worker 푸시 이벤트 핸들러를 리팩토링하면, 웹 푸시 메시지가 모든 브라우저를 십분 활용하죠

선언적 웹 푸시 지원 브라우저에선 안정적이고 효율적으로 처리됩니다

아직 선언적 웹 푸시를 지원하지 않는 브라우저는 기존 웹 푸시 메시지처럼 JavaScript를 작성해 처리합니다 선언적 웹 푸시가 모두에게 도움이 되기를 바랍니다 Safari 18.5 이상이 설치된 macOS iOS 18.4 및 iPadOS 18.4 이상의 홈 화면에 저장된 웹 앱에서 사용해 보세요

앱에 처음으로 앱 푸시 기능을 도입하려고 한다면 처음부터 선언적 형식을 선택할 수 있습니다 이미 웹 푸시를 사용하고 있다면 지금이 전환하기 가장 좋은 시기죠 기존 Safari 푸시 알림 형식도 선언적이기는 했지만 새로운 방식으로 전환하는 게 훨씬 간편합니다 새로운 방식을 도입하는 과정에서 이 세션 리소스를 항상 참고하고 웹 표준 커뮤니티나 WebKit 프로젝트에 피드백을 남겨 주세요

이 세션을 참고해 저희 브라우저가 전반적인 웹 푸시를 지원하는 자세한 방법을 살펴보고 올해 Safari와 WebKit의 새로운 기능도 더 알아보세요

시청해 주셔서 감사합니다