개인정보 처리: masking, tokenization, pseudonymization, retention

개인정보를 어떻게 다루어야 하는가

데이터 플랫폼이 커질수록 개인정보(PII, Personally Identifiable Information)를 다루는 테이블과 파이프라인이 늘어난다. 이름, 이메일, 전화번호, 주민등록번호, IP 주소, 결제 정보는 규정 위반과 침해 사고의 공통 분모다.

DBA와 데이터 엔지니어가 맞닥뜨리는 실제 질문은 이렇다.

• 분석팀에 개발용 DB 덤프를 줄 수 있는가? 그냥 주면 안 된다.
• 고객이 탈퇴했다. 어디에 이름이 남아 있는가? 삭제 범위를 어떻게 증명하는가?
• 머신러닝 팀이 원본 데이터를 달라고 한다. 어떻게 줘야 하는가?

이 장은 masking, tokenization, pseudonymization의 차이와 적용 시점, 그리고 데이터 보존 정책(retention)을 운영 관점에서 정리한다.

1. PII란 무엇인가: 직접 식별자와 간접 식별자

직접 식별자(direct identifier)는 단독으로 개인을 특정할 수 있다. 이름, 주민등록번호, 여권번호, 이메일, 전화번호가 해당한다.

간접 식별자(quasi-identifier)는 단독으로는 특정이 어렵지만 조합하면 특정 가능해진다. 생년월일 + 성별 + 우편번호 세 가지만 조합해도 대다수 개인이 식별된다는 연구가 있다. IP 주소, 기기 fingerprint, 위치 좌표, 구매 패턴도 간접 식별자다.

통제를 설계할 때 직접 식별자만 보고 끝내면 안 된다. 간접 식별자의 조합 가능성을 함께 검토해야 한다.

2. 세 가지 기법의 차이: masking, pseudonymization, tokenization

용어가 혼용되는 경우가 많아 구분이 필요하다. 핵심은 가역성(reversibility) 과 원본 형식 보존(format preservation) 이다.

2.1 Masking (마스킹)

마스킹은 PII를 비가역적으로 제거하거나 치환하는 기법이다. 원본 값을 복원할 수 없다. 주로 비프로덕션 환경(개발, QA, 분석 샌드박스) 에 데이터를 제공할 때 사용한다.

마스킹의 제약: 조인 키가 마스킹되면 테이블 간 관계가 깨진다. 예를 들어 user_id는 마스킹하면 안 되는 경우가 많다. 이때는 pseudonymization이나 tokenization이 필요하다.

2.2 Pseudonymization (가명처리)

GDPR에서 정의하는 pseudonymization은 PII를 직접 식별자 없이는 특정인을 찾을 수 없는 값으로 대체하되, 별도 보관된 추가 정보(mapping table)를 사용하면 원본을 복원할 수 있는 기법이다. 즉, 가역적이지만 접근 제어된 변환이다.

가명처리된 데이터는 GDPR 하에서 여전히 개인정보로 간주된다. 단, 원본 대비 낮은 위험 등급을 받아 일부 처리 제한이 완화된다.

2.3 Tokenization (토크나이제이션)

토크나이제이션은 PII를 의미 없는 랜덤 토큰(token) 으로 대체하되, 원본-토큰 매핑을 토큰 볼트(Token Vault) 에 안전하게 보관하는 방식이다. pseudonymization과 구조적으로 유사하지만, 몇 가지 특성이 다르다.

FPE(Format-Preserving Encryption): 신용카드 번호 4111-1111-1111-1111을 4382-9017-2843-6591처럼 카드 번호 형식을 유지한 채 토크나이징한다. 기존 DB 스키마(컬럼 타입, 길이 제약)를 변경하지 않고 적용할 수 있다.

2.4 세 기법 비교

3. Anonymization과의 차이: GDPR 관점

익명화(anonymization) 는 원본을 어떤 수단으로도 특정인에 귀속시킬 수 없도록 비가역적으로 변환한 것이다. 익명화에 성공하면 GDPR의 적용 대상에서 벗어난다.

pseudonymization은 매핑 테이블이 존재하는 한 개인정보다. 마스킹도 불완전하게 적용되면(간접 식별자 조합) 여전히 개인정보일 수 있다. 익명화는 "재식별이 불가능하다"는 것을 입증해야 하기 때문에 실무에서는 완전한 익명화를 달성하기 어렵다.

실무 원칙: 완전 익명화를 주장하려면 그 근거를 문서로 남겨야 한다. 근거가 없으면 가명처리로 다루는 것이 안전하다.

4. 데이터 보존 정책 (Retention Policy)

retention policy는 데이터를 얼마나 오래 보관할 것인지, 보관 기간이 지나면 어떻게 처리할 것인지를 정한 규칙이다. 단순히 오래된 데이터를 지우는 문제가 아니다.

4.1 왜 retention이 어려운가

개인정보는 여러 곳에 복사된다.

• 운영 DB → replica → 백업 → S3 object storage → DW → BI 캐시 → 로그
• 파이프라인이 복잡할수록 PII 복사본의 위치가 늘어난다

"DB에서 삭제했다"고 해도 S3 Parquet 파일, Kafka 토픽, Elasticsearch 인덱스, 로그 파일에 원본이 남아 있는 경우가 흔하다.

4.2 GDPR과 CCPA의 보존 요건

GDPR 핵심 원칙: 수집 목적에 필요한 기간을 초과해 개인정보를 보관해서는 안 된다(storage limitation, Art.5(1)(e)). GDPR Art.17은 "잊혀질 권리(right to erasure)"를 부여한다.

CCPA: 소비자가 개인정보 삭제를 요청하면 사업자와 서비스 제공자는 이를 이행해야 한다. 삭제 범위에는 서드파티에 공유된 데이터도 포함된다.

4.3 운영 DB의 논리적 삭제 vs 물리적 삭제

논리적 삭제(soft delete): deleted_at 컬럼을 표시하고 실제 행은 남긴다. 쿼리 편의성과 감사 추적을 위해 많이 쓰이지만, PII 삭제 요건에 부합하지 않는다. 잊혀질 권리 요청이 오면 논리적 삭제로는 불충분하다.

PII 컬럼 masking + 식별자 유지: name, email 등 PII 컬럼만 NULL 처리하거나 마스킹하고 user_id는 유지한다. 통계·집계 쿼리의 무결성을 유지하면서 PII를 제거하는 절충안이다.

완전 물리 삭제: DELETE FROM users WHERE user_id = ? 후 관련 복사본(replica, 백업, 파생 데이터)까지 삭제 확인. 어렵지만 규정 측면에서 가장 안전하다.

4.4 Data Lake에서의 삭제

S3 Parquet 파일에서 특정 사용자 데이터를 삭제하는 것은 RDBMS 행 삭제보다 훨씬 복잡하다. 파일 자체를 재작성해야 한다.

Apache Iceberg/Delta Lake의 MERGE 활용: Row-level delete를 지원해, 특정 user_id 행을 삭제 후 compaction으로 파일 재작성 가능하다.

-- Iceberg: 특정 사용자 데이터 삭제
DELETE FROM events WHERE user_id = 1001;
-- 이후 OPTIMIZE TABLE로 파일 재작성

주의: Iceberg/Delta의 time travel과 snapshot은 과거 파일을 보관한다. 완전 삭제를 위해서는 오래된 스냅샷까지 VACUUM 또는 expire_snapshots로 정리해야 한다.

5. 파이프라인 내 PII 처리 설계

5.1 PII 분류 태깅

데이터 카탈로그(Amundsen, DataHub, Apache Atlas)에서 PII 컬럼에 태그를 부착한다. 이 태그가 있으면 파이프라인이 자동으로 마스킹을 적용하거나, 접근 정책을 다르게 설정한다.

-- dbt 메타데이터 태깅 예시 (schema.yml)
-- columns:
--   - name: email
--     meta:
--       pii: true
--       masking: sha256_hash

5.2 Development/Test 환경 데이터 제공 규칙

운영 DB의 덤프를 그대로 개발 환경에 복사하는 관행은 PII 침해다.

• 정책: 개발/QA 환경에는 반드시 마스킹된 데이터만 제공
• 방법: 운영 → 마스킹 파이프라인 → 개발 DB의 단방향 흐름
• 도구: Faker, Mockaroo, AWS DMS Data Masking, dbt Seed, 사내 스크립트

5.3 ML 파이프라인과 가명처리

ML 모델 학습에 실제 사용자 데이터가 필요한 경우, pseudonymization을 적용해 원본과 분리한다. 모델이 pseudo_id로 학습하면 모델 자체에 사용자 PII가 내재화되지 않는다.

6. 운영 체크리스트

마무리: 처리 목적이 사라지면 데이터도 사라져야 한다

마스킹, 가명처리, 토크나이제이션은 "데이터를 사용하면서도 리스크를 줄이는" 방법이다. 보존 정책은 "사용이 끝난 데이터는 버린다"는 원칙이다. 이 두 가지가 조합될 때 진정한 PII 통제가 된다.

DBA와 데이터 엔지니어가 흔히 놓치는 것은 DB 한 곳에서의 처리가 파생 복사본까지 자동으로 적용되지 않는다는 점이다. PII는 복사된 곳을 따라다닌다. 데이터가 어디에 흘러갔는지를 파악하는 lineage가 없으면 삭제 요청 하나도 완전히 처리하기 어렵다.

다음 장에서는 누가 언제 어떤 데이터에 접근했는지를 기록하고 검토하는 감사 로그(audit log)와 접근 검토(access review)를 다룬다.

References

• GDPR Article 4(5), "Pseudonymisation": https://gdpr.eu/article-4-definitions/
• GDPR Article 17, "Right to erasure": https://gdpr.eu/right-to-be-forgotten/
• NIST SP 800-188, "De-Identifying Government Datasets": https://csrc.nist.gov/pubs/sp/800/188/final
• NIST SP 800-38G, "Recommendation for Block Cipher Modes of Operation: Methods for Format-Preserving Encryption": https://csrc.nist.gov/pubs/sp/800/38/g/r1/final
• Databricks, "Handling Right to be Forgotten in GDPR and CCPA using Delta Live Tables": https://www.databricks.com/blog/handling-right-be-forgotten-gdpr-and-ccpa-using-delta-live-tables-dlt
• Protecto, "Top PII Data Masking Techniques: Pros, Cons & Use Cases": https://www.protecto.ai/blog/top-5-pii-data-masking-techniques/
• k2view, "Pseudonymization vs Tokenization: Benefits and Differences": https://www.k2view.com/blog/pseudonymization-vs-tokenization/
• PCI Security Standards Council, "PCI DSS v4.0 Quick Reference Guide": https://www.pcisecuritystandards.org/document_library/
• Databricks Documentation, "Prepare your data for GDPR compliance": https://docs.databricks.com/aws/en/security/privacy/gdpr-delta