[Google Play][정책] READ_MEDIA_IMAGES·VIDEO를 유지할지 Photo Picker로 바꿀지 결정한 뒤 Data safety와 account deletion 답변을 왜 따로 다시 맞추나

IT 리서치 노트

[Google Play][정책] READ_MEDIA_IMAGES·VIDEO를 유지할지 Photo Picker로 바꿀지 결정한 뒤 Data safety와 account deletion 답변을 왜 따로 다시 맞추나

Google Play에서 `READ_MEDIA_IMAGES`와 `READ_MEDIA_VIDEO`를 유지할지 Photo Picker로 바꿀지 결정할 때 많은 팀이 manifest나 declaration만 손보고 끝낸다. 하지만 2026년 8월 20일 기준 Google Play 공식 도움말을 다시 보면, broad photo/video permission 판단, Data safety deletion request mechanism 답변, account deletion의 인앱 경로와 웹 링크는 서로 다른 질문으로 남아 있다. 이 글은 broad media permission 결정을 끝낸 뒤에도 Data safety와 account deletion 답변을 왜 따로 다시 맞춰야 하는지 정리한다.

목차

1. 개요
2. 어디서 실제로 막히는가
3. 실무에서 적용하는 순서
4. 공식 문서와 예시 화면으로 확인하기
5. 주의사항과 리스크
6. 결론
7. 참고 링크

1. 개요

결론부터 말하면 Google Play photo/video permission 대응은 broad permission 유지 또는 Photo Picker 전환 결정 → 모든 트랙 manifest 반영 → Data safety deletion mechanism 및 SDK disclosure 재검토 → account deletion 인앱 경로와 웹 링크 확인 → privacy policy 문장 재정렬 순으로 가는 편이 가장 빠르다. broad permission 결정과 disclosure 정리는 같은 질문이 아니다.

즉 Photo Picker로 갈아탔다는 사실만으로 reviewer 패키지가 닫히지 않는다. permission 최소화는 하나의 축이고, Data safety와 account deletion은 또 다른 축이다. 이 둘이 따로 맞지 않으면 reviewer는 여전히 불일치로 본다.

실제 제출 메모까지 이어 가려면 Photo Picker 전환 뒤 reviewer memo에 manifest, declaration, Data safety, account deletion을 같은 칸으로 남기는 후속 글도 같이 보는 편이 좋다. 이 글이 왜 다시 맞춰야 하는지를 설명한다면, 후속 글은 무엇을 어떤 표로 남길지를 보여 준다.

2. 어디서 실제로 막히는가

실무에서 자주 꼬이는 패턴은 네 가지다. 첫째, broad media permission을 제거하고도 Data safety 답변은 예전 상태로 둔다. 둘째, production manifest만 고치고 testing track이나 다른 version code는 그대로 남긴다. 셋째, Photo Picker 전환으로 사진 접근 범위를 줄였는데 account deletion과 privacy policy 문장은 손대지 않는다. 넷째, SDK가 계속 수집하는 진단·식별자·미디어 처리 범위를 inventory에 반영하지 않는다.

Photo & Video Permissions reminder는 broad access 유지·제거·연장 요청 중 하나를 정하라고 한다. Restricted permissions 문서는 Android 13 이상이라면 system picker가 core functionality에 충분한지 먼저 보라고 적는다. Data safety 도움말은 deletion request mechanism을 전역 폼에서 답하라고 하고, account deletion 도움말은 계정 생성 앱이라면 인앱 삭제 경로와 웹 삭제 링크를 둘 다 요구한다. 이 네 문장을 합치면 reviewer는 permission, declaration, deletion, policy wording을 각각 따로 본다.

예를 들어 broad permission을 제거해도 앱이 계정 생성형이면 account deletion 요구사항은 그대로다. 반대로 broad permission 유지가 승인되어도 Data safety에서 삭제 요청 수단, SDK disclosure, privacy policy 보관 문장이 어긋나면 또 다른 불일치가 된다. 그래서 Photo Picker 전환은 끝이 아니라 제출 패키지 재정렬의 시작점이다.

• 증상: permission은 고쳤는데 reviewer 메일은 계속 온다.
• 실패: manifest와 Data safety를 같은 문제로만 본다.
• 막힘: broad permission 제거 후 account deletion 문장까지 자동으로 끝났다고 착각한다.
• 누락: SDK inventory와 모든 트랙 version code를 함께 확인하지 않는다.

보이는 현상	먼저 볼 곳	판단 기준
Photo policy 메일이 왔다	manifest와 declaration	broad access 유지인지 Photo Picker 전환인지 정한다
Data safety 답변이 또 어긋난다	deletion mechanism, SDK inventory	permission 변경과 disclosure 변경을 분리한다
계정 삭제 관련 코멘트가 남는다	in-app path + web link	계정 생성 앱이면 둘 다 있어야 한다

3. 실무에서 적용하는 순서

가장 짧은 실행 순서는 다섯 단계다. 1단계에서 broad permission이 core 기능에 정말 필요한지, 아니면 Photo Picker로 줄일 수 있는지 결정한다. 2단계에서 모든 version code와 testing track까지 manifest 상태를 확인하고 수정하고 저장한다. 3단계에서 Data safety deletion request mechanism과 SDK disclosure를 다시 확인하고 입력하고 저장한다. 4단계에서 계정 생성 앱이면 in-app delete path와 web deletion link를 클릭하고 열고 검증한다. 5단계에서 privacy policy의 retention and deletion 문장을 이 상태에 맞게 다시 쓰고 다시 확인하고 다시 제출한다.

1. Photo Picker 전환 또는 broad access declaration 여부를 먼저 결정한다.
2. 모든 트랙과 version code에서 manifest 상태를 맞춘다.
3. Data safety deletion mechanism과 SDK disclosure를 재검토한다.
4. 계정 생성 앱이면 인앱 삭제 경로와 웹 링크를 둘 다 확인한다.
5. privacy policy의 보관·삭제 문장을 최종 상태에 맞춘다.

이 순서를 지키면 reviewer 대응 메일도 훨씬 짧아진다. 우리는 broad media permission을 제거했고, Data safety deletion mechanism은 이렇게 표시했으며, 계정 삭제는 앱 안 경로와 웹 링크에서 둘 다 가능하다는 세 문장을 한 패키지로 제출할 수 있기 때문이다. 실제 제출 전에는 manifest를 열고, Data safety 폼을 열고, deletion link를 열고, privacy policy 문장을 확인하는 네 동작을 한 번에 묶어 두는 편이 좋다.

제출 메모 예시

media_access_decision=photo_picker
all_version_codes_checked=true
data_safety_deletion_mechanism=contact_form
sdk_media_collection_rechecked=true
account_creation=true
in_app_delete_path=/settings/account/delete
web_deletion_link=https://example.com/account-deletion
privacy_policy_retention_updated=true

이 메모만 있어도 permission 대응, Data safety, account deletion이 어떤 상태로 함께 제출됐는지 다음 주에도 바로 복기할 수 있다.

4. 공식 문서와 예시 화면으로 확인하기

첫 공식 화면은 Photo and Video Permissions reminder다. Google Play는 `READ_MEDIA_IMAGES`, `READ_MEDIA_VIDEO`를 가진 앱을 별도 대상군으로 분명히 지목하고, broad access 유지·제거·연장 요청 중 하나를 선택하라고 적는다.

사진·동영상 broad permission을 유지하는지 제거하는지 자체가 먼저 결정돼야 한다.

하지만 이 결정만으로 reviewer 패키지가 끝나는 것은 아니다. 권한을 남겨도, 빼도, disclosure 정리는 따로 남는다.

두 번째 자료는 minimum scope alternatives 문장이다. Play는 Android 13 이상 앱이라면 system picker가 core functionality에 충분한지 먼저 보라고 설명한다.

Photo Picker 같은 minimum scope alternative가 충분하면 broad permission을 유지하면 안 된다.

즉 이 단계는 permission 유지 여부를 가르는 기술 판단이다. 하지만 이후 Data safety와 account deletion 문장은 별도 정책 축으로 다시 맞춰야 한다.

세 번째 화면은 Data safety deletion request mechanism이다. Data safety 도움말은 앱이 사용자 데이터 삭제 요청 수단을 제공하는지 전역 폼에서 답해야 한다고 적는다.

Data safety는 permission 결정과 별도로 deletion request mechanism, SDK 수집, 데이터 유형을 다시 묻는다.

Photo Picker로 바꿨다고 해도 자동으로 이 답변이 정리되지는 않는다. reviewer는 broad permission과 disclosure를 서로 다른 질문으로 본다.

네 번째 자료는 account deletion 요구사항이다. 계정 생성이 있는 앱이라면 in-app 삭제 경로와 외부 web link resource를 둘 다 제공해야 한다고 문서가 분명히 적는다.

Account deletion 요구사항은 broad media permission 여부와 별도로 인앱 삭제 경로와 웹 삭제 링크를 동시에 본다.

따라서 `Photo Picker로 바꿨으니 개인정보 이슈는 끝났다`는 식의 정리는 틀린다. 권한 최소화와 삭제 경로 표기는 별도 축이다.

실무에서는 reviewer 문장을 표로 나눠 두는 편이 좋다. broad permission 유지 여부, Data safety disclosure, account deletion 경로는 서로 다른 질문이기 때문이다.

Photo Picker 전환 여부와 Data safety·account deletion 답변을 분리한 결정표다.

이미 Google Play Data Safety 기본 글, SDK Index와 User Data policy 글, account deletion 링크와 Data safety 문장 글을 봤다면, 이번 표는 broad media permission 축을 그 패키지에 붙이는 단계다.

마지막 자료는 제출 전 체크리스트다. broad permission을 유지하든 제거하든, reviewer 패키지는 권한·Data safety·account deletion 세 줄이 같은 문장을 가리켜야 한다.

Photo and Video Permissions 정책 대응 뒤 reviewer 패키지에서 다시 맞출 최소 체크리스트다.

이 메모가 없으면 manifest는 바뀌었는데 Data safety가 예전 상태이거나, deletion URL은 바뀌었는데 인앱 경로 문구가 그대로 남는 일이 자주 생긴다.

5. 주의사항과 리스크

첫 번째 리스크는 Photo Picker 전환만으로 reviewer 패키지가 끝났다고 생각하는 것이다. 두 번째는 broad permission 제거를 production에만 반영하고 테스트 트랙은 잊는 것이다. 세 번째는 Data safety deletion mechanism을 예전 답변으로 두는 것이다. 네 번째는 계정 생성 앱인데 웹 링크만 있고 인앱 삭제 경로가 없거나, 반대로 인앱 경로만 있고 외부 요청 링크가 없는 것이다.

운영 전에 최소한 manifest 상태, version code 범위, SDK inventory, deletion mechanism, in-app path, web link, privacy policy retention sentence를 같은 표로 남기는 편이 좋다. 이 일곱 칸이 없으면 reviewer 메일마다 다른 팀이 다른 문장으로 대응하게 된다. 특히 제출 직전에는 manifest를 확인하고, testing track을 확인하고, 링크를 클릭하고, 폼 답변을 저장하고, policy 문장을 다시 읽는 순서를 고정해야 한다.

• Photo Picker 전환과 Data safety 답변은 별개로 다시 봐야 한다.
• 계정 생성 앱이면 인앱 삭제 경로와 웹 링크를 동시에 확인한다.
• SDK가 수집하는 데이터와 privacy policy 보관 문장을 같이 맞춘다.

6. 결론

Google Play photo/video permission 대응의 핵심은 broad media permission 결정 이후에도 Data safety와 account deletion 답변을 별도 축으로 다시 맞추는 것이다. Permission 최소화는 시작일 뿐이고, reviewer는 그 다음에 disclosure와 삭제 경로까지 같은 상태인지 본다.

• broad permission 유지·제거 결정을 먼저 고정한다.
• Data safety deletion mechanism과 SDK disclosure를 다시 확인한다.
• 계정 생성 앱이면 인앱 삭제 경로와 웹 삭제 링크를 둘 다 검증한다.

제출 직전 증거 묶음을 더 짧게 정리하려면 2026년 8월 21일 후속 글처럼 reviewer memo 템플릿으로 manifest, declaration, Data safety, account deletion을 한 표로 모으는 편이 안전하다.

7. 참고 링크

1. https://support.google.com/googleplay/android-developer/answer/15800983?hl=en
2. https://support.google.com/googleplay/android-developer/answer/16558241?hl=en
3. https://support.google.com/googleplay/android-developer/answer/10787469?hl=en
4. https://support.google.com/googleplay/android-developer/answer/13327111?hl=en