Google Play가 요구하는 계정 삭제 URL
Play Console은 App content → Data deletion에서 공개 웹 URL을 요구합니다. 그 페이지가 로그인 없이 사용자에게 무엇을 할 수 있게 해야 하는지, 그리고 제출이 반려되는 실수를 설명합니다.
Google Play는 계정이 있는 앱에 두 가지 삭제 경로를 요구합니다. 하나는 앱 안에, 다른 하나는 로그인하거나 다시 설치하지 않고도 같은 요청을 할 수 있는 공개 웹 URL입니다. 웹 URL은 App content → Data deletion에서 신고합니다. 페이지는 요청을 받는 역할을 하며, 자체 시스템에서 데이터를 삭제하는 일은 여전히 개발자의 몫입니다.
대신 몇 분 만에 끝내세요
AppFoyer는 이 가이드가 다루는 페이지, 즉 개인정보처리방침, 이용약관, 지원, 계정 삭제 페이지와 app-ads.txt를 전용 하위 도메인에서 호스팅합니다. 직접 도메인이나 서버를 둘 필요가 없습니다. 앱 하나는 무료이며, 스토어가 요구하는 것은 무엇도 유료로 막아 두지 않습니다.
2026년 9월 19일 확인. 스토어 정책은 바뀌며, 예고 없이 바뀌기도 합니다. 아래의 모든 내용은 공식 문서로 연결되며, 권위를 갖는 것은 이 페이지가 아니라 그 문서입니다. 둘이 다르면 스토어가 맞습니다. 이 가이드는 영어 원문을 번역한 것이며, 스토어 문서의 인용문은 영어 원문 그대로 두었습니다.
앱에서 사람들이 계정을 만들 수 있다면, Google Play는 그 계정을 삭제하는 두 가지 경로를 요구합니다. 하나는 앱 안에, 다른 하나는 같은 요청을 할 수 있는 공개적으로 접근 가능한 웹 URL입니다. 웹 URL은 Play Console의 App content → Data deletion(앱 콘텐츠 → 데이터 삭제)에서 신고하며, Google Play 고객센터는 그 URL이 “must be functional (for example, loads without error), relevant in scope”(번역: 작동해야 하며(예: 오류 없이 로드됨), 범위에 맞아야 합니다)라고 명시합니다. 이미 앱을 제거한 사람도 이 URL을 사용할 수 있어야 합니다.
한 문단으로 정리하면 이것이 요구사항입니다. 이 페이지의 나머지는 페이지 자체가 해야 하는 일과, 제출이 반려되는 실수에 관한 것입니다.
여기서는 두 가지가 요구되며, 혼동하기 쉽습니다.
- 요청을 제출할 수 있는 공개 페이지.
- 요청이 도착했을 때 자체 시스템에서 실제로 데이터를 삭제하는 것.
첫 번째는 호스팅 문제입니다. 두 번째는 오로지 개발자의 몫이며, 어떤 서비스도 대신해 줄 수 없습니다. 다르게 말하는 곳이 있다면, 그곳은 개발자의 데이터베이스에 접근할 수 없습니다.
페이지가 사용자에게 할 수 있게 해야 하는 일
요구사항은 사용자의 입장에서 쓰여 있으므로, 그 입장에서 읽으십시오. 앱을 제거했거나, 비밀번호를 잊었거나, 애초에 비밀번호가 없었던 사람도 여전히 페이지에 접근해 계정 삭제를 요청할 수 있어야 합니다.
그래서 흔한 몇 가지 구성은 제외됩니다.
- 로그인이 필요한 페이지. 삭제를 요청하려면 로그인해야 한다면, 그 기능이 가장 필요한 사람들이 사용할 수 없습니다.
- 앱 안의 경로만 있는 경우. 앱 내 경로도 필수이지만, 웹 URL을 대신하지는 못합니다. 웹 URL은 더 이상 앱이 없는 사람도 스토어 등록정보에서 접근할 수 있습니다.
- 404가 나는 URL. 확인하기가 아주 쉬워서 실제로 걸리는 것은 바로 이것입니다.
페이지에는 어떤 데이터가 삭제되는지, 무엇이 얼마 동안 보관되는지(결제 기록은 법에 따라 보관해야 하는 경우가 많습니다), 삭제에 얼마나 걸리는지를 적어야 합니다.
사람들이 틀리는 부분: 요청 받기
양식을 표시하는 페이지만으로는 충분하지 않습니다. 요청이 개발자에게 도달해야 합니다.
이것은 단순한 파일 호스트가 혼자서는 할 수 없는 유일한 부분입니다. GitHub Pages, CDN 뒤의 버킷은 파일을 제공할 뿐 POST를 받을 수 없습니다. 개발자가 실제로 고를 만한 대부분의 호스트는 이를 해결합니다. Cloudflare Workers, Netlify와 Vercel 함수, Netlify Forms 등이 있으므로 이것은 넘을 수 없는 벽이 아니라 연결 작업입니다. 하지만 무언가가 요청을 받아야 하며, 흔한 직접 구축 방식은 다음 네 가지 중 하나로 귀결됩니다.
- 페이지에 적힌 이메일 주소. 수집되는 것을 막을 방법이 없습니다.
- 서드파티 양식 서비스. 이제 그 서비스가 사용자의 이메일 주소를 보게 됩니다.
- 호스트의 엣지 함수. 몇 줄이면 되지만, 이제 모든 앱에서 직접 관리해야 하는 코드가 됩니다.
- 1년에 두 건일 수도 있는 요청을 위해 계속 운영해야 하는 작은 서버.
무엇을 고르든 의도적으로 결정하십시오. 요청을 조용히 버리는 삭제 페이지는 없는 것보다 나쁩니다. 사용자에게 요청이 접수되었다고 말하고 있기 때문입니다.
기록 남기기
무엇을 만들든 요청 기록을 남기십시오. 주소, 날짜, 어떻게 처리했는지입니다. 규제 기관이나 스토어가 물어본다면, “삭제했습니다”는 주장이고 날짜가 적힌 목록은 증거입니다.
AppFoyer가 여기서 하는 일
저희는 페이지를 호스팅하고 요청을 전달합니다. 사용자가 요청을 제출하면 저희가 감사 기록으로 저장하고, 알림을 보내 드립니다. 모든 요금제에서는 이메일로, 유료 요금제에서는 Telegram이나 Slack으로도 보냅니다. 삭제는 개발자가 자체 시스템에서 직접 합니다. 저희는 그 시스템에 접근할 수 없으며, 접근할 수 있다고 주장하지도 않습니다.
저희에게 결제를 중단하더라도 그 페이지는 온라인 상태로 유지됩니다. 사용자는 그 일과 아무 관련이 없기 때문입니다.
공식 출처
- Provide information about data deletion — Google Play 고객센터. 제출하기 전에 읽으십시오. 결정하는 것은 이 페이지가 아니라 그 페이지입니다.