[Google Play][정책] Photo Picker로 바꾼 뒤 reviewer 패키지를 version code와 track 기준으로 다시 묶을 때 무엇을 한 표로 남기나

IT 리서치 노트

[Google Play][정책] Photo Picker로 바꾼 뒤 reviewer 패키지를 version code와 track 기준으로 다시 묶을 때 무엇을 한 표로 남기나

Google Play에서 Photo Picker로 전환한 뒤에도 reviewer 질문이 반복될 때가 있다. 2026년 8월 22일 기준 Play 정책 문서는 `READ_MEDIA_IMAGES`와 `READ_MEDIA_VIDEO`를 submission 안의 모든 version code에서 제거하라고 하고, production과 testing tracks를 함께 언급한다. 또 internal test는 closed/open test와 동시에 존재할 수 있고, 사용자는 eligible track 안에서 가장 높은 version code를 받는다. 그래서 reviewer 패키지는 단순한 manifest 메모가 아니라 version code와 track 기준의 한 표로 다시 묶는 편이 낫다. 이 글은 그 표에 무엇을 넣을지 정리한다.

목차

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

1. 개요

결론부터 말하면 Photo Picker 전환 뒤 reviewer 패키지는 version code, track, 권한 제거 상태, Photo Picker 대체 흐름, reviewer 재현 경로를 한 표에 같이 넣는 편이 가장 안전하다. 정책은 submission 안의 모든 version code와 production/testing tracks를 함께 본다.

즉 reviewer note는 '권한을 제거했다'는 선언보다 '어느 track의 어느 version code가 현재 어떤 상태인가'를 보여 주는 문서여야 한다. 그래야 internal, closed, production이 동시에 존재할 때도 불필요한 왕복을 줄일 수 있다. 여기에 reviewer 로그인 계정과 country, deletion path까지 한 표에 올리는 흐름은 reviewer 계정과 country·track 증거를 같이 남기는 후속 글에서 바로 이어진다.

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

실무에서 자주 막히는 지점은 메모가 기능 설명 중심으로만 쓰이고, track과 version code 축이 빠지는 것이다. 개발자는 최신 production build만 머릿속에 떠올리지만, reviewer는 submission 전체와 test track까지 함께 본다.

또 Photo Picker 전환은 단순히 권한 한 줄 삭제가 아니다. 정책 문서가 말하듯 최소 범위 대안이 충분하면 민감 권한을 보유하지 말아야 한다는 방향 전환이므로, reviewer 패키지에는 '어떤 화면이 어떤 대안 흐름으로 바뀌었는가'가 드러나야 한다.

그리고 testing track이 여러 개 살아 있으면 혼선이 더 커진다. internal test는 closed/open과 동시에 돌 수 있고, 사용자는 eligible track 중 가장 높은 version code를 받을 수 있다. 이 구조를 설명하지 않으면 reviewer가 어느 빌드를 기준으로 봐야 하는지 다시 물을 가능성이 높다.

• version code 없이 track만 적으면 어느 빌드를 말하는지 अस्पष्ट해진다.
• track 없이 manifest diff만 적으면 submission 전체 정합성을 설명하지 못한다.
• Photo Picker 대체 흐름을 빼면 '권한 삭제가 기능을 깨지 않았는가' 질문이 남는다.

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

가장 실무적인 묶음은 한 표 + 한 문단이다. 표에는 version code, track, READ_MEDIA 상태, Photo Picker 적용 흐름, reviewer test path를 적고, 문단에는 '모든 version code에서 권한을 제거했고 각 track에서 어떤 build가 현재 대상인지'를 짧게 정리한다. reviewer가 표를 열자마자 어떤 빌드를 확인하고 어떤 메뉴를 클릭하고 어떤 응답을 기대해야 하는지 보여 주는 것이 목적이다.

1. 먼저 submission 안의 active version code와 track을 조회해 적는다.
2. 다음으로 각 build에서 READ_MEDIA 권한 제거 상태를 확인하고 표에 저장한다.
3. 이어서 Photo Picker로 바뀐 사용자 흐름과 메뉴 경로를 적고 reviewer test path를 확인한다.
4. 마지막으로 reviewer가 로그인 후 어디를 클릭하고 어떤 화면 응답을 봐야 하는지 note에 저장한다.

Reviewer 패키지 최소 필드

version_code
track
permission_removed
photo_picker_screen
reviewer_login_path
data_safety_status
account_deletion_status

핵심은 policy 증거와 reviewer 재현 경로를 같은 문서에 두는 것이다. 기술적 수정이 있었더라도 reviewer가 어떤 build를 어디서 확인할지 모르면 다시 질문이 온다. version code와 track 기준 표는 그 왕복을 줄여 준다.

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

첫 번째 공식 자료는 `READ_MEDIA_IMAGES`와 `READ_MEDIA_VIDEO`를 submission 안의 모든 version code에서 제거하라는 문장이다. 여기서 production과 testing tracks가 함께 언급된다.

Photo Picker 전환 뒤에는 submission 안의 모든 version code와 track을 함께 설명해야 한다.

즉 reviewer 메모는 단순히 '최신 빌드에서 권한을 뺐다'로 끝나면 부족하다. 어떤 version code가 어떤 track에 남아 있는지 같이 묶어야 한다.

두 번째 자료는 Photo Picker 같은 최소 범위 대안을 먼저 써야 한다는 정책 문구다. reviewer는 단순 코드 수정이 아니라 권한 전략 전체가 바뀌었는지 보게 된다.

최소 범위 대안이 충분하면 민감 권한을 요청하지 말아야 하므로 reviewer 패키지에는 권한 전략 변화가 드러나야 한다.

그래서 reviewer 패키지에는 manifest diff만이 아니라 어떤 사용자 흐름이 Photo Picker로 대체됐는지도 짧게 적는 편이 좋다. READ_MEDIA와 Photo Picker 결정 글의 다음 단계가 바로 이 묶음이다.

세 번째 공식 자료는 internal tests가 closed와 open tests와 동시에 돌아갈 수 있다는 문장이다. track이 여러 개 살아 있으면 reviewer 패키지도 track 단위로 나눠 적어야 한다.

internal test가 closed/open test와 동시에 존재할 수 있으므로 reviewer 패키지에는 track별 version code 상태가 보여야 한다.

track을 한 줄로 뭉개면 '어느 track에 아직 옛 권한이 남아 있나'를 reviewer가 다시 물을 가능성이 높다.

네 번째 자료는 version code 규칙을 reviewer 패키지 표에 옮긴 보조 자료다. 어떤 tester가 어떤 빌드를 받는지 설명할 때 version code 축이 먼저 와야 한다.

reviewer 패키지는 version code와 eligible track 기준으로 읽히도록 구성하는 편이 안전하다.

이 정리표를 함께 적으면 '왜 internal build는 괜찮은데 production에서 계속 걸리나'를 한 장 표로 설명하기 쉬워진다. reviewer memo 템플릿 글을 읽었다면 이번 글은 그 메모를 version code와 track 기준으로 재구성한 버전이다.

실제로는 reviewer가 한 번에 이해할 표가 필요하다. manifest, declaration, Data safety, account deletion만 나열하지 말고 version code와 track에 매달아 묶는 편이 낫다.

Photo Picker 전환 뒤 reviewer 패키지에 넣기 좋은 version code·track 기준 표 예시다.

이 표를 쓰면 어느 build가 권한을 제거했고 어떤 track이 아직 살아 있는지 한 번에 설명된다.

마지막 자료는 reviewer note 예시다. 한 표와 함께 짧은 설명 문장을 붙이면 불필요한 왕복을 줄일 수 있다.

version code와 track 중심으로 다시 쓴 reviewer note 예시다.

여기서 중요한 것은 기술 변경, track 배치, reviewer 재현 경로를 한 문단 안에 같이 담는 것이다.

5. 주의사항과 리스크

첫 번째 리스크는 최신 production build만 적고 test track을 생략하는 것이다. 정책 문서가 production과 testing tracks를 함께 언급하는 이상, active test track이 있다면 reviewer 패키지에도 같이 보여 주는 편이 안전하다.

두 번째 리스크는 Photo Picker 대체 흐름을 설명하지 않는 것이다. reviewer는 권한을 뺐다는 사실뿐 아니라 기능이 어떤 경로로 계속 동작하는지도 확인하려 한다. 그래서 최소 한두 개의 핵심 사용자 흐름은 써 두는 편이 좋다.

세 번째 리스크는 Data safety와 account deletion 정합성을 reviewer package와 따로 관리하는 것이다. 이 branch의 이전 글들처럼 제출 묶음은 한 번에 같이 읽히므로, note 안에서 현재 답변 상태를 짧게라도 같이 언급하는 편이 낫다.

6. 결론

Photo Picker로 바꾼 뒤 reviewer 패키지를 다시 묶을 때는 version code와 track을 표의 첫 열로 두는 편이 가장 안전하다. 정책은 submission 전체와 production/testing tracks를 함께 보고, tester는 eligible track 안의 가장 높은 version code를 받기 때문이다.

같은 Google Play branch를 이어 읽는다면 READ_MEDIA와 Photo Picker 결정 글, reviewer memo 템플릿 글, 그리고 reviewer 계정과 country·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=ko
3. https://support.google.com/googleplay/android-developer/answer/9845334?hl=en