GDPR 안전 파이프라인: 저장 전 PII 익명화
2026년 업데이트
dbt에서 PII 컬럼에 태그를 달았습니다. Snowflake에 동적 마스킹을 설정했습니다. GDPR을 준수하고 있다고 생각합니다.
원본 콘텐츠는 여전히 마스킹 없이 웨어하우스에 도달합니다. 마스킹은 쿼리 시점에 실행됩니다. 마스킹되지 않은 콘텐츠가 원본(raw) 스키마에 저장됩니다. 원본 스키마에 접근 권한이 있는 사람은 누구나 읽을 수 있습니다. dbt 모델은 마스킹 정책이 존재하기 전에 실행되었습니다. 예전에 수집된 테이블은 한 번도 마스킹되지 않았습니다.
"마스킹 정책이 있다"와 "파이프라인이 안전하다" 사이의 간격이 바로 GDPR 위반이 발생하는 곳입니다.
GDPR에서 anonym.legal이 어떻게 지원하는지는 컴플라이언스 개요를 참조하세요.
ELT 파이프라인이 PII를 노출하는 방식
추출-로드-변환(ELT) 패턴이 이제 표준입니다. 먼저 원본 데이터를 웨어하우스로 로드하고, 변환은 나중에 옵니다. 단계는 다음과 같습니다:
- 추출: 소스 시스템이 모든 필드를 내보냅니다. Salesforce CRM, Stripe 결제, Intercom 지원 — 모든 것이 나갑니다.
- 로드: 소스 데이터가 웨어하우스 수집(ingestion) 스키마에 도달합니다. Snowflake, BigQuery, Redshift 모두 동일하게 작동합니다. 모든 PII 필드가 포함됩니다.
- 변환: dbt 모델이 데이터를 분석을 위해 정제하고 조인합니다.
수집 레이어에는 완전한 개인 정보가 저장됩니다. 이름, 이메일 주소, 전화번호, 결제 정보, 지원 티켓 텍스트. 많은 팀에서 엔지니어와 분석가가 원본 스키마 접근 권한을 갖고 있습니다. 언제든지 이 테이블을 쿼리할 수 있습니다.
Snowflake의 태그 기반 마스킹은 쿼리 시점에 도움이 됩니다. 하지만 제대로 설정된 다운스트림 모델에만 적용됩니다. 예전에 수집된 테이블은 마스킹하지 않습니다. 직접 스키마 쿼리를 차단하지 않습니다. 모든 모델과 대시보드에 태그를 달아야 합니다. 스키마가 성장함에 따라 이 부담도 커집니다.
로드 전 익명화
파이프라인 레벨에서 PII를 익명화하면 원본 레이어 위험이 제거됩니다. 콘텐츠가 웨어하우스에 도달하기 전에 처리하세요.
ETL 방식 (사전 로드 익명화):
- 소스 시스템에서 추출
- 익명화 단계 실행
- 깨끗한 결과를 웨어하우스로 로드
웨어하우스는 마스킹되지 않은 PII를 받지 않습니다. 수집 스키마에는 깨끗한 콘텐츠만 저장됩니다. 다운스트림 모델, 대시보드, 직접 쿼리 모두 깨끗한 결과로 작동합니다.
두 가지 주요 방식이 있습니다.
옵션 1 — API 통합:
웹훅이나 스트리밍 내보내기가 있는 시스템의 경우, 항목을 먼저 anonym.legal API를 통해 라우팅합니다. Intercom을 떠나는 지원 티켓은 웨어하우스 전에 API를 통해 전달됩니다. Stripe 내보내기도 동일하게 처리됩니다.
POST /api/anonymize
{
"text": "고객 John Smith (john@example.com)이 보고했습니다...",
"entities": ["PERSON", "EMAIL_ADDRESS", "PHONE_NUMBER"],
"method": "replace"
}
옵션 2 — 배치 전처리:
일별 또는 주별 CSV/JSON 파일 내보내기의 경우, 로드 전에 배치 처리를 통해 파일을 실행합니다.
Airflow DAG 구조:
extract_task >> anonymize_batch_task >> load_to_warehouse_task
익명화 작업이 파일을 업로드하고 깨끗한 버전을 돌려받습니다. 로드 작업은 나머지를 처리합니다.
하위 처리자 및 데이터 흐름 세부 사항은 보안 관행 페이지를 참조하세요.
dbt 컬럼 태그가 하는 것과 하지 않는 것
dbt를 사용하면 PII 컬럼에 태그를 달 수 있습니다:
models:
- name: stg_customers
columns:
- name: email
tags: ['pii', 'email']
- name: full_name
tags: ['pii', 'personal_data']
태그로 할 수 있는 것:
- PII가 어디에 있는지 문서화
- 다운스트림 마스킹 정책 트리거 (웨어하우스 레벨 설정 필요)
- Secoda 같은 도구로 계보 추적
태그로 할 수 없는 것:
- 원본 스키마의 수집된 테이블 마스킹
- 직접 테이블 쿼리 차단
- 로드 시점에 데이터 익명화
- 오래된 데이터를 소급하여 마스킹
dbt 컬럼 태그는 거버넌스 도구입니다. PII가 어디에 있는지 보여줍니다. GDPR 제32조가 요구하는 "적절한 기술적 조치"를 적용하지 않습니다.
Snowflake 마스킹의 한계
Snowflake의 동적 마스킹은 쿼리 시점에 사용자로부터 컬럼 콘텐츠를 숨깁니다. 프로덕션 사용에 강력한 제어입니다. 하지만 명확한 한계가 있습니다.
주요 한계:
- 모든 새 컬럼에는 명시적 정책이 필요
- 스키마 변경 시 정책을 업데이트할 때까지 새 컬럼이 마스킹되지 않을 수 있음
- SYSADMIN 및 ACCOUNTADMIN 역할이 마스킹을 우회할 수 있음
- 임포트 작업은 종종 마스킹을 건너뛰는 높은 권한으로 실행됨
- 정책이 설정되기 전에 로드된 이전 데이터는 일반 형식으로 저장됨 — 정책은 쓰기 시점이 아닌 읽기 시점에 실행됨
쿼리 시점의 마스킹으로는 충분하지 않습니다. 데이터는 저장되기 전에 깨끗해야 합니다.
컴플라이언스 문서화
GDPR의 책임 규정은 증명을 요구합니다. 말만으로는 충분하지 않습니다. 엔지니어링 팀에게 이것은 서면 기록을 의미합니다.
처리 활동 기록(ROPA): 고객 정보가 분석 웨어하우스로 로드되기 전에 익명화된다고 문서화하세요. 익명화 단계는 GDPR에 따른 처리 활동입니다.
기술적 보호 조치 메모: 파이프라인이 대상으로 하는 엔티티 유형을 기록하세요. 사용된 익명화 방법을 기록하세요. 배치 실행 로그가 이것을 무료로 제공합니다.
데이터 계보: Secoda 또는 dbt의 내장 계보를 통해 소스 테이블이 분석 모델에 도달하기 전에 익명화 단계를 거친다는 것을 보여줄 수 있습니다. 이것이 감사 추적입니다.
벤더 레지스터: 익명화 서비스는 하위 처리자입니다. 그들의 DPA와 개인정보 보호 정책이 벤더 레지스터에 있어야 합니다.
구현 단계
dbt와 Snowflake 파이프라인의 경우:
1단계: 원본 레이어 감사
개인 정보를 보유하는 테이블을 찾습니다. dbt 컬럼 태그 또는 카탈로그에서 PII 태그된 테이블을 쿼리합니다.
2단계: 익명화 범위 설정
각 소스 테이블에 대해 어떤 컬럼이 PII를 보유하는지 결정합니다. 그런 다음 어떤 것이 익명화가 필요하고 어떤 것이 가명화가 필요한지 결정합니다. 지원 티켓 본문: 익명화. 주문 ID: 조인 키를 유지하기 위해 가명화. 타임스탬프: 시계열 분석을 위해 그대로 유지.
3단계: 구현 방식 선택
배치 내보내기를 사용하는 소규모 팀: 로드 전에 배치 파일 처리를 사용합니다. 엔지니어링 팀이 있는 경우: Airflow 또는 Prefect에서 API 통합을 구축합니다.
4단계: 테스트 및 검증
실제 적용 전에 샘플에서 익명화를 실행합니다. dbt 모델이 여전히 작동하는지 확인합니다. 일부 모델은 이메일로 조인합니다. 이것들은 일관된 대체 값이 필요합니다. 가명화는 조인 키를 유지합니다. 비식별화(Redact)는 이것을 파괴합니다.
5단계: 오래된 원본 테이블 처리
익명화가 적용되기 전에 로드된 콘텐츠는 소급 처리가 필요합니다. 내보내기, 익명화, 재로드. 테이블당 일회성 작업입니다.
결론
태그 기반 마스킹은 PII가 어디에 있는지 보여줍니다. 스키마 접근 권한이 있는 사용자가 읽는 것을 막지 않습니다. 실제 GDPR 컴플라이언스를 위해서는 PII가 웨어하우스에 도달하기 전에 깨끗해야 합니다. 이것은 수집 레이어를 프로덕션 레이어만큼 안전하게 만듭니다.
이것은 컬럼 태깅보다 어렵습니다. 하지만 "적절한 기술적 조치"가 실제로 의미하는 바입니다.