앱 개인정보처리방침, 수집 항목부터 삭제 절차까지 작성하는 법

앱 출시가 가까워지면 개인정보처리방침 템플릿부터 찾기 쉽습니다. 하지만 다른 서비스의 문구를 복사해 이름만 바꾸면 실제 앱이 사용하는 로그인, 분석, 광고, 오류 보고와 결제 SDK가 빠질 수 있습니다. 반대로 사용하지 않는 기능과 데이터를 적어 사용자가 앱의 동작을 오해하게 만들 수도 있습니다.

개인정보처리방침은 법률 문구를 모아놓은 페이지가 아니라 데이터가 어디에서 들어와 누구에게 전달되고 언제 지워지는지 설명하는 운영 문서입니다. 문서를 쓰기 전에 앱 코드와 서버, 외부 SDK의 데이터 흐름을 먼저 조사해야 합니다. 이 글은 국내 1인 개발자가 그 조사표를 만들고 Google Play 공개 내용까지 맞추는 절차를 다룹니다.

법령과 플랫폼 정책은 변경될 수 있고 서비스별 처리 구조도 다릅니다. 2026년 8월 31일 확인한 개인정보보호법과 Google Play 공식 정책을 기준으로 작성했으며, 실제 공개 전에는 개인정보 보호 담당 기관이나 법률 전문가의 검토가 필요한지 판단해야 합니다.

문서 작성의 시작점은 ‘무엇을 적을까’가 아니라 ‘우리 앱에서 어떤 데이터가 실제로 움직이는가’입니다.

개인정보처리방침의 출발점

1. 앱 화면이 아니라 데이터의 전체 경로를 조사하기

사용자가 직접 입력하는 이름과 이메일만 보면 데이터의 일부만 확인하게 됩니다. 앱은 운영체제 권한, 기기 정보, 네트워크 로그, 분석 이벤트와 오류 보고서를 통해서도 데이터를 처리할 수 있습니다. 직접 만든 서버뿐 아니라 인증, 광고, 결제, 푸시, 분석과 고객지원 도구까지 조사 범위에 포함합니다.

조사할 때는 데이터 이름만 적지 말고 출발지, 전송 대상, 저장 위치, 이용 목적과 삭제 조건을 한 줄에 기록합니다. 예를 들어 ‘이메일 / 회원가입 화면 / 자체 API / 사용자 테이블 / 로그인과 알림 / 탈퇴 시 삭제’처럼 씁니다. 이 표가 개인정보처리방침과 Play Console 답변의 원본 자료가 됩니다.

2. 데이터 항목을 기능별로 구체화하기

‘서비스 이용 정보’처럼 넓은 표현만 쓰면 어떤 데이터를 다루는지 확인하기 어렵습니다. 이메일, 사용자 ID, 광고 식별자, IP 주소, 기기 모델, 오류 로그, 운동 기록처럼 실제 필드와 이벤트 단위로 쪼갭니다. 같은 데이터라도 사용자가 직접 입력하는지, 앱이 자동 생성하는지, SDK가 전송하는지를 구분합니다.

• 회원가입과 로그인에 사용하는 계정 정보
• 사용자가 앱 안에서 생성하는 기록과 콘텐츠
• 사진, 파일, 위치처럼 기기에서 선택하는 데이터
• IP, 기기 정보, 앱 버전과 접속 로그
• 분석 이벤트, 광고 ID와 오류 진단 정보
• 결제·구독 상태와 주문 식별정보
• 문의 메일과 고객지원 대화 내용
• 백업과 관리자 도구에 남는 복제 데이터

데이터 분류는 문서 작성만을 위한 작업이 아닙니다. 필요하지 않은 필드와 이벤트를 발견하면 수집 자체를 제거할 수 있습니다. 처리방침에 한 줄을 추가하는 것보다 앱이 불필요한 데이터를 보내지 않도록 바꾸는 편이 위험과 운영 비용을 함께 줄입니다.

3. 각 데이터의 목적을 실제 기능과 연결하기

‘서비스 제공 및 개선’처럼 모든 항목에 같은 목적을 붙이지 않습니다. 이메일은 로그인과 중요 알림, 운동 기록은 진행 상황 표시, 오류 로그는 장애 분석처럼 데이터와 기능의 관계를 설명합니다. 한 데이터를 여러 목적으로 사용한다면 각각 구분하고, 핵심 기능과 무관한 분석이나 마케팅 목적이 섞이지 않았는지 검토합니다.

권한이 있다고 해서 모든 상황에서 데이터를 사용할 수 있는 것은 아닙니다. 민감한 데이터 접근이 사용자가 예상하기 어려운 방식으로 일어난다면 앱 안에서 수집 항목과 목적을 명확히 설명하고 필요한 동의를 받아야 하는지 검토합니다. Google Play는 중요한 데이터 접근 고지가 개인정보처리방침 안에만 숨어 있어서는 안 된다고 안내합니다.

4. 보관 기간과 삭제 시점을 시스템 기준으로 정하기

보관 기간은 관행적으로 ‘회원 탈퇴 시까지’라고 쓰기보다 데이터별로 정합니다. 계정 삭제 즉시 지울 데이터, 부정 이용 대응을 위해 제한된 기간 보관할 로그, 법적 의무가 있는 거래 기록과 백업에서 일정 시간이 지나야 사라지는 데이터를 구분합니다. 별도 보관 근거가 있다면 대상과 기간을 확인합니다.

문서에 삭제한다고 적었지만 DB의 계정 상태만 비활성화하면 실제 동작과 맞지 않습니다. 기본 테이블, 파일 스토리지, 검색 인덱스, 분석 도구, 이메일 시스템과 백업에서 어떤 처리가 일어나는지 확인합니다. 익명화하거나 통계로 남기는 데이터가 있다면 개인과 다시 연결되지 않는지 구현을 검토합니다.

1. 사용자가 앱 또는 웹에서 삭제를 요청합니다.
2. 본인 확인 후 계정의 신규 접근과 처리를 중단합니다.
3. 운영 DB와 파일 저장소에서 삭제 대상 데이터를 처리합니다.
4. 외부 처리 도구와 SDK에 삭제 요청이 필요한지 확인합니다.
5. 백업 데이터의 만료·덮어쓰기 주기에 따라 삭제를 완료합니다.
6. 법적 근거로 분리 보관하는 데이터가 있다면 접근을 제한합니다.
7. 완료 여부를 확인할 로그는 개인정보를 최소화해 남깁니다.

5. 외부 SDK와 제3자 처리를 별도 표로 관리하기

앱에서 직접 API를 호출하지 않아도 포함된 SDK가 데이터를 외부로 보낼 수 있습니다. Google Play의 사용자 데이터 정책은 앱에 포함된 제3자 코드와 그 데이터 처리에 대해서도 개발자가 책임을 져야 한다고 설명합니다. SDK 공급자의 정책 페이지를 읽는 것에서 끝내지 말고 실제 설정과 전송 데이터를 확인합니다.

• 현재 빌드에 포함된 SDK와 버전을 모두 나열했다
• 각 SDK가 기본 설정에서 수집하는 데이터를 확인했다
• 사용하지 않는 자동 수집과 광고 기능을 비활성화했다
• 데이터가 전송되는 회사와 국가·서버 위치를 확인했다
• 삭제·열람 요청을 외부 도구에도 반영할 수 있다
• SDK 변경 시 정책 문서 재검토 항목을 릴리스 절차에 넣었다

업무 위탁, 제3자 제공과 국외 이전은 이름이 비슷해도 적용되는 요건이 같지 않을 수 있습니다. 계약 관계와 데이터 처리 목적, 통제 주체를 기준으로 구분해야 하므로 애매한 경우에는 임의로 표제만 선택하지 말고 전문가 검토를 받는 것이 좋습니다.

6. 개인정보처리방침의 기본 구조 만들기

개인정보보호법 제30조는 개인정보처리자가 처리방침을 수립·공개하도록 정하고 있습니다. 구체적인 공개 항목은 서비스와 적용 법령에 따라 달라질 수 있으므로 현재 법령과 관계 기관의 최신 작성지침을 확인합니다. 문서는 사용자가 찾기 쉬운 위치에 두고 각 항목을 명확한 제목으로 나눕니다.

문서에는 개발 내부 용어보다 사용자가 이해할 수 있는 이름을 씁니다. 예를 들어 내부 이벤트 이름만 적지 말고 어떤 행동에서 생성되는 정보인지 설명합니다. 모든 상황을 한 문장에 넣기보다 표와 소제목을 사용하고, 문의 주소는 실제로 수신·응답되는지 테스트합니다.

7. Google Play 데이터 보안과 문서를 일치시키기

개인정보처리방침과 Play Console의 데이터 보안 양식은 같은 원본 조사표를 사용해야 합니다. Google Play는 앱이 수집·공유하는 데이터와 보안 관행을 신고하도록 하며, 앱이 직접 다루는 데이터뿐 아니라 제3자 라이브러리와 SDK의 처리도 포함해야 한다고 안내합니다.

데이터를 수집하지 않는 앱도 데이터 보안 양식을 완료하고 개인정보처리방침 링크를 제공해야 하는 상황이 있습니다. 비공개·공개·프로덕션 테스트 트랙에 게시된 앱에 적용되는 범위를 확인하고, 내부 테스트만 사용하는 단계와 혼동하지 않습니다. 답변은 출시 후보 빌드를 기준으로 작성합니다.

앱 코드, 개인정보처리방침, Play Console 데이터 보안 답변은 같은 데이터 흐름표에서 나와야 합니다.

세 문서를 맞추는 기준

• 앱 권한과 데이터 보안 답변이 일치한다
• SDK가 수집·공유하는 데이터가 답변에 포함되어 있다
• 선택 수집과 필수 수집을 실제 UI처럼 구분했다
• 전송 암호화와 삭제 요청 가능 여부를 실제 구현으로 확인했다
• 개인정보처리방침의 항목·목적·보관 기간과 모순되지 않는다

8. 계정 삭제는 문구보다 실제 경로가 먼저다

앱에서 사용자가 계정을 만들 수 있다면 탈퇴 버튼과 데이터 삭제 처리를 제품 기능으로 설계해야 합니다. Google Play는 계정 삭제 기능을 앱 안에서 제공하고, 사용자가 앱을 다시 설치하지 않아도 요청할 수 있는 외부 웹 경로도 제공하도록 안내합니다. 계정 일시정지나 로그인 차단만으로 삭제를 대신할 수 없습니다.

외부 삭제 페이지는 Google Play의 계정 삭제 요구사항을 확인해 만들고 Play Console에 연결합니다. 어떤 데이터가 즉시 삭제되고 무엇이 법적 근거로 일정 기간 보관되는지, 요청 처리에 필요한 본인 확인과 예상 절차를 설명합니다. 단순히 고객센터 첫 화면으로 보내 사용자가 다시 삭제 방법을 찾아야 하는 구조는 피합니다.

9. 민감한 접근은 앱 화면에서도 설명하기

위치, 연락처, 사진과 파일처럼 사용자가 예상하기 어려운 데이터 접근은 처리방침 링크만 제공한다고 충분하지 않을 수 있습니다. 권한 요청 직전에 어떤 기능이 어떤 데이터를 왜 사용하는지 분명하게 설명하고, 사용자가 선택할 수 있는 흐름을 만듭니다. 설명보다 먼저 권한 팝업을 띄우거나 동의하지 않으면 관계없는 기능까지 막지 않도록 점검합니다.

운영체제 권한 이름과 개인정보처리방침 표현도 맞춥니다. 사진 한 장 선택 기능인데 전체 저장소 접근이 필요한 것처럼 보이거나, 백그라운드 위치를 쓰면서 문서에는 현재 위치만 적으면 실제 동작을 설명하지 못합니다. 가능한 범위가 좁은 API와 권한을 선택하는 것이 우선입니다.

10. 공개 URL과 앱 안의 접근 경로 점검하기

처리방침 페이지는 로그인 없이 열리고 모바일에서 읽을 수 있어야 합니다. 임시 문서 링크, 접근 권한이 필요한 클라우드 문서와 다운로드해야만 읽을 수 있는 파일보다 고정된 HTTPS 웹페이지가 관리하기 좋습니다. 앱 이름, 운영자, 문의처와 시행일을 표시하고 주소가 바뀌지 않도록 관리합니다.

1. 홈페이지에 고유한 개인정보처리방침 URL을 만듭니다.
2. 앱 설정이나 정보 화면에서 같은 페이지로 연결합니다.
3. Play Console의 개인정보처리방침 필드에 URL을 등록합니다.
4. 로그아웃 상태와 모바일 네트워크에서 페이지를 엽니다.
5. 앱 이름, 운영자와 지원 이메일이 스토어 정보와 같은지 확인합니다.
6. 계정 삭제 외부 URL이 필요한 경우 별도 경로를 연결합니다.
7. 이전 버전과 변경일을 확인할 보관 방식을 정합니다.

11. 릴리스마다 문서 변경 여부 확인하기

개인정보처리방침은 출시할 때 한 번 작성하고 끝나는 문서가 아닙니다. 새 SDK 추가, 권한 변경, 로그인 방식, 광고 도입, 서버 이전, 보관 기간과 계정 삭제 흐름이 바뀌면 조사표와 문서를 다시 검토합니다. 앱 기능만 배포하고 문서를 나중에 바꾸는 시차를 줄이도록 릴리스 체크리스트에 포함합니다.

공개 전 최종 점검

• 앱·서버·SDK·운영 도구의 데이터 흐름표를 작성했다
• 항목별 처리 목적과 필요성을 실제 기능으로 설명할 수 있다
• 보관 기간과 DB·파일·백업 삭제 절차가 구현되어 있다
• 외부 SDK와 제3자 처리를 최신 빌드 기준으로 확인했다
• 개인정보처리방침과 Play 데이터 보안 답변이 일치한다
• 앱 안과 외부 웹에서 계정 삭제 경로를 사용할 수 있다
• 공개 URL이 로그인 없이 모바일에서 정상적으로 열린다
• SDK·권한 변경 시 문서를 갱신하는 릴리스 절차가 있다

정확한 개인정보처리방침은 좋은 문장보다 정확한 시스템 조사에서 나옵니다. 데이터 흐름표를 하나의 원본으로 두고 앱 권한, 서버 저장, 외부 SDK, 처리방침과 마켓 답변을 함께 갱신하면 문서와 실제 동작이 어긋나는 문제를 줄일 수 있습니다. 조사 과정에서 필요 없는 수집을 발견했다면 문구를 늘리기 전에 코드에서 제거하는 것이 가장 확실한 개선입니다.