I/O 2016에서 발표한 Awareness API 기술 A to Z

aware
Google이 금년 I/O에서 공개한 Awareness API를 사용해 보세요. 여러분의 안드로이드 애플리케이션이 사용자의 상황이나 위치를 더 쉽고 정확하게 인식하도록 할 수 있으며, 무엇보다도 기존보다 간단하게 구현할 수 있습니다.

이번 포스팅은 Awareness API의 전반적인 내용을 모두 담기 위해 노력했습니다. 여러분의 모바일 애플리케이션에 Awareness API가 필요한지 알아보고, 핵심 사용 방법에 대해 배울 수 있는 시간이 되기를 기대합니다!

 

1. High-quality App. 사용자 Context 인지의 필요성
여러분의 애플리케이션도, 이제 High-quality App으로 발돋움 할 때입니다.
High-quality App이란 직관적인 UI, 잘 구현된 기능 등 기존의 기준들은 당연히 충족해야 하는 것으로 보고, 사용자의 위치나 상황 등을 고려하여 적절히 서비스할 수 있는 그 이상의 애플리케이션을 의미합니다.
context

사용자의 위치나 상황, 즉 사용자의 Context를 제대로 파악하고 이해하는 것이 High-quality App의 핵심입니다. 

-수영을 시작하면, 애플리케이션이 자동으로 수영하고 있음을 인지하여 사용자의 수영 기록을 저장한다.
-직장에 도착하면, 스마트폰이 인지하여 홈 화면에 직장에서 자주 사용하는 애플리케이션이 보여진다.
-음악 애플리케이션을 실행하면, 날씨나 스트레스 정도, 선호 음악 등을 고려해서 음악을 추천한다.

이렇게 애플리케이션을 통해 사용자 맞춤형 서비스, 이른바 온-디멘드(On-demand) 서비스를 제공하기 위해서는 User의 Context를 파악하는 기술이 필요조건입니다.

 

2. Context의 구체적 분류, 그리고 관련 API들
구글은 사용자의 Context 인식을 위해서 9가지 API를 준비해 놓았습니다.
그렇다면 사용자의 Context를 이해하기 위해서는 구체적으로 무엇을 알아야 할까요? 모바일 애플리케이션 개발자가 사용자 Context를 검출할 수 있도록 구현된 구글의 9가지 API로 대신 답하겠습니다.

Location ( Where is the user? ) – 사용자 위치 파악
Location

Activity ( What is the user doing? ) – 사용자 활동 파악
activity

Nearby ( What is near the user? ) – 사용자 주변 기기 파악
nearby

 

3. About Awareness API
Awareness API는 9가지 Context 관련 API 퍼즐 조각을 하나의 그림으로 완성한 것입니다.
위에서 소개한 것처럼, Context와 관련된 여러가지 API가 있습니다. 문제는 저희가 보통 한 가지 API만 사용하지 않는다는 것입니다. 예를 들어 사용자 위치를 파악하는 동시에, 어떤 속도로 이동하는지 파악하는 등 최소 2가지 이상의 API를 사용합니다. 기존의 이러한 API 혼용 방식은 몇 가지 문제점이 있었습니다.

[복잡성] 여러 개의 센서 신호를 다루기 위한 다양한 API들의 존재
[개발의 어려움] 다양한 API 들을 조합하기 위한 알고리즘 구현으로 많은 시간이 소요
[배터리 소모] API들의 사용 순서 등에 따라서 배터리 낭비가 심해질 수 있음

이런 문제들을 해결해서 개발자들이 정말로 필요한 사용자 기능 개발에 집중할 수 있도록 하기 위해서 만들어진 것이 이번 구글 I/O 2016에서 공개된 Awareness API입니다. 기존의 문제점들을 해결하기 위해서 만들어진 API인 만큼, 기존의 단점들이 장점으로 승화되었습니다.

[개발의 단순화] 기존의 API들을 통합하고 단순화. 필요한 기능 개발에 집중 가능
[배터리 이슈] API 내부 알고리즘이 배터리 소모가 최소화되도록 구현되어 있음. 개발자가 배터리를 걱정할 필요가 사라짐
[직관적인 Context 분류] 총 7가지의 시그널(time, location, places, beacons, headphones, activity, weather)로 context를 직관적으로 분류하여 쉽게 사용할 수 있음

 

사용방법
그렇다면 실질적인 사용방법을 알아볼까요? Awareness API는 사실 각각 독립적으로 사용할 수 있는 두 개의 API로 분리되어 있습니다. 그 중 하나는 Fence API고, 또 다른 하나는 Snapshot API 입니다.

펜스 API(Fence API) :
fence간단하게 어떤 펜스, 즉 기준을 설정하면, 기준의 충족 여부에 따라서 참 또는 거짓(True of False)의 값을 알려주는 API입니다. 개발자들은 이 참 또는 거짓의 Boolean Type을 이용해서 사용자의 상황을 검출할 수가 있습니다. 예를 들어서, 이어폰을 꽂았는지, 운전을 시작했는지, 특정 장소에 도착했는지 등의 여부를 펜스 API를 통해서 간단하게 검출해서 사용자에게 어떤 제안이나 서비스를 해줄 수가 있습니다. 무엇보다도, 여러가지 펜스를 설정해두고, 이것들을 조합해서 복합적인 기준을 만들 수가 있습니다.

스냅샷 API(Snapshot API) :
snap펜스 API와 독립적으로 사용할 수 있는 API로, 어떤 Context의 실제 값을 알 수 있습니다. 예를 들면 현재 위치의 위도와 경도 값, 현재 날씨 등입니다.

정리해볼까요? Fence API를 이용해서 사용자가 특정 행동을 하거나 특정 상황인지의 여부를 참, 거짓 형태의 값으로 알 수 있다면, Snapshot API를 이용해서 사용자 행동의 실제 값(ex : 사용자의 현재 움직이는 속도)이나 주변 상황의 실제 값(ex : 현재 날씨 23도)을 알 수 있습니다.

 

4. Awareness API를 사용해야 하는 이유 네 가지
지금까지 Awareness API 사용 방법을 알아보았습니다. 위에서도 언급했지만, Awareness API는 단순히 구현하기 쉽다는 장점만 있는 것은 아닙니다. 기존의 API를 Awareness API로 대체하는 것에 대해 망설이시는 분들은, Awareness API를 구현할 때 구글이 고려했던 네 가지 이슈(Coverage, Accuracy, Latency, Power)에 대해서 알아야 합니다.
rlend

Coverage : 사용자 인지는 실내, 실외 가리지 않고 모든 장소에서 가능해야 하지만, 쉽지 않은 일입니다.
Accuracy : 사용자 인지는 정확하게 이루어져야만 하고, 저희 개발자들은 정확성 향상을 위해 많은 시간을 투자해야 했습니다.
Latency : 사용자 인지는 실시간으로 이루어져야 합니다. 하지만 센서를 사용하기 위해서 실시간으로 애플리케이션을 깨우는 것은 많은 배터리를 소모합니다. 그렇다고 측정 간격을 길게 가져가면, 사용자 인지의 정확성이 떨어집니다.
Power : 스마트폰의 배터리는 무한정이지 않습니다. 그렇기 때문에 실시간으로 사용자의 Context를 파악하는 것은 많은 배터리 소모로 이어집니다.

개발자들은 사용자의 Context를 인지하기 위해서 여러 가지 API를 조합하는 알고리즘을 구현해야 했을 뿐만 아니라, Coverage, Accuracy, Latency, Power 등 추가적인 이슈 사항들도 고려하기 위해서 머리를 싸매야 했습니다. 이제는 Awareness API를 이용해서 간단히 해결하세요! 구현 방법도 간단할 뿐만 아니라 다른 이슈들로 고민하지 않고 원하는 기능 개발에 집중하실 수 있습니다.

 

*2016년 6월 29일부터, Awareness API를 공개적으로 이용할 수 있게 되었습니다. 구체적인 사용 방법을 공유하기 위해서 빠른 시일 이내에 다시 찾아뵙겠습니다. 감사합니다.

[중요 업데이트] Google Maps APIs Standard Plan 정책 변경 (2016.6.22 부터 적용)

구글 Geo Developers Blog에 2016년 6월 22일 발행된 Ken Hoetmer(Google Maps APIs Product Manager)의 공지를 번역한 글입니다.

오늘날 위치정보를 사용하는 수백만개 이상의 앱과 웹사이트가 Google Maps API를 통해 매일 수십억개의 리퀘스트를 생성하고 있습니다. 카 쉐어링(car sharing)서비스부터 사진작가들을 위해 해와 달의 정보를 제공해 주는 서비스, 노숙자 지원 서비스까지, 지도와 위치정보의 잠재력은 개발자들의 창의성에 따라 무궁무진하게 발휘될 수 있습니다.

지난 10년간  데스크탑에서 모바일로 인터넷 환경이 획기적으로 변화했으며 이와 함께 Google Maps의 서비스도 개발자 및 사용자들의 필요에 맞춰 진화했습니다. 기기의 수가 늘어나면서 쿼리 수 또한 기하학적으로 증가 해 왔고 전세계 수억명의 사용자들이 새로 인터넷을 접하고 있는 상황입니다. 이에 따라 오늘 Google Maps는 몇가지 업데이트를 통해 Google Maps APIs 스탠더드 플랜의 범위와 가격 정책에 일관성과 간결성을 더하고자 합니다.

 

2016년 6월 22일부터 Google Maps API 스탠더드 플랜에 다음과 같은 변화가 적용됩니다:

  1. API 키(key)가 없는 리퀘스트는 더 이상 지원되지 않습니다. 향후 업데이트 또한 API 키를 사용한 리퀘스트에만 적용 될 것입니다. API 키가 있어야 Google이 필요시 개발자에게 연락을 취하고 수월하게 오작동을 감지할 수 있습니다.
  2. 새로운 Google Maps의 JavaScript API, Static Maps API, Street View Image API에 대해 하루 25,000건까지 무료로 맵을 로딩할 수 있게 되었습니다 (단, 기업 내부 사용을 위한 시스템 및 상업적인 목적으로의 구글맵 사용이 아닌 경우). “90연속일” 사용을 기준으로 해당 API에 적용되었던 다소 모호한 기존 정책은 2016년 10월 12일로 폐지됩니다. 새 정책의 도입으로 개발자들이 서비스의 성장 전망을 감안하여 기획을 할 수 있게 되었습니다. 언론 및 미국 소재 비영리재단은 구글의 지원 프로그램을 통해 추가 비용 없이 할당량을 늘릴 수 있게 됩니다.
  3. Google Maps JavaScript API, Static Maps API, Street View Image API에 대해 구매하여 사용할 수 있는 일일 맵 로딩 최대 한도가 API 당 1,000,000에서 100,000로 축소되었습니다.* 보다 더 큰 규모의 서비스가 필요한 개발자에게는 기술지원과 서비스 수준 협약서(Service Level Agreement)가 포함된 프리미엄 플랜이 가장 적합하리라 생각합니다. 이에 따라 맵스 및 웹 서비스 API 스탠더드 플랜의 사용한도(quota)를 일관적으로 적용할 수 있게 되었습니다.  
  4. 이제 Google Maps JavaScript API의 클라이언트-사이드 리퀘스트도 해당 웹서비스 API의 사용건수로 집계되어 일일 사용한도의 제한을 받게 됩니다.

 

신규 정책은 2016년 6월 22일 또는 그 이후로 생성된 모든 Maps API 적용 맵에 즉시 반영 됩니다.

기존 사용자들은 어플리케이션이 업데이트 전과 동일하게 작동 할 수 있도록 사용량에 따라 새 정책의 적용에서 제외될 수 있습니다. 구글은 기존 API 키 사용자들의 사용량 증가 패턴을 분석해 향후 새 정책에 영향을 받을 가능성이 있는 모든 사용자들에게 적극적으로 연락을 취할 계획입니다. 기존 API 키 사용자께서는 스탠더드 플랜 업데이트 내용 요약을 참고하시어 각 업데이트가 세부적으로 어떤 영향을 미칠지 확인 해 주시기 바랍니다.

보다 더 자세한 설명이 필요하신 분께서는 Google Maps 공식 파트너 (주)SPH help@sphinfo.co.kr 으로 연락주시기 바랍니다.

*2016년 6월 22일 이전 생성된 앱 및 웹사이트 중 새로운 사용한도 기준을 초과해온 경우 예외가 적용될 수 있습니다.