[go: up one dir, main page]

수많은 새로운 기능과 향상된 기능을 갖춘 Android Studio 2.2가 최근에 출시되었습니다. 새롭게 다시 작성된 통합 APK 패키징 및 서명 단계와 같이, 일부 사항은 Android Gradle 플러그인에서 눈에 띄지 않게 변경되었으므로 놓치기 쉽습니다.

APK Signature Scheme v2

Android 7.0 Nougat에 APK Signature Scheme v2를 새로 도입하면서, 저희는 Android Gradle 플러그인에서 APK를 어셈블하는 작업 방식을 다시 쓰기로 결정했습니다. 인내심을 가지고 이 문서에 설명되어 있는 v2 서명에 대한 매우 상세한 기술 정보를 모두 읽어볼 수도 있겠지만, 여기서는 Android 앱 개발자로서 알아둬야 할 정보만 요약해서 빠르게 파악할 수 있도록 간략히 설명하겠습니다.
  • 무결성을 확인하는 데 사용되는 APK의 암호화 서명이 지금은 ZIP Central Directory 바로 앞에 있습니다.
  • v1에서는 보관처리된 각 파일의 콘텐츠를 압축 해제한 것과 반대로, 여기서는 서명이 계산된 후 전체 APK 파일의 바이너리 콘텐츠에 대해 인증됩니다.
  • APK는 v1 서명과 v2 서명으로 모두 동시에 서명될 수 있으므로, 이전 Android 릴리스와도 호환됩니다.
Android가 APK를 인증하는 방법에 이런 변경 사항을 적용하는 이유는 무엇일까요? 첫째로는 이 새로운 서명 형식의 보안과 확장성을 강화하고, 둘째로는 성능 향상을 위해서입니다. 이 새로운 서명은 기기에서 인증하는 시간이 크게 단축되므로(비용이 많이 드는 압축 해제 불필요) 앱 설치 시간이 더 빨라집니다.

하지만 이 새로운 서명 구성표로 인해 APK 생성 프로세스에 새로운 제약 조건이 적용됩니다. v1에서는 압축되지 않은 파일 콘텐츠만 인증되었으므로, APK 서명 후에도 상당히 많은 콘텐츠를 수정할 수 있었습니다. 즉, 파일을 이리저리 옮기거나 심지어 다시 압축할 수도 있었죠. 실제로, 빌드 프로세스에 포함된 zipalign 도구가 정확히 그런 작업을 수행했습니다. 이 도구는 런타임 성능 향상을 위해 알맞은 바이트 경계에 ZIP 항목을 맞추는 데 사용되었습니다.

v2 서명은 애플리케이션 패키지를 구성하는 파일을 개별로 인증하지 않고 패키지 자체를 통째로 인증하므로, 서명 후에는 zipalign을 더 이상 실행할 수 없습니다. 그게 바로 압축, 정렬 및 서명 작업이 지금은 단 하나로 통합된 빌드 프로세스 단계에서 이루어지는 이유입니다.

빌드 프로세스에 어떠한 식으로든 APK 파일을 변조하거나 후처리하는 사용자 설정 작업이 있는 경우에는 해당 작업을 중지하세요. 그렇지 않으면 v2 서명이 무효화되어 APK가 Android 7.0 이상 버전과 호환되지 않을 위험이 있습니다.

개발자들이 (명령줄 등을 통해) 수동으로 서명하고 정렬하는 방식을 선택한다고 가정하고 Android SDK에 apksigner라는 새로운 도구를 제공합니다. 이 도구는 v1 및 v2 APK 서명 및 인증 기능을 모두 제공합니다. 참고로, v2 서명을 사용하는 경우 apksigner를 실행하기 전에 zipalign을 실행해야 합니다. 또한, JDK에서 제공되는 jarsigner 도구는 Android v2 서명과 호환되지 않으므로 v2 서명을 유지하려면 이 도구를 사용해 APK를 다시 서명할 수 없다는 점에 유의하세요.

Android Gradle 플러그인을 사용하여 빌드할 때 v1 또는 v2 서명을 추가하지 못하게 하려는 경우에는 build.gradle의 signingConfig 섹션에 다음 줄을 추가하면 됩니다.

v1SigningEnabled false
v2SigningEnabled false

참고: 두 가지 서명 구성표는 모두 Android Gradle 플러그인 2.2에서 기본적으로 사용됩니다.


더 작은 APK를 위한 릴리스 빌드

저희는 이번 기회에 패키지 작성 도구를 다시 작성할 때 릴리스 APK의 크기를 일정 수준 최적화했으며, 이에 따라 Play Store에서 다운로드 속도를 높이고 델타 업데이트 크기를 줄여 기기에서 낭비되는 공간을 줄이는 성과를 얻었습니다. 다음은 저희가 수행한 몇 가지 변경 사항입니다.
  • 애플리케이션 패키지 내 파일들이 정렬되어 APK간의 차이가 최소화됩니다.
  • 모든 파일 타임스탬프와 메타데이터는 0으로 처리됩니다.
  • 레벨 6 및 레벨 9 압축이 모든 파일에 대해 병렬로 검사되어 가장 적합한 압축 레벨이 사용됩니다. 즉, L9이 크기 면에서 거의 이점이 없다면 성능 향상을 위해 L6가 선택될 수 있습니다.
  • 네이티브 라이브러리가 압축되지 않고 페이지가 정렬된 상태로 APK에 저장됩니다. 이에 따라 Android 6.0 Marshmallow의 android:extractNativeLibs="false" 옵션이 지원되며, 이를 통해 애플리케이션은 기기에서 더 적은 공간을 사용할 뿐만 아니라 Play Store에서는 더 작은 업데이트를 생성할 수 있습니다.
  • Play Store 업데이트 알고리즘을 더욱 효과적으로 지원하기 위해 Zopfli 압축은 사용되지 않습니다. Zopfli로 APK를 다시 압축하지 않는 것이 좋습니다. 여전히 프로젝트에서 PNG 파일과 같은 개별 리소스를 사전에 최적화하는 것이 좋습니다.
이렇게 변경함으로써 사용자가 속도가 연결 속도가 느리거나 성능이 떨어지는 기기를 사용하는 상황에서도 정상적으로 앱을 다운로드하고 업데이트할 수 있도록 릴리스를 가능한 한 작게 만드는 데 도움이 됩니다. 하지만 디버그 빌드는 어떨까요?


설치 속도를 높이기 위한 디버그 빌드

앱을 개발할 때는 반복 주기, 즉 코드를 변경하여 빌드하고 연결된 기기나 에뮬레이터에 배포하는 과정을 빠르게 유지하고 싶으실 겁니다. Android Studio 2.0부터는 이 모든 단계를 최대한 빠르게 진행할 수 있도록 노력하고 있습니다. Instant Run을 통해 이제는 런타임 중에 변경된 코드와 리소스만 업데이트할 수 있으며, 그와 동시에 새 에뮬레이터는 멀티프로세서를 지원하고 더욱 빠른 APK 전송과 설치가 가능하도록 ADB 속도를 높여 줍니다. 빌드 기능 개선을 통해 그 시간을 훨씬 더 단축할 수 있으며, Android Studio 2.2에서 디버그 빌드를 위한 증분식 패키징과 병렬 압축 기능을 도입할 예정입니다. 대상 기기 밀도와 ABI를 위한 선택적인 리소스 패키징 등의 다른 기능과 더불어, 이 기능 덕분에 훨씬 더 빠르게 개발 작업을 수행할 수 있을 것입니다.

주의: Instant Run용으로 생성되었거나 디버그 빌드를 호출하여 생성된 APK 파일은 Play Store에 배포할 수 없습니다! 이 파일에는 Instant Run을 위한 추가 기기 코드가 포함되어 있으며 빌드를 시작할 때 연결되어 있던 기기를 제외한 기타 기기 구성의 리소스는 빠져 있습니다. Android Studio의 Generate Signed APK 명령어나 assembleRelease Gradle 작업을 사용하여 생성할 수 있는 APK의 릴리스 버전만 배포해야 합니다.

게시자: Wojtek Kaliciński, Android 디벨로퍼 어드보케

Firebase에 개발자가 멋진 앱을 더 쉽게 빌드할 수 있게 해주는 기능 일체가 포함되어 있다는 사실을 알고 계셨나요?

우리가 한동안 "게임" 대신 "앱"에 대한 얘기를 해왔다는 사실을 눈치채셨을지 모르겠군요. 그건 여러분이 Swift, 자바 또는 Objective-C로 앱을 작성하는 한 Google의 모바일 라이브러리가 훌륭하게 작동하기 때문이에요.

문제는 대부분의 게임 개발자들이 C++에서 자체 게임 엔진을 빌드하거나 인기가 많은 타사 게임 플랫폼(예: Cocos2D 또는 Unity)을 사용해 모바일 게임을 구동하고 있다는 사실입니다. 현재로서는 베타 버전으로 사용할 수 있는 C++ 버전의 Firebase 라이브러리를 구축한 상태인 데 반해, Unity 개발자들은 구식의 Firebase 데이터베이스 플러그인을 사용하는 상태로 남아 있습니다.

지금까지도 말입니다! Google의 많은 엔지니어들이 수고를 아끼지 않고 여러분이 계속해서 피드백을 주신 덕분에 Firebase 플랫폼의 훨씬 더 많은 기능을 포함하는 Unity SDK를 새로 출시하고 공식적으로 지원하게 되었습니다.

이것이 Unity 개발자에게는 어떤 의미일까요? 저희가 5월에 발표했던 새로운 Firebase 기능 중 많은 기능을 이제 활용할 수 있게 되었다는 의미랍니다. 즉, 다음과 같은 기능들이죠.

Firebase Analytics: 게임 내에서 발생하는 이벤트를 기록하는 분석 패키지로, 무료로 무제한으로 사용할 수 있습니다. 이 기능으로 게임 플레이어가 더 이상 나아가지 못하는 곳이 어딘지, 잠재고객이 시간이 지남에 따라 어떤 식으로 증가하는지, 또는 각국의 플레이어가 프리미엄 통화를 주로 어디에 쓰는지 알 수 있죠. 이 모든 것은 Firebase Analytics를 사용해 쉽게 기록할 수 있고, BigQuery와의 통합을 통해 작업하는 도중에 훨씬 더 정교한 데이터 마이닝을 실행할 수 있습니다.

Firebase 실시간 데이터베이스: 앱 데이터가 모든 기기에 걸쳐 보통 수백 밀리초 내에 마법처럼 동기화되는 데이터베이스입니다. 이는 사용자의 저장된 게임을 기기 간에 동기화하거나 턴 방식의 보드, 카드 또는 전략 게임을 구동하는 데 도움이 될 수 있으므로, 게임 내 채팅 기능과 같이 거의 실시간에 가까운 기능에 유용합니다. 즉, 멀티플레이어 슈팅 게임이나 MOBA를 구동하는 데 이 기능을 사용하고 싶진 않을 겁니다. 저는 게임 개발자들을 잘 알고 있어요. 그래서 '실시간'이 실제로 의미하는 바에 대해 좀 더 분명하게 짚어봐야 할 필요가 있답니다. ;)

동적 링크: 플레이어를 게임의 어떤 요소로 안내하거나(플레이어가 게임을 설치한 경우) Play Store/App Store로 이끌기 위해(플레이어가 게임을 설치하지 않은 경우) 사용할 수 있는 모바일 딥 링크입니다. 저는 게임 개발자가 동적 링크를 활용할 수 있는 최고의 사용 사례는 동적 링크를 사용해 인앱 공유를 가능하게 하는 것이라고 생각해요. 동적 링크를 사용하면 게임의 어떤 레벨을 재생하여 공유하거나 플레이어의 멋진 새 캐릭터/요새/사용자가 생성한 콘텐츠로 연결해 주는 링크를 공유할 수 있습니다. 이 모든 작업을 수행하는 자체 인터페이스를 빌드하고 싶은 생각이 없다면 Firebase 초대를 통해 멋진 형식의 이메일이나 SMS 메시지 안에 동적 링크가 패키징되어 자동으로 생성되도록 할 수도 있습니다.

인증: "휴우~ 전 정말이지 게임을 만드는 데만 집중하고 싶은데 인증 시스템을 빌드하느라 시간을 다 써버리는 것 같아요"라고 말하는 게임 개발자는 지금까지 없었습니다. Firebase 인증을 사용하여 앱을 개발하면 Facebook, Google, Github 등 제3의 공급자 서비스를 이용하던 사용자가 더욱 쉽게 여러분의 앱에 로그인할 수 있도록 하거나 맞춤 사용자 이름 및 비밀번호 시스템을 더욱 쉽게 만들 수 있습니다.

클라우드 메시징: Firebase 클라우드 메시징을 사용하면 단일 엔드포인트를 통해 iOS 기기와 Android 기기로 모두 알림을 보낼 수 있습니다. 또한, Firebase 알림 패널을 통해 알림을 보낼 수도 있습니다. 즉, 개발팀에서 기술 담당자가 아닌 팀원이라도 맞춤 서버 코드나 curl 호출 작성에 대한 염려 없이 알림을 보낼 수 있습니다.

원격 구성: 이 기능을 사용하면 클라우드에서 게임의 값을 업데이트할 수 있습니다. 솔직히 말해, 이는 게임과 관련해 제가 가장 흥미를 느끼는 기능입니다. 타워 방어 게임을 설계한 사람이면 누구나 하나의 유닛에서 압도적인 하나의 기록이 전체 게임의 균형을 무너뜨릴 수 있다는 점을 알고 있을 겁니다. 원격 구성에서는 클라우드에서 이러한 값을 변경한 후 Firebase Analytics를 사용해 이러한 변경이 기대하는 결과를 가져다 줄지 확인할 수 있습니다. 원격 구성을 사용하면 전문가 플레이어와 같은 특정 사용자 그룹에 사용자 설정 값을 제공할 수도 있습니다.

Android 기기와 iOS 기기에 이 라이브러리를 직접 사용할 수 있지만, 관련 팀에서 친절하게도 Windows, macOS 및 Linux용 스텁 메서드에 추가해 두었으므로 데스크톱도 대상으로 하는 게임인 경우 많은 조건 코드를 추가하는 문제를 걱정할 필요가 없습니다. 여담으로, SDK의 실시간 데이터베이스 부분은 Unity 편집기 내에서 직접 작동하여 테스트와 디버그 작업이 좀 더 훌륭하게 이루어집니다.


Unity용 Firebase SDK를 직접 시험해 보세요! 바로 여기서 사용할 수 있으며, 개발자가 꽤 멋진 게임을 더 쉽게 빌드할 수 있게 해주는 기능이 전부 포함되어 있습니다.

Todd Kerpelman 디벨로퍼 어드보케

▶ 원문 링크


요즘 인공 지능과 관련된 흥미진진한 일들이 많이 일어나고 있습니다. 그래서 스스로 머신 러닝 기술을 한번 다루어 보려는 사람들도 많습니다. 저희는 엔지니어든, 취미로 하는 사람이든, 학생이든, 단순히 호기심 넘치는 사람이든 상관없이, 누구라도 인공 지능 기술을 더 쉽게 다루어 볼 수 있도록 도움을 드리고 싶습니다. 하지만 때로는 이제 막 인공 지능 기술을 접하는 사람들이 꽤나 두려움에 휩싸일 수도 있습니다.

그게 바로 저희가 A.I. Experiments라고 하는 사이트를 만든 이유입니다. 이 사이트에서는 누구라도 인공 지능 기술과 관련된 실습을 통해 간단히 실험해보고 나름대로의 실험 환경을 만들 있는 리소스를 제공합니다.



이런 실험을 통해 머신 러닝이 이미지, 그림, 언어, 소리 등과 같은 모든 종류의 것들을 어떻게 이해하는지 알 수 있습니다. 이런 실험은 웹 개발자, 음악가, 게임 디자이너, 새 소리 연구가, 데이터 시각화 전문가 등 각기 다른 관심 사항을 가진 사람들이 고안한 것으로, 참여한 모든 이가 머신 러닝을 사용하는 방법에 대한 각자의 아이디어를 제공하고 있습니다.

또한, 코드 작성자도 자신만의 실험을 더욱 쉽게 만들어 볼 수 있도록 하고 싶습니다. 저희가 특별히 선보이는 많은 프로젝트는 Cloud Vision API, Tensorflow 및 머신 러닝 커뮤니티에서 얻을 수 있는 기타 라이브러리 등, 누구라도 사용할 수 있는 도구를 사용해 빌드한 것입니다. 이 사이트에는 제작자들이 자신의 작업 방식을 설명하는 동영상과 함께, 시작하는 데 도움이 되는 오픈소스 코드로 연결해 주는 링크가 포함되어 있습니다. A.I. Experiments 웹 사이트에 들러 자신이 직접 만든 결과물을 제출하거나 다른 사람들이 올려둔 것을 살펴시기 바랍니다.

머신 러닝으로 어떤 일을 할 수 있는지 더 심층적으로 알고 싶으면 Google Arts & Culture에서 동료 개발자들의 새로운 실험을 확인해 보세요.

Alexander Chen, Creative Lab

▶ 원문 링크


Google 웹마스터 센터는 귀하에게 도움이 되길 바라며 지난 몇 주간 Accelerated Mobile Pages에 대한 수많은 세부사항을 정리했습니다. 다음의 주제를 다룹니다.

또한 웹마스터 포럼에서 Google 검색에서 AMP 사용을 시작하는 것에 대한 몇 가지 AMP 질문을 확인했습니다. 도움을 드리고자 Google 웹마스터 센터에서 확인한 가장 일반적인 질문 몇 가지를 정리해 보았습니다.


질문: 웹사이트의 AMP 페이지 제작을 고려하고 있습니다. 장점이 무엇인가요? 어떤 사이트와 페이지에 AMP가 적합한가요?

사용자는 빠르고 수월하게 로드되는 콘텐츠를 좋아합니다. AMP 형식을 사용하면 사용자가 모바일 기기에서 콘텐츠를 사용하고 몰입할 의향을 높여줄 수 있습니다. 연구에 따르면 사용자 중 40%가 로드에 3초 이상 걸리는 사이트를 떠납니다. The Washington Post는 AMP를 적용한 결과 기사 로드 시간이 88% 감소하고 모바일 검색결과에서 재방문하는 사용자 수가 23% 증가했습니다.

AMP 형식은 뉴스, 레시피, 영화 목록, 제품 페이지, 리뷰, 동영상, 블로그 등 모든 정적 웹 콘텐츠에 유용합니다.

질문: 이미 문제를 해결했는데도 Search Console에 AMP 페이지 오류가 기록됩니다. 왜 아직도 오류가 표시되나요?

간단히 답변하면 Search Console에 AMP 페이지 변경사항이 업데이트될 때까지 약 1주가 걸립니다. 더 자세한 답변은 Google 웹마스터 트렌드 분석 담당자 John Mueller가 Search Console 지연 문제에 대해 공유한 자세한 게시물을 참조하세요.

질문: AMP 페이지가 Google 검색에 표시되지 않습니다. 어떻게 하나요?

유효한 AMP 페이지만 Google 검색에 표시됩니다. AMP HTML 웹 유효성 검사 도구Chrome 또는 Opera 확장 프로그램을 사용하여 AMP 페이지의 유효성을 검사하거나 크론 작업과 같은 좀 더 자동화된 프로세스를 통해 새 콘텐츠가 모두 유효한지 확인합니다.

AMP 페이지에 schema.org 구조화된 데이터를 포함하는 것을 전반적으로 권장하며(JSON-LD 추천) 이는 특히 뉴스 게시자에게 중요합니다. 유효한 마크업 속성을 포함하는 뉴스 콘텐츠는 Google 검색 결과의 주요 뉴스 섹션에 표시될 수 있습니다. 구조화된 데이터를 테스트하려면 구조화된 데이터 테스트 도구를 사용해 보세요.

여기에서 해결되지 않은 질문이 있으면 아래의 댓글이나 Google 웹마스터 Google+ 페이지에 의견을 공유해 주세요. 자유롭게 웹마스터 도움말 포럼에 글을 게시하셔도 좋습니다.

게시자: Tomo Taylor, AMP 커뮤니티 관리자

▶ 원문 링크


Firebase 인증은 Google, Facebook, Twitter 및 GitHub를 통해 매우 쉽게 인증을 수행할 수 있도록 하는 페더레이션 ID 공급자를 지원합니다. 예를 들어, 웹 앱에서 Firebase 사용자가 Google로 로그인하는 데 필요한 모든 사항은 다음과 같습니다.

var google = new firebase.auth.GoogleAuthProvider();
firebase.auth().signInWithPopup(google);

하지만 어떤 경우에는 사용자가 다른 ID 공급자를 이용하여 Firebase 앱에 로그인할 수 있도록 하고 싶을 수도 있습니다. 예를 들어, 사용자가 Instagram API를 사용해 Instagram 사진을 공유할 수도 있도록 할 계획인 경우에는 특히 Instagram이 훌륭한 대안이 될 수 있습니다.
Firebase가 기본적으로 지원하지 않는 ID 공급자도 이용할 수 있으나, 이 경우 약간 더 많은 코드 및 서버가 필요합니다. 그러면 Instagram 로그인을 Firebase 웹 앱에 통합하는 데 필요한 단계를 살펴봅시다. Instagram은 로그인에 OAuth 2.0을 사용하므로, 이 게시물은 LinkedIn과 같은 다른 OAuth 2.0 ID 공급자를 적용하는 데도 틀림없이 도움이 될 것입니다.


디자인 개요

Instagram은 앱을 승인하고 Instagram 사용자의 ID를 포함하는 사용자 데이터에 액세스하기 위한 주요 경로로써 OAuth 2.0을 지원합니다. 이 경우, 사용자가 OAuth 2.0 인증 코드 흐름을 거치고 앱에 액세스 권한을 부여하도록 해야 합니다. 다음은 OAuth 2.0 흐름의 진행 방식입니다.

우선, Instagram의 승인 엔드포인트로 사용자를 리디렉션해야 합니다. 그러면 Instagram에서는 사용자에게 개발자의 앱에 대한 액세스 권한을 부여하도록 최초 요청 시 동의 작업을 팝업 창을 통해 수행합니다.

사용자가 앱을 승인한 후에는 인증 코드와 함께 도메인으로 다시 리디렉션됩니다. 서버 쪽에서는 Instagram 앱의 사용자 인증 정보를 사용하여 액세스 토큰을 얻기 위해 인증 코드를 교환할 수 있습니다. 인증 코드를 교환하는 프로세스에서 Instagram은 사용자 ID도 반환합니다. LinkedIn 등의 다른 OAuth 2.0 공급자를 이용하는 경우에는 가끔 추가적인 요청이 필요하기도 합니다.
서버에서 Instagram 사용자 정보를 가져온 후 Firebase 맞춤 인증 토큰을 생성합니다. 사용자는 이 토큰을 통해 signInWithCustomToken 메서드를 사용하여 웹 앱에서 Firebase에 로그인할 수 있습니다.
클라이언트에서 Firebase 프로필을 업데이트할 수 있도록 표시 이름, 사진 URL 등, Instagram에서 가져온 사용자 프로필 정보도 전달해보겠습니다. (참고: Instagram은 사용자의 이메일을 제공하지 않으므로 이메일 정보가 없는 Firebase 계정을 가지게 될 텐데, 그래도 괜찮습니다.) 작업을 마쳤으면 팝업을 닫습니다. 그러면 이제 사용자가 Instagram 계정에서 가져온 프로필 데이터로 Firebase에 로그인됩니다.


실제로 빌드해 봅시다!

이제 좀 더 세부적으로 들어가서, 이 통합의 핵심 요소를 구현하는 방법을 살펴봅시다. Node.js에서 백엔드를 작성해볼게요.


Instagram으로 앱 등록

웹 앱에 Instagram 인증 흐름을 시작하는 버튼을 추가해야 합니다. 이를 수행하려면 먼저 OAuth 2.0에 필요한 앱 사용자 인증 정보를 가져올 수 있도록 애플리케이션을 Instagram Developers 콘솔에 등록해야 합니다.
Instagram 앱 구성에서 http://localhost:8080/instagram-callback(테스트용) 및 https:///instagram-callback(프로덕션 도메인)을 유효한 리디렉션 URI로 허용 목록에 추가했는지 확인하세요. Instagram 클라이언트 ID클라이언트 비밀번호는 따로 잘 적어두세요. 나중에 필요하니깐요.

클라이언트 ID와 비밀번호를 가져오려면 앱을 등록하고 콜백 URL을 허용 목록에 추가하세요. 이는 모든 OAuth 2.0 공급자 이용 시 진행해야 하는 일반적인 단계입니다.


Instagram의 OAuth 2.0 구성

서버에서 OAuth 2.0 프로토콜의 세부 정보를 숨기는 데 도움이 되는 simple-oauth2 패키지를 사용하겠습니다. 이 패키지를 설정하려면 Instagram 클라이언트 ID와 비밀번호, 그리고 Instagram의 OAuth 2.0 토큰 및 승인 엔드포인트와 같은 몇 가지 값을 제공해야 합니다. 다음은 Instagram에 사용해야 하는 값입니다.
// Instagram OAuth 2 setup
const credentials = {
 client: {
   id: YOUR_INSTAGRAM_CLIENT_ID, // Change this!
   secret: YOUR_INSTAGRAM_CLIENT_SECRET, // Change this!
 },
 auth: {
   tokenHost: 'https://api.instagram.com',
   tokenPath: '/oauth/access_token'
 }
};
const oauth2 = require('simple-oauth2').create(credentials);


Instagram 인증 흐름 시작

서버에서 사용자를 Instagram의 동의 화면으로 리디렉션하는 URL 핸들러를 추가하세요. 이 작업의 일부로, 사용자가 Instagram 인증 흐름을 거친 후 다시 리디렉션되는 경로인 리디렉션 URI를 입력해야 합니다. 이 경우에는 /instagram-callback을 콜백 핸들러 경로로 사용하겠습니다.

app.get('/redirect', (req, res) => {
  // Generate a random state verification cookie.
  const state = req.cookies.state || crypto.randomBytes(20).toString('hex');
  // Allow unsecure cookies on localhost.
  const secureCookie = req.get('host').indexOf('localhost:') !== 0;
  res.cookie('state', state.toString(), {maxAge: 3600000, secure: secureCookie, httpOnly: true});
  const redirectUri = oauth2.authorizationCode.authorizeURL({
    redirect_uri: `${req.protocol}://${req.get('host')}/instagram-callback`,
    scope: 'basic',
    state: state
  });
  res.redirect(redirectUri);
});

또한, 세션 고정 공격을 피하기 위해 OAuth 요청의 상태 매개변수에 임의의 문자열을 전달하고 이를 HTTP 쿠키로도 저장합니다. 이를 통해 반환되는 상태 매개변수를 쿠키에 저장된 매개변수와 비교하고 흐름이 앱에서 발생했는지 확인할 수 있습니다.

클라이언트에서 다음과 같이 팝업을 트리거하는 버튼을 추가하세요.

function onSignInButtonClick() {
  // Open the Auth flow in a popup.
  window.open('/redirect', 'firebaseAuth', 'height=315,width=400');
};

사용자가 로그인 버튼을 클릭하면 팝업이 열리면서 Instagram 동의 화면으로 리디렉션됩니다.

사용자가 승인하면 code URL 쿼리 매개변수에 전달된 승인 코드와 앞서 전달한 state 값과 함께 /instagram-callback URL 핸들러로 다시 리디렉션됩니다.


액세스 토큰을 얻기 위한 승인 코드 교환

사용자가 콜백 URL로 다시 리디렉션되면 다음을 수행하세요.
  • 상태 쿠키가 상태 URL 쿼리 매개변수와 동일한지 확인하세요.
  • 인증 코드를 교환하여 액세스 토큰을 얻고 Instagram에서 사용자 ID를 검색하세요.
app.get('/instagram-callback',(req, res) => {
  // Check that we received a State Cookie.
  if (!req.cookies.state) {
    res.status(400).send('State cookie not set or expired. Maybe you took too long to authorize. Please try again.');
  // Check the State Cookie is equal to the state parameter.
  } else if (req.cookies.state !== req.query.state) {
    res.status(400).send('State validation failed');
  }

  // Exchange the auth code for an access token.
  oauth2.authorizationCode.getToken({
    code: req.query.code,
    redirect_uri: `${req.protocol}://${req.get('host')}/instagram-callback`
  }).then(results => {
    // We have an Instagram access token and the user identity now.
    const accessToken = results.access_token;
    const instagramUserID = results.user.id;
    const profilePic = results.user.profile_picture;
    const userName = results.user.full_name;

    // ...

  });
});

이제 이 구현의 OAuth 2.0 관련 부분을 마쳤으므로, 다음으로 할 일은 대부분 Firebase와 관련된 일입니다.

다음으로, Firebase 맞춤 인증 토큰을 생성하고, 맞춤 인증 토큰으로 사용자를 로그인시키고 Firebase 사용자 프로필을 업데이트할 HTML 페이지를 제공합니다(이에 대해서는 나중에 자세히 설명함).

app.get('/instagram-callback', (req, res) => {

    // ...

  }).then(results => {
    // We have an Instagram access token and the user identity now.
    const accessToken = results.access_token;
    const instagramUserID = results.user.id;
    const profilePic = results.user.profile_picture;
    const userName = results.user.full_name;
      
    // Create a Firebase custom auth token.
    const firebaseToken = createFirebaseToken(instagramUserID);

    // Serve an HTML page that signs the user in and updates the user profile.
    res.send(
        signInFirebaseTemplate(firebaseToken, userName, profilePic, accessToken)));
  });
});


맞춤 인증 토큰 생성

Firebase 맞춤 인증 토큰을 생성하려면 서비스 계정 사용자 인증 정보를 사용하여 Firebase를 설정해야 합니다. 그러면 이런 토큰을 만드는 데 필요한 관리 권한이 부여됩니다. 서비스 계정 사용자 인증 정보 파일을 service-account.json으로 저장해야 합니다.

const firebase = require('firebase');
const serviceAccount = require('./service-account.json');
firebase.initializeApp({
  serviceAccount: serviceAccount
});

맞춤 인증 토큰은 간단히 만들 수 있습니다. Instagram의 사용자 ID를 기반으로 사용자의 uid를 선택하기만 하면 됩니다.

function createFirebaseToken(instagramID) {
  // The uid we'll assign to the user.
  const uid = `instagram:${instagramID}`;

  // Create the custom token.
  return firebase.auth().createCustomToken(uid);
}

(참고: 서비스 계정 사용자 인증 정보는 안전하게 지켜야 하므로, 맞춤 토큰은 항상 서버 쪽에서 생성해야 합니다.)

맞춤 토큰을 생성했으면 Firebase에 로그인하는 클라이언트에 이를 전달할 수 있습니다.


맞춤 토큰을 사용하여 로그인

이 시점에서 서버는 팝업 창 내에서 실행되는 HTML 페이지를 제공하며 다음 작업을 수행합니다.
  • 나중에 Instagram API에 액세스해야 하는 경우 Instagram 액세스 토큰을 실시간 데이터베이스에 저장합니다. (참고: 사용자만 읽을 수 있도록 하는 보안 규칙을 사용해야 합니다.)
  • Firebase 사용자의 이름과 프로필 사진을 업데이트합니다.
  • 사용자를 로그인시키고 팝업을 닫습니다.

기본 Firebase 앱을 사용하는 대신 임시 Firebase 앱 인스턴스를 사용하여 프로필을 업데이트하는 것도 하나의 묘책입니다. 그러면 사용자의 프로필이 업데이트되기 전에 기본 페이지에서 인증 리스너가 트리거되지 않도록 차단됩니다.

app.get('/instagram-callback', (req, res) => {

    // ...

    // Serve an HTML page that signs the user in and updates the user profile.
    res.send(
        signInFirebaseTemplate(firebaseToken, userName, profilePic, accessToken)));
  });
});

function signInFirebaseTemplate(token, displayName, photoURL, instagramAccessToken) {
 return `
   <script src="https://www.gstatic.com/firebasejs/3.4.0/firebase.js"></script>
   <script src="promise.min.js"></script><!-- Promise Polyfill for older browsers -->
   <script>
     var token = '${token}';
     var config = {
       apiKey: MY_FIREBASE_API_KEY, // Change this!
       database URL: MY_DATABASE_URL // Change this!
     };
     // We sign in via a temporary Firebase app to update the profile.
     var tempApp = firebase.initializeApp(config, '_temp_');
     tempApp.auth().signInWithCustomToken(token).then(function(user) {
    
       // Saving the Instagram API access token in the Realtime Database.
       const tasks = [tempApp.database().ref('/instagramAccessToken/' + user.uid)
           .set('${instagramAccessToken}')];
  
       // Updating the displayname and photoURL if needed.
       if ('${displayName}' !== user.displayName || '${photoURL}' !== user.photoURL) {
         tasks.push(user.updateProfile({displayName: '${displayName}', photoURL: '${photoURL}'}));
       }
  
       // Wait for completion of above tasks.
       return Promise.all(tasks).then(function() {
         // Delete temporary Firebase app and sign in the default Firebase app, then close the popup.
         var defaultApp = firebase.initializeApp(config);
         Promise.all([
             defaultApp.auth().signInWithCustomToken(token),
             tempApp.delete()]).then(function() {
           window.close(); // We’re done! Closing the popup.
         });
       });
     });
   </script>`;
}

사용자가 팝업에서 기본 Firebase 앱에 로그인된 후 인증 상태 리스너가 기본 페이지에서 트리거됩니다. Firebase에서는 인증 상태가 여러 탭 간에 공유된다는 점을 기억하세요. 사용자 프로필 정보를 표시하고, 실시간 데이터베이스, Firebase 저장소 등을 사용할 수 있습니다.


직접 시험해 보세요!

저희는 개발자 여러분이 시험해 볼 수 있는 데모 앱을 https://instagram-auth.appspot.com/에 만들어 두었습니다.

이 샘플은 오픈소스입니다. Github(https://github.com/firebase/custom-auth-samples)에서 관련 리소스를 자유롭게 살펴보시기 바랍니다.


Android와 iOS는 어떠냐고요?

지금까지 이 글에서 보여드린 코드는 웹 앱에서 작동하는 코드입니다. Instagram 인증을 Android 또는 iOS 앱에 추가하는 데는 몇 가지 기법이 있으며 이 게시물에서는 이에 대해 다루지 않을 것이므로 계속해서 새로운 소식이 있는지 눈여겨보시기 바랍니다!


다 되었습니다!

다른 ID 공급자에 대한 샘플을 찾고 있거나 이를 통합하는 데 문제가 있는 경우 댓글을 쓰거나 GitHub 리포지토리 문제를 사용하여 알려주시면 저희가 성심껏 도와드리겠습니다!

▶ 원문 링크

전 세계적으로 디지털 정보를 공유하는 데 있어 해결해야 할 주요 문제는 컴퓨터가 텍스트를 표시할 수 없는 경우에 나타나는 빈 상자(⯐)를 의미하는, 소위 '두부(tofu)' 문제입니다. 이러한 두부 문제는 혼란과 커뮤니케이션 장애를 일으키고 사용자 환경을 저해할 수 있습니다.

5년 전, Google은 Noto, 즉 'No more tofu(두부 문제 방지)'라고 하는 글꼴 프로젝트를 통해 이 문제를 해결하는 작업에 착수했습니다. 오늘날, Google의 오픈소스 Noto 글꼴 모음은 유니코드 표준에 포함된 모든 기호에 대해 아름다우면서도 일관된 디지털 활자를 제공하여, 800개가 넘는 언어와 110,000자가 넘는 문자를 지원합니다.

캡션: Noto 글꼴에서 지원하는 110,000자 이상의 문자 중 몇 가지 샘플입니다.


Noto 프로젝트는 Google Android 및 ChromeOS 운영체제의 필요로 시작되었습니다. 시작할 당시에는 이 문제가 얼마나 심각한지 인식하지 못했습니다. 따라서 수백 개의 언어를 대상으로 디자인 및 기술적인 측면에서 테스트를 수행해야 했으며, 특정 스크립트의 경우 전문가의 전문 지식이 필요했습니다. 예를 들어, 아랍어의 경우 각 문자에는 그 다음에 오는 텍스트에 따라 달라지는 4개의 문자 모양(즉, 문자가 취할 수 있는 모양)이 있습니다. 인도어의 경우, 문자 모양이 주변 텍스트에 따라 재정렬되거나 두 개로 분할될 수 있습니다.

이러한 중요한 목표를 실현하기 위해 Monotype, Adobe 및 자원 봉사 검토자로 구성된 훌륭한 네트워크를 포함하여 활자 및 글꼴 디자인 부문의 전문가와 협력해 왔습니다. 매일 사용되는 공통 언어에서 '두부 문제를 방지'하는 것을 뛰어넘어 Noto는 디지털화를 통해 자주 사용되지 않는 언어에 대한 기록과 문화를 유지할 목적으로도 사용됩니다. 새로운 문자가 유니코드 표준에 도입될 때 마다 Google은 이 문자를 Noto 글꼴 모음에 추가할 예정입니다.

Google은 이 글꼴 모음과 함께 개방성, 접근성, 혁신을 구현하는 데 최선을 다하고 있습니다. 전체 Noto 글꼴 모음, 디자인 소스 파일 및 글꼴 구성 파이프라인을 아래 링크에서 무료로 이용할 수 있습니다. 국경과 문화의 벽을 뛰어넘어 서로 나누고 소통하는 정신으로 즐겁게 이용해 보시기 바랍니다!

게시자: Xiangye Xiao 및 Bob Jung, 국제화
▶ 원문 링크

Firebase 호스팅에서 HTTP/2를 사용할 수 있게 되었다는 반가운 소식을 전해드립니다. HTTP/2는 HTTP 프로토콜의 최신 버전으로, 전 세계 브라우저중 77%가 이미 지원하고 있습니다. 웹 개발자에게는 다음과 같은 흥미로운 장점이 있습니다.
  • 단일 커넥션을 통해 여러 개의 요청을 전송할 수 있습니다. HTTP/2를 사용하면 여러 리소스를 묶을 필요성이 적어집니다.
  • HTTP/2는 바이너리 프로토콜이기 때문에 헤더를 압축할 수 있고 데이터를 더욱 효율적으로 전송할 수 있습니다.
  • 서버는 주도적으로 클라이언트에 콘텐츠를 "푸시"할 수 있습니다.
이 모든 점을 고려하면, 상당한 성능 이점은 물론이고 네트워크 속도가 느린 모바일 기기에서 웹 애플리케이션의 로드 속도를 빠르게 향상 시킬 기회가 생깁니다.

HTTP/2는 새롭게 프로비저닝되는 사용자 정의 도메인뿐 아니라 모든 *.firebaseapp.com 트래픽에도 사용할 수 있습니다. Firebase에서 맞춤 도메인을 이미 구축한 경우 아래의 맞춤 도메인 마이그레이션 섹션을 참조하십시오.

Firebase 호스팅에 HTTP/2 활용하기

아무 것도 하지 않아도 Firebase 호스팅에 HTTP/2를 활용할 수 있습니다! 사용자 브라우저가 지원하기만 하면 HTTP/2가 자동으로 제공됩니다. 하지만, HTTP/2에 맞게 최적화하려는 경우에는 염두에 두어야 할 몇 가지 모범 사례가 있습니다.
  1. 단일 연결을 사용하여 동시 요청을 다중 송신할 수 있기 때문에 많은 리소스를 함께 연결하기 위한 이점은 더 이상 없습니다. 브라우저는 리소스 캐시 작업을 훌륭하게 수행하므로, 실제로는 변경 빈도가 더 낮은 파일을 더 많이 제공하는 것이 좋습니다. 여기서 더 많은 파일은 수십개의 파일을 의미합니다. 수백 개의 파일을 처리하면 여전히 상당한 오버헤드를 수반할 수 있으므로 주의해야 합니다.
  2. 자산을 여러 도메인에 "분할"할 필요가 없습니다. Firebase 호스팅은 이미 빠른 CDN을 사용하기 때문에 HTTP/2를 사용하면 동일한 도메인에서 모든 파일을 제공하는 데 유리합니다.
  3. 따라서 필요한 자산만 로드하시기 바랍니다! 왕복 횟수가 더 적으므로 애플리케이션 셸을 부트스트랩하는 데 필요한 파일만 로드하도록 최적화해야 합니다. 다른 리소스는 사용자 상호 작용을 바탕으로 필요에 따라 로드되어야 합니다.
위에 명시된 지침은 꼭 지켜야 하는 규칙은 아닙니다. 성능 최적화를 할 때와 마찬가지로 어떤 최적화 조합이 앱의 요구 사항을 가장 잘 충족하는 결과를 제공하는지 다양하게 테스트해야 합니다.

서버 푸시 테스트

Firebase 호스팅은 Link 헤더를 사용하여 HTTP/2 서버 푸시를 시험적으로 지원합니다. 서버 푸시를 사용하면 초기 요청 수행 시 서버가 추가 리소스를 위한 콘텐츠를 자동으로 전송할 수 있습니다. 서버 푸시의 가장 일반적인 용도는 페이지가 로드될 때 연결된 자산(예: JavaScript 또는 CSS 파일)을 전송하는 것입니다.

Firebase 호스팅에 서버 푸시를 구성하려면 다음과 같이 Link 헤더를 firebase.json 구성에 추가해야 합니다.
{
  "hosting": {
    "headers": [
      {
        "source": "/",
        "headers": [{"key": "Link", "value": "</js/app.js>;rel=preload;as=script,</css/app.css>;rel=preload;as=style"}]
      },
      {
         "source": "/users/*",
        "headers": [{"key": "Link", "value": "</js/app.js>;rel=preload;as=script,</css/app.css>;rel=preload;as=style;nopush,</css/users.css>;rel=preload;as=style"}]
      }
    ]
  }
}


여기서는 루트 경로에서 /js/app.js와 /css/app.css를 미리 로드하고, /users/*와 일치하는 경로에서 /css/users.css를 추가로 미리 로드하는 데 서버 푸시를 사용합니다. 브라우저 캐시에 이미 있을 가능성이 큰 파일에 대해서는 (두 번째 예제의 app.css에 대한 지시문과 같이) nopush 지시문을 사용하여 HTTP/2 푸시를 사용하지 않고 자산을 미리 로드할 수 있습니다.

서버 푸시는 아직 초기 단계이므로 다음과 같이 명심해야 할 사항이 몇 가지 있습니다.
  1. Link 헤더를 설정하는 데 와일드카드를 사용하는 경우 주의해야 합니다. 리소스가 그 자체를 미리 로드하도록 설정하면 안 됩니다.
  2. 서버 푸시는 성능과 대역폭 사용 간에 균형을 맞추는 기술입니다. 즉, 브라우저에서 이미 캐싱된 자산을 푸시할 경우 불필요한 데이터를 전송하게 됩니다. 푸시되는 자산을 성능에 중요한 작은 자산으로 유지하도록 노력하고, 사용자가 휴대기기에서 추가 데이터에 대한 비용을 지불해야 할 수 있다는 점을 알고 있어야 합니다!
  3. 미리 로드하기 기능은 푸시를 사용하지 않고도 탁월한 성능을 제공하는 데 유용합니다! ;nopush를 미리 로드 Link 헤더에 추가하면 브라우저는 서버 푸시 없이 자산을 미리 로드합니다. 이는 브라우저에 이미 캐싱되어 있을 수 있다고 생각하는 자산에 유용합니다.
저희는 HTTP/2가 최초의 로드 환경을 개선할 잠재력이 얼마나 될지 무척 기대되며, 서버 푸시를 단순하고 안정적이며 사이트에 효과적인 것으로 만들어줄 더 많은 방법을 강구하고 있습니다.

맞춤 도메인 마이그레이션

HTTP/2로 마이그레이션하면서, 저희는 SSL 인증서를 SNI(Server Name Indication)로 전환하는 중입니다. SNI는 계속해서 인프라를 더욱 안정적으로 확장할 수 있도록 해주며, 전 세계 98% 브라우저에서 지원됩니다. 이러한 변화는 사용자 트래픽에 영향을 미칠 가능성이 있으므로, 2016년 12월까지 기존의 맞춤 도메인을 자동으로 전환하지 않을 계획입니다.

2016년 8월 11일 이전부터 Firebase 호스팅에 맞춤 도메인을 보유한 분이라면 DNS 레코드를 업데이트해야 HTTP/2를 이용할 수 있습니다. dig <your-site>.firebaseapp.com을 실행하여 SNI로 이미 전환되었는지 확인할 수 있습니다. 결과에 s-sni.firebaseapp.com이 표시되면 사이트가 이미 마이그레이션된 것입니다.

CNAME을 사용하는 경우 마이그레이션하려면 s-sni.firebaseapp.com을 가리키도록 DNS를 업데이트해야 합니다. A 레코드를 사용하는 경우에는 다음과 같이 업데이트하십시오.

151.101.1.195
151.101.65.195

DNS를 변경하고 그 변경 내용이 전파되면 사이트가 HTTP/2로 구동될 것입니다! 올해 말까지 모든 Firebase 호스팅 트래픽을 HTTP/2와 SNI로 전환할 예정입니다. 따라서 SNI가 사용자에게 어떤 영향을 미칠지 걱정된다면 지원 사이트를 방문하시기 바랍니다.

Firebase 호스팅과 관련된 저희의 목표는 모든 이가 PWA(Progressive Web Apps) 개발의 모범 사례를 자유롭게 활용하도록 하는 것입니다. HTTP/2는 이런 목표를 향한 여정에서 거치는 또 하나의 단계이며, 여러분이 이를 활용하여 무엇을 빌드할지 정말 기대됩니다!

▶ 원문 링크


Google I/O에서 저희는 고품질 모바일 VR(가상 현실)을 지원하는 플랫폼인 Daydream을 발표하고 개발자 여러분이 Daydream용 앱을 만들 수 있도록, 개발 도구를 공개했습니다. 그 후로, 저희 팀은 피드백을 수집하고, 이를 바탕으로 고품질 VR 앱과 서비스를 만들 수 있는, 효율적이고 강력한 개발자 도구를 제공할 수 있도록 계속해서 노력해 왔습니다.


저희는 Daydream을 지원하는 Google VR SDK 1.0에 대한 베타 시험이 완료되었음을 발표하게 되어 매우 자랑스럽게 생각하며, 현재 Daydream 개발자 사이트에서 정식 Google VR SDK 1.0을 다운로드할 수 있습니다. 업데이트된 SDK로 일반적인 VR 개발 작업을 간소화할 수 있습니다. 개발자는 Daydream 지원 휴대폰과 헤드셋을 위한 몰입형 모바일 VR 애플리케이션을 만드는데 데 집중할 수 있습니다. SDK는 입체 영상 구현을 위한 통합 비동기식 재투영(integrated asynchronous reprojection), 고성능 공간 오디오 및 Daydream 컨트롤러를 사용한 상호 작용을 지원합니다.

Google VR SDK 1.0을 사용하여 훨씬 더 쉽게 개발 작업을 시작할 수 있도록 하기 위해, 저희는 이미 익숙한 게임 엔진과 도구를 사용할 수 있도록 Unity 및 Unreal과 제휴했습니다. 또한, 설명서 전문, 참조 샘플 앱 및 가이드를 게시하여 사이트를 업데이트했습니다.

기본 Unity 통합

이번 릴리스에서는 Unity에 기본적으로 통합된 Daydream을 선보입니다. 이를 통해 Daydream 개발자는 VR 렌더링에 Unity의 최적화된 기능을 모두 활용할 수 있습니다. 또한, 헤드 추적, 딥 링크 및 간편한 안드로이드 매니페스트 구성과 같은 기능도 추가로 지원합니다. 많은 Daydream 실행 앱이 이미 이런 최신 통합 기능과 연동되고 있으며, 지금 새로운 Unity 바이너리(여기)와 Daydream 플러그인(여기)을 다운로드할 수 있습니다.

기본 UE4 통합

저희는 UE4 기본 통합을 더욱 개선했으며, 이는 개발자가 더욱 향상된 프로덕션 수준의 품질을 제공하는 Daydream 앱을 빌드하는 데 도움이 될 것입니다. 이 최신 버전에는 편집기에서 Daydream 컨트롤러 지원 기능, 넥 모델(neck model), 새로운 렌더링 최적화 기능 등이 추가되었습니다. UE4 개발자는 여기에서 소스를 다운로드할 수 있습니다.


지금 시작하세요.

초기 Daydream 지원 휴대폰 및 헤드셋이 이번 가을에 출시될 예정이지만, 지금 바로 Google VR SDK 1.0과 DIY 개발자 키트를 사용하여 고품질의 Daydream 앱 개발을 시작할 수 있습니다.

저희는 또한 Daydream을 위한 훌륭한 콘텐츠를 빌드하는 더욱 많은 개발자와 긴밀하게 작업할 수 있도록 현재 DAP(Daydream Access Program) 참가 신청을 받고 있습니다. DAP 참가 신청을 하려면 Daydream 앱 제안서를 제출하시기 바랍니다.

Daydream 플랫폼을 위한 콘텐츠를 만들 때는 앱이 모든 Daydream 지원 휴대폰과 헤드셋에서 아무런 문제 없이 원활하게 작동해야 한다는 점에 유의하세요. Daydream은 이제 막 시작되었으므로 함께 협력하여 새로운 몰입형 대화식 VR 환경을 빌드하는 데 도움을 드릴 수 있게 되기를 고대합니다. 곧 제공될 Daydream 지원 휴대폰 및 Daydream 헤드셋과 컨트롤러에 대한 추가 정보에 계속 관심을 가져 주세요.

▶ 원문 링크

현재 Google Play 개발자 지원팀에서는 채팅/이메일 2가지 채널을 통해 개발자 콘솔 및 정책 관련 이슈에 대한 상담을 지원하고 있습니다. 새로 업데이트된 'Google Play 개발자 지원팀에 문의하기' 페이지를 방문하시면 지원되는 모든 채널에 대한 정보와 운영 시간을 확인할 수 있으며, 페이지 내의 링크를 통해 채팅/이메일 상담 신청이 가능합니다.

채팅의 경우 개발자 콘솔, 도움말 센터, 혹은 Google Play 개발자 지원팀 문의 페이지 등 다양한 소스의 링크를 통해 바로 실시간 상담을 시작할 수 있습니다. 한국어 채팅은 공휴일을 제외하고 월요일부터 금요일까지 10~12시, 13~18시에 운영됩니다. 영어 채팅은 GMT(그리니치표준시) 기준으로 월요일 9시부터 금요일 23시 59분까지 운영됩니다. 


Google Play 개발자 지원팀에 문의하기 [링크]


    게시자: Google Play 개발자 지원팀