[Google Play][정책] account deletion 링크는 맞는데 Data safety 보관·삭제 설명이 어긋날 때 어떤 문장부터 다시 맞추나

IT 리서치 노트

[Google Play][정책] account deletion 링크는 맞는데 Data safety 보관·삭제 설명이 어긋날 때 어떤 문장부터 다시 맞추나

Google Play에서 account deletion 링크는 정상인데 Data safety 보관·삭제 설명과 privacy policy 문장이 어긋나면 reviewer는 링크 오류보다 disclosure 불일치로 본다. 2026년 8월 19일 기준 Google Play 공식 도움말을 다시 보면 account deletion 요구사항은 Data deletion questions, 외부 web resource, in-app path, Data safety form, privacy policy의 data retention and deletion policy가 함께 맞아야 한다. 이 글은 account deletion 링크는 맞는데 보관·삭제 설명이 어긋날 때 어떤 문장부터 다시 맞춰야 하는지 정리한다.

목차

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

1. 개요

결론부터 말하면 Google Play account deletion 불일치는 외부 deletion URL 기능 확인 → privacy policy의 retention/deletion 문장 확인 → Data safety deletion mechanism 답변 확인 → SDK 자동 수집 범위 반영 → store listing 노출 문구 재검토 순으로 가는 편이 가장 빠르다. 링크가 열리는 것만으로는 정책 일치가 끝나지 않는다.

즉 reviewer가 보는 것은 URL 존재 여부가 아니라, 삭제 요청 경로와 보관 예외 설명, Data safety 답변, SDK 데이터 범위가 같은 사실을 말하고 있는지다. broken link 수정과 문장 정합성 수정은 같은 티켓 안에 있어도 원인 분기는 अलग게 해야 한다.

만약 지금 팀 이슈가 READ_MEDIA_IMAGES, READ_MEDIA_VIDEO, Photo Picker 전환 여부처럼 broad media permission 축까지 함께 얽혀 있다면, 후속 글인 [Google Play][정책] READ_MEDIA_IMAGES·VIDEO를 유지할지 Photo Picker로 바꿀지 결정한 뒤 Data safety와 account deletion 답변을 왜 따로 다시 맞추나를 같이 보는 편이 빠르다. 이 글은 account deletion과 보관·삭제 문장 정합성에 집중하고, 후속 글은 photo/video permission 분기와 declaration 패키지까지 묶어서 설명한다.

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

실무에서 반복되는 막힘은 네 가지다. 첫째, account deletion 링크는 열리는데 사용자가 실제 삭제 요청 경로를 바로 찾지 못한다. 둘째, privacy policy에는 retention 예외가 남아 있는데 Data safety form은 삭제 요청 가능만 체크해 두어, reviewer가 “무엇을 언제까지 남기는가”를 다시 묻게 된다. 셋째, SDK가 수집하는 diagnostics나 identifiers가 Data safety에는 누락돼 있는데 account deletion 문구는 앱 코드 기준으로만 써 놓아 범위가 서로 다르게 보인다. 넷째, in-app path와 외부 web resource가 존재해도 store listing의 Data deletion 영역과 policy 문장이 같은 vocabulary를 쓰지 않아 사용자가 혼란을 겪는다.

Google Play account deletion 도움말은 account creation이 있는 앱이라면 Data deletion questions를 Data safety form에 답해야 하고, in-app path와 외부 web resource를 제공해야 한다고 적는다. Data safety 도움말은 third-party SDK를 통한 데이터 수집·공유도 반영해야 한다고 설명한다. User Data policy 요약은 privacy policy 안에 retention and deletion policy가 포함되어야 하며, account deletion 요청 시 associated data 삭제와 retention 예외를 명확히 알려야 한다고 못 박는다. 이 셋을 합치면 문제는 링크 하나가 아니라 문장 세트다.

특히 rejection 대응에서 흔한 실수는 URL을 고치고 바로 재제출하는 것이다. 하지만 policy 문장과 Data safety 답변이 그대로면 reviewer는 같은 불일치를 다시 본다. 따라서 수정은 URL 기능 확인, retention 예외 문장 정리, Data safety 답변 정리, SDK 범위 확인, store listing 노출 확인 순서로 가야 한다. 한 단계라도 빠지면 사용자는 삭제는 가능해 보여도 실제로 무엇이 지워지고 무엇이 법적 이유로 남는지 이해하지 못한다.

• 증상: deletion 링크는 열리는데 reviewer가 여전히 정책 불일치를 지적한다.
• 오류: retention 예외를 privacy policy에만 두고 Data safety에는 안 반영한다.
• 실패: SDK 자동 수집 범위를 deletion 설명에서 빼먹는다.
• 재발: URL 수정 후 policy·badge·form 답변을 다시 안 맞춘다.

불일치 장면	먼저 볼 문장	왜 중요한가
링크는 열리지만 reviewer 재질문	privacy policy retention/deletion	무엇이 남는지 설명이 없으면 정책 일치가 깨진다
Data safety만 수정함	external URL + in-app path 문장	사용자 제어 경로가 store listing과 달라 보인다
SDK 범위 지적	SDK data scope 문장	자동 수집 데이터가 deletion 범위와 어긋나기 쉽다

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

가장 실용적인 수정 순서는 다섯 단계다. 1단계에서 external deletion URL이 실제로 열리고, app 또는 developer 이름이 일치하며, 삭제 요청 경로가 눈에 띄는지 본다. 2단계에서 privacy policy의 retention and deletion policy 문장을 읽고, 삭제 즉시 지워지는 데이터와 법적·보안 이유로 남기는 데이터를 명시한다. 3단계에서 Data safety form의 deletion mechanism 답변과 Data deletion questions를 같은 표현으로 수정한다. 4단계에서 third-party SDK의 data scope를 다시 확인해 diagnostics, identifiers, crash logs 같은 자동 수집 항목을 반영한다. 5단계에서 store listing badge와 reviewer 제출 메모를 갱신한다.

1. external deletion URL이 실제 삭제 요청 경로를 보여 주는지 확인한다.
2. privacy policy의 retention and deletion policy 문장을 먼저 손본다.
3. Data safety deletion mechanism 답변을 같은 표현으로 맞춘다.
4. SDK 자동 수집 범위를 다시 인벤토리화한다.
5. store listing 노출과 reviewer diff 메모를 갱신한다.

reviewer 패키지 메모 예시

deletion_url_checked=true
in_app_path_checked=true
retention_exception=fraud-prevention logs retained for 30 days
privacy_policy_updated=true
data_safety_questions_updated=true
sdk_scope_rechecked=analytics_sdk diagnostics
store_listing_badge_expected=data deletion available

이 순서대로 가면 URL 기능 수정과 policy 문장 수정이 자연스럽게 분리된다. 운영자는 링크를 열고, 문장을 수정하고, Data safety를 저장하고, SDK 범위를 다시 보고, reviewer 메모를 남기면 된다. “링크는 맞는데 왜 또 반려되지?”라는 질문을 “어느 문장 세트가 아직 다르게 말하고 있지?”로 바꾸는 것이 핵심이다.

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

첫 공식 화면은 account deletion이 store listing과 Data safety form에 함께 걸린다는 문장이다. Google Play는 app이 account creation을 제공한다면 Data deletion questions를 Data safety form에 답하고, in-app 경로와 외부 web resource를 모두 제공해야 한다고 적는다. 따라서 링크가 열리기만 한다고 끝나는 문제가 아니다.

account deletion 요구사항은 Data safety form의 Data deletion questions와 함께 관리해야 하며, in-app과 외부 web resource 경로가 모두 필요할 수 있다.

이미 SDK 변경 뒤 Data safety와 User Data policy를 맞추는 글이 disclosure 인벤토리 출발점을 다뤘다면, 이번 글은 그중에서도 account deletion 문구가 따로 놀 때 어떤 문장부터 다시 고칠지를 좁힌 후속판이다.

두 번째 공식 화면은 Data safety 범위다. Google Play는 앱이 직접 수집·공유하는 데이터뿐 아니라 third-party libraries or SDKs를 통해 수집·공유되는 데이터도 정확히 반영해야 한다고 설명한다. account deletion 링크는 맞는데 Data safety 보관·삭제 설명이 어긋날 때, 이 SDK 범위 누락이 자주 원인으로 남는다.

Data safety는 앱 코드뿐 아니라 third-party libraries or SDKs가 수집·공유하는 데이터까지 반영해야 한다.

즉 deletion 링크만 열어 두고 실제 보관 데이터 범위를 안 고치면 reviewer는 쉽게 불일치를 잡아낸다. 어떤 데이터가 남고 어떤 데이터가 삭제 요청 대상인지, SDK 자동 수집분까지 같은 표에서 다시 보아야 한다.

세 번째 공식 화면은 privacy policy 내용 자체다. User Data policy 요약은 privacy policy에 developer의 data retention and deletion policy가 명시되어야 하고, account deletion 요청 시 associated user data를 삭제해야 하며, 합법적 이유로 보관하는 데이터가 있다면 이를 분명히 설명하라고 적는다.

privacy policy에는 data retention and deletion policy가 포함되어야 하며, account deletion 후 남기는 데이터가 있다면 그 이유를 명확히 설명해야 한다.

이 문장 덕분에 수정 순서가 보인다. broken link를 고치는 문제와 보관·삭제 문장을 고치는 문제를 섞지 말고, 정책 문장과 Data safety 답변을 같은 vocabulary로 다시 맞추는 편이 빠르다.

실무에서는 문장 매핑표가 필요하다. store listing에서 보이는 account deletion 안내, privacy policy 보관 문장, Data safety의 deletion mechanism 답변을 한 줄씩 맞춰 두면 reviewer 패키지가 훨씬 짧아진다.

account deletion 링크, privacy policy, Data safety 답변을 한 문장 단위로 맞추는 매핑표다.

특히 scope가 넓은 OAuth·Play reviewer 대응을 함께 하는 팀이라면 current scope diff 증빙 글처럼 current state를 먼저 기록하고 제출 패키지를 그 상태에 맞추는 방식이 여기서도 그대로 통한다.

마지막 자료는 reviewer diff 메모다. 어떤 문장을 어떻게 바꿨는지, retention 예외를 어디에 넣었는지, deletion URL이 무엇인지 텍스트로 남겨 두면 rejection 이후 대응이 빨라진다.

Google Play account deletion 문구 불일치 점검에 바로 쓸 수 있는 diff 메모 예시다.

이런 메모를 남기면 링크 수정, privacy policy 수정, Data safety 답변 수정, app build 변경을 서로 다른 커밋이나 티켓으로 분리하기 쉬워진다. 단순히 URL만 고치고 끝내는 실수를 막는 데도 도움이 된다. broad media permission 유지 여부나 Photo Picker 전환 결정까지 동시에 정리해야 한다면, 위 메모에 permission 결정 칸을 하나 더 추가하고 후속 글의 체크리스트를 같이 붙여 두면 reviewer 패키지 재사용이 쉬워진다.

5. 주의사항과 리스크

첫 번째 리스크는 external deletion URL이 열리기만 하면 요건을 충족했다고 믿는 것이다. 사용자가 실제 삭제 요청 경로를 찾지 못하거나, app 또는 developer 이름이 안 맞으면 reviewer는 여전히 불일치로 본다. 두 번째는 retention 예외를 policy에만 두고 Data safety에는 안 넣어, 삭제 범위가 더 넓거나 좁게 보이게 만드는 것이다. 세 번째는 SDK 자동 수집 범위를 앱 코드 기준 문장에 포함하지 않아, reviewer가 store listing과 실제 데이터 흐름을 다르게 읽게 만드는 것이다.

운영 문서에는 최소한 deletion URL, in-app path, retention 예외, Data safety deletion mechanism, SDK scope, reviewer 제출 시각을 함께 남겨 두는 편이 좋다. 그래야 다음 업데이트 때도 URL, policy, form 세 축이 동시에 움직이는지 짧게 점검할 수 있다.

• 링크 존재와 정책 일치는 같은 문제가 아니다.
• retention 예외는 privacy policy와 Data safety에서 같은 의미로 보여야 한다.
• SDK 자동 수집 범위까지 deletion 설명에 포함해야 reviewer 패키지가 닫힌다.

6. 결론

Google Play account deletion 불일치는 URL 하나보다 문장 세트 문제에 가깝다. external deletion URL, privacy policy의 retention/deletion policy, Data safety deletion mechanism, SDK scope가 같은 사실을 말하도록 다시 맞추면 reviewer 대응이 훨씬 짧아진다. 링크가 맞더라도 문장이 다르면 store listing은 계속 흔들린다.

실무에서는 Play Console에서 Data safety 답변을 먼저 확인하고, deletion URL을 직접 클릭해 경로를 조회하고, privacy policy 문장을 입력·수정한 뒤 reviewer 제출 메모 파일에 retention 예외와 SDK 범위를 저장한다. 그다음 앱 화면에서 account deletion 버튼을 실행하고, 응답 화면과 오류 로그를 확인하고, 콘솔 제출 직전에 같은 문장을 다시 복사해 비교하면 재심사 반복을 줄이기 쉽다. 여기에 photo/video permission 검토가 남아 있다면 후속 글 순서대로 manifest, declaration, Data safety, account deletion을 한 번에 재점검하면 된다.

• external deletion URL은 기능과 discoverability를 같이 본다.
• retention/deletion policy 문장을 먼저 고친 뒤 Data safety를 맞춘다.
• SDK 자동 수집 범위까지 같은 vocabulary로 반영한다.

7. 참고 링크

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