앱 MVP Data safety: 권한·SDK·데이터 흐름 증빙을 나누는 5가지 기준
앱 MVP Data safety: 권한·SDK·데이터 흐름 증빙을 나누는 5가지 기준
Google Play 배포를 앞둔 MVP 팀이 Data safety를 작성할 때 가장 위험한 지점은 선언 화면을 먼저 열고, 실제 앱 안의 데이터 흐름을 나중에 추측하는 일입니다. 권한을 하나 찾았다고 곧바로 수집이라고 결론 내리거나, SDK 제공 문서를 받았다고 우리 앱의 선언까지 끝났다고 보는 것도 같은 문제입니다.
먼저 답하면, Data safety 준비는 사용자 흐름에서 어떤 데이터가 어디로 가는지 확인하고, 앱 코드와 SDK의 근거를 분리한 뒤, Google Play의 수집·공유 정의에 맞춰 선언 초안을 만들고, 스토어 미리보기와 배포 후보를 대조하는 순서로 진행하는 편이 안전합니다. 이 글은 특정 앱의 정책 적합성이나 심사 결과를 보장하지 않습니다.
1. 시작점은 권한 목록이 아니라 사용자 데이터의 이동입니다
Data safety의 ‘수집’은 앱에서 사용자 기기 밖으로 데이터가 전송되는 경우를 뜻합니다. 그래서 먼저 화면 또는 기능별로 사용자가 입력·선택·생성하는 항목을 적고, 해당 값이 기기 안에만 남는지, 우리 서버로 가는지, SDK 또는 외부 서비스로 가는지 확인해야 합니다.
예를 들어 사진 선택, 회원가입, 오류 보고, 푸시 알림, 결제, 분석 이벤트는 모두 같은 방식으로 판단하면 안 됩니다. 기능 이름과 권한 이름은 출발점일 뿐입니다. 어떤 값이 전송되는지, 전송 주체가 앱 코드인지 SDK인지, 사용자가 그 기능을 실행할 수 있는지를 한 행에 남기세요.
확인 항목 | 남길 증거 | 결론을 서두르면 안 되는 이유 |
|---|---|---|
사용자 흐름 | 화면·입력값·전송 시점 | 권한만으로 실제 전송을 단정할 수 없음 |
앱 코드 | API 호출·네트워크 요청·설정값 | 코드 조각 하나가 전체 경로를 뜻하지 않음 |
SDK | 이름·버전·제공사 문서·초기화 조건 | SDK 문서가 우리 앱의 실제 사용을 대신하지 않음 |
서버·외부 서비스 | 수신 목적지·처리 목적·보관 여부 | 동일 데이터도 목적과 전달 상대에 따라 질문이 달라짐 |
Google의 Android 안내는 권한 선언, API 호출, 입력 폼, WebView, 라이브러리 등을 확인 단서로 제시하지만 목록은 완전하지 않다고 설명합니다. 따라서 ‘발견한 단서’와 ‘실제 흐름으로 확인한 사실’을 같은 상태로 기록하지 않는 것이 중요합니다.
2. 앱 코드와 외부 SDK의 책임을 같은 표에서 분리합니다
Google Play의 Data safety 안내는 앱에 포함한 제3자 라이브러리·SDK가 수집하거나 공유하는 데이터도 선언에 반영해야 한다고 설명합니다. 여기서 핵심은 SDK 제공사의 일반 설명을 복사하는 것이 아니라, 현재 빌드에 포함된 SDK 버전과 실제 활성화 조건을 확인하는 일입니다.
같은 분석 SDK라도 어떤 기능을 켰는지, 어떤 식별자나 이벤트를 보내는지, 설정을 바꿨는지에 따라 앱의 판단 근거가 달라질 수 있습니다. SDK 행에는 공급사 링크만 두지 말고 버전, 초기화 위치, 관련 화면, 전송 관찰 또는 제공사 자료, 재검토 조건을 함께 적으세요.
특히 WebView는 앱이 전달하는 코드·동작을 통제하는 경우에만 별도 확인이 필요할 수 있습니다. 사용자가 열린 웹을 자유롭게 탐색하는 경우와 앱이 정한 화면·스크립트를 제공하는 경우를 한 범주로 묶으면 선언 근거가 약해집니다.
3. ‘수집’과 ‘공유’의 질문을 따로 답합니다
공식 도움말은 수집을 기기 밖 전송으로, 공유를 제3자에게 사용자 데이터를 이전하는 경우로 설명합니다. 이 정의에는 SDK를 통한 제3자 전송과 앱이 통제하는 WebView에서의 전송도 포함될 수 있습니다. 반면 서비스 제공자가 개발자의 지시에 따라 처리하는 경우처럼 공유로 보지 않는 예외도 문서에 제시돼 있습니다.
그러므로 한 데이터 항목마다 ‘우리 시스템 밖으로 나가는가’와 ‘누구에게 어떤 관계로 전달되는가’를 분리해 답하세요. 로컬에서만 처리한 데이터, 전송하지만 일시적으로 요청 처리만 위해 쓰는 데이터, 서버에서 보관하거나 다른 서비스에 전달하는 데이터도 같은 이름표로 관리하지 않는 편이 좋습니다.
이 구분은 법률 해석을 대신하지 않습니다. Data safety 문서의 정의와 실제 기술 흐름이 만나는 지점을 기록하기 위한 실무 기준입니다. 불확실한 처리 경로가 있다면 ‘수집 안 함’으로 추정해 제출하기보다, 담당 개발자·SDK 제공사·서버 운영자에게 확인할 질문으로 남기세요.
4. 선언 화면에는 데이터 유형·목적·처리 방식을 연결합니다
Data safety 양식에서는 수집 또는 공유하는 데이터 유형별로 사용·처리 방식을 질문합니다. 공식 안내는 암호화 전송 여부와 데이터 삭제 요청 경로도 확인 항목으로 설명합니다. 따라서 원본 증빙표에는 데이터 유형만 적지 말고, 해당 기능의 목적, 필수·선택 판단 근거, 전송 보호 방식의 확인 주체, 삭제 요청 경로의 실제 소유자를 연결해야 합니다.
어떤 데이터 유형인가? 화면·코드·SDK·서버 로그 정책을 대조합니다.
왜 필요한가? 사용자 기능과 처리 목적을 짧게 연결합니다.
선택인가 필수인가? 모든 사용자에게 제공되는 회피·동의 경로를 확인합니다.
전송 중 보호는 확인됐는가? 실제 통신 구성과 담당자의 확인을 남깁니다.
삭제 요청 경로가 있는가? 사용자에게 제공한 현재 경로와 운영 책임자를 기록합니다.
스토어에 표시되는 선언은 팀 내부 표를 그대로 복사한 결과가 아닙니다. 사용자에게 보이는 문구와 실제 앱 동작이 맞는지 검토하는 단계가 따로 필요합니다. 유인어스의 앱 MVP 외부 SDK 도입 기록 기준도 함께 보면 SDK 추가·버전 변경·제거를 어떤 변경 이벤트로 남길지 정리할 수 있습니다.
5. 최종 대조는 제출 직전 배포 후보에서 합니다
개발 중에는 테스트 SDK, 디버그 설정, 실험용 이벤트가 섞일 수 있습니다. 반대로 배포 후보에는 새 SDK 버전이나 설정이 포함될 수 있습니다. 그래서 Data safety 선언의 최종 근거는 오래된 스프레드시트가 아니라, 이번에 제출할 앱 버전의 의존성·설정·사용자 흐름·스토어 미리보기를 함께 비교한 기록이어야 합니다.
Google Play는 제출한 Data safety 정보를 검토하지만, 개발자가 완전하고 정확한 선언의 책임을 진다고 안내합니다. 따라서 검토 화면이 열렸거나 미리보기가 보였다는 사실을 정확성의 증거로 바꾸면 안 됩니다. 제출 결과도 Play Console의 실제 상태를 확인하기 전에는 확정이라고 표현하지 마세요.
권장하는 변경 이력은 릴리스 버전, 기능 또는 화면, 데이터 유형, 앱 코드·SDK 구분, 전송 목적지, 수집·공유 판단, 근거 링크, 확인자, 재검토 조건입니다. 개인 식별자나 실사용 데이터 값을 이 문서에 복사할 필요는 없습니다.
Data safety의 목적은 빈칸 없는 양식을 만드는 데 있지 않습니다. 사용자 흐름, 코드·SDK, 전송 경로, 스토어 공개 문구를 같은 배포 후보 기준으로 설명할 수 있게 만드는 것입니다. 최신 Google Play 문서와 실제 빌드를 함께 확인하세요.
자주 묻는 질문
권한을 요청하면 무조건 Data safety에 수집이라고 써야 하나요?
아닙니다. Android 안내는 권한을 중요한 확인 단서로 제시하지만, Data safety의 수집 판단은 실제로 사용자 데이터가 기기 밖으로 전송되는지와 그 처리 흐름을 함께 확인해야 합니다.
SDK 제공사의 Data safety 문서만 확인하면 되나요?
아닙니다. Google Play는 제3자 SDK의 데이터 처리도 앱의 선언에 반영하도록 안내합니다. 현재 앱에 포함된 SDK 버전, 활성화한 기능, 실제 데이터 흐름을 별도로 대조해야 합니다.
기기 안에서만 처리한 데이터도 수집으로 선언해야 하나요?
공식 도움말은 기기 안에서만 접근·처리되고 기기 밖으로 전송되지 않는 데이터는 수집 범위에서 제외한다고 설명합니다. 다만 실제로 외부 전송이 없는지는 기능·코드·SDK 기준으로 확인해야 합니다.
Data safety 미리보기가 보이면 정확성 검수도 끝난 건가요?
아닙니다. 미리보기는 사용자가 볼 내용을 확인하는 단계입니다. 선언의 완전성과 정확성은 실제 앱 동작과 근거를 개발자가 책임지고 대조해야 합니다.