[go: up one dir, main page]

<블로그 원문은 여기에서 확인하실 수 있으며, 블로그 번역 리뷰는 김태호(Android GDE)님이 참여해 주셨습니다.>
게시자: Hoi Lam, 디벨로퍼 어드보케 

Telegram Messenger에서 크로스 플랫폼 지원

지난달, Android Wear 2.0의 다섯 번째이자 마지막 개발자 프리뷰가 발표되었습니다. 이 릴리스에서는 iOS 지원을 추가하고 다양한 버그 수정 및 개선 사항을 포함했습니다. 이 프리뷰로 컴파일된 앱을 Google Play Store에 최종 제출할 준비가 되었으므로, 이제는 앱을 게시할 차례입니다.

iOS 지원


2015년 이후로 Android Wear 시계를 iPhone과 페어링할 수 있으며, 이제는 iPhone과 페어링된 시계에 앱을 배포할 수 있게 되었습니다. 그렇게 하려면 시계 앱 매니페스트에 standalone=true 플래그를 설정하기만 하면 됩니다. 그러면 시계 앱에 Android 앱이 필요 없다는 점이 Play Store에서 인식되어, 시계 앱이 Play Store 상에서 iPhone과 페어링된 시계용 앱 목록에 나타날 수 있습니다. 시계 앱을 iPhone에 페어링하고 테스트하려면 다음 단계를 따르세요.

플랫폼은 배터리 절약과 네트워크 대역폭 간에 균형을 유지하므로, 독립형 앱의 사용 가능한 네트워크 대역폭은 예상보다 적을 수 있습니다. iPhone과 페어링된 시계에서 Wi-Fi 및 셀룰러 네트워크에 액세스하는 방법 등 네트워크 액세스 관련 내용은 가이드라인을 확인하세요.

또한, 이 개발자 프리뷰 릴리스에서는 iOS 기기와 페어링된 시계에서 실행되는 Android Wear 앱이 페어링된 iOS 기기에서 웹 페이지를 실행하기 위해 OAuthRemoteIntent와 같은 전화 핸드오프 플로우를 수행할 수 있게 될 것입니다.

Google Play Store에 앱 업로드


최종 개발자 프리뷰에서는 웨어러블 지원 라이브러리가 업데이트되었습니다. API 레벨 25와 이 지원 라이브러리로 컴파일된 앱은 Google Play Store에 배포할 준비가 된 것으로 간주됩니다. 이 개발자 프리뷰 릴리스에서는 프리뷰 시스템 이미지 또는 에뮬레이터에 대한 업데이트가 제공되지 않는다는 점에 유의하세요.

기타 개선 사항 및 버그 수정


  • 탐색 창: 플래그 설정을 전환하여 아이콘만으로 구성된 단일 페이지의 작업 창으로 전환하면 앱 내의 여러 뷰를 더 빠르고 효율적으로 탐색할 수 있습니다.
  • NFC HCE 지원: 이제 NFC 호스트 카드 에뮬레이션 FEATURE_NFC_HOST_CARD_EMULATION이 지원됩니다.
  • ProGuard 및 Complication API: ProGuard가 새롭게 구성되어, 컴플리케이션 데이터 컨테이너 클래스가 더 이상 난독 처리되지 않습니다. 따라서 워치 페이스가 컴플리케이션 데이터 제공자가 제공하는 데이터에 액세스하려고 할 때 발생하는 ClassNotFoundException 오류가 해결되었습니다.

탑이미지.jpg

Indie Games Festival 2017

구글플레이는 개발자들이 전 세계 수십억 유저들과 언제든 만날 수 있도록 연결하는 플랫폼으로서, 특히 한국에서 활약하고 있는 개발자들을 지원하여, 전 세계 유저들이 최고의 게임을 접할 수 있도록 최선을 다하고 있습니다.

Indie Games Festival 2017은 국내 최고의 인디 게임을 발굴하고 선보일 목적으로 진행되는 행사입니다. 이번 대회를 통해 여러분의 게임이 업계 전문가들과 세계 각국의 플레이어들로부터 주목 받는 절호의 기회가 되길 희망합니다. 또한 다음의 부상들을 통해 수상자에게 성장의 기회도 제공하고자 합니다.
  • 결승행사에서 게임을 소개할 수 있는 쇼케이스 기회 제공 
  • 구글플레이 스토어의 프리미엄 위치에 노출 
  • 유튜브 크리에이터와의 브랜디드 콘텐츠 제작 지원 
  • 구글플레이 최고의 파트너 대상 행사인 Playtime 2017 참가권 제공 
  • 안드로이드 개발자 및 구글플레이 소셜 채널에 프로모션 
  • 구글 클라우드 플랫폼 크레딧 제공 
  • 기타 다양한 혜택 제공

여러분의 게임을 전시하고 수상의 기쁨까지 누리고 싶다면?

지금 바로 대회에 참가해 보세요! 참가신청 하러가기

한국 최고의 인디 게임을 내 손으로 직접 투표하고 싶다면?

지금 바로 결승행사 관람을 신청해 보세요! 관람신청 하러가기

[주요 일정]

  • 2017년 2월 22일(수) > 대회 출품작 제출 시작 
  • 2017년 4월 02일(일) > 대회 출품작 제출 마감 
  • 2017년 4월 14일(금) > 대회 결승 후보 발표 
  • 2017년 4월 22일(토) > 공개 쇼케이스 및 결승 이벤트 개최 
  • 2017년 4월 23일(일) > 쇼케이스 
  • 2017년 5월~3개월간 > 결승 진출작 20개 멘토링 프로그램 진행 

상세 참가 자격조건 / 수상자에게 주어지는 다양한 혜택 / 결승행사 관람 및 세부 진행과정은 홈페이지를 통해 확인해 주시기 바랍니다.

* 대회 참가신청 접수 마감은 4월2일까지입니다.
* 대회에 참가하지 않더라도 일반관람을 신청하실 수 있습니다.
* 원활한 행사진행을 위해 가급적 사전등록을 해주시기 바랍니다.

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

작년에 Google I/O에서 Android Instant Apps 프리뷰가 공개되었습니다. Android 앱을 설치하지 않고도 실행할 수 있는 새로운 방법이죠. Google은 사용자의 불편을 최소화하면서 앱을 검색하고 실행할 수 있도록 최선을 다하고 있으며, Instant Apps는 그중 중요한 부분입니다.

Google은 소수의 개발자와 협력하여 사용자 환경과 개발자 환경을 개선하고 있습니다. 오늘은 제한된 테스트 환경에서 이런 Instant Apps 중 몇 개를 Android 사용자에게 처음으로 선보일 예정이며, 여기에는 BuzzFeed, Wish, Periscope 및 Viki의 앱이 포함됩니다. 사용자 피드백을 수집하고 제품에 적용함으로써 이러한 환경을 더 많은 앱과 사용자에게 확장할 수 있게 될 것입니다.

인스턴트 앱을 개발하려면 Instant Apps 기능을 활용할 수 있도록 기존 Android 앱을 업데이트한 다음, 앱 일부를 다운로드하여 즉시 실행할 수 있도록 앱을 모듈화해야 합니다. 이를 위해 지금까지와 동일한 Android API와 Android Studio 프로젝트를 사용하게 될 것입니다. 또한, 오늘 Instant Apps 개발을 준비하기 위한 몇 가지 중요한 절차를 밟을 수도 있습니다. 전체 SDK는 몇 개월 내에 제공될 예정입니다.

이미 수천 명의 개발자가 Instant Apps에 큰 관심을 보이고 있습니다. 많은 의견을 보내주세요. 올 후반기에 멋진 경험을 공유할 날을 손꼽아 기다리겠습니다. 계속 지켜봐 주세요!

게시자: Aurash Mahbod, Google Play 소프트웨어 엔지니어

<블로그 원문은 여기에서 확인하실 수 있습니다.>
게시자: Rahul Mishra, Android 보안 프로그램 관리자
2016년 4월, Android 보안 팀은 Google Play 앱 보안 향상(ASI) 프로그램이 개발자가 100,000개의 애플리케이션에서 보안 문제를 해결하는 데 어떤 도움을 주었는지 설명했습니다. 이후 저희는 11가지의 새로운 보안 문제를 탐지하여 개발자에게 알려주고 개발자의 앱 업데이트를 위한 리소스와 지침을 제공했습니다. 그 덕분에 90,000명 이상의 개발자가 275,000개 이상의 앱을 업데이트하는 성과를 거두었습니다!
ASI는 이제 개발자에게 26가지 잠재적 보안 문제를 알려줍니다. 이 프로세스를 더욱 투명하게 만들기 위해 저희는 개발자가 이러한 모든 보안 문제에 대한 정보를 한 곳에서 찾을 수 있는 새 페이지를 도입했습니다. 이 페이지에는 지침과 추가 지원 연락처가 있는 지원 센터 문서에 대한 링크가 포함되어 있습니다. 개발자는 이 페이지를 리소스로 사용하여 새로운 문제에 대해 알아보고 기존의 모든 문제들을 추적할 수 있습니다.

새로운 Android 개발자용 보안 페이지에서 최신 보안관련 게시물, 보안 관련 모범 사례 및 보안 검사 목록을 꼭 확인해 보세요. 이러한 모든 리소스의 목적은 일반적인 보안 개념에 대한 이해를 높이고 앱 관련 문제를 해결하는 데 도움이 되는 예시를 제공하기 위한 것입니다.

도움을 주고받을 수 있는 방법:
피드백이나 질문은 Google Play 개발자 도움말 센터를 통해 저희에게 알려주세요.
앱의 잠재적인 보안 문제를 신고하려면 security+asi@android.com으로 이메일을 보내 주세요.

<블로그 원문은 여기에서 확인하실 수 있으며, 블로그 번역 리뷰는 권순선(Google)님이 참여해 주셨습니다.>
게시자: Amy McDonald Sandjideh, TensorFlow 기술 프로그램 관리자

TensorFlow는 세상에 선을 보인 첫 해에 연구원, 엔지니어, 예술가, 학생 뿐만 아니라 언어 번역에서부터 피부암 조기 발견당뇨병 환자의 실명 예방에 이르는 모든 영역들에서 많은 사람들이 진전을 이루는 데 도움을 주었습니다. 6,000개가 넘는 온라인 오픈 소스 저장소에서 사람들이 TensorFlow를 사용하고 있습니다.

지난 15일, TensorFlow Developer Summit이 마운틴뷰에서 개최되었고 전 세계로 생중계되었으며, 이날 TensorFlow 1.0이 드디어 발표되었습니다.


더욱 빠른 속도: TensorFlow 1.0은 놀라울 정도로 빠릅니다! XLA는 향후 훨씬 더 나은 성능 향상을 위한 기틀을 마련하며, tensorflow.org에는 이제 최대 속도를 달성하기 위해 모델을 조정하는 데 활용할 수 있는 유용한 정보가 포함되어 있습니다. 곧 여러 인기 있는 모델에 대해 업데이트된 구현 버전을 발표하여 TensorFlow 1.0을 완전히 활용하는 방법을 보여드릴 것입니다. 8GPU 기반의 Inception v3에서는 속도가 7.3배 향상되었고, 64GPU 기반의 분산된 Inception v3에서는 속도가 58배나 향상되었습니다!


더욱 향상된 유연성: TensorFlow 1.0에는 TensorFlow를 위한 높은 수준의 API와 tf.layers, tf.metrics 및 tf.losses 모듈을 도입합니다. 또한, 저희는 또 다른 인기 있는 고차원 신경망 라이브러리인 Keras와 완벽하게 호환되는 새로운 tf.keras 모듈도 포함한다는 내용을 발표했습니다.


예전보다 훨씬 강화된 실서비스 적용 수준: TensorFlow 1.0은 기존 코드의 중단에 대해 걱정할 필요 없이 새로운 기능을 더욱 손쉽게 선택할 수 있도록 하여 Python API 안정성(자세한 내용은 여기를 참조)을 약속합니다.

TensorFlow 1.0의 기타 주요 사항:

  • Python API가 NumPy와 더욱 흡사한 모습으로 바뀌었습니다. 이 변경 사항과 더욱 높은 API 안정성을 지원하기 위해 수행된 이전 버전과의 호환성 관련 기타 변경 사항을 알아보려면 저희가 제공해드리는 유용한 마이그레이션 가이드변환 스크립트를 참조하십시오.
  • 자바Go용 시험용 API
  • 수준이 더욱 높아진 API 모듈(tf.layers, tf.metrics 및 tf.losses) - skflowTF Slim을 통합한 후 tf.contrib.learn에서 가져왔습니다.
  • CPU 및 GPU를 대상으로 하는 TensorFlow 그래프를 위한 도메인 특수 용도 컴파일러인 XLA를 시험용으로 출시합니다. XLA는 빠르게 진화하고 있으며 향후 릴리스에서 더 진보할 것으로 기대합니다.
  • 라이브 TensorFlow 프로그램의 디버그에 활용할 수 있는 명령줄 인터페이스 및 API인 TensorFlow Debugger(tfdbg) 소개
  • 객체 검색 및 현지화, 카메라 기반 이미지 양식화에 대한 새로운 Android 데모 추가
  • 설치 관련 개선 사항: Python 3 Docker 이미지가 추가되었으며, TensorFlow의 pip 패키지가 이제 PyPI와 호환됩니다. 즉, 이제 pip install tensorflow를 간단히 호출하여 TensorFlow를 설치할 수 있습니다.

저희는 전 세계 TensorFlow 커뮤니티에서 이루어지는 발전 속도에 전율을 느끼고 있습니다. TensorFlow 1.0과 이 솔루션이 어떻게 사용되는지에 대한 자세한 내용을 들어보려면 더 높은 수준의 API에서 모바일 환경의 TensorFlow, 그리고 새롭게 제공되는 XLA 컴파일러에 이르기까지 최근 업데이트된 사항과 TensorFlow의 흥미로운 사용 사례를 소개하는 TensorFlow 개발자 회담 YouTube 동영상을 시청해보시기 바랍니다.





라이브 스트림 링크와 동영상 재생목록을 보려면 여기를 클릭하세요.


TensorFlow 에코시스템은 TensorFlow Serving 같은 기존 도구에 대한 업데이트 외에도, 동적 일괄 처리를 지원하는 Fold 같은 새로운 기술과 Embedding Projector 같은 도구와 함께 계속해서 성장하고 있습니다. 모든 사람들이 이용할 수 있는 딥 러닝 분야에서 진보를 이루어낸 기고자, 교육자, 그리고 연구자 커뮤니티에 깊은 감사의 인사를 드립니다. 저희는 GitHub 이슈와 같은 포럼과 Stack Overflow, @TensorFlow, discuss@tensorflow.org 그룹 및 향후 이벤트에서 여러분과 함께 활동하게 되기를 기대합니다.



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

게시자: Suzanne van Tienen, Google Play 제품 관리자

Google Play 개발자 콘솔팀은 유료 앱, 인앱 구매, 구독 서비스를 더 간단하고 효율적으로 운영할 수 있도록 기능을 개선하고 있습니다.

첫째, Google Play 개발자 콘솔에서 기존 Google Payments Center의 주문 관리 기능을 사용할 수 있습니다. 둘째, Developer Console에서도 결제 설정을 확인하고 변경할 수 있습니다. 주문 관리 및 결제 설정 기능은 올바른 권한을 소유한 지정된 사용자만 사용할 수 있습니다. 여러분의 팀원 중 꼭 필요한 사용자만 민감한 정보에 접근할 수 접근 권한을 잘 설정하시기 바랍니다.



Google Play Developer Console에 추가된 새로운 주문 관리 탭


개발자 콘솔에 주문 관리 기능이 추가되면서 동시에 몇 가지 기능이 개선되었습니다.
  • 대량 환불: 이제 주문에 대한 환불을 개별적으로 실행하지 않고 여러 주문에 대해 동시에 환불하도록 선택할 수 있습니다.
  • 구독 취소: 주문 관리 탭에서 직접 구독을 취소하고 환불할 수 있습니다(별도의 UI로 이동할 필요 없음).
  • 권한: "Manage orders"라고 하는 새로운 사용자 액세스 권한을 Developer Console에 추가했습니다. 이 권한을 통해 사용자는 주문을 찾고 환불을 실행하고 구독을 취소할 수 있습니다. 이들 사용자에게 다른 기능은 읽기 전용이며 재무 보고서는 표시되지 않습니다("View financial reports"가 설정된 사용자만 재무 데이터를 볼 수 있음). 개발자 콘솔에서 액세스한 경우 결제 설정은 계정 소유자에게만 제한됩니다.

개발자 콘솔로 주문 관리 마이그레이션

이제는 개발자 콘솔에서 주문 관리 기능을 사용할 수 있습니다. 1월 23일부터 Payments Center에서는 주문 관리 기능을 더 이상 사용할 수 없습니다. Payments Center에서 사용자 권한이 자동으로 넘어오지 않으므로 계정 소유자는 환불 및 기타 주문 관리 기능에 액세스해야 하는 사용자가 계속해서 액세스할 수 있도록, 새로운 'Manage orders' 권한을 가진 개발자 콘솔 계정에 사용자를 모두 추가해야 합니다. 새로운 사용자를 개발자 콘솔 계정에 추가하는 방법은 다음과 같습니다.
  1. Google Payments Center에 로그인하여 모든 기존 사용자를 검토합니다.
  2. 개발자 콘솔에 로그인하고 Order Management에 대한 액세스 권한이 필요한 모든 사용자에게 다음 권한 중 하나 또는 둘 모두 추가합니다.
    1. 재무 보고서 보기: 재무 보고서에 액세스하고 이를 볼 수 있는 권한을 부여합니다.
    2. 주문 관리: 주문을 보고 환불할 수 있지만 집계된 재무 통계를 보거나 판매 및 대금 결제 보고서를 다운로드할 수는 없는 권한을 부여합니다.
  3. 사용자에게 주문 관리를 위한 새로운 위치를 알려줍니다.

<블로그 원문은 여기에서 확인하실 수 있으며, 블로그 번역 리뷰는 문현경(Web Technologies GDE)님이 참여해 주셨습니다.>
2017년도에 저희는 Cloudflare 네트워크로 들어오는 트래픽 중 절반 이상이 휴대기기에서 비롯될 것이라 전망한 바 있습니다. 이러한 트래픽의 형식이 작은 화면에 제대로 표시되도록 지정되어 있더라도 모바일 웹은 데스크톱 CPU, 네트워크 연결 및 디스플레이에 맞게 설계된 기존 웹 프로토콜 및 기술을 기반으로 구축되어 있습니다. 따라서 모바일 웹 탐색이 기본 모바일 앱을 사용하는 경우에 비해 느리게 느껴집니다.

2015년 10월에 Google 팀은 모바일 웹을 기본 앱만큼 빠르게 만드는 새로운 개방형 기술인 AMP(Accelerated Mobile Pages)를 발표했습니다. 이 발표가 있은 이후, 많은 게시자들이 AMP를 채택해왔습니다. 현재는 70만 개의 각기 다른 도메인에 걸쳐 6억 페이지를 AMP 형식으로 사용할 수 있습니다.

이 AMP 콘텐츠로 들어오는 트래픽 대부분은 Google.com에서 검색을 실행하는 사용자들로부터 비롯됩니다. 방문자가 Google 검색 이외의 소스를 통해 콘텐츠를 찾는 경우 AMP에서 해당 콘텐츠를 제공할 수 있더라도 대개는 그렇게 하지 않습니다. 따라서 모바일 웹은 계속해서 필요한 수준보다 느린 속도에 머무르게 됩니다.

모바일 웹을 앱처럼 빠르게 만들기


Cloudflare의 Accelerated Mobile Links는 이러한 문제를 해결하는 데 도움을 주어, 콘텐츠를 검색하는 방식에 관계없이 콘텐츠를 앱처럼 빠르게 처리해 줍니다. Accelerated Mobile Links를 사용하면 Cloudflare 고객 사이트에서 AMP 버전을 사용할 수 있는 콘텐츠에 대한 링크가 자동으로 식별됩니다. 휴대기기에서 링크를 클릭하면 AMP 콘텐츠가 거의 즉각적으로 로드됩니다.

Cloudflare에서 Accelerated Mobile Links 활성화

휴대기기에서 이 게시글을 보고 다음 링크 중 하나를 클릭하여 Accelerated Mobile Links가 어떤 식으로 작동하는지 확인해 보시기 바랍니다.

Accelerated Mobile Links 애니메이션 데모

사용자 참여 증대


Accelerated Mobile Links를 통해 얻을 수 있는 이점 중 하나는 AMP 콘텐츠가 이 콘텐츠에 연결된 사이트에서 직접 뷰어에 로드된다는 점입니다. 따라서, 독자가 AMP 콘텐츠 사용을 마치고 새로 열려진 뷰어를 닫으면 링크의 원래 소스로 돌아가게 됩니다. 이런 식으로 모든 Cloudflare 고객의 사이트는 네이티브앱처럼 동작하게 되므로 사용자 참여도도 높아지게 됩니다.

더욱 향상된 브랜드 환경을 원하는 대규모 게시자들을 위해, Cloudflare는 게시자의 도메인에 맞게 뷰어의 도메인을 맞춤설정할 수 있는 기능을 제공할 예정입니다. 초기 단계로, 방문자를 Google에서 소유한 도메인으로 보내지 않고 AMP 콘텐츠를 원활하게 사용할 수 있는 환경을 제공합니다. Accelerated Mobile Links 뷰어를 맞춤설정하는 데 관심이 있는 대규모 게시자라면 Cloudflare 팀에 문의하시기 바랍니다.

AMP에 대한 혁신 추구


Google이 AMP를 초기에 개발한 업체이기는 하지만 관련 기술은 공개되어 있습니다. 저희는 Cloudflare의 Accelerated Mobile Links와 Cloudflare의 자체 AMP 캐시 개발을 위해 Google 팀과 긴밀히 협력했습니다. Google의 AMP 프로젝트 기술 책임자인 Malte Ubl 씨는 Cloudflare와의 협업에 대해 이렇게 말했습니다.

“Cloudflare와 협업하여 Cloudflare AMP 캐싱 솔루션을 개발한 작업은 오픈소스 개발에서 가능한 수준만큼 원활하게 이루어졌습니다. Cloudflare는 이 프로젝트의 정규 컨트리뷰터가 되었고 모든 AMP 사용자에게 더 나은 코드베이스를 만들었습니다. 한정된 캐시를 지원하는 것에서 다수의 캐시를 지원하는 것으로 나아가는 것이 항상 소프트웨어 프로젝트에서 뛰어넘어야 할 커다란 산이며, 이러한 도약을 이루어낸 Cloudflare의 멋진 솔루션을 보게 되어 정말 놀랍습니다.”

Cloudflare는 현재 Google과 완전히 동일한 성능과 보안 이점을 제공하는 유일한 타사 호환 AMP 캐시를 제공하는 업체입니다.

저희는 오픈소스의 기본 정신에 입각하여 게시자와 최종 사용자의 문제를 해결하기 위해 프로젝트에 대한 업데이트 개발에 도움이 되도록 노력하고 있습니다. AMP에 대해 표명된 문제를 해결하기 위해 저희가 현재 개발 중인 기능 몇 가지를 구체적으로 설명하자면 다음과 같습니다.
  • 게시자의 원래 도메인을 사용하여 AMP 콘텐츠를 더욱 손쉽게 공유할 수 있는 기능
  • 데스크톱 방문자를 AMP 버전에서 다시 콘텐츠의 원래 버전으로 자동으로 리디렉션
  • 콘텐츠의 AMP 버전으로 리디렉션되지 않기를 바라는 최종 사용자가 분리할 수 있는 기능
  • 게시자가 AMP 뷰어를 브랜드화하여 자체 도메인에서 제공할 수 있는 기능

Cloudflare는 AMP 프로젝트에 전념하고 있습니다. Accelerated Mobile Links는 Cloudflare에서 출시하는 첫 번째 AMP 기능이지만, 향후 몇 달 동안 이에 대한 작업을 더 진행할 예정입니다. 현재, Accelerated Mobile Links는 모든 Cloudflare 고객에게 무료로 제공됩니다. Cloudflare Performance 대시보드에서 사용할 수 있습니다. 계속해서 모바일 웹의 속도를 높이기 위해 개발되고 출시되는 추가 AMP 기능이 있는지 관심을 가지고 지켜보시기 바랍니다.

게시자: Matthew Prince, Cloudflare CEO

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



Parul Soi
Parul Soi
개발자 관계 프로그램 관리자

Firebase 시리즈의 Pirate Metrics에 대해서 세 번째 게시글을 올립니다. 첫 번째 게시글에서는 Pirate Metrics란 무엇이고 왜 중요한지 살펴봤습니다. 두 번째 게시글에서는 Firebase를 사용하여 확보 전략을 개선하는 방법을 보여드렸습니다.

사용자를 확보한 후의 주요 목표는 사용자가 제품을 사용하도록 하는 것입니다. 사용자는 이런저런 앱을 자주 설치하긴 하지만 쉽사리 빠져들지는 않습니다. 행운이 따르는 앱 개발자라면, 사용자가 앱을 설치했다는 사실조차 잊어버리거나 심지어 제거해버리기 전에 하루나 이틀 정도는 사용해볼지도 모르죠. 사용자 확보에 쏟은 모든 노력이 물거품이 될 수도 있습니다.





따라서 처음 며칠이 매우 중요합니다. 수집한 데이터를 통해 사용자가 어느 시점에서 앱을 활성화하는지 패턴을 찾아내고 더 많은 사용자들이 그런 시점을 거치도록 하는 방법을 알아내고 싶을 것입니다. 소셜 네트워크 애플리케이션의 친구 수나 동영상 게임에서 마주치는 레벨 수를 예로 들 수 있습니다. 올바른 “활성화 전략” 수립에는 항상 많은 실험이 뒤따릅니다.

이러한 실험을 수행하기에 적합한 도구가 있는데, 그건 바로 Firebase의 Remote Configuration입니다. Remote Config를 통해 서버에서 어떤 키/값 을 설정하고, 이를 사용하여 애플리케이션 내부의 경험에 다양한 변화를 줄 수 있습니다. Firebase 콘솔에서 이런 값들이 업데이트되면 애플리케이션 내부에 반영되고, 따라서 새로운 버전을 출시하지 않고서도 사용자의 경험에 변화를 줄 수 있습니다.

Remote Config에서 이 기능을 사용하고 “무작위 백분위” 표적화 기법을 사용하여 값을 설정하면, 기본적으로 A/B 테스트 설정이 준비됩니다. 그런 다음, 효과가 있는 것으로 입증된 실험에 대해 롤아웃을 늘려가면서 분석에 미치는 영향을 확인하고 서버 자체에서 이런 값들을 동적으로 변경할 수 있습니다. 따라서 A/B 테스트를 위한 훌륭한 솔루션이 되는 것이죠.

테스트를 최적화하려면, 개선하려는 데이터 요소(예: 처음 앱을 열 때 사용자 등록 비율 증가)부터 먼저 정의하는 것이 좋습니다. 그런 다음 해당 데이터 요소의 개선을 위해 실행할 실험을 구상합니다. 실험을 통해 각기 다른 앱 튜토리얼 및 가입 방법, 게임 초기 단계에서의 난이도 조절이 어떤 영향을 미치는지 알아볼 수 있어 궁극적으로는 활성화 비율을 개선할 수 있게 됩니다.

Google은 APAC지역의 디지털 환경을 조사하는 연구 보고서 개발 프로젝트를 지원하고 있습니다. 이 작업의 일환으로 스타트업, 금융투자회사 그리고 다국적 기업 종사자를 대상으로 각국의 디지털 환경에 대한 여러분의 의견을 듣고 있습니다. 설문 조사는 약 10분 정도 소요될 예정이며, 여러분의 의견은 연구 보고서 개발에 매우 중요하게 쓰일 예정입니다.

설문 조사는 철저히 익명으로 진행되며, 여러분이 남겨주신 소중한 의견에 대한 보답으로 본 보고서의 최종 결과를 공유드릴 예정입니다. 아래 해당되는 링크에 따라 설문을 진행해 주시기 바랍니다.


설문에 참여해 주셔서 고맙습니다.

<블로그 원문은 여기에서 확인하실 수 있으며, 블로그 번역 리뷰는 김태호(Android GDE)님이 참여해 주셨습니다.>
Firebase에서는 Firebase 콘솔에서 개발자가 생성하는 프로젝트를 통해 구현하는 앱에서 함께 사용할 수 있는 여러 가지 기능을 제공합니다. 보통은 단일 프로젝트에서 제공하는 개발자 앱의 리소스만 전부 확보하면 충분하지만, 단 하나의 앱으로 여러 프로젝트의 데이터에 액세스할 수 있도록 하는 경우도 많습니다. 예를 들어, 두 가지 다른 데이터베이스의 데이터에 액세스하여 각 데이터베이스에 대한 사용자의 액세스를 인증할 수 있어야 할 경우도 있습니다. 이 글에서는 이러한 과정이 어떤 식으로 이루어지는지 보여드리겠습니다.

먼저 몇 가지 용어부터 살펴보겠습니다.

이전 Firebase.com 프로젝트
이전 콘솔에서 생성하여 새로운 콘솔로 업그레이드하지 않은 Firebase 데이터베이스와 연결된 프로젝트입니다.

Google API 프로젝트
대개 https://console.developers.google.com 또는 https://console.cloud.google.com에서 Google API에 액세스하기 위해 사용하는 프로젝트입니다.

Firebase 프로젝트
새로운 Firebase 콘솔에서 생성한 프로젝트입니다. Firebase 프로젝트는 모두 아래에서 설명하는 Google API 프로젝트이기도 합니다.


특정 플랫폼을 위한 클라이언트입니다. 각 프로젝트마다 여러 앱이 연결되어 있을 수 있습니다.


기존 Google API 프로젝트와 함께 업그레이드한 이전 Firebase.com 프로젝트

이 시나리오는 다른 Google API 프로젝트에서 서비스를 사용할 수도 있지만 기존의 이전 Firebase.com 데이터베이스를 새로운 Firebase 프로젝트로 업그레이드하려는 개발자에게 적합합니다. 업그레이드한 이전 프로젝트는 새로운 Firebase 프로젝트가 되는데, 기존 사용자를 위한 Google Sign-In 인증을 제공하는 Google API 프로젝트와 함께 사용해야 합니다.

여기서 문제는 Google Sign-In 구성 요소가 Android에서 제대로 작동해야 하려면 SHA-1(APK 서명에 사용하는 키 지문)과 패키지 이름(예: com.foo.bar)을 앱에 등록해야 한다는 점입니다. Google Sign-In은 이 조합을 통해 특정 앱에서 사용 중인 Google API 프로젝트가 무엇인지 인식할 수 있기 때문입니다. SHA1과 패키지 이름으로 구성되는 쌍은 Google과 Firebase 프로젝트에서 전역적으로 고유하므로, 동일한 SHA-1과 패키지 이름 쌍을 업그레이드한 Firebase 프로젝트에 추가하려고 하면 (Google API 프로젝트에) OAuth2 클라이언트가 이미 존재한다는 오류 메시지가 나타납니다.
경고: 프로덕션 환경에서 이러한 오류가 발생할 경우 앱에 등록된 기존 클라이언트 ID를 삭제하지 마세요! 삭제하면 기존 사용자가 앱을 올바로 사용할 수 없게 되기 때문입니다. 이 경우 올바른 해결책은 Firebase 콘솔에서 업그레이드한 프로젝트에 대해 동일한 패키지 이름으로 새로운 앱을 생성하는 것입니다. 단, SHA1은 포함하지 않아야 합니다.
이제, 평상시와 같이 Firebase 인증을 사용하여 Google Sign In을 구현합니다. 어느 한 시점에서 Google Sign Options 객체를 구성해야 합니다.
GoogleSignInOptions gso = new GoogleSignInOptions.Builder(GoogleSignInOptions.DEFAULT_SIGN_IN)
              .requestIdToken(getString(R.string.default_web_client_id))
              .requestEmail()
              .build();
여기서 default_web_client_id 문자열은 ID 토큰의 audience 필드 설정에 사용됩니다. 값은 Google 프로젝트가 아닌 Firebase 프로젝트의 google-services.json 파일에서 가져옵니다. 따라서 이 값을 Google 프로젝트의 클라이언트 ID로 바꿔야 합니다. 어떤 웹 클라이언트 ID라도 사용할 수도 있으며, 새로 생성할 수도 있습니다.
다음으로, Firebase 프로젝트로 돌아가서 GoogleSignInOptions (Firebase 콘솔의 Auth > Sign In Providers > Google 섹션)에 설정한 클라이언트 ID를 허용 목록에 추가합니다.
google-services.json을 다시 다운로드하여 Android 앱에 추가해야 합니다. 그러면 Firebase 프로젝트가 Google 프로젝트에서 생성되는 Google ID 토큰을 허용합니다. 따라서 Android 앱이 Google 프로젝트를 사용하여 Google에 로그인한 후 정상적인 접근 방식에 따라 Google ID 토큰을 사용해 Firebase 프로젝트로 인증하게 됩니다. Google API 프로젝트에 연결된 Google API에 대해 인증된 호출을 생성하고 Firebase 프로젝트를 사용하여 Firebase API에 대한 인증된 호출을 생성할 수 있습니다.

두 가지 다른 Firebase 프로젝트에서 데이터베이스에 액세스

앞서 설명한 상황에서는 Google 프로젝트에도 액세스해야 하는 단일 Firebase 프로젝트가 있었던 경우였고, API가 서로 달랐기 때문에 아무런 문제가 없었습니다. 하지만 같은 API를 사용하여 여러 프로젝트에 액세스해야 할 때도 있습니다. 여러 데이터베이스 인스턴스에 액세스하는 경우를 예로 들 수 있습니다.
Firebase를 사용하는 Android 앱의 경우 모든 Firebase API의 구성을 관리하는 중앙 FirebaseApp 객체가 있습니다. 이 객체는 앱 실행 시 콘텐츠 제공자가 자동으로 초기화하므로, 보통은 이 객체와 상호 작용해야 할 필요가 전혀 없습니다. 하지만 단일 앱에서 여러 프로젝트에 액세스하려는 경우 각 프로젝트를 개별적으로 참조하기 위해 별개의 FirebaseApp이 필요합니다. Firebase에서 자동으로 생성하는 기본 인스턴스 이외의 인스턴스 초기화는 개발자 자신이 결정할 문제입니다.
예를 들어, 기본 Firebase 데이터베이스 인스턴스에 연결할 때는 암시적으로 기본 Firebase 앱을 사용합니다.
FirebaseDatabase database = FirebaseDatabase.getInstance();
다른 프로젝트에서 다른 Firebase 실시간 데이터베이스에 연결하려면 우선 연결하려는 다른 Firebase 프로젝트에 대해 FirebaseApp 인스턴스를 초기화하고 인스턴스의 식별자를 지정합니다. 이 경우에는 다음과 같이 "secondary"입니다.

FirebaseOptions options = new FirebaseOptions.Builder()
       .setApplicationId("1:530266078999:android:481c4ecf3253701e") // Required for Analytics.
       .setApiKey("AIzaSyBRxOyIj5dJkKgAVPXRLYFkdZwh2Xxq51k") // Required for Auth.
       .setDatabaseUrl("https://project-1765055333176374514.firebaseio.com/") // Required for RTDB.
       .build();
FirebaseApp.initializeApp(this /* Context */, options, "secondary");

그러면 같은 클라이언트 API를 사용하여 데이터베이스에 액세스할 수 있지만, 이번에는 관련 FirebaseAppFirebaseDatabase.getInstance()에 전달함으로써 어떤 프로젝트에 액세스할지 지정합니다.
// Retrieve my other app.
FirebaseApp app = FirebaseApp.getInstance("secondary");
// Get the database for the other app.
FirebaseDatabase secondaryDatabase = FirebaseDatabase.getInstance(app);


두 개의 다른 Firebase 데이터베이스 인증

위에서 설명한 두 가지 방법을 결합하면 연결할 외부 ID가 있을 때마다 Firebase 프로젝트 간에 인증 데이터를 공유할 수 있습니다.
예를 들어, 앱에서 Google Sign-In을 통한 로그인을 허용하고 기본 프로젝트 및 보조 프로젝트에서 인증을 요구하는 데이터베이스 규칙을 구성한 경우 동일한 Google 자격 증명을 사용하여 두 시스템 모두에 로그인할 수 있습니다.
먼저 평소와 같이 기본 프로젝트에서 Google Sign-In을 사용하도록 앱을 설정합니다. 그러면 기본 프로젝트에서 기본 클라이언트 ID를 얻게 됩니다. 클라이언트 ID는 지정된 앱 클라이언트(웹, Android, iOS)의 식별자일 뿐이며, 보통 클라이언트 자체에 포함되어 있습니다. 한 프로젝트의 클라이언트 ID가 여러 개일 수 있지만, GoogleSignInOptions builder에 대한 requestIdToken 호출에 지정된 항목을 허용 목록에 추가해야 합니다.
.requestIdToken(getString(R.string.default_web_client_id))
보통 google-services.json에서 유형이 "3"인 첫 번째 client_id로 이 항목을 찾을 수 있습니다. 제 경우엔 다음과 같았습니다.
{
 "client_id": "56865680640-e8mr503bun5eaevqctn4u807q4hpi44s.apps.googleusercontent.com",
 "client_type": 3
},
이제 Auth > Sign In Providers 섹션의 Google 패널(보조 프로젝트에 있음)로 이동합니다. 여기서 클라이언트 ID를 허용 목록에 추가할 수 있습니다.

이제 Google Sign-In 결과에서 동일한 GoogleSignInAccount 객체를 가져와서 기본 앱과 보조 앱에 대해 모두 인증할 수 있습니다.
AuthCredential credential = GoogleAuthProvider.getCredential(account.getIdToken(), null);
FirebaseAuth.getInstance().signInWithCredential(credential);

FirebaseApp app = FirebaseApp.getInstance("secondary");
FirebaseAuth.getInstance(app).signInWithCredential(credential);
사용자가 한 번만 로그인해도 두 프로젝트에 대해 모두 인증됩니다.


프로젝트 간 UID 공유

여기서 한 가지 문제점은 각 프로젝트에서 Firebase 사용자 ID가 다르다는 점입니다. 예를 들어, 동일한 Google 자격 증명을 사용하는 경우 다음과 같은 두 가지 UID를 얻습니다.
Default Auth UID: 0960868722032022577213DA4EA8B7A1683D92B405DD
Secondary Auth UID: 7h6XOeSxmkNsSseFJ1jU31WZHDP2
앱이 계정 링크 기능을 제공하지 않으면 데이터베이스 구조 및 보안 규칙 등에 Google(또는 Facebook, Twitter 등) 사용자 ID를 사용할 수 있습니다. 하지만 각 프로젝트에 똑같은 사용자 ID를 사용해야 하거나 이메일/비밀번호 또는 익명 인증을 사용하는 경우 상황은 약간 더 까다롭습니다.
다행히도, 사용자설정 인증 토큰이 자체 UID를 지정하므로 서버 측 코드와 함께 사용자설정 인증 기능으로 이 문제를 해결할 수 있습니다.
이번에는 보조 프로젝트에서 어떠한 항목도 허용 목록에 추가하지 않지만, 보조 프로젝트와 기본 프로젝트 모두의 서비스 계정을 다운로드합니다. 우선, Android 클라이언트에서 로그인하여 FirebaseAuth 클라이언트에서 Firebase ID 토큰을 가져옵니다.
참고: 여기서는 원하는 로그인 제공자를 사용할 수 있습니다. 그냥 사용자설정 토큰을 사용해 프로젝트 전체에 걸쳐 사용자 ID를 연결하겠습니다.
firebaseAuth.getCurrentUser().getToken(false /* forceRefresh */)
       .addOnCompleteListener(new OnCompleteListener() {
   @Override
   public void onComplete(@NonNull Task task) {
       String token = task.getResult().getToken(); // Send this to the server.
   }
});
토큰을 서버로 보내고 이 토큰으로 Firebase 사용자설정 토큰을 생성합니다. 현재 서버 측에 있기 때문에 서비스 계정을 사용하고는 있지만 Android에서와 마찬가지로 각각의 앱을 초기화해야 합니다(여기서는 Java 서버 SDK를 사용하지만 NodeJS도 이와 마찬가지로 사용할 수 있음).
FirebaseOptions options = new FirebaseOptions.Builder()
  .setServiceAccount(new FileInputStream("default-service-account.json"))
  .build();
FirebaseApp.initializeApp(options);


FirebaseOptions secondaryOptions = new FirebaseOptions.Builder()
  .setServiceAccount(new FileInputStream("secondary-service-account.json"))
  .build();
FirebaseApp.initializeApp(secondaryOptions, "secondary");
기본 앱은 클라이언트에서 오는 토큰을 인증하는 데 사용하고 보조 앱은 적당한 UID 세트로 사용자설정 인증 토큰을 생성하는 데 사용합니다.
// Verify the ID token using the default app.
FirebaseAuth.getInstance().verifyIdToken(idToken)
  .addOnSuccessListener(new OnSuccessListener() {
    @Override
    public void onSuccess(FirebaseToken decodedToken) {
      String uid = decodedToken.getUid();
      System.out.println("User " + uid + " verified");
      FirebaseApp app = FirebaseApp.getInstance("secondary");
      String customToken = FirebaseAuth.getInstance(app).createCustomToken(uid);
      // TODO: Send the token back to the client!
    }
});
Android 앱으로 돌아가서, 서버에서 사용자설정 토큰을 가져와서 이를 사용해 보조 프로젝트를 인증합니다.
FirebaseApp app = FirebaseApp.getInstance("secondary");
FirebaseAuth.getInstance(app).signInWithCustomToken(token);
이제, 두 프로젝트의 Firebase UID가 일치합니다.
Default Auth UID: 0960868722032022577213DA4EA8B7A1683D92B405DD
Secondary Auth UID: 0960868722032022577213DA4EA8B7A1683D92B405DD


iOS와 웹도 마찬가지

오늘 설명해드린 내용이 단일 앱에서 여러 Firebase 프로젝트를 다룰 때 유용한 옵션으로 활용할 수 있길 바라겠습니다. iOS와 웹에도 이런 사항이 적용되는지 궁금하시다면 확실히 그렇다고 말씀드릴 수 있습니다. Android의 FirebaseApp에 상응하는 앱을 사용하여 보조 프로젝트에 대한 참조를 생성하기만 하면 됩니다.
JavaScript에서는 firebase.app을 사용합니다.
var config = {
    apiKey: "",
    authDomain: ".firebaseapp.com",
    databaseURL: "https://.firebaseio.com",
    storageBucket: ".appspot.com",
    messagingSenderId: "",
  };

var secondary = firebase.initializeApp(otherAppConfig, "secondary");
var secondaryDatabase = secondary.database();
iOS에서는 FIRApp을 사용합니다.
// Alt: load from plist using |FIROptions(contentsOfFile:)|
let options =  FIROptions(googleAppID: googleAppID, bundleID: bundleID, GCMSenderID: GCMSenderID, APIKey: nil, clientID: nil, trackingID: nil, androidClientID: nil, databaseURL: databaseURL, storageBucket: nil, deepLinkURLScheme: nil)

FIRApp.configure(withName: "secondary", options: fileopts)
guard let secondary = FIRApp.init(named: "secondary")
      else { assert(false, "Could not retrieve secondary app") }

let secondaryDatabase = FIRDatabase.database(app: secondary);
자세한 내용과 관련 링크는 Firebase 문서에 새로 추가된 Configuring Your Firebase Project(Firebase 프로젝트 구성) 페이지를 살펴보시기 바랍니다.

지난 11월에 2016년 한해를 마무리하며 그동안 저희 GDG에 참여해주셨던 분들의 특별한 경험을 많은 분들과 공유하고자 GDG Stories Asia를 진행하였습니다. 아시아 지역에서 무려 100명이 넘는 개발자 분들이 참여해 주셨고, 한국에서는 총 네 분의 이야기가 선정되었습니다.

GDG Stories Asia에 참여해 주신 모든 분들께 다시 한번 감사드리며, 선정되신 네 분의 GDG 이야기를 여러분께 소개합니다!


계성혁 (GDG Incheon/ GDG Korea Campus)



Q: 개발자가 되기로 결심한 이유는 무엇이었습니까?
A: 어렸을 때부터 컴퓨터에 관심이 많았고, 프로그램을 만드는 것에 흥미를 느끼게 되어 개발자가 되기로 결심했습니다. 현재는 대학교 컴퓨터공학과에 재학 중입니다.

Q: GDG로부터 얻었던 도움이 있다면 무엇이었습니까?
A: 2014년 GDG Incheon에서 GDG 활동을 하면서, 학교를 벗어나 시야를 더 넓히고, 새로운 것에 도전하도록 계기를 만들어줬습니다. 또 최근에 새로 만들어진 GDG Korea Campus에서는, 학교라는 경계를 넘어 신입 개발자가 되기 위해 정진하는 학생 개발자들의 커뮤니티라는 점에서 저 자신이 더 열심히 할 수 있는 계기를 만들어줬습니다.

Q: 그동안 참석했던 GDG 행사 중 가장 인상깊었던 행사가 있다면 소개해 주세요.
A: GDG의 많은 행사들을 참여했지만, 그 중 가장 인상 깊었던 행사는 I/O Extended 행사와 DevFest라고 생각합니다. 최신 기술 트렌드를 Live로, 혹은 나중에 사람들과 이에 대해 관심사를 나누며 새로운 기술들에 대해 알아갈 수 있는 점이 좋았습니다. 특히 DevFest는 개발자들의 축제라는 컨셉으로 실력에 상관없이 개발자라는 이름으로 하나되어 지식을 공유하고 분위기를 즐길 수 있었다는 점에서 가장 인상 깊었습니다.

김종찬(GDG Korea Campus/ GDG Korea Android)



Q: 개발자가 되기로 결심한 이유는 무엇이었습니까?
A: 8살 어린시절부터 저의 목표는 컴퓨터를 잡고 무언가를 하는 것이었습니다. 그 이유는 컴퓨터라는 부피도 작지만 내가 어떤 생각을 하느냐에 따라 그 영향력이 어마어마 해질수 있다고 생각했기 때문입니다. 오랫동안 생각해온 그 꿈을 대학에 와서 어떻게 이룰지 철없이 고민하였지만, GDG는 그 고민을 철든상태로 고민하게해준 고마운 커뮤니티입니다.

Q: GDG로부터 얻었던 도움이 있다면 무엇이었습니까?
A: 안드로이드와 인연을 가진게 올해로 6년째입니다. 처음에 안드로이드를 다룬다고 이야기하던 저는 Java를 절차지향적으로 짜는 그런 아무것도 모르는 풋내기 수준이었습니다. 하지만 이곳에서 만난 고수분들과 어떤 내용인지 몰라도 듣게 되는 세션들이 점차 제가 스스로 성장해나가는 과정에서 매우 빠른 촉진제가 되었습니다. 수많은 고수분들로부터 개발자로써 어떻게 나아가야하는지, 어떤 코드를 짜야하는지 직접 배울 수 있었습니다. 그러면서 제가 등뒤를 보고 뛰어넘고 싶다고 생각한 인생의 스승님도 만나게 되었습니다. 결과적으로 GDG는 현재 대학교 2학년 한 학생을 커뮤니티에서 수차례 기술과 관련한 발표를 해보고, 누군가의 코드 짜는것을 도와주며 그러면서 자신을 성장시키고, 스스로 깔끔하고 효율적인 코드와 애자일 실천을 따르려 노력하는 사람으로 만들어주었습니다.

Q: Google이 여러분 혹은 주변 사람들이 (개인적으로 혹은 전문적으로) 멋진 일들을 기획하고 만들어나가는 일들을 어떻게 돕고 있다고 생각하십니까?
A: 집단지성 그 자체입니다. 기술업계를 지금보다 더 좋게하고자 염원하는 사람들이 각자 다른 경험을 바탕으로 그 흐름을 이끌고 있습니다. 예를 들어 최근 대두되는 머신러닝과 같은 주제를 커뮤니티에서 지속적으로 이야기하지 않는다면 한국의 기술수준은 급격히 떨어질 것입니다. 어느 회사 하나가 잘한다고 그 국가의 기술수준이 변하진 않기때문입니다. 그 국가의 개발자들의 전체적인 수준이 진보해야합니다. GDG와 Google은 한국의 평균적인 개발자들의 기술력과 기술업계가 나아가는 좋은 방향을 조금씩 천천히 하지만 견고하게 이끌고 있다고 생각합니다.

Q: 그동안 참석했던 GDG 행사 중 가장 인상깊었던 행사가 있다면 소개해 주세요.
A: 제가 스스로 기획하고 실행했던 GDG DevCamp 2016입니다. 저는 이곳에서 단순히 학생 개발자들은 지금 알고있는 것보다 조금 더 많이 알아가고, 자신의 활동영역이 개발자에 비해서 좁은 디자이너들은 그 터를 만들어주고자 했던것이 목표였습니다. 지식을 제공하고자 하는 입장이었지만, 저는 이곳에서 요즘 디자이너들이 어떤것을 고민하고, 무엇을 잘해야 좋은 디자이너로 성장하는지 알았으며 기쁜소식으로 요즘 학생 개발자들의 수준이 많이 업그레이드 되었고 더 기술적으로 높은 수준을 지향해도 좋다는 생각을 했습니다. 학생 수준에서 깔끔하고 유지보수하기 좋은 코드를 짜는 것과, 새로이 대두되는 머신러닝에 대한 관심을 보이는것이 그리 쉽게 생각할만한 현상은 아니기 때문입니다. 미래의 내 동료들의 수준이 어느정도인지 가늠하고, 그 사람들을 기대하며 그 기대에 부응하는 내 수준을 만들어가겠다는 생각을 하게되었습니다.

윤재석(GDG Seoul)



Q: 개발자가 되기로 결심한 이유는 무엇이었습니까?
A: 어렸을 적부터 무엇인가를 만드는 것을 좋아했는데, 개발자라는 직업은 그 취미와 똑같았던 것 같습니다. 또한 무엇인가를 만들어서 누군가에게 선물해줄 수 있다는 것이 큰 의미를 주어 개발자를 하게 되었습니다.

Q: GDG로부터 얻었던 도움이 있다면 무엇이었습니까?
A: 저는 학생 시절에 처음으로 GDG를 알게 되었습니다. GDG에서 주최하는 행사들을 따라다니며, 개발자의 미래 모습을 미리 그려볼 수 있었습니다. 그 뿐만 아니라 Android, Chromium, Google Cloud Platform과 같은 Google의 기술들을 간접적으로 체험해볼 수 있는 행사들도 있었습니다. 그 경험들은 학생개발자임에도 불구하고 Google의 기술을 기반으로한 다양한 프로젝트를 도전해볼 수 있도록 해주는 원동력이 되었고 덕분에 많은 프로젝트를 성공적으로 참여할 수 있었습니다. 특히 이후에는 GDG 운영자가 되어 학생시절임에도 불구하고 큰 행사들을 준비하고 개최해보면서, 더 많은 개발자들을 위한 생각들과 Google의 기술을 더 깊이있게 고민해볼 수 있었던 경험은 잊을 수 없는 것 같습니다.

Q: Google이 여러분 혹은 주변 사람들이 (개인적으로 혹은 전문적으로) 멋진 일들을 기획하고 만들어나가는 일들을 어떻게 돕고 있다고 생각하십니까?
A: Google의 많은 기술들은 대부분 Google 혼자 생존하기 위한 기술이 아닌, 그 기술을 통해 더 큰 프로젝트를 만들 수 있도록 해주는 플랫폼 역할을 하고 있다고 생각합니다. 단연 그 부분은 기술뿐만이 아니라 Google과 그 사람이 함께 성장할 수 있는 부분이라는 확신이 든다면 아낌없이 투자하고 있다고 생각합니다. 예를들면 제가 GDG 운영자를 하면서, 학생시절에 학생들이 성장할 수 있도록 하는 행사(Hello, World!)를 개최했었던 기억이 납니다. 이 행사는 Google에게는 직접적인 수익이 없었던 행사임에도 불구하고 한국 학생 개발자의 성장과 Google의 기술 체험해보는 행사를 위해 행사장 대관, 식사 등 많은 투자를 하였었기 때문입니다.

Q: 그동안 참석했던 GDG 행사 중 가장 인상깊었던 행사가 있다면 소개해 주세요.
A: 위에 언급하였던 학생 개발자를 위한 Hello, World! 가 기억에 남습니다. 이 행사는 학생개발자들이 자신의 진로를 잡지 못하고 단순히 대학교를 나와서 졸업을 하는 경우가 많은 현실에 안타까움을 가지고 준비된 행사였습니다. 어떻게해야 이런 고민이 많은 친구들을 행사에 참여하도록 독려할 수 있을지도 많은 고민이었고, 이 귀중한 시간을 쪼개서 나온 친구들에게 어떻게해야 더 의미있는 내용을 전달해줄 수 있을지도 고민이었습니다. 하지만 이 행사를 통해 학생개발자들을 위한 고민을 더욱더 깊이있게 할 수 있었고, 또한 저 자신은 과연 학생개발자로써 어떠한 자세로 살아가고 있는 지를 돌아볼 수 있던 좋은 행사였습니다.또한 많은 그룹(GDG SSU, 이화앱센터, 중앙대 ZeroPage, 인하대 아이그루스)과 함께 연합하여 준비하였는데, 모두 같은 마음으로 준비하였다는 것. 또 많은 학생개발자들이 참석하여 자신의 성장을 생각해보고 개발자에 대해 이해할 수 있는 귀중한 시간이었다는 것은 이 행사가 가장 인상깊은 이유인 것 같습니다.

최원영(GDG Korea Android/ GDG Seoul)



Q: 개발자가 되기로 결심한 이유는 무엇이었습니까?
A: 신입 시절 아무것도 모르고 포지션이 애매할 때 회사의 권유로 안드로이드 개발을 시작했습니다. 내가 만든 것을 그 자리에서 바로 바로 확인하고 수정할 수 있다는 점에 매료되었고, 실제로 내가 만든 앱을 내가 쓸 수 있다는 점이 좋아서 안드로이드 개발자로서 계속 일을 하고 있습니다.

Q: GDG로부터 얻었던 도움이 있다면 무엇이었습니까?
A: GDG 를 통해서 안드로이드와 관련된 트렌드를 좀 더 잘 알 수 있게 되었고, 또한 이를 통해서 개발자들과 네트워킹하며 더 성장할 수 있는 계기가 되고 있습니다. 관련 네트워크를 통해 형성된 인맥으로 취업까지 한것은 덤이라고 생각합니다.

Q: Google이 여러분 혹은 주변 사람들이 (개인적으로 혹은 전문적으로) 멋진 일들을 기획하고 만들어나가는 일들을 어떻게 돕고 있다고 생각하십니까?
A: Google Campus 내지는 기타 다른 행사들을 통해서 구글이 스타트업 및 개인 개발자들에게 많은 공헌을 하고 있다고 생각합니다.

Q: 그동안 참석했던 GDG 행사 중 가장 인상깊었던 행사가 있다면 소개해 주세요.
A: GDG DevFest Seoul이 인상 깊었습니다. 참여자나 스피커가 아닌 스탭으로서 팝콘을 튀기며 행사를 지원했습니다. 여러 사람들과 좀 더 잘 알 수 있는 계기가 되었으며, 또한 다음 기회에는 스피커로서 받은 것들을 되돌려주고 싶다는 생각도 들었습니다.