지난 2016년 10월 5일부터 기업용 Gmail 사용자를 대상으로 계정 보안 기능이 강화되었습니다. Google Apps 도메인을 사용 중인 사용자가 비밀번호를 변경하면, Gmail 기반 인증을 통해 발급받은 OAuth 2.0 토큰이 자동으로 해지 됩니다. 따라서, 해당 토큰을 사용하는 앱은 새로운 토큰을 발급받아야 하며, 그렇지 않으면 사용자 메일 수신함에 접근할 수 없게 됩니다. 이는 사용자가 Gmail 관련 토큰이 무효가 되는 시점 이후에 비밀번호를 변경하는 경우에만 적용됩니다.

개발자는 애플리케이션이 해지된 토큰으로 인해 발생하는 HTTP 400 또는 401 오류를 처리하도록 수정하고, 사용자가 OAuth 흐름을 다시 진행해 앱을 다시 인증할 수 있도록 요청해야 합니다. 작년 말에 저희는 이와 비슷하지만, 더욱 광범위한 인증 범위에 영향을 미치는 보안 정책 관련 변경 계획을 발표한 바 있습니다. 그 이후에 저희는 앱 고객을 대상으로 한 이런 변경 계획을 바로 진행하는 대신, 위에서 설명한 것처럼 영향력이 덜한 업데이트를 개발하는 작업에 착수했습니다.

토큰이 해지된다는 것은 무슨 의미입니까?

해지된 OAuth 2.0 토큰으로는 더는 사용자 정보에 접근할 수 없습니다. API 호출 시, 해지된 토큰을 사용하면 오류가 발생합니다. Google API에 접근하는 애플리케이션은 실패한 API 호출을 처리하도록 수정해야 합니다.

토큰 해지 그 자체는 새로운 기능이 아닙니다. 사용자는 예전부터 항상 보안 점검 메뉴에서 애플리케이션에 대한 접근을 해지할 수 있었고, Google Apps 관리자는 관리 콘솔에서 동일한 작업을 수행할 수 있습니다. 또한, 장기간 사용되지 않은 토큰은 항상 만료되거나 해지되었습니다. 다만, 보안 정책을 강화되어, 애플리케이션이 인식하는 해지된 토큰의 비율이 커질 수 있습니다.

어떤 API와 범위가 영향을 받습니까?

관리자와 최종 사용자가 느낄 혼란을 최소화하면서, 보안상의 이점을 달성하기 위해, 저희는 이 정책 변경을 이메일 범위에만 적용하고 Apps Script 토큰은 제외하기로 했습니다. Google Apps Marketplace를 통해 설치된 앱에도 토큰 해지가 적용되지 않습니다. 이 변경 사항이 적용되면 Apple Mail 및 Thunderbird와 같은 타사 메일 앱(물론, 하나 이상의 메일 범위를 포함하는 다중 범위를 사용하는 다른 애플리케이션도 해당함)에서 비밀번호를 재설정한 경우 새 OAuth 2.0 토큰이 부여될 때까지 데이터 액세스가 금지됩니다. 개발자 애플리케이션은 이 시나리오를 감지하여 애플리케이션이 계정 데이터에 접근하지 못하게 되었음을 사용자에게 알리고 OAuth 2.0 흐름을 다시 진행하도록 요청해야 합니다.

모바일 메일 애플리케이션도 이 정책 변경에 포함되었습니다. 예를 들어, iOS에서 기본 메일 애플리케이션을 사용하는 사용자는 비밀번호가 변경된 경우 해당 Google 계정 자격 증명을 사용하여 다시 인증해야 합니다. 모바일 환경에서 실행되는 타사 메일 앱 역시 사용자가 자신 계정의 비밀번호를 재설정하는 경우, 다시 사용자 인증 과정을 거쳐야합니다. iOS 및 Android에서 실행되는 Gmail 앱도 동일한 방식으로 동작합니다.

내 토큰이 해지되었는지 어떻게 확인할 수 있습니까?

수명이 짧은 액세스 토큰과 수명이 긴 새로 고침 토큰 둘 다, 사용자가 비밀번호를 변경하면 해지됩니다. 해지된 액세스 토큰을 사용하여 API에 접근하거나, 새 액세스 토큰을 생성하면 HTTP 400 또는 401 오류가 발생합니다. 애플리케이션이 라이브러리를 사용하여 API를 사용하거나 OAuth 흐름을 처리하는 경우, 예외로 발생할 가능성이 큽니다. 예외의 원인을 판단하는 자세한 방법은 라이브러리 관련 문서를 참조하십시오.

참고: HTTP 400 오류는 다양한 원인으로 발생할 수 있으므로, 해지된 토큰으로 인해 발생하는 400 오류의 페이로드는 다음과 유사할 것이라 예상할 수 있습니다.

{
  "error_description": "Token has been revoked.", 
  "error": "invalid_grant"
}

내 애플리케이션에서 해지된 토큰을 어떻게 처리해야 할까요?

토큰이 해지되는 것이 오류 상황이 아니라, 정상적인 상태라고 생각해야합니다. 애플리케이션은 이런 상태를 예상하고 감지해야 하며, UI는 토큰을 복원할 수 있도록 최적화되어야 합니다.

애플리케이션이 제대로 작동하도록 하려면 다음 작업을 수행하는 것이 좋습니다.

• API 호출과 토큰 새로 고침 근처에 해지된 토큰을 감지할 수 있는 오류 처리 코드를 추가합니다.
• 해지된 토큰을 감지하면 사용자가 애플리케이션을 다시 인증할 수 있을 때까지 Google API 액세스를 이용하는 모든 애플리케이션 기능을 비활성화합니다. 예를 들어, Google API와 데이터를 동기화하는 반복적인 백그라운드 작업이 영향을 받을 수 있으므로 이런 작업을 모두 일시 중단합니다.
• 사용자에게 액세스가 해지되었음을 알리고 해당 리소스에 대한 액세스를 다시 인증하도록 요청합니다.
• 앱이 사용자와 직접 상호 작용하는 경우 사용자에게 이메일을 보내거나 다음에 애플리케이션을 열 때 알림을 표시하는 등의 방법으로 다시 인증하도록 요청해야 합니다.
• 하지만, 앱이 사용자와 관계없이 독립적으로 실행되는 경우(이를테면 Gmail API를 사용하는 백그라운드 앱) 이메일이나 기타 메커니즘을 통해 사용자에게 알려야 합니다.
• 액세스를 다시 인증할 수 있는 간소화된 UI를 제공합니다. 사용자가 애플리케이션을 탐색하여 원래 설정을 찾도록 하지 마십시오.
• 해지된 토큰은 토큰이 해지된 방법에 상관없이 유사한 오류 메시지를 표시합니다. 따라서 비밀번호 변경으로 인해 토큰이 해지되었다고 가정하고서 메시지를 표시하면 안 됩니다.

애플리케이션이 증분 인증(Incremental authorization)을 사용하여 동일한 토큰에서 범위를 늘려나가는 경우 지정된 사용자가 활성화한 기능과 범위를 추적해야 합니다. 최종 결과로서, 앱이 여러 범위에 대해 인증을 요청하고 획득했으며 그 중 하나 이상이 메일 범위인 경우 해당 토큰이 해지됩니다. 이는 처음에 승인된 모든 범위에 대해 다시 인증하도록 사용자에게 요청해야 한다는 뜻입니다.

많은 애플리케이션이 백그라운드 또는 서버 간 API 호출을 수행할 목적으로 토큰을 사용합니다. 사용자는 당연히 이 백그라운드 작업이 안정적으로 계속될 것이라 여깁니다. 이번 정책 변경은 그러한 앱에도 영향을 미치므로 재인증을 요청하는 프롬프트 알림이 훨씬 더 중요해집니다.

자세한 내용과 전체 메일 범위 목록은 도움말 센터 문서 및 FAQ를 참조하시기 바랍니다. 앞으로 정책에 추가해야 할 추가 범위가 있다면 미리 알려드리겠습니다. 관련 세부 사항이 확정되면 바로 알려드리겠습니다.

게시자: Michael Winser(Google Apps 제품 책임자), Wesley Chun(Google Apps 디벨로퍼 어드보케)

▶ 원문 링크

Firebase 원격 구성에서 제가 가장 좋아하는 기능 중 하나는 다양한 사용자 그룹에 각각 다른 콘텐츠를 제공할 수 있는 기능입니다. 예를 들어, 개발자의 앱에서 많은 돈을 지출해온 사람들을 위해 홈페이지의 디자인을 바꾸어 보여줄 수 있습니다. 또는 조깅을 즐기는 사람에게는 그에 맞는 피트니스 앱의 한 부분을 강조하고, 웨이트 트레이닝을 하는 사람 역시 그에 맞는 피트니스 앱의 다른 부분을 강조할 수 있습니다.

원격 구성이 처음 출시된 이후 지금까지 줄곧, 개발자는 다양한 Firebase Analytics 잠재고객에 속한 사람들에게 각각 알맞은 콘텐츠를 제공함으로써 매우 정교한 사용자 타겟팅을 실현할 수 있었습니다.

하지만 최근에 들어, 원격 구성에서 사용자 속성이 각각 다른 사람들에게 그에 맞는 데이터 세트를 전송할 수 있게 되어, 이 기능의 유용성이 훨씬 더 커졌습니다.

아마 이렇게 말씀하실지도 모르겠군요. "잠깐만요. 저는 이미 잠재고객에 속한 사용자 타겟팅을 통해 단순한 사용자 속성이 아니라 더욱 정교한 타겟팅을 수행할 수 있어요. 그런데 이게 뭐가 더 좋다는 건가요?"라고 말이죠.

맞아요. 사실입니다. 잠재고객 기능은 많은 다양한 이벤트와 사용자 속성으로 정의할 수 있는 사용자로 구성된 그룹을 생성할 수 있도록 지원함으로써 개발자에게 매우 강력하고 구체적인 사용자 타겟팅을 제공합니다. 예를 들어, "내 게임에서 레벨 5를 깬 왼손잡이 캐나다인"이라는 잠재고객을 생성할 수 있습니다.1

하지만 잠재고객에는 원격 구성 내에서 사용하기 더 어렵게 만들 수 있는 두 가지 제한 사항이 있습니다.

첫째, 50명의 잠재고객으로 제한되고 이 잠재고객은 Firebase 내에서 Analytics 보고서를 실행하거나, Google 애드워즈를 통해 리마케팅 캠페인을 빌드하는 등의 다른 타겟팅에 이런 동일한 잠재고객을 사용할 수도 있는 사람들과 공유됩니다. 이로 인해 여러 개의 더 작은 임시 사용자 그룹을 생성하거나 조직의 다른 사람들이 사용 중일 수 있는 기존 잠재고객을 편집하기가 더 어려워집니다.

둘째, 잠재고객 기능이 현재 작동하는 방식으로는, 사용자가 일단 잠재고객에 들어가면 절대로 빠져나올 수 없습니다. 리마케팅 캠페인에 잠재고객을 이용하는 개발자의 일반적인 마케팅 담당자에게는 이것이 바로 정확히 기대하는 바겠지만, 원격 구성의 목적에 비춰볼 때는 이 점이 때때로 문제가 될 수 있습니다.

개발자가 출시한 게임을 시작했지만 아직 레벨 10을 끝내지 못한 사람들로 구성된 "Newbies"(초보자) 잠재고객을 생성하고 싶은 경우를 상상해 봅시다. 이 그룹에서 잠재고객을 생성하려고 하면, 게임을 시작한 모든 사람들이 이 잠재고객에 추가됩니다. 하지만, 그 중에서 레벨 15나 레벨 20에 도달한 사용자도 이 잠재고객 그룹에 계속 남게 됩니다. 근본적으로 처음 생성한 잠재고객 그룹이 "모든 플레이어"가 포함된 잠재고객 그룹이 되어버리는 것입니다.

그것이 바로 제가 원격 구성에서 사용자를 타겟팅할 때 제 콘텐츠를 맞춤설정하는 한 가지 방법으로서 사용자 속성을 사용하는 쪽을 선호하는 이유입니다. 사용자 속성을 사용하면 소규모 일회성 타겟팅 그룹을 많이 생성할 수 있으며, 이를 통해 기존의 잠재고객을 사용하는 경우보다 조금 더 동적으로 타겟팅 그룹을 생성할 수 있습니다.

구글플레이에서는 전 세계 다양한 개발자가 출시한 1백만 개 이상의 앱이 등록되어 있습니다. 매일 전 세계 사용자가 약 8000만장의 사진을 찍는데 사용하는 카메라 앱 레트리카, 누적 다운로드 수가 1억 건이 넘는 컬러 노트, 일본에서 큰 인기를 끌고 있는 실시간 계산기 등 다양한 앱을 만나보실 수 있습니다.

그런데 앞에서 말씀 드린 앱이 모두 한국 개발자가 만든 앱이라는 사실, 알고 계신가요? 소개 해 드린 3개 개발사를 비롯해 수많은 한국 개발사가 글로벌 플랫폼을 활용해 전 세계의 사용자에 도달하고 있습니다. 이에 구글플레이는 더 많은 한국 개발사가 앞서 말씀드린 개발사처럼 성장하는 것을 돕고자 구글플레이 내에 ‘대한민국 앱 개발사’ 콜렉션을 출시하게 되었습니다.

대한민국 앱 개발사 콜렉션은 한국 구글플레이 내에 별도로 노출하며 한국 개발사가 만든 앱을 약 10개 정도 3주에 한 번씩 선정해 선보일 예정입니다. 이를 통해 한국 개발사가 앱을 사용자들에게 더 효율적으로 소개하도록 돕고, 또 사용자는 다양한 분야의 한국 개발사 앱 중 자신이 원하는 앱을 간편하게 찾을 수 있습니다.

그리고 콜렉션 기간 중 좋은 성과를 보이고 글로벌 대응이 되어있는 개발사의 경우에는 해외 사용자를 대상으로 앱을 소개하는 기회도 제공할 예정입니다.

대한민국 앱 개발사 콜렉션에는 특정 조건을 만족하는 개발사라면 누구나 참가 신청을 할 수 있으며, 해당 앱의 카테고리 및 출시일 등 간단한 정보만 제출하시면 신청이 가능합니다.

참가신청을 위한 조건은 아래와 같으며 자세한 사항은 링크의 신청서를 참고해주시길 바랍니다.

신청 조건:

- 비게임 분야의 앱 개발사(게임 개발사의 경우 여기를 참고해주세요)
- 현재 구글플레이에 출시가 되어 있거나 6개월 이내에 출시할 계획인 앱
- 현재 출시가 되어 있는 경우 구글플레이 평점 4.0 이상

신청 양식: 

적합한 비즈니스 모델이 아주 초기 단계부터 핵심 앱 개발 전략에 적용된 경우 성공적인 앱은 결국 성공적인 수익 창출 비즈니스가 됩니다. Firebase는 고품질의 앱을 만드는 것부터 앱 트래픽을 늘리고 이로부터 수익을 창출하는 것에 이르기까지, 각 수명 주기 단계에서 앱 개발자에게 도움을 주기 위해 제작되었으므로 현재 고려 중일 수 있는 수익 창출 개념에 대해 살펴보도록 하겠습니다.

• 이상적인 앱 수익 창출 전략을 생각해 보세요.
  수익 창출은 인앱 구매, 구독, 광고 등의 많은 요소에서 비롯됩니다. 인앱 광고에 대해 생각해 볼 때, 이는 앱이 제공하는 가치와 무엇이 잠재고객에게 동기 부여를 하는지에 따라 앱에 적합할 수도, 그렇지 않을 수도 있습니다. 여러 가지 수익 창출 옵션을 실험해 보고 가장 효과적인 옵션을 결정하세요. 여러 옵션에 대해 A/B 테스트를 실시하고 클릭률을 평가하는 것을 생각해 볼 수 있습니다. 앱을 빌드할 때 조기에 현명한 결정을 내리는 데 도움이 되는 모든 수익 창출 옵션에 대한 자료를 읽어보세요.

• AdMob을 사용하여 수익을 늘릴 수 있는 방법을 알아보세요.
  AdMob은 Firebase에 포함된 핵심 요소로, 앱 개발자가 수익을 창출하는 데 도움이 될 수 있습니다. AdMob은 광고 수익 실적 및 사용자 참여에 대한 통계를 제공하는 동시에, 여러 광고 네트워크에 대한 액세스를 제공하여 사용자에게 보여줄 계획인 광고가 사용자에게 확실히 가치 있는 정보가 되도록 해줍니다.

▶ 원문 링크

클라이언트 웹사이트의 AMP 제작(AMPlify)을 지원하기 전 미리 알아두면 좋은 8가지 도움말을 알려드립니다. Accelerated Mobile Pages 지원 확대 계획 공지를 먼저 확인하세요.

시작은 간단합니다.

사이트에서 유명 콘텐츠 관리 시스템(CMS)을 사용한다면 AMP 페이지를 시작하고 구동하는 것은 플러그인 설치만큼 간단합니다. 맞춤 HTML를 사용하거나 처음부터 직접 제작한 사이트인 경우 추가 개발 리소스가 필요합니다.

모든 사이트가 적합한 것은 아닙니다.

AMP는 뉴스, 레시피, 영화 목록, 제품 페이지, 리뷰, 동영상, 블로그 등 모든 정적 웹 콘텐츠에 유용합니다. 그러나 경로 매핑, 이메일, 소셜 네트워크와 같은 동적 기능이나 상호작용 기능이 많은 단일 페이지 앱에는 효율적이지 않습니다.

사이트 전체를 #AMPlify하지 않아도 됩니다.

클라이언트의 기존 사이트에서 기사, 제품, 블로그 게시물 등 간단한 정적 콘텐츠 페이지부터 시작하여 단계적으로 AMP를 추가해 나갑니다. 사용자가 플랫폼 및 검색결과를 통해 액세스하는 이러한 페이지를 '리프' 페이지라고 하며, 이처럼 간단한 변경으로도 웹사이트에 AMP의 이점을 가져올 수 있습니다. 이 방법을 사용하면 AMP가 아닌, 고급 동적 기능을 필요로 하는 홈페이지 및 다른 '브라우저' 페이지를 그대로 유지할 수 있습니다.

콘텐츠가 많은 새 홈페이지를 처음부터 직접 만드는 경우 처음부터 AMP로 전체 사이트를 구축해 보세요. 먼저 시작 가이드라인을 확인하세요.

AMP는 오픈소스 프로젝트이며 계속해서 진화합니다.

사이트의 사용 사례에서 아직 AMP 형식을 지원하지 않는 경우 GitHub 기능 요청을 신청하거나 직접 구성요소를 설계할 수도 있습니다.

특정 위치에 표시되려면 AMP에 추가 조건이 필요할 수 있습니다

Google 검색결과에 표시되려면 AMP 페이지가 유효한 AMP HTML로 구성되면 됩니다. 그러나 일부 AMP 통합 제품에는 AMP 유효성 검사 외의 추가 조건이 필요할 수 있습니다. 예를 들어 Google 주요뉴스 섹션에 적합하게 하려면 AMP 페이지를 구조화된 데이터로 Article 마크업으로 마크업해야 합니다.

검색결과의 순위 변화는 없습니다.

페이지나 사이트에 자격 있는 유효한 AMP 페이지가 있는지의 여부는 검색결과 페이지의 사이트 순위와 관계가 없습니다. 차이점은 AMP 버전이 있는 웹 결과는 아이콘으로 라벨 표시된다는 것입니다.

Google의 AMP는 전 세계적으로 확장되고 있습니다.

Google의 AMP 검색결과는 올해 말 출시 이후 전 세계적으로 확장될 것입니다. 새로운 뉴스 AMP 콘텐츠를 표시하는 주요뉴스 캐러셀은 이미 여러 국가 및 언어로 사용할 수 있습니다.

언제나 도움을 받을 수 있습니다.

질문이 있는 경우 도움을 받을 수 있는 유용한 리소스가 다양합니다.

• 웹마스터 도움말 포럼: AMP 및 Google의 AMP 구현에 대한 질문
• Stack Overflow: AMP에 대한 기술적 질문
• GitHub: 기능 요청 제출 또는 기여

페이지의 AMP 버전 제작(#AMPlify)에 가장 도움이 되는 팁은 무엇인가요? 아래의 댓글이나 Google 웹마스터 Google+ 페이지에서 알려주세요. 질문이 있거나 도움이 필요하다면 웹마스터 도움말 포럼에 자유롭게 글을 올려주시기 바랍니다.

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

안녕하세요 Google Developer Group (GDG) 여러분,

벌써 2016년 한해를 마무리하는 시점이 다가오고 있습니다. 저희 GDG에 참여해 주신 모든 분들께 감사 인사 드립니다. 한해를 마무리하며 GDG에 참여해주셨던 분들의 특별한 경험을 많은 분들과 공유하기 위해 GDG Stories Asia 를 진행합니다!

지난 11월 5일 (토), GDG Korea 에서는 국내 개발자들이 한자리에 모여 서로 지식을 교환하고, 아이디어를 공유하고, 기술에 대한 열정을 표출할 수 있도록 GDG DevFest Seoul 2016 을 개최하였습니다!

사이트의 Accelerated Mobile Pages를 제작(#AMPlify)할 때 페이지의 유효성 검사 상태를 주기적으로 확인하는 것이 중요합니다. 유효한 AMP 페이지만 Google 검색에 표시되기 때문입니다.

AMP를 구현할 때 페이지에 오류가 포함되어 이로 인해 Google 검색에서 색인을 생성하지 못할 수 있습니다. 페이지에는 권장사항이 아닌 구성요소나 추후 오류가 될 수 있는 구성요소인 경고도 포함될 수 있습니다.

Google Search Console은 Google에서 어떤 AMP 페이지를 오류로 파악했는지를 확인할 수 있게 하는 무료 서비스입니다. 어떤 URL에 문제가 발생했는지 알게 되면 몇 가지 손쉬운 도구를 통해 쉽게 유효성 검사 오류 세부정보를 확인할 수 있습니다.

1. 브라우저 개발자 도구

개발자 도구를 사용하여 유효성을 검증하려면 다음 단계를 따르세요.

1. 브라우저에서 AMP 페이지를 엽니다.
2. URL에 '#development=1'을 추가합니다. 예: http://localhost:8000/released.amp.html#development=1
3. Chrome DevTools 콘솔을 열고 유효성 검사 오류를 확인합니다.

Developer Console 오류는 다음과 유사하게 표시됩니다.

2. AMP 브라우저 확장 프로그램