Google Play 정책 분석 AMA

좋습니다.

Google Play 정책을 분석하는 이 패널에 참여해 주셔서 감사합니다.

저는 자동차용 Android팀의 개발자 관계 엔지니어인 얀 클라이너트입니다.

오늘 패널의 진행을 맡게 되었습니다.

패널인 보단과 폴이 자기소개를 하겠습니다.

보단님, 먼저 시작해 주세요.

안녕하세요, 여러분.

저는 Google Play 신용안전팀에서 일하는 보단입니다.

저는 4년 넘게 YouTube에서 일하고 있으며 기술 신뢰 및 안전 업계에서 10년 넘게 근무했습니다.

저는 기술, 업계, 문화가 상호작용하는 방식과 이벤트가 새로운 앱 개발을 장려하는 방식을 살펴보는 것을 좋아합니다. 또한 여러분과 같은 개발자가 성공할 수 있도록 최선을 다해 지원할 수 있는 이러한 이벤트를 좋아합니다.

안녕하세요.

제 이름은 폴입니다.

저는 보단과 같은 팀에서 일하고 있으며, 보단과 거의 같은 기간인 10년 동안 신용안전팀에서 일해 왔습니다. 대부분의 기간을 Google Play 신용안전팀에서 보냈습니다.

오늘 이 자리에 서게 되어 매우 기쁩니다. 이제 시작해 보겠습니다.

감사합니다.

패널을 시작하기 전에 폴에게 다시 마이크를 넘기겠습니다.

먼저 정책 리소스에 관한 간략한 개요와 권장사항 등의 정보를 제공하여 앱이 더 원활하고 효율적인 정책 검토를 받을 수 있도록 준비하는 데 도움을 줄 것입니다.

네.

그렇다면 Play 정책이란 무엇일까요?

이는 개발자가 Google Play 스토어에서 모바일 애플리케이션을 게시하고 유지관리할 때 준수해야 하는 기본 규칙입니다.

화면에 Play 정책 리소스에 관한 짧은 링크를 제공했습니다.

첫 번째 링크를 클릭하면 개발자 정책 센터로 이동합니다.

페이지 상단의 '최근 업데이트'를 클릭하면 새로운 정책에 관한 세부정보와 기존 정책의 업데이트 또는 설명 내용을 확인할 수 있습니다.

시각 또는 청각 자료를 통해 학습하는 것을 선호하는 경우 두 번째 짧은 링크를 통해 정책 바이트 재생목록으로 이동할 수 있습니다.

정책 업데이트를 설명하는 동영상입니다.

마지막으로 세 번째 링크를 클릭하면 Android 스튜디오의 Google Play 정책 인사이트에 관해 자세히 알아볼 수 있는 페이지로 이동합니다. 이 기능은 Android 스튜디오에서 린트 검사로 제공되는 유용한 사전 검토 가이드를 제공하기 위한 것입니다.

좋습니다.

또한 이러한 Google Play 정책에 따라 Android 앱을 감사하여 권한, 계정 삭제, 데이터 보안 전반의 규정 준수 여부를 확인하는 데 도움이 되는 Android 기술도 있습니다.

다른 스킬과 마찬가지로 Android CLI를 사용하여 이 스킬을 설치할 수 있습니다.

android skills list
android skills add play-policy-insights

마지막으로, 얀의 패널 질문을 시작하기 전에 Play 정책 및 앱 리뷰를 사용할 때의 권장사항을 공유하고자 합니다.

첫 번째는 검토자에게 로그인 사용자 인증 정보를 제공하는 것입니다.

간단한 문제처럼 보이지만, 지연이나 거부의 매우 일반적인 원인은 액세스할 수 없는 콘텐츠입니다.

앱에 로그인이 필요하거나, 제한 콘텐츠가 있거나, 크레딧 또는 정기 결제가 있는 경우 테스트 사용자 인증 정보를 제공해야 합니다.

일부 앱의 경우 앱을 시작할 때 로그인 사용자 인증 정보를 제공해야 하고, 다른 앱의 경우 앞서 언급한 유료 콘텐츠와 같이 다른 섹션이 있을 수 있습니다.

Play Console에서 이 작업을 수행한 후 검토자에게 로그인 사용자 인증 정보를 제공할 수 있습니다.

이전에는 앱 액세스라고 불렸지만 이제는 로그인 세부정보라고 하며 앱 콘텐츠 섹션에 있습니다.

그런 다음 사용자 인증 정보가 2단계 인증, 보안문자, 페이월 등 모든 종류의 인증을 우회하는지 확인해야 합니다.

예, 이전 버전 코드를 비활성화합니다.

따라서 개발자는 깨끗하고 규정을 준수하는 프로덕션 빌드를 업로드하지만, 공개 테스트, 비공개 테스트 등 다른 트랙의 Play Console에서 규정을 준수하지 않는 이전 버전이 여전히 활성 상태라는 사실을 잊어버리는 경우가 많기 때문에 거부 루프라고 하는 현상을 자주 경험합니다. 따라서 이전 테스트 트랙에 있는 App Bundle이라도 Play 정책 검토, Play 정책의 적용을 받습니다.

따라서 제한된 권한을 요청하거나 오래된 취약한 SDK를 사용하는 경우 여전히 검토 대상이 됩니다.

따라서 제출 버튼을 누르기 전에 모든 트랙에서 오래된 버전 코드를 모두 교체하거나 비활성화해야 합니다.

셋째, 검토에 충분한 시간을 할애하고 관리형 게시를 사용하세요.

따라서 앱 검토 및 게시가 완료되기까지 7일 이상 걸릴 수 있으며, 특히 신규 앱이거나 민감한 권한을 요청하는 앱인 경우 더 오래 걸릴 수 있습니다.

따라서 충분한 리드 타임을 제공해야 합니다.

주요 출시가 있는 경우 실제 출시일로부터 최소 몇 주 전에 새 앱을 제출해야 합니다.

그런 다음 관리형 게시와 연결할 수 있습니다.

관리형 게시는 승인된 업데이트를 출시할 준비가 될 때까지 보류할 수 있는 기능으로, 마케팅 캠페인이나 기타 민감한 출시 중에 예기치 않은 지연이 발생하는 것을 방지합니다.

이때 검토를 위해 이미 제출한 앱을 다시 제출하지 않도록 주의해야 합니다.

그렇게 하면 시계가 다시 시작되기 때문입니다.

개발자가 이 점을 잊고 앱을 절반쯤 개발한 후에야 '아, 이 부분을 조금 변경해야겠네'라고 생각하는 경우가 있습니다.

다시 제출하면 검토 절차가 처음부터 다시 시작됩니다.

선언을 확인하세요.

따라서 데이터 보안 섹션, 개인정보처리방침, 사진/동영상 권한과 같은 앱 콘텐츠 선언은 모든 트랙에서 활성 번들 또는 버전 코드의 앱 매니페스트와 일치해야 합니다.

예를 들어 앱 매니페스트에서 정확한 위치 액세스를 요청하지만 권한 선언 양식에 그 목적이 공개되지 않은 경우 앱에 시정 조치가 적용될 수 있으며, 실제로 적용될 가능성이 매우 높습니다.

따라서 서드 파티 SDK가 선언하지 않은 데이터를 유출하지 않도록 해야 합니다.

앱에서 특정 데이터를 사용하지 않더라도 해당 데이터를 사용하는 SDK를 통합하면 시정 조치가 적용될 수 있습니다.

Google Play SDK 색인을 확인하여 널리 사용되는 100여 가지 상업용 SDK에 대한 통계 정보를 확인하세요.

다음으로 넘어가기 전에 간단한 질문을 드리고 싶습니다.

시정 조치란 구체적으로 무엇을 의미하나요?

이 용어는 무슨 뜻인가요?

시정 조치는 불리한 조치일 수 있으므로 경고부터 거부, 삭제, 정지 또는 계정 차단과 같은 더 심각한 시정 조치까지 다양할 수 있습니다.

따라서 시정 조치라고 하면 이러한 불리한 조치를 의미합니다.

됐습니다

감사합니다.

네.

마지막으로 이의신청을 사용합니다.

거부된 후 동일한 버전을 다시 제출하지 마세요.

또한 짧은 기간 내에 동일한 문제로 반복적으로 거부되면 알고리즘 플래그가 트리거되어 폴이 언급한 삭제 또는 정지와 같은 더 심각한 시정 조치가 적용될 수 있습니다.

따라서 앱이 거부되면 변경사항을 적용하거나, 추측하거나, 의견을 반영하지 않은 상태로 바로 다시 제출하지 마세요.

정확한 위반 사항과 안내가 포함된 알림이 콘솔 받은편지함과 제공하신 관련 이메일로 전송됩니다.

거부에 동의하지 않거나 이해하지 못하는 경우 이의신청을 제출할 수 있습니다.

거짓양성이라고 생각되면 커뮤니케이션에 제공된 링크를 사용하여 이의신청을 제출할 수 있습니다.

이는 아무런 변경 없이 서둘러 다시 제출하는 것보다 더 나은 첫 번째 단계입니다.

커뮤니케이션을 받았는데 이해가 잘 되지 않거나, 너무 장황하거나, 단락이 너무 많거나, 어떤 경우든 이의신청팀에 다시 문의해도 괜찮습니다.

그러면 실제 사람과 이메일을 주고받게 됩니다.

커뮤니케이션에 제한이 있을 수 있지만, 거부 사유에 대한 추가 세부정보를 얻을 수 있는 경우가 많습니다.

이의신청팀은 커뮤니케이션이 상당히 길어질 수 있다는 점을 이해하고 있습니다.

따라서 개발자님과 개발자님의 앱에 구체적으로 적용되는 섹션을 강조 표시하거나 굵게 표시할 수 있습니다.

그렇습니다.

이제 얀에게 다시 넘기겠습니다.

좋습니다.

감사합니다.

그래서 다양한 채널과 소스를 통해 개발자들의 질문을 수집했습니다.

오늘 다룰 질문은 정책과 관련하여 개발자로부터 자주 듣는 몇 가지 문제를 대표합니다.

그럼 이 부분부터 시작해 보겠습니다.

권한과 관련하여 앱이 거부될 수 있는 일반적인 이유는 무엇인가요?

개발자가 권한 정책 위반과 관련된 거부를 방지하려면 어떻게 해야 하나요?

좋습니다.

권한은 제가 맡겠습니다.

따라서 권한, 특히 민감한 권한은 앱의 광고된 목적의 핵심 목적에 핵심적이어야 합니다.

따라서 앱에 포함되지 않거나 광고되지 않은 보조 기능이나 일부 기능이 있는 경우 앱이 거부될 가능성이 높습니다.

따라서 선언이 앱의 사용 사례와 일치하는지 확인하세요.

또한 선언에 제공한 동영상 링크에 액세스할 수 없어 앱이 거부되는 경우도 많습니다.

검토팀에서 앱을 완전히 검토하려면 앱, 제공된 동영상 링크, 앱 내의 모든 항목에 액세스할 수 있어야 합니다.

따라서 앱, 매니페스트, 선언 내에서 모든 항목에 액세스할 수 있는지 확인하세요.

따라서 이 세 가지 항목을 완료하면 프로세스가 더 원활하게 진행될 것입니다.

됐습니다

좋습니다.

그렇다면 앱 내에서 AI 생성 콘텐츠를 사용하기 위해 서드 파티 플랫폼을 사용하는 앱 개발자가 늘고 있다는 말씀이시죠?

이러한 플랫폼에서 부적절하거나 사실과 다른 콘텐츠를 생성하는 경우 개발자의 앱이 거부될 수 있나요? 이 경우 실제로 누구에게 책임이 있나요?

네.

네, 거부될 수 있습니다.

Play 스토어가 시작된 이래로 개발자가 앱에 포함하는 모든 항목 또는 사용자가 앱에서 액세스할 수 있는 모든 항목은 개발자의 책임이라는 입장을 항상 유지해 왔습니다.

생성형 AI는 새로운 분야이지만 이 원칙은 동일하게 적용됩니다.

생성형 AI와 유사한 것으로 사용자 제작 콘텐츠를 들 수 있습니다. 두 정책 모두 동일한 종류의 정책이 많이 필요하기 때문입니다. 예를 들어, 부적절한 콘텐츠가 표시되면 신고할 수 있어야 합니다.

필터링 메커니즘이 있어야 합니다.

물론 적용되는 다른 정책도 있지만, 저는 이렇게 생각합니다. 생성형 AI 콘텐츠가 있는 경우 Google에서 앱을 검토하고, 사용자가 부적절한 콘텐츠를 발견하면 신고를 클릭하고, 필터링 메커니즘이 작동합니다.

따라서 Google, 개발자, 사용자가 모두 협력하여 모든 사람을 위해 앱을 최대한 안전하게 유지해야 합니다.

좋습니다.

좋습니다.

하지만 일반적으로 사용자가 콘텐츠를 신고하는 메커니즘 외에도 개발자가 필터링 메커니즘을 적용하는 것이 좋다는 말씀이신가요?

특정 유형의 콘텐츠가 사용자에게 표시되지 않도록 하는 방법이 있나요?

정답입니다.

네.

검토 과정에서 Google팀이 코드를 파헤치거나 정확한 필터링 메커니즘을 리버스 엔지니어링하지는 않습니다.

부적절한 콘텐츠에 액세스할 수 있는지 확인하는 것뿐입니다.

그리고 가능하다면 커뮤니케이션을 다시 보내고, 필터링 메커니즘을 더 강력하게 만드는 방법을 파악하는 것은 귀하의 팀의 역할이 될 것입니다.

알겠습니다.

좋습니다. 감사합니다.

명의 도용 또는 모방 정책이라는 정책이 있죠?

명의 도용 정책에 따라 앱이 거부되었지만 어떤 이유로든 오류라고 생각하는 경우 어떻게 해야 하나요?

이러한 유형의 거부를 사전에 방지하려면 어떻게 해야 하나요?

이의신청

예, 보드에 표시된 다섯 번째 권장사항 중 하나입니다. 거부되면 이의신청을 해야 합니다.

그다음에 해야 할 일은, 가장 일반적인 시나리오는 명의 도용 대상 브랜드가 본인의 브랜드인 경우입니다.

또는 다른 사람을 대신하여 앱을 만드는 경우도 있습니다. 아마도 가장 일반적인 경우일 것입니다. 피트니스 시설, SaaS, 일종의 SaaS 솔루션을 위해 앱을 만드는 화이트 라벨 개발자가 있는 경우입니다.

그렇다면 자체 개발자 계정으로 게시하는 것이 더 쉽겠죠?

이의신청을 제출할 수 있으며, YouTube팀에서는 권한 증빙 자료를 검토합니다.

예를 들어 Joe's Chicken이라는 고객이 있고, 이 고객은 미시시피 서부에서 가장 맛있는 치킨을 판매한다고 가정해 보겠습니다.

Joe's Chicken에서 공식 회사 서신 양식에 로고를 포함하여 ABC 개발자에게 앱에 자사의 이미지와 유사성을 사용할 권한을 부여한다는 내용의 권한 증명 서한을 제공합니다. 이때 앱 이름과 앱 패키지 이름을 기재하는 것이 좋습니다.

com.joeschicken.app과 같은 패키지 이름이 있을 수 있습니다. 그러면 개발자에게 응답하고 해당 문서를 제공할 수 있습니다.

좋습니다.

그리고 두 번째 부분은…

이를 방지하기 위해 사전에 할 수 있는 일이 있나요?

예를 들어 첫 번째 제출 시에, 이름은 기억나지 않지만, 증빙 서류를 업로드할 수 있나요?

예.

실제로

Play Console에는 사전 알림 양식이 있습니다. 이 양식을 제출하고 계정과 다른 법인을 연결하는 문서를 업로드할 수 있습니다.

이렇게 하면 앱 제출 시 이러한 시정 조치로 인한 불이익을 사전에 방지할 수 있습니다.

네

됐습니다

좋습니다.

앞서 권장사항 섹션에서 서드 파티 SDK 사용에 관해 간단히 언급하셨는데, 이 부분에 관해 조금 더 자세히 알아보고 싶습니다.

앱에서 서드 파티 SDK를 사용하는 경우, 서드 파티 SDK가 사용자 데이터 등을 사용하는 방식에 대한 책임은 앱 개발자에게 있다는 말씀이시군요.

그렇다면 개발자는 SDK가 데이터 보안 및 사용자 데이터 정책을 준수하는지 어떻게 알 수 있을까요?

이러한 환경을 어떻게 헤쳐 나갈 수 있을까요?

네, 좋은 질문입니다.

Google에서 처음 2년 동안 SDK 관련 업무를 많이 했습니다. 이 질문은 생성형 AI와 사용자 제작 콘텐츠에 관해 이야기했던 이전 질문과도 관련이 있습니다. 앱에 포함된 모든 콘텐츠는 궁극적으로 개발자의 책임이라는 점입니다.

폴이 소개에서 Google Play SDK 색인이라는 것이 있다고 간단히 언급한 것 같은데요. Google에서 검색해 보시면 됩니다.

첫 번째 또는 두 번째 결과인 Google Play SDK 색인을 클릭하면 수익 창출, 광고, 건강 등 다양한 카테고리로 분류된 수백 개의 SDK가 포함된 웹페이지가 표시됩니다.

이 페이지는 공개적으로 사용 가능한 데이터를 가져옵니다.

Google에서 주최하는 행사입니다.

하지만 SDK를 살펴보면 일부 SDK 옆에 SDK Console에 등록됨과 같은 배지가 표시되어 있습니다.

개발자가 앱을 위한 Play Console을 사용하는 것처럼 SDK 개발자도 SDK Console에 액세스할 수 있습니다.

이러한 앱도 유사한 검토 절차를 거쳐야 합니다.

SDK를 Google에 전송합니다.

Google은 몇 가지 다른 검사를 거치지만, 검사를 통과하고 규정을 준수하면 배지를 받게 됩니다.

개발자는 이 색인에서 어떤 SDK가 해당 절차를 통과했는지 확인할 수 있습니다.

앱이 승인되거나 SDK가 규정을 준수하지 않는 일이 없다고 보장할 수는 없지만, 두 가지 측면에서 신뢰를 준다고 생각합니다.

첫째, 해당 SDK를 사용하면 앱이 거부되지 않을 가능성이 훨씬 높습니다.

확률일 뿐입니다.

두 번째는 전체 프로세스에서 제가 정말 좋아하는 부분인데요. SDK에 규정을 준수하지 않는 부분이 있는 것으로 확인되면 두 가지 접근 방식을 취합니다.

첫 번째는 SDK 개발자에게 연락하여 'SDK가 규정을 준수하지 않는 방식으로 사용자 데이터를 전송하는 것으로 확인되었습니다'라고 알리는 것입니다.

그러면 개발자는 앱 또는 SDK가 정책을 준수하도록 조치를 취합니다.

그리고 거의 동시에 또는 조금 후에, 두 번째 단계로 Google팀에서 개발자에게 알림이나 경고를 보냅니다.

알림에는 '앱이 규정을 준수하지 않는 방식으로 데이터를 전송하고 있으며 ABC SDK에서 이러한 문제가 발생하고 있습니다'와 같은 내용이 표시됩니다.

따라서 개발자가 취할 수 있는 조치는 SDK를 제공된 규정 준수 버전으로 업데이트하는 것입니다.

더 강력한 조치를 취하고 싶다면 SDK를 삭제하거나 교체할 수 있지만, 이는 많은 노력과 작업이 필요하다는 것을 알고 있습니다.

하지만 Google Play SDK 색인을 사용하면 이 문제를 해결할 수 있습니다.

네.

색인에는 어떤 정책을 준수하는지 또는 준수하지 않는지 정확히 명시되어 있지 않지만, 배지를 받으면 신뢰할 수 있다는 의미입니다.

좋습니다.

네.

네, 좋습니다.

말씀하신 내용을 바탕으로 추론해 보면, 개발자에게 '이 SDK를 사용 중인데 문제가 있습니다'라는 메시지를 보내면

업데이트할 예정인 경우 어떤 버전인지 알려주나요? 개발자가 수정하면 '더 나은 버전은 이러이러합니다'라고 알려주나요?

아니면 직접 조사를 해야 하나요?

버전 코드가 있는 것 같습니다.

확실하지는 않지만 업데이트할 수 있는 버전 코드가 표시되어 있는 것으로 알고 있습니다.

네, 그리고 저는 개발자도 아니고 엔지니어도 아니지만, 개발자들과 이야기를 나누다 보면 때로는 버튼 하나 또는 몇 개만 클릭하면 앱 내에서 SDK 업데이트 프로세스가 시작되는 경우도 있다고 합니다.

그거 멋진데요.

됐습니다

감사합니다.

좋습니다.

로그인 사용자 인증 정보에 관해 말씀해 주셨는데, 이 주제는 제가 어느 정도 알고 있는 내용이며 이 정보를 포함하는 것이 얼마나 중요한지 알고 있습니다.

2단계 인증을 우회하고 페이월을 우회하거나 구독 기반 콘텐츠에 액세스하는 방법과 같은 것들을 언급하셨습니다.

하지만 개발자가 고려해야 할 다른 일반적인 상황에는 어떤 것이 있을까요?

예를 들어, 제가 경험한 것 중 하나는 앱에 특정 국가 또는 특정 위치에서만 액세스할 수 있는 콘텐츠가 있거나, 실제로 테스트하려면 두 개의 로그인이 필요한 메시지 앱과 같은 경우입니다.

로그인을 제공하는 것 외에 개발자가 추가 작업을 해야 하는 다른 상황이 있나요?

네.

검토팀에 제공하는 로그인 사용자 인증 정보로 시작하고 끝내야 합니다. 이를 통해 검토팀이 앱의 모든 기능에 액세스할 수 있도록 해야 합니다.

Play Console의 해당 섹션은 이전에 앱 액세스라고 불렸으며, 약 한 달 전쯤에 로그인 세부정보로 변경되었습니다.

사용자 이름, 비밀번호를 입력할 수 있는 입력란이 있고 그 아래에 자유 형식 텍스트 입력란이 있습니다.

따라서 로그인 단계가 간단하지 않은 경우 로그인 단계를 안내할 수 있습니다.

원하는 경우 사용자에게 두 번째, 세 번째, 네 번째 로그인을 제공할 수도 있습니다.

Google팀에서 앱을 검토할 때 어떤 방식으로 진행되는지 알려드리자면, 누군가 방에 앉아서 앱을 살펴본 후 승인 또는 거부를 클릭하는 것이 아닙니다.

다양한 정책과 워크플로를 검토하는 팀이 많기 때문에 여러 기기에서, 때로는 여러 지역에서 두 명 이상의 사용자가 앱에 로그인할 수 있습니다.

많은 안전 메커니즘이 '로그인이 많이 발생하면' 사용자의 안전을 위해 로그인을 중지하고 되돌리기 때문에 어려움이 있다는 것을 알고 있습니다.

하지만 어떤 방법을 선택하시든, YouTube는 다양한 워크플로에서 앱을 검토하고 있으므로, 결국에는 해당 알림을 보게 될 수도 있습니다.

따라서 여러 로그인을 제공하면 도움이 될 수 있습니다.

네.

됐습니다

네, 선언에서 자유 형식 텍스트를 활용하는 것이 얼마나 중요한지 강조해야 합니다.

따라서 데모 계정이 단순히 사용자 이름과 비밀번호로 구성되어 있지 않고 더 많은 단계가 포함되어 있다면 검토팀이 앱에 액세스하는 방법을 이해할 수 있도록 해야 합니다.

사용자 이름, 비밀번호보다 복잡한 경우 Google팀에서 방법을 이해할 수 있도록 방법을 보여주는 동영상을 제공할 수 있습니다.

네.

앱을 직접 살펴보는 것을 좋아하는데, 꽤 멋진 로그인 화면이 있는 앱도 있습니다.

제가 본 것 중에는, 정말 거짓말이 아니라, 이 버튼을 17번 탭한 다음 화면에 X를 그리고, 개발자 모드가 표시되면, 11개의 다른 단계를 따라야 하는 것도 있었습니다. 그러니 그렇게 하지 마세요.

그렇게 하면 좀 어려워지니까요.

제가 들은 한 가지 시나리오는 일부 앱에서는 연속 로그인 또는 앱과의 동시 로그인을 X회만 허용하고, 그 이후에는 '하나를 삭제해야 합니다'라는 메시지가 표시된다는 것입니다.

따라서 앱에서 이 기능을 지원하는 경우 이전 로그인과 같은 액세스 권한을 삭제할 수 있는 페이지를 찾는 방법에 관한 정보를 포함하는 것도 유용합니다.

네.

됐습니다

따라서 Google에서 정책을 업데이트하거나 새로운 정책을 발표할 때 개발자가 앱을 변경해야 할 수 있으며, 변경사항에 따라 구현하는 데 시간이 걸릴 수 있습니다.

이러한 요청에는 기한이 있는 경우도 있습니다.

예를 들어 특정 날짜까지 새로운 정책을 준수하기 위해 XYZ를 완료해야 한다는 내용입니다.

기한이 다가오고 있지만 개발자가 규정을 준수하기 위해 시간이 더 필요하다는 것을 알고 있는 경우 어떤 옵션이 있나요?

경고처럼 들리네요.

경고처럼 들리네요.

네.

예, 경고의 경우 간단한 방법은 시간을 더 달라고 요청하는 것입니다.

이 프로세스는 일반적으로 새로운 정책, 기존 정책의 업데이트, 또는 명확한 설명이 발표되는 방식으로 진행됩니다.

그리고 Google은 일반적으로 리드 타임을 충분히 제공하는 편입니다.

그리고 조치를 취하기 6개월 전에 정책을 공개적으로 발표할 수도 있습니다.

그러면 경고가 전송되고, '6개월 또는 12개월 전에 발표된 정책을 앱이 위반하고 있습니다'라는 메시지가 표시됩니다.

하지만 폴과 제가 가끔 반박하는 부분이 있는데, 7일 이내에 변경해야 한다고 말하는 경우가 있습니다.

개발에 시간이 오래 걸리는 것 같습니다.

이해합니다.

그러면 저는 그냥 응답합니다.

이의신청을 통해 진행할 수 있으며, '정책을 이해하고 있으며 앱이 규정을 준수하지 않는다는 점을 알고 있습니다.

이미 해결 중이거나 정책 문제를 해결하기 위해 이러한 조치를 취할 예정이지만 시간이 더 필요합니다.'라고 말할 수 있습니다.

따라서 일반적으로 조금 더 많은 시간을 제공합니다.

7일이 더 지나고 그 기간이 끝나갈 때 다시 요청할 수 있습니다.

물론 무한하지는 않습니다.

하지만 말씀드린 것처럼 폴과 저는 반대 의견을 제시하지만, 이는 개인적인 차원에서도, 더 높은 차원에서도 마찬가지입니다.

새로운 정책이 시행될 예정이고 누가 이 작업을 진행하고 있는지 알고 있다면 "7일이나 14일이 아닌 28일 전에 경고를 줄 수 있을까요?"라고 말할 수 있습니다.

네.

실제로

규정 준수를 위해 선의로 변경사항을 적용하고 있다는 점을 선의로 입증하면 Google Play에서 새로운 기한을 설정하는 데 협력할 것입니다.

더 나은 타임라인을 제공합니다.

좋습니다.

이의신청은 적절하게 사용하기만 하면 다양한 상황에 도움이 되는 다목적 도구와 같다고 할 수 있겠네요.

타당한 경우 이의신청을 사용하고 이의신청을 제출하는 이유를 충분히 자세히 설명하는 것이 고려와 도움을 받는 좋은 방법이 될 수 있습니다.

좋습니다.

개발자가 하나의 개발자 계정으로 여러 앱을 보유하고 있는 경우(이런 경우는 항상 발생합니다)

한 앱이 정책 위반으로 정지되면 전체 개발자 계정에는 어떤 영향을 미치나요?

이로 인해 계정이나 규정을 준수하는 다른 앱이 위험에 처할 수 있나요?

어떻게 작동하나요?

그럴 수 있습니다.

이러한 개발자는 빈 라벨 개발자와 같습니다.

아까 조의 치킨에 대해 이야기했었죠?

그리고 해당 업계에 속한 고객이 있을 수도 있습니다.

야구에 비유하자면 삼진 아웃을 당하는 것과 같습니다.

안타깝게도 Play 스토어에 진입하려는 악의적인 행위자가 존재하며, 이로 인해 Google은 가벼운 시정 조치부터 삭제, 정지, 계정 차단과 같은 강력한 조치에 이르기까지 다양한 조치를 취하고 있습니다.

따라서 Play 스토어에 유사한 앱이 여러 개 있는데 그중 하나가 정지되었다고 가정해 보겠습니다.

음.

너는 악의적인 행위자지?

그래서 수정하고 한 달 후에 다시 제출하려고 합니다.

그러면 YouTube팀에서 이를 감지하고 다시 정지 조치를 취합니다.

그런 다음 앱에서 삭제했다가 한 달 후에 다시 추가하면 반복 패턴의 행동이 생기고, 타석에 들어서서 삼진을 세 번 당하면 이제 아웃되는 거죠?

하지만 치킨 레스토랑을 위한 앱을 만든다고 가정해 보겠습니다. 악성 콘텐츠가 아니며 사람들에게 맛있는 음식을 제공하려는 것뿐입니다.

CI/CD 파이프라인 등을 통해 이 모든 앱을 동시에 제출했는데 10개의 앱이 동시에 거부되거나 정지되었다고 가정해 보겠습니다. 이 경우 Google은 개발자가 동시에 수많은 앱을 제출하고 있다는 점을 이해하므로 이를 하나의 경고로만 간주합니다.

음.

그렇군요.

이것이 질문에 대한 답변이 되었기를 바랍니다.

네, 좋습니다.

감사합니다.

하나 더 있습니다.

지금까지는 이미 자리를 잡은 개발자에게 더 적합한 질문이 많았지만, 이번 질문은 Play Console에서 처음 설정할 때와 관련된 질문입니다.

Google Play 결제 프로필이 인증되었다고 가정해 보겠습니다.

본인 인증 오류는 이제 사라졌고 전화번호 인증만 남아 있습니다.

이 경우 개발자는 개발자 계정에서 앱을 게시할 준비가 되었는지 확인하기 위해 무엇을 해야 하나요?

퍼즐 조각을 하나씩 맞추는 것처럼 느껴질 때도 있고, 이와 같은 상황에서 절차를 완료하는 방법을 모를 수도 있습니다. 이럴 때는 어떻게 해야 하나요?

예, 얼마 전 다른 이벤트에서 비슷한 질문을 받았는데요. 신규 개발자에게는 당연히 적용되는 사항이지만 기존 개발자 중 상당수도 다시 인증을 받아야 했던 것 같습니다.

1년 정도 된 것 같은데 맞나요?

잘 기억이 안 나네요.

대부분은 자동으로 인증되었지만 일부는 인증을 받아야 했습니다.

좋습니다.

아니면 주소와 Dun & Bradstreet 프로필이 일치하지 않는 경우…

실제로

실제로

Google 프로필입니다.

좋습니다.

예, 전화번호라고 가정해 보겠습니다.

이 질문에는 두 가지 방식으로 답변해 드리겠습니다.

좋습니다.

첫 번째는 이 단계를 진행하는 동안 Play Console에 알림이 표시되는 경우가 많다는 것입니다.

그러면 '전화번호를 등록할 시간입니다'라는 알림이 표시됩니다.

이건 아주 간단합니다.

국제 전화번호 형식으로 입력합니다. +1 408, 번호가 무엇이든 상관없습니다.

SMS 또는 전화 통화 인증을 진행하고 표시되는 단계를 따릅니다.

하지만 그렇게 하려고 해도 오류 메시지 등이 표시되는 경우가 있습니다. 개발자 중에도 그런 경우가 있었고 SMS 코드를 받지 못하는 경우도 있었습니다.

이의신청팀에 문의하는 방법을 알려드리겠습니다.

그 팀은 한 팀이지만 실제로는 6개 또는 24개의 다른 팀이 있는 것 같습니다.

Will.

실제로 액세스할 수 있는 Play Console에서 도움말 메뉴를 통해 질문에 답변합니다.

이제 UI가 약간 변경되었습니다.

이전에는 홈 화면 왼쪽의 메뉴에 있었습니다.

하단에 도움말 버튼이 있었습니다.

이 버튼은 사라졌지만, 이제 페이지 하단의 바닥글로 스크롤하면 도움말 버튼이 표시됩니다.

클릭하면 지원 티켓 만들기라는 작은 파란색 알약 버튼이 표시됩니다.

그렇게 적혀 있는 것 같아요.

음.

예.

그러면 질문할 수 있는 드롭다운이 표시됩니다.

전화번호로 바로 연결되는 드롭다운이 여러 개 있습니다. 거의 외우고 있는 것 같은데, 개발자 계정을 인증하는 것과 비슷합니다. 두 번째 드롭다운도 꽤 비슷하고, 라디오 버튼이 여러 개 표시됩니다.

그중 하나는 전화번호 인증 전용입니다.

그런 다음 SMS 인증 코드를 받거나 해당 절차를 진행하려고 할 때 화면에 버그가 표시될 수 있습니다.

전화번호 인증뿐만 아니라 Play 개발자 계정과 관련된 다른 많은 질문에 대해서도 이 방법을 사용할 수 있습니다.

대부분의 경우 Play Console에서 인증을 위한 다음 단계를 잘 보여주므로 단계를 따르기만 하면 됩니다.

좋습니다.

됐습니다

이제 시간이 거의 다 되었네요. 이 패널에 참여해 주신 모든 분께 감사드립니다.