Google for Developers Korea Blog: 10월 2018

Android에서 Google 어시스턴트 미디어 작업 통합 검증하기

2018년 10월 29일 월요일

.post-body span { white-space: normal !important; } 원문은 이곳에서 확인하실 수 있으며 리뷰에는 이승민(Android GDE)님이 수고해주셨습니다.
게시자: Nevin Mital, 파트너 개발자 관계 담당자 MCT(Media Controller Test) 앱은 Android에서 미디어 재생과 관련된 복잡한 문제를 테스트할 수 있게 해주는 강력한 도구로, 이제는 훨씬 더 유용성이 강화되었습니다. Android 스마트폰, 자동차, TV, 헤드폰 등에서 Google 어시스턴트를 통한 음성 상호 작용을 비롯한 미디어 환경은 Android MediaSession API로 구동됩니다. 이 도구는 미디어 작업 통합을 검증하는 것에 도움이 됩니다. 우리는 QA 테스트 자동화 지원에 사용할 수 있는 새로운 검증 테스트 프레임워크를 추가했습니다. MCT는 Universal Android Music Player와 같은 미디어 API를 구현하는 앱과 함께 사용하도록 되어 있습니다. MCT는 PlaybackState 및 Metadata와 같은 미디어 앱의 MediaController에 대한 정보를 노출하는데, MCT를 사용하여 앱 간 미디어 컨트롤을 테스트할 수 있습니다. Media Action Lifecycle은 따라가기 복잡할 수 있습니다. 간단한 Play From Search 요청에도 중간 단계가 많아서(아래에 타임라인 형태로 간략히 묘사함) 뭔가 하나라도 잘못될 경우 문제가 될 가능성이 높습니다. MCT를 사용하여 음악 앱이 MediaController TransportControl 요청을 처리하는 방식에서 불일치 사항을 강조표시할 수 있습니다. 사용자, Google 어시스턴트 그리고 Play From Search 요청을 위한 타사 Android 앱 사이의 상호 작용 타임라인.

사용자, Google 어시스턴트 그리고 Play From Search 요청을 위한 타사 Android 앱 사이의 상호 작용 타임라인.

이전에는 MCT를 사용하려면 많은 수동 상호 작용과 모니터링이 필요했습니다. 새로운 검증 테스트 프레임워크는 미디어 앱이 재생 요청에 올바로 응답하는지 확인할 수 있는 원클릭 테스트 기능을 제공합니다.

검증 테스트 실행MCT에서 새로운 검증 테스트에 액세스하려면 원하는 미디어 앱 옆에 있는 Test 버튼을 클릭하세요. 시작 화면의 MCT 스크린샷. 각각에 대해 Control 뷰나 Test 뷰로 이동하기 위한 옵션과 함께 설치된 미디어 앱 목록이 포함되어 있습니다.

시작 화면의 MCT 스크린샷. 각각에 대해 Control 뷰나 Test 뷰로 이동하기 위한 옵션과 함께 설치된 미디어 앱 목록이 포함되어 있습니다.

다음 화면에는 MediaController에 대한 세부 정보(예: PlaybackState, Metadata, Queue)가 표시됩니다. 오른쪽 위의 툴바에는 버튼이 두 개 있는데, 왼쪽 버튼은 파싱 가능한 로그와 서식 지정된 로그 사이를 전환하는 토글 버튼이고 오른쪽 버튼은 가장 최신 정보를 표시하도록 이 뷰를 새로 고칠 수 있는 버튼입니다. UAMP용 Testing 뷰에서 왼쪽 화면의 MCT 스크린샷에는 Media Controller의 Playback State, Metadata, Repeat Mode, Shuffle Mode, Queue에 대한 정보가 포함되어 있습니다.

UAMP용 Testing 뷰에서 왼쪽 화면의 MCT 스크린샷에는 Media Controller의 Playback State, Metadata, Repeat Mode, Shuffle Mode, Queue에 대한 정보가 포함되어 있습니다.

왼쪽으로 스와이프하면 검증 테스트 뷰가 나오는데, 이 뷰에는 정의된 테스트를 스크롤하며 볼 수 있는 목록, 쿼리가 필수적인 테스트에 대한 쿼리를 입력하는 텍스트 필드, 테스트 결과를 표시하는 섹션이 표시됩니다. UAMP용 Testing 뷰에서 오른쪽 화면의 MCT 스크린샷에는 테스트 목록, 쿼리 텍스트 필드, 결과 표시 섹션이 포함되어 있습니다.

UAMP용 Testing 뷰에서 오른쪽 화면의 MCT 스크린샷에는 테스트 목록, 쿼리 텍스트 필드, 결과 표시 섹션이 포함되어 있습니다.

한 예로, Play From Search Test를 실행하려면 텍스트 필드에 검색어를 입력한 다음 Run Test 버튼을 누르면 됩니다. 테스트에 성공한 것으로 보이는군요! UAMP용 Testing 뷰에서 오른쪽 화면의 MCT 스크린샷. 'Memories' 쿼리로 Play From Search 테스트를 실행하여 성공적으로 끝났습니다.

UAMP용 Testing 뷰에서 오른쪽 화면의 MCT 스크린샷. 'Memories' 쿼리로 Play From Search 테스트를 실행하여 성공적으로 끝났습니다.

아래는 Pause Test(왼쪽)와 Seek To Test(오른쪽)의 예입니다. UAMP용 Testing 뷰에서 오른쪽 화면의 MCT 스크린샷. Pause 테스트를 성공적으로 실행했습니다.

UAMP용 Testing 뷰에서 오른쪽 화면의 MCT 스크린샷. Seek To 테스트를 성공적으로 실행했습니다.

Android TVMCT는 현재 Android TV에서도 작동합니다. 미디어 앱이 MCT의 Android TV 버전과 작동하려면 미디어 앱에 MediaBrowserService가 구현되어 있어야 합니다. 그 자세한 방법은 여기를 확인해 보세요. Android TV에서 MCT를 실행하면 설치된 미디어 앱의 목록이 나타납니다. 이 목록에는 MediaBrowserService를 구현하는 앱만 표시됩니다. 시작 화면의 Android TV MCT 스크린샷. 설치된 미디어 앱 중 MediaBrowserService를 구현하는 앱의 목록이 포함되어 있습니다.

시작 화면의 Android TV MCT 스크린샷. 설치된 미디어 앱 중 MediaBrowserService를 구현하는 앱의 목록이 포함되어 있습니다.

앱을 선택하면 테스트 화면으로 이동하며, 이 화면의 오른쪽에 검증 테스트 목록이 표시됩니다. 테스트 화면의 Android TV MCT 스크린샷. 오른쪽에 테스트 목록이 포함되어 있습니다.

테스트를 실행하면 화면 왼쪽이 선택한 MediaController 정보로 채워집니다. 자세한 내용은 Logcat에서 MCT 로그를 확인해 보세요. 테스트 화면의 Android TV MCT 스크린샷. Pause 테스트가 성공적으로 실행되었으며 화면 왼쪽에 선택한 MediaController 정보가 표시됩니다.

테스트 화면의 Android TV MCT 스크린샷. Pause 테스트가 성공적으로 실행되었으며 화면 왼쪽에 선택한 MediaController 정보가 표시됩니다.

쿼리가 필요한 테스트는 키보드 아이콘과 함께 표시됩니다. 이러한 테스트 중 하나를 클릭하면 쿼리를 입력하는 입력란이 열립니다. Enter 키를 누르면 테스트가 실행됩니다. 테스트 화면의 Android TV MCT 스크린샷. Seek To 테스트를 클릭하여 쿼리 입력란을 연 모습입니다.

텍스트를 더 쉽게 입력하기 위해 다음과 같이 ADB 명령어를 사용할 수도 있습니다. adb shell input text [query] '%s'는 단어 사이에 공백을 추가하는 역할을 합니다. 예를 들어 adb shell input text hello%sworld 명령어를 실행하면 입력란에 'hello world'라는 텍스트가 추가됩니다. 다음 단계 MCT에는 현재 다음과 같은 요청에 대한 간단한 단일 미디어 작업 테스트가 포함되어 있습니다.

Play

Play From Search

Play From Media ID

Play From URI

Pause

Stop

Skip To Next

Skip To Previous

Skip To Queue Item

Seek To

테스트의 구조와 더 많은 테스트를 추가하는 방법에 관한 자세한 기술적 사항은 MCT GitHub 위키를 참조하세요. 있으면 유용할 것이라 생각하는 테스트와 버그 수정에 대한 풀 리퀘스트를 제출해주시면 고맙겠습니다. 자세한 내용은 기여 절차를 살펴보시기 바랍니다. GitHub에 관한 최신 업데이트를 확인해 보세요.

AMP로 수익을 내고 계시나요?

2018년 10월 26일 금요일

.post-body span { white-space: normal !important; } 블로그 원문은 이 곳에서 확인하실 수 있고 번역 리뷰는 조은(Webtech GDE)님이 도와주셨습니다
편집자 주: 이 글은 Google의 AMP 제품 관리자 Vamsee Jasti이 Medium에 게시했던 글입니다.
저는 AMP에서 프로덕트 매니저로 근무 중이며 저희 팀은 웹 광고를 개선하는 동시에 게시자의 성장과 발전을 돕는 데 주력하고 있습니다. 이 글에서는 저희가 AMP에서 광고하기 위한 디자인 선택 사항에 관한 배경을 설명하고 AMP 페이지를 최대한 활용하는 데 도움을 드리고자 매주 구체적인 최적화 권장 사항을 제시하고 있습니다.

AMP 페이지를 최적화하여 AMP 투자의 수익을 극대화하시기 바랍니다.
구체적인 최적화 조언을 얻으려면 여기 링크를 클릭하십시오. (영문 블로그로 이동합니다)

AMP 및 비 AMP 페이지에서 광고 밀도가 동일하게 하기

높은 광고 조회수 및 가시성을 위해 AMP 페이지 최적화

AMP에서 멀티사이즈 & fluid ads로 광고 경쟁률 높이기

헤더 입찰, 보다 잘하기 -> AMP RTC

AMP로 비디오 광고 활용하기

결론부터 말하자면 AMP 페이지를 게시하고 있다면 최소한 AMP 페이지가 수익을 잘 내고 있는지 꼭 확인해 보세요. 투자하고 있다면 수익을 확인할 수 있어야 합니다.
우리가 AMP를 출시하면서 중요하게 여겼던 점은 비 AMP 페이지에서 그랬던 것과 꼭 마찬가지로, 게시자가 AMP 페이지에서 수익을 창출하도록 돕는 것이었습니다. 광고는 여전히 많은 게시자에게 큰 수익원이기 때문입니다. 필자는 게시자들과 수많은 인터뷰를 가진 후 일부 게시자가 AMP 페이지의 장점을 충분히 활용하지 못해 수익을 많이 내지 못하고 있다는 사실을 알았습니다. 문제 우리는 많은 게시자와 함께 일하면서 AMP를 통한 수익 창출과 관련된 피드백을 받았고 AMP에서 지원이 필요한 광고 기능이 다수 있다는 얘기를 듣곤 했지만, 작년에 여러 가지 기능을 출시한 후 피드백이 많이 줄었습니다. 해야 할 일은 항상 늘고 있지만, AMP 출시 이후 우리는 여러 가지 기능을 출시했고 이제는 거의 모든 격차를 해소했습니다. 손익 분기점에 도달했을 뿐 아니라 비 AMP 페이지에 비해 AMP 페이지에서 초과 수익을 올린 게시자도 있습니다. 50% 가까운 트래픽을 AMP 페이지로 받는 게시자의 경우 매년 1백만 달러 이상의 수익에 해당할 수 있는 수치입니다. 해결 방법 단순한 트래픽(일회적 미끼용 링크를 클릭한 횟수나 플랫폼에서의 트래픽 구매를 기준으로 하는 방문자)이 아니라 잠재고객(해당 사이트를 종종 방문해서 여기저기 둘러보는 방문자)을 찾아내는 업무에 종사하는 게시자라면 아마 이미 의식적으로 적당한 절충점을 찾아 균형을 맞추고 계실지 모르겠습니다. 사이트의 사용자 환경과 광고로부터 창출하는 수익 사이의 절충점 말이지요. 극단적인 예를 들자면, 많은 수익을 창출하는 상품을 보여주는 페이지로 넘어가기 전에 팝업 광고를 3개 연속으로 띄우는 일이야 쉽사리 할 수 있겠지만, 사용자가 광고에 질려 금새 사이트에서 나가버리거나 다음에 이 사이트를 방문하기 망설이게 되어 게시자의 브랜드에 부정적 영향을 미치기도 합니다. AMP의 광고 이면에 숨겨진 원리 AMP를 사용할 경우 이러한 절충점에 관한 한, 우리는 다른 무엇보다도 사용자 환경을 우선시하는 입장을 가졌지만 과거의 기술적 한계와 같은 이유로 비 AMP 페이지에서는 구현하기 어려운 기능을 사용하여 여전히 광고가 매우 좋은 수익을 창출할 방법을 다시 숙고해보았습니다. 그중 몇 가지 방법을 소개하겠습니다.
1. 광고를 페이지 렌더링의 중요 경로 밖으로 빼내기 일반 페이지와는 달리, AMP 페이지는 광고 수명 주기에서 가능한 한 일찍 페이지에서 광고 요청을 합니다. 따라서 페이지 렌더링을 병렬 처리하는 동시에 광고 서버가 동작하여 최적의 광고를 고르도록 할 수 있습니다. 아마 광고가 다시 나타날 때쯤이면 페이지에서 이미 로딩을 마쳤을 것이므로 광고 역시 즉시 렌더링할 수 있어 광고의 가시성 향상과 클릭률 증가로 이어질 것입니다. 우리는 AMP가 이러한 측정 기준에서 정말 훌륭한 성과를 낸다는 점을 보여주는 데이터를 수집해왔습니다. 광고 요청 시퀀스를 간단히 조정하는 것만으로도 게시자와 광고자 모두에게 득이 됩니다. 우리는 이를 'Fast Fetch'(빠르게 가져오기)라고 부르는데, 여기에서 개선 사항에 관한 모든 내용을 확인하실 수 있습니다. 이러한 변화 이후로 사용자에게 빈 사각형이 표시되는 문제가 현저히 줄어드는 대단한 성과를 거두었습니다.

Fast Fetch와 Delayed Fetch 광고 요청
이는 브라우저에서 광고 태그가 나와야 광고 요청이 이루어지므로 광고 요청을 지연한 후에 렌더링하는 Delayed Fetch(지연된 가져오기)와는 반대입니다.

2. 사용자의 눈에 띄는 리플로우를 허용하지 않고 여러 가지 크기의 광고 지원
어떤 사이트를 방문해 콘텐츠를 읽기 시작했는데 어디선지 모르게 광고가 나타나 콘텐츠 위에 떡하니 자리를 차지하는 바람에 콘텐츠를 계속 읽기 위해 마우스를 클릭해 광고를 없애거나 숨겨야 하는 경우가 얼마나 자주 있으신가요? 이런 상황은 사용자 환경의 관점에서 분명히 나쁜 일이며, 그래서 AMP에서는 그런 일이 생기지 않도록 절충점을 찾았습니다. AMP가 광고를 위한 공간을 미리 확보하되 콘텐츠를 리플로우하는 일 없이 계속 콘텐츠 전체를 렌더링할 수 있도록 광고마다 미리 결정된 기본 크기가 있어야 합니다.

AMP는 기본 광고 크기를 예약하므로 사용자의 눈에 띄는 리플로우가 전혀 없습니다.
하지만 우리는 여러 가지 크기의 광고가 광고 경매 수요층을 더 크게 만들어주므로 더 나은 수익성으로 이어진다는 점을 잘 알고 있습니다. AMP는 게시자가 기본 크기를 정의하고 보조 크기도 선택할 방법을 마련함으로써 광고가 표시 영역 아래에 있거나 현재 표시 영역에 있다면 기본 크기보다 작은 한, 광고를 반환되는 크기로 조정할 수 있도록 허용했습니다. 게시자 피드백을 보면 이 방법은 90% 이상의 게시자에게 최대의 수익을 안겨주는 광고 크기로 광고를 삽입할 기회를 주었다는 점에서 좋은 절충점이었던 것으로 나타났습니다. 다음에 게시할 글에서 더 자세한 내용을 설명하겠지만 출시 관련 블로그 게시물을 읽어보세요.

3. 사용자가 쉽게 닫거나 스크롤해 지나갈 수 있는 형식의 광고 우선 선택 인정할 건 인정합시다. 사이트를 방문하는 대다수 사용자는 광고가 아니라 콘텐츠를 보러 오는 겁니다. 그래서 AMP에서는 콘텐츠를 '가리는' 광고는 절대 표시하지 않는다는 디자인 원칙을 택했습니다. 즉, 콘텐츠를 가리는 팝업(중간 광고)이 없다는 뜻입니다. 흥미로운 점은, 업계 전체가 이러한 광고 형식을 거부하고 있다는 사실입니다. 그 대신, 우리는 모든 리치 미디어 광고를 비롯하여 고정된 레이아웃 내에서 모든 광고를 지원했습니다.

AMP에서 선호하는 광고는 사용자가 쉽게 닫을 수 있는 광고
또한 AMP는 스티키 광고와 마법의 양탄자 광고 같은 몇 가지 기본 광고 형식도 선보였습니다. 게시자가 우리에게 관심사를 알려주는 훨씬 더 풍부한 형식을 지원하는 동시에 훌륭한 사용자 환경을 보장할 계획입니다. 어떤 광고 형식을 사용하든, 사용자가 광고에 있는 전용 닫기 버튼을 탭하거나 그냥 스크롤해서 벗어날 수 있어야 합니다. 자, 그렇다면 수익은? 혹시 오해하실지 몰라 드리는 말씀이지만, 그냥 손바닥 뒤집듯 쉬운 일이란 없습니다. 끊임없이 최적화하고 새로운 것을 시도하고 훌륭한 UX 원칙을 고수하면서도 최대의 수익을 안겨주는 광고 설정으로 실험하고 안정화하느라 갖은 노력을 기울입니다. 좋은 소식을 전해드리죠. AMP에서는 그러한 최적화 작업이 꽤나 간단하다는 점입니다. 게다가 몇 가지 작업만 하면 AMP 페이지를 통해 최대의 수익을 창출할 수 있습니다. 앞으로 몇 주 정도에 걸쳐 다음 각각의 주제에 관해 자세히 설명하겠습니다.

AMP 및 비 AMP 페이지에서 광고 밀도가 동일하게 하기

높은 광고 조회수 및 가시성을 위해 AMP 페이지 최적화

AMP에서 멀티사이즈 & fluid ads로 광고 경쟁률 높이기

헤더 입찰, 보다 잘하기 -> AMP RTC

AMP로 비디오 광고 활용하기

AMP 페이지에서 직접 광고 판매하기

“자동 광고 새로고침”을 사용하여 광고를 새로고침하기

AMPHTML 광고와 함께 열어가는 미래

변화를 꾀하고 AMP에서 수익을 창출하세요
우리는 AMP로 광고를 소싱할 위치와 함께 일할 공급업체를 결정하는 데 있어 융통성을 제공한다고 믿습니다. 단지 AMP를 사용하기 위해 공유 수익의 일부라도 놓치는 일이 없습니다. 기본적으로 AMP 페이지와 통합된 광고 네트워크가 100개를 넘고 헤더 비딩(AMP RTC 사용)과 서버 측 교환을 통해 더 많은 네트워크가 지원됩니다.
AMP 팀은 오픈 웹에 대해 뚜렷한 신념을 가지고 있고 페이월이든 광고든 상관없이 게시자가 이를 바탕으로 지속 가능한 비즈니스를 구축하는 데 최선을 다해 도움을 드리고 있습니다. 앞으로 몇 주간 더 자세한 내용을 소개할 예정이니 계속 지켜봐 주세요. 이번 시리즈나 AMP에 대한 다른 어떤 사항에 관해서도 활발한 피드백을 기다리고 있겠습니다. 한시라도 빨리 실행해보고 싶은 분은 수익 창출 모범 사례 요약을 확인해 보시고 바로 실행으로 옮기세요!

Playtime 2018: 앱을 더 작은 번들로 쪼개 더 많은 사용자를 만나보세요.

2018년 10월 25일 목요일

.post-body span { white-space: normal !important; }

블로그 원문은 이곳에서 확인하실 수 있고 리뷰는 양찬석(Google) 님이 도와주셨습니다.
게시자: Matt Henderson, Google Play 제품 관리자
지난 10월 18일 매년 세계 각지에서 열리는 Playtime 이벤트가 샌프란시스코와 베를린을 시작으로 개막되었습니다. 이 후, 상파울루, 싱가포르, 타이페이, 서울(주> 서울에서는 12월 초에 개최될 예정입니다), 도쿄에서도 잇따라 이벤트가 열릴 예정입니다. Playtime은 전 세계 전문가들이 Google Play에 대한 깊은 통찰과 최신 업데이트 정보를 공유하는 행사입니다.
Google Play는 개발자가 더 쉽게 앱을 개발하고 전 세계 잠재고객에게 더 쉽게 앱을 배포할 수 있도록 지속적으로 투자하고 있습니다. 이번 포스트에서는 올해 Playtime 이벤트에서 발표된 몇 가지 흥미로운 업데이트 사항을 소개합니다.
앱을 더 작게 만들기 안드로이드 앱 번들은 안드로이드 앱을 배포할 때 사용할 수 있는 새로운 포맷입니다. 이를 이용해 앱 크기는 줄이면서도 훌륭한 사용자 경험을 제공할 수 있습니다. 더 나아가, 안드로이드 앱 번들의 모듈화 기능을 사용해 설치 시점이 아니라 사용자가 요청할 때 필요한 기능을 다운로드 받도록 만들 수 있습니다. 이렇게 하면 앱의 크기를 더 줄일 수 있습니다. 크기가 작은 앱의 전환율이 더 높으며, 사용자 조사에 따르면 앱을 삭제하는 주요한 원인 중 하나가 앱 크기로 나타났습니다.
이미 수천 개의 앱이 앱 번들 형태로 배포되고 있습니다. 평균적으로 기존 APK 대비 앱 번들의 크기 감소율은 35%입니다. 이번 Playtime에서는 앱 번들의 이점을 더욱 향상시키는 몇 가지 업데이트가 소개되었습니다.

더 많은 크기 절감 효과: 개발자의 추가 작업 없이도 이제 앱 번들의 다운로드 크기는 평균 8%, M+ 기기에서 16% 더 작아질 것입니다. 새로운 절감 효과는 비압축  네이티브 라이브러리를 지원하는 데 따른 것으로, 기기에 여러 개의 복사본을 저장할 필요가 없기 때문입니다.

더 쉽게 전환: 이제는 Android Studio 3.2 스테이블 버전 및 Unity 2018.3 베타에서 앱 번들을 빌드할 수 있습니다.

용량이 큰 앱에 대한 지원 개선: 설치되는 APK 크기가 500MB 이하인 앱은, 확장 파일을 사용할 필요 없이 앱 번들로 바로 Google Play에 업로드할 수 있습니다. 이 기능은 사전 체험판 형식으로 제공되고 있으며 향후 모든 개발자에게 공개될 예정입니다.

안드로이드 앱 번들, 동적 기능 모듈, 그 외 작은 모듈 형태로 앱을 구성하여 얻게 되는 모든 이점에 대해 자세히 알아보려면 다음 미디엄 게시물을 참고하시기 바랍니다.
인스턴트 앱과 앱 번들의 통합 지금까지 인스턴트 앱을 더 쉽게 만들 수 있도록 해달라는 개발자 피드백을 많이 들어왔습니다. 이를 위해, Play Store에서 ‘사용해 보기' 기능 지원을 위해 필요한 크기 제한을 10MB로 늘리고 URL 요구 사항을 삭제했습니다. 또한 게임 개발자를 위해 Unity와 제휴을 맺고 Google Play Instant 플러그인을 만들고, 또한 Cocos Creator에서 바로 인스턴트 앱을 만드는 기능을 소개했습니다.
다음으로, 안드로이드 앱 번들을 사용해 인스턴트 앱을 만들 때 생기는 가장 큰 어려움 중 하나를 해결하고자 합니다. 지금까지 개발자는 인스턴트 앱과 기존 설치 용 앱을 둘 다 배포했어야 합니다. Android Studio 3.2를 사용하면 인스턴트 앱으로 사용될 수 있는 번들을 만들 수는 있었지만, 여전히 별도로 기본 앱 번들을 만들고 이를 업로드해야했습니다.
하지만 이제는 두 벌의 코드를 유지할 필요가 없습니다. Android Studio 3.3 베타 릴리스를 사용하면 하나의 앱 번들만 만들어 이를 Google Play에 올리고, 해당 번들이 인스턴트 앱으로도 사용될 수 있다고 설정하거나, 해당 번들에 포함된 모듈 중 일부가인스턴트 앱으로 사용되도록 설정할 수 있습니다. ‘통합 앱 번들’은 인스턴트 앱 환경의 미래이므로, 여러분 모두 꼭 한번 사용해보셨으면 합니다. 인스턴트 앱을 사전 체험판으로 제공 Google Play Instant는 현재 유료 게임 및 사전 등록 캠페인용으로 제공될 수 있습니다. 다시 말해, 사용자가 정식 출시 전에 게임을 플레이할 수 있고, 이를 통해 추가적인 홍보 효과를 누릴 수 있습니다. 새로운 앱과 게임이 매일같이 Google Play Instant의 세계에 합류하고 있습니다. 그중에서도 특히 Devolver Digital의 Umiro와 Scopely의 Looney Tunes 메이헴 월드은 최초로 이러한 기능을 활용하는 파트너 중 하나입니다.

장애 비율 감소와 품질 개선 Play Console은 성능 모니터링과 앱 품질 개선에 도움이 되는 두 가지 도구를 제공합니다. 사전 출시 보고서는 Firebase Test Lab에 준비된 실제 기기에서 앱을 테스트하고 프로덕션 단계로 진행하기 전에 문제점을 파악하고 수정하는데 유용한 메타데이터를 생성합니다. Android Vitals는 실제 사용 환경의 사용자 기기에서 앱의 성능과 품질을 추적하는 데 도움이 됩니다.
Google Play는 이 두가지를 묶어 더 실질적인 인사이트를 제공하는데 노력을 기울이고 있습니다. 만일 Android Vitals에서 발견된 앱 비정상 종료 오류가 사전 출시 보고 기능을 실행할 때도 발견되면 이를 확인할 수 있습니다. 데이터는 양쪽 방향으로 모두 연결되며, 실제 사용 환경에서 이미 일어나고 있는 비정상 종료가 사전 출시 보고에서 발생하는 경우 Android Vitals에서 현재 해당 이슈가 미치는 영향을 확인할 수 있으며, 이를 통해 사전 출시 보고서에 포함된 문제점의 우선 순위를 더 나은 방식으로 정할 수 있습니다.

앱과 비즈니스의 최적화 Play를 통해 개발자가 앱과 비즈니스를 더 쉽게 관리할 수 있도록 여러 가지 업데이트가 있었습니다.

구독자 유지를 위한 도구: 2018년 I/O에서 구독 취소에 관한 설문조사를 소개한 바 있습니다. 개발자는 이 설문조사 결과를 통해 애써 모은 구독자가 구독을 취소하는 이유를 보다 잘 이해할 수 있습니다. 추가로, 사용자가 완전히 구독을 취소하는 대신 구독을 일시 중지할 수 있는 기능을 테스트 중이며, 이를 통해 개발자가 구독을 취소하려는 구독자의 마음을 돌리기 위한 프로모션을 제시할 수 있는 기능을 제공할 예정입니다.

더욱 융통성 있는 구독 가격 책정: Play Billing Library 버전 1.2부터, 새로운 SKU를 만들 필요 없이 기존 구독 서비스의 가격을 변경할 수 있습니다. 또한 요금제 변경을 제안하고 기존 갱신 날짜에 변경된 요금제를 발효할 수도 있습니다.

더 강력한 측정항목: 개발자의 핵심 측정항목 평가에 도움이 되도록 Play Console에 새로운 도구를 추가했습니다. 누적 데이터, 이전 30일 평균 통계(30-day rolling average), 비즈니스의 흐름에 더욱 정확히 맞추기 위한 다른 시간 주기 기반의 롤업(roll-ups for different time periods)과 같은 도구가 추가되었습니다. 원하는 형태로 구성된 보고서를 CSV 파일로 다운로드할 수도 있습니다.

더욱 쉬워진 앱 업데이트: 이제 In-App Updates라는 새로운 API를 사용하여, 사용자가 앱을 떠나지  않고도 업데이트 프롬프트를 통해 앱을 업데이트하도록 할 수 있습니다. 개발자는 전체 화면을 사용해 사용자가 앱을  다운로드하고 다시 시작하는 단계를 안내하거나, 적절히 각 상태를 관리하며 사용자가  백그라운드에서 업데이트된 버전을 다운로드하고 설치하도록 도와줄 수 있습니다. 이 프로그램은 현재 사전 체험판으로 제공되며 향후 몇 개월 이내에 정식 공개 될 예정입니다.

Play에 대해 배우는 새로운 방법 성공적인 앱을 위한 아카데미 과정을 출시하게 된 것도 마음 설레는 일입니다. 이 프로그램은 개발자가 Play Console을 최대한 활용하고, Play 정책을 이해하고, 모범 사례에 따라 품질 개선과 비즈니스 실적 향상을 이루는 데 도움이 되는 새로운 대화식 교육 과정을 담고있습니다. 무료로 제공되는 이 새로운 프로그램에서는 퀴즈와 성취도 평가를 통해 학습 진도를 추적하면서 자신의 전문성을 스스로 확인해보실 수 있습니다. 현재 영어 버전으로 제공되고 있지만, 곧 새로운 콘텐츠와 번역된 버전의 교육 과정을 추가할 예정입니다.
개발자 여러분이 만드는 다양한 앱과 세상 사람들에게 미치는 영향력에 늘 새로운 영감을 얻습니다. 멋지고 놀라운 앱과 게임을 만든 개발자를 기념하는 #IMakeApps 컬렉션을 확인해 보시고 여러분의 #IMakeApps 스토리를 공유해 주세요.
이 블로그 게시물이 얼마나 유용했는지 알려주세요. ★ ★ ★ ★ ★

AMP 프로젝트가 열린 거버넌스 모델을 도입합니다

2018년 10월 16일 화요일

.post-body span { white-space: normal !important; } 단 2명의 컨트리뷰터로 미약하게 시작했던 AMP 프로젝트가 2년만에 700명의 컨트리뷰터를 보유하고 1만개의 커밋을 하고 수천만 웹사이트에 영향을 주는 오픈소스 프로젝트가 되었습니다. 초기에는 AMP 거버넌스 모델, 즉 의사결정이 어떻게 이루어지는지에 대한 체계를 세울때 속도에 초점을 맞추었습니다. AMP는 처음부터 개발자와 사용자의 목소리와 피드백을 기반으로 움직이긴 했지만, 거버넌스만큼은 테크리드인 제가(이 글의 필자) 중심적인 역할을 했습니다. 무엇을 어떻게 집행해야 할지를 최종적으로는 제가 결정했다는 얘기입니다.
프로젝트가 작을 때는 이런 방식이 잘 동작했지만 지금같은 거대한 AMP 프로젝트에는 더이상 맞지 않다는 것을 깨달았습니다. 그래서 모든 구성원의 목소리가 반영될 수 있는 모델을 만들고 싶었습니다. 직접 코드를 작성하지 않는 최종 사용자까지 포함해서요. 지난 몇 달 동안 이와 관련된 조사를 했고 Node.js 프로젝트의 선례를 따르기로 했습니다. 합의를 기반으로 하는 거버넌스 모델입니다.

AMP의 컨트리뷰터는 총 710명인데 그 중 22%는 구글 직원이고 78%는 트위터, 핀터레스트, 야후, 이베이 등을 포함한 다른 회사 사람들입니다. 30일만에 무려 350건의 개선사항이 AMP에 적용되었습니다!
AMP팀은 다음의 몇 가지 목표를 염두에 두고 새로운 거버넌스 모델을 제안했습니다.

코드 작성에서 AMP의 방향 설정 그리고 구현할 기능 및 수정할 버그의 결정 등 모든 영역에서 다양한 목소리가 나오도록 장려할 것. 이는 AMP 코드에 기여하지 않지만 AMP의 변화에 영향을 받는 사람들의 목소리도 포함합니다. 

코드 변경 승인부터 AMP의 기술 및 제품 로드맵 수립에 이르기까지 어떤 개인이나 회사가 어떻게 영향을 미치는지 좀 더 투명하게 보여줄 것.

거버넌스 모델 때문에 AMP의 일반적인 개발 작업이 느려지지 않을 것. 이번 변경으로 인해 개발자들의 생산성이 동일한 수준이거나 향상되도록 할 것.

다른 오픈 소스 프로젝트의 성공과 실패에서 배울 것. 이를 위해 AMP팀은 Node.js와 Kubernetes팀과 이야기를 나눴고 JS Foundation 등의 거버넌스 철학을 살펴봤으며 여러 오픈 소스 및 웹 표준의 거버넌스 문서를 검토했습니다.

제안서에 상세한 내용을 실었지만 새로운 모델에서 강조하는 중요한 내용을 몇 가지 소개합니다.

한 명의 테크리드가 아니라 AMP를 개발하는데 자원을 투입한 회사의 대표들로 기술운영위원회(Technical Steering Committee)를 구성하고 AMP 프로젝트의 중요한 사항을 여기서 결정하게 됩니다. 최종적으로는 한 회사가 기술운영위원회에서 3분의 1이상의 의석을 점유하지 않을 것입니다.

자문위원회(Advisory Committee)는 AMP 유권자들의 대표로 구성하고 기술운영위원회에 조언을 합니다.

현재 UI, 인프라스트럭처, 문서화 등 AMP의 특정 영역을 관장하는 비공식 팀은 워킹그룹으로 대체됩니다. 워킹그룹은 의견을 수렴하여 결정하는 과정을 명확하게 수립할 것입니다. 

새로운 체계를 갖추기 위한 첫 번째 작업으로 AMP 거버넌스 그룹의 초기 멤버쉽을 확정하려고 합니다. 거버넌스 그룹에 참여하기 원하시면 저희에게 알려주십시오. 만만한 작업이 아니기 때문에 여러분이 이 작업으로 따로 월급을 받고 있지 않다면 저희가 비용을 지불할 계획입니다. 혹시 재정 지원이 필요하시면 위에 링크된 양식에 기입해주십시오. 저희가 특히 관심있는 분들은 소비자 권익과 보호 분야의 경험자입니다. 그동안 자문위원회를 구성하기 위해 여러 그룹 및 전문가들과 논의를 진행했습니다. 감사하게도 엘파이스(El País), 워싱턴포스트(Washington Post), 테라(Terra) 등의 퍼블리셔, 알리익스프레스(AliExpress), 이베이(eBay) 등의 이커머스 사이트, 클라우드플레어(Cloudflare), 오토매틱(Automattic) 등의 플랫폼 업체, 그리고 더 파시엘로 그룹(The Paciello Group)의 리오니 왓슨(Léonie Watson), 구글/크롬의 니콜 설리번(Nicole Sullivan), 테렌스 이든(Terence Eden) 등 오픈웹 지지자를 포함한 다양한 분들이 자문위원회에 참여하기로 했습니다.
추가적으로 말씀드리면 저희는 AMP 재단 설립을 검토하고 있습니다. 이에 관하여 앞으로 몇 달동안 기술운영위원회, 자문위원회, 그리고 AMP 커뮤니티 구성원들의 의견을 받겠습니다. 거버넌스 모델을 수정하는 것은 그런 목표를 이루기 위한 첫 번째 과정이라고 보시면 됩니다.
AMP 컨트리뷰터 서밋을[1] 포함하여 앞으로 AMP 커뮤니티의 다른 분들과도 논의를 계속해서 새 거버넌스 모델을 다듬을 계획입니다. 거버넌스 제안서를 검토해 보시기 바랍니다. 디자인 리뷰도[2] 진행할 계획인데 참석하셔서 의견을 개진해주시기를 바랍니다. 2018년 10월 25일, 제안서 검토 기간이 종료하는대로 새로운 거버넌스 모델이 바로 효력을 발휘할 것입니다.
저희는 AMP 커뮤니티가 한 단계 성숙한다는 생각에 조금 들떠 있습니다. 사용자와 개발자를 모두 만족시키는 더 좋은 웹을 만드는 데 여러분도 동참하시기를 바랍니다.
말테 우블, 구글 AMP 프로젝트 테크 리드
참고 [1][2] AMP 컨트리뷰터 서밋은 2018년 9월 25일, 거버넌스 디자인 리뷰 2018년 10월 10일에 개최했습니다.

Android에서 Google 어시스턴트 미디어 작업 통합 검증하기

AMP로 수익을 내고 계시나요?

Playtime 2018: 앱을 더 작은 번들로 쪼개 더 많은 사용자를 만나보세요.

AMP 프로젝트가 열린 거버넌스 모델을 도입합니다

Contents

검색

Tag

Archive

Feed