Data safety 양식과 개인정보처리방침이 서로 다를 때

Data safety 양식과 개인정보처리방침은 같은 앱에 대한 두 가지 설명이며, 스토어는 이 둘을 함께 읽습니다. 둘이 서로 다르면 어느 쪽이 틀렸든 그 불일치 자체가 문제입니다. Google Play는 이를 분명히 밝힙니다. “When Google becomes aware of a discrepancy between your app behavior and your declaration, we may take appropriate action, including enforcement action.”(번역: Google이 앱의 동작과 신고 내용 사이의 불일치를 알게 되면, 집행 조치를 포함한 적절한 조치를 취할 수 있습니다.)

Apple도 이름만 다를 뿐 같은 구조입니다. 제품 페이지의 App Privacy 세부 정보와, 필수인 개인정보처리방침 URL입니다.

이 페이지는 두 문서를 일치시키는 방법, 그리고 두 문서가 모두 대조되는 세 번째 기준인 앱이 실제로 하는 일에 관한 것입니다.

두 문서 간단히 보기

Data safety 양식(Play Console → App content)과 App Privacy 세부 정보(App Store Connect)는 구조화된 신고서입니다. 체크박스와 카테고리로 이루어져 있고, 사용자가 설치 전에 읽는 요약으로 스토어 등록정보에 표시됩니다. 정해진 설문에 대한 답변입니다.

개인정보처리방침은 직접 호스팅하는 URL에 있는 산문입니다. 같은 내용을 문장으로 설명하고, 여기에 설문에는 칸이 없는 내용, 즉 법적 근거, 보존 기간, 연락처, 삭제 요청 방법을 더합니다.

어느 쪽도 다른 쪽을 대신하지 못합니다. 방침이 양식을 채워 주지 않으며, 양식을 작성했다고 해서 방침이 정확하다는 뜻도 아닙니다.

두 문서가 어긋나는 지점

몇 달의 간격을 두고 작성됩니다. 방침은 출시 주에 작성됩니다. 양식은 제출 당일 누군가가 의존성 목록을 보면서 채우고, 아무도 방침으로 돌아가 보지 않습니다.

새 SDK가 들어옵니다. 한 스프린트에서 크래시 리포터를 추가합니다. 풀 리퀘스트에는 방침이나 양식에 관한 내용이 전혀 없으므로 둘 다 바뀌지 않습니다. Google Play는 이것도 해당된다고 명시합니다. 데이터 수집은 “includes data collected and handled through any third-party libraries or SDKs used in their apps… You must reflect data collection or sharing carried out by such third-party code in the Data safety form for your app.”(번역: 앱에서 사용하는 모든 서드파티 라이브러리나 SDK를 통해 수집되고 처리되는 데이터를 포함합니다… 이러한 서드파티 코드가 수행하는 데이터 수집이나 공유를 앱의 Data safety 양식에 반영해야 합니다.) Apple도 같은 것을 요구합니다. “You need to identify all of the data you or your third-party partners collect.”(번역: 귀하 또는 귀하의 서드파티 파트너가 수집하는 모든 데이터를 파악해야 합니다.)

기능이 공개 내용 없이 출시됩니다. “주변 찾기” 기능을 위한 위치 정보, 파트너와 사용자 ID를 공유하는 추천 시스템 같은 것입니다. 엔지니어링 작업은 눈에 보이지만, 신고 작업은 누구의 보드에도 올라가 있지 않습니다.

둘 중 하나에 템플릿을 사용했습니다. 광고가 없는 앱에 광고 식별자를 나열한 생성된 방침은 누락만큼이나 불일치입니다. 그리고 정직하게 작성한 양식과 모순되기 때문에 오히려 더 쉽게 눈에 띕니다.

유일하게 통하는 순서로 맞추기

어느 한 문서가 아니라 앱에서 시작하십시오. 두 문서 모두 앱을 설명해야 하므로, 한쪽을 다른 쪽에 맞춰 고치면 오류가 옮겨갈 뿐입니다.

1. 의존성 파일을 여십시오. build.gradle/libs.versions.toml, Podfile/Package.swift, pubspec.yaml, package.json. 모든 서드파티 SDK를 나열하십시오.
2. 각각이 무엇을 전송하는지 적으십시오. 크래시 리포터는 기기 식별자와 스택 트레이스를 보냅니다. 분석 SDK는 이벤트와, 흔히 광고 ID를 보냅니다. 광고 SDK는 훨씬 더 많은 것을 보냅니다. 푸시 라이브러리는 기기 토큰을 등록합니다. 여기서의 출처는 벤더 자체의 개인정보 문서입니다.
3. 직접 수집하는 데이터를 추가하십시오. 계정, 업로드, 백엔드에 저장하는 모든 것입니다.
4. 선언한 권한과 사용 목적 문자열을 확인하십시오. 이는 앱이 접근할 수 있는 것에 대한 두 번째의 독립적인 목록입니다. ACCESS_FINE_LOCATION, NSLocationWhenInUseUsageDescription, 카메라, 연락처, 사진 등입니다.
5. 이제 그 목록으로 양식을 작성하고, 같은 목록으로 방침을 다시 쓰십시오. 두 문서를 비교했기 때문이 아니라 하나의 출처에서 나왔기 때문에 일관성을 갖게 됩니다.

최신 상태로 유지해야 하는 것은 양식이 아니라 그 목록입니다. 두 신고서 모두 그 목록에서 파생됩니다.

이후에도 일치 상태 유지하기

신고 내용은 소리 없이 낡아 가므로, 확인 작업을 소리 없이 지나가지 않는 무언가에 붙여 두어야 합니다. Google Play는 이를 요구합니다. “Your Data safety form responses must remain accurate and complete at all times.”(번역: Data safety 양식 응답은 항상 정확하고 완전한 상태를 유지해야 합니다.) Apple도 마찬가지입니다. “You’re responsible for keeping your responses accurate and up to date.”(번역: 응답을 정확하고 최신 상태로 유지할 책임은 귀하에게 있습니다.)

효과가 있는 가장 저렴한 방법은 릴리스 체크리스트에 한 줄을 넣는 것입니다. 이번 릴리스에서 의존성이 바뀌었는가? 그렇다면 방침과 양식을 다시 확인한다. 의존성 변경이야말로 두 문서를 모두 무효로 만드는 사건이기 때문입니다.

이 페이지가 알려 드릴 수 없는 것

어떤 규제가 구체적으로 적용되는지입니다. GDPR, UK GDPR, CCPA/CPRA, LGPD, 아동 개인정보 보호 규정은 각각 방침에 특정한 내용을 요구하며, 그중 어느 것이 적용되는지는 사용자가 어디에 있는지와 앱이 무엇을 하는지에 따라 달라집니다. 앱에 조금이라도 특이한 점이 있다면, 예를 들어 건강 데이터, 아동, 한 문장으로 설명하기 망설여지는 무엇이든 있다면, 변호사와 한 시간 상담할 가치가 있습니다. 템플릿은 저희 것을 포함해 출발점일 뿐 조언이 아닙니다.

AppFoyer가 여기서 하는 일

저희는 빌드 파일에서 찾은 SDK를 바탕으로 개인정보처리방침 초안을 작성합니다. 저장소를 읽는 코딩 에이전트를 사용하거나 짧은 양식을 통해서입니다. 그래서 방침과 스토어에 제출하는 답변이 기억이 아니라 같은 의존성 목록에서 나옵니다. 서드파티를 명시하는 자리표시자가 교체될 때까지 체크리스트는 이 페이지를 계속 표시합니다. 검토자가 양식과 대조하는 부분이 바로 그 섹션이기 때문입니다.

저희는 Data safety 양식을 대신 작성해 드리지 않으며, 어떤 서비스도 그렇게 할 수 없습니다. 이 양식은 본인의 콘솔에서 서명하는 신고서이며, Google Play는 “you alone are responsible for making complete and accurate declarations”(번역: 완전하고 정확한 신고를 할 책임은 오직 귀하에게 있습니다)라고 말합니다.

공식 출처

• Provide information for Google Play’s Data safety section — Google Play Console 고객센터
• App privacy details on the App Store — Apple
• Privacy policy requirements — Google Play 고객센터