
목차
CDP(고객 데이터 플랫폼)를 도입하거나 운영할 때, 가장 복잡하고 중요한 부분이 바로 '데이터 정책'입니다. 데이터 플랜, 보존 기간, 삭제 절차, 권한 관리 등 신경 써야 할 항목이 많아 자칫하면 내부 감사나 규정 준수(Compliance) 리스크에 노출될 수 있습니다.
이 글에서는 복잡한 CDP 데이터 정책을 한 번에 정리할 수 있는 핵심 체크리스트를 공유합니다. 이 글의 결론은 명확합니다. "표준 데이터 정책 템플릿을 만들어두고, 예외적인 경우만 따로 관리하여 리스크를 최소화하는 것"입니다.
1. 데이터 플랜(스키마) 수립: 모든 데이터의 청사진
가장 먼저 해야 할 일은 '데이터 플랜'을 수립하는 것입니다. 이는 우리 회사의 모든 제품과 채널에서 사용할 공통 데이터 사전(Data Dictionary)을 정의하는 것과 같습니다. 데이터 플랜을 통해 데이터 거버넌스를 강화하고, 데이터 수집 단계에서부터 일관성을 확보할 수 있습니다.
- 원칙: 이벤트와 속성(Property) 스키마를 버전별로 명확하게 고정합니다. 예를 들어, mParticle의 Data Plan 기능은 사전에 정의된 계획과 일치하지 않는 데이터의 수집을 차단하거나 검증하는 강력한 도구를 제공합니다.
- 최소 수집 원칙: 개인정보(PII)는 수집 용도와 보존 목적이 명확할 때만 동의하에 수집해야 합니다.
- 실행: 워크스페이스별로 데이터 플랜 버전을 관리하고, 변경 사항은 PR(Pull Request) 기반의 승인 절차를 통해 운영하는 것이 좋습니다.
2. 데이터 보존 및 삭제 정책: '언제까지'와 '어떻게'의 기준
데이터를 얼마나 보관할지는 시스템의 한계가 아닌, 명확한 정책에 따라 결정되어야 합니다.
- 보존 기간은 정책으로 통제: Treasure Data는 고객이 직접 데이터 만료 및 삭제 정책을 설정하도록 하여 사실상 보존 기간에 제한을 두지 않습니다. 필요에 따라 테이블 단위로 만료 기간을 관리할 수 있습니다.
- 플랫폼 정책 확인: 반면, Segment는 2025년 4월 15일부터 서비스 전반의 일관성과 규정 준수를 위해 롤링 삭제 등 보존 정책을 일괄 적용합니다. 장기 데이터는 데이터 웨어하우스 같은 외부 저장소로 이관하는 것을 권장합니다.
- DSAR(데이터 주체 권리) 경로 확보: 사용자가 데이터 삭제나 열람을 요청할 경로를 마련해야 합니다. Segment의 삭제·억제(Deletion & Suppression) API나 Treasure Data의 DSAR 폼 등이 좋은 예시입니다.
3. 권한·역할·승인 정책: '누가' 데이터를 다룰 것인가
데이터 접근 권한은 '최소 권한의 원칙'에 따라 역할 기반으로 관리해야 합니다.
- 권한 단계 분리: 권한을 ‘보기’, ‘질의(쿼리)’, ‘내보내기’, ‘외부 전송’ 등 단계별로 세분화하여 관리합니다.
- 중요 작업은 2인 승인: 데이터 삭제, 억제, 만료 기간 변경 등 민감한 작업은 데이터 오너와 보안/컴플라이언스 담당자의 2인 승인 체계를 갖추는 것이 안전합니다.
- 역할군 정의: 운영(데이터 라우팅, 외부 전송), 개발(스키마 관리), 거버넌스(보존/동의/감사 승인) 세 가지 역할군으로 나누어 가이드라인을 수립합니다.
4. 반드시 확인해야 할 예외 및 제외 조건
표준 정책만큼 중요한 것이 바로 예외 관리입니다. 아래 항목들은 반드시 체크해야 합니다.
- 서드파티 전송 금지 필드: 법률이나 계약에 따라 외부 전송이 금지된 필드(예: 주민등록번호, 결제 토큰 원문) 목록을 만드세요.
- 광고 ID 및 쿠키 동의 철회: 사용자가 광고 ID 수집에 대한 동의를 철회(Opt-out)하면, 해당 ID의 외부 전송을 즉시 차단하고 리셋해야 합니다. Segment의 Privacy Portal이나 삭제 도구를 활용해 억제 목록을 관리할 수 있습니다.
- 데이터 주체 요청 SLA: 삭제/열람 요청 접수부터 검증, 시스템 전파까지의 처리 기한(SLA, 예: 30일 이내)과 담당자를 명확히 지정해야 합니다.
- 권한 상승 승인: 임시로 높은 권한이 필요할 경우, 24~72시간의 유효 기간을 설정하고 모든 승인 과정을 감사 로그로 남겨야 합니다.
- 개발 환경 분리: 샌드박스(개발 환경)는 프로덕션(운영 환경)과 완전히 분리하고, 합성 데이터나 익명화된 데이터만 사용하도록 규칙을 정합니다.
5. 감사 로그 및 증빙 절차
모든 정책 변경과 데이터 처리 기록은 추후 감사에 대비해 반드시 증빙 자료로 남겨야 합니다.
- 변경 이력 통합 관리: 데이터 보존, 만료, 삭제, 권한 변경과 관련된 모든 티켓, 승인, 실행 로그를 단일 저장소에 보관합니다.
- DSAR 처리 산출물: 사용자 요청 처리 시, 요청 내용, 신원 확인, 처리 결과, 시스템 증적(예: API 호출 로그, 배치 리포트)을 PDF 등으로 스냅샷을 만들어 보관합니다.
- 플랫폼 활동 기록: Segment나 Treasure Data 콘솔에서 수행한 조치나 API 호출 이력을 보관하여 감사 증빙 자료로 확보합니다.
6. 오류 처리 및 데이터 정제
데이터 파이프라인에서 발생하는 오류를 처리하고 데이터를 깨끗하게 유지하는 절차도 필요합니다.
- 실패 데이터 격리: 외부 시스템으로 데이터 전송에 실패했거나 스키마가 일치하지 않는 이벤트는 별도의 격리 큐(Quarantine Queue)로 보내 재처리하거나 폐기합니다.
- 삭제 후 재수집 방지: 사용자가 데이터 삭제를 요청한 경우, 억제 목록(Suppression List)을 활용하여 해당 사용자의 데이터가 다시 수집되지 않도록 데이터 유입 단계에서 필터링해야 합니다.
- 정책 변경 시 유예 기간: 데이터 보존 기간 등 주요 정책을 변경할 때는, 영향을 받는 리포트나 파이프라인을 분석할 ‘유예 기간’을 두고 배포하는 것이 안전합니다.
의사결정 매트릭스 (참고용 템플릿)
복잡한 정책을 쉽게 결정할 수 있도록 간단한 의사결정표를 활용해 보세요.
정책 축 비교표
항목 | 상태값 | 근거 문서 |
---|---|---|
데이터 플랜/스키마 | 필수 | mParticle Data Planning (런타임 차단/검증) |
보존 기간 | 필수 | Segment 보존/삭제 정책, TD 보존 정책 (고객 통제) |
삭제·익명화 | 필수 | Segment Deletion/Suppression API, TD DSAR |
권한·역할 | 권장 | 내부 R&R 정책 |
로그·감사 | 필수 | DSAR 처리·정책 변경 증빙 |
운영 시나리오별 의사결정표
이벤트 유형 | 보존 기간 | 삭제 트리거 | 예외 승인자 | 감사 증빙 |
---|---|---|---|---|
개인정보(PII) | 3~5년 (법정 기간 우선) | DSAR, 계약 종료 | 보안/법무 | 삭제 API 호출 로그, 리포트 |
행동 데이터 | 1~2년 | 동의 철회, 플랜 미일치 | 데이터 오너 | 라우팅 차단, 버전 기록 |
결제 데이터 | 5년 | 환불 완료, 정산 종료 | 재무/보안 | 회계 증빙 + 삭제 배치 로그 |
광고 데이터 | 6~13개월 | 옵트아웃, ID 리셋 | 마케팅/보안 | 억제 목록, 전송 차단 로그 |
자주 묻는 질문 (FAQ)
Q1: 데이터 보존 기간의 기본값은 어떻게 설정해야 하나요?
A1: 시스템의 기본값을 따르기보다, 정책상의 기본값을 먼저 정의하는 것이 좋습니다. 예를 들어, ‘행동 데이터는 12개월, 결제 데이터는 5년’과 같이 기준을 세우고, 예외적인 경우에만 테이블이나 도메인별로 기간을 조정하세요.
Q2: 사용자가 데이터 삭제를 요청한 후, 데이터가 다시 수집되는 것을 어떻게 막나요?
A2: 억제(Suppression) 목록과 동의 상태 값을 데이터 유입(Ingestion) 단계의 필터링 규칙에 필수로 적용해야 합니다. 이를 통해 삭제된 사용자의 데이터가 재유입되는 것을 원천적으로 차단할 수 있습니다.
Q3: 샌드박스(개발 환경) 데이터도 보존 규칙이 필요한가요?
A3: 네, 필요합니다. 샌드박스에는 합성(Synthetic) 데이터나 익명화된 데이터만 사용하고, 기본 7일에서 30일 후 자동으로 만료 및 폐기되는 규칙을 적용하는 것이 좋습니다.
최종 체크리스트
CDP 데이터 정책을 수립할 때, 아래 5가지 항목을 최종적으로 점검해 보세요.
- 서드파티 전송 금지 필드 목록 (법적/계약상 근거 포함)
- 광고 ID·쿠키 동의 관리 철회 시 실시간 전송 차단 로직
- 데이터 주체 요청(삭제/열람) SLA 및 담당자 지정
- 중요 권한(Export/Deletion) 상승 시 2인 승인 체계
- 샌드박스와 프로덕션 환경의 완전 분리 및 데이터 익명화 규칙
함께 읽으면 좋은 글
면책 조항: 이 글에 포함된 정보는 예시이며, 각 플랫폼의 정책이나 요금은 변경될 수 있습니다. 실제 적용 시에는 반드시 최신 공식 문서를 확인하시기 바랍니다.
공식 출처