[Google Play][정책] Photo Picker로 바꾼 뒤 reviewer memo에 manifest, declaration, Data safety, account deletion을 어떤 칸으로 같이 남기나

IT 리서치 노트

[Google Play][정책] Photo Picker로 바꾼 뒤 reviewer memo에 manifest, declaration, Data safety, account deletion을 어떤 칸으로 같이 남기나

Google Play에서 Photo Picker로 전환한 뒤에도 심사 대응이 길어지는 팀이 많다. 이유는 권한 코드를 바꾼 것과 심사자가 보는 증거 묶음을 같은 릴리스 단위로 맞추지 못하기 때문이다. 2026년 8월 21일 기준 Google Play 도움말을 다시 보면 READ_MEDIA 권한 제거 범위는 모든 version codes와 production·testing tracks까지 포함되고, custom picker는 broad access 정당화가 아니며, Data safety form은 testing tracks까지 포함되고, 계정 생성 앱은 account deletion의 인앱 경로와 웹 링크 리소스를 같이 제공해야 한다. 그래서 reviewer memo도 manifest, declaration, Data safety, account deletion을 한 표로 묶어 적는 편이 가장 안전하다.

목차

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

1. 개요

결론부터 말하면 Photo Picker 전환 뒤 reviewer memo는 manifest 변경, broad access declaration 상태, Data safety 답변, account deletion 경로 네 칸을 같은 release 기준으로 묶어 써야 한다. Google Play 정책은 권한 제거 범위를 모든 version codes와 testing tracks까지 요구하고, Data safety도 package 전체를 기준으로 보며, 계정 생성 앱에는 deletion 증거까지 요구한다.

즉 '권한만 뺐다' 또는 'Photo Picker로 바꿨다' 한 줄로는 심사 메모가 완성되지 않는다. reviewer가 보는 것은 현재 package 전체 동작과 관련 정책 답변의 일치 여부이기 때문이다.

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

실무에서 가장 흔한 막힘은 개발 변경과 정책 메모가 서로 다른 단위를 바라보는 것이다. 개발팀은 한 branch에서 Photo Picker를 붙이고 merged manifest를 바꿨다고 끝났다고 생각한다. 하지만 policy 담당자는 declaration과 Data safety를 예전 broad access 답변 그대로 두거나, account deletion 문구는 별도 문서에서만 관리한다. 이렇게 되면 한 릴리스 안에서 서로 다른 진실이 생긴다.

Google Play 도움말은 몇 가지 중요한 경계를 분명히 한다. READ_MEDIA 권한을 제거하려면 모든 version codes와 production·testing tracks에서 제거해야 한다. custom picker를 만들었다고 해서 broad permission 자격이 자동으로 생기지 않는다. Data safety form은 closed, open, production testing tracks까지 포함된다. 그리고 계정 생성 앱은 인앱 삭제 경로와 웹 링크 리소스를 함께 제공해야 한다. 즉 reviewer memo는 권한 정책, 데이터 선언, 계정 삭제 경로를 따로 쓰는 문서가 아니라 하나의 증거 묶음이어야 한다.

예를 들어 앱이 occasional image selection만 필요해서 Photo Picker로 바꿨다고 하자. manifest에서는 READ_MEDIA_IMAGES를 뺐지만, Data safety에는 아직 사진 데이터 수집 경로가 이전 답변대로 남아 있을 수 있다. 또 account deletion 웹 링크는 살아 있지만, reviewer memo에는 그 링크와 인앱 경로가 빠질 수 있다. 이 경우 심사자는 '정책 이해가 아직 맞지 않다'고 볼 가능성이 높다. 반대로 broad access가 여전히 core functionality인 앱이라면 왜 Photo Picker가 기술적으로 부족한지 reviewer memo에 별도 칸으로 적어야 한다.

• 증상: 권한은 제거했는데 declaration 답변이 예전 상태다.
• 실패: manifest 변경과 정책 답변을 다른 릴리스 기준으로 관리한다.
• 증상: testing track artifact에만 READ_MEDIA 권한이 남아 있다.
• 실패: production만 보면 된다고 생각한다.
• 증상: account deletion 문구가 Data safety와 따로 논다.
• 실패: reviewer memo에 deletion 증거 칸이 없다.

영역	흔한 어긋남	왜 문제인가
Manifest	테스트 트랙 artifact에 권한이 남아 있음	심사 기준이 package 전반과 active version code를 본다
Declaration	custom picker를 broad access 정당화로 혼동	기술적 sufficiency 설명이 빠지면 답변 불일치가 생긴다
Data safety / deletion	동일 릴리스인데 답변과 경로가 따로 관리됨	정책 증거 묶음 전체 신뢰도가 떨어진다

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

가장 실무적인 방법은 reviewer memo 템플릿을 고정하는 것이다. 첫째 칸에는 manifest에서 READ_MEDIA 권한이 제거됐는지, 남아 있다면 왜 broad access가 core functionality인지 적는다. 둘째 칸에는 declaration 답변 상태와 Photo Picker 또는 broad access 기술 사유를 쓴다. 셋째 칸에는 Data safety 답변이 현재 package와 third-party SDK 동작에 맞는지 적는다. 넷째 칸에는 account deletion의 인앱 경로와 웹 링크를 적는다. 마지막 줄에는 이 네 칸을 검증한 artifact와 track 범위를 적는다.

1. merged manifest와 active version code 기준으로 READ_MEDIA 권한 상태를 확인한다.
2. Photo Picker 전환인지 broad access 유지인지 declaration 문구를 분리해 적는다.
3. Data safety form 답변을 current package 동작과 SDK 영향 기준으로 다시 맞춘다.
4. account deletion의 인앱 경로와 웹 링크 리소스를 같은 릴리스 기준으로 확인한다.
5. reviewer memo에 위 네 칸과 증거 artifact를 한 번에 남긴다.

중요한 점은 reviewer memo가 장문의 설득문이 아니라 불일치 제거 문서라는 것이다. 심사자가 빨리 확인할 수 있도록 '무엇을 바꿨나', '어디서 확인하나', '어떤 트랙까지 반영됐나'를 짧게 쓰는 편이 좋다. Photo Picker 전환이라면 broad access가 더 이상 core functionality가 아니라는 점이 보여야 하고, broad access 유지라면 왜 system picker가 기술적으로 부족한지 보여야 한다.

또 Data safety와 account deletion을 같은 memo에 넣는 이유는 둘 다 사용자 데이터 처리 증거이기 때문이다. 사진 선택 플로우를 바꾸면 수집 경로 설명이 달라질 수 있고, 계정 생성 앱이라면 deletion 경로 설명도 함께 최신 상태여야 한다. 이 둘이 어긋나면 reviewer 입장에서는 메모 전체 신뢰도가 떨어진다.

릴리스 체크 포인트

manifest_checked_all_tracks=true
read_media_removed=true
declaration_updated=true
data_safety_updated=true
third_party_sdk_reviewed=true
account_deletion_in_app_path_verified=true
account_deletion_web_link_verified=true
reviewer_memo_bundle_ready=true

정리하면 reviewer memo의 목적은 Photo Picker 전환 뒤 정책 증거가 한 릴리스 안에서 서로 모순되지 않음을 보여 주는 것이다. 네 칸만 고정해도 대부분의 누락이 줄어든다.

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

첫 공식 화면은 `READ_MEDIA_IMAGES`와 `READ_MEDIA_VIDEO`를 제거할 때 모든 version codes와 production·testing tracks를 같이 보라고 적은 부분이다. Photo Picker로 바꿨는데 한 트랙이나 한 artifact에 권한이 남아 있으면 reviewer memo의 첫 줄부터 틀어진다.

Photo Picker로 전환했다면 READ_MEDIA 권한 제거 범위는 모든 version codes와 production·testing tracks까지 함께 확인해야 한다.

이미 READ_MEDIA 유지 vs Photo Picker 전환 분기 글에서 정책 결정을 했다면, 이번 글은 그 결정을 reviewer memo에 어떻게 증거화할지 정리하는 후속편이다.

두 번째 자료는 custom picker가 있다고 해서 자동으로 broad permission 정당화가 되지 않는다는 정책 문구다. reviewer memo에는 '우리는 Photo Picker로 바꿨다' 또는 '왜 broad access가 아직 core functionality인지'를 기술적으로 분리해 적어야 한다.

custom picker는 자동 면제가 아니므로, reviewer memo에는 Photo Picker 전환 여부와 broad access 필요 사유를 분리해 적어야 한다.

이 문구를 빼먹으면 개발팀은 UI를 바꿨다고 생각하지만 심사자는 여전히 선언 불일치를 본다.

세 번째 자료는 Data safety form이 closed, open, production testing tracks까지 포함된다는 설명이다. Photo Picker 전환 뒤 manifest는 바꿨는데 Data safety 답변은 예전 broad access 전제를 남겨 두는 실수가 여기서 많이 나온다.

Data safety form은 testing tracks까지 포함되므로 reviewer memo에도 트랙 전반의 선언 일치 여부를 같이 남겨야 한다.

즉 manifest diff만으로는 끝나지 않는다. declaration과 Data safety 답변도 같은 package 기준으로 다시 맞춰야 한다.

네 번째 공식 자료는 account deletion 요구사항 중 웹 링크와 인앱 경로를 함께 제공해야 하는 부분이다. Photo Picker 전환과 직접 관련 없어 보여도, reviewer memo에서는 같은 릴리스의 정책 증거 묶음으로 같이 확인하는 편이 안전하다.

계정 생성 앱은 account deletion에 대해 인앱 경로와 웹 링크 리소스를 함께 제공해야 하므로 reviewer memo에 별도 칸이 필요하다.

특히 지난 글 account deletion 문구 정합성 글에서 다뤘듯이, Data safety와 deletion 답변이 서로 어긋나면 심사 대응 메모 전체 신뢰도가 떨어진다.

실무에서 유용한 것은 reviewer memo 표 자체다. 팀이 어떤 칸을 채워야 하는지 먼저 정해 두면 manifest 수정, declaration, Data safety, account deletion이 따로 노는 일을 줄일 수 있다.

Photo Picker 전환 뒤 reviewer memo에 함께 남기면 좋은 핵심 칸 예시다.

표를 고정하면 QA, 정책 담당자, 개발자가 서로 다른 용어로 같은 변경을 설명하는 혼선을 줄일 수 있다.

마지막 자료는 reviewer memo 텍스트 예시다. 정책 답변은 길게 쓰는 것보다 manifest, declaration, Data safety, deletion을 같은 release 단위로 맞춰 적는 것이 중요하다.

Photo Picker 전환 릴리스에 대해 reviewer에게 남길 수 있는 안전한 메모 예시다.

이 형식을 쓰면 심사 대응 메일, 내부 QA, 배포 체크리스트가 같은 근거를 바라보게 된다.

5. 주의사항과 리스크

첫 번째 리스크는 production 빌드만 보고 testing track artifact를 놓치는 것이다. 두 번째는 custom picker를 broad access 정당화와 같은 것으로 오해하는 것이다. 세 번째는 account deletion을 별도 운영 문서로만 두고 reviewer memo에서 빼는 것이다.

릴리스 전에 확인할 것은 manifest 범위, declaration 상태, Data safety 답변, deletion 경로다. 네 항목 중 하나라도 예전 상태를 유지하면 Photo Picker 전환 자체가 맞아도 심사 대응 설명은 어긋날 수 있다.

• 모든 version code와 tracks 범위를 같이 본다.
• custom picker와 broad access 자격을 혼동하지 않는다.
• Data safety와 account deletion을 같은 memo에 묶는다.

6. 결론

Photo Picker 전환 뒤 Google Play reviewer memo는 권한 제거 사실 하나만 적는 문서가 아니다. manifest, declaration, Data safety, account deletion을 같은 release 단위로 맞춰 적어야 심사자가 현재 package의 정책 상태를 빠르게 확인할 수 있다. 네 칸 템플릿을 고정하면 개발 변경과 정책 답변이 따로 노는 문제를 크게 줄일 수 있다.

• manifest와 declaration을 같은 문장으로 연결한다.
• Data safety와 deletion 답변도 같은 릴리스 기준으로 맞춘다.
• reviewer memo는 불일치 제거 문서로 본다.

reviewer 패키지를 실제 제출 묶음으로 더 다듬으려면 version code와 track 기준으로 reviewer package를 한 표로 다시 묶는 2026년 8월 22일 후속 글도 함께 보면 좋다. 이 글이 memo 안에 무엇을 같은 칸에 넣을지를 정리했다면, 후속 글은 그 메모를 어떤 build와 track 축으로 묶어 제출할지를 보여 준다.

7. 참고 링크

1. https://support.google.com/googleplay/android-developer/answer/15800983?hl=en
2. https://support.google.com/googleplay/android-developer/answer/16935362?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