Skip to content

ChungUlLim_ProjectBlog

Jump to bottom
sowjd edited this page Nov 5, 2017 · 45 revisions

앱 설치 없이도 PUSH 알림을 받을 수 있다9?!

| 진동벨이 필요 없는 카페 주문 완료 알림 시스템

By 청울림 팀 | 김응준, 권소영, 심소정

목차

  1. 서론 | 청각장애인 분들이 겪는 카페 이용의 어려움
  2. 본론 | 해결의 실마리
    1) PWA란?
    2) PWA를 이용한 카페 주문완료 시스템
    3) 시스템 배경 및 기반 기술
    • AWS EC2 Amazon Linux 인스턴스 생성
    • Node.js Server
    • HTTPS 사용을 위한 Let's encrypt CA 인증서 발급 받기
    • Notification API & Push API
  3. 결론 | 가능성과 한계
    1) 프로젝트 결과
    2) 프로젝트 요약 정리
    3) 기대되는 효과
    4) 한계
    5) 확장가능성

[ 1.서론 | 청각장애인 분들이 겪는 카페 이용의 어려움 ]

청각장애인분들이 카페를 이용할 때 가장 불편했던 점이 무엇일까요?
위의 표를 보아, 청각장애인분들은 카페에서 커피 제조 완료시 직원이 부르는 것을 듣지 못하는 것이 가장 불편하다고 하셨습니다.

그러면 ‘진동벨을 구비하여 사용하면 되지 않느냐!’ 라는 의문이 들텐데요.

하지만 진동벨의 단가는

개당 6~9만원의 비용이든다고 합니다. 깜빡 잊고 진동벨을 들고 가시는 분들도 많으셔서 분실의 우려도 또한 높다고 하는데요.

그리하여 먼저 ‘진동벨을 대체하여 무엇을 지금은 사용하고 있는가?’하고 조사를 해 보았습니다.

첫번째로 한 대형 프랜차이즈 카페 를 예로 들 수 있습니다.

이 프랜차이즈 카페는 해당 카페의 앱을 다운 받아 휴대폰 단말기로 주문 완료 알림을 주는 서비스를 제공하고 있습니다. 휴대폰으로 알림을 받기때문에 진동벨이 필요 없는 좋은 대체 방안으로 보이는데요. 사실 앱 서비스가 진동벨을 대신하기는 어렵습니다. 그 이유는 두 가지가 있습니다.

이유 1. 모든 카페가 앱 서비스를 제공할 수는 없다.
모든 카페가 앱 서비스를 제공 할 수 없다는 것은 소규모의 카페의 경우 각 개인 카페의 앱을 제작하고 관리하기가 쉽지 않기 때문이라는 것입니다. 일반 카페마다 앱을 모두 제작하기에는 많은 어려움이 있겠죠?
이유 2. 모든 손님이 앱을 사용하지는 않는다.
앱을 다운받아야하는 번거로움과 알림서비스의 필요성을 느끼지 못하는 등 여러가지 이유들로 손님들은 앱을 잘 사용하지 않습니다. 실제로 할인이나 포인트적립 등의 혜택을 위해 앱을 다운받아 사용하지만, 그다지 필요성을 느끼지 못하는 손님들은 앱을 설치하지 않습니다. 즉, 모든 손님이 앱을 사용하지 않으며 대형 프랜차이즈 카페도 이 사실을 인지하고 있기 때문에 매장 내에서는 여전히 진동벨을 사용하고 있습니다.

두번째로 문자메시지로 음료 제작 완료를 알려주는 시스템을 예로들 수 있습니다.

일부 카페는 앱이 아닌 전화번호를 이용하여 음료 제조 완료를 알려주는 경우도 있다고 합니다. 하지만 개인 전화번호를 카페측에 알려주어야 한다는 것은, 개인정보 유출 우려도가 높은 요즘 손님들이 달가워하지는 않겠죠?

청각장애인 분들께서 겪고있는 어려움(커피 제조 완료시 직원이 부르는 것을 듣지 못하는 것), 앱 설치의 번거로움, 개인정보유출 등의 문제들로부터 저희팀은 사람들이 가장 많이 지니고 다니는 휴대폰 단말기를 사용하되 앱이 아닌 웹으로 구현하여 서비스를 제공할 수 있도록 개발하기로 했습니다. 조사를 하던 도중 웹으로 휴대폰 단말기로 알림을 줄 수 있는 PWA라는 개념을 발견하고 이를 사용하기로 결정했습니다.

[ 2.본론 | 해결의 실마리 ]

1) PWA(Progressive Web Apps)란?

구글 크롬 엔지니어 알렉스 러셀이 2015년에 고안한 개념으로 앱에 근접해가는 웹으로, 앱 수준과 같은 사용자 경험을 웹에서 제공하는 것을 목적으로 가짐

장점

  • 웹주소만 있으면 누구나 접근하여 사용할 수 있다.
  • 단말기의 저장공간을 많이 차지 않는다.
  • 다양한 플랫폼을 통해서 홍보를 진행할 수 있다.
  • 앱보다 빠른 구동속도를 가진다.
  • 오프라인일 때에도 로딩이 가능하다.

단점

  • 사용자가 한번 접속하게 하기는 쉽지만, 반복해 접속하게하기는 쉽지않다.

PWA를 실현하기 위해 사용되는 기술
Web App Manifest : Native App 접근성 제공
Service Worker : 오프라인 캐싱, 백그라운드 처리
Push Notification : 푸시 알림

모바일 웹이지만 푸시 알림을 보낼 수 있다. <출처: 구글 개발자 블로그>

그래서 저희는 PWA의 ‘서비스 작업자(service worker)’로 불리는 API로 사용자에게 푸시 알림을 보내는 시스템을 구성했습니다.

Service worker란
브라우저에 의해 백그라운드에서 실행되는 스크립트기반의 워커이며, 웹페이지와는 별도의 생명주기를 가지고 동작하는 것입니다.

서비스워커가 별도의 생명주기를 가지고 동작한다고 하는데 이번에는 서비스워커의 생명주기에 대해서 알아보겠습니다.

Service worker의 생명주기

사용자가 웹 페이지에 최초로 접속하면 서비스 워커는 install 이벤트를 시도합니다. install은 서비스 워커 별로 한 번만 호출되며, 해당 서비스워커 스크립트를 수정하면 브라우저는 다른 서비스워커로 간주합니다. install에 실패하면, 다음 웹 페이지 접속 시에 다시 install을 시도합니다. install을 성공하면 서비스워커는 activiated 상태, 즉 활성화가 됩니다. 이 단계에서, 서비스 워커는 fetch나 push 이벤트를 처리할 수 있습니다. 처리할 이벤트가 없는 때에는 idle 상태로 대기합니다.

그럼 서비스 워커는 무슨일을 할까요?
서비스워커의 기능

  • 캐시(cache)와 상호작용
    서비스 워커는 네트워크의 연결이 끊겨도 PWA앱이 작동할수 있게 해줍니다. 데이터를 기기에 캐시로 저장해 놓고 정보를 캐시에서 꺼내오기 때문이죠.
  • 푸시 알림(Push Notification) 보내기
    브라우저가 닫힌 상태에서도 동작하는 특성으로부터 푸시알림을 보낼 수 있습니다.
  • 백그라운드 동기화(Background Sync)
    인터넷 연결이 끊겨 중단된 작업을 인터넷이 연결되면 바로 재개할 수 있습니다.

다음으로는 간단하게 서비스워커를 등록하고 활성화하는 방법에 대해서 살펴보겠습니다.

Service Worker 등록 및 활성화
먼저, 푸시서비스를 사용하기 위해서는 우선 서비스워커를 등록해야합니다.

먼저 웹브라우저가 서비스워커를 지원하는지 판단하고, 지원한다면 /sw.js에 있는 서비스워커 등록하는 것입니다. 서비스 워커 파일의 위치는 도메인의 루트와 동일합니다. 서비스 워커는 현재 경로와 하위 경로에서만 동작하기 때문에, 서비스 워커의 동작 범위가 도메인의 모든 항목에 적용되어야하기 때문이죠.

웹 사이트의 다른 중요한 프로세스의 속도를 늦추지 않기 위해서 웹페이지를 완전히 다운로드한 후 서비스 워커를 등록 하는데요. 아래의 코드처럼 window.addEventListener 을 추가해주면 됩니다.

if ('serviceWorker' in navigator) { window.addEventListener('load', function() { navigator.serviceWorker.register('./sw.js'); }); }

2) PWA를 이용한 카페 주문 완료 시스템

시나리오

손님이 카페 점원에게 주문을 한 후 nfc태크에 태깅을 합니다. 웹페이지 접속과 동시에 손님의 단말정보는 서버의 데이터베이스에 저장됩니다. 음료제작이 완료되면 손님의 단말기로 push알림이 보내어집니다.

시스템 구성도

Client 단말기(손님)는 nfc태깅을 통해 웹브라우저에 접속합니다.(1) 웹브라우저는 서버의 웹페이지data를 읽어 Client 단말기의 화면에 나타내 줍니다.(2, 3) 이때 웹브라우저에 서비스 워커가 등록되고(4) 손님이 웹페이지의 푸시알림허용버튼을 클릭하면 구독객체(푸시 메시지를 전송하기 위해 필요한 정보)가 서버의 데이터베이스에 저장됩니다.(5)

Manager 단말기(카페점원)도 (5)까지 Client 단말기와 동일하게 진행됩니다. Manager 단말기에서 Client 단말기에게 push알림을 보내면(6) 노드서버의 web push protocol을 이용하여 Client 단말기로 push알림이 전송됩니다.(7)

3) 시스템 배경 및 기반 기술

앞서 시스템이 어떤 시나리오로 동작하고 각 시스템 구성이 어떻게 연결되어 있는지, 그리고 시스템 구성 사이에 어떤 동작이 이루어지는지에 대해서 살펴보았습니다. 이제 위의 시스템 구성이 무엇을 가지고 만들어졌고, 구성 간 상호작용이 어떤 원리로 동작하는지 좀 더 자세히 알아보겠습니다. 이 설명의 목적은 시스템의 배경과 기반 기술의 전반적인 이해를 돕기 위한 것이므로, 너무 깊이 있는 내용은 생략하겠습니다.

  • AWS EC2 Amazon Linux 인스턴스 생성

웹 서비스를 제공하기 위해서는 당연히 웹 서버가 필요합니다. 기본적으로, 사용자가 서버에 서비스에 대한 어떤 요청(Request)를 하게 되면, 서버는 그에 상응하는 응답(Response)을 해주는 방식으로 동작하는 것이죠. 간단한 예를 들자면, 사용자가 웹 브라우저로 서버에 웹페이지를 요청하면 서버는 해당 웹페이지를 사용자의 웹 브라우저에 띄우게 됩니다.

AWS는 Amazon Web Services의 약어로, 아마존은 과금 방식을 통해 클라우드 서버를 사용할 수 있게 해주는 서비스를 제공하고 있습니다. 서비스 중에, ‘프리티어’라고 해서 1년간 매월 750시간까지 EC2 t2.micro 인스턴스를 사용할 수 있게 해주는 서비스가 있습니다. 여기서 인스턴스란 서버를 말하며 한달 내내 서버를 돌려도 750시간이 되지 않으니, 사실상 무료로 서비스를 이용하게 해주는 것이죠. AWS에 가입만 하면 프리티어의 대상이 됩니다.
EC2 인스턴스를 생성할 때, Ubuntu, Red Hat, Amazon Linux 등의 선택지 중에 하나를 고르게 되는데 저희 시스템에는 Amazon Linux가 사용되었습니다. 인스턴스의 자세한 성능이나 생성 방법에 대해서는 생략하고, 중요하다고 생각되는 ‘보안그룹 설정’과 ‘키 페어’에 대해서만 간략하게 설명하도록 하겠습니다.

보안그룹 설정
먼저 보안 그룹(Security Group)은 간단하게 말해서 네트워크 정책에 따른 보안을 설정해 주는 개념입니다. 어떤 형태의 데이터를, 어느 길을 통해 받아들이고 내보낼 것인지에 대한 설정을 한다고 보시면 됩니다. 위의 사진은 저희 EC2 인스턴스의 보안 그룹 설정 상태입니다. 매 항목을 자세히 설명하기에는 네트워크 관련 지식이 필요하기 때문에 간단한 부분만 설명하도록 하겠습니다. 먼저 ‘소스’ 항목은 어디로부터 오는 데이터를 허용할 것인지를 정합니다. 일종의 IP를 지정해줄 수 있는데, 사진의 형태는 Anywhere을 의미하여 어느 곳에서 오는 데이터인지에 상관 없이 허용할 수 있음을 뜻합니다. ‘포트 범위’는 일종의 문이라고 볼 수 있습니다. 예를 들어, SSH(Secure Shell, 네트워크 보안 도구 중 하나로 원격 접속을 안전하게 할 수 있게 해주는 프로토콜) 유형은 Putty 등의 프로그램을 사용하여 리눅스 계열의 서버를 원격 제어하기 위해 필요한 방식인데, 해당 유형은 22번 포트를 통해서만 접근할 수 있는 것입니다. 이와 유사한 방식으로, 80번 포트와 443번 포트는 해당 인스턴스를 웹 서버로 사용하기 위해서, 22번은 SSH사용을 위해, 27017번은 MongoDB 사용을 위해, 3306번은 MySQL 사용을 위해, 그리고 3000번은 뒤에 설명할 Node.js 서버 사용을 위해 설정한 것입니다.

키 페어
다음으로 키 페어(Key pair)는 Public Key와 Private Key의 쌍을 의미합니다. 이 개념도 깊게 들어가면 키 페어의 암호화 알고리즘 방식이 2048-bit SSH-2 RSA 방식이라는 등의 전문지식이 필요하므로, 일반적인 사용 방법을 EC2에서 사용하는 SSH 인증 방식을 통해 설명하겠습니다. 일단, Public key는 암호화에 사용되며 EC2 서버가 가지고 있다는 점과 Private key는 복호화에 사용되며 사용자(client)가 가지고 있다는 점을 염두해주세요.

  1. Client는 Server에 SSH 접속 요청을 한다.
  2. Server는 임의의 값을 생성하고 Public Key를 사용하여 해당 값을 암호화하여 Client에게 보낸다.
  3. Client는 서버로부터 받은 값을 Private Key로 복호화 해서 다시 Server로 보낸다.
  4. Server는 Client로부터 받은 값과 처음의 임의의 값과 비교해서 일치하면 접속을 허용하고 틀리면 불허한다.

이처럼 값을 대조하는 간단한 방식으로 이루어집니다. 유의하실 점은 최초에 Private Key를 다운로드 받게 되면 .pem 형식의 파일을 얻을 수 있는데, 이 파일을 그대로 사용할 수 는 없고 puttygen과 같은 프로그램을 사용해서 .ppk 형태의 파일을 얻어내어 사용해야 합니다.

  • Node.js Server

웹 개발에 있어서 분야는 크게 프론트엔드(Front end)와 백엔드(Back end)로 나뉘어 집니다. 프론트엔드는 주로 클라이언트 측에서의 처리를 담당하고, 백엔드는 데이터베이스 등의 서버 측의 처리를 담당합니다. 자바스크립트는 본래 프론트엔드에서만 사용되던 언어인데, 이 언어를 사용하여 프론트엔드 뿐만 아니라 백엔드를 개발할 수 있게 한 일종의 도구가 바로 노드(Node.js) 입니다. 즉, 노드는 하나의 언어로 프론트엔드와 백엔드를 모두 개발할 수 있다는 큰 장점을 지닙니다.

노드를 사용하면, 다양한 기능을 제공하는 모듈(또는 패키지)들을 내 코드에 적용하여 해당 기능을 쉽게 사용할 수 있다는 장점이 있습니다. NPM(Node Packaged Manager) 프로그램을 이용하면 모듈의 설치와 관리가 쉬워지고, 업데이트 관리 역시 할 수 있습니다.

우선, 노드 서버를 구현하기 위해서는 AWS EC2 인스턴스에 노드를 설치해야 합니다. 미리 말하자면, 저희 프로젝트에서 노드 서버를 어떤 방식으로 구현하는가에 대해서는 지금 다룰 수 없습니다. 노드 서버의 구현 방법을 설명하기에는 제 능력이 모자랄 뿐만 아니라, 일단 그 양이 너무 방대합니다. 따라서, 필요하다면 이 후에 저희 프로젝트에서 노드 서버의 역할이나 데이터의 흐름 정도만 간단하게 언급하겠습니다.

다시 돌아와서, EC2 인스턴스에 노드를 설치하기 위해서는 NVM(Node Version Manager)를 먼저 설치해야 합니다. SSH를 통해 인스턴스에 접속하여 NVM을 설치합니다. NVM은 노드의 설치를 간단하게 해줄 뿐만 아니라 이후 노드 버전의 관리에도 큰 도움이 됩니다.

NVM을 설치하고 난 후에, ‘nvm install 8’ 명령어를 통해 간단하게 노드를 설치할 수 있습니다. 프로젝트에서, 노드 서버의 역할은 크게 3가지 입니다.

첫째 역할은, 요청되는 데이터를 라우팅(routing) 처리하여 분류하고, 그에 맞는 응답을 합니다.

간단한 코드로 예를 들어 설명하겠습니다.

클라이언트측
아래 코드는 클라이언트 측에서 서버로 POST 방식으로 데이터를 전송하는 코드입니다. 빨간 박스를 보시면, 가려진 부분은 도메인 주소로 데이터의 목적지를 의미합니다. 데이터를 보낼 서버의 포트 번호가 3000번임을 의미합니다. 이제, 그 뒤에 process/addSubscription를 잘 기억해 두시길 바랍니다. 이 부분을 통해서 서버에서 라우팅이 이루어집니다.

서버측
아래 사진은 서버 측에서, 라우팅을 부분에 관련된 코드 중 일부를 가져온 것입니다. 이번에도 역시 빨간 박스를 살펴보도록 하겠습니다. 여기서 app은 노드 서버 자신을 의미합니다. 점 뒤의 post는 app에 post방식으로 들어온 데이터들을 다루겠다는 것을 의미합니다. 첫번째 파라미터를 보면, 앞서 클라이언트 측에서 데이터를 보낼 때 기억해 두시라 한 부분과 일치함을 알 수 있습니다. 두번째 파라미터는 조건에 맞는 데이터가 전달되면 실행될 함수를 말합니다. 여기까지 정리하면, 아래의 코드는 노드 서버에 post방식으로 전달된 데이터 중에 /process/addSubscription의 꼬리표를 가진 것이 있다면 user.addSubscription 함수를 실행하라는 것이 됩니다. 이와 유사한 방법으로 다른 데이터들도 라우팅 처리하여 적절한 함수를 실행하게 만들 수 있습니다.

둘째 역할은, 인스턴스에 설치된 DB와 연동하여 관련 작업을 처리합니다.

노드는 MongoDB나 MySQL 같은 데이터베이스와 연동되어 사용될 수 있습니다. NPM을 통해 적합한 모듈을 다운받아 사용하시면 됩니다. 저희 프로젝트의 경우에는 MongoDB를 사용했습니다.

MongoDB는 관계형 데이터베이스가 아닌 NoSQL(Not Only SQL) 데이터베이스입니다. 데이터의 구성은 총 3가지로, database, collection, document입니다. Database는 말 그대로 최상위층에 있는 데이터베이스를 의미합니다. Collection은 document의 컨테이너 개념으로 table과 유사하다고 볼 수 있습니다. 마지막으로 document에는 JSON(JavaScript Object Notation)의 형태로 데이터를 저장할 수 있습니다.

MongoDB의 장점

-Schema-less 구조 : 데이터 모델의 유연한 변화가 가능
-빠른 속도의 Read/Write 가능
-Scale Out 구조 : 빅데이터 처리에 용이
-JSON 구조 : 데이터의 직관적 이해 가능
-쉬운 사용법으로 개발에 편리

MongoDB의 단점

-불안정성과 데이터 손실 가능성 : 데이터 갱신 시 바로 디스크에 입력하지 않음
-JOIN이나 트랜잭션 처리에 취약 : 성능 제약
-인덱스를 많이 사용할 경우 메모리를 많이 사용

아래의 사진은 “Do it! Node.js 프로그래밍” 책에서 제공한 소스 코드 중 일부를 참고용으로 가져온 것입니다. 살펴보면, 먼저 mongoose 모듈을 require함수를 통해 가져와서 mongoose 객체에 할당합니다. 그리고 이 mongoose 객체는 connect 함수를 통해 로컬 호스트의 DB와 연결됩니다. 그리고 다시 DB를 database 객체에 할당하여 사용합니다. 중간 부분에 스키마에 대해 정의하는 부분과 그 아래에 모델을 정의하는 부분이 필요한 이유는 앞서 말했듯이 MongoDB가 Schema-less 이기 때문입니다.

셋째 역할은, 클라이언트의 웹 브라우저(단말기)로 푸시 알림을 보냅니다.

아래 코드는 프로젝트에서 사용하는 web push 관련된 서버 측 코드 중 일부입니다. 아래 쪽에 webPush.sendNotification 함수는 특정 클라이언트의 웹 브라우저(단말기)에 푸시 알림을 보내는 역할을 합니다. 이 때 함수에 전달되는 것은 보시는 바와 같이 pushSubscription, payload, options이죠. 먼저 pushSubscription은 push 알림을 받을 상대의 구독(Subscription) 객체 값을 가지고 있습니다. 사진 상에는 나와있지 않지만 DB에서 필요한 구독 객체 값을 읽어와서 pushSubscription 객체에 할당하도록 코딩하였습니다. 참고로, 구독 객체를 이용해서 특정 웹 브라우저를 구분할 수 있습니다. 이외에도 사진과 같은 방법으로 payload 및 options 도 함수에 전달할 수 있습니다.

  • HTTPS 사용을 위한 Letsencrypt CA 인증서 발급 받기

HTTPS란?
HTTPS(Hypertext Transfer Protocol over Secure Socket Layer)는 HTTP 프로토콜에서 보안의 개념이 추가된 프로토콜입니다. 서버와 웹 브라우저 사이의 교환되는 정보를 암호화함으로써, 누군가 고의로 네트워크 상에 오가는 정보를 빼내더라도 HTTPS 프로토콜을 사용하여 암호화되어 있는 정보는 해석할 수 없습니다. HTTPS의 사용으로, 비암호화로 야기되던 보안 이슈는 많이 감소하였습니다.

Let’s Encrypt CA 인증서
HTTPS를 웹 사이트에 적용하기 위해서는 CA (Certificate Authority)에서 인증서를 받아야 합니다. 공인/사설 인증기관을 통해 인증서를 구매할 수 있습니다. 구매비용이 그리 저렴하지는 않은데, ISRG(Internet Security Research Group)에서 만든 Let’s Encrypt라는 인증 기관을 이용하면 무료로 인증서를 취득하고 갱신할 수 있습니다.
인증서를 취득하는 자세한 방법은 설명하지 않겠습니다. 다만, Certbot 에이전트를 사용하면 EC2 인스턴스에 쉽게 Let’s encrypt 인증서를 설치할 수 있고 갱신도 할 수 있습니다. 또한, 도메인 주소가 필요하므로 미리 구매해 놓기를 추천합니다. 정상적으로 모든 과정을 마치고 나면, 아래처럼 초록색 자물쇠와 함께 https로 웹 사이트에 접속할 수 있게 됩니다.

  • Notification API & Push API

푸시 알림 서비스는 Notification API와 Push API 이 두 가지 API 구성으로 동작합니다. 이 두 API는 모두 백라운드에서 푸시 메세지 이벤트에 응답하고 이를 응용 프로그램에 전달하는 Service Worker API를 기반으로 구축됩니다.

Notification API
Notification API는 단말기에 알림을 띄우는 역할을 합니다. 물론 알림을 띄우기 위해서는 사전에 사용자의 허가가 필요합니다.

허가 요청
아래는 requestPermission 함수를 호출하여 사용자에게 알림 허용 팝업창을 띄우는 코드입니다. 사용자가 웹 사이트에 접속하면 웹 브라우저는 팝업창을 띄우고, 사용자의 응답이 웹 브라우저에 저장됩니다. 사용자가 알림을 허용한 상태에서만 알림을 표시할 수 있습니다.

알림 표시
아래는 showNotification 함수를 호출하여 단말기에 알림을 호출하는 코드입니다. 호출되는 알림에 대해 옵션을 설정할 수 도 있고, Interaction API를 추가로 사용하면 Service Worker와 상호작용하여 사용자가 알림을 본 후에 취하는 행동에 따른 action 처리도 할 수 있습니다.

아래 코드는 사용자가 알림을 클릭하였을 때, 서비스워커가 클릭 이벤트에 반응하여 동작하는 코드입니다. 이벤트 리스너는 클릭한 action에 따라 알림을 끌 수 도 있고 혹은 특정 웹 사이트로 이동할 수 도 있습니다.

Push API
웹 페이지가 열려 있지 않은 경우에, 사용자의 단말기에 알림을 띄우기 위해서는 Push API를 사용해야 합니다. Push API가 사용자의 웹 브라우저에 푸시 메시지를 보내면, Service Worker가 그 메시지를 받고 그 다음 Notification API는 알림을 화면에 띄우게 되는 것입니다.

구독 객체
Push API가 특정 웹 브라우저에게 푸시 메시지를 보내기 위해서는 각 브라우저를 구분할 수 있는 어떤 것이 필요합니다. 이 때 사용하는 것이 구독(Subscription) 객체입니다. 앞서, Notification API에서 사용자가 알림을 허용하면, 각 웹 브라우저의 자체적인 푸시 서비스에 웹 브라우저가 등록됩니다. 그리고 이어서 사용자 웹 브라우저의 endpoint URL과 public key가 포함된 특수한 객체가 만들어지는데, 이것이 곧 구독 객체이며 아래의 형태와 같습니다.

푸시 메시지를 받을 사용자는 public key로 암호화된 endpoint URL을 보고 알 수 있습니다. 이 endpoint URL에 있는 식별자는 암호화 되어 있기 때문에 봐도 이해할 수가 없으며, 고정적이지 않기 때문에 제 3자가 사용자를 추적할 수도 없습니다. 애초에 Service Worker와 함께 동작하기 때문에 HTTPS 사용하는 웹 사이트에서만 동작이 가능하고, 따라서 서버와 푸시 서비스 간의 통신 채널과 푸시 서비스와 사용자 간의 통신 채널은 안전합니다.
서버로부터 푸시 메시지를 받게 되면, 사용자의 웹 브라우저의 백그라운드에서 동작하는 서비스 워커는 이에 반응하여 동작합니다. 아래는 push 이벤트에 반응하여 동작하는 이벤트 리스너 코드입니다. 서비스 워커가 push 이벤트를 인식하면, showNotification 함수가 동작하여 알림을 화면에 띄웁니다.

푸시 서비스 프로세스
결국, 서비스 워커와 Notification API, 그리고 Push API를 이용한 푸시 메시지를 보내고 받고 알림을 표시하는 프로세스는 아래의 그림과 같습니다.

[ 3.결론 | 가능성과 한계 ]

1) 프로젝트 결과

2) 프로젝트 요약 정리

청각장애인분들은 진동벨이 없는 카페에서 음료제조 완료알림을 받는데 불편함을 느끼십니다. 저희는 앱 설치나 문자메세지 등 진동벨을 대체하는 기존의 방식과는 달리, 스마트폰을 통해 간편하게 음료제조완료를 push 알림으로 받을 수 있도록 PWA형식의 시스템을 개발하였습니다.

3) 기대되는 효과

카페입장)

  • 진동벨 관리(분실, 고장, 청결상태 등)에 대한 부대비용을 고려하지 않아도 됩니다.

점원입장)

  • 손님이 주문을 한 후 nfc태깅을 통해 음료제작 완료알림을 받을 수 있도록 허용하기 때문에 점원이 주문을 받으면서 진동벨에 입력하고 음료제작이 완료되었을 떄 그에 맞는 진동벨 번호를 호출하는 번거로움을 줄일 수 있습니다.

손님입장)

  • 웹주소만으로 접근이 가능하기때문에 접근성이 용이하고 편리할 것입니다.
  • 앱을 설치할 필요가 없고, 단말기의 저장공간을 거의 차지 않기때문에 부담이 적을 것입니다.

4) 한계

  1. 아이폰 사용자는 이용할 수 없다.

    • ios가 개발한 웹브라우저인 safari에서는 PWA를 지원하지 않습니다. 또한 아이폰에 크롬 앱이 설치되어 있더라도 PWA의 모든 기능이 작동하진 않습니다.

  2. 특정 웹브라우저만 사용가능하다.

    • 브라우저별로 지원되는 PWA관련 서비스가 다릅니다. 또한 동일한 브라우저라도 설치된 버전에 따라서 서비스가 지원되지 않을 수 있습니다.
    • 저희 시스템은 크롬 웹브라우저 버전 50이상을 추천드리며 그 이하의 버전에서 시스템이 잘 동작하지 않을 수 있습니다.

  3. 스마트폰을 사용하지 않는다면 대체할 만한 장치가 필요하다.

    • 요즘 대부분의 사람들은 스마트폰을 사용하지만 카페를 이용하는 모든 손님들이 스마트 폰을 이용한다는 보장은 없습니다. 그러나 스마트폰을 사용하지 않아도 웹브라우저가 설치된 장치(예: 노트북)에 url을 입력하면 이용할 수 있습니다.

5) 확장가능성

  1. 애플의 긍정적인 검토

    • Apple은 여전히 PWA를 지원하지 않지만 WebKit에서 service worker API를 개발중입니다. 따라서 언젠가 Apple도 일종의 PWA와 같은 형태를 지원할 전망이 보입니다.
    • 참고사이트 https://webkit.org/status/

  2. 오프라인 로딩가능 활용

    • PWA는 온라인시에 한번만 로딩하면 오프라인 상태일때도 로딩이 가능합니다. 이런 점을 이용하여 카페측에서 메뉴판 페이지를 만든다면 카페를 방문하지 않고도 메뉴에 대한 정보를 제공할 수 있을 것입니다.

  3. 결제모듈 적용

    • 2번에서 소개한 메뉴판 페이지가 개발되었다면 더 나아가 결제시스템을 적용할 수 있습니다. 그렇게 된다면 손님들이 카페에 직접 와서 어떤 메뉴가 있는지 확인하고 뭘 먹을지 결정하여 주문을 완료하기까지의 시간을 절약하는데 도움을 줄 수 있습니다.

  4. 업데이트 시 설치 필요 X

    • 서비스 제공자가 기능 및 보안 업데이트를 했을 시 모든 사용자들이 온라인 상태에서 다시 로드만 해주면 최신상태로 유지할 수 있습니다. 따라서 전체 사용자에게 최적화된 사용자환경을 지속적으로 제공할 수 있습니다.

Clone this wiki locally