앱 열 개의 규정 준수를 정확하게 유지하기
정말로 앱마다 따로 있어야 하는 것, 공유할 수 있는 것, 포트폴리오가 저지르는 두 가지 실수, 그리고 매년의 공황을 반나절 작업으로 바꾸는 관리 대장.
작업량은 앱 수에 비례해 줄어들지 않습니다. 각 앱에는 자체 스토어 등록정보가 있으므로 자체 URL, 자체 삭제 경로, 자체 신고가 필요합니다. 규모에 맞게 확장되는 것은 방법입니다. 하나의 호스트 이름 패턴, 페이지 유형별 템플릿 하나, 그리고 기억하는 대신 다시 생성하는 앱별 종속성 목록.
대신 몇 분 만에 끝내세요
AppFoyer는 이 가이드가 다루는 페이지, 즉 개인정보처리방침, 이용약관, 지원, 계정 삭제 페이지와 app-ads.txt를 전용 하위 도메인에서 호스팅합니다. 직접 도메인이나 서버를 둘 필요가 없습니다. 앱 하나는 무료이며, 스토어가 요구하는 것은 무엇도 유료로 막아 두지 않습니다.
2026년 9월 19일 확인. 스토어 정책은 바뀌며, 예고 없이 바뀌기도 합니다. 아래의 모든 내용은 공식 문서로 연결되며, 권위를 갖는 것은 이 페이지가 아니라 그 문서입니다. 둘이 다르면 스토어가 맞습니다. 이 가이드는 영어 원문을 번역한 것이며, 스토어 문서의 인용문은 영어 원문 그대로 두었습니다.
앱 하나는 체크리스트입니다. 앱 열 개는 시스템이며, 실패하는 방식이 달라집니다. 어려운 것은 없지만 항상 무언가가 조금씩 낡아 있고, 가장 오랫동안 손대지 않은 앱의 거부 알림으로 그것을 알게 됩니다.
앱마다 따로 있어야 하는 것
각 앱에는 자체 스토어 등록정보와 자체 데이터 처리 방식이 있으므로 타협할 수 없습니다.
- 개인정보처리방침. SDK 구성이 다르면 공개할 내용도 다릅니다. “저희 앱들”을 포괄하는 공유 방침은 전형적인 포트폴리오 실수입니다. 아래를 참고하세요.
- 계정 삭제 페이지, 그리고 여러분에게 도달하는 경로. 앱마다 필요합니다.
- Data safety 및 App Privacy 신고. 해당 앱 자체의 종속성 목록을 바탕으로 등록정보마다 작성합니다.
app-ads.txt, 앱에 광고가 표시된다면. 해당 앱의 등록정보에 있는 웹사이트를 통해 찾습니다.- URL 자체. 각 등록정보에 자체 필드가 있기 때문입니다.
정말로 공유할 수 있는 것
- 템플릿. 모든 개인정보처리방침에 하나의 구조, 이용약관에 하나의 구조를 두고 앱마다 채웁니다.
- 호스트 이름 패턴. 앱마다 예측 가능한 주소가 임시방편 URL 모음보다 낫습니다.
- 지원 주소. 정말로 받은편지함 하나가 모든 앱을 담당한다면.
- SDK에 대한 지식. Crashlytics나 AdMob이 수집하는 것은 어느 앱에서나 같은 사실입니다. 다른 것은 어떤 앱에 포함되어 있는지뿐입니다.
- 절차. 릴리스 체크리스트, 검토 주기, 아래의 관리 대장.
포트폴리오가 저지르는 두 가지 실수
모든 앱에 방침 하나. 누구나 떠올리는 절약법이지만 양방향으로 실패합니다. 조용한 유틸리티 앱은 전혀 건드리지 않는 데이터를 방침에 나열하고, 가장 최근 앱이 지난달에 추가한 것은 빠뜨립니다. 둘 다 정직하게 작성한 Data safety 양식과 맞지 않으며, 둘을 비교하는 검토자는 이 앱에 관한 것이 아닌 방침을 보게 됩니다.
누구의 것인지 구분되지 않는 공유 삭제 받은편지함. 열 개의 앱 중 어느 앱을 말하는지 표시 없이 “계정을 삭제해 주세요”라는 요청이 도착합니다. 식별할 수 없는 것은 처리할 수 없으며, 그것을 알아내는 동안에도 GDPR 기한은 흘러갑니다. 각 앱의 요청을 알림만 봐도 앱이 분명하도록 라우팅하세요.
관리 대장
포트폴리오를 관리 가능하게 만드는 것은 실제로 관리하는 단일 표입니다. 스프레드시트면 충분합니다. 앱마다 한 행, 그리고 다음 열을 둡니다.
| 열 | 이유 |
|---|---|
| 앱 이름, 번들 / 애플리케이션 ID | 식별 |
| 등록된 스토어 | 업데이트할 콘솔 수를 결정 |
| 개인정보처리방침 URL | 붙여 넣고 또 붙여 넣는 그 URL |
| 계정 삭제 URL | 마찬가지 |
| 지원 주소 / 페이지 | 마찬가지 |
| 선언된 개발자 웹사이트 | app-ads.txt를 찾는 곳 |
| 광고 표시 여부 | app-ads.txt가 해당되는지 여부 |
| 계정 여부 | 삭제가 해당되는지 여부 |
| 주요 SDK | 종속성 목록 요약 |
| 방침 마지막 검토일 | 무엇이 낡았는지 알려 주는 날짜 |
마지막 열이 제값을 하는 열입니다. 두 스토어 모두 신고가 출시 시점에 정확했던 것으로 끝나지 않고 계속 정확하게 유지될 것을 요구하며, “마지막 검토일”은 열 개를 모두 읽지 않고도 어긋난 세 개의 앱을 찾는 방법입니다.
효과적인 주기
- 릴리스마다, 앱마다: 종속성이 바뀌었나요? 그렇다면 해당 앱의 방침과 두 데이터 양식을 다시 확인하세요. 기억에 맡기지 말고 릴리스 체크리스트에 넣으세요.
- 분기마다, 포트폴리오 전체에서: 관리 대장을 열고 “마지막 검토일”로 정렬해 가장 오래된 몇 개를 확인합니다. 모든 URL이 로그아웃 상태에서 여전히 200을 반환하는지 확인합니다.
- URL이 옮겨질 때마다: 영향을 받는 모든 앱의 모든 콘솔을 업데이트하고, 이전 주소는 계속 리디렉션되게 두세요. 앱이 열 개라면 이것이 10분의 9만 끝난 채로 남기 가장 쉬운 변경입니다.
관리 대장의 모든 URL에 curl을 실행해 200이 아닌 것을 보고하는 열 줄짜리 스크립트는 반나절이면 만들 수 있으며, 실제로 일어나는 실패, 즉 조용히 사라진 호스트를 잡아냅니다.
AppFoyer가 하는 일
각 앱은 독립된 앱입니다. 자체 서브도메인, 자체 다섯 페이지, 자체 app-ads.txt, 자체 알림 채널, 자체
체크리스트가 있습니다. 잘못될 공유 방침이 없으며, 각 앱의 삭제 요청은 앱별로 식별되어 도착합니다.
대시보드의 체크리스트는 관리 대장의 실시간 부분입니다. 앱마다 어떤 스토어 필드가 아직 비어 있고 그것이 왜 중요한지 알려 주므로, “무엇이 낡았는가”는 업데이트를 잊어버린 스프레드시트 열이 아니라 하나의 화면이 됩니다. 플랜은 게시할 수 있는 앱 수로 구분됩니다. Free는 1개, Pro는 10개, Advanced는 50개입니다.
한계에 대해 솔직하게 말하자면, 일괄 편집과 앱 그룹은 아직 없습니다. 오늘 광고 네트워크 한 줄을 앱 열다섯 개에 추가하려면 열다섯 번 편집해야 합니다. 이 작업은 계획되어 있지만 출시되지 않았으며, 포트폴리오 도구를 판매하는 페이지라면 그중 무엇이 실제로 있는지 밝혀야 합니다.
공식 출처
- Provide information for Google Play’s Data safety section — Google Play Console 고객센터, 신고를 정확하게 유지하는 것에 관해
- App privacy details on the App Store — Apple, 응답을 최신 상태로 유지하는 것에 관해
- Set up app-ads.txt — AdMob 고객센터