Google for Developers Korea Blog

Google I/O를 위한 Google 어시스턴트 액션 제작기 (1)

2019년 1월 18일 금요일

이 게시물은 Google I/O ’18 Google 어시스턴트 액션의 디자인과 제작에 관해 두 파트로 나누어 소개하는 글로, April Pufahl(@aprilpufahl)과 함께 작성했습니다. 코드는 여기서 확인하세요.

행사에 몸소 참석하는 분이든, 가까운 곳에서 열리는 뷰잉 파티에 참석하는 분이든, 집에서 동영상으로 보는 분이든, Google I/O와 같은 이벤트를 최대한 활용한다는 것은 일종의 도전입니다. Actions on Google 팀은 어시스턴트 액션을 통해 이벤트 현장에 가시는 분과 동영상 시청자 모두에게 똑같이 유익한 경험을 줄 수 있는 기회를 발견했습니다. 더 많은 분들이 행사를 만끽할 수 있도록 Google 어시스턴트 액션을 만들고 싶었습니다. 이 게시물에서는 어시스턴트 액션을 만들 때 마딱드린 주요 과제와 이를 해결하기 위한 결정 사항을 비롯하여, 액션을 설계하는 과정에 중점을 두고 설명하겠습니다. 이어질 다음 게시물에서는 기술적 구현에 관해 상세히 다룰 예정입니다.

왜 대화인가?

대화 디자인은 강력한 접근 방식이지만, 모든 사례에 적합한 것은 아닙니다. 예를 들어 대화는 어떤 레스토랑의 영업 시간을 찾는 작업에는 효과적이지만, 저녁 메뉴를 찾아보기에는 좀 거추장스럽게 느껴집니다. 우리는 어시스턴트 액션이 제공하는 대화가 속도, 단순성, 편재성을 통해 사용자에게 확실히 가치를 부가하도록 하고 싶었습니다. 대화가 적합할 것이라 생각한 이유는 다음과 같습니다.

이벤트에 대한 대화는 직관적입니다. 사용자는 어떤 이벤트가 어디서 있을 예정인지에 대해 이벤트 플래너 및 관련 스태프와 대화하는 멘탈 모델을 이미 가지고 있습니다.
사용자가 이벤트에 관해 물어볼 수 있습니다. 사용자는 질문을 통해 자신이 정확히 원하는 바(예: 일정 정보, 세션 주제, 가는 길 등등)를 빠르게 확인할 수 있습니다.
사용자가 멀티태스킹을 해야 합니다(특히 이벤트에 참석할 때). 사용자가 잠시 다른 일을 해야 하거나 뭔가에 시선을 빼앗길 수도 있습니다. 또는 이동할 일이 생길 수도 있습니다.
이벤트에 대한 세부 사항을 묻는 것처럼 개인적 궁금증이 아닌 사항을 물어봐야 할 때, 사용자는 대화나 타이핑으로 질문하는 걸 편하게 느낍니다.

사용 사례의 확정

위의 전제로부터 어떻게 다음 단계로 나아갈 수 있을까요? 어떤 소프트웨어 프로젝트에서나 마찬가지로, 우선 요구 사항 수집부터 시작했습니다. 특히 다음과 같은 사용 사례에 집중하고 싶었습니다.

이벤트 참석자와 참석하지 못한 사람을 포함한 대부분의 사용자 포괄
I/O에 관해 사용자가 가장 자주 묻는 질문과 궁금증 해결
특히 이벤트 참석자를 위해 빠른 속도 강조
이벤트 이전, 도중, 이후에 사용자가 갖는 다양한 목표 존중

이러한 모든 목표에 맞춘 디자인 시도는 엄청나게 도전적인 과제였습니다. 우리는 I/O 이전, 도중, 이후에 여러 사용자 프로필에 걸쳐 다양한 사용 사례에 적합한 단일 솔루션을 만들어야 했습니다. 하지만 개발자를 위해 액션의 구현 소스를 공개하는 것이 제2의 목표였기에, 더 많은 기능을 탑재하려고 높은 품질 기준을 낮추고 싶진 않았습니다. Android IOSched 앱의 전통을 유지하면서 우리의 솔루션이 Actions on Google 개발자를 위한 도구이자 모델이 될 수 있기를 바랐습니다.

사용자가 가장 자주 묻는 질문을 파악하기 위해, 1) I/O ’17 액션에 대해 Dialogflow 분석을 통해 얻은 데이터와 2) 전에 I/O에서 일한 적 있는 Google 직원과 대화를 나누었습니다.

I/O ’17 액션은 기조연설, 행사 장소 등에 대한 몇 가지 기본적인 질문에 답해주었고, 사용자가 관심 영역별로 알맞은 세션을 찾을 수 있게 해주었습니다. 수집한 사용 데이터를 보면, 세션 찾기 기능이 꽤 많이 사용되었고 사용자들이 일단 해당 대화 경로에 들어오면 큰 오류없이 작업을 잘 마무리 하는 것으로 확인되었습니다. 대부분의 사용자는 기조연설이나 사은품 증정에 대해 물었고 여러 가지 발표, I/O Extended 등에 대해 미리 준비된 다른 답변은 찾지 않았습니다. 이를 바탕으로, 우리는 세션을 찾아 더 구체적인 정보를 알아내고 이벤트에 대한 FAQ의 검색 기능을 향상하기 위한 사용자 환경 개선에 초점을 맞추고 싶었습니다.

I/O에서 일한 Google 직원들과 대화를 나눠본 결과, 참석자들이 묻는 질문에는 다음과 같은 4가지 주요 범주가 있는 것으로 나타났습니다.

일반적인 길 안내(예: 화장실은 어디죠?)
개인적 길 안내(예: 내가 다음으로 참석할 세션은 어디서 열리죠?)
이벤트 세부 정보(예: 점심시간은 몇 시예요?)
위치별 이벤트 세부 정보(예: 이 방에서 다음에 진행되는 세션은 무엇인가요?)

이러한 조사 결과를 바탕으로 이벤트 현장에서 쉽게 길을 찾고 원하는 세션에 참가할 수 있도록 네비게이션에 대한 지원을 추가하고 싶었습니다. 또한 사용자가 이동 중에도 빠르게 네비게이션에 액세스할 수 있도록 사용자의 일정에도 연결하고 싶었습니다. 이런 기능을 실제로 구현하려면 기능마다 일정 부분 절충해야 할 사항이 있습니다(파트 2에서 자세히 다룰 예정임).

이 모든 정보를 활용하여 디자인을 안내해 줄 가상 사용자와 가상 사용자의 사용 여정을 만들었습니다.

페르소나 만들기

다음으로, 사용자와 상호 작용하는 페르소나 디자인에 초점을 맞췄습니다. 페르소나를 만드는 목적은 사용자가 마치 사람과 대화하고 있다고 여기게끔 하려는 게 아니라, 먼저 학습한 커뮤니케이션 시스템을 활용하여 최선의 대화를 파악하기 위한 것입니다. 특히 다음과 같은 특성에 초점을 맞추었습니다.

실용적이고 직접적임
기술에 정통함
열정적임
I/O 전문가임

우리는 GDE(Google Developer Expert)가 이러한 특성을 구현한 캐릭터의 훌륭한 예라고 판단했습니다. GDE는 개발자 커뮤니티에서 개방성과 전문성을 갖춘 호기심 많고 창의성이 풍부하며 열정적인 존재입니다. 이 시점에서 우리는 사는 이야기, 동기 부여, 기술적 선호도를 비롯하여, 한 페이지 분량에 걸쳐 가상 사용자의 일대기를 작성하는 실수를 범했습니다. 너무 의욕이 앞섰던 거죠. 애초에 생각했던 페르소나는 대화 내용을 작성할 때 쉽게 마음속에 떠오를 정도로 단순해야 하는데 말이죠. 그래서 그 내용을 짧은 한 단락으로 줄였습니다. 우리가 만든 가상 사용자를 Keeper of I/O-Specific Knowledge라고 불러 게임의 대가와 같은 느낌을 자아내고 싶었습니다. 신규 사용자의 경우 환영 인사의 일부로 이 이름을 들려줍니다. 이름의 첫 글자를 따면 KIOSK가 됩니다. 꽤 그럴듯하지 않습니까?

다음으로 이 가상 사용자에게 생명력을 불어넣어 줄 목소리를 선택해야 했습니다. 음성 오디오 녹음이 사용자 환경 개선에는 이상적인 방법이었겠지만, 문자열의 변동을 고려하면 막상 그렇게 구현할 경우 무척 지루해졌을 것입니다. 대신 Actions on Google 카탈로그에서 사용 가능한 음성을 살펴보았습니다. 사용 가능한 미국 영어용 TTS 음성 중에서 '실용적'이고 '기술에 정통'하며 '직접적인' 속성에 대해 'Female 2'에 최고 점수를 주었습니다.

샘플 대화 만들기

화자(사용자와 가상 사용자)와 대화 주제(사용 사례)를 분명히 정하고 나니 대화 작성을 시작할 수 있었습니다. 이를 통해 코드 표기, 복잡한 흐름도, 인식-문법 문제 등의 복잡한 기술적 처리 과정을 생략하고 음성 및 액션이 주는 대략적인 느낌을 확인하기 위한 실험을 할 수 있습니다. 행사 참가자(Anna)가 현재 I/O에 참석 중인데 그날의 나머지 세션에 대한 정보를 원하는 대화로 시작해봤습니다.

먼저 1) 사용자에게 환영 인사를 건네고, 2) 기대 수준을 조절하고, 3) 사용자가 통제권을 갖도록 하는 방식으로 환영 인사를 작성했습니다. 'Google I/O 18'이라는 이름은 액션이 할 수 있는 일을 제대로 나타내지 못하기 때문에, 이 액션을 '론치패드'로 설명했습니다. 결정적으로, 참석자와 비참석자가 서로 다른 목표(예: 가는 길 파악과 라이브스트림 시청)를 생각하고 있으므로 각 사용자 환경에 맞춰 조정하고 싶었습니다. 그래서 범위를 좁혀가는 질문(이 경우에는 예/아니요 질문)을 던졌습니다. 이때 넓은 범위의 질문(예: 어떤 게 필요하세요?)을 하기 전에 가상 사용자의 명칭(Keeper of I/O-Specific Knowledge)을 활용하는 것 외에도 사용자에게 몇 가지 추천 항목(예: 일정 관리, 할 일 찾기, 길 안내 받기 등)을 제시했습니다. 사용자는 추천 항목 중 하나를 선택하거나 액션이 지원하는 다른 항목(예: 기조연설 또는 세션 찾아보기)으로 바로 갈 수 있었습니다.

이 샘플 대화의 나머지 부분에서 지원하고 싶은 다양한 사용 사례로 사용자를 안내하는 메뉴를 만들었습니다. 사용자가 액션과 대화를 시작할 때 어떤 내용을 물을 수 있을지 자동으로 알지는 못할 것이므로 이는 유용한 기능입니다. 그와 동시에, 사용자에게 너무 많은 옵션을 제시해 혼란스럽게 만들고 싶지 않았으므로, 옵션을 직관적인 범주로 분류하려 했습니다. 예컨대 9가지 옵션을 그냥 나열한 메뉴를 제시하기보다는 다음과 같은 3가지 범주로 분류했습니다.

전문가에게서 배우기

기조연설
세션
오피스 아워
앱 리뷰

데모

코드랩
샌드박스

휴식 및 기타

음식
사은품
폐장 후 시간

이를 기반으로 각각 다른 사용 사례에 초점을 맞춘 10가지 샘플 대화를 더 만들었습니다.

디자인 구체화

몇몇 샘플 대화를 만든 후, 대화의 상위 레벨 흐름과 로직을 요약하기 시작했습니다. 이런 작업을 수행하는 과정에서, 대화 구조가 다차원이라는 점이 분명해졌습니다. 즉, 대화의 변화는 단지 한두 가지의 사용자 특성이 아니라 다음 세 가지 요소에 종속되어 있다는 점을 깨달았습니다.

사용자가 액션의 신규 사용자인지, 아니면 기존 사용자인지 여부
현재 세션 날짜가 I/O 이전, 도중 또는 이후인지 여부
사용자가 I/O에 참석 중인지 여부

이를 통해 다음과 같은 도식을 도출했습니다.

근본적으로 다음과 같은 사용 사례를 다루었습니다.

이벤트에 대한 일반적인 정보 관련 질문(날짜, 위치, 기조연설 등)
이벤트에서 할 일 또는 길 찾기(참석자의 경우)
일정 찾아보기
자신의 일정 찾아보기

일반적인 이벤트 관련 질문은 상당히 간단하게 다룰 수 있습니다. 기조연설, 사은품, 음식 등에 관련된 각 질문에 대해 이벤트와 관련된 날짜를 기준으로 미리 준비된 답변을 내놓았습니다. 각각의 답변이 TTS(텍스트 음성 변환)에서 렌더링되는 것을 청취하고 필요에 따라 SSML(Speech Synthesis Markup Language)을 사용했습니다. 대체로 대화 구문이 더욱 자연스럽게 들리도록 하려고 묵음 구간을 추가함으로써 가상 사용자가 실제 사람이 말할 때처럼 '호흡하느라 잠시 쉬어가며' 말하도록 했습니다.

예를 들어 사용자가 I/O에서 입을 옷에 대해 물어볼 때 다음과 같이 답변하도록 디자인했습니다.

각 프롬프트에 대해 여러 가지 조건을 고려했다는 점에 유의하세요. 또한 사용자가 한 눈에 내용을 파악할 수 있도록 가급적 내용을 압축해서 표현했습니다. 덕분에 다중 모달 대화로 디자인을 확장할 시점이 되었을 때, 음성 프롬프트를 쉽게 재사용할 수 있었습니다.

일정 찾아보기 사용 사례의 경우, I/O ’17 액션용으로 빌드된 흐름을 확장하여 사용자가 세션 시간도 찾아보도록 할 수 있었습니다. 또한 더욱 스마트한 찾아보기 환경을 제공하여 I/O 이전, 도중, 이후에 변화하는 사용자의 요구를 충족시키겠다는 더 어려운 과제에도 도전했습니다. 예를 들어 이벤트가 열리기 전에 사용자에게 모든 옵션을 제시하고 싶을지 모릅니다. 하지만 이벤트 도중에는 당일 진행될 세션만 제시함으로써 사용자가 당일 세션 목록을 모두 확인해야만 다음날의 세션을 찾아볼 수 있도록 하고 싶을 수도 있을 것입니다.

사용자가 어시스턴트와 상호 작용하는 데 사용하는 기기에 화면이 있는지 여부에 따라서도 대화 환경을 적절히 조정했습니다. 사용자가 Google Home과 대화하고 있다면 사용자에게 지나치게 많은 옵션을 제시하지 않도록 대화 프롬프트에 (총 17개 중) 임의로 6개 항목만 표시합니다. 사용자가 휴대폰을 사용하고 있다면 화면을 활용해 17개 항목을 전부 사전순으로 표시합니다. 다양한 프롬프트를 활용하고 표준어 대신 준말과 같이 좀 더 자연스러운 음성을 사용한다는 점에도 주목해 보세요. 디자인 단계에서는 한껏 큰 야심을 품기도 했지만, 구현 단계에서는 일정 부분 절충하고 타협해야 했습니다. 하지만 어떤 상황에서도 사용자가 충분히 납득할 수 있는 수준으로 만들었습니다.

길 안내를 받고 자신의 일정을 찾아보는 사용 사례는 주로 구현에 종속되었으므로, 이 단계에서는 밑그림을 그리기 어려웠습니다. Android IOSched 앱(Android에서 사용자를 위해 공개하기로 결정한 경우)과 스케줄링 백엔드에 의존적인 부분도 있었습니다. 어시스턴트용 Google 로그인이 프리뷰 버전으로 제공되고 있었지만, 이 액션에는 사용할 수 없었습니다. 이런 요소가 더 명확해질 때까지는 대화에서 이 부분을 열린 상태로 두었습니다.

골격이 제법 그럴듯하게 갖춰졌다는 생각이 들자, 나머지 세부적인 부분을 디자인할 때라고 판단했습니다. 즉, 뭔가 잘못될 수 있는 사례를 최대한 많이 다루어야 하는 시점이었다는 뜻입니다. 아마 상상하실 수 있듯이, 문제가 무척 복잡해졌습니다. 여러 가지 논리적 결정 지점, 오류 및 거부 처리, 메뉴 내부의 메뉴 등등 복잡한 디자인 문제가 남아 있습니다. 알 수 없는 답변(또는 대체 답변), 거부, 허용, 시스템 장애 등을 포함한 모든 프롬프트에 대한 모든 사용자 반응을 고려했습니다. 뿐만 아니라, 스마트 스피커부터 휴대폰까지 각각의 어시스턴트 표면에 알맞게 각각의 대화 경로와 프롬프트를 맞춤 제작해야 했습니다. 우리는 사용자가 전에 경험한 적이 있는 것과 유사한 결정 지점에 와 있음을 알아차릴 경우, 주어진 대화 상태로 '재진입'하기 위한 특정 프롬프트를 만들었습니다. 한 올 한 올 빈틈없이 뜨개질하듯이, 이 모든 과정을 거치며 액션을 만들어야 한다는 점을 기억해 주세요.

액션 전체에 걸쳐 몇 가지 똑같은 패턴을 활용할 수 있었습니다. 예를 들어 오류 처리 전략은 대부분 대화 내내 똑같이 유지했습니다. 보통은 다음과 같이 마지막으로 물어본 질문의 맥락을 기준으로 조정된 변형이었습니다.

TTS에서 알맞게 렌더링되도록 하기 위해 '4 0 4'를 세 개의 숫자로 발음했다는 점에 주목해 주세요. 실용적이고도 직접적인 톤을 유지하면서도 기술과 관련해서는 가벼운 농담을 포함하여, 우리는 오류 프롬프트를 작성할 때도 계속 페르소나를 염두에 두고 작성했습니다.

이때 야심 차고 종합적인 디자인을 계획했습니다. 기술적 종속성을 고려하여 약간의 공간은 남겨두고 의도한 모든 사용 사례와 가능한 한 많은 극단적 사례를 포괄했습니다. 문제는 그걸 실제로 빌드해야 했다는 거죠…

이 게시물의 두 번째 부분도 읽어보시기 바랍니다. 위에서 설명한 모든 것을 어떻게 구현했는지 설명한 글입니다.

SMS 및 통화 기록 정책 변경에 관한 알림

2019년 1월 18일 금요일

.post-body span { white-space: normal !important; } 작성자: 폴 뱅크헤드(Paul Bankhead), 구글플레이 제품 관리 책임자 본 블로그와 동일한 내용이 안드로이드 개발자 블로그에도 게재 되었습니다.
구글이 얼마 전 발표(한국 블로그)하고 개발자들에게 이메일로 직접 알려드린 바와 같이 SMS 및 통화 기록에 대한 권한을 요청하는 앱은 구글 플레이 스토어에서 삭제될 예정입니다. 권한 요청 양식을 제출하지 않아 앱이 삭제되었다면 아래에서 다음으로 어떤 조치를 취해야 하는지 확인하시기 바랍니다.
구글은 민감한 데이터에 대한 액세스와 권한을 매우 중대한 사안으로 여깁니다. 사용자가 선호하는 전화 앱이나 문자 앱을 선택할 수 있도록 고안되었지만, 동일한 수준의 액세스가 필요 없는 경험을 제공할 때도 빈번하게 사용되어 온 SMS 및 통화 기록 권한에 대해서는 더욱 신중하게 접근하고 있습니다. 지난 10월 구글은 사용자들이 그들의 데이터에 대한 관리 능력을 향상하기 위해 SMS 및 통화 기록에 대해 개발자의 액세스를 제한한다고 발표했습니다.
구글의 새로운 정책은 SMS 및 통화 기록에 대한 권한을 요청하는 앱은 이러한 민감한 데이터가 앱의 핵심 기능 구현에 꼭 필요한 경우에만 허용하도록 하고, 사용자는 앱 실행에 사용자의 데이터가 필요한 이유를 이해할 수 있도록 변경되었습니다.
이번 새로운 정책 발표가 있기 전에 해당 앱 권한을 사용해 온 앱의 개발자에게는 이메일로 정책 변경 사실을 알리고, 90일 내에 권한을 삭제하거나 권한 요청 양식을 제출하여 추가 검토를 받도록 안내했습니다.
앱 검토에 대해 자세히 알아보기
구글은 앱 검토 절차를 매우 신중하게 진행하고 있으며, 많은 개발자에게 큰 변화라는 사실도 인지하고 있습니다. 수십 개의 구글 앱을 비롯한 모든 앱에 동일한 기준을 적용하며, 지난 몇 달 동안 개발자의 피드백을 수렴하여 허용 사례를 확대했습니다. 구글의 글로벌 앱 리뷰팀은 제출된 모든 요청에 대하여 다음을 고려하여 신중하게 앱을 검토합니다.

일반적인 사용자가 해당 유형의 앱에 SMS/통화 기록 데이터에 대한 전체 액세스 권한이 필요한 이유를 납득할 가능성

앱의 기능이 사용자에게 주는 이익

앱의 주요 기능에서 액세스 권한이 갖는 중요도

민감한 데이터에 액세스하는 같은 부류의 앱으로 인한 위험 

앱의 기능을 실행하는 구체적인 대안이 존재하는지 여부 

정책 변경이 시행되면 데이터 액세스가 필요한 일부 기능은 제공하지 못할 수 있습니다. 하지만 구글이 검토한 바에 따르면 많은 경우 대체 API를 사용하여 데이터 접근 범위를 줄이고도 같거나 유사한 기능을 사용자들에게 제공할 수 있습니다. 예를 들어, 계정 인증을 위해 SMS를 사용하는 개발자는 대신 SMS Retriever API를 사용할 수 있고, SMS로 콘텐츠를 공유하는 앱은 기본 SMS 앱을 트리거하여 미리 작성한 메시지를 인텐트를 통해 표시할 수 있습니다. 새로운 정책에 따라 앱을 다시 제출하거나 권한 요청 양식을 제출해주신 수만 명의 개발자분들께 감사의 인사를 전합니다. 양식을 제출한 개발자에게는 3월 9일까지 변경 유예 기간이 연장되었습니다.
다음 단계 향후 몇 주 동안, SMS 또는 통화 기록 액세스 권한을 요청하면서 권한 요청 양식을 제출하지 않은 모든 앱이 플레이 스토어에서 삭제될 예정입니다. 앱이 삭제되어 다시 게시하기 원하시면, 플레이 콘솔에서 다음과 같이 진행해 주시기 바랍니다.

이러한 권한을 요청하지 않는 새로운 버전의 앱을 제출하거나, 

액세스 권한을 요청하는 앱을 새로운 버전으로 제출합니다. 이 경우 플레이 콘솔에서 권한 요청 양식을 제출해야 하며(양식 제공 예정), 3월 9일까지 권한을 삭제하거나 액세스 요청을 승인받아야 합니다. 

안드로이드 생태계 전체를 건강하게 유지하는 일은 매우 중요하며, 모든 개발자의 장기적인 성공을 위해서는 사용자의 데이터 보호가 필수적입니다. 변경된 정책을 준수하려면 상당한 노력이 필요하다는 것을 잘 알고 있습니다. 사용자의 개인 정보를 보호하면서 동시에 혁신적인 서비스를 제공하기 위해 노력해 주셔서 진심으로 감사드립니다.

더욱 스마트한 영상 처리 앱 개발을 위하여 ML Kit에 얼굴 윤곽 기능이 추가됩니다

2019년 1월 16일 수요일

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

작성자 : Christiaan Prins, 제품 관리자

영상 처리 앱을 개발하는 중이거나 개발할 생각이라면, ML Kit의 새로운 얼굴 윤곽 인식 기능이 마음에 드실 겁니다. ML Kit를 사용하면 컴퓨터 비전을 사용한 얼굴 인식과 같이, 많은 일반적인 머신러닝(ML) 사용 사례를 이용할 수 있습니다. 사진 속 인물의 머리에 모자를 어디에 씌울지 알 필요가 있으세요? 눈에 안경을 씌우고 싶으세요? 아니면 왼쪽 눈에 단안경을 씌워야 할 수도 있겠군요. ML Kit의 얼굴 인식 기능을 사용하면 모두 가능합니다. 이 게시물에서는 Android나 iOS에서 모두 더 나은 영상 처리 앱을 빌드할 수 있게 해주는 새로운 얼굴 윤곽 인식 기능을 다루겠습니다. 얼굴 윤곽 인식 이제는 몇 가지 구성 옵션만으로도 얼굴의 세부적인 윤곽을 인식할 수 있습니다. 얼굴 윤곽은 얼굴과 눈, 코, 입과 같은 공통적인 특징의 외형을 나타내는 100여 개의 점으로 구성된 집합입니다. 아래 이미지에서 이를 보실 수 있습니다. 피험자가 눈썹을 위로 들어 올릴 때 윤곽 점들도 그에 맞춰 움직입니다. 이런 점들은 고급 카메라 앱이 사용자의 얼굴에 대해 크리에이티브 필터와 아티스틱 렌즈를 설정하는 방식을 보여줍니다.

코드 몇 줄만 작성하면 이러한 점을 인식하는 얼굴 인식기를 설정할 수 있습니다. lazy var vision = Vision.vision()
let options = VisionFaceDetectorOptions()
options.contourMode = .all
let faceDetector = vision.faceDetector(options: options) 윤곽 점을 실시간으로 업데이트할 수도 있습니다. 이상적인 프레임 속도를 달성하기 위해 얼굴 인식기는 기본적으로 fast 모드로 구성됩니다. 얼굴의 점을 인식할 준비가 되면 이미지나 버퍼를 ML Kit로 보내어 처리하세요. faceDetector.process(visionImage) { faces, error in
guard error == nil, let faces = faces, !faces.isEmpty else { return }
for face in faces {
   if let faceContour = face.contour(ofType: .face) {
     for point in faceContour.points {
       print(point.x) // the x coordinate
       print(point.y) // the y coordinate
     }
  }
}       그러면 ML Kit가 이미지와 같은 배율로 윤곽의 x 및 y 좌표로 구성된 점 배열을 제공합니다.

얼굴 특징부의 위치 인식 얼굴 인식기는 얼굴의 특색을 잘 드러내는 표지점을 인식할 수도 있습니다. 표지점은 코, 눈, 귀, 입과 같은 얼굴의 특징을 지칭하는 포괄적인 용어일 뿐입니다. 우리는 I/O에서 ML Kit를 출시한 이래로 그 성능을 극적으로 개선해왔습니다! 표지점을 인식하려면 다음과 같이 landmarkMode 옵션으로 얼굴 인식기를 구성하세요. lazy var vision = Vision.vision()
let options = VisionFaceDetectorOptions()
options.landmarkMode = .all
let faceDetector = vision.faceDetector(options: options) 그런 다음, 이미지를 인식기로 전달해 인식된 표지점의 좌표를 받아 처리하세요. faceDetector.process(visionImage) { faces, error in
guard error == nil, let faces = faces, !faces.isEmpty else { return }
for face in faces {
   // check for the presence of a left eye
   if let leftEye = face.landmark(ofType: .leftEye) {
     // TODO: put a monocle over the eye [monocle emoji]
     print(leftEye.position.x) // the x coordinate
     print(leftEye.position.y) // the y coordinate
   }
}
} 여러분이 ML Kit를 사용하여 무엇을 만들지 정말 기대됩니다. 이런 새로운 기능을 사용해 더욱 스마트한 기능을 영상 처리 앱에 손쉽게 탑재할 수 있기를 바라겠습니다. ML Kit를 사용한 얼굴 인식에 대한 모든 내용을 알아보려면 iOS 또는 Android에 대한 문서를 확인해 보세요. 즐거운 개발 되세요!

Android 생태계 보안 투명성 보고서

2019년 1월 8일 화요일

.post-body span { white-space: normal !important; } 게시자: Jason Woloz, Eugene Liderman, Android 보안 및 개인정보보호팀
업데이트: 우리는 투명성 보고서에서 2018년 3분기의 데이터를 계산한 방식에 영향을 미친 버그를 식별했습니다. 이 버그로 인해 보고서의 데이터와 이 블로그 게시물의 데이터 사이에 불일치가 발생했습니다. 이 블로그 게시물의 데이터 요소를 수정했습니다.
Google I/O 2018의 What's new in Android security(Android 보안의 새로운 내용) 세션 중에 공유한 바와 같이, 투명성과 개방성은 Android가 지향하는 가치에서 중요한 부분입니다. 우리는 새로운 기능과 향상된 점에 관해 블로그를 통해 정기적으로 정보를 공유하고 Android 생태계의 트렌드를 잘 보여주는 연간 Android Security Year in Review(Android 보안 검토 보고서)를 발간합니다. 이 사안에 대해 더 자주 정확한 통계와 정보를 제공하기 위해, 우리는 분기별 Android Ecosystem Security Transparency Report(Android 생태계 보안 투명성 보고서)를 도입합니다. 이 보고서는 정부와 기업의 정책과 행동이 개인정보 보호, 보안 및 온라인을 통한 정보 액세스에 어떤 영향을 미치는 보여주기 위해 2010년에 시작한 투명성 보고서 사이트에 최근에 추가된 보고서입니다.
이 Android 생태계 보안 투명성 보고서에서는 Google Play 프로텍트가 정기적으로 실시하는 전체 기기 검사를 통해 PHA가 설치된 기기를 탐지해내는 빈도에 관해 다룹니다. Google Play 프로텍트는 Android 기기에 내장된 보호 기능으로, Google Play 내부와 외부에서 매일 500억 개 이상의 앱을 검사합니다. 이러한 검사를 통해 잠재적으로 위험한 애플리케이션(PHA)의 증거를 찾습니다. 검사를 통해 PHA를 찾아낼 경우, Google Play 프로텍트는 사용자에게 이를 경고하고 PHA를 중지하거나 삭제할 수 있습니다. 2014년부터 발간된 Android의 첫 연례 Android 보안 검토 보고서에 따르면 PHA가 설치된 기기는 1% 미만이었습니다. 이 비율은 시간이 흐르면서 꾸준히 감소했으며 2018년에 이르기까지 이러한 하향 추세는 계속되고 있습니다. 투명성 보고서에서는 시장 부문(PHA의 출처가 Google Play이든 Google Play 외부이든 무관), Android 버전, 국가라는 세 가지 영역으로 구분된 PHA 비율을 다룹니다.
시장 부문별로 잠재적으로 위험한 애플리케이션이 설치된 기기
Google은 앱의 출처에 상관없이 Android 기기를 보호하기 위해 최선을 다합니다. 예년의 추세를 계속 이어받아, Google Play에서만 앱을 다운로드하는 Android 기기는 다른 소스에서 앱을 다운로드하는 기기에 비해 PHA를 받을 확률이 9배나 낮습니다. Google Play에 출시되는 앱은 출시 전에 Google Play 정책을 충실히 따르는지 확인하기 위한 애플리케이션 검토 과정을 거칩니다. Google은 위험 점수 평가 도구를 사용하여 앱을 분석함으로써 잠재적으로 위험한 동작을 탐지합니다. Google의 애플리케이션 위험 분석기는 뭔가 미심쩍은 점이 있는 앱을 발견하면 그 앱을 신고하고 필요한 경우 수동으로 검토할 수 있도록 보안 분석가에게 해당 PHA를 알려줍니다. 우리는 사용자가 Google Play 외부에서 자신의 기기로 다운로드하는 앱도 검사합니다. 의심스러운 앱을 찾아내는 경우 그 앱의 출처가 Google Play가 아니더라도 사용자를 보호하는 조치를 취합니다.
Android 생태계 보안 투명성 보고서에 나와 있는 시장 부문별로 잠재적으로 위험한 애플리케이션이 설치된 기기 차트는 시간의 경과에 따라 하나 이상의 PHA가 설치되어 있는 Android 기기의 비율을 보여줍니다. 이 차트에는 두 개의 선이 있는데, Google Play의 앱만 설치하는 기기의 PHA 비율을 나타내는 선과 Google Play 외부의 앱도 설치하는 기기의 PHA 비율을 나타내는 선입니다. 2017년, Google Play의 앱만 설치한 기기 중 하나 이상의 PHA가 설치된 기기는 평균 0.09%였습니다. 2018년의 1~3분기까지는 PHA 비율의 평균값이 더 낮아져 0.08%를 기록했습니다.
Google Play 외부의 앱을 설치한 기기의 보안도 개선되었습니다. 2017년에는 Google Play 외부의 앱을 설치한 기기 중 최대 0.82%가 PHA의 영향을 받았는데, 2018년 1~3분기에는 그 비율이 최대 0.68%로 떨어졌습니다. 2017 이후로, 우리는 2017년도 보안 검토 보고서의 10페이지에서 다룬 자동 사용 중지 기능을 확대하여 이 수치를 줄였습니다. 멀웨어 비율은 분기마다 다르지만, 우리의 통계 결과는 시간의 경과에 따라 계속 일관된 하향 추세를 보여주고 있습니다. 2019년 초에 공개할 2018년도 Android 보안 검토 보고서를 통해 더 자세한 내용을 공유하도록 하겠습니다.
Android 버전별로 잠재적으로 위험한 애플리케이션이 설치된 기기
Android가 최신 버전일수록 PHA의 영향을 덜 받습니다. 이런 결과를 얻은 것은 지속적인 플랫폼 및 API 강화, 꾸준한 보안 업데이트와 앱 보안, 민감한 정보에 대한 앱의 액세스를 줄이도록 유도하는 개발자 교육 등의 다양한 요인 덕분이라 생각합니다. 특히, Nougat, Oreo, Pie와 같은 최근에 나온 Android 버전은 이전에 PHA가 기기에서 지속성을 확보하고 PHA를 삭제하려는 시도로부터 스스로를 보호하도록 해준 권한 에스컬레이션 공격에 대해 더욱 복원력이 뛰어납니다. Android 버전별로 잠재적으로 위험한 애플리케이션이 설치된 기기 차트는 PHA가 설치되어 있는 기기의 비율을 보여주는데, 기기에서 실행 중인 Android 버전을 기준으로 정렬해서 표시합니다.
잠재적으로 위험한 애플리케이션이 설치된 기기 비율(10대 국가 기준)
전반적으로, 10대 Android 시장의 PHA 비율은 안정적인 상태로 유지되었습니다. 시장의 유동성으로 인해 분기별로 이러한 수치에 변동이 있긴 하지만, 2019년 1분기에 발표할 연간 보안 검토 보고서에서 이러한 변화를 주도한 요인에 대해 더욱 심층적으로 다룰 생각입니다.
잠재적으로 위험한 애플리케이션이 설치된 기기 비율(10대 국가 기준) 차트는 Android 기기가 가장 많이 사용되는 10개국에서 PHA가 하나 이상 설치된 기기의 비율을 보여줍니다. 인도는 평균 감염 비율이 34%나 급감하여 기기에 존재하는 PHA가 가장 많이 줄어든 나라로 확인되었습니다. 인도네시아, 멕시코, 터키 역시 각 지역에 있는 기기에 PHA가 존재할 가능성이 줄었습니다. 한국은 PHA가 설치된 기기의 비율이 0.1%에 불과해 가장 낮은 수치를 보였습니다.
보고서 확인시간의 경과에 따라, 우리는 Android 생태계 보안 투명성 보고서에 생태계의 상태에 대해 더 많은 통계 정보를 추가할 것입니다. 이 보고서에서 언급한 용어나 제품에 관한 의문 사항이 있으면 투명성 보고서의 FAQ 섹션을 살펴보세요. 우리가 새로 발표하는 블로그 게시물과 Gartner의 Mobile OSs and Device Security: A Comparison of Platforms(모바일 OS 및 기기 보안: 플랫폼 비교) 보고서에서 밝힌 Android의 성능을 보여주는 동영상도 확인해 보세요.

Google I/O를 위한 Google 어시스턴트 액션 제작기 (1)

SMS 및 통화 기록 정책 변경에 관한 알림

더욱 스마트한 영상 처리 앱 개발을 위하여 ML Kit에 얼굴 윤곽 기능이 추가됩니다

Android 생태계 보안 투명성 보고서

Contents

검색

Tag

Archive

Feed