Tacotron 2의 모델 아키텍처에 대해 자세히 알아보기. 이미지의 아래쪽 절반은 문자 시퀀스를 스펙트로그램에 매핑하는 시퀀스-시퀀스 모델을 나타냅니다. 기술적인 세부 사항은 논문을 참조하세요.
최첨단 TTS 시스템의 결과를 보여주는 Tacotron 2 오디오 샘플 몇 가지를 들을 수 있습니다. 인간 청취자에게 생성된 음성이 얼마나 자연스러운지 점수를 매겨달라고 요청한 평가에서 성우와 같은 전문가들이 녹음한 음성에 대해 매긴 점수와 비슷한 점수를 얻었습니다.
샘플이 훌륭한 것 같지만 아직 해결해야 할 어려운 문제가 몇 가지 남아 있습니다. 예를 들어, 우리의 시스템은 복잡한 단어(예: decorum, merlot)를 발음하는 데 어려움이 있으며 극단적인 경우에는 이상한 소리를 랜덤하게 생성할 수도 있습니다. 또한, 아직은 실시간으로 오디오를 생성할 수 없습니다. 게다가 아직은 생성된 음성을 제어할 수도 없습니다(예: 행복하거나 슬픈 음색을 내도록 지시). 이들 각각은 그 자체로 흥미로운 연구 과제입니다.
감사의 말
Jonathan Shen, Ruoming Pang, Ron J. Weiss, Mike Schuster, Navdeep Jaitly, Zongheng Yang, Zhifeng Chen, Yu Zhang, Yuxuan Wang, RJ Skerry-Ryan, Rif A. Saurous, Yannis Agiomyrgiannakis, Yonghui Wu, Sound Understanding 팀, TTS Research 팀 및 TensorFlow 팀에 감사의 마음을 전합니다.
개요 페이지에서는 비정상 종료가 발생하지 않은 사용자 비율이 두드러지게 표시되므로 어떤 빌드가 안정성 측면에서 향상되고 있는지를 측정할 수 있습니다.
또한 유의성 배지 도 확인할 수 있습니다. 이 배지가 강조 표시되어 있을 때는 앱 작동을 비정상적으로 만들 수 있는 두드러지는 요소가 있음을 나타냅니다. 예를 들어, 유의성 배지를 통해 특정 문제가 특정 기기, OS 또는 탈옥된 휴대폰에서만 발생하는지를 알 수 있습니다.
이러한 통찰력 있는 정보에 힘입어 문제를 효과적으로 분류하고, 긴급한 문제에 신속하게 대응할 수 있습니다. 탈옥된 기기에서만 일반적으로 발생하는 문제는 우선 순위를 낮출 수 있습니다. 아니면 최신 OS 릴리스로 인해 발생한 문제를 수정하는 데 더 집중할 수도 있습니다. 유의성 배지는 문제를 해결할 때 더욱 현명한 결정을 내리는 데 도움이 됩니다.
사용자설정 키 및 로그
Crashlytics를 사용하면 비정상 종료가 발생한 이유와 어떠한 일이 발생하여 비정상 종료에까지 이르게 되었는지에 대한 추가 정보와 그에 대한 컨텍스트를 제공하는 로그와 키를 계측할 수 있습니다.
구체적으로 말하면, 로그를 사용하여 비정상 종료가 발생하기 바로 전에 사용자가 어떠한 작업을 하고 있었는지에 대한 세부 정보를 수집할 수 있습니다(예: 사용자가 다운로드 화면으로 이동하고 다운로드 버튼을 클릭함). 또한, 로그를 사용하여 사용자 작업에 대한 세부 정보를 얻을 수도 있습니다(예: 이미지 다운로드 크기). 로그는 비정상 종료 전에 발생한 이벤트의 타임라인을 보여 줍니다. 비정상 종료가 발생하면 더욱 신속하게 디버그하는 데 도움이 되도록 로그 내용을 취하여 이를 비정상 종료 보고에 추가합니다.
상황에 따라 사용자 앱의 마지막 상태를 아는 것이 작업 순서만큼 중요한 경우도 있습니다. 키는 사용자가 앱을 탐색함에 따라 덮어 쓰이는 항목에 대해 마지막으로 알려진 값을 기록하는 키 값 쌍입니다. 예를 들어, 키를 사용하면 게임 앱에서 사용자가 마지막으로 이룬 레벨이나 맞춤 설정의 최신 구성 등 디버그 작업에 유용할지 모르는 컨텍스트를 나타낼 수 있는 정보를 추적할 수 있습니다.
로그와 키는 세션 메타데이터에서 단서를 찾고 버그를 재현하기 위해 사용자가 수행한 단계를 되짚어 갈 수 있는 아주 훌륭한 방법입니다.
실시간 알림
안정성 문제는 워크스테이션을 사용하지 않을 때도 언제든지 나타날 수 있습니다. 새로운 문제가 발생하면 Crashlytics 대시보드에 실시간으로 우선순위에 따라 표시될 뿐만 아니라 새로운 문제가 발생할 때, 문제로 인해 성능이 저하되는 경우, 그리고 문제의 영향이 갑자기 커지는 경우 이메일 알림도 전송됩니다. 여러분 뒤에 Crashlytics가 있으므로 안심하시고 잠시 물러나 여유롭게 커피 한잔 드셔도 됩니다. Crashlytics는 최근 제공한 앱과 관련하여 문제가 발생하면 알림을 전송해주므로 중요한 비정상 종료를 절대로 놓치지 않을 것입니다.
Firebase Crashlytics와 Cloud Functions for Firebase의 통합
Crashlytics의 많은 강력한 기능을 Firebase에 도입한 것 외에, 우리는 플랫폼의 다른 부분에도 Crashlytics를 통합하는 작업도 진행하고 있습니다. 이제, Cloud Functions for Firebase를 트리거하기 위한 이벤트 소스로 Crashlytics 데이터를 활용할 수 있습니다. 이번 통합을 통해 중요한 앱 흐름(예: 구매 흐름)에 영향을 미치는 문제를 팀의 엔지니어나 Slack 채널에 직접 전달하는 워크플로를 자동화할 수 있습니다. 이런 식으로 긴급한 문제가 즉각적이고도 적절하게 모니터링되고 에스컬레이션되도록 할 수 있습니다.
또한, 안정성 데이터를 새로 디자인된 Firebase 콘솔의 다양한 영역에서 함께 노출합니다. 개발자 여러분은 최고 수준의 안정성을 유지하기 위해 여러 페이지 사이에서 탐색할 필요가 없습니다. 이제는 Crashlytics 데이터를 프로젝트 개요 페이지, Firebase용 Google 애널리틱스 대시보드는 물론, 최신 릴리스 섹션에서도 볼 수 있습니다.
앞으로 예정된 더욱 흥미로운 업데이트
Crashlytics의 이번 베타 출시는 최고의 Fabric과 Firebase의 기능을 결합하는 단계의 시작에 불과합니다. 고객은 이미 Google의 플랫폼을 함께 사용하여 놀라운 결과를 달성하고 있습니다. 일례로, 만남을 갖기에 최고의 날짜와 시간을 찾는 데 도움이 되는 앱인 Doodle을 살펴보도록 하겠습니다. Doodle은 Crashlytics 및 원격 구성을 사용해 앱을 새롭게 디자인하고 사용자 유지율과 참여율을 높였습니다.
이제부터 신규 및 기존 Firebase 고객은 Crashlytics를 사용해야 합니다. Crashlytics가 최고의 Firebase용 오류 보고 도구이기 때문입니다. 신규 Firebase 고객은 g.co/firebase/optin을 방문하여 Crashlytics 사용을 시작할 수 있으며, 기존 오류 보고 고객은 오류 보고 대시보드의 배너를 클릭하시면 됩니다. 우리는 계속해서 Crashlytics를 발전시켜 나갈 것이며 여러분의 피드백을 손꼽아 기다리고 있습니다!
이미 Fabric에서 Crashlytics를 사용하고 계시다면 현재 조건으로 충분하십니다. 따라서 아직은 마이그레이션할 필요가 없습니다. Fabric 앱에서 Firebase Crashlytics를 이용할 수 있는 방법에 대한 흥미로운 소식을 곧 알려드릴 예정입니다.
기존 GoogleApiClient 방식 대신, 더욱 느슨하게 결합된 API 클라이언트 사용으로 변경됨에 따라 상용구 코드가 줄어들고 사용 패턴이 더욱 명확해지고 스레드 안전성이 확보되는 이점이 있습니다. 현재 게임을 API 클라이언트로 마이그레이션하는 경우 다음 자료를 참고하시기 바랍니다.
올해 초 Fabric 구성원들이 Firebase와 함께 하기로 했을 때, 우리는 앱을 개발하는 과정에서 일반적으로 발생하는 문제를 해결하는 플랫폼을 제공함으로써 여러분과 같은 개발자들이 멋진 사용자 환경을 만드는데 집중하게 하자는 공통된 목표를 달성하는 것에 뜻을 모았습니다.
많은 영역 중에서도 Fabric이 뛰어난 한 가지는 바로 콘솔과 대시보드였습니다. 우리는 지난 몇 달 동안 Fabric과 협력하여 Fabric과 Firebase에서 가장 뛰어난 부분을 하나로 합치려는 노력을 해왔습니다. 오늘, 우리는 Firebase 콘솔에 대한 몇 가지 개선 사항을 알려드리고자 합니다.
새롭게 설계된 탐색 기능
우리는 먼저 개발팀이 작업하는 방식을 더욱 정확히 반영하기 위해 탐색 기능을 새로 설계하는 작업부터 시작했습니다. 그래서 Firebase 제품을 네 개 그룹, 즉 개발, 안정성, 분석 및 성장으로 묶었습니다. 기존에 Firebase 콘솔에 표시되었던 제품들은 모두 그대로 표시되며, Firebase 플랫폼에서 제공하는 여러 제품들을 더욱 간단히 탐색할 수 있게끔 각 항목들을 재구성했습니다.
새로운 프로젝트 홈
몇 가지 중요 측정항목을 전면과 중심에 표시하도록 Firebase 콘솔의 프로젝트 홈 화면도 다시 설계했습니다. 이제는 Firebase에서 프로젝트를 처음 열 때 네 개의 주요 측정항목, 즉 30일간 비정상 종료가 발생하지 않은 사용자 비율, 30일간 비정상 종료 발생 횟수, 일일 활성 사용자 수 및 매월 활성 사용자 수와 함께 시간 경과에 따라 이러한 추세를 표시하는 그래프가 표시됩니다. 연구 조사를 수행한 결과 개발자는 이 네 가지 측정항목 중 하나를 찾는 데 대부분의 시간을 쓰고 있다는 사실을 확인했으므로 프로젝트 홈 방문 페이지에서 이러한 측정항목에 손쉽게 액세스할 수 있게 했습니다.
Latest Release
많은 사랑을 받은 또 다른 Fabric 콘솔 기능은 Latest Release 섹션입니다. 이 대시보드에서는 최신 앱 출시에서 가장 중요한 통계 정보 일체를 제공하므로 무엇이 잘 진행되고 있는지, 무엇을 롤백해야 하는지 빠르게 파악할 수 있습니다. Latest Release 섹션은 새로 설계된 Firebase 콘솔의 Analytics 섹션 하위에서 찾아볼 수 있습니다.
업데이트된 Analytics 대시보드
오늘부터 Analytics 대시보드가 궁금한 사항을 쉽게 이해할 수 있도록 단순한 카드로 구성된 것을 볼 수 있을 것입니다. 'DAU' 또는 '사용자 유지 집단(코호트)'과 같은 용어를 기준으로 데이터를 구성하면 탐색하기 어렵기 때문에 "내 사용자가 어디에 참여하는가?" 또는 "사용자를 얼마나 잘 유지하고 있는가?"와 같이 앱과 관련하여 궁금해하는 사항을 기준으로 대시보드를 다시 구성했습니다. 연구 조사 결과 사용자 중 90%가 이 설계를 선호하는 것으로 확인되었으며 여러분도 이 설계가 유용하다는 점을 확인하시게 되기를 바랍니다!
실시간 정보
Fabric의 동료들과 여러 개발자들로부터 들은 의견을 통해 실시간 정보 확보가 중요하다는 점을 알게 되었습니다. 새로운 앱 출시 여부를 추적하거나 버그 수정 상태를 모니터링하는 것과 관계없이 앱에서 어떤 일이 일어나고 있는지 실시간으로 파악할 수 있어야 하며, 이에 따라 변경사항을 반영하거나 작업의 우선 순위를 지정할 수 있어야 합니다.
이를 위해, 새로운 Analytics 대시보드에 표시되는 카드와 콘솔의 Latest Release 섹션에 비정상 종료 및 활성 사용자에 대한 실시간 데이터를 추가되었습니다. 이는 단지 첫 시작일 뿐입니다. 앞으로 계속해서 Firebase 콘솔의 나머지 부분에서도 실시간 데이터를 더 많이 확인할 수 있도록 지원할 계획입니다.
추론을 위해, 모바일 플랫폼에서 신속하게 실행할 수 있도록 최적화된 TensorFlow Lite 작업 세트로 훈련된 프로젝션 모델이 컴파일된 후 기기에서 바로 실행됩니다. 온디바이스 대화형 모델에 대한 TensorFlow Lite 추론 그래프는 다음과 같습니다.
온디바이스 대화형 모델에 대한 TensorFlow Lite 실행.
오늘 출시되는 오픈소스 대화형 모델(코드와 함께 출시)은 위에서 설명한 결합 ML 아키텍처를 사용하여 완벽히 훈련된 모델입니다. 오늘 출시에는 데모 앱도 포함되어 있으므로 휴대기기에서 원터치 스마트 회신 기능을 쉽게 다운로드해 사용해 보실 수 있습니다. 이 아키텍처를 통해 애플리케이션 요구 사항을 기준으로 모델 크기와 예측 품질을 손쉽게 구성할 수 있습니다. 여기서 이 모델이 올바른 효과를 발휘하는 샘플 메시지 목록을 확인할 수 있습니다. 시스템에서는 채팅 대화에서 관찰된 인기 있는 응답 인텐트에서 학습되고 컴파일된 고정된 세트를 통해 회신 제안을 폴백할 수도 있습니다. 기본 모델은 Google이 해당 앱에서 Smart Reply 응답에 사용하는 모델과 다릅니다1.
대화형 모델 이외의 옵션
흥미롭게도, 위에서 설명한 ML 아키텍처에서는 기본 모델을 유연하게 선택할 수 있습니다. 우리는 이 아키텍처를 여러 기계 학습 접근 방식과도 호환되도록 설계했습니다. 예를 들어, TensorFlow 딥 러닝에 사용하는 경우 기본 모델에 대해 경량 신경망(ProjectionNet)을 학습하는 반면, 다른 아키텍처(ProjectionGraph)는 신경망 대신 그래프 프레임워크를 사용하는 모델을 나타냅니다.
결합 프레임워크는 여러 가지 ML 모델링 아키텍처를 사용하는 작업에 대해 경량의 온디바이스 모델을 훈련하는 데 사용할 수도 있습니다. 일례로서, 우리는 동적 프로젝션 작업으로 구성된 단순한 프로젝션 아키텍처 및 완전히 연결된 몇 가지 좁은 계층이 결합된 트레이너 모델에 대해 복잡한 피드 전달 또는 반복 아키텍처(예: LSTM)를 사용하는 ProjectionNet 아키텍처를 도출했습니다. 전체 아키텍처는 TensorFlow에서 역전파를 사용하여 완벽하게 훈련되며 훈련을 마치고 나면 간결한 ProjectionNet이 추론에 직접 사용됩니다. 우리는 이 방법을 사용하여 모델 크기를 상당히 축소시키고(최대 몇 자릿수 이상 축소) 여러 시각적 및 언어 분류 작업(몇 가지 예는 여기를 참조)에 대한 정확성과 관련하여 높은 성능을 실현하는 소형 ProjectionNet 모델을 성공적으로 훈련했습니다. 마찬가지로 반지도학습 설정에서도 그래프 학습 프레임워크를 사용하여 다른 경량 모델을 훈련했습니다.
온디바이스 모델 훈련을 위한 ML 아키텍처: 딥 러닝을 사용하여 훈련된 ProjectionNet(왼쪽)과 그래프 학습을 사용하여 훈련된 ProjectionGraph(오른쪽).
우리는 앞으로도 계속해서 TensorFlow Lite 모델을 향상하고 업데이트된 모델을 오픈소스로 출시할 예정입니다. 이러한 ML 아키텍처를 사용하여 학습된 출시 모델(및 향후 모델)은 많은 자연어 및 컴퓨터 버전 애플리케이션에 재사용하거나 머신 인텔리전스 실현을 위해 기존 앱에 연결할 수 있을 것입니다. 기계 학습 및 자연어 처리 커뮤니티에서 이를 바탕으로 우리가 아직 생각하지 못한 새로운 문제 및 활용 사례를 처리할 수 있게 되기를 바랍니다.
감사의 말 Yicheng Fan 씨와 Gaurav Nemade 씨가 이 작업에 막대하게 기여했습니다. Rajat Monga, Andre Hentz, Andrew Selle, Sarah Sirajuddin과 TensorFlow 팀의 Anitha Vijayakumar, 그리고 Robin Dua, Patrick McGregor, Andrei Broder, Andrew Tomkins과 같은 분들은 물론 Google Expander 팀에게도 감사의 인사를 전합니다.
1 출시된 온디바이스 모델은 휴대폰 및 웨어러블 기기에서 지연 시간이 짧은 소규모 애플리케이션에 최적화할 목적으로 훈련되었습니다. 하지만 Google 앱의 Smart Reply 예측은 그보다 크고 복잡한 모델을 사용하여 생성되었습니다. 또한, 프로덕션 시스템에서는 부적절한 콘텐츠를 감지하도록 훈련된 여러 분류자를 사용하며 추가 필터링 및 조정을 적용하여 사용자 환경 및 품질 수준을 최적화하고 있습니다. 오픈소스 TensorFlow Lite 버전을 사용하는 개발자는 최종 애플리케이션에 이와 같은 방법도 따를 것을 권장합니다.↩
운전은 우리의 일상 활동에 있어 필수적인 부분입니다. 따라서 Google에서는 어떻게 하면 Android 기기를 Google 사용자가 사용하기에 더 적합하고 안전하게 만들 수 있을지 고심하는 데 많은 시간을 할애합니다. 운전에 방해가 되지 않도록 하고 개방적인 에코시스템을 빌드하여 안전이 최우선인 스마트폰 환경을 구현할 수 있을까 하는 고심 말입니다.
우리는 최근에 새로 발표한 Pixel 2세대 기기에서 운전 중 알림 일시중지 기능을 선보였습니다. 운전 중 알림 일시중지 기능을 사용하면 운전할 때 기기가 자동으로 알림 일시중지 모드로 전환됩니다. 이 모드에서는 수신 메시지와 알림이 무음 처리되지만 수신 전화, 내비게이션 안내 및 음성 상호작용은 연결된 차량 블루투스를 이용해 계속 받을 수 있습니다. 이 제품은 운전 중 주의를 산만하게 할 요소를 최대한 줄이는 동시에 사용자가 계속해서 원활하게 내비게이션 또는 이와 유사한 다른 앱은 방해받지 않고 사용할 수 있도록 설계되었습니다.
이면을 살펴보면, 이 제품은 여러 센서, 블루투스 및 와이파이에서 저출력 신호를 사용하여 사용자가 운전 중일 때를 감지하는 AI 기반 온디바이스 동작 인식을 사용합니다. 동작 인식 기능은 Android 센서 허브를 사용하여 짧은 지연 시간, 낮은 전력 및 정확한 운전 감지를 보장합니다.
이것이 바로 우리가 나아가야 할 다음 단계이지만 앞으로도 갈 길이 멉니다. 내년 초에는 산만한 요소가 없는 운전 환경을 빌드하기 위해 운전 중 알림 일시중지 기능에서 사용되는 동일한 API인 Activity Recognition Transition API를 출시할 예정입니다.
보내주신 피드백에 감사드리며, 제품의 진화에 따라 계속 여러분의 의견을 경청할 것입니다.
운전 중 알림 일시중지 기능 설정에 관해 궁금한 사항이 있으시면 고객센터를 통해 확인하시기 바랍니다.
Tolerance: 이 허용치 슬라이더를 통해 허용되는 오차 정도를 낮음, 보통 또는 높음으로 지정할 수 있습니다. 낮은 허용치에서는 사용자 모집단이 더 작아지지만 오차에 대한 위험도 낮아집니다. 이와 유사하게, 높은 허용치에서는 사용자 모집단이 더 커지지만 오차 위험도 높아집니다. 'churn' 경우에는 이탈할 것으로 예측되지만 실제로는 앱을 계속 사용하는 사용자를 오차의 예로 들 수 있습니다.
Target Users: 이 작업에서는 해당 사용자 그룹에 대해 Remote Config 또는 Notifications 를 선택할 수 있는 드롭다운이 제공됩니다. 이 옵션은 인앱 인센티브를 제공하기 위한 몇 가지 유용한 지침을 보여주는 링크도 제공합니다.
Remote Config를 선택하면 해당 모집단에 대해 설정하고 싶은 원격 구성 매개변수를 지정하고 그에 대한 값을 지정할 수 있는 새 화면이 표시됩니다. 예를 들어, 게임을 빌드했는데 많은 사람들이 이탈한데다 게임 플레이가 너무 어렵다는 피드백이 온다면 난이도에 대한 원격 구성 변수를 설정할 수 있을 것입니다. 그러면 이탈할 가능성이 높은 사용자라도 기본값을 낮게 설정하여 좀 더 쉽게 게임을 즐기도록 유도할 수 있습니다.
Notifications를 선택하면 Firebase 클라우드 메시징을 사용하여 전송할 메시지를 작성할 수 있는 익숙한 작성기가 표시됩니다. 더불어 타겟 잠재고객을 선택할 수 있는 일반적인 옵션 외에도, 사용자 세그먼트로서 예측된 사용자 그룹도 미리 채워지게 됩니다.
이를 통해 해당 사용자 그룹으로 알림이 전달되도록 할 수 있습니다. 예를 들어, 이탈 위험이 있는 사용자에 대해 앱을 계속 사용하도록 유도하는 알림을 보낼 수 있습니다.
자신만의 예측 생성. 기본 제공되는 예측 카드로만 제한되지 않습니다. 당연히 앱에서 설정하는 사용자설정 이벤트를 기반으로 자신만의 예측을 생성할 수도 있습니다. 이 경우, 예측을 생성할 수 있는 카드가 표시됩니다.
이 카드를 선택하면 이벤트가 발생할 시기 또는 발생하지 않을 시기에 대한 예측을 생성할 수 있습니다. 이는 해당 전환 이벤트에 참여할 가능성이 큰 사용자의 식별에 도움이 됩니다.
예를 들어, 위 사례에서는 사용자가 게임에서 레벨이 올라갈 때마다 level_up 전환 이벤트가 기록됩니다. 따라서 레벨이 올라갈 수 있는 플레이어에 대한 예측을 생성하고 그들에게 게임을 계속할 수 있도록 인센티브를 제공할 수 있습니다.
그러면 예측을 저장한 후 시간이 지남에 따라 기본 제공되는 카드와 같은 방식으로 Firebase 콘솔에서 카드에 데이터가 채워집니다.
알림과 원격 구성으로 사용자를 타겟팅하는 옵션을 포함하여 다른 카드와 같은 방법으로 이 카드를 사용할 수 있습니다.
Firebase Predictions는 베타 제품이며 우리는 계속해서 이에 대한 작업을 하고 향상해 나갈 것입니다. 궁금한 점이나 피드백이 있으면 알려주시기 바랍니다. 버그 및 제품과 관련한 제안 사항은 firebase.google.com/support로 알려주시기 바랍니다.
firebase.google.com/products/predictions/에서 Firebase Predictions에 대한 자세한 사항을 알아보거나 여기서 Google 문서를 직접 확인해 보실 수 있습니다.
그럼 전화번호 선택기를 제공하는 방법과 이 후 SMS Retriever API를 활용해, 서버로부터 인증 코드를 요청하는 방법을 살펴보겠습니다. 결과적으로 안드로이드 디바이스 상에서 사용자 입력 과정 없이 자동으로 인증 코드를 수신하여 파싱할 수 있습니다.
참고: 시작하기 전에 전화 번호가 있고, SMS를 수신할 수 있으며, Google Play Service 10.2.x 이상이 설치된 기기에서 아래 기능을 테스트할 수 있습니다.
Phone Selector를 사용하여 전화번호 가져오기
첫 번째 단계에서는 사용자가 앱 내에서 SMS 인증을 시작하도록 합니다. 앱에서 전화번호를 입력하라는 메시지를 사용자에게 표시합니다. 다음과 같이 Phone Selector를 사용해 이 기능을 쉽게 구현할 수 있습니다.
// Construct a request for phone numbers and show the picker
private void requestHint() {
HintRequest hintRequest = new HintRequest.Builder()
.setPhoneNumberIdentifierSupported(true)
.build();
PendingIntent intent = Auth.CredentialsApi.getHintPickerIntent(
apiClient, hintRequest);
startIntentSenderForResult(intent.getIntentSender(),
RESOLVE_HINT, null, 0, 0, 0);
}
HintRequest 빌더는 전화번호 식별자가 필요하다는 사실을 Play Service에 알립니다. 그 후, 사용자가 전화번호를 선택할 수 있는 Play Service 대화상자를 표시하기 위한 인텐트를 만듭니다. 이 API는 어떠한 사용 권한도 요구하지 않고, 휴대폰 또는 Google 계정에서 얻을 수 있는 번호를 사용자가 선택할 수 있도록 표시합니다.
사용자가 전화번호를 선택하면 최신 버전의 Play Service를 실행하는 기기에서 E164 형식으로 onActivityResult에서 애플리케이션에 이 전화번호가 반환됩니다. 어떤 경우에는 휴대폰에 따라 전화번호를 가져오지 못할 수도 있으므로 자격 증명이 null이 아닌지 여부를 확인해야 합니다. 전화번호가 없으면 사용자가 수동으로 입력할 수 있는 방법을 제공할 필요가 있습니다.
// Obtain the phone number from the result
@Override
public void onActivityResult(int requestCode, int resultCode, Intent data) {
super.onActivityResult(requestCode, resultCode, data);
if (requestCode == RESOLVE_HINT) {
if (resultCode == RESULT_OK) {
Credential credential = data.getParcelableExtra(Credential.EXTRA_KEY);
// credential.getId(); <-- E.164 format phone number on 10.2.+ devices
}
}
}
이제, 사용자 전화번호를 확인했습니다. 이 방법이 유용하기는 하지만, 개발자는 해당 사용자가 이 전화번호를 소유하고 있는지 인증해야합니다. 예를 들어, 이 번호를 사용하여 다른 사용자와 메시지를 주고받거나 이 번호로 사용자 자신의 신원을 확인할 수 있는지 여부를 확인하고 싶을 것입니다.
SMS Verification API를 활용하여 전화번호 인증
전화번호 소유 여부를 확인하는 간단한 방법은 일회성 인증 코드를 포함한 SMS를 해당 번호로 보내고 앱에 입력하도록 하는 것입니다. SMS Verification API는 앱이 들어오는 SMS를 수신할 수 있는 기능을 제공합니다. 그러면 앱이 이렇게 이 SMS에서 자동으로 코드를 파싱할 수 있습니다.
앱은 다음과 같이 SmsRetrieverClient를 구현합니다..
SmsRetrieverClient client = SmsRetriever.getClient(this /* context */);
Task<Void> task = client.startSmsRetriever();
task.addOnSuccessListener(new OnSuccessListener<Void>() {
@Override
public void onSuccess(Void aVoid) {
// successfully started an SMS Retriever for one SMS message
}
});
task.addOnFailureListener(new OnFailureListener() {
@Override
public void onFailure(@NonNull Exception e) {
});
);
그 후, 작업을 시작하기만 하면 됩니다. on Success 리스너뿐만 아니라, 문제가 발생한 경우 이를 처리하기 위한 on Failure 리스너도 포함되어 있습니다. SMS Retriever를 시작한 후에는 사용자의 전화번호를 서버로 보내고 메시지를 생성하여 해당 번호로 보내기 위한 워크플로를 시작해야 합니다.
이 메시지는 특정 방식으로 구성되어야 합니다. 메시지는 SMS 메시지 크기에 맞아야 하므로, 140바이트를 초과할 수 없습니다. '<#>' 또는 두 개의 연속되고 폭이 없는 공백 문자(U + 200B)를 특정 접두사로 사용하여 시작해야 합니다. 자세한 내용은 해당 문서를 참조하세요. 아래의 설명과 같이 앱을 식별하는 11자 길이의 해시로 끝나야 합니다.
예:
<#> Use 123456 as your verification code in Example App!
FA+9qCX9VSu
일회성 인증 코드는 어떠한 문자열이든 가능하며, 단순하게 임의의 숫자를 생성해도 됩니다. 메시지는 여기에 제시된 절차에 따라 판별되는 해시로 끝나야 합니다. Google Play Service는 이 해시를 사용하여 인증 메시지에 해당하는 앱을 결정합니다. 앱 패키지 및 서명 인증서용으로 이 해시를 한 번만 생성하면 됩니다. 이 해시는 변경되지 않으며 클라이언트 앱에서 제공되지 않습니다.
그러면 서버가 기존에 구축한 SMS 인프라 또는 서비스를 사용하여 휴대폰으로 메시지를 보낼 수 있습니다. 이 메시지가 수신되면 Google Play Service가 메시지의 텍스트를 포함하는 인텐트를 브로드캐스트합니다. 코드는 다음과 같습니다.
public class MySMSBroadcastReceiver extends BroadcastReceiver {
@Override
public void onReceive(Context context, Intent intent) {
if (SmsRetriever.SMS_RETRIEVED_ACTION.equals(intent.getAction())) {
Bundle extras = intent.getExtras();
Status status = (Status) extras.get(SmsRetriever.EXTRA_STATUS);
switch(status.getStatusCode()) {
case CommonStatusCodes.SUCCESS:
String message = (String) extras.get(SmsRetriever.EXTRA_SMS_MESSAGE);
break;
case CommonStatusCodes.TIMEOUT:
break;
}
}
}
}
브로드캐스트 리시버의 onReceive에서 추가 항목을 얻고 그곳에서 상태를 확인합니다. 메시지가 성공적으로 수신된 경우, 추가 항목에서 메시지를 확인 할 수 있습니다. 여기에서 인증 코드를 파싱하고 서버로 다시 전송하여 전화번호 소유 여부를 확인할 수 있습니다.
이 API를 일찍 사용해 본 파트너들은 긍정적인 반응을 보이고 있습니다. 다음은 이들 파트너의 사용 후기를 일부 발췌한 내용입니다.
Twilio는 안드로이드 SMS 인증이 그 어느 때보다도 쉬워졌다는 사실을 확인하고는 이에 대한 내용을 블로그에 올렸습니다.
"전화번호를 사용해 사용자 계정을 등록하고 식별하는 안드로이드용 모바일 앱을 빌드하는 개발자라면 안드로이드용 Twilio Verification SDK를 꼭 사용해 보세요. 그러면 매끄럽고 안전하고 쉬운 가입 절차 제공 문제를 그 어느 때보다도 빠르게 해결하실 수 있을 겁니다." - Simil Thorpe, Twilio의 제품 소유자
Authy는 이러한 API가 많은 변경 사항을 수행할 필요 없이 기존의 SMS 인프라와 잘 연동된다는 사실에 만족감을 표시했습니다.
"Phone Selector와 SMS Retriever를 Authy 2FA 앱에 추가하면 애플리케이션에 필요한 높은 수준의 보안을 유지하는 동시에 사용자에게 놀라울 정도로 뛰어난 UX를 제공할 수 있습니다." - Serge Kruppa, Authy 엔지니어링 책임자
Telesign은 동일한 백엔드 프레임워크에서 UX가 향상되고 보안이 강화되며 전환율이 증가한다는 점을 확인했습니다.
"번거로운 부분이 줄어든 이러한 인증 모드를 통해 얻을 수 있는 유의미한 장점 중 하나는 고객이 사용자 가입 및 등록 과정에서 전환율이 증가하는 것을 눈으로 볼 수 있다는 점입니다.
Google Play Service는 SMS 메시지를 해당 메시지 내의 애플리케이션 해시를 기반으로 대상 애플리케이션만 액세스할 수 있도록 허용하므로, 이를 통해 보안 강화라는 이점도 얻을 수 있습니다."- Priyesh Jain(게시물 작성자)
Android는 고급 휴대폰에서 비행기 좌석 시스템에 이르기까지 수십억 개의 기기에서 실행되고 있습니다. Android OS는 이처럼 광범위한 기기에서 제대로 작동하도록 리소스를 공격적으로 관리하는데, 이로 인해 때로는 견고한 앱을 빌드하기가 어렵고 복잡해질 수 있습니다. 이 작업을 좀 더 쉽게 하기 위해, 우리는 Google I/O에서 Architecture Components의 미리보기를 선보임으로써 수명 주기 관리 및 데이터 지속성과 같은 일반적인 작업을 위한 라이브러리와 함께 앱 아키텍처에 대한 지침을 제공했습니다. 이와 함께, 이러한 기본 구성 요소를 통해 더 적은 상용구 코드로 모듈식 애플리케이션을 작성할 수 있으므로 개발자가 쓸데없이 시간을 낭비하는 대신 혁신을 꾀하는 데 집중할 수 있으며, 우리는 앞으로도 이러한 기반을 기초로 앱 빌드가 계속 이루어지기를 바랍니다.
오늘 우리는 Room 및 Lifecycle Architecture Components 라이브러리가 1.0 Stable에 도달했음을 기쁜 마음으로 알려드립니다. 이러한 API는 프로덕션 앱 및 라이브러리에 바로 사용할 수 있으며 앱 아키텍처 및 로컬 저장소와 관련하여 도움을 구하는 개발자들에게 권장합니다(단, 권장 사항일 뿐이지 필수 사항은 아님). Lifecycle은 이제 지원 라이브러리에도 통합되었으므로 AppCompatActivity와 같은 표준 클래스와 함께 사용할 수 있습니다.
우리는 오늘 Stable 버전을 선언하지만 베타 구성 요소가 이미 앱에서 함께 사용되고 있으며 설치 건수가 수십억 건에 이릅니다. Zappos와 같은 주요 개발업체는 다음과 같이 Architecture Components 덕분에 중요한 문제에 더 많은 시간을 할애할 수 있었습니다.
Android Architecture Components 출시 전에는 자체적으로 ViewModel을 구현했었습니다. 로더와 종속성 주입을 사용하여 구성이 변경되는 과정에서 ViewModel을 유지했습니다. 최근에 우리는 Architecture Components ViewModel 구현으로 전환했으므로 이러한 상용구 코드를 더 이상 사용하지 않게 되었습니다. 우리는 설계, 비즈니스 로직 및 테스트에 더 많은 시간을 소비하고 상용구 코드를 작성하거나 Android 수명 주기 관련 문제를 걱정하는 데는 시간을 덜 낭비할 수 있게 되었다는 사실을 확인했습니다.
또한, Activity 수명 주기에 직접 후크되는 LiveData를 사용하기 시작했습니다. LiveData를 사용하여 네트워크 데이터를 검색하고 표시하므로 네트워크 호출 구독 관리에 대해 더 이상 염려할 필요가 없게 되었습니다.
- David Henry, Zappos의 Android 소프트웨어 엔지니어
Architecture Components는 개발자들이 뛰어난 사용 환경을 빌드하는 데 집중할 수 있도록 몇 가지 일반적인 문제를 없애주는 단순하고 유연하며 실용적인 접근 방식을 제공합니다. 이는 앱 아키텍처에 대한 지침에 따라 함께 연결되는 핵심 구성 요소를 기반으로 합니다.
Lifecycle
모든 Android 개발자는 Activity를 시작, 중지 및 제거할 때 운영체제 문제를 다루어야 합니다. 즉, 수명 주기를 거치면서 UI를 업데이트하는 데 사용되는 observable과 같은 구성 요소의 상태를 관리해야 합니다. Lifecycle을 사용하면 자체적인 수명 주기를 관리하는 수명 주기 인식 구성 요소 를 생성할 수 있으므로 누수나 비정상 종료 문제가 발생할 가능성이 줄어들게 됩니다. Lifecycle 라이브러리는 LiveData와 같은 다른 Architecture Components의 기반입니다.
LiveData
LiveData는 데이터를 유지하고 업데이트를 제공하는 수명 주기 인식 observable입니다. UI 코드는 변경 사항을 구독하고 LiveData에 해당 Lifecycle에 대한 참조를 제공합니다. LiveData는 수명 주기를 인식하므로 해당 Lifecycle이 시작되거나 재개될 때 업데이트를 제공하지만 LifecycleOwner가 제거될 때 업데이트 제공을 중지합니다. LiveData는 더욱 안전하고 성능이 좋은 반응형 UI를 간단하게 빌드할 수 있는 방법입니다.
ViewModel
ViewModel은 Activity 및 Fragment와 같은 수명 주기와 연결된 엔터티로부터 로직 및 뷰 데이터에 대한 소유권을 분리합니다. ViewModel은 연결된 Activity 또는 Fragment가 영구적으로 제거될 때까지 유지됩니다. 즉, 회전으로 인해 Fragment가 다시 생성되는 등의 이벤트가 발생해도 뷰 데이터가 유지됩니다. ViewModel은 일반적인 수명 주기 관련 문제를 해결할 뿐만 아니라 더욱 모듈화되고 테스트하기가 더욱 쉬운 UI를 빌드하는 데에도 도움이 됩니다.
Room
거의 모든 앱이 데이터를 로컬 위치에 저장할 필요가 있습니다. Android에서는 버전 1부터 플랫폼에 SQLite를 번들로 포함해 제공하고 있지만 이를 직접 사용하기란 무척 어려울 수 있습니다. Room은 더 적은 상용구 코드로 SQlite의 기능을 완벽히 활용할 수 있는 단순한 객체 매핑 계층입니다. 컴파일 시간 쿼리 검증 및 기본 제공 마이그레이션과 같은 기능을 통해 더욱 쉽게 강력한 지속성 계층을 빌드할 수 있는 동시에, LiveData와의 통합을 통해 Room은 데이터베이스가 지원되고 수명 주기가 인식되는 observable을 제공할 수 있습니다. Room은 로컬 저장소를 관리하는 데 필요한 단순성, 강력한 기능 및 견고성을 모두 아우르고 있으므로 꼭 한번 사용해 보시기를 바랍니다.
앱 아키텍처에 대한 가이드 및 기타 등등
마지막으로, 모든 개발자에게 적용되는 핵심 원리와 Architecture Components를 함께 사용하기 위한 구체적인 지침을 제공하는 앱 아키텍처에 대한 가이드를 작성했다는 점도 알려드립니다. 우리는 개발자들로부터 명확하고 일관된 지침이 중요하다는 의견을 많이 들어왔기 때문에 현재 해당하는 경우 Architecture Components를 참조하도록 개발자 문서를 업데이트하고 있습니다. 또한, Architecture Components 사이트를 통해 풍부한 동영상, 코드랩 및 샘플 앱도 제공하고 있으며 앞으로 더 많은 것들을 제공할 예정입니다.
계속 지켜봐 주세요.
첫 번째 Architecture Components 세트가 이제 Stable 버전으로 제공되지만 할 일이 더 있다는 것을 알고 있습니다. 지난 몇 달 동안 우리는 개발자 여러분의 피드백을 들어왔으며 이에 따라 기능을 개선했습니다. 또한, RecyclerView를 사용하여 대규모 데이터세트를 처리하기가 너무 어렵다는 내용의 피드백에 따라 최근에 PagedList라고 하는 새로운 Architecture Components를 알파 버전으로 출시했습니다. 이는 시작에 불과합니다. 우리는 더 많은 주요 구성 요소를 개발 중에 있으며, 향후 몇 달 내에 발표할 계획입니다.
Architecture Components와 관련하여 우리가 바라는 바는, 개발자가 휴대기기를 위한 독창적이고 새로운 환경을 제공하는 데 집중할 수 있도록 해드리는 것입니다. 마침내 프로덕션용 Stable 버전으로 이들 Architecture Components를 발표할 수 있게 되어 기쁘게 생각합니다. 우리는 그 과정에서 이처럼 유용한 피드백을 제공해 주신 커뮤니티에 감사하다는 인사를 드리고 싶으며 이 게시물의 댓글을 통해 계속해서 논의가 활발하게 이루어지기를 기대합니다. 끝으로, 이 Stable 버전 출시를 기다려 주신 개발자 여러분, 지금 바로 시작해 보시기 바랍니다.
