한국의 개발자들을 위한 Google for Developers 국문 블로그입니다.
제스처 탐색: 배경 설명
2019년 10월 18일 금요일
<블로그 원문은
이곳
에서 확인하실 수 있으며 블로그 번역 리뷰는 이승민 (Android GDE)님이 참여해 주셨습니다>
게시자: Allen Huang, Rohan Shah - Android UI 제품 관리자
Android Q에서 가장 큰 변화 중 하나는 새로운 제스처 탐색 기능을 도입한 점입니다. 간단히 개요만 설명하자면, 사용자는 새로운 시스템 탐색 모드를 통해 버튼이 아니라 제스처로 뒤로 이동하거나(왼쪽/오른쪽 가장자리 스와이프), 홈 화면으로 이동하거나(아래에서 위쪽으로 스와이프), 기기 도우미를 트리거할 수 있습니다(아래쪽 모서리에서 안쪽으로 스와이프).
시스템 탐색용 제스처 모델을 적용함으로써 앱에 화면의 더 많은 부분을 제공해 더욱 몰입도 높은 환경을 지원할 수 있습니다.
우리는 이 도전 과제에 접근한 방식, 그 이유는 물론이고 일부 절충점까지도 사람들이 들여다볼 수 있도록 하고 싶었습니다. 제스처 탐색과 관련해 다소 지나치게 앞서나가는 면도 있지만, 그 배경 설명을 통해 우리의 프로세스와 사용자 서비스에 있어 개발자와 OEM 생태계의 균형을 맞추는 방법을 어느 정도 이해하실 수 있기를 바랍니다. 앱 개발자로서 이런 변화를 다루는 방법에 관한 자세한 내용을 살펴보고 싶으시면 Chris의
'Going edge-to-edge' 기사 시리즈
를 읽어 보세요.
왜 제스처인가?
앱 개발자와 Android 파트너가 스마트폰에서 새롭고 혁신적인 접근 방식을 시도해 볼 기회를 준다는 점이 Android의 놀라운 점입니다.
지난 3년간, 우리는 휴대용 기기에서 제스처 탐색 패턴이 급증하는 것을 목격했습니다. (제스처 탐색 기술은
2009년경
에 이미 개발되었습니다!)
무척 참신한 아이디어를 시도한 혁신적인 Android 파트너와 Android 앱이 이런 트렌드를 주도했습니다(예:
Fluid NG
,
XDA
).
우리는 이 문제를 더욱 깊이 연구하기 시작하면서 다음과 같이 사용자가 누릴 이점에 집중했습니다.
제스처는 스마트폰을 더욱 빠르고 자연스러우며 인체공학적으로 탐색하는 방법이 될 수 있음
제스처는 그냥 스마트폰을 손에 쥐면서 우연히 조작하게 될 수도 있는 소프트웨어 버튼보다 더 의도적인 조작 방법임
특히 하드웨어가 화면은 더욱 커지고 베젤은 더욱 작아지는 쪽으로 발전하는 추세에서, 제스처 탐색 기술을 활용하면 HOME/BACK 버튼과 이런 버튼이 표시되는 메뉴 모음과 같은 시스템 요소가 앱 콘텐츠를 가리는 양을 최소화함으로써 앱 몰입도를 더욱 높일 수 있음
하지만 제스처 탐색이 장점만 있는 건 아니었습니다. 우리는 다수의 제스처 모드에 다음과 같은 문제가 있다는 점도 확인했습니다.
제스처 탐색이 모든 사용자에게 효과가 있는 것은 아님
제스처 탐색 방법은 버튼 탐색보다 배우기 어렵고 조정이 필요할 수 있음
제스처 탐색이 앱의 탐색 패턴에 방해가 될 수 있음
하지만 무엇보다도
, 우리는 특히 Android 개발자 입장에서는 다양한 Android 스마트폰에 다양한 제스처 탐색 방법이 있을 때 단편화라는 더 큰 문제가 있다는 점을 깨달았습니다.
우리는 작년에 삼성, Xiaomi, HMD Global, OPPO, OnePlus, LG, Motorola 등 많은 파트너와 함께 협력하면서 제스처 탐색이 앞으로 나아갈 수 있도록 표준화하는 작업을 진행했습니다. 일관된 사용자 및 개발자 환경을 보장하기 위해, Android Q 제스처가 새로운 Q+ 기기를 위한 기본 제스처 탐색이 될 것입니다.
이런 제스처 탐색이 특히 손동작과 거동이 불편한 사람을 비롯하여 일부 사용자에게는 기대한 효과를 발휘하지 못한다는 점을 잘 알고 있으므로, 모든 Android 기기에서 3개의 버튼을 이용한 탐색 방법이 계속 탐색 옵션으로 제공될 것입니다.
그렇다면 왜
이런
제스처일까요?
우리는 사용자가 스마트폰을 손에 쥐는 방법, 일반적인 도달 범위, 스마트폰에서 사용자가 가장 많이 사용하는 부분을 파악하기 위한 연구를 시작했습니다. 그때부터 우리는 많은 프로토타입을 만들어 바람직함, 사용 속도, 인체공학 등의 다양한 측면을 테스트했습니다. 그리고 사용자가 이런 시스템을 습득하는 속도, 시스템에 익숙해지는 속도, 시스템에 대해 가지는
느낌
에 관한 폭넓은 연구를 통해 최종 디자인을 확정했습니다.
맨 처음부터 지금까지 유지된 Android 탐색의 고유 요소는 ‘뒤로’ 버튼입니다. ('올바른' 동작이 무엇인지에 관한 수많은 논쟁에도 불구하고) 많은 사용자가 메뉴를 이동하고 학습하기에 Android가 더 쉽다는 점을 인정하며, 뒤로 버튼은 정말 많이 사용됩니다! 사실, 홈 버튼보다도 50% 더 많이 사용되는 게 바로 이 뒤로 버튼입니다. 그래서 우리의 디자인 목표 중 하나는 뒤로 이동 제스처를 인체공학적이고 믿을 수 있으며 직관적으로 만드는 것이었습니다. 우리는 앱 서랍 창이나 최근 항목과 같이 사용 빈도가 더 낮은 다른 탐색 기능보다 뒤로 버튼에 대해 세운 이 목표를 더 우선시했습니다.
아래의 도달 가능성 차트에서 보듯이, 우리는 엄지가 가장 많이, 가장 편안하게 닿는 영역 및 동작과 일치하도록 두 가지 핵심적인 제스처(뒤로 및 홈)를 디자인했습니다.
사용자가 한 손으로만 스마트폰을 쥔 상태에서 편안하게 제스처를 취할 수 있는 곳을 보여주는 스마트폰 화면 히트맵
언급한 바와 같이, 우리는 다양한 제스처 모델의 프로토타입을 만들어 사용자의 평가와, 완전한 Q 모델의 다양한 탐색 패러다임에서 사용자가 여러 테스크를 수행하는데 걸리는 시간을 비교하였습니다. 다음은 테스트 결과를 보여주는 몇 가지 그래프입니다.
다양한 탐색 모드에 대해 인체공학과 한 손 사용에 대한 사용자 평가 비교(높을수록 좋음)
다양한 탐색 모드에서 홈/뒤로 작업을 완료하는 데 필요한 평균 시간 비교(낮을수록 좋음)
다양한 탐색 모드에서 개요/최근 항목 기반 작업을 완료하는 데 필요한 평균 시간 비교(낮을수록 좋음)
사용자들은 평균적으로 대부분의 다른 모델보다 더 빠르게 홈 및 뒤로 이동과 관련된 작업을 수행했으며, 버튼을 사용할 때보다 훨씬 빨랐습니다. 하지만 이 모델은 사용자들이 홈 화면에 비해 이동 빈도가 절반 미만인 개요/최근 항목 앱에 빠르게 액세스할 수 있는 이점을 희생한 대가를 치르고 나온 모델이었습니다.
더욱 정성적인 관점에서 보자면, 사용자들은 Q 모델이 한 손 동작에 더 적합하고 도달하기 쉬운 모델로 봤지만, 여전히 더 많은 사용자에게 버튼이 더욱 인체공학적인 방법으로 봤습니다.
앱 서랍 창과 다른 앱 스와이프
우리는 측면 스와이프가 뒤로 이동 기능을 위한 제스처로서 수많은 절충점 사이에 가장 균형 잡힌 동작이라는 결론에 도달했지만, 특히 그 제스처가 앱에 어떤 영향을 미칠지에 관해 어려운 결정을 내렸다는 점에 주목하는 것이 중요합니다.
예를 들어, 우리는 (Google 앱에 따라) 최대 3~7%의 사용자가 스와이프 동작으로
앱 서랍 창
을 열고 나머지 사용자는 햄버거 메뉴를 눌러 서랍 창을 호출한다는 사실을 알았습니다. 이 앱 서랍 창 스와이프 동작은 현재 뒤로 기능으로 과부하가 걸린 상태라서 일부 사용자는 햄버거 메뉴를 사용하는 데 적응할 필요가 있을 것입니다. 이는 어려운 선택이었지만, 뒤로 이동 기능이 많이 사용된다는 점을 고려해 우리는 가장 효과적인 방법에 맞춰 최적화했습니다.
결코 사용자의 행동을 갈아치우는 게 목표가 아니므로, 우리는 사용자가 서랍 창과 뒤로 이동 동작을 구분할 수 있도록 여러 가지 방법을 시도했습니다. 하지만 사용자가 뒤로 이동하기를 시도하면서 동작이 원하는 결과로 이어질지 확신이 부족할 때, 이 모든 경로는 결국 사용자가 앱 서랍 창을 끌어오는 결과로 이어졌습니다.
앱 서랍 창과 관련된 문제를 넘어, 제스처 탐색 자체가 사람들에겐 큰 변화로 느껴져 적응하는 데 평균 1~3일 정도 걸렸습니다. 특히, 사용자들은 캐러셀에서 오른쪽이나 왼쪽으로 스와이프하는 동작과 뒤로 이동을 트리거하는 동작과 같은 패턴을 올바로 사용하는 데 애를 먹었습니다.
우리는 정성적 연구에서 처음 변화가 생긴 1~3일의 기간이 지난 후에는 사용자들이 능숙하게 변화에 적응해 이 두 가지 동작을 일관되게 구분할 수 있게 되었음을 확인했습니다. 대다수의 사용자가 3개의 버튼을 사용하는 탐색 방식이 여전히 옵션으로 남아 있지만 그 방법으로 다시 돌아가고 싶어 하지는 않았습니다.
추가적인 연구 결과, 사용자가 (다른 많은 탐색을 거쳐) 새로운 시스템 탐색 방식에 익숙해지기까지 분명한 조정 단계가 있는 것으로 나타났습니다. 우리는 Q 모델에서 뒤로 이동 기능의 사용량이 최초 1~3일 동안 감소한다는 점을 발견했습니다. 그 기간이 지난 후, 하루에 뒤로 버튼을 누른 평균 횟수는 결국 버튼 3개 사용 방법 및 우리의 P 탐색 방법과 동일한 것으로 나타납니다.
이 변화가 개발자에게 의미하는 바는?
우리는 제스처 탐색을 통해 Android의 사용자 환경을 더욱 발전시키고 표준화하려고 합니다. 우리가 최종 결정한 모델은 대부분의 사용자에게 최적의 모델이지만, 일부 기존 앱 제스처와 충돌이 발생하여 개발자로서는 사용자가 앱과 상호 작용하는 방식을 조정할 필요가 있다는 의미이기도 합니다. 우리는 Android 개발자에 대한 우리의 책임을 진지하게 받아들이며 이런 변화의 과정에서 도움을 드리고 싶습니다.
제스처 탐색을 지원하는 다음 세 가지 주요 단계가 있습니다.
앱이 전체 화면에 표시될 수 있도록
더 넓은 화면으로 이동
합니다.
시스템 사용자 인터페이스(예: 탐색 메뉴)와
시각적으로 겹치는 모든 부분을 적절히 처리
합니다.
시스템 제스처로 모든 제스처 충돌을 해결합니다.
우리는 방금 Medium에 이러한 단계를 차례대로 자세히 설명하는 '
더 넓은 화면으로 이동
' 시리즈의 첫 번째 글을 게시했습니다. 이 시리즈의 마지막 글에서는 우리가 목격한 일반적인 몇 가지 상황과 앱에서 이런 상황을 최상으로 지원할 수 있는 방법을 다루겠습니다.
피드백을 보내주시는 모든 분께 감사드립니다. 여러분과 나누는 모든 의견과 소통 덕분에 Android Q의 제스처 탐색 환경을 개선할 수 있었고, 더 넓게는 매일같이 Android를 더 나은 모습으로 만드는 데 큰 도움이 되고 있습니다.
코드에서 커뮤니티까지: 개발자가 Devfest를 좋아하는 이유
2019년 10월 14일 월요일
Ricardo Costeira는 포르투갈 코임브라에서 온 소프트웨어 엔지니어입니다. Ricardo는 Google Developer Groups가 전 세계적으로 호스팅하고 개발자 커뮤니티가 주도하는 최대 규모의 이벤트인 DevFest에 작년에 처음으로 참석했습니다. DevFest 2019를 기념하기 위해, Ricardo의 이야기와 그가 코드를 작성하다가 커뮤니티를 찾은 경위에 관한 사연을 공유하고자 합니다.
Ricardo(왼쪽)와 동료 GDG 리드가 DevFest Coimbra를 계획하고 있습니다.
1. 처음에 DevFest에 대한 얘기를 어떻게 듣게 되셨나요? 참여하고자 마음먹은 이유는 무엇이었나요?
2018년 당시 코임브라에서 3년간 살고 있었는데, 소프트웨어 개발자로 일하던 직장의 동료들을 제외하면 친구가 전혀 없었어요. 제 열정을 이해하고 알아봐주는 더 많은 사람과 함께하는 삶을 갈망하다가, 변화를 택해야 할 때라고 결심했어요. 그래서 소셜 미디어를 통해 나와 같은 생각을 가진 더 많은 사람들과 소통할 방법이 있을지 알아봤어요. 마침내, 제 피드에 DevFest가 나타났죠. 대담한 리더, 활기 넘치는 연사, 충만한 창의력이 넘치는 각종 행사로 가득 찬 이 멋진 이벤트가 코임브라에서 열린다는 소식을 어디선가 보게 된 거죠. 커뮤니티와 함께한다는 게 이토록 절 흥분시키리라곤 기대도 못했던 일이랍니다. 그래서 이벤트 입장권을 구했어요.
2. DevFest에서의 첫 경험에 대해 말씀해 주시겠어요?
너무나도 활기차고 들뜨게 해준 경험이었습니다. 처음 행사장에 입장하자 모든 이가 마치 오랫동안 알고 지낸 사이인 것처럼 반갑고 친근하게 제게 말을 걸더군요. 모두 함박웃음을 짓는 표정에 큰 소리로 맘껏 웃고 정말 친절한 분들이었어요. 전 다소 수줍음이 많고 천성적으로 사람들과 쉽게 어울리지 못하고 겉도는 성격인데, 그곳에서 '마치 집처럼 편하고 강한 소속감이 든다'는 느낌에 스스로도 놀랐어요. 바로 그날 밤, 다음에 참석할 수 있는 이벤트가 있을지 찾아봤어요. 그날 이후로, 전 다른 이벤트에도 2번 더 참석했고 6차례 더 참가 등록을 했고, 지금은 GDG 리드가 되었죠. 쉽게 말해, 전 완전히 푹 빠져있어요.
그래서 이 모든 일을 계기로 제게 어떤 변화가 일어났을까요? 솔직히, DevFest 덕분에 제 성격이 바뀌었어요. 지금의 저는 커뮤니티의 일원이고자 하는데, 제 인생에서 새롭게 느끼는 감정이랍니다.
"전 다소 수줍음이 많고 천성적으로 사람들과 쉽게 어울리지 못하고 겉도는 성격인데, 그곳에서 '마치 집처럼 편하고 강한 소속감이 든다'는 느낌에 스스로도 놀랐어요."
3. DevFest 2018에서 경험했던 것 중에서 올해도 다시 보고 싶은 것이 있나요?
부스요. DevFest Coimbra에는 다양한 회사에서 온 사람들과 대화할 수 있는 부스가 있어요. 아주 가까운 곳에서 성장의 모든 기회를 배울 수 있다는 건 정말 설레고 흥분되죠. 제 경우엔, 포르투갈이 얼마나 빨리 성장하고 있는지, 어째서 그 많은 회사가 DevFest에 참가해 최고의 인재들과 대화를 나누고 싶어 하는지 보는 것만으로도 짜릿한 경험이었어요. 이런 관계의 형성을 통해 자신에게 적합한 기회를 찾았을 때 차이를 만들어낼 수 있답니다.
4. DevFest 2019를 앞두고 어떤 점을 가장 크게 기대하고 계세요?
이 행사가 참석하시는 분들에게 영감을 일깨워주는 계기가 되길 바랍니다. 전 최근에 행사 조직 담당자로 참여했다가 제가 DevFest에 첫발을 들여놓으며 가졌던 바로 그 느낌을 신규 참석자들께 안겨드렸던 점이 너무 좋았어요. 동료 GDG 리드들과 함께 일하면서 일종의 경외감에 빠져 있는 참석자들이 함께 어울릴 수 있도록 하면서 그런 의미를 찾게 되었어요.
5. DevFest 2019 참석자에게 조언하실 말씀이 있으세요?
그냥 '안녕하세요?'라고 인사하면 됩니다. 그 한 마디 짧은 인사로 사람들과 얼마나 넓고 깊은 관계를 형성하고 크게 성장하는 계기가 될지 알고 나면 깜짝 놀라실 겁니다. DevFest는 강연이나 워크숍뿐 아니라, 사람들 사이에 진정한 교류가 이루어지는 곳이기도 합니다. 외향적이거나 내성적인 두 부류의 사람을 모두 알아보고 이해하면서 따뜻하게 환영해주는 커뮤니티입니다. 즉, 어떤 사람이든, 어떤 방법으로 코딩하든 상관없이, 바로 당신을 위한 곳이라 할 수 있습니다.
"DevFest는 강연이나 워크숍뿐 아니라, 사람들 사이에 진정한 교류가 이루어지는 곳이기도 합니다."
근처에서 열리는 DevFest를 찾고 싶으세요?
devfest.withgoogle.com
을 확인한 후 우리 커뮤니티에 참여해 다른 개발자를 만나보고 클라우드, Android, Flutter, 머신러닝 등에 관해 알아보세요.
#DevFest #Community
한국에서 열리는 Devfest 목록을 확인하시고 가깝거나 관심 가는 이벤트에 지금 바로 등록해보세요!
서울
10/20
수원
11/05
대전
11/16
캠퍼스
11/16
부산
11/30
송도인천 11/30
TensorFlow 2.0을 출시했습니다.
2019년 10월 10일 목요일
<블로그 원문은
이곳
에서 확인하실 수 있으며 블로그 번역 리뷰는 박해선(MachineLearning GDE)님이 참여해 주셨습니다>
올해 초,
TensorFlow Dev Summit
에서 TensorFlow 2.0 알파 버전을 발표했습니다. 기쁜 마음으로 TensorFlow 2.0의 최종 릴리스 출시를 발표합니다.
여기
에서 TensorFlow 2.0의 설치 방법을 알아보세요.
TensorFlow 2.0은 커뮤니티의 주도로 나온 결과물입니다. 사용자들이 원하는 유연하고 강력하며 어떤 플랫폼에도 배포 가능한 사용하기 간편한 플랫폼입니다. TensorFlow 2.0은 최신 머신러닝 기술을 추구하고 확장 가능한 ML 기반 애플리케이션을 만드는 개발자, 기업, 연구자를 위한 광범위한 도구 생태계를 제공합니다.
TensorFlow 2.0을 사용한 개발
TensorFlow 2.0을 사용하면 ML 애플리케이션을 훨씬 더 쉽게 개발할 수 있습니다.
Keras와 TensorFlow
의 통합,
즉시 실행
(eager execution)(기본 설정), 파이썬 함수 실행(execution)을 통해 TensorFlow 2.0은 Python 개발자에게 최대한 익숙한 애플리케이션 개발 경험을 제공합니다. ML의 경계를 허무는 연구자를 위해 TensorFlow의 저수준 API에 많은 투자를 해왔습니다. 이제 내부에서 사용하는 모든 연산을 외부로 공개하고 변수 및 체크포인트(checkpoint)와 같은 중요한 개념을 위해 상속 가능한 인터페이스를 제공합니다. 이를 통해 TensorFlow를 다시 빌드할 필요 없이 TensorFlow의 내부 구조 위에 시스템을 구축할 수 있습니다.
우리는 클라우드, 웹, 브라우저, Node.js, 모바일 및 임베디드 시스템을 비롯한 다양한 런타임(runtime)에서 모델을 실행할 수 있도록,
SavedModel
파일 형식을 표준화했습니다. 그 덕분에 TensorFlow로 모델을 실행하고,
TensorFlow Serving
으로 모델을 배포하고,
TensorFlow Lite
로 모바일 및 임베디드 시스템에서 모델을 사용하고,
TensorFlow.js
로 브라우저나 Node.js에서 훈련하고 실행할 수 있습니다.
고성능 훈련 시나리오의 경우,
분산 전략(
Distribution Strategy) API
를 사용하여 최소한의 코드 변경만으로 훈련을 분산하고 별도의 구성 없이 바로 우수한 성능을 달성할 수 있습니다. Keras의 Model.fit 메서드와 맞춤 훈련 루프도 분산 훈련을 지원합니다. 현재
다중 GPU 지원
이 제공되며,
여기
서 Google Cloud에서 GPU를 사용하는 방법에 관해 자세히 알아볼 수 있습니다. 향후 릴리스에서 Cloud TPU 지원을 제공할 예정입니다. 자세한 내용은 분산 훈련
가이드
를 확인해 보세요.
TensorFlow 2.0은 GPU에서 성능이 많이 개선되었습니다. 예를 들어
ResNet-50
과
BERT
에서 TensorFlow 2.0은 몇 줄의 코드로 Volta 및 Turing GPU에서 혼합 정밀도(mixed precision)를 사용해 최대 3배 더 빠른 훈련 성능을 제공합니다. TensorFlow 2.0은 TensorRT와 긴밀히 통합되며
향상된 API
를 사용하여 Google Cloud의
NVIDIA T4 Cloud GPU
를 사용한 추론 시 더 나은 사용성과 높은 성능을 제공합니다.
NVIDIA에서 가속 컴퓨팅 소프트웨어 제품 관리 책임을 맡고 있는 Kari Briski 상무이사는 이렇게 말했습니다. "개발자들은 NVIDIA GPU 및 시스템에서 머신러닝을 통해 불과 몇 년 전만 해도 불가능해 보였던 문제들을 해결할 수 있습니다. TensorFlow 2.0은 훌륭한 GPU 가속 기능으로 가득 차 있는데, 커뮤니티에서 향상된 이 도구로 만들어낼 놀라운 AI 애플리케이션을 한시라도 빨리 보고 싶습니다."
TensorFlow에서 모델을 효율적으로 만들기 위해서는 훈련 데이터와 검증 데이터를 손쉽게 얻는 것이 가장 중요합니다. 이를 위해 이미지, 텍스트, 동영상 등의 다양한 데이터 형식을 포함한 방대한 데이터세트에 대한 표준 인터페이스를 제공하는
TensorFlow Datasets
를 제공합니다.
전통적인 Session 기반 프로그래밍 모델이 계속 유지되겠지만, 즉시 실행을 사용한 일반적인 파이썬 개발 방식을 사용하는 것이 좋습니다.
tf.function
데코레이터를 사용하여 코드를 그래프로 변환하여 원격으로 실행하거나 직렬화하고 성능을 최적화할 수 있습니다. 일반적인 파이썬 제어 흐름을 TensorFlow 제어 흐름으로 직접 변환할 수 있는
Autograph
가 이를 보완해 줍니다.
물론, TensorFlow 1.x를 사용자가 2.0으로 이전하기 위한 가이드를 찾고 있다면,
여기
에 알맞은 정보를 게시해 두었습니다. TensorFlow 2.0 릴리스에는 처음 시작할 때 도움이 될만한 자동 변환 스크립트도 포함되어 있습니다.
Google 내부와 TensorFlow 커뮤니티의 많은 사용자와 함께 협력하여 TensorFlow 2.0 기능을 테스트하고 소중한 의견을 통해 많은 도움을 받았습니다. 한 예로서, Google 뉴스 팀은 TensorFlow 2.0으로 BERT 기반의 언어 이해 모델을 출시해
기사 이해 범위를 대폭 넓혔습니다
. TensorFlow 2.0은 새로운 아이디어를 빠르게 구현할 수 있는 유연하고 사용하기 간편한 API를 제공합니다. 모델 훈련과 배포가 기존 인프라에 끊김없이 통합되었습니다.
또한 ML은 파이썬 개발자만을 위한 것이 아닙니다.
TensorFlow.js
를 사용하여 자바스크립트 개발자가 훈련 및 추론 기능을 수행할 수 있으며,
Swift for TensorFlow
라이브러리로 모델을 빌드하기 위한 언어인 Swift에 계속 투자하고 있습니다.
소개할 것이 정말 많습니다. 이를 위해
TensorFlow 2.0의 모든 새로운 기능을 효과적으로 활용하는 방법
에 관한 편리한 가이드를 만들었습니다. TensorFlow 2.0을 보다 더 쉽게 시작할 수 있도록, 우리는
여기
에서 2.0 API를 사용하여 널리 사용되는 여러 가지 ML 모델의 참조 구현을 제공합니다.
그뿐 아니라,
deeplearning.ai
및
Udacity
와 함께 만든 온라인 과정을 확인해 보면 TensorFlow 2.0을 사용하여 애플리케이션을 빌드하는 방법을 배울 수 있습니다.
빨리 시작하려면
Google Cloud의 딥러닝 VM 이미지
를 사용하세요. TensorFlow 2.0 딥러닝 프로젝트를 만드는데 도움이 되도록 사전 구성된 가상 머신으로, 따로 설정할 필요가 없습니다.
자세히 알아보기
TensorFlow 2.0을 다운로드하고 ML 애플리케이션 코딩을 시작하는 방법을 비롯하여, TensorFlow 2.0에 관한 자세한 내용은
tensorflow.org
에서 확인할 수 있습니다. 마지막으로, TensorFlow 2.0과 관련 생태계에 관해 더욱 흥미진진한 각종 발표, 강연, 실습 교육, 프레젠테이션 등을 원하시면, 10월 28일~31일에 캘리포니아 산타클라라에서 열리는
TensorFlow World
에 직접 참가해보세요. 그때 만날 수 있으면 좋겠습니다!
머신러닝으로 버스 지연 예측하기
2019년 10월 2일 수요일
게시자: Alex Fabrikant, Google Research 연구원
원문은
이 곳
에서 확인하실 수 있습니다.
전 세계 수억 명의 사람이 매일 대중교통을 이용해 출퇴근하고 있고, 전 세계 대중교통의 절반 이상을 버스가 담당하고 있습니다. 지구촌의 수많은 도시가 계속 성장함에 따라, 출퇴근하는 사람들은 기다리는 차편, 특히 교통 상황에 따른 영향을 크게 받는 버스 도착 시간의 지연 여부를 정확히 알고싶어 합니다. Google 지도에서 제공하는 대중교통 안내 정보는 수많은 교통 관련 기관에서 실시간으로 제공하는 데이터에 의존하지만, 기술 및 리소스의 제약으로 인해 실시간으로 제공하지 못하는 기관도 많습니다.
현재, Google 지도에서는
버스용 실시간 도착 지연 서비스를 도입
했는데, 애틀랜타부터 자그레브, 이스탄불, 마닐라 등에 이르는 전 세계 수백 개의 도시에서 버스 도착 지연을 예측하는 서비스입니다. 덕분에 6천만 명 이상의 사람이 버스 도착 시간을 더 정확히 알 수 있게 되었습니다.
3주일 전에 인도에서 첫선을 보인
이 시스템은 실시간 자동차 교통 흐름 예측 데이터를 버스 노선 및 정류소 데이터와 결합하여 버스 운행 시간이 얼마나 될지 예측하는 머신러닝 모델로 운영됩니다.
모델의 시작
교통 기관에서 실시간 예측 정보를 제공하지 않는 많은 도시에서는 사람들이 Google 지도 운전 안내 기능을 사용해 버스 지연을 대략적으로 추정하는 현명한 임시방편을 쓴다는 사실을 설문조사를 통해 파악할 수 있었습니다. 하지만 버스는 단순히 덩치가 큰 자동차가 아닙니다. 버스는 정류소에서 정차하고, 일반 자동차보다 가속, 감속, 회전에 시간이 더 걸리면서도 때로 버스 전용 차선처럼 특별한 도로를 사용할 수 있는 특권을 받기도 합니다.
한 가지 예로, 수요일 오후에 시드니에서 버스에 탑승하는 사례를 살펴봅시다. 버스의 실제 운행(파란색)이 공표된 일정(검은색)보다 몇 분 정도 늦어지고 있습니다. 자동차 교통 흐름 속도(빨간색)가 버스 운행에 영향을 주지만(예: 2,000미터 지점에서 감속), 800미터 지점의 정류소에서 정차하는 바람에 일반 자동차에 비해 버스 속도가 상당히 느려지게 됨을 알 수 있습니다.
모델을 개발하기 위해 교통 기관의 실시간 피드에서 받은 데이터를 해당 노선 운행 중 버스 운행 경로에서의 교통 흐름 속도에 맞춰 조정했고, 이를 반영하여 시간의 경과에 따른 버스 위치 시퀀스로부터 훈련 데이터를 추출했습니다. 이 모델은 운행 스케줄 단위의 시퀀스(도로 블록과 정류소 도착)로 분할되며, 각 시퀀스는 버스 운행 스케줄의 한 부분에 해당하고 각 단위에서 시간을 예측합니다. 보고가 자주 이루어지지 않거나 버스가 빨리 움직이거나 블록과 정류소 거리가 짧은 등의 이유 때문에 인접한 한 쌍의 관측 데이터는 대개는 많은 단위에 걸쳐 있게 됩니다.
이 구조는 최근에
음성 처리
,
기계 번역
등에 성공적으로 적용된 것과 같은 신경 시퀀스 모델에 적합합니다. 이 모델은 더 간단합니다. 각 단위에서 시간을 독립적으로 예측하며, 단위별 예측의 합이 최종 출력됩니다. 많은 시퀀스 모델과는 달리, 이 모델에서는 각 단위에서 도출한 결과를 결합할 방법을 학습할 필요, 단위 시퀀스를 통해 state를 전달할 필요도 없습니다. 대신에 시퀀스 구조를 사용하여 공동으로 (1) 개별 단위에서 시간 모델을 훈련하고 (2) 관찰되는 각각의 궤적이 총 시간을 궤적이 걸쳐 있는 많은 단위의 합에 할당하는 'linear 시스템'을 최적화할 수 있습니다.
파란색 정류소에서 출발하는 버스 운행 (a)를 모델링하기 위해, 모델 (b)에서는 파란색 정류소, 세 개의 도로 부분, 흰색 정류소 등에 대해 운행 스케줄 단위에서 지연 예측 값을 합산합니다.
‘위치’ 모델링하기
도로 교통의 지연 외에도, 우리는 모델을 훈련하는 과정에서 버스 노선에 관한 세부 정보뿐 아니라 버스 운행의 위치와 타이밍에 관한 신호도 고려합니다. 소규모 지역 내에서도 모델은 다양한 거리에서 자동차 속도 예측을 버스 속도로 다르게 변환해야 합니다. 아래의 왼쪽 패널에는 한 버스 운행 노선에 대해 모델에서 예측하는 자동차 속도와 버스 속도 간의 비율이 색으로 표시되어 있습니다. 빨간색에 더 가깝고 더 느려지는 부분은 정류소 근처에서 버스가 감속하기 때문에 그렇게 표시될 수 있습니다. 상자로 강조표시한 부분에서 빠른 속도를 나타내는 녹색 구간의 경우, 모델이 버스 전용 회전 차선을 발견했으며 이는 스트리트 뷰(오른쪽)에서도 확인할 수 있습니다. 그런데 이 노선은 우회전이 좌회전보다 느린 호주에 있는 노선으로, 해당 지역의 특색을 고려하지 않는 모델에서는 놓치게 되는 또 다른 측면입니다.
특정 거리, 인근 지역, 도시의 고유한 특성을 포착하기 위해, 운행 스케줄 단위의 지리 정보(도로 또는 정류소의 정확한 위치)가 다양한 축척으로 해당 위치의 삽입 데이터의 합으로 모델에 표시되는 상태에서, 우리는 모델이 다양한 크기의 지역에 대한 표시의 계층 구조를 학습하도록 합니다. 먼저 특수한 사례를 이용해 더욱 세분화된 위치에 대해 점진적으로 더 큰 페널티를 부과하며 모델을 훈련하고, 특징 선택(feature selection)에 대한 결과를 사용합니다. 그와 같이 세분화된 특징이 거의 문제가 되지 않는 교외의 개활지와는 반대로, 이를 통해 100미터의 거리도 버스의 움직임에 영향을 미칠 정도로 충분히 복잡한 지역에서 세분화된 특징이 고려되도록 할 수 있습니다.
또한 훈련 시에 훈련 데이터에는 없었던 지역에 대해 이후에 쿼리가 있을 가능성도 시뮬레이션합니다. 각 훈련 배치에서 예시를 임의로 자른 조각을 선택하고 각 조각에 대해 임의로 선택한 눈금 미만의 지리적 특징은 삭제합니다. 일부 예시는 정확한 버스 노선 및 거리와 함께 유지되고, 다른 예시는 인근 지역이나 도시 수준의 위치만 유지하며, 또 다른 예시에는 아예 지리적 컨텍스트가 없습니다. 그러면 훈련 데이터에 관련 내용이 없거나 부족한 지역에 관한 이후의 쿼리에 대한 모델의 준비 수준을 더 높일 수 있습니다. 우리는 Google 지도가
업무상 붐비는 시간
,
주차 곤란
및 기타 특징에 대해 사용하는 것과 동일한 데이터셋에서 사용자의 버스 이용에 관해 익명화된 추론을 사용하여 훈련 자료의 범위를 확장합니다. 하지만 이 데이터에는 전 세계 버스 노선 대다수가 포함되지 않으므로, 우리의 모델은 새 지역으로 확고하게 일반화해야 합니다.
지역적 특색 학습
도시와 인근 지역은 저마다 다른 생활 리듬으로 움직이므로, 모델이 위치 표시를 시간 신호와 결합할 수 있도록 허용합니다. 버스는 시간에 대해 복잡한 종속성을 가집니다. 예컨대, 화요일 오후 6시 30분에서 오후 6시 45분 사이의 시간대에 일부 인근 지역에서는 러시아워의 교통 혼잡이 진정 기미를 보이는 반면에, 다른 인근 지역에서는 저녁 약속으로 사람들이 분주하게 모여드는 시간대일 수 있고, 또 다른 곳은 완전히 적막한 느낌을 주는 마을도 있을 것입니다. 우리의 모델은 특정 지역의 하루 중 몇 시인지, 일주일 중 무슨 요일인지와 같은 신호의 임베딩을 학습하는데, 이를 위치 표시와 결합하면 자동차 교통량을 통해서는 관찰할 수 없는 러시아워의 버스 정류장 혼잡과 같은 두드러진 지역별 변화를 포착할 수 있습니다.
이 임베딩은 하루의 각 시간대에 4차원 벡터를 할당합니다. 대부분의 신경망 내부 구조와는 달리, 4차원은 거의 시각화하기에 충분하지 않으므로, 모델이 아래와 같은 예술적 렌더링을 통해 이러한 차원 중 세 차원에서 하루의 시간을 어떻게 배열하는지 살펴봅시다. 이 모델은 실은 시간이 순환적이라는 점을 학습하여 시간을 '루프' 형태로 배치합니다. 그러나 이 루프는 시계 앞면의 평평한 원 모양이 아닙니다. 모델은 버스 움직임의 변화에서 많은 특징을 잡아낼 수 없는 '한밤중'이나 '늦은 오전'과 같이, 다른 뉴런이 개념을 쉽게 구분할 수 있는 간단한 규칙을 만들 수 있도록 하는 넓은 굴곡부를 학습합니다. 반면에, 저녁의 퇴근 패턴은 인근 지역과 도시 간에 훨씬 더 큰 차이를 보이며, 모델은 오후 4시부터 오후 9시 사이에 더욱 복잡하고 '찌그러진' 패턴을 생성하는 것으로 보이는데 이를 통해 각 도시의 러시아워 타이밍에 관해 더욱 난해하고 복잡한 추론이 가능합니다.
모델의 시간 표시(4가지 차원 중 3가지)가 루프를 형성하는데, 여기서는 시계의 원주로 재구성했습니다. 오후 4시~9시 및 오전 7시~9시와 같이 위치에 더욱 종속적인 시간 범위는 더 복잡하게 '찌그러지는' 반면에, 오전 2~5시와 같은 특징이 없는 큰 범위는 더 간단한 규칙에 맞게 완만하게 표시됩니다. ( textures.com에서 구한 텍스처와 hdrihaven에서 구한 HDRI 사용한 Will Cassella의)
다른 신호와 함께, 이런 시간 표시를 통해 자동차 속도를 일정하게 유지하더라도 복잡한 패턴을 예측할 수 있습니다. 예를 들어 뉴저지를 관통하는 10km 거리의 버스에 탑승한 경우를 가정하여, 우리 모델에서는 점심시간에 거리로 나오는 인파와 평일의 러시아워를 선택합니다.
종합적으로 살펴보기
모델을 완전히 훈련한 상태에서 위의 시드니 버스 탑승에 관해 학습한 내용을 살펴봅시다. 당일의 자동차 교통 데이터를 기반으로 모델을 실행하면 아래와 같이 녹색으로 예측 결과를 얻을 수 있습니다. 이 모델이 모든 걸 포착하지는 못합니다. 예를 들어 버스는 적어도 31초 이상 정지했지만 800미터 지점에 있는 정류소에서 머문 시간은 10초에 불과합니다. 그러나 우리의 예측 모델이 실제 버스 이동과는 1.5분 이내의 범위에서 오차를 유지하므로, 해당 버스 운행에 관해 운행 스케줄이나 자동차 주행 시간만으로 주어지는 정보에 비해 훨씬 많은 뉘앙스를 포착하는 셈입니다.
앞으로의 여정
현재로선 우리 모델에 한 가지가 없죠? 버스 운행 스케줄 자체 말입니다. 지금까지는 기관에서 제공하는 공식 버스 운행 스케줄을 포함하여 실험한 결과, 예측 결과를 현저히 개선하는 효과는 없었습니다. 어떤 도시에서는 교통 상황의 변동이 워낙 심해 스케줄 계획을 세우려는 시도 자체가 무의미할 수도 있습니다. 반면에 다른 도시에서는 버스 스케줄이 정확히 지켜질 수 있지만, 그건 아마 교통 기관에서 교통 패턴을 신중하게 고려하기 때문일 것입니다. 그리고 우리는 데이터로부터 그러한 점을 추론합니다.
우리는 계속해서 스케줄의 제약 조건과 다른 많은 신호를 더 나은 방식으로 실험하면서 더욱 정확하게 시간을 예측하여 사용자가 더 쉽게 여정을 계획할 수 있도록 하겠습니다. 또한, 우리가 여러분의 편안한 여행길에 유익한 존재이길 바랍니다. 즐거운 여행길 되시길!
감사의 말
이번 작업은 Google Research의 James Cook, Alex Fabrikant, Ivan Kuznetsov, Fangzhou Xu와 Google 지도의 Anthony Bertuca, Julian Gibbons, Thierry Le Boulengé, Cayden Meyer, Anatoli Plotnikov, Ivan Volosyuk가 공동으로 진행했습니다. Senaka Buthpitiya, Da-Cheng Juan, Reuben Kan, Ramesh Nagarajan, Andrew Tomkins에게 감사드리고, 특히 지원과 큰 도움이 된 토론에 아낌없는 성원을 보내주신 Transit 팀에 감사드립니다. 또한 모델의 시간 임베딩을 다시 생각해보는 데에 영감을 주신 Will Cassella에게도 감사의 인사를 드립니다. 시스템 훈련의 기초가 된 교통 데이터 피드를 제공해주신 관련 기관에도 많은 신세를 졌습니다.
Contents
ML/Tensorflow
Android
Flutter
Web/Chrome
Cloud
Google Play
Community
Game
Firebase
검색
Tag
인디게임페스티벌
정책 세미나
창구프로그램
AdMob
AI
Android
Android 12
Android 12L
Android 13
Android 14
Android Assistant
Android Auto
Android Games
Android Jetpack
Android Machine Learning
Android Privacy
Android Studio
Android TV
Android Wear
App Bundle
bootcamp
Business
Chrome
Cloud
Community
compose
Firebase
Flutter
Foldables
Game
gdg
GDSC
google
Google Developer Student Clubs
Google I/O
Google Play
Google Play Games
Interview
Jetpack
Jetpack Compose
kotlin
Large Screens
Library
ma
Material Design
Material You
ML/Tensorflow
mobile games
Now in Android
PC
Play Console
Policy
priva
wa
wear
Wearables
Web
Web/Chrome
Weeklyupdates
WorkManager
Archive
2026
8월
7월
6월
5월
4월
3월
2월
1월
2025
12월
11월
10월
9월
8월
7월
6월
5월
4월
3월
2월
1월
2024
12월
11월
10월
9월
8월
7월
6월
5월
4월
3월
2월
1월
2023
12월
11월
10월
9월
8월
7월
6월
5월
4월
3월
2월
1월
2022
12월
11월
10월
9월
8월
7월
6월
5월
4월
3월
2월
1월
2021
12월
11월
10월
9월
8월
7월
6월
5월
4월
3월
2월
1월
2020
12월
11월
10월
9월
8월
7월
6월
5월
4월
3월
2월
1월
2019
12월
11월
10월
9월
8월
7월
6월
5월
4월
3월
2월
1월
2018
12월
11월
10월
9월
8월
7월
6월
5월
4월
3월
2월
1월
2017
12월
11월
10월
9월
8월
7월
6월
5월
4월
3월
2월
1월
2016
12월
11월
10월
9월
8월
7월
6월
5월
4월
3월
2월
1월
2015
12월
11월
10월
9월
8월
7월
6월
5월
4월
3월
2월
1월
2014
12월
11월
10월
9월
8월
7월
6월
5월
4월
3월
2월
1월
2013
12월
11월
10월
9월
8월
7월
6월
5월
4월
3월
2월
1월
2012
12월
11월
10월
9월
8월
7월
6월
5월
3월
2월
1월
2011
12월
11월
Feed