[PWA] Push Notification 개요

• 오늘부터 천천히 엘리스 3차 프로젝트에 사용한 Web Push API 적용 및 트러블슈팅 대장정 과정에 대해 하나씩 포스팅할 생각이다.
• 간단하게 적용 가능했던 manifest.json 파일 설정 후 홈 화면에 추가하기 기능은 프로젝트 중간에 포스팅했으나, push notification 기능은 2주간 구현한 내용이기도 하고 관련 기능들 하나 하나 순서대로 포스팅하려고 일부러 아껴뒀다(?)고 쓰고 미뤘다고 읽는...
• 어떻게 시작해야 할지 좀 막막해서 간단하게 써 본 목차는 다음과 같다.
• 1. [PWA] Push Notification 개요
  2. [PWA] Push Notification 튜토리얼 따라해보기
  3. [PWA] Push Notification Nodejs 프로젝트에 적용하기
  4. [PWA] Push Notification 상황별 다른 알림 옵션 설정하기
  5. [PWA] Push Notification 알림 자동 발송하기 (feat. node-schedule)
  6. [PWA] Push Notification 안드로이드 QR 코드로 구독하기
  7. [PWA] Push Notification 외전1. query string으로 사용자 인증값 전달하기 (feat. AES 암호화)
  8. [PWA] Push Notification 외전2. chrome에서의 subscription token 만료 문제 (feat. nodemailer)
• 목차와 같이 튜토리얼로 시작해서 프로젝트에서 처음 기획한 기능대로 구현까지 디벨롭 한 과정을 나열할 예정이라 핵심만 찾는 누군가에게 도움되는 글은 아닐 것 같지만 그래도 모든 과정을 기록으로 남겨두고 싶어 작성하는 포스팅이다😋 이거 말고도 SSL 적용 과정, Front에서 작업한 Heatmap, Onboarding 포스팅도 쓰려했는데 아득... 

---

 

 [ 01 사용하게 된 배경 ] 

• 우리팀의 메인 기능은 NLP를 이용해 "사용자가 입력한 증상별 영양제 추천"이고, 서브 기능은 "영양제 복용 시간 및 건강 관리 스케줄러" 기능이다.
• 이 스케줄러 기능에서 영양제 복용 시간을 알려주기 위해 알림 서비스 기능이 필요했고, 내가 아이디어를 내며 처음 제안한 건 사실 카카오 알림톡 서비스였다. 그런데 프로젝트를 시작하고 찾아보면 찾아볼수록... 사업자 번호 없이 개인 혹은 학생이 카카오에서 알림톡 기능을 사용하기는 불가능하다는 것을 깨달았고 포기하기 아쉬운 기능이라 대안을 찾다가 찾다가 찾은게 PWA의 Web Push 기능이었다.
  • 카카오 디벨로퍼 공식문서 다 뒤지고 지푸라기라도 잡는 심정으로 kakao-devtalk에도 문의를 남겼는데 원하는 시간에 원하는 내용으로 원하는 사람에게 톡을 보내는 건 알림톡 혹은 친구톡에서만 가능한 게 맞았다. (둘 다 사업자 번호 필요)
  • 그래서 찾다보니 라인톡에서는 가능한지 대안으로 라인톡을 사용한 과정을 포스팅하신 블로그도 발견했지만 한국에선 주류가 아닌 라인으로 넘어가긴 싫었다...
  • 저런걸 알고 있었다면 바로 대안으로 선택할 수 있었을지 모르지만 나는 이번에 PWA도, Web Push도 처음 들어봐서 Push 알림은 앱만 가능한 줄 알았다가 한 줄기의 빛을 만난 기분이었다✨
• 그런데 외부 API 사용이 다 거기서 거기겠거니 하고 멋지게 뛰어든 Web Push는 정말 만만치 않았다...ㅎㅎ 따라서 2주간 고통받으며 이해한 (심지어 기능 구현하고 나서도 계속 이해중인) 개념부터 정리해보겠다.
• 그리고 나는 수많은 블로그를 보면서도 이해가 되지 않았기에😅 결국 유튜브까지 뒤져 이해가 되는 튜토리얼을 찾아냈다. 오늘은 그 튜토리얼 소개와 실습까지의 내용이다.

 

 [ 02 Web Push란? ] 

 (1) App Push vs Web Push  

• 푸시라고 하면 보통 스마트폰을 통해 알림을 받는 App Push부터 떠오를텐데, Web Push 역시 웹과 안드로이드 환경에서 푸시 알림을 발송해준다. 각각의 정의는 다음과 같다.
  • 앱 푸시(App Push) : 스마트 기기에 설치된 "앱"을 통해 운영자가 제공하는 정보를 수신하는 알림 기능
  • 웹 푸시(Web Push) : 웹사이트 방문자에게 "웹 브라우저"를 통해 푸시 알림을 수신하는 기능
• 둘의 가장 큰 차이는 바로 메시지를 발송/수신하는 채널이 다르다는 것이다.
  • 앱 푸시(App Push)는 사용자의 디바이스에 반드시 앱이 설치되어 있어야 발송할 수 있다. 앱은 안드로이드나 iOS 두 운영체제에서 모두 설치, 사용할 수 있어 운영체제에 따른 제약이 없다.
  • 웹 푸시(Web Push)는 별도의 앱이 필요 없다. 웹 푸시는 크롬이나 Edge, 파이어폭스와 같은 "웹 브라우저"를 활용해 메시지를 발송하기 때문이다. 하지만 현재 애플의 iOS에서는 웹푸시를 허용하고 있지 않기 때문에 iOS를 사용하는 모바일 단말기인 아이폰에서는 웹푸시를 수신할 수 없다. (Mac OS는 가능)
    • 그러나 2022년 6월에 열린 WWDC에서 애플은 iOS 16부터 Safari에 Web Push Notification 기능을 추가한다고 공식 발표했다! 다만 iOS 16을 설치한다고 바로 가능한 것은 아니고 2023년에 가능하게 될 예정이라고 말했다. (참고)
      
    • 개발자들의 반응을 보니 애플이 이걸?!이라는 반응과 드디어!!라는 반응으로 나뉘는 것 같은데, 애플이 이제서야 PWA의 Web Push 기능을 추가하는 이유는.. 그냥 막연하게 또 보안 때문이겠지~했다가 이 영상을 보고 새로운 정보를 알게 됐다. 애플은 매 년 개발자로부터 앱스토어 수수료로 수십억을 받아내고 있는데, PWA의 홈 화면 추가, 웹 푸시 알림 기능 등은 서비스 제공시 앱이 아닌 웹을 선택할 충분한 이유가 되고 따라서 PWA의 가능성을 견제한다고...
      
      다른 블로그에서도 PWA의 미래는 iOS와 안드로이드에서 얼마나 밀어주느냐에 따라 달렸는데, 인앱결제도 못하는 PWA를 밀어줄 것 같진 않다고 하셨다. 그래서 아직 완전히 앱을 대체할 편의성은 아니지만 PWA가 주목받는 기술임은 확실한 것 같다!

출처 : https://uracle.blog/2021/09/24/webpush-2/

 (2) PWA (Progressive Wep App)  

• 이 글에서 간단하게 작성했지만 좀 더 시간을 들여 PWA가 뭔지 공부해보자면... (학습 사이트)
• PWA는 웹과 네이티브 앱의 기능 모두의 이점을 갖도록 수 많은 특정 기술과 표준 패턴을 사용해 개발된 웹 앱이다.
• 따라서 PWA는 하나의 기술로 생성된 것이 아니고, 여러 기능들을 포함해 웹 앱을 구축하는 하나의 새로운 철학을 나타낸다.
• 첫눈에 웹 앱이 PWA인이 아닌지 구분하기는 쉽지 않고, 앱이 특정 요구 사항을 만족하거나 다음의 기능들이 구현되었을 때 PWA라고 볼 수 있다.
  • 오프라인에서 동작
  • 설치가 가능 (홈 화면에 추가)
  • 쉬운 동기화
  • 푸시 알림 등
• 이러한 PWA 앱의 완성도는 개발자도구의 Lighthouse에서 퍼센트로 측정할 수 있으나 대략적인 지표로만 참고한다.

출처 : https://developer.mozilla.org/ko/docs/Web/Progressive_web_apps/Introduction

 (3) Service Worker 

• PWA를 위해 요구되는 핵심 요소는 Service Worker의 지원이다.
• 다행이도 Service Worker는 현재 데스크탑 및 모바일의 모든 주요 브라우저에서 지원된다. (참고)

• 그렇다면  Service Worker 란?
  웹 응용 프로그램, 브라우저, 그리고 (사용 가능한 경우) 네트워크 사이의 프록시 서버 역할을 하며 이벤트 기반 워커로서 JavaScript 파일의 형태를 갖고 있다.
  • 워커 맥락에서 실행되기 때문에 DOM에 접근할 수 없고 앱을 구동하는 주 JavaScript와는 다른 스레드에서 동작하므로 연산을 가로막지 않는다. (논 블로킹)
  • 서비스 워커는 온전히 비동기적으로 설계되어 서비스 워커 내에서는 동기적인 API를 사용할 수 없다.
  • 서비스 워커는 보안 상의 이유로 HTTPS에서만 동작한다. 네트워크 요청을 수정할 수 있다는 점에서 중간자 공격에 굉장히 취약하기 때문이다. 단, 개발 환경인 localhost는 예외로 동작한다.
  • 크롬의 시크릿 모드나 firefox의 사생활 보호 모드에서는 제대로 동작하지 않을 수 있다.
• Service Worker의  생명주기 
  1. 다운로드
     • 서비스 워커가 제어하는(등록된) 사이트/페이지에 사용자가 처음 접근하는 순간 서비스 워커 파일이 즉시 다운로드된다.
     • 다운로드한 파일이 더 새로운 버전인 경우 서비스 워커의 설치를 시도한다. 버전 비교는 기존 서비스 워커 파일과의 바이트 단위 비교 결과를 사용한다. 이 페이지/사이트에서 서비스 워커를 처음 발견한 경우에도 "새로운 버전"으로 취급한다.
  2. 설치
     • 기존 서비스 워커가 없으면 설치를 시도하고, 설치를 성공하면 활성화한다.
     • 기존에 서비스 워커가 존재하던 경우, 새로운 버전을 백그라운드에서 설치하지만 바로 활성화하지 않는다. 이 시점의 워커를 "대기 중인 워커"라고 부르는데 대기 중인 워커는 이전 버전의 서비스 워커를 사용하는 페이지가 모두 닫힌 경우 활성화되어 활성 워커가 된다.
  3. 활성화
     • 이벤트를 듣고 요청에 응답할 수 있는 상태이다.

출처 : https://developer.mozilla.org/ko/docs/Web/API/Service_Worker_API

---

 

• 생각보다 정리가 길어져 튜토리얼 따라하는 내용은 다음 포스팅으로 넘겨야겠다.
• 프로젝트 기간이 짧다보니 구현에 눈이 멀어(?) 일단 냅다 튜토리얼 보고 따라하고 수정해서 적용하는데 끝내고라도 이렇게 이론을 정리하는 시간이 매우 매우 중요한 것 같다.
• 예를 들어 Service Worker 생명주기... 트러블 슈팅하며 Service Worker를 의심했을 때 찾아봤었는데 그 땐 뭔 말인지 몰랐다가 이번에 정리하며 이해가 됐다 🤣