SDK가 무엇을 수집하는지 알아내는 방법
반복할 수 있는 방법, Firebase가 직접 공개한 표를 이용한 실제 예시, 그리고 아무것도 공개하지 않는 업체의 경우 어디를 봐야 하는지.
의존성 파일을 열어 모든 서드파티 SDK를 나열한 다음, 각 업체가 직접 공개한 데이터 공개 페이지를 읽으세요. 예를 들어 Firebase는 각 제품이 어떤 데이터를 수집하는지 정확히 공개합니다. 그 목록이 개인정보처리방침의 실질적인 내용이며, Data safety와 App Privacy 답변의 출처가 되어야 합니다.
대신 몇 분 만에 끝내세요
AppFoyer는 이 가이드가 다루는 페이지, 즉 개인정보처리방침, 이용약관, 지원, 계정 삭제 페이지와 app-ads.txt를 전용 하위 도메인에서 호스팅합니다. 직접 도메인이나 서버를 둘 필요가 없습니다. 앱 하나는 무료이며, 스토어가 요구하는 것은 무엇도 유료로 막아 두지 않습니다.
2026년 9월 19일 확인. 스토어 정책은 바뀌며, 예고 없이 바뀌기도 합니다. 아래의 모든 내용은 공식 문서로 연결되며, 권위를 갖는 것은 이 페이지가 아니라 그 문서입니다. 둘이 다르면 스토어가 맞습니다. 이 가이드는 영어 원문을 번역한 것이며, 스토어 문서의 인용문은 영어 원문 그대로 두었습니다.
데이터에 관한 스토어 요건은 모두 하나의 목록으로 귀결되는데, 그것을 적어 두는 사람은 거의 없습니다. 개인정보처리방침, Data safety 양식, App Privacy 답변은 같은 목록을 세 가지로 표현한 것입니다. 그러니 그 목록을 한 번 제대로 만드는 것이 일의 전부입니다.
두 스토어 모두 SDK의 동작이 개발자의 책임이라고 명시합니다. Google Play는 데이터 수집이 “includes data collected and handled through any third-party libraries or SDKs used in their apps”(번역: 앱에서 사용하는 모든 서드파티 라이브러리나 SDK를 통해 수집·처리되는 데이터를 포함합니다)라고 합니다. Apple은 “you or your third-party partners collect”(번역: 개발자 또는 개발자의 서드파티 파트너가 수집하는) 데이터를 밝히라고 요구합니다.
1단계 — 모든 SDK 찾기
기억에 의존하지 말고 파일을 읽으세요.
| 플랫폼 | 파일 |
|---|---|
| Android | build.gradle / build.gradle.kts, libs.versions.toml, AndroidManifest.xml(권한, 메타데이터) |
| iOS | Podfile, Package.swift, *.pbxproj, Info.plist(사용 목적 문자열), *.entitlements |
| Flutter | pubspec.yaml |
| React Native / Expo | package.json, app.json |
직접 고르지 않은 전이 의존성도 포함하세요. 광고 라이브러리를 끌어오는 SDK는 그 라이브러리가 수집하는 것을 수집합니다.
2단계 — 각 업체의 자체 공개 자료 읽기
진지한 업체 대부분은 자사 SDK가 정확히 무엇을 보내는지 설명하는 페이지를 공개합니다. 고객들이 바로 이 양식들을 위해 그 정보가 필요하기 때문입니다. 블로그 글도, 포럼 답변도 아닌 그 페이지가 출처입니다.
Firebase가 실제 예시입니다. Google이 제품별 내역을 Apple의 App Privacy 카테고리에 대응시켜 공개하기 때문입니다.
| Firebase 제품 | Google 문서에 따른 수집 항목 |
|---|---|
| Analytics | 앱 인스턴스 ID, 사용자 속성, 이벤트, IP 주소 |
| Crashlytics | 크래시 시점의 스택 트레이스와 애플리케이션 상태, 기기 및 OS 정보, 그리고 개발자가 첨부하는 커스텀 키, 로그, 사용자 ID |
| Cloud Messaging | 앱 설치 ID에 연결된 푸시 토큰, 기기 모델, 언어, 시간대, OS 버전, 앱 식별자와 버전 |
| Authentication | 자체 생성하는 식별자, 그리고 활성화한 로그인 제공업체에서 오는 이메일 주소, 전화번호, 표시 이름 |
| Performance Monitoring | 실행 시간, 네트워크 지연 같은 성능 지표, 기기 및 OS 정보, 지역 구분을 위한 IP 주소 |
| Remote Config | 국가 및 언어 코드, 시간대, OS 버전, 앱 및 번들 식별자 |
Crashlytics를 쓴다면 이 표를 두 번 읽으세요. 마지막 열의 일부는 개발자가 만든 것입니다. 크래시 리포트에 첨부하는 커스텀 키와 사용자 ID는 개발자가 보내기로 선택한 데이터이며, 개발자 자신의 말로 방침에 들어가야 합니다.
직접 찾아가 볼 만한, 공개 자료를 내는 다른 업체들: 광고 네트워크(AdMob, AppLovin, Unity, ironSource), 어트리뷰션 도구(AppsFlyer, Adjust), 오류 리포팅(Sentry, Bugsnag), 구매(RevenueCat, Adapty), 그리고 인증 제공업체.
3단계 — 업체가 아무것도 공개하지 않을 때
특히 작은 라이브러리에서 일어나는 일입니다. 그럴 때는:
- 네트워크 트래픽을 읽으세요. 프록시를 거쳐 앱을 실행하고 SDK가 무엇을 보내는지 보세요. 반박할 수 없는 유일한 방법이며, 오후 한나절이면 결론이 납니다.
- 소스를 읽으세요. 공개되어 있다면요.
- 업체에 서면으로 문의하고 답변을 보관하세요.
- 제거를 고려하세요. 데이터 동작을 아무도 밝히려 하지 않는 의존성은 남의 편의를 위해 대신 짊어지고 있는 부담입니다.
4단계 — 목록을 세 문서로 바꾸기
하나의 목록, 세 가지 표현, 이 순서대로:
- 개인정보처리방침 — 카테고리, 목적, 이름이 명시된 서드파티, 보관 기간, 연락처.
- Play Console의 Data safety 양식 — 같은 사실을 체크박스로.
- App Store Connect의 App Privacy — 같은 사실을 다시, Apple의 카테고리로.
서로를 보고 채우지 말고 언제나 목록에서 채우세요. 둘이 어긋나면 스토어는 SDK를 믿습니다. 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이 알게 되면, 집행 조치를 포함한 적절한 조치를 취할 수 있습니다)이라고 명시합니다.
사실대로 유지하기
세 문서를 모두 무효로 만드는 사건은 언제나 같습니다. 의존성이 바뀐 것입니다. 릴리스 체크리스트에 한 줄을 넣으세요. 이번 릴리스에서 의존성이 바뀌었는가? 그렇다면 방침과 두 양식을 다시 확인한다. 두 스토어 모두 이것들이 출시 때 정확했던 것만이 아니라 계속 정확하게 유지되기를 요구하기 때문입니다.
AppFoyer가 여기서 하는 일
이 방법이 바로 저희 에이전트가 자동화하는 것입니다. 코딩 에이전트에게 저장소를 가리키면, 그 의존성 파일들을 읽고, 찾은 것을 알려진 SDK 맵과 대조하고, 찾아낸 서드파티의 이름을 밝힌 개인정보처리방침 초안을 작성합니다. 각 사실이 나온 파일과 줄 번호를 함께 알려 주므로, 믿는 대신 확인할 수 있습니다. 에이전트가 없다면 짧은 양식이 같은 질문을 합니다.
결과물은 개발자가 검토하는 초안입니다. 알아보지 못하는 라이브러리는 볼 수 없으며, 개발자의 클릭 없이는 절대 아무것도 게시하지 않습니다.
공식 출처
- Privacy and security in Firebase 및 App Store data collection — Google. 위의 표는 이 페이지들에서 가져왔으며, 권위 있는 출처는 이 페이지가 아니라 그 페이지들입니다.
- Provide information for Google Play’s Data safety section — Google Play Console 고객센터
- App privacy details on the App Store — Apple