기술

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