스마트폰과 푸시 알림 서비스

2007년 미국 샌프란시스코에서 개최된 맥 월드에서 아이폰이 처음 공개된 이후 지금까지 수많은 스마트폰이 출시되고 있으며 사람들의 관심과 기대도 계속되고 있다. 스마트폰 이전에는 PDA가 다소 큰 크기와 투박한 사용자 인터페이스(UI)였지만 스케줄링 기능과 이동성을 앞세워 사용됐다. 그때와의 확연한 차이라면 미려한 UI와 내부 프로그램의 실행속도, 모바일의 특징을 살린 네트워크를 꼽을 수 있다. 이번 연재는 iOS의 ‘푸시 알림 서비스(APNs)’를 기준으로, 심도 깊은 내용보다는 푸시 알림 서비스(Push Notification Service)의 전반적인 소개와 산재된 정보를 모아보는 식으로 진행하겠다.

민재열 linkermin@gmail.com｜영화 <Hackers 2 - Takedown>을 보고 IT를 동경해버린 공학도. 넥슨에서 시스템 엔지니어링 업무를 담당했으며, 현재 모바일과 평생 개발에 관심이 많다.

누구나 회사에서 업무를 진행하거나 개인적인 약속을 지키기 위해 일정관리 프로그램을 스마트폰에 등록해 사용한 경험이 있을 것이다. 그러나 바쁜 일상을 지내다 보면 다양한 이유로 프로그램에 등록된 일정을 확인하지 못해 당혹스러운 상황이 발생하기도 한다. 필자는 그런 사태를 미연에 방지하고자 해당 프로그램에 포함된 알림 기능을 꼭 등록한다. 

일정관리 프로그램의 대부분은 자체 알림 기능(Local Notification)을 포함하고 있다. 하지만 웹/모바일 환경으로 확대 되면서 네트워크를 이용한 알림 공유가 떠오르고 있다. 필자가 경험한 바에 의하면 로컬 일정관리 프로그램과 웹 일정을 공유하거나 서버의 서비스 상태를 모니터링할 때는 모두 SMS(Short Message Service)를 사용한다. 

하지만 이것은 사용자가 항상 들고 다니며 사용빈도가 높은 휴대폰을 엔드포인트로 고려한 알림 서비스다.

원격 알림 기능
원격으로 메시지를 전달받는 서비스인 SMS는 휴대폰이 확산되면서 필수 기능 중 하나로 자리매김했다. SMS는 사용자간 메시지를 주고받는 것 외에도 일정알림이나 서버 모니터링 시 주요 메시지를 전달받는 원격 알림으로 사용된다. 

하지만 스마트폰 관련 앱이 폭발적으로 확대되면서 알림 서비스는 단순 메시지 전달 외에도 소셜 네트워크 서비스(SNS), 뉴스, 주식, 경매, 스포츠 결과, 게임 등 다양한 용도로 사용되고 있다. 그래서 SMS의 비용측면과 메시지 전달의 즉시성을 모두 만족시키는 원격 알림 서비스(Remote Notification Service)에 대한 관심이 커지고 있다. 

이런 배경을 고려해 지금부터 원격 알림의 기본적인 내용과 스마트폰에서 왜 푸시 알림을 사용하는지 그리고 모바일 OS에서 제공되는 알림 지원 서비스를 알아보겠다.

Push VS Pull
애플에서 제공하는 원격 알림 지원 서비스는 푸시 알림이며, 안드로이드 및 윈도우폰 7에서도 같은 형태의 알림기능을 제공한다. 이는 스마트폰 환경의 적합성을 고려해 서비스한다는 것을 의미한다. 

먼저 Push 형태의 서비스가 무엇인지 알아보고 이와 상반되는 Pull 서비스와 비교해 보겠다. 좀 더 빠른 이해를 돕기 위해 <표 1>에 두 가지 서비스 형태에 대한 대략적인 설명과 서비스 예를 작성했다. 

<표 1> Push 서비스와 Pull 서비스 비교

일반 사용자 PC 환경에서는 프로그램이 사용되지 않으면 백그라운드로 전환돼 전력이나 네트워크 사용량에 크게 영향을 주기 않는다. 하지만 휴대성이 장점인 모바일 기기는 크기와 성능, 배터리, 네트워크 사용량 등을 고려해야 한다. 

알림 서비스는 사용자가 다른 작업을 하거나 모바일 기기를 사용하지 않아도 서비스돼야 한다. 그래서 Pull 방식으로 서비스하면 관련 애플리케이션이 항상 백그라운드로 실행되면서 Pulling으로 정보를 가져오거나 사용자가 직접 업데이트를 진행해야 한다. 이로 인해 알림 서비스의 즉시성(Real-time)과 배터리 및 네트워크 대역 같은 자원 효율성에 문제가 발생할 수 있다. 

물론 실시간에 민감하지 않거나 Polling으로 정보를 가져오는 시간을 짧게 줄이면 문제가 해결되지 않겠냐고 생각하는 독자들이 있을 것이다. <그림 1>을 보자.

<그림 1> polling 서비스 시의 베터리 전력 사용량

<그림 1>을 보면, 평소에는 5~8mA의 전력이 소비되다 약 10초간 네트워크로 Polling 서비스를 사용하면(그래프 중앙 구간) 180~200mA의 전력이 소비되는 것을 알 수 있다. 

또 Short Poll로 약 0.5mA의 Polling 서비스를 사용하면 하루 기준 시간당(H/Day) 소비량은 5분 간격일 경우 약 144mA, 15분 간격일 경우 48mA의 전력이 소비되는 것을 알 수 있다. 물론 이 수치는 하드웨어에 따라 차이가 있겠지만 평소 전력 소비량과 비교한다면 결코 무시할 수준이 아니다. 

이런 제한사항을 극복하고 알림 서비스가 로컬 환경이 아닌 원격, 즉 원격 알림을 할 수 있으면서 스마트폰 환경에 맞는 적절한 대안이 Push 서비스인 것이다. 지금부터 많이 사용되며 이슈가 되고 있는 모바일 OS 별 푸시 알림 지원 서비스를 소개하겠다.

애플의 APNs
애플의 푸시 알림 서비스(Apple Push Notifica tion service 이하 APNs)는 iOS를 지원하기 위해 구성돼 있다. 클라우드 서비스 형태를 가지고 있으며, 전 세계 아이폰 iOS를 대상으로 알림 메시지를 전달한다. 

APNs의 소개는 애플에서 제공하는 개발자 라이브러리 문서를 위주로 설명하겠다. 

<그림 2> 프로바이더에서 APNs를 거쳐 사용자 앱까지 푸시 알림을 보내는 절차

<그림 2>는 생성된 알림 메시지가 전달되는 과정을 보여준다. 한 개 혹은 다수의 프로바이더(개발자가 구성한 서버)에서 시작된 메시지는 APN을 통해 디바이스(아이폰)로 전달된다. 디바이스상에 있는 운영체제(iOS)는 해당 메시지와 관련된 앱의 알림을 한다. 사용자가 앱을 종료한 상태이더라도 iOS에서 해당 메시지를 모니터링하고 있기 때문에 알림 메시지가 수신되면 해당 앱으로 알림 메시지를 전달한다. 

만일 앱이 구동되고 있지 않다면 앱 아이콘 우측 상단에 배지 넘버(Badge Number)가 표시된다. 그리고 앱이 삭제돼 iOS에서 최종 수신지를 찾지 못한다면 피드백 서비스의 정해진 Time Stamp 값을 확인한 뒤 초과 시 APNs에서 알림을 더 이상 보내지 않는다. 

다음은 프로바이더와 APNs, 디바이스간 구성된 보안 연결방식이다. 각 포인트 연결 시 TLS(SSL 3.0의 업그레이드 표준화 버전, SSL 3.1)를 이용해 Peer-to-Peer Connection Trust로 암호화되고 신뢰 구간을 형성한다. 그 후 Device Token과 Payload로 이루어진 알림 메시지를 전달하게 된다. 

여기서 Device Token은 전화번호와 유사한 의미로, 특정 스마트폰을 구별하는 정보(UDID) 와는 다른 의미이다. 디바이스가 APNs에 처음 접근하면 발급받을 수 있고, 프로바이더와 해당 정보를 공유한다. 이후 프로바이더에서 APNs으로 알림 메시지를 전달할 때 같이 보낸다. 

Payload는 알림에 포함돼 사용자에 전달될 메시지 데이터이며, 알림 Type과 Custom Data를 포함한다. <그림 3>은 위에서 언급한 Connection Trust 흐름을 나타낸 것으로 TLS를 이용한 보안성 신뢰 구간을 형성한다. <그림 4>는 알림을 구성하는 Device Token과 Payload에 대한 내용이다. 

<그림 3> Connetction Trust 흐름도

<그림 4> 알람의 구성

알림 Message에서 Payload는 전송되는 데이터 정보를 가지고 있으며, Device Token은 인증 정보를 가지고 있는 중요한 부분이다. 푸시 알림을 사용하는 iOS 기반의 앱은 반드시 APNs에 등록해야 한다. 앱은 디바이스(아이폰)에 설치된 후 iOS를 통해 APNs에 등록하는 절차를 따르게 된다. 등록 요청을 받은 APNs는 디바이스에 포함된 유일한 Device Certificate로 Device Token을 생성하고 Token Key와 함께 암호화해 디바이스로 재송한다. 

각 Peer-to-Peer 구간에서의 Token 생성과 분산 구조는 <그림 5>와 같다. 생성된 Device Token은 프로바이더로 보내져 공유된 후 프로바이더에서 알림 메시지를 전달할 때 마다 같이 전송된다.

<그림 5> Token 생성 절차

<그림 6> Device Token의 분배(to Provider)

설명한 일련의 절차를 거쳐 보안 인증이 구성된다. 이후 디바이스는 APNs와 Token, Device Certificate를 통해 전달받은 상태가 되었음을 확인하고, 프로바이더는 APNs의 Token 인증 절차를 거쳐 디바이스로 알림을 보낼 수 있다. 

<그림 7> Notification의 전송

구글의 C2DM
C2DM(Cloud to Device Messaging Framework)은 안드로이드에서 Push Service를 하기 위한 클라우딩 서비스로 안드로이드 2.2(프로요)를 발표하면서 제공됐다.
그동안 Polling으로 정보 데이터를 갱신하는 데 만족했으나 앱에서 푸시 알림을 사용할 수 있다는 것은 자원 활용 면에서도 환영할 일이었다. 그러나 ‘구글 서비스’를 사용하려면 앱 사용자가 초기에 구글 계정을 인증받아야 한다는 점과 안드로이드 2.2 이상의 버전에서만 동작한다는 점 등이 사용자에게 부담으로 작용할 수 있다. 

<그림 8>은 안드로이드 개발자 사이트에서 확인한 플랫폼 버전 현황이다.

<그림 8> 2011년 1월 1일부터 14일간 수집한 안드로이드 플랫폼 현황

해당 서비스를 소개하기 위해 여러 자료를 찾아봤지만 세부적인 구현 내용에 대해서는 아직 문서가 없었다. 그나마 해외 블로그에 실린 내용 중 일부가 C2DM 서비스 흐름을 잘 표현한 것 같아 공유해본다. <그림 9>는 앱 서버를 구축해 사용할 경우다.

<그림 9> C2DM의 Life Cycle

<그림 9>를 간략히 설명하면

1) 먼저 앱이 실행되면서 ‘개발자 ID - 구글 계정’, ‘애플리케이션 ID - 패키지 이름’을 C2DM으로 전달하고 ‘등록 ID - 모바일 기기를 식별하는 ID’를 수신
2, 3) 발급받은 등록 ID를 자체적으로 구축한 앱 서버에 전송/기록
4) 개발자 이메일 주소와 암호를 통해 ‘AUTH Token’을 획득
5) ‘등록 ID’ + ‘AUTO Token’을 메시지와 함께 C2DM으로 전달
6~8, 10) C2DM 내에서의 처리
9) 사용자 앱으로 푸시 알림 전달

현재까지 안드로이드 플랫폼을 위한 C2DM 서비스는 구글 랩에서 진행 중이다. 구글 서비스를 통한 인증 부분과 대량의 콘텐츠 푸시 등 개발자와 사용자에게 다소 투박한 서비스를 제공하고 있다. 하지만 일반 서비스로 릴리즈되면서 차츰 편의성과 성능이 향상될 것이라 기대한다.

마이크로소프트의 MPNs
마이크로소프트는 모바일 OS 계열에서 오랫동안 자리를 차지하고 있었다. 하지만 윈도우의 UI와 애플리케이션 대부분을 그대로 모바일 기기에 적용해선지 모바일 OS의 매력은 다소 감소됐다. 

아이폰과 안드로이드 진영의 확대와 함께 마이크로소프트도 윈도우폰 7을 출시했으며, 기존과는 확실히 다른 인터페이스를 갖추게 됐다. 아직 국내에서는 윈도우폰 7용 디바이스가 활성화되지 않았지만 커뮤니티 상에서 활발한 교육과 개발 이슈가 공유되는 것을 보면 곧 스마트폰 앱 시장에 한 부분을 차지할 것으로 보인다. 

마이크로소프트에서 제공하는 푸시 알림은 MPNs(Microsoft Push Notification service)이다. 윈도우 애저 기반의 클라우드 서비스에서 동작하는 푸시 알림 서비스로, 상용 서버 제품을 출시하던 마이크로소프트웨어가 출시한 만큼 인프라가 잘 갖추어져 있을 것이라고 기대한다. 먼저 MSDN에 소개된 푸시 알림 서비스를 대략적으로 알아보고 그 특징을 살펴보자. 

<그림 10> 푸시 알림 for Windows Phone

<그림 10>에서 보듯 알림 서비스는 기존에 소개한 내용과 유사하다. 설치된 앱에서 OS 서비스를 통해 푸시 지원 클라우드 서비스(MPNs)로 접근한다. 디바이스와 푸시 서비스 간에 유일한 ID 등을 교환하면서 장비가 인식되고, 그 정보를 앱 서버(자체 구성된 써드파티 서버)와 공유한다. 

이후 디바이스에서 앱 서버로 알림 메시지를 보내거나 앱 서버에서 작성한 메시지를 푸시 지원 서비스(MPNs)를 통해 최종적으로 스마트폰에 알람이 도착된다.

원본 출처 - http://www.imaso.co.kr/?doc=bbs/gnuboard.php&bo_table=article&wr_id=37946