Google Developers Korea Blog

새로워진 Android Kotlin 코드랩 과정을 만나보세요!

Thursday, October 31, 2019

.post-body span { white-space: normal !important; } <블로그 원문은 이곳에서 확인하실 수 있습니다>

게시자: Jocelyn Becker, Google Developer Training 선임 프로그램 관리자 Kotlin으로 Android 앱을 빌드하는 방법을 배우고 싶으세요? Kotlin Bootcamp for Programmers(프로그래머를 위한 Kotlin 부트캠프) 및 Developing Android apps in Kotlin(Kotlin으로 Android 앱 개발) 코드랩 과정으로 시작해 보세요. Google과 Udacity는 현재 Kotlin 부트캠프와 Kotlin으로 Android 앱을 빌드하는 방법에 대한 동영상 기반 과정을 제공하고 있습니다. 저마다 학습 방법이 다른 분들께 도움을 드리고자, 가이드 기반 코드랩 과정으로 새로 게시했습니다. 올해 250만 명 이상의 사용자가 이와 같은 Google 코드랩을 통해 빌드 작업을 했습니다. Kotlin 부트캠프

Google은 Kotlin 친화적인 Android API와 API 확장 프로그램을 비롯하여, Kotlin으로 Android 앱을 빌드하기 위한 특급 지원을 제공합니다. Kotlin은 자바 프로그래밍 언어 및 라이브러리와 완벽히 상호 운영되고 IntelliJ 및 Android Studio와 함께 포함됩니다. Kotlin 부트캠프 과정에서는 Kotlin 명령문 작성 방법과 같은 기초적인 지식부터 시작해서 기본 제공 함수의 확장과 같은 함수 조작 작업에 이르기까지, Kotlin으로 프로그래밍하기 위해 필요한 모든 내용을 배우게 됩니다. 프로그래밍 방법을 이미 알고 계신 분을 위해, Kotlin 부트캠프에서는 Kotlin으로 Android 앱을 빌드하는 데 필요한 기초 과정을 제공합니다. 지금 바로 Kotlin 부트캠프를 시작해보세요!
Kotlin으로 Android 앱 빌드

Kotlin에 익숙하신 분이라면 Android 앱을 빌드하는 단계로 바로 진행하실 수 있습니다. 이 과정을 통해 'Hello World' 수준의 초보적 프로그래밍에서 세상과 실제로 연결하는 수준으로 나아갈 수 있습니다. 한 화면에서 기본적인 대화식 사용자 인터페이스를 빌드하기 시작해 인터넷을 통해 라이브 서버에서 데이터를 가져오는 멀티스크린 GDG(Google Developer Group) Finder 앱으로 끝을 맺습니다. 그 중간에는 데이터베이스를 위한 Room, 백그라운드 처리를 위한 Work Manager, Navigation 구성 요소 등의 Android Jetpack 구성 요소에 대해 배웁니다. 인기 있는 커뮤니티 라이브러리를 사용하여 이미지 로딩용 Glide, 네트워킹용 Retrofit, JSON 파싱용 Moshi와 같은 공통 작업을 단순화하게 될 것입니다. 이 과정에서는 앱 코드를 더 빠르고 정밀하게 작성하는 데 도움이 되도록 코루틴과 같은 주요 Kotlin 기능을 소개합니다. 각 단원에서, 현실적인 아키텍처를 가진 앱을 만들고 주요 기능을 구현하는 실습을 하게 됩니다. 예를 들어 주사위 굴리기 앱을 배포하는 방법에 대한 학습을 시작합니다. 'Android Trivia' 게임을 빌드하여 탐색을 구현하는 방법을 배우고 수면 추적기 앱을 빌드하여 Room 데이터베이스를 만드는 방법을 배웁니다. 모두 합쳐 10여 개의 앱을 만들고 관련 작업을 하게 되므로, 이 과정을 마치면 스스로 놀라운 앱 아이디어의 실현을 위해 사용할 수 있는 예제 코드 포트폴리오를 보유하게 되는 셈입니다. 지금 바로 시작하세요!

새로운 Android Emulator 도구를 사용한 지속적인 테스트

Monday, October 28, 2019

.post-body span { white-space: normal !important; } <블로그 원문은 이곳에서 확인하실 수 있으며 블로그 번역 리뷰는 노현석(Android GDE)님이 참여해 주셨습니다>

게시자: Lingfeng Yang, Android Studio 팀 개발자들은 종종 일상적인 개발 업무 중에 Android Emulator를 사용해 최신 변경 사항을 빠르게 테스트해 본 후에 커밋하곤 합니다. 그뿐 아니라, 개발자가 지속적 통합(CI) 시스템에서 Emulator를 사용해 더 큰 규모의 자동화 테스트를 합니다. 이런 사용 사례를 더욱 지원하기 위해, 우리는 Android Emulator 컨테이너 스크립트를 오픈소싱하고 다음 두 가지 고충 사항과 관련하여 개발자 환경을 개선하는 노력을 기울이고 있습니다.

Deployability - 원하는 버전의 Android Emulator를 찾아서 실행.

Debuggability - Android Emulator의 원격 인스턴스에서 버그 추적.

Deployability Android는 다양한 하드웨어 및 소프트웨어 구성을 지원하는데, Android Emulator 역시 다르지 않습니다. 하지만 이와 같은 다양한 방식으로 인해 환경 구성에서 오히려 혼동이 생길 수 있습니다. 개발자는 어떻게 Emulator와 시스템 이미지를 구해야 할까요? 어떤 드라이버가 필요할까요? CPU 또는 GPU 가속 유무에 관계없이 어떻게 실행할까요? 그 밖에도 많은 점이 혼란스럽습니다. 이런 점을 해소하기 위해 우리는 다음과 같은 솔루션을 내놓았습니다.

Android Emulator 다운로드 스크립트 - 이 스크립트는 최신 Emulator 이미지(AOSP와 Google Play Service 포함)는 물론이고, (Linux, Mac OS, Windows 지원) Emulator 바이너리도 제공합니다. 이 스크립트를 기존 지속적 통합 시스템과 통합할 수 있습니다. 우리는 앞으로 과거의 테스트 결과를 더 쉽게 재현하기 위해 최신 버전 외에도 지원 중단된 버전을 다운로드할 수 있도록 이 서비스를 향상시킬 생각입니다.

Android Emulator Docker 이미지 생성기 - Android 시스템 이미지와 Emulator는 전체 중 한 부분일 뿐입니다. 환경, 드라이버, 사전 설치 시스템 종속 항목을 위해, 우리는 Docker 이미지 생성기를 만들었습니다. 이렇게 하면 Android Emulator가 작동하는 완벽한 환경이 만들어집니다. Docker 이미지를 시작한 후, 1) 포트 전달과 ADB 또는 2) gRPC와 WebRTC를 통해 Emulator와 상호작용할 수 있습니다. 현재, Docker 이미지 생성기는 Linux에서 작동하도록 설계되었습니다. 우리는 Mac OS 및 Windows 호스트도 모색 중이므로 계속 관심을 가져주시기 바랍니다!

재현성을 높이기 위해, 기본 Dockerfile 템플릿을 사용하면 필요한 Command line 플래그와 시스템 종속 성이 더욱 명확해집니다 (Docker 이미지를 빌드하여 재현할 수 있습니다). 하드웨어 가속의 경우 run.sh로 전달되는 --privileged 플래그를 확인하세요. Emulator를 실행할 때 CPU 가속을 사용할 수 있으며 CPU 가속(KVM)을 사용하는 상태로 컨테이너를 실행하려면 --privileged가 필요합니다. Android Emulator 이미지를 만들고 배포하는 방법에 관한 자세한 내용은 README를 참조하세요. Debuggability Emulator가 실행 중이고 테스트 또는 Emulator가 실패할 경우 실행 중인 환경으로 들어가 오류를 진단하기 어려울 수 있습니다. 진단에서는 가상 기기와의 직접적인 상호작용이 필요할 때가 종종 있습니다. 우리는 직접 상호작용을 위해 다음 두 가지 메커니즘을 제공합니다.

ADB

원격 스트리밍

ADB의 경우 우리는 Docker 게스트에서 호스트로 특정 포트를 전달하여 logcat 및 shell과 같은 모든 명령어를 허용합니다. 현재 포트는 5555이므로, 더 많은 피드백을 수집하고 다양한 컨테이너에 걸쳐 포트를 분리하는 최선의 방법에 관해 더 많은 연구를 수행해야 할 것입니다. 원격 스트리밍 보안 참고: 원격 스트리밍을 사용할 때는 일단 서비스가 시작되고 나면 포트 80/443을 통해 컴퓨터에 연결할 수 있는 모든 사용자가 Emulator와 상호작용할 수 있다는 점을 염두에 두세요. 따라서 공용 서버에서 Emulator를 실행할 때 주의하십시오! 원격 스트리밍을 사용하면 컨테이너에서 Emulator를 실행할 수 있는데, 로컬에서 실행하는 것만큼이나 상호작용이 원활히 이루어집니다. 컨테이너에서 Emulator를 실행하면 ADB 명령어로는 발견하기 어려울 수 있는 문제를 더 쉽게 디버깅할 수 있습니다. 동영상 스트리밍에 사용되는 WebRTC와 마우스 및 키보드 이벤트를 Emulator로 보내는 데 사용되는 gRPC가 지원되는 브라우저를 사용하여 Emulator에 액세스할 수 있습니다. 원격 스트리밍에는 다음 세 가지 컨테이너가 필요합니다.

최신 Emulator를 호스팅하는 컨테이너

gRPC에 필요한 Envoy 웹 프록시가 있는 컨테이너

React 웹 앱을 제공하기 위한 nginx가 있는 컨테이너

README에 설명되어 있는 것처럼, docker-compose를 사용하여 Docker 컨테이너를 함께 구성할 수 있습니다. 컨테이너는 포트 80 및 443에 바인딩되므로, 웹 서버가 실행되고 있지 않은지 확인하세요. 브라우저에서 호스트를 가리키면 자체 서명된 인증서가 제공됩니다. 브라우저에서 호스트를 가리키면 아래와 같은 이미지가 나타날 것입니다.

이때도 호스트에 연결할 수 있는 사람이라면 누구든 Emulator와 상호 작용할 수 있다는 점을 잊지 마세요. 따라서 공용 서버에서 Emulator를 실행할 때는 주의하세요! 테스트 규모의 확장 테스트란 게 마치 꼭 내야 하는 세금처럼 여겨질 수 있습니다. 하지만 많은 노련한 개발자가 경험한 바와 같이, 적절히 자동화된 테스트 코드는 코드 베이스가 점점 커지고 복잡해짐에 따라 개발 속도를 높일 수 있습니다. 지속적 테스트를 통해 뭔가 변경하더라도 앱에 문제가 생기지 않으리라는 확신을 가질 수 있을 것입니다.

딥 러닝으로 피부병 감별 진단하기

Monday, October 21, 2019

.post-body span { white-space: normal !important; } <블로그 원문은 이곳에서 확인하실 수 있으며 블로그 번역 리뷰는 신정규(MachineLearning GDE)님이 참여해 주셨습니다>
게시자: Google Health 소속 Yuan Liu 박사(소프트웨어 엔지니어), Peggy Bui 의학박사(기술 프로그램 관리자)
어느 시점에서든 전 세계적으로 약 19억 명이 피부 상태 문제로 고통받고 있으나, 피부과 전문의가 부족하여 많은 경우 일반의가 그 진료를 담당하고 있는 실정입니다. 미국에서만도 클리닉을 방문하는 환자 중 최대 37%가 한 가지 이상의 피부 트러블이 있는 것으로 파악되고, 그중 절반 이상을 피부과 전문의가 아닌 의사가 진료하는 것으로 나타났습니다. 하지만 여러 연구에 따르면, 일반의와 피부과 전문의 사이의 피부병 증상 진찰 정확도 격차가 상당히 큰 것으로 입증되는데, 피부과 전문의가 77~96%의 정확도를 보인 반면, 일반의의 정확도는 24~70%에 불과한 것으로 나타났습니다. 이에 따라 최상의 진료 의뢰가 이루어지지 못해 치료가 지연되고 진찰과 치료에 오류가 생길 수 있습니다.
비전문의가 진찰 정확도를 높이기 위한 기존의 전략으로는 참고 문헌과 온라인 자료를 활용하고 동료와 상담하는 방법 등이 있었습니다. 그런데 이제는 진찰 정확도 향상에 도움을 줄 목적으로 머신러닝 도구도 개발되었습니다. 이전의 연구는 주로 피부암의 조기 선별, 특히 병변이 악성 또는 양성인지 여부나 병변이 흑색종인지 여부에 중점을 두었습니다. 하지만 피부 문제의 90% 이상은 악성이 아니므로, 피부병에 대한 전 세계적인 부담을 줄이기 위해서는 이처럼 흔한 피부병에 효율적으로 대처하는 것도 중요합니다.
'A Deep Learning System for Differential Diagnosis of Skin Diseases(피부병 감별 진단을 위한 딥 러닝 시스템)'에서, 우리는 1차 의료에서 흔히 보는 피부병 증상을 해결하기 위한 딥 러닝 시스템(DLS)을 개발했습니다. 테스트 결과, 어떤 환자 증례에 대해 똑같은 정보(이미지와 메타데이터)를 제공할 경우 DLS는 26가지 피부병 증상에 관해 미국의 해당 위원회에서 인증한 피부과 전문의와 동등한 수준의 진찰 정확도를 달성할 수 있는 것으로 나타났습니다. 이 연구는 DLS가 각종 피부병 증상을 정확히 진찰하기 위한 전문적인 교육과 수련을 추가로 받지 않은 일반의의 진찰 능력을 강화할 수 있는 잠재력을 잘 보여줍니다.
DLS 디자인 임상의는 확실한 해답이 없는 애매모호한 사례에 직면할 때가 종종 있습니다. 예를 들어 어떤 증상이 환자의 발진 정체피부염 때문인지, 연조직염 때문인지, 아니면 두 가지가 모두 합쳐진 증상인지 확실치 않을 수 있습니다. 임상의는 딱 한 가지 진찰 결과만 내놓기보다는 가능한 진찰 결과의 순위를 매긴 목록인 감별 진단 결과를 작성합니다. 감별 진단에서는 진찰 결과가 확인될 때까지 추가 정밀 검사(실험실 검사, 영상 촬영, 시술, 상담)와 치료를 체계적으로 적용할 수 있도록 문제를 구조화합니다. 이와 같이, 피부 트러블에 대해 가능한 피부병 증상의 순위를 매긴 목록을 생성하는 딥 러닝 시스템(DLS)은 임상의의 사고 방식과 매우 흡사하게 작동하고 환자를 위한 즉석 선별, 진찰 및 치료에 관건이 됩니다.
이런 예측 결과를 제공하기 위해, DLS는 피부 이상을 보여주는 하나 이상의 임상 이미지와 최대 45가지 유형의 메타데이터(나이, 성별, 증상 등의 의료 기록 중 환자 스스로 알려준 정보 요소)를 포함한 입력 데이터를 처리합니다. 각 증례에 대해 여러 개의 이미지를 Inception-v4 신경망 아키텍처를 사용하여 처리하고 분류 계층에서 사용할 수 있도록 특징이 변환된 메타데이터와 결합했습니다. 우리는 주로 1차 의료 기관에서 원격 피부과 진료 서비스로 의뢰가 이루어진 17,777건의 개인 식별 정보가 제거된 사례를 활용한 연구를 통해 DLS를 개발하고 평가했습니다. 2010년부터 2017년까지의 데이터는 모델 훈련에 사용하고 2017년부터 2018년까지의 데이터는 평가에 사용했습니다. 모델 훈련 중에, DLS는 40명 이상의 피부과 전문의가 제공한 50,000여 건의 감별 진단 데이터를 활용했습니다.
DLS의 정확도를 평가하기 위해, 우리는 DLS의 진찰 결과를 미국의 관련 위원회에서 인증을 받은 3인의 피부과 전문의가 내놓은 진찰 결과를 기준으로 한 엄격한 참조 기준과 비교했습니다. 피부과 전문의들은 총 3,756건의 증례에 대한 감별 진단 결과('유효성 검사 집합 A')를 제공했으며, 이런 진단 결과는 실측 라벨을 얻기 위한 투표 과정을 통해 집계되었습니다. DLS가 순위를 매긴 피부병 증상 목록을 피부과 전문의가 도출한 이 감별 진단 데이터와 비교한 결과, 각각 71%와 93%의 top-1 및 top-3 정확도를 달성했습니다.

DLS의 계통도와 유효성 검사 집합에 포함된 각 증례에 대해 위원회의 인증을 받은 3인의 피부과 전문의의 투표를 통해 참조 기준(실측)을 도출한 방법.
전문가 평가와의 비교 우리는 이 연구에서 임상 의료인을 폭넓은 범위의 경험 및 훈련 수준과 진찰 정확도를 보여주는 피부과 전문의, 1차 의료 기관 의사(PCP), 전담 간호사(NP)의 세 범주로 나누어 무작위로 선정한 후 그들이 유효성 검사 A 데이터세트 중 일부('유효성 검사 집합 B')에 대해 진단한 결과의 정확도와 DLS의 정확도를 비교하기도 했습니다. 임상의가 제공하는 전형적인 감별 진단에는 최대 3가지 진단 결과만 포함되므로, 우리는 DLS가 예측한 결과 중 순위가 높은 3가지 진단 데이터만 임상의가 제공한 데이터와 비교했습니다. DLS는 유효성 검사 B 데이터세트에서 90%의 top-3 진찰 정확도를 달성했는데, 이는 피부과 전문의에 필적하는 수준이고 1차 의료 기관 의사(PCP)와 전담 간호사(NP)보다는 현저히 높은 수준이었는데, 각 그룹에 6명의 임상 의료인을 대상으로 하여 각각 75%, 60%, 55%의 정확도를 보였습니다. 이처럼 높은 top-3 정확도는 (피부과 전문의를 포함한) 임상의가 원래는 감별 진단에서 파악되지 않았던 가능성을 고려함으로써 진찰 정확도와 증상 관리를 개선하는 데 DLS가 도움이 될 수 있다는 점을 시사합니다.

DLS가 선두인(top-1) 감별 진단은 PCP와 NP보다는 월등히 높고 피부과 전문의와는 동등한 수준입니다. DLS의 top-3 정확도를 살펴보면 이 정확도가 상당히 높아져, 대부분의 증례에서 DLS의 질병 순위 목록에 해당 증례에 대한 올바른 실측 결과가 포함되어 있음을 시사합니다.
인구통계학적 성능 평가 피부 유형은 특히 피부 자체의 육안 평가가 진찰에 결정적으로 중요한 역할을 하는 피부과와 높은 관련성이 있습니다. 피부 유형에 대한 잠재적 편향성을 평가하기 위해, 우리는 유형 I('창백하고 흰 피부, 강한 태양빛에 항상 화상, 절대 그을리지 않음')부터 유형 VI('가장 어두운 갈색, 절대 화상 없음')까지의 범위로 구분한 척도인 피츠패트릭 피부 유형을 기준으로 DLS의 성능을 조사했습니다. 설득력 있는 결론을 도출하기 위한 충분한 수의 사례를 확보하기 위해, 우리는 데이터 중 5% 이상을 대표하는 피부 유형인 피츠패트릭 피부 유형 II에서 IV까지의 피부 유형에 초점을 맞추었습니다. 이들 범주에서는 DLS의 정확도가 비슷하게 나왔는데, top-1 정확도는 69~72%, top-3 정확도는 91~94%였습니다. 환자가 스스로 알려주는 다른 인구통계 정보인 나이, 성별, 인종/종족 등의 정보를 기반으로 데이터세트에 존재하는 상당수(5% 이상)의 사람에 대한 환자 하위 그룹에서도 DLS가 정확성을 유지한 점이 고무적이었습니다. 추가로 진행된 정성 분석에서, 우리는 DLS가 피부 톤 대신 피부 이상에도 '초점'을 맞춰 재확인시켜 준 세일리언시(설명) 기법을 통해 평가를 실시했습니다.

왼쪽: 비전문가에게는 어려운 문제인 탈모 증례에 대해 적절한 치료법을 결정해야 하는 특정 진찰 결과에 이른 사례. 오른쪽: DLS가 중요하다고 식별하여 예측에 사용한 영역을 녹색으로 강조 표시한 이미지. 가운데: DLS가 예컨대 잠재적 편향성을 나타낼 수 있는 앞머리 피부색 대신에 이러한 예측을 하기 위해 탈모 부위에 주로 초점을 맞추었음을 나타내는 결합 이미지.
여러 가지 데이터 형식의 통합 우리는 DLS 성능에 관해 다양한 유형의 입력 데이터가 나타내는 효과도 연구했습니다. 여러 각도에서 촬영한 이미지가 있으면 원격 진료 피부과 전문의가 피부병 증상을 더 정확히 진찰하는 데 도움이 될 수 있는 것과 마찬가지로, DLS의 정확도는 이미지 개수가 증가함에 따라 향상됩니다. 메타데이터(예: 의료 기록)가 없으면 모델도 올바른 성능을 발휘하지 못합니다. 의료 기록을 활용할 수 없는 상황에서 발생할 수 있는 이런 정확도 격차는 이미지만으로 DLS를 훈련하는 방법으로 일부 해소할 수 있습니다. 그럼에도, 다음 데이터는 피부병 증상에 관한 몇 가지 질문에 대한 대답을 제시하면 DLS 정확도를 상당히 개선할 수 있다는 점을 시사합니다.

더 많은 이미지(파란색 선)나 메타데이터(파란색과 빨간색 비교)가 있으면 DLS 성능이 향상됩니다. 입력 데이터로 활용할 메타데이터가 없는 경우, 이미지만 사용하여 별개의 DLS를 훈련하면 부족하긴 해도 현재의 DLS(녹색 선)에 비해서는 개선됩니다.
향후 작업과 응용 이런 결과는 매우 장래성이 있긴 하지만, 앞으로도 해야 할 일이 많이 남아 있습니다. 첫째, 실제 의료 현장의 실태를 반영하자면, 우리가 준비한 데이터세트에서 흑색종과 같은 피부암은 상대적으로 희귀하므로 암을 검출하기 위해 정확한 시스템을 훈련하는 우리의 능력을 저해하는 요인이 되었습니다. 이와 관련해, 우리의 데이터세트에서 피부암 라벨은 생검을 통해 입증된 것이 아니라서, 이 점에 있어서는 실측 자료의 품질에 한계가 있었습니다. 둘째, 데이터세트에 다양한 피츠패트릭 피부 유형이 포함되지는 않았지만, 이 데이터세트에서 어떤 피부 유형은 유의미한 훈련이나 분석을 수행하기에는 너무 드물었습니다. 마지막으로, 이 유효성 검사 데이터세트는 단 하나의 원격 피부과 진료 서비스에서 얻은 것이라는 한계도 있었습니다. 2개 주에 걸쳐 17개 1차 의료 기관에서 모은 자료가 포함되었지만, 더 넓은 지역에서 수집된 더욱 다양한 증례에 대한 유효성 검사가 꼭 필요할 것입니다. 우리는 훈련 및 유효성 검사 세트에 생검을 통해 입증된 피부암 증례를 더 많이 포함하고 추가적인 피츠패트릭 피부 유형을 대표하는 증례와 다른 임상 센터에서 제공하는 증례를 포함함으로써 이러한 제한 사항을 극복할 수 있다고 생각합니다.
피부 질환의 감별 진단 결과를 알려주는 딥 러닝의 성공은 이러한 도구가 임상의의 진료 활동을 보조할 수 있는 잠재력을 보여준다는 점에서 매우 고무적인 일입니다. 예를 들어 이러한 DLS는 임상 진료를 위해 증례를 선별하여 우선순위 결정에 도움이 되거나 피부과 전문의가 아닌 일반의가 피부과 진료를 더 정확히 시작하는 데 도움이 되고 더 높은 수준의 피부과 진료에 접근할 수 있는 가능성을 열어줄 수도 있습니다. 앞으로도 할 일이 상당히 많이 남아 있지만, 우리는 향후 임상의를 위해 이러한 시스템의 유용성을 검토하는 작업에 기꺼운 마음으로 최선을 다할 것입니다. 연구 협업에 관한 문의 사항이 있으시면 dermatology-research@google.com으로 연락해주세요.
감사의 말 이 작업은 소프트웨어 엔지니어, 연구원, 임상의, 여러 직무 분야의 공헌자 등, 다양한 분야에서 종사하는 분들의 노고 덕분에 진행할 수 있었습니다. 이 프로젝트에 기여해 주신 주요 인사로 Yuan Liu, Ayush Jain, Clara Eng, David H. Way, Kang Lee, Peggy Bui, Kimberly Kanada, Guilherme de Oliveira Marinho, Jessica Gallegos, Sara Gabriele, Vishakha Gupta, Nalini Singh, Vivek Natarajan, Rainer Hofmann-Wellenhof, Greg S. Corrado, Lily H. Peng, Dale R. Webster, Dennis Ai, Susan Huang, Yun Liu, R. Carter Dunn, David Coz와 같은 고마운 분들이 계십니다. 저자 일동은 데이터 수집을 위한 소프트웨어 인프라 지원을 해주신 William Chen, Jessica Yoshimi, Xiang Ji, Quang Duong에게 감사 말씀을 드립니다. Genevieve Foti, Ken Su, T Saensuksopa, Devon Wang, Yi Gao, Linh Tran에게도 감사의 마음을 전합니다. 마지막으로 언급하지만 역시 중요한 점으로, 이번 연구를 위해 다양한 증례를 검토해주신 피부과 전문의, 1차 의료 기관 의사, 전담 간호사, 그리고 피부병 증상 매핑을 완성하는 데 도움을 주신 Sabina Bis와 원고에 대한 피드백을 해주신 Amy Paller의 참여가 없었다면 이번 작업은 가능하지 않았을 것입니다.

제스처 탐색: 배경 설명

Friday, October 18, 2019

.post-body span { white-space: normal !important; } <블로그 원문은 이곳에서 확인하실 수 있으며 블로그 번역 리뷰는 이승민 (Android GDE)님이 참여해 주셨습니다>
게시자: Allen Huang, Rohan Shah - Android UI 제품 관리자

모바일 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를 좋아하는 이유

Monday, October 14, 2019

.post-body span { white-space: normal !important; }
DevFest Coimbra를 계획 중인 Ricardo(왼쪽)와 동료 GDG 리드

Ricardo Costeira는 포르투갈 코임브라에서 온 소프트웨어 엔지니어입니다. Ricardo는 Google Developer Groups가 전 세계적으로 호스팅하고 개발자 커뮤니티가 주도하는 최대 규모의 이벤트인 DevFest에 작년에 처음으로 참석했습니다. DevFest 2019를 기념하기 위해, Ricardo의 이야기와 그가 코드를 작성하다가 커뮤니티를 찾은 경위에 관한 사연을 공유하고자 합니다.
Ricardo(왼쪽)와 동료 GDG 리드가 DevFest Coimbra를 계획하고 있습니다.
1. 처음에 DevFest에 대한 얘기를 어떻게 듣게 되셨나요? 참여하고자 마음먹은 이유는 무엇이었나요? 2018년 당시 코임브라에서 3년간 살고 있었는데, 소프트웨어 개발자로 일하던 직장의 동료들을 제외하면 친구가 전혀 없었어요. 제 열정을 이해하고 알아봐주는 더 많은 사람과 함께하는 삶을 갈망하다가, 변화를 택해야 할 때라고 결심했어요. 그래서 소셜 미디어를 통해 나와 같은 생각을 가진 더 많은 사람들과 소통할 방법이 있을지 알아봤어요. 마침내, 제 피드에 DevFest가 나타났죠. 대담한 리더, 활기 넘치는 연사, 충만한 창의력이 넘치는 각종 행사로 가득 찬 이 멋진 이벤트가 코임브라에서 열린다는 소식을 어디선가 보게 된 거죠. 커뮤니티와 함께한다는 게 이토록 절 흥분시키리라곤 기대도 못했던 일이랍니다. 그래서 이벤트 입장권을 구했어요.
2. DevFest에서의 첫 경험에 대해 말씀해 주시겠어요?
너무나도 활기차고 들뜨게 해준 경험이었습니다. 처음 행사장에 입장하자 모든 이가 마치 오랫동안 알고 지낸 사이인 것처럼 반갑고 친근하게 제게 말을 걸더군요. 모두 함박웃음을 짓는 표정에 큰 소리로 맘껏 웃고 정말 친절한 분들이었어요. 전 다소 수줍음이 많고 천성적으로 사람들과 쉽게 어울리지 못하고 겉도는 성격인데, 그곳에서 '마치 집처럼 편하고 강한 소속감이 든다'는 느낌에 스스로도 놀랐어요. 바로 그날 밤, 다음에 참석할 수 있는 이벤트가 있을지 찾아봤어요. 그날 이후로, 전 다른 이벤트에도 2번 더 참석했고 6차례 더 참가 등록을 했고, 지금은 GDG 리드가 되었죠. 쉽게 말해, 전 완전히 푹 빠져있어요.
Ricardo

그래서 이 모든 일을 계기로 제게 어떤 변화가 일어났을까요? 솔직히, 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

새로워진 Android Kotlin 코드랩 과정을 만나보세요!

새로운 Android Emulator 도구를 사용한 지속적인 테스트

딥 러닝으로 피부병 감별 진단하기

제스처 탐색: 배경 설명

코드에서 커뮤니티까지: 개발자가 Devfest를 좋아하는 이유

Tag

Archive

Feed

Google Korea

Products

Developers