본문으로 건너뛰기
AppFoyer
무료 시작

가이드 출시 이후

이미 게시된 스토어 등록정보의 URL 바꾸기

앱 게시 후 개인정보처리방침이나 삭제 페이지를 옮기는 방법. 깨진 링크를 남기지 않는 순서와, 이전 주소가 계속 응답해야 하는 이유.

Play Console과 App Store Connect의 URL 필드는 언제든 수정할 수 있습니다. 위험은 수정 자체가 아니라, 등록정보는 아직 이전 URL을 가리키는데 그 URL이 이미 죽어 있는 공백입니다. 새 주소를 먼저 게시하고, 등록정보를 업데이트하고, 이전 주소는 계속 리디렉션되게 두세요.

1:11
1:11 영상 · YouTube에서 열림

대신 몇 분 만에 끝내세요

AppFoyer는 이 가이드가 다루는 페이지, 즉 개인정보처리방침, 이용약관, 지원, 계정 삭제 페이지와 app-ads.txt를 전용 하위 도메인에서 호스팅합니다. 직접 도메인이나 서버를 둘 필요가 없습니다. 앱 하나는 무료이며, 스토어가 요구하는 것은 무엇도 유료로 막아 두지 않습니다.

무료로 시작하기 실제 예시 보기

2026년 9월 19일 확인. 스토어 정책은 바뀌며, 예고 없이 바뀌기도 합니다. 아래의 모든 내용은 공식 문서로 연결되며, 권위를 갖는 것은 이 페이지가 아니라 그 문서입니다. 둘이 다르면 스토어가 맞습니다. 이 가이드는 영어 원문을 번역한 것이며, 스토어 문서의 인용문은 영어 원문 그대로 두었습니다.

언젠가는 옮기게 됩니다. 무료 호스트가 서비스를 종료하거나, 도메인이 만료되거나, 회사 이름이 바뀌거나, 늘 만들려던 제대로 된 사이트를 만들었을 때입니다. 필드는 수정할 수 있으므로 변경 자체는 간단합니다. 사람들이 걸리는 것은 조용히 이전 주소를 가리키고 있는 나머지 모든 것입니다.

아무것도 깨뜨리지 않는 순서

  1. 새 URL을 게시하고 로그아웃 상태에서 확인합니다. 무엇이든 그것을 가리키기 전에 살아 있어야 합니다.
  2. 이전 주소가 새 주소로 리디렉션되게 합니다. 삭제가 아니라 리디렉션입니다. 사람들이 건너뛰는 단계이며, 여러분을 구해 주는 단계입니다.
  3. 콘솔 필드를 업데이트합니다. 개인정보처리방침과 데이터 삭제 URL은 Play Console → App content에서, 개인정보처리방침과 Support URL은 App Store Connect에서. Google Play는 방침이 “is available on an active URL” (번역: 활성 URL에서 이용 가능해야 함)일 것을 요구합니다. 따라서 필드는 잠깐이라도 죽은 곳을 가리켜서는 안 됩니다.
  4. 앱 안의 링크를 업데이트합니다. Play의 User Data 정책은 Play Console 그리고 앱 자체 안에 개인정보처리방침 링크를 요구하며, 앱 안의 링크는 대개 몇 달 전에 출시한 빌드에 하드코딩되어 있습니다. 이전 버전 사용자는 업데이트할 때까지 계속 이전 URL로 가며, 일부는 끝내 업데이트하지 않습니다.
  5. 리디렉션을 그대로 둡니다. 일주일이 아니라, 가능하다면 무기한으로.

다른 순서로 하면, 즉 필드를 먼저 바꾸거나 이전 호스트를 먼저 삭제하면, 검토가 진행되는 동안 게시된 등록정보가 404를 가리키는 상황이 됩니다.

이전 주소가 계속 응답해야 하는 이유

콘솔 필드는 여러분이 관리하는 주소입니다. 하지만 이전 URL이 존재하는 곳은 그곳만이 아닙니다.

  • 출시된 앱 바이너리. 이전 모든 버전의 설치된 모든 사본이 이전 URL로 연결됩니다. 여러분은 이것을 업데이트할 수 없습니다. 사용자가 언젠가 업데이트하며, 일부는 끝내 하지 않습니다.
  • 스토어 등록정보 캐시와 애그리게이터 사이트. 여러분의 등록정보를 수집한 곳들입니다.
  • 이미 보낸 이메일과 영수증.
  • 광고 네트워크 기록. 이전 호스트가 선언된 개발자 웹사이트였다면 해당됩니다.

그러니 “이전 URL은 죽었지만 필드는 업데이트했다”는 여러분 쪽에서만 맞는 말입니다.

예외: app-ads.txt는 리디렉션하면 안 됩니다

특별한 경우가 하나 있으며, 조용히 돈을 잃게 만드는 경우입니다. 광고 네트워크는 스토어 등록정보에 있는 웹사이트의 루트에서 /app-ads.txt를 가져오며, 사양은 이 파일이 직접 제공될 것을 기대합니다. 그 앞에 리디렉션이 있으면 파일이 완벽하게 올바르더라도 “not found” 결과의 흔한 원인이 됩니다.

따라서 이전 호스트가 선언된 개발자 웹사이트였고 이를 리디렉션용으로 유지한다면, 이전 주소가 아직 크롤링될 수 있는 동안에는 그 호스트의 /app-ads.txt를 리디렉션하지 말고 200으로 제공해야 합니다. 나머지는 모두 301로 보내도 되지만, 그 경로 하나만은 안 됩니다.

이전 후 확인할 것

시크릿 창에서, 로그아웃한 상태로 다음을 실행하세요.

curl -i https://old-host.example/privacy        # expect 301 to the new URL
curl -i https://new-host.example/privacy        # expect 200
curl -i https://old-host.example/app-ads.txt    # expect 200 text/plain, NOT a redirect

그런 다음 콘솔에서 확인합니다. 모든 URL 필드가 올바른 페이지를 열고, Data safety / App Privacy 답변이 여전히 새 페이지의 내용과 일치하는지. 페이지를 옮기는 것은 방침이 SDK 두 개 전부터 낡아 있었다는 것을 알아차리기에 좋은 기회입니다.

쉽게 되돌릴 수 없는 변경

URL은 설정이 아니라 정체성입니다. 한 번 스토어 등록정보에 들어가면 여러분이 관리하지 않는 곳들에 존재하게 되므로, 옮기는 일은 계속 유지할 주소로 한 번, 신중하게 할 가치가 있습니다. 어떤 호스트든 그 URL을 콘솔 필드에 붙여 넣기 전에 물어야 할 질문은 “무료인가”가 아니라 “이 정확한 주소가 2년 뒤에도 응답할 것인가, 그렇지 않다면 리디렉션할 수 있는가”입니다.

AppFoyer가 하는 일

바로 이 문제를 중심으로 두 가지가 만들어져 있습니다.

앱의 무작위 주소는 영구적입니다. 모든 앱은 생성 시 app-xxxxxx.appfoyer.page를 받으며, 이 주소는 절대 바뀌지 않습니다. 나중에 유료 플랜에서 커스텀 서브도메인을 지정하더라도 원래 주소는 리디렉션 없이, 만료 없이 같은 사이트로 계속 응답합니다. 1년 전에 콘솔 필드에 붙여 넣은 주소가 무언가의 이름을 바꿨다고 해서 작동을 멈추지 않습니다.

교체한 커스텀 서브도메인은 즉시 해제됩니다. 하나를 교체하면 이전 주소는 리디렉션 없이 즉시 응답을 멈추고, 다른 계정을 포함해 누구나 그 주소를 가져갈 수 있습니다. 따라서 나중에 바꿀 수도 있는 등록정보에는 커스텀 서브도메인을 넣지 마세요. 계속 작동하는 것이 보장되는 주소는 위의 영구 주소입니다.

그리고 영구 주소는 리디렉션하는 대신 사이트 자체를 제공하므로, /app-ads.txt는 현재 주소에서뿐 아니라 그곳에서도 200으로 응답합니다. 위의 규칙이 별도 설정 없이 지켜집니다.

공식 출처