개인정보처리방침을 빌드와 일치시키기

개인정보처리방침을 작성하는 것은 한 번으로 끝나는 일입니다. 그것을 사실대로 유지하는 것은 그렇지 않습니다. 방침은 작성할 당시의 빌드를 설명하고, 빌드는 계속 바뀝니다. 풀 리퀘스트가 크래시 리포팅, 구독 라이브러리, 위치 권한을 추가하고, 앱이 출시되는데, 개인정보처리방침, Data safety 양식, App Privacy 세부 정보는 여전히 예전 앱을 설명하고 있습니다.

두 스토어 모두 이것을 자신들이 아니라 개발자의 문제로 봅니다. Google Play는 Data safety 답이 항상 정확하고 완전하게 유지되어야 하며, 앱에 포함된 서드파티 라이브러리와 SDK가 수집하는 데이터도 개발자가 신고해야 한다고 말합니다. Apple도 App Privacy 세부 정보에 대해 같은 말을 하며, 업데이트를 제출하지 않고도 언제든 App Store Connect에서 답을 변경할 수 있다고 덧붙입니다.

불일치가 실제로 생기는 곳

“데이터를 더 수집하자”는 결정에서 생기는 경우는 거의 없습니다. 평범한 엔지니어링 작업에서 생깁니다.

• 새 의존성. 크래시 리포팅, 분석, 페이월 SDK, 지도 라이브러리.
• 새 권한. 한 기능을 위한 위치, 스캐너를 위한 카메라, 광고를 위한 추적.
• 플레이버 또는 타깃. 무료 빌드에 유료 빌드에는 없는 광고 SDK가 추가됩니다.
• 제거. 이것도 불일치입니다. 방침이 이제 과다 신고하게 되는데, 더 안전한 실수이긴 하지만 여전히 실수입니다.

이 모든 것은 빌드 파일에 나타납니다. build.gradle, AndroidManifest.xml, Podfile, Package.swift, Info.plist, pubspec.yaml, package.json. 그래서 검사할 수 있습니다.

접근 방식: 기록, 그리고 모든 풀 리퀘스트에 대한 검사

1. 페이지를 작성할 때, 무엇을 기준으로 작성했는지 기록합니다. 그 시점의 빌드에 있는 SDK, 데이터 유형, 권한입니다.
2. 모든 풀 리퀘스트에서 빌드 파일을 다시 읽고 비교합니다.
3. 무언가 다르면, 무엇이 어디서(파일과 줄) 다른지, 그리고 어떤 페이지나 양식에 영향을 줄 수 있는지 알려 줍니다.

두 가지 특성이 중요합니다. 검사는 빌드 파일만 읽어야 합니다. 소스 코드나 비밀 정보는 절대 읽지 않아야 어떤 저장소에서든 안전하게 실행할 수 있습니다. 그리고 “위반”이 아니라 “최신이 아닐 수 있음”이라고 말해야 합니다. 빌드 파일에 라이브러리가 있다고 해서 앱이 그것을 사용한다는 증거는 아니며, 그것이 앱이 수집하는 것을 바꾸는지는 개발자만 압니다.

AppFoyer로 설정하기

이 검사는 모든 요금제에서 무료입니다. 빌드 파일만 읽고, 키나 비밀 정보가 필요 없으며, 어디로도 아무것도 보내지 않고, 페이지를 절대 변경하지 않습니다.

Claude Code 플러그인으로

1. “make this app store-ready”라고 말합니다. 플러그인은 페이지 초안을 작성하는 것 외에도 저장소 루트에 appfoyer.json을 작성합니다. 페이지를 작성할 때 기준이 된 것의 기록입니다.
2. “add the AppFoyer drift check”라고 말합니다. 플러그인이 GitHub 워크플로를 보여 주고, 승인하면 .github/workflows/appfoyer.yml을 작성합니다.
3. 두 파일을 커밋합니다. 플러그인은 대신 커밋하거나 푸시하지 않습니다.

플러그인 없이

워크플로를 직접 추가합니다.

name: AppFoyer drift check
on: pull_request
permissions:
  contents: read
jobs:
  check:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v5
      - uses: appfoyer/check-action@v1

풀 리퀘스트를 엽니다. 저장소에 아직 appfoyer.json이 없으면, 작업 요약(job summary)에 빌드를 바탕으로 작성할 파일이 표시됩니다. 게시된 페이지와 비교한 뒤 커밋하십시오.

또는 로컬에서 만들 수도 있습니다. npm에 게시된 같은 스캐너입니다.

npx @appfoyer/check init

다른 CI 시스템에서

npm 패키지는 Node 20 이상이 실행되는 곳이면 어디서든 실행됩니다. 예를 들어 GitLab에서는 다음과 같습니다.

appfoyer-drift-check:
  image: node:22
  script:
    - npx -y @appfoyer/check --fail-on-drift

--format markdown은 GitHub 작업 요약에 표시되는 것과 같은 보고서를 제공하며, --format json은 스크립트용입니다.

검사 결과의 모습

페이지가 RevenueCat 없이 작성된 앱에 RevenueCat을 추가하는 풀 리퀘스트입니다.

"Trail Notes": 2 changes
  + In-app purchases / subscriptions (data collected)  app/build.gradle.kts:28
      → Privacy policy may not declare "In-app purchases / subscriptions"
      → Google Play Data safety and Apple App Privacy answers may be outdated
      → Terms may not cover purchases and subscriptions
  + RevenueCat (SDK)  app/build.gradle.kts:28
      → Store forms: RevenueCat is not in the app's SDK list
      → Privacy policy may not name this SDK

기본적으로 작업은 결과를 보고하고 통과합니다. with: 아래에 fail-on-drift: "true"를 추가하면 기록이 업데이트될 때까지 실패하도록 할 수 있습니다.

변경이 보고되면

1. 변경이 영향을 주는 것을 업데이트합니다. 같은 브랜치에서 “make this app store-ready”라고 다시 말하십시오. 플러그인이 빌드를 다시 읽고, 앱의 사실 정보를 업데이트하고, 변경이 영향을 주는 페이지의 초안을 다시 작성하고, appfoyer.json을 다시 씁니다. 또는 대시보드에서 페이지와 Store forms 탭을 직접 편집하십시오.
2. 기록을 갱신합니다. 플러그인은 이미 갱신했습니다. 대시보드에서 편집했다면 npx @appfoyer/check update를 실행하거나, 작업 요약에서 결과 아래에 있는 갱신된 파일을 복사하십시오.
3. 같은 풀 리퀘스트에 커밋합니다. 다음 실행에서는 변경이 표시되지 않으며, 히스토리에는 의존성 변경과 공개 내용 변경이 함께 들어온 것으로 남습니다.
4. 콘솔의 스토어 양식을 업데이트합니다. 검사도 AppFoyer도 Play Console이나 App Store Connect에 접근할 수 없습니다. 답안 초안은 대시보드의 Store forms 탭에 있습니다.
5. 업데이트된 초안을 검토 화면에서 게시합니다.

하나의 저장소에 여러 앱이 있는 경우

appfoyer.json은 스토어 등록정보마다 하나의 항목을 가집니다. 자체 애플리케이션 ID를 가진 제품 플레이버는 자체 항목을 가지므로, 무료 플레이버에서만 쓰는 광고 SDK는 유료 플레이버가 아니라 무료 플레이버의 페이지와 비교됩니다. 플러그인은 스토어 준비를 마친 플레이버마다 항목을 하나씩 작성합니다. 직접 작성할 경우, 항목에는 sourceSets 목록(["free"], 또는 다차원 빌드라면 조합에 포함된 모든 플레이버와 조합 자체)과, 앱이 모노레포 안에 있다면 root 폴더를 지정합니다.

검사가 볼 수 없는 것

• 의존성의 의존성. 단, Podfile.lock이 이를 나열하는 iOS는 예외입니다. 다른 라이브러리가 끌어온 SDK는 빌드 파일에 나타나지 않으므로 여기에도 나타나지 않습니다.
• 코드로만 된 설정. Expo의 app.config.js / app.config.ts는 JavaScript이므로 읽지 않습니다. app.json과 package.json은 읽습니다.
• 선언한 것을 실제로 사용하는지. 존재하지만 사용하지 않는 의존성도 보고됩니다.
• 백엔드. 빌드 파일의 어떤 것도 서버가 무엇을 얼마 동안 저장하는지 알려 주지 않습니다.

이것은 변경 사항을 공개하는 비용이 가장 적게 드는 시점에 주는 알림이며, 컴플라이언스 판정도 법률 조언도 아닙니다.

공식 출처

• Provide information for Google Play’s Data safety section — Google Play Console 고객센터: 양식을 정확하게 유지하는 것, 그리고 서드파티 SDK 데이터
• App privacy details on the App Store — Apple: 응답을 최신 상태로 유지하는 것, 그리고 앱 업데이트 없이 응답을 업데이트하는 것
• appfoyer/check-action과 @appfoyer/check — Action과 npm 패키지, 그리고 각각이 읽는 것