앱 MVP 외부 SDK 개인정보 공개: 코드 목록·스토어 선언·제출 전 검수를 나누는 5가지 기준

앱 MVP에 분석, 오류 수집, 로그인, 푸시, 결제 같은 외부 SDK를 넣었다면 ‘SDK를 도입했다’는 기록만으로 출시에 필요한 개인정보 검토가 끝나지 않습니다. 같은 SDK라도 실제 설정, 호출 경로, 서버 전송, 사용 목적에 따라 앱이 공개해야 할 내용은 달라질 수 있습니다. iOS의 Privacy Manifest, App Store의 개인정보 공개, Google Play의 Data safety는 서로 같은 파일이나 버튼이 아닙니다.

먼저 답하면, 운영자는 `코드에 포함된 SDK`, `SDK와 앱이 실제로 다루는 데이터`, `플랫폼별 제출 산출물`, `제출 직전의 빌드·스토어 화면`, `변경 후 재검토 시점`을 각각 확인해야 합니다. 이 글은 특정 SDK의 수집 사실이나 심사 결과를 단정하지 않습니다. 현재 Apple과 Google의 공식 문서를 바탕으로, 앱 MVP 운영자가 출시·업데이트 전에 확인할 기록의 경계를 정리합니다.

먼저 답: 외부 SDK 개인정보 공개는 5개의 기록으로 나눕니다

1. 앱 빌드에 실제 포함된 SDK와 버전은 무엇인가?

2. 각 SDK와 앱 코드가 어떤 데이터·권한·도메인·API를 실제로 다루는가?

3. iOS의 Privacy Manifest와 Xcode Privacy Report에서 무엇을 확인할 것인가?

4. Google Play Data safety에서 앱 전체 기준으로 어떤 데이터 처리 사실을 선언할 것인가?

5. SDK·설정·데이터 흐름이 바뀐 뒤 누가, 언제, 어떤 산출물을 다시 검토할 것인가?

이 다섯 기록을 분리하면 ‘SDK 업체 문서가 있으니 끝났다’거나 ‘스토어에 한 번 적었으니 다음 배포에도 같다’는 판단을 줄일 수 있습니다. 특히 앱의 코드, 서버 전송, 웹뷰, SDK 설정은 서로 다른 변경 경로를 가질 수 있으므로 한 화면의 체크 표시를 완료 증거로 보지 않는 편이 안전합니다.

1. SDK 목록은 출발점이고, 데이터 공개는 별도 판단입니다

가장 먼저 배포 대상 빌드에서 SDK 목록과 버전을 확정합니다. 패키지 매니저, lockfile, 앱 바이너리, 빌드 설정 중 팀이 재현할 수 있는 기준을 하나 정하고, 직접 넣은 SDK뿐 아니라 다른 라이브러리가 다시 포함하는 의존성도 확인합니다. 이 목록은 ‘무엇을 조사해야 하는가’를 정하는 인벤토리이며, 그 자체가 데이터 처리 선언은 아닙니다.

Apple은 앱에 포함된 모든 코드에 대해 개발자가 책임을 진다고 안내하며, 일부 제3자 SDK에는 Privacy Manifest와 서명이 필요할 수 있다고 설명합니다. Google Play도 앱에 포함된 제3자 라이브러리·SDK가 수집하거나 공유하는 데이터는 Data safety 양식에 반영해야 한다고 안내합니다. 따라서 공급사의 문서 링크만 저장하지 말고, 현재 빌드의 SDK 이름·버전·도입 목적·담당자·문서 확인일을 한 줄씩 연결하세요.

여기서 ‘SDK를 설치했지만 기능을 아직 켜지 않았다’는 상태도 추측으로 처리하면 안 됩니다. 실제 초기화 여부, 설정 플래그, 호출 경로, 네트워크 전송 여부를 개발·운영 환경별로 확인한 뒤 `확인됨`, `확인 필요`, `제거 예정`처럼 상태를 남깁니다. 공급사 문서는 조사 출발점이고, 앱의 실제 구현 검토를 대신하지 않습니다.

2. iOS는 Manifest와 Privacy Report를 제출 화면과 섞지 않습니다

Apple의 Privacy Manifest는 앱 또는 제3자 SDK가 수집하는 데이터 유형, 추적 관련 정보, 필요한 이유를 선언해야 하는 API 사용 등을 기록하는 파일입니다. Apple은 Xcode가 앱과 연결된 제3자 SDK의 Manifest를 모아 Privacy Report를 만들 수 있다고 설명합니다.

이 보고서는 포함된 코드의 개인정보 관련 정보를 점검하는 데 도움을 주지만, 앱의 App Store Connect 공개 내용을 자동으로 확정하는 승인 증명은 아닙니다.

제3자 SDK의 Manifest와 앱 자체 Manifest의 역할도 한 칸에 뭉치지 마세요. Apple 문서는 제3자 SDK가 자신이 수집하는 데이터를 자신의 Manifest에 기록해야 한다고 설명하고, 앱 개발자는 생성된 Privacy Report를 활용해 앱의 개인정보 공개를 준비할 수 있다고 안내합니다.

따라서 iOS 릴리스 전 기록에는 `앱 Manifest 존재·유효성`, `SDK Manifest 확인`, `Archive에서 생성한 Privacy Report`, `App Store Connect에 입력할 공개 내용`을 별도 증빙으로 둡니다.

특히 특정 SDK가 Apple의 요구 대상 목록에 포함되는지, SDK가 바이너리 의존성으로 들어가는지, 필요한 서명이 있는지는 버전과 배포 방식에 따라 달라질 수 있습니다. 목록을 기억으로 판단하지 말고, 제출 직전에 Apple의 현재 요구 사항과 해당 빌드 산출물을 다시 대조하세요.

3. Google Play는 앱 전체의 실제 데이터 처리를 기준으로 봅니다

Google Play의 Data safety는 앱이 수집·공유·보호하는 데이터를 사용자에게 표시하기 위한 공개 정보입니다. Google은 앱에 포함된 제3자 SDK·라이브러리가 수집하거나 공유하는 데이터도 앱의 양식에 반영해야 하며, 정확하고 완전한 선언의 책임은 개발자에게 있다고 안내합니다.

여기서 SDK 제공자가 ‘데이터 수집 없음’이라고 설명했더라도 그대로 복사해 제출하지 않습니다. 먼저 앱에서 그 SDK가 받는 입력, 전송하는 데이터, 사용하는 권한, 웹뷰 동작, 서버 간 전달을 확인합니다.

Google의 안내상 기기 밖으로 전송되는 데이터는 수집 판단에 관련될 수 있고, 라이브러리·SDK가 앱에서 직접 제3자에게 전송하는 경우도 공유 판단에 관련될 수 있습니다. 반대로 처리 방식과 예외 조건은 앱의 구체적 구현에 따라 달라지므로, 이 글의 일반 설명만으로 특정 항목을 ‘미신고’로 결론내릴 수는 없습니다.

실무 표에는 `데이터 유형`, `발생 화면 또는 API`, `전송 주체`, `수신자 범주`, `사용 목적`, `선택·필수 여부`, `전송 중 보호 방식`, `확인 근거`, `담당자`, `검토일`을 둡니다. 이 표는 개발팀의 기술 사실과 스토어 입력값을 연결하는 중간 증거입니다. Data safety 화면은 이 표를 그대로 대신하는 시스템 설계서가 아닙니다.

4. ‘코드 변경’과 ‘공개 변경’을 같은 변경 티켓으로 연결합니다

외부 SDK 검토가 놓치기 쉬운 순간은 신규 도입보다 기존 SDK의 설정 변경입니다. 예를 들어 분석 이벤트에 새 속성을 추가하거나, 오류 보고에 식별자를 붙이거나, 로그인 SDK의 범위를 변경하거나, 웹뷰에서 앱이 제어하는 콘텐츠를 바꾸면 데이터 흐름의 판단 근거가 바뀔 수 있습니다. 반대로 패키지만 업데이트했더라도 실제 동작과 공급사 문서가 달라질 수 있으므로 ‘버전만 올렸다’는 이유로 검토를 생략하지 않습니다.

변경 티켓에는 최소한 `변경 전·후 SDK와 버전`, `기능·데이터 흐름의 변경 여부`, `iOS Manifest·Privacy Report 재검토 여부`, `Google Play Data safety 재검토 여부`를 남깁니다. 개인정보 처리방침·동의 문구 영향, 검토한 사람과 시각, 미확인 항목의 배포 조건도 같은 티켓에 연결합니다.

출시 보류가 필요한지 여부는 서비스의 실제 데이터 처리와 플랫폼의 현재 요구에 따라 결정해야 하며, 블로그 글의 체크리스트가 개별 심사나 법률 판단을 대체하지 않습니다.

외부 SDK의 일반 도입 책임과 버전·제거 기록은 앱 MVP 외부 SDK 도입: 책임·동의·버전·제거를 남기는 5가지 기록에서 이어서 볼 수 있습니다. 광고 추적과 제품 분석의 경계를 검토해야 한다면 앱 MVP iOS 추적 요청: 분석과 광고 추적을 나누는 5가지 기준도 함께 확인하세요.

우리 앱의 SDK·개인정보 공개 점검 흐름 상담하기

5. 제출 전에는 빌드·기록·스토어 화면을 같은 버전으로 맞춥니다

제출 직전에는 문서만 읽지 말고 실제 배포 후보 빌드에서 다시 확인합니다. iOS는 Archive로 생성한 Privacy Report와 Manifest 유효성을 살피고, Google Play는 App content의 Data safety 초안과 현재 앱 동작 근거를 대조합니다. 두 플랫폼 모두 데이터 공개가 사용자에게 보이는 정보라는 점은 같지만, 입력 위치와 산출물은 다르므로 한 플랫폼의 완료 상태를 다른 플랫폼의 완료로 복사하지 않습니다.

검수 순서는 간단합니다. 먼저 배포 후보의 버전과 커밋을 고정하고, SDK 인벤토리를 뽑습니다. 다음으로 각 데이터 흐름의 근거를 모아 iOS·Android 산출물에 연결합니다. 그 뒤 스토어 제출 화면의 초안을 두 번째 사람이 읽을 수 있는 형태로 남기고, SDK 업데이트·서버 설정 변경·새 권한 추가가 있으면 같은 흐름을 다시 시작합니다. 최종 판단은 실제 앱과 최신 플랫폼 문서를 가진 담당자가 해야 합니다.

출시 전 점검표

자주 묻는 질문

SDK 제공 문서에 ‘데이터를 수집하지 않는다’고 쓰여 있으면 그대로 선언해도 되나요?

아닙니다. 공급사 문서는 중요한 근거이지만, 앱에서 실제로 어떤 설정과 호출을 사용하는지까지 대신 확인하지는 않습니다. 현재 빌드의 SDK 버전, 기능 활성화, 앱·서버 데이터 흐름을 함께 확인한 뒤 플랫폼별 제출 항목을 판단하세요.

iOS 앱 Manifest 하나에 모든 SDK 데이터를 직접 적으면 되나요?

일괄적으로 그렇게 판단하면 안 됩니다. Apple은 제3자 SDK가 자신이 수집하는 데이터를 SDK Manifest에 기록한다고 설명하며, Xcode Privacy Report는 앱과 연결된 SDK Manifest를 모아 점검에 도움을 줍니다. 앱 Manifest, SDK Manifest, Privacy Report, App Store Connect 공개 내용을 구분해 현재 문서를 확인하세요.

Google Play Data safety에는 SDK가 처리하는 데이터도 포함하나요?

Google Play는 앱에 포함된 제3자 SDK·라이브러리가 수집하거나 공유하는 데이터도 앱의 Data safety 양식에 반영하라고 안내합니다. 다만 실제 데이터 유형과 처리 방식은 앱 구현에 따라 다르므로, 공급사 문서와 실제 흐름을 함께 검토해야 합니다.

SDK 버전만 올렸고 기능은 그대로라면 재검토하지 않아도 되나요?

버전 변경만으로 무조건 결론내릴 수는 없습니다. SDK의 동작, 선언 문서, 포함 방식, 앱 설정이 달라질 수 있으므로 변경 티켓에서 영향 여부를 확인하고, 필요한 플랫폼 산출물을 다시 검토하세요.

공식 출처

- Apple Developer: Privacy manifest files — 앱·SDK의 Manifest와 Privacy Report 개요 - Apple Developer: Describing data use in privacy manifests — SDK Manifest와 앱 Privacy Report의 구분 - Apple Developer: Third-party SDK requirements — 제3자 코드 책임과 요구 대상 확인 - Google Play Console Help: Data safety — SDK를 포함한 앱 데이터 공개와 개발자 책임 - Android Developers: Declare your app’s data use — 실제 앱·라이브러리 데이터 처리 검토 기준

외부 SDK 개인정보 공개는 서류를 한 번 채우는 일이 아니라, 현재 빌드의 코드·데이터 흐름·플랫폼별 산출물을 같은 버전으로 맞추는 운영 작업입니다. MVP 단계에서는 SDK 수를 줄이는 것보다, 무엇을 넣었고 무엇을 확인했는지 다시 찾을 수 있게 기록하는 일이 먼저입니다.

우리 앱의 SDK·개인정보 공개 점검 흐름 상담하기