기술

PIPA·GDPR이 모바일 앱에 요구하는 것 — 개발자 체크리스트

동의 → 보관 기간 → 삭제 요청 → 미성년자 → 제3자 제공 → 처리방침 → 책임자. 한국 PIPA와 EU GDPR이 공통으로 묻는 7가지를 Flutter + Firebase로 정리

앱 출시 전 또는 정기 점검 시 한 번 훑어볼 만한 체크리스트다. PIPA(개인정보보호법, 한국)와 GDPR(EU)이 공통으로 요구하는 항목 위주로, Flutter + Firebase 환경에서의 실용적 구현도 함께 적었다.

법률 자문이 아니라 개발자 관점의 정리다. 정확한 적용은 변호사·DPO와 함께 검토해야 한다.

1. 동의 수집 사용 전에 받았는가

PIPA는 개인정보 수집·이용 시 사전 동의를 요구한다. 필수 항목과 선택 항목을 구분해서 별도 체크박스로 받아야 한다. GDPR도 동의는 “freely given, specific, informed, unambiguous"여야 한다고 적고 있다. 사전 체크된 박스는 동의로 인정되지 않는다.

구현 포인트:

  • 회원가입 화면에서 “전체 동의” 단일 체크박스만 두지 않는다. 필수 항목과 선택 항목(마케팅 등)을 분리한다.
  • 동의 일자, 동의 버전, 동의한 항목을 서버에 기록한다. 추후 “그때 무엇에 동의했는가"의 입증이 필요하다.
  • Firestore 예시:
1
2
3
4

users/{uid}/consents/{consentId}
  - version: "2026.04"
  - acceptedAt: 2026-05-01T09:00Z
  - items: ["privacy_required", "marketing"]

2. 보관 기간 무한 저장 금지

PIPA는 수집 목적 달성 후 지체 없이 파기를 요구한다. 법령상 보존 기간이 있는 경우(전자상거래 5년 등)만 예외다. GDPR의 storage limitation 원칙도 같은 취지다 목적에 필요한 기간만 보관.

구현 포인트:

  • Firestore TTL 정책 활용: 컬렉션별로 expiresAt 같은 필드를 두고 콘솔에서 TTL을 활성화하면 자동 삭제된다.
  • Firebase Auth 자체에는 TTL이 없으므로 inactive 사용자 정리는 Cloud Functions의 스케줄러로 별도 구현한다.
  • 로그·접속 기록은 90일 이상 보관 시 별도 동의 또는 법적 근거를 명시한다.

3. 삭제 요청 30일 안에 처리되는가

PIPA는 정보주체의 삭제·열람·정정 요청을 받으면 10일 이내 처리를 요구한다. GDPR의 Right to erasure(잊혀질 권리)는 부당 지연 없이, 늦어도 1개월 이내 처리해야 한다.

구현 포인트:

  • 앱 안에 “회원 탈퇴” 메뉴가 필수다. 메일 문의로만 받는 구조는 부적합하다.
  • 탈퇴 버튼이 실제로 무엇을 지우는지 정의해야 한다 사용자 프로필, 게시물, 댓글, 채팅, 푸시 토큰까지.
  • 백업이나 logs 컬렉션에 남는 식별자도 익명화 처리한다.
  • Firebase Auth의 deleteUser() 호출 후 Firestore의 사용자 데이터는 Cloud Functions의 onDelete 트리거로 cascading 삭제하는 패턴이 안정적이다.

4. 미성년자 별도 동의가 필요한가

PIPA: 만 14세 미만은 법정대리인 동의가 필수. GDPR: 만 16세 미만(국가별로 13~16세). 부모 동의 필수.

구현 포인트:

  • 가입 시 생년월일을 받아 미성년자 여부를 자동 판별한다.
  • 미성년자 분기에서는 보호자 이메일/연락처를 추가로 입력받고, 보호자에게 인증 메일을 발송한다 → 보호자가 클릭해야 가입 완료.
  • 사용자 전원이 미성년자인 도메인(예: 학교 앱)이라면 가입 시 학교 인증을 동의 절차에 통합하는 식의 변형이 필요하다. 일반 앱은 “미성년 비율이 작아도 분기는 무조건 만들어둘 것"이 안전하다.

5. 제3자 제공 어디로 흘러나가는가

PIPA는 제3자 제공 시 별도 동의를 요구한다. 누구에게, 무슨 항목을, 무슨 목적으로 제공하는지 명시해야 한다. GDPR은 third-party processor와 DPA(Data Processing Agreement) 체결을 요구한다.

구현 포인트:

  • Firebase Analytics, Crashlytics, AdMob, 푸시 SDK 등은 모두 제3자 처리자에 해당한다.
  • 처리방침에 사용 중인 SDK 전체 목록과 각각의 데이터 흐름을 명시한다.
  • AdMob 사용 시 IDFA/AAID 수집 여부에 대한 별도 동의가 필요하다 (iOS는 ATT 프롬프트 + 앱 내 동의).
  • EU 사용자가 있다면 Google Analytics 4의 EU 데이터 보호 옵션을 활성화한다.

6. 처리방침 접근 가능한 위치에 있는가

PIPA는 처리방침을 “이용자가 쉽게 확인할 수 있도록” 게시할 것을 요구한다. 앱 내 1~2 탭으로 접근 가능해야 한다. GDPR의 transparency 원칙 역시 데이터 수집 시점에 privacy notice 제공을 요구한다.

구현 포인트:

  • 회원가입 화면에 “처리방침 보기” 링크 + 탭 시 풀스크린으로 표시한다.
  • 설정 메뉴에 “개인정보 처리방침"과 “이용약관” 두 개 모두 노출한다.
  • 외부 URL이 아닌 앱 내부에서 렌더하는 편이 안정적이다 네트워크가 끊겨도 보여야 하기 때문이다. Markdown을 번들링하는 방식을 권장한다.

7. 책임자 표기 누구에게 문의해야 하는가

PIPA는 개인정보 보호책임자(CPO)의 이름·소속·연락처를 명시하도록 한다. GDPR은 DPO 임명이 의무인 경우(공공기관, 대규모 모니터링 등)에 한해 연락처 공개를 요구한다.

구현 포인트:

  • 처리방침 마지막에 다음 형식으로 표기한다:
1
2
3
4
5

개인정보 보호책임자
- 성명: 홍길동
- 소속: 한솔개발팀
- 이메일: privacy@example.com
- 전화: 02-XXX-XXXX
  • 1인 개발자라면 본인이 책임자다. 이메일은 개인 주소보다 별도 도메인(privacy@yourdomain.com)이 낫다 회원가입용 메일과 분리되어야 식별이 쉽다.

마무리

체크리스트 형식으로 적었지만 각 항목의 구현은 단순하지 않다. 특히 4번(미성년자)과 5번(제3자 제공)은 모바일 앱에서 잘 빠지는 영역이라 출시 전 별도 점검이 필요하다.

이 글은 PIPA·GDPR 모두를 만족시키려는 사람의 기준이다. 한쪽 시장에만 출시할 거라면 해당 법령만 정확히 따르는 편이 작업량이 줄어든다.

© 2026 monkshark.dev