Google Developers 팀에서는 구글 기술을 사용한 다양한 프로젝트를 전시하고, 많은 분들이 체험해볼 수 있도록 Google HackFair 를 매년 개최해오고 있습니다. 2012년을 시작으로 올해로 5회째를 맞이하는 Google HackFair 2017에서 여러분의 기발한 아이디어를 구글 기술로 현실화시킨 독창적인 프로젝트를 기다리고 있습니다!

<블로그 원문은 여기에서 확인하실 수 있으며, 블로그 번역 리뷰는 정승욱(Android GDE)님이 참여해 주셨습니다.>
Cloud Functions for Firebase 팀과 함께 일하면서 가장 마음에 드는 부분 중 하나는 개발자가 모바일 애플리케이션에서 Firebase가 호스팅하여 완전히 관리되는 백엔드로 로직을 이동하는 데 도움을 드리고 있다는 점입니다. 개발자는 몇 줄의 자바스크립트 코드를 작성하는 것만으로도 리얼타임 데이터베이스의 콘텐츠 변경을 자동으로 처리하는 로직을 통합할 수 있습니다. 여러 사람들이 빌드하는 내용을 지켜보는 건 정말 흥미로운 일입니다!

Cloud Next 2017에서 Cloud Functions가 처음 발표되었을 때 데이터베이스에 대한 모든 유형의 변경에 대해 사용 가능한 트리거는 하나뿐이었습니다. 이 트리거는 onWrite() 콜백을 사용하여 지정되며, 어떤 종류의 변경이 발생했는지 파악할 책임은 코드 작성자에게 있었습니다. 예를 들어, 앱에 대화방이 있고 새 메시지가 도착하면 Firebase 클라우드 메시징을 사용하여 대화방 사용자들에게 알림을 보내고 싶은 경우를 생각해봅시다. 이런 기능을 구현하기 위해 다음과 같은 코드를 작성할 수 있습니다.

exports.sendNotification = functions.database
        .ref("/messages/{messageId}").onWrite(event => {
    const dsnap = event.data  // a DeltaSnapshot that describes the write
    if (dsnap.exists() && !dsnap.previous.exists()) {
        // This is a new message, not a change or a delete.
        // Send notifications with FCM...
    }
})

쓰기 위치에 새 데이터가 있는지, 해당 위치에 이전 데이터가 없는지 확인하려면 이벤트 객체에서 DeltaSnapshot을 검사해야 합니다. 왜 이런 과정이 필요한 걸까요? 새 메시지, 업데이트된 메시지 및 삭제된 메시지를 포함하여 일치하는 위치에 있는 데이터가 변경되는 모든 경우에 onWrite()가 트리거되기 때문입니다. 그러나 이 함수는 새로운 메시지에만 관심이 있으므로 쓰기가 업데이트 또는 삭제가 아닌지 확인해야 합니다. 업데이트 또는 삭제가 있었다면, 이 함수가 계속 트리거되어 즉시 반환됩니다. 이러한 추가 실행에는 비용이 소요되는데, 유용한 작업을 수행하지 않는 함수에 대해 요금이 발생되도록 하려는 개발자는 없을 것입니다.

변경 사항

Cloud Functions 데이터베이스 트리거에서 더 이상 이러한 추가 검사가 필요하지 않다는 희소식을 전해 드립니다! firebase-functions 모듈 버전 0.5.9부터는 onCreate(), onUpdate(), onDelete()라는 세 가지 유형의 데이터베이스 트리거를 작성할 수 있습니다. 이러한 트리거는 변경된 유형을 인식하고 개발자가 바라는 변경의 유형에만 응답하여 실행됩니다. 이제 위의 함수를 다음과 같이 작성할 수 있습니다.

exports.sendNotification = functions.database
        .ref("/messages/{messageId}").onCreate(event => {
    // Send notifications with FCM...
})

여기서는 같은 위치에 있는 데이터에 대한 어떤 후속 업데이트에 대해서도 이 함수가 다시 트리거되는 문제에 대해 걱정할 필요가 없습니다. 이 함수는 읽기도 쉬울 뿐더러, 운영 비용도 적게 듭니다.

참고로, onWrite()는 사라진 게 아닙니다. 원한다면 언제든지 작성하는 함수와 함께 이 함수를 계속 사용하실 수 있습니다.

onWrite() 및 onUpdate()로 무한 루프 방지

이전에 onWrite()를 사용하여 한 위치에서 데이터를 추가하거나 변경한 적이 있다면, onWrite() 중에 해당 데이터를 변경함으로써 onWrite()가 다시 한 번 호출된다는 점을 알고 계실 겁니다. (모든 쓰기가 쓰기로 카운트되기 때문입니다.)

메시지 작성 후 메시지의 lastUpdated 속성을 업데이트하는 다음 함수를 고려하세요.

exports.lastUpdate = functions.database
        .ref("/messages/{messageId}").onWrite(event => {
    const msg = event.data.val()
    msg.lastUpdated = new Date().getTime()
    return event.data.adminRef.set(msg)
})

얼핏 보면 괜찮은 것 같지만 뭔가 중요한 내용이 빠져있습니다. 이 함수는 자신이 트리거된 위치와 동일한 위치에 다시 쓰기 때문에 실제로는 onWrite()에 대한 또 다른 호출을 트리거합니다. 이에 따라 쓰기의 무한 루프가 발생하므로 두 번째 호출에서 벗어날 방법이 필요하다는 것을 알 수 있습니다.

onUpdate() 함수 구현에도 이런 문제가 있는 것으로 드러납니다. 이 특정 사례에서 한 가지 해결책은 lastUpdated의 기존 값을 확인하여 현재 날짜보다 30초 이상 오래되지 않은 경우 벗어나는 것입니다. 따라서 onUpdate()를 사용하여 이 함수를 다시 작성한다면 다음과 같은 내용일 수 있습니다.

exports.lastUpdate = functions.database
        .ref("/messages/{messageId}").onUpdate(event => {
    const msg = event.data.val()
    const now = new Date().getTime()
    if (msg.lastUpdated > now - (30*1000)) {
        return
    }
    msg.lastUpdated = now
    return event.data.adminRef.set(msg)
})

이제 이 함수는 약간의 추가 로직으로 무한 루프를 방지합니다.

이러한 새로운 트리거를 사용하려면 firebase-functions 모듈을 0.5.9로 업데이트해야 합니다. 이런 업데이트에 대한 자세한 내용은 여기에 있는 문서를 참조하세요.

<블로그 원문은 여기에서 확인하실 수 있으며, 블로그 번역 리뷰는 신정규(Machine Learning GDE)님이 참여해 주셨습니다.>

게시자: 연구원 Luke Metz, 소프트웨어 엔지니어 Yun Liu(2016년 Google Brain Resident 참가자)

“통계, 물리학, 화학 등 다양한 학문적 배경을 가진 사람들이 모여서 운영되는 Google Brain Residency는 제가 딥 러닝과 심도 있는 프로그래밍을 모두 처음으로 접한 소중한 경험이었습니다. 컴퓨터 비전과 언어에 대한 딥 러닝, 강화 학습, 이론 등, 제가 선택한 다양한 주제를 연구하기 위해 제게 주어진 자율권을 활용했습니다. 원래는 통계학 박사 학위를 취득하려고 했지만 이곳에서의 경험이 자극제가 되어 올해 가을부터 시작되는 Stanford CS 프로그램에 등록했습니다.” - Melody Guan, 2016년 Google Brain Residency 참가자
이번 달로 Google Brain Residency 프로그램의 첫 클래스를 운영한 지 1년이 되어 마무리하게 되는데, 놀랍도록 성공적인 성과를 거두었습니다. 이 1년짜리 프로그램은 다양한 교육 배경과 경험을 가진 사람들이 기계 학습과 딥 러닝에 대해 연구할 수 있는 기회를 제공할 목적으로 마련되었습니다. 지난 1년 동안 프로그램 참가자인 레지던트들은 이론에서부터 로봇 공학과 음악 생성에 이르는 다양한 주제 분야에서 각종 연구 보고서를 꿰뚫고 Google 스케일의 실험을 설계 및 구현하고 최첨단 기술 연구에 참여하는 등, 분주한 활동을 해왔습니다.

1년 전, 프로그램의 시작과 함께 처음으로 구성된 초대 레지던트 클래스는 지금까지 ICLR(15건), ICML(11건), CVPR(3건), EMNLP(2건), RSS, GECCO, ISMIR, ISMB 및Cosyne 같은 유명 기계 학습 간행물에 30여 건의 논문을 발표했습니다. 현재 NIPS, ICCV, BMVC 및 Nature Methods에서 추가로 18건의 논문을 심사하는 중입니다. 위의 논문 중 두 건은 Distill에 발표되었는데, 디콘볼루션이 체커보드 아티팩트를 만들어내는지 탐구하고 필체 생성 모델의 시각화 방법을 제시하는 내용이었습니다.

레지던트들이 작성한 한 Distill 논문에서는 신경망이 필체를 생성하는 방식을 상호작용적으로 탐구합니다.

로봇이 관찰을 통해 인간의 움직임을 모방하는 방법을 배울 수 있는 시스템. 자세한 내용은 “Time-Contrastive Networks: Self-Supervised Learning from Multi-View Observation”(레지던트 Corey Lynch, P. Sermanet, J. Hsu, S. Levine 공저, CVPR Workshop 2017에 채택됨)을 참조하세요.

하드웨어 기기 할당을 위한 계산을 강화 학습을 사용하여 최적화하여 분산 딥 러닝 네트워크를 대규모로 훈련하는 모델. 자세한 내용은 “Device Placement Optimization with Reinforcement Learning”(레지던트 Azalia Mirhoseini 및 Hieu Pham, Q. Le, B. Steiner, R. Larsen, Y. Zhou, N. Kumar, M. Norouzi, S. Bengio, J. Dean 공저, ICML 2017에 제출됨)을 참조하세요.

딥 러닝 아키텍처에 중점을 두고 최적화 방법을 찾는 과정을 자동화하는 접근방식. “Neural Optimizer Search with Reinforcement Learning”(레지던트 Irwan Bello 및 Barret Zoph, V. Vasudevan, Q. Le 공저, ICML 2017에 제출됨) 논문의 최종 버전이 곧 발표 예정.

레지던트들은 범용 시퀀스-시퀀스 모델(번역에서 예시로 사용됨), 음악 합성, 인간 스케치 모방, 모델 트레이닝을 위한 서브샘플링, 모델에 대한 효율적인 "주의" 메커니즘, 시계열 분석(특히 신경과학 분야)을 통해 오픈소스 커뮤니티에 상당히 공헌하기도 했습니다.

이번 프로그램을 마친 레지던트들은 각자의 커리어에서 한 단계 더 높은 수준으로 도약하게 될 것입니다. 이들 중 다수는 Google Brain 팀에서 정직원으로 연구 경력을 계속 쌓아갈 예정입니다. 다른 레지던트들은 스탠포드, UC 버클리, 코넬, 옥스포드, NYU, 토론토, CMU 등의 대학교에서 최고의 기계 학습 박사과정을 선택했습니다. 이 프로그램에서 기울인 노력과 경험을 밑거름으로 하여 앞으로 맺게 될 결실을 지켜보는 것만으로도 너무나 자랑스럽고 뿌듯할 것입니다!

이번 주에 프로그램의 첫 클래스를 무사히 "졸업"하는 저희들을 이어 다음 클래스 참가자 35명이 1년간의 여정을 시작하게 됩니다. 다양한 경험과 교육 배경, 놀라운 재능을 가진 분들이라 역시 기대가 큽니다. 새로운 레지던트들이 저희가 지난 1년간 진행했던 첫 클래스의 성공을 기반으로 어떻게 성장해나가면서 팀을 새롭고 흥미진진한 방향으로 계속 이끌어갈지 정말 기대됩니다. 또 다른 흥미진진한 연구와 혁신의 한 해를 기대해봅니다!

2018년 Residency 프로그램 신청은 2017년 9월에 시작됩니다. 프로그램에 대해 자세히 알아보려면 g.co/brainresidency를 방문하시기 바랍니다.

<블로그 원문은 여기에서 확인하실 수 있으며, 블로그 번역 리뷰는 조은(우아한형제들)님이 참여해 주셨습니다.>
지난 4월에 여러분께 amp-bind를 사용해 더욱 향상된 AMP 페이지 상호작용을 시험해보는 걸 권했습니다. 오늘은 amp-bind의 정식 출시를 알리며 한다는 점을 알려드리면서 이를 계기로 특히 전자상거래 측면에서 AMP 지원 범위가 얼마나 확대될지 감을 잡으실 수 있도록 이 기능을 좀 더 상세히 살펴보도록 하겠습니다.

<블로그 원문은 여기에서 확인하실 수 있으며, 블로그 번역 리뷰는 양찬석(Google)님이 참여해 주셨습니다.>

 게시자: Fergus Hurley, Google Play 제품 관리자

열악한 앱 성능은 많은 사용자가 겪는 문제입니다. 혹시 최근에 사용중인 앱이 비정상 종료되거나, 응답 없음(ANR) 오류가 발생하거나, 혹은 렌더링 속도가 버벅된 경우가 있나요? 배터리가 너무 빨리 줄어들어, 배터리 사용량을 확인해봤더니 배터리를 과도하게 사용하는 앱이 있다면 어떻게 반응하실지 생각해보세요. 앱 성능에 문제가 있으면, 언젠가 사용자가 그 사실을 알게됩니다. 실제로 Google Play의 앱 리뷰 내용을 내부 분석한 결과, 별 1개짜리 리뷰 중 절반이 앱의 안정성에 대해 언급한 것으로 나타났습니다.

반대로, 사람들은 최고의 성능을 보이는 앱에는 계속해서 후한 평점과 호의적인 리뷰로 화답합니다. 그 결과 Google Play에서 순위가 올라가고 설치 수도 증가하게 됩니다. 뿐만 아니라, 사용자가 앱을 더 많이 사용하고, 더 많이 앱에 참여하고 더 많은 시간과 비용을 기꺼이 투자합니다.

이번 I/O에서 Google Play Console의 새로운 안드로이드 바이탈(Android vitals) 대시보드가 발표되었습니다. 안드로이드 바이탈은 악성 앱 동작을 이해하고, 분석하는 데 도움이 되도록 설계되었습니다. 이를 활용해, 문제의 원인을 분석하고, 앱의 성능을 향상시키고, 앱 사용자를 더 행복하게 만들 수 있습니다.

Google Play Console의 안드로이드 바이탈

안드로이드 바이탈은 앱의 성능을 한 눈에 확인하고 주요 지표를 살펴볼 수 있는 출발점입니다. 대시보드는 개발자와 사업 팀 모두에게 똑같이 유용합니다. 주요 지표를 통해 앱의 성능을 객관적으로 모니터링하고, 실제 사용자 데이터를 분석하여 어떤 부분이 문제가 되는지 그리고 어떤 부분을 우선적으로 개선해야하는지에 관한 통찰을 얻을 수 있습니다.

안드로이드 바이탈은 사용자가 사용량 및 진단 데이터를 자동으로 공유하도록 허가한 안드로이드 기기에서 다음과 같은 데이터를 수집합니다.

• 안정성: ANR 비율 및 비정상 종료 비율
• 렌더링 시간: 느린 렌더링(16ms) 및 UI 프레임 멈춤 현상(700ms)
• 배터리 사용량: wake locks 점유 및 과도한 웨이크업

Busuu가 앱 성능 향상에 주력하여 4.1☆에서 4.5☆로 평점을 높인 방법을 살펴보세요.

Busuu는 세계 최대의 언어 학습 앱 중 하나입니다. 제품 책임자인 Antoine Sakho에게서 Busuu가 사용자 평점을 높인 비결을 들어보세요.

안드로이드 및 Google Play 도구를 활용해 앱 성능을 향상시키는 방법에 대해 자세히 알아보세요

대시보드에 표시되는 데이터 및 앱의 성능과 안정성을 향상시키는 방법을 이해하려면 안드로이드 바이탈의 모범 사례 문서를 읽어보세요. 또한, 잘못된 동작을 식별하고 수정하는 데 사용할 수 있는 안드로이드 및 Google Play 개발자 도구에 관한 I/O 세션 동영상도 참고하시기 바랍니다.


다른 Play Console 기능에 대해 자세히 알아보시고, Playbook 앱을 사용하여 최신 소식과 팁을 계속 확인하면서 Google Play에서 성공가도를 달리시기 바랍니다. 지금 바로 베타에 가입하고 설치해 보세요.

<블로그 원문은 여기에서 확인하실 수 있으며, 블로그 번역 리뷰는 양찬석(Google)님이 참여해 주셨습니다.>
지난 4월 Python용 Firebase Admin SDK가 정식 출시되었습니다. 첫 번째 버전은 Firebase 인증 기능과 관련된 두 가지 주요 기능 - 맞춤 토큰 작성 및 ID 토큰 인증 기능을 제공했습니다. 버전 2.1.0부터는 추가로 Firebase 실시간 데이터베이스 지원 기능을 제공합니다.

구현 방식의 차이로 인해, 새롭게 추가된 API는 기존 Admin SDK(Node.js 및 자바)에서 제공하던 데이터베이스 API와는 한 가지 큰 차이점이 있습니다. 실시간 이벤트 리스너를 지원하지 않는다는 점입니다. 현재 Python Admin SDK에서는 실시간 업데이트 알림을 받기 위해, 이벤트 리스너를 데이터베이스 참조에 추가할 수 없습니다. 대신, 모든 데이터 획득 작업이 블로킹(blocking) 방식으로 이루어집니다. 이러한 차이가 있지만, 여전히 이 API를 활용해 다양한 일을 수행할 수 있습니다.

Python Admin SDK의 데이터베이스 모듈을 사용하면 기본 데이터 조작 작업과 고급 쿼리를 모두 수월하게 처리할 수 있습니다. Python 환경에서 데이터베이스와 상호작용을 시작하려면, 우선, 접근할 실시간 데이터베이스 URL을 사용해 SDK를 초기화 합니다.

import firebase_admin
from firebase_admin import credentials

cred = credentials.Cert('path/to/serviceKey.json')
firebase_admin.initialize_app(cred, {
    'databaseURL' : 'https://my-db.firebaseio.com'
})

그런 다음 SDK의 db 모듈에서 데이터베이스 참조를 가져옵니다. 일반적인 데이터베이스 작업을 위한 기능들이 Python 메서드(get(), set(), push(), update() 및 delete())로 노출되어 있습니다.

from firebase_admin import db

root = db.reference()
# Add a new user under /users.
new_user = root.child('users').push({
    'name' : 'Mary Anning', 
    'since' : 1700
})

# Update a child attribute of the new user.
new_user.update({'since' : 1799})

# Obtain a new reference to the user, and retrieve child data.
# Result will be made available as a Python dict.
mary = db.reference('users/{0}'.format(new_user.key)).get()
print 'Name:', mary['name']
print 'Since:', mary['since']

Firebase 실시간 데이터베이스에서 모든 데이터 값은 JSON으로 저장됩니다. Python Admin SDK를 활용해 어떻게 JSON과 Python의 네이티브 데이터 형식을 오고 갈 수 있는지 잘 살펴보시기 바랍니다.

고급 쿼리를 실행하려면 데이터베이스 참조에서 사용할 수 있는 order_by_* 메서드 중 하나를 호출합니다. 쿼리 객체가 반환되며, 해당 쿼리 객체를 대상으로 추가적인 API를  실행할 수 있습니다. 예를 들어, 아래 코드조각에서 처럼 API를 호출하여, limit 쿼리와 range 쿼리를 실행하고 정렬된 결과를 가져올 수 있습니다.

from firebase_admin import db

dinos = db.reference('dinosaurs')

# Retrieve the five tallest dinosaurs in the database sorted by height.
# 'result' will be a sorted data structure (list or OrderedDict).
result = dinos.order_by_child('height').limit_to_last(5).get()

# Retrieve the 5 shortest dinosaurs that are taller than 2m.
result = dinos.order_by_child('height').start_at(2).limit_to_first(5).get()

# Retrieve the score entries whose values are between 50 and 60.
result = db.reference('scores').order_by_value() \
    .start_at(50).end_at(60).get()

새로운 API에 대한 자세한 내용은 Admin SDK 문서를 살펴보시기 바랍니다. Github 리포지토리도 확인해보시고, 문제가 있는 경우 알려주시거나, 직접 패치를 제공해 주셔도 좋습니다. Admin SDK를 더욱 개선하는 데 도움을 주시면 고맙겠습니다. 사실, 여러분의 지속적인 피드백이 이처럼 짧은 기간에 이 API를 만들고 출시하는 데 좋은 자극제가 되었습니다. Firebase로 즐겁게 코딩해 보세요!

<블로그 원문은 여기에서 확인하실 수 있으며, 블로그 번역 리뷰는 곽동현(Machine Learning GDE)님이 참여해 주셨습니다.>

게시자: Łukasz Kaiser, Google 브레인 팀 수석 연구원

딥 러닝(DL)은 기계 번역, 음성 인식 및 물체 감지와 같은 많은 유용한 기술의 급속한 발전을 이끌었습니다. 연구 커뮤니티에서는 실험 결과를 재현하고 딥 러닝을 발전시키는 데 도움을 주려고 저자들이 공개한 코드를 쉽게 찾아볼 수 있습니다. 그러나 이러한 DL 시스템은 대부분 상당한 엔지니어링 작업이 필요하고 특정 문제 또는 아키텍처에 대해서만 작동할 수 있는 고유한 실험 설정을 사용하므로, 새로운 실험을 실행하고 그 결과를 비교하기가 어렵습니다.

오늘 우리는 설레는 마음으로 TensorFlow의 딥 러닝 모델의 학습을 위한 오픈 소스 시스템인 Tensor2Tensor(T2T)를 공개합니다. T2T는 번역, 파싱, 이미지 캡션 등과 같은 다양한 ML 애플리케이션용 최고성능 모델을 쉽게 만들 수 있게 하여, 이전보다 훨씬 빠르게 다양한 아이디어를 탐색할 수 있게 해줍니다. 이 릴리스에는 DL 연구의 시작에 도움이 되는 몇몇 최신 논문(Attention Is All You Need, Depthwise Separable Convolutions for Neural Machine Translation 및 One Model to Learn Them All)에서 발표한 최고의 모델을 비롯한 데이터셋 및 모델의 라이브러리가 포함되어 있습니다.

번역 모델	학습 시간	BLEU(베이스라인과의 차이)
Transformer(T2T)	3일(8개의 GPU)	28.4(+7.8)
SliceNet(T2T)	6일(32개의 GPU)	26.1(+5.5)
GNMT + 전문가 혼합	1일(64개의 GPU)	26.0(+5.4)
ConvS2S	18일(1개의 GPU)	25.1(+4.5)
GNMT	1일(96개의 GPU)	24.6(+4.0)
ByteNet	8일(32개의 GPU)	23.8(+3.2)
MOSES(구문 기반의 베이스라인)	해당 없음	20.6(+0.0)

T2T가 제공할 수 있는 향상 사항의 한 예로, 우리는 기계 번역에 라이브러리를 적용했습니다. 위의 표에서 볼 수 있듯이, 2개의 서로 다른 T2T 모델인 SliceNet과 Transformer는 이전의 최고성능 모델인 GNMT+MoE를 능가합니다. 최고의 T2T 모델인 Transformer는 표준 GNMT + MoE 모델보다 3.8점 높고 이 모델 자체는 베이스라인인 구문 기반 번역 시스템, MOSES보다 4점 높았습니다. 특히 T2T를 사용하면 단일 GPU로 하루 만에 이전의 최고성능 결과를 달성할 수 있습니다. 작은 Transformer 모델(위에 표시되지 않음)은 단일 GPU에서 1일 학습 후 24.9 BLEU를 달성합니다. 이제 GPU를 사용하는 모든 사람들이 스스로 훌륭한 번역 모델을 고안할 수 있습니다. github 저장소에 이를 수행하는 방법에 대한 설명이 있습니다.

모듈식 멀티태스킹 교육

T2T 라이브러리는 친숙한 TensorFlow를 사용하여 개발되었으며, 데이터셋, 모델 아키텍처, 옵티마이저, 학습률 감소 방법, 하이퍼 파라미터 등과 같이 딥 러닝 시스템에 필요한 여러 가지 요소를 정의합니다. 결정적으로, 이 모든 부분 요소들 사이에 표준 인터페이스를 반드시 사용하고 최신 ML 모범 사례를 구현합니다. 따라서 모든 데이터셋, 모델, 옵티마이저 및 하이퍼 파라미터 셋을 선택하고 학습을 실행하여 어떻게 수행되는지 확인할 수 있습니다. 아키텍처를 모듈화했으므로 입력 데이터와 예측된 출력 간의 모든 부분이 텐서-to-텐서 함수입니다. 모델 아키텍처에 대한 새로운 아이디어가 있다면 전체 구현을 바꿀 필요가 없습니다. 텐서르 ㄹ입력으로 받고 텐서를 출력하는 함수를 정의하여, 베딩 부분과 Loss함수 및 기타 모든 부분을 그대로 유지한 채, 모델의 중간 부분을 수정할 수 있습니다.

<블로그 원문은 여기에서 확인하실 수 있으며, 블로그 번역 리뷰는 Justin Hong(Google)님이 참여해 주셨습니다.>
게시자: Wayne Piekarski, IoT 디벨로퍼 어드보케

오늘 우리는 Android Things Console의 프리뷰를 출시합니다. 개발자는 이 콘솔을 통해 공장 출고 시 이미지를 생성하고 운영체제 및 개발자가 제공하는 APK의 업데이트를 비롯해, Android Things IoT 기기에서 실행되는 소프트웨어를 관리할 수 있습니다. 기기가 곧 제공될 예정인 Developer Preview 5와 같은 향후 업데이트를 받으려면 Android Things Console을 통해 다운로드한 시스템 이미지를 기기에 플래싱 해두어야 합니다. Google은 OTA(Over-The-Air) 업데이트를 지원하는 인프라를 모두 제공하므로, 개발자로서는 자신의 특정 애플리케이션에 집중할 수 있으며 이전보다 더욱 빠르고 안정적으로 시장에 진입하기 위해 OTA 인프라를 자체적으로 만들 필요가 없습니다.

콘솔을 살펴보고 콘솔이 제공하는 기능을 알아보도록 하겠습니다.

제품 제작 및 제품 설정

개발자는 먼저 기기의 기반이 되는 SoM(System-on-Module)의 유형과 이름을 선택하는 과정을 포함하는 제품 정의 단계부터 시작합니다. 많은 개발자가 IoT 기기를 빌드할 때 Google Play 서비스를 사용하고 싶어 하는데, 이 콘솔에서는 옵션 기능으로 구성됩니다. OEM 파티션 크기도 구성되는데, 향후 확장되는 APK 크기를 포함할 수 있을 정도로 커야 합니다.

시스템 이미지

기기가 콘솔로부터 올바른 제품에 대한 향후 업데이트를 받으려면 초기 기본 펌웨어가 필요합니다. 초보자의 경우, 단순하게 'Create Build Configuration'을 사용하여 제품에 맞게 구성된 빈 번들이 포함된 기본 공장 출고 시 이미지를 빌드할 수 있습니다. 그런 다음 이 시스템 이미지를 기기로 다운로드하여 플래싱할 수 있고, APK를 테스트용으로 사이드로딩하여 개발 작업을 시작할 수 있습니다.

이후에 기기에 배포할 애플리케이션 준비가 끝나면 번들 ZIP 파일을 콘솔로 업로드할 수 있습니다. 이 번들은 기본 APK 파일과 APK에서 서비스로 제공되는 사용자 공간 드라이버, 그리고 기본 APK에서 실행되는 추가 APK를 모두 포함하는 ZIP 파일이며 부팅 중에 표시되는 bootanimation.zip 파일도 포함됩니다. 이렇게 업로드된 번들 파일은 기기에 배포할 수 있는 완전한 시스템 이미지의 생성에 사용됩니다. 번들 파일 콘텐츠에 대한 자세한 내용은 관련 문서에서 확인할 수 있습니다.

OTA 업데이트

이 탭에서는 개발자가 기기 그룹에 푸시할 시스템 이미지를 선택할 수 있습니다. 개발자가 한 시스템 이미지를 선택한 후 'Push to Devices'를 실행하면 프로세스가 시작됩니다. 그러면 이 이미지가 모든 기기로 안전하게 푸시되고 A/B 파티션 중 하나에 설치된 후 기기가 재부팅될 때 활성화됩니다. 장애가 감지되면 기기가 이전에 정상 작동한 것으로 알려진 버전으로 자동으로 롤백되므로 향후 업데이트가 계속 가능합니다. 개발자는 Android Things의 새 릴리스를 사전에 테스트한 후 기기를 자동으로 업데이트할지 결정할 수 있습니다.

피드백

Android Things Console은 현재 프리뷰로 제공되고 있으며, 더 많은 기능과 사용자 지정 옵션을 추가하기 위해 노력하고 있습니다. Android Things 개발자께서는 모두 Android Things Console을 사용해보고 피드백을 주시면 감사하겠습니다. 버그 신고 및 기능 요청을 작성하고 Stack Overflow에 질문 사항을 올리는 방법으로 피드백을 제공해 주실 수 있습니다. Android Things Console에 대해 더 자세히 알아보려면 다음의 상세 문서를 검토하시기 바랍니다. 또한, Google+를 통해 최신 정보를 구하고 아이디어를 토론할 수 있으니 Google IoT 개발자 커뮤니티에 가입하시기를 권해 드립니다.

<블로그 원문은 여기에서 확인하실 수 있으며, 블로그 번역 리뷰는 정승욱(Android GDE)님이 참여해 주셨습니다.>
많은 Firebase 개발자들은 대개 Android, iOS 또는 웹용이거나 이 세 가지를 전부 지원하는 앱 자체에만 집중합니다. 저처럼 개발 업무 중 클라이언트 측에서 대부분의 시간을 보내는 분이라면, 백엔드 구성 요소를 다루는 일 역시 번거로울 수 있습니다. 이제 Cloud Functions for Firebase를 사용하여 서버를 관리할 필요 없이 자바스크립트로 아주 쉽고 재미있게 백엔드 코드를 작성하고 배포할 수 있습니다. 개인적으로 제가 편하게 느끼는 개발 환경은 Android입니다. 그래서 저는 Cloud Functions를 파악하기 위해 자바스크립트 공부를 다시 하고 Cloud Functions가 백엔드 코드 실행에 사용하는 node.js를 배우는 시간을 보냈습니다.

Promise 소개

그 과정에서 저는 자바스크립트에서 비동기 작업을 관리하는 새로운 방법을 배웠습니다. 브라우저에서 자바스크립트로 작업해봤거나 Cloud Functions로 작업한 경험이 있는 분이라면 이미 Promise라고 하는 클래스에 익숙하실 겁니다. Promise는 비동기 작업을 처리할 수 있는 매우 일반적인 방법입니다. Android 개발자에게 가장 쉽게 이해되는 개념으로 설명하자면, Firebase API를 다룰 때 가끔 사용하는 Task API와 비슷한 것이라 생각하시면 됩니다.

Promise를 사용하면 데이터베이스 쓰기 또는 네트워크 요청과 같이 비동기식으로 실행하는 작업 단위에 응답할 수 있습니다. Cloud Functions는 Promise를 인식합니다. 어떤 함수가 비동기 작업 중에 계속 활성 상태를 유지하도록 하려면 이 함수에서 Promise를 반환하는 방법을 쓰면 됩니다(클라이언트로 응답을 전송해야 하는 HTTP/S 트리거는 예외). Promise를 반환할 때는 해당 함수에서 수행되는 모든 비동기 작업이 완전히 완료된 후 "확인"되는 Promise를 반환해야 합니다. 많은 개발자들이 Firebase YouTube 채널의 동영상이 Cloud Functions에서 Promise의 작동 방식을 이해하는 데 무척 유용하다는 사실을 깨달았습니다.


이 동영상에서는 Jen이 Promise를 다룰 수 있는 두 가지 기본 방법에 대해 설명합니다. 첫째, Promise에 then() 메서드를 사용하여 작업 항목을 순차적으로 연결하는 방법이 있습니다. 여기서는 다음 작업 항목이 이전 항목 결과의 영향을 받습니다. 둘째, Promise.all() 메서드가 있습니다. 이 메서드는 병렬로 발생하는 여러 작업 항목이 모두 완료된 후 확인되는 새 Promise를 생성합니다. 이 두 메커니즘을 적절히 활용하여 함수에서 일반적으로 수행되는 대부분의 작업을 관리할 수 있습니다. 작업이 완료되면 Cloud Functions 환경이 정리할 시점을 알 수 있도록 함수에서 최종 Promise를 반환합니다.

ECONNRESET 때문에 힘드셨나요?

단순한 함수에서는 무척 쉽사리 효과를 볼 수 있습니다. 하지만 저 자신을 비롯한 많은 개발자들은 Promise를 많이 포함한 많은 작업을 진행할 때 복잡한 함수는 정말 관리하기 어렵다는 점을 뼈저리게 느끼게 되었습니다. 제대로 관리되지 않는 Promise로 인해 나타나는 증상 중 하나는 Firebase 콘솔의 함수 로그에 다음 오류가 표시되는 것입니다.

Error: read ECONNRESET

이 오류는 몇 가지 상이한 점을 의미할 수 있습니다. 어떤 경우에는 클라이언트 라이브러리에 버그가 발생한 것일 수 있습니다. 또 어떤 경우에는 Promise를 다룰 때의 흔한 실수로 인해 나타나는 증상입니다.

네트워크 연결이 완료되기 전에 함수가 종료되는 경우 열려 있는 연결을 강제로 차단할 수 있다는 뜻이며, 이때 로그에는 ECONNRESET이 남습니다. 다음은 이러한 오류가 발생할 수 있는 상황입니다.

비동기 작업 중 세 가지 항목을 시작하려고 하는데, 작업 완료 시 확인되는 Promise를 반환하는 doSomeAsync()라는 함수에서 작업이 시작되고, 다음과 같이 세 번째 작업에서 Promise를 반환한다고 생각해 봅시다.

doSomeAsync(x)
doSomeAsync(y)
return doSomeAsync(z)

이 함수에서 Promise를 반환하는 것은 좋습니다. 하지만 Cloud Functions에는 모든 작업이 완전히 완료된 후 확인되는 새 Promise가 필요합니다. 마지막 작업 항목이 항상 다른 두 작업 항목 이후에 끝나리라는 보장이 없으면 Cloud Functions가 함수를 일찍 정리하며, 이로 인해 문제가 발생할 수 있습니다. 대신, 다음과 같이 모든 작업의 모든 Promise를 다른 모든 Promise가 확인된 후에만확인되는 새 Promise로 결합해야 합니다.

const promise_x = doSomeAsync(x)
const promise_y = doSomeAsync(y)
const promise_z = doSomeAsync(z)
return Promise.all([promise_x, promise_y, promise_z])

개발자가 함수에서 시작하는 비동기 작업의 모든 항목을 일일이 추적하지 않을 경우, 로그에 두려워하던 ECONNRESET 오류가 표시될 수 있으며 작업 항목이 예상대로 작동하지 않을 수 있습니다. 모든 Promise를 유지하려면 실제로 약간 부지런을 떨어야 할 수도 있습니다!

더 복잡한 함수의 예를 보고 싶으면 Google I/O '17에서 제가 진행한 세션에서 작성한 오픈소스 tic-tac-toe 웹 게임을 참조하시기 바랍니다. 이를 통해 Firebase를 사용하여 전체적으로 어떻게 빌드했는지 알 수 있을 것입니다.


Cloud Functions 및 기타 Firebase 제품에 대한 추가 가이드 및 콘텐츠는 YouTube Firebase 채널과 Firebase 블로그를 확인하시기 바랍니다.

<블로그 원문은 여기에서 확인하실 수 있으며, 블로그 번역 리뷰는 김태호(Google)님이 참여해 주셨습니다.>
7,000명이 넘는 개발자들이 쇼어라인 앰피시어터(Shoreline Amphitheater)에서 열린 올해의 Google I/O에 참가하면서 이곳 마운틴 뷰는 정말 숨가쁘게 돌아갔습니다. 우리는 여러 가지 중요한 제품 발표를 진행했지만 그중에서도 특히 새롭게 리디자인된 AdMob이 가장 기대되는 제품입니다!

많은 개발자 여러분이 수익을 창출하기 위해 인앱 광고를 활용하고 있습니다. 실제로 백만 개가 넘는 앱이 현재 AdMob을 사용하여 iOS 및 Android 환경에서 수익을 내고 있습니다. 그리고 지금까지 Google이 여러분과 같은 개발자들에게 지불한 금액이 35억 달러를 넘어섰습니다. 하지만 우리는 개발자 여러분의 성공을 돕기 위해 훨씬 더 많은 일을 할 수 있을 것이라는 점을 알고 있었습니다. 그래서 개발자가 수익성 있는 사업을 더욱 빠르게 구축하고 규모를 확장해도 수익성을 유지할 수 있도록 AdMob 플랫폼을 처음부터 다시 빌드했습니다.

새로운 사용자 인터페이스를 통한 사용 편의성 실현

<블로그 원문은 여기에서 확인하실 수 있으며, 블로그 번역 리뷰는 양찬석(Google)님이 참여해 주셨습니다.>
게시자: Xiaowen Xin 및 Renu Chaudhary, Android 보안 팀

외부 콘텐츠를 잘 표시하는 것이 핵심 기능인 앱들이 있습니다. 뉴스 리더 앱은 주요 뉴스 기사를 보여주고, 쇼핑 앱은 판매 제품의 목록을 표시해야 합니다. 이런 경우, 신뢰할 수 없는 외부 콘텐츠를 잘 처리하는 것이 정말 중요합니다. 공격자가 즐겨 사용하는 방식 중 하나는 잘못된 형식의 콘텐츠를 전달하는 것 입니다. 이에 올바르게 대처하지 못하면, 앱의 동작이 잘못되거나 주요한 정보가 노출 될 위험이 있습니다.

많은 안드로이드 앱이 WebView를 사용하여 신뢰할 수 없는 콘텐츠를 다루고 있습니다. 구글은 악성 콘텐츠에 의해 다른 콘텐츠나 앱이 손상되지 않도록 수년에 다양한 개선 작업을 진행 해왔습니다. 안드로이드 롤리팝 버전부터 WebView를 독립된 APK로 제공하고 있으며, Play Store에서는 6주마다 WebView 업데이트를 진행하여 사용자에게 신속하게 중요 수정 사항을 제공하고 있습니다. 이에 더 나아가, 새롭게 소개되는 최신 WebView에서는 중요한 보안 관련 기능 두 가지가 소개되었습니다.

안드로이드 O에서 렌더러 프로세스 격리

안드로이드 O부터는 WebView의 렌더러가 호스트 앱과 별개의 격리된 프로세스에서 실행됩니다.

<크롬(Chrome)과 유사하게, WebView는 이제 두 단계로 격리되며 더 향상된 보안을 제공합니다.>

1. 렌더링 엔진이 별개의 프로세스로 분할됩니다. 이는 호스트 앱을 렌더러 프로세스에서 발생하는 버그 또는 비정상 종료로부터 보호하고, 렌더러를 악용할 수 있는 악성 웹사이트가 호스트 앱을 악용하기 더욱 어렵게 만듭니다.
2. 이를 더 강화하기 위해, 렌더러 프로세스는 한정된 권한을 갖은 격리된 프로세스 샌드박스 내에서 실행됩니다. 예를 들어, 렌더링 엔진은 자체적으로 디스크에 쓰거나 네트워크와 통신할 수 없습니다.
   
   또한, 렌더링 엔진은 안드로이드 환경의 크롬에서 사용하는 것과 동일한 seccomp 필터(seccomp에 대한 블로그 게시물을 곧 발표할 예정임)에도 바인딩됩니다. seccomp 필터는 렌더러 프로세스가 액세스할 수 있는 시스템 API의 종류와 기능을 제한 할 수 있습니다.

세이프 브라우징 통합

최신 버전의 WebView에는 잠재적으로 위험할 수 있는 사이트를 감지하여 사용자에게 경고하는 구글의 세이프 브라우징 기능이 통합되었습니다. 올바르게 구성된 WebView는 세이프 브라우징의 멀웨어 및 피싱 데이터베이스를 바탕으로 요청된 URL을 검사하고 사용자가 위험한 사이트를 방문하기 전에 경고 메시지를 표시합니다. 크롬의 경우 한 달에 2억 5천만 건 이상의 요청이 세이프 브라우징 기능의 혜택을 받고 있습니다. 이제는 안드로이드 WebView에서도 이러한 정보를 확인할 수 있습니다.

세이프 브라우징 활성화

앱의 모든 WebView에 대해 세이프 브라우징을 활성화하려면 매니페스트 태그에 다음을 추가하세요.

<manifest>
     <meta-data android:name="android.webkit.WebView.EnableSafeBrowsing"
                android:value="true" />
      . . .
     <application> . . . </application>
</manifest>

WebView는 별도의 APK로 배포되므로, Android 5.0 이상을 실행하는 기기에서 현재 WebView용 세이프 브라우징을 이용할 수 있습니다. 매니페스트에 단 한 줄만 추가하여 앱을 업데이트하고 대부분의 사용자들을 보호할 수 있도록 보안을 즉시 강화할 수 있습니다.

<블로그 원문은 여기에서 확인하실 수 있으며, 블로그 번역 리뷰는 문현경(Web Technologies GDE)님이 참여해 주셨습니다.>

작성자: 권순선, 아태지역 개발자 생태계 총괄 (Head of APAC Ecosystem, Developer Relations)

머신러닝은 이제 구글의 거의 모든 제품에서 다양하게 쓰이면서 많은 사용자들에게 편리하고 유용한 기능을 제공하고 있습니다. 이에 구글은 TensorFlow 머신러닝 프레임워크를 오픈소스로 공개하고 이를 클라우드에서 이용할 수 있는 Cloud ML을 제공하고 있을 뿐만 아니라 Vision API, Translation API 등 머신러닝 기술을 이용한 다양한 API들도 함께 제공하면서 전세계의 더욱 많은 개발자들이 머신러닝 관련 기술을 이용할 수 있도록 하는데도 많은 노력을 기울이고 있습니다.

머신러닝에 관심을 가지는 개발자들이 늘어나면서 한국에서는 TensorFlow Korea 사용자 모임에서 많은 개발자들이 다양한 정보를 공유하고 지식과 경험을 공유하고 있습니다. 이 TensorFlow Korea 사용자 모임의 주도로 7월 한달 동안 제주에서 전세계의 개발자들이 함께 모여 머신러닝 관련 기술을 함께 개발하는 머신러닝 캠프 제주 2017(이하 캠프)이라는 행사가 열리는데요. 구글도 여기에 카카오, 제주특별자치도, 국립제주대학교, 제주창조경제혁신센터와 함께 이 캠프를 후원하게 되어 매우 기쁘고 또 영광스럽게 생각합니다. 이 캠프에 선발된 개발자는 총 20명이며 여기에 멘토들이 함께하는데 총 633명이 캠프에 지원하였고 그중 절반 이상은 해외에서 신청하여 참석자를 선정하는데 매우 어려움이 있었습니다만 그만큼 많은 분들이 관심과 열의를 가지고 지원해 주셔서 또 기쁜 일이기도 했습니다. 최종 선발된 20명 중에서도 중국, 미국, 독일, 홍콩, 인도, 터키, 스웨덴, 헝가리 등 다양한 국적의 개발자들이 포함되어 명실공히 국제적인 규모가 되었습니다. (선정된 참석자들에게는 항공과 숙소 등이 모두 제공되며 머신러닝 개발에 필요한 구글 클라우드 크레딧도 함께 제공됩니다.) 캠프는 7월 3일에 시작되어 7월 28일에 참석자들이 그동안 개발한 결과물들을 공유하게 되는데 음성인식, 기계번역, 이미지 생성, 이미지 분석, 자율주행 등 다양한 분야를 대상으로 머신러닝 관련 기술들이 TensorFlow를 이용하여 개발될 예정이며 그 과정에서 개발된 코드들은 모두 GitHub에 공개될 예정입니다. 전체 프로젝트 목록은 여기에서 보실 수 있습니다. 7월 10일에는 캠프 참여자뿐만 아니라 국내외의 머신러닝 연구자/개발자들이 함께 참여하는 머신러닝 컨퍼런스도 개최됩니다. 여기에는 구글 브레인을 이끌고 있는 제프 딘(Jeff Dean) 시니어 펠로우와, 구글 브레인 내에서 텐서플로 팀을 이끌고 있는 라잣 몬가(Rajat Monga) 엔지니어링 디렉터가 화상 연결을 통해 참여할 예정이며, 조경현 뉴욕대 교수, 이홍락 미시건대 교수/구글 브레인팀 방문 과학자, 임재환 서던캘리포니아대 교수, 경기대학교의 최예림 교수 등 머신러닝 학계의 유명 석학이 함께 참여하여 머신러닝의 현재와 미래를 조망해보는 뜻깊은 시간을 가질 예정입니다. 머신러닝 컨퍼런스 참석을 희망하시는 분들은 온오프믹스에서 신청하실 수 있습니다.

또한 7월 11일과 25일에는 머신러닝에 관한 기초적인 교육 프로그램인 머신러닝 학습 캠프가 열리는데, 여기서는 처음 접하는 분들을 위해 머신러닝과 TensorFlow에 관한 기초적이고 간단한 내용을 다루어 보게 됩니다. 머신러닝 학습 캠프 참석자도 온오프믹스를 통해 추후 모집할 예정이니 많은 관심 부탁드립니다.

이번 머신러닝 캠프 제주 2017을 통해 다양하고 유용한 결과물들이 개발되고 이 과정에서 참석자들이 즐겁고도 유용한 시간을 보낼 수 있기를 기원합니다. 다시 한번, 이 의미있는 행사에 구글도 함께할 수 있게 되어 진심으로 기쁘게 생각합니다.