데이터 프라이버시 실전 - GDPR·CCPA·PIPA와 암호화·마스킹·삭제권 처리 완벽 가이드

들어가며

지난 #137 SIEM·SOAR로 보안 6단 방어선이 마무리됐습니다. 보안이 "우리 시스템을 지키는 일"이었다면, 오늘부터 다루는 프라이버시는 "그 시스템 위에 있는 사람의 데이터를 다루는 책임"입니다. 차원이 다른 문제입니다.

2025년 한 해 한국 개인정보보호위원회가 부과한 과징금 합계는 약 418억 원이었고, EU에서는 GDPR 누적 과징금이 65억 유로를 넘었습니다. 그런데 사고를 보면 패턴이 비슷합니다. 모르고 수집한 PII가 로그에 그대로 찍히고, 암호화되지 않은 백업이 외부 객체스토리지에 노출되고, 삭제 요청을 처리할 절차가 없어 6개월 묵혀두는 식입니다. 설계 단계에서 답이 없으면, 사고는 시간 문제입니다.

오늘 글에서는 백엔드 개발자가 실제로 코드와 인프라 위에서 풀어야 하는 프라이버시 과제를 정리합니다.

• 1부 - GDPR·CCPA·PIPA 핵심 차이
• 2부 - 데이터 분류 - PII·민감정보·식별자
• 3부 - 저장 시 암호화(At Rest) + KMS 키 관리
• 4부 - 전송·사용 시 암호화(In Transit/In Use)
• 5부 - 마스킹·토큰화·해싱·차등 프라이버시
• 6부 - 정보주체 권리 처리(열람·정정·삭제·이동)
• 7부 - 동의 관리(CMP)와 다크 패턴 회피
• 8부 - 로그·LLM 파이프라인의 PII 누출 방지
• 9부 - Spring Boot 실전 코드
• 10부 - 사고 신고 의무와 흔한 실수

1. GDPR·CCPA·PIPA 핵심 차이

전 세계 데이터 보호법은 EU GDPR(2018), 미국 CCPA/CPRA(2020/2023), 한국 개인정보보호법(PIPA, 2020 전면개정·2023 강화)이 사실상 표준 기준입니다. 운영하는 서비스가 한 군데라도 이 지역의 사용자를 받으면 그 법이 적용됩니다.

축	GDPR (EU)	CCPA/CPRA (캘리포니아)	PIPA (한국)
적용 대상	EU 거주자 데이터 처리 시 전 세계	캘리포니아 거주자 + 매출/규모 조건	한국 내 처리하는 모든 사업자
법적 근거 모델	합법 처리 근거 6종(동의·계약·법적 의무·중대 이익·공익·정당 이익)	옵트아웃(Sale/Sharing 거부)	원칙적 옵트인 동의
정보주체 권리	열람·정정·삭제·이동·반대·자동결정 거부	열람·삭제·정정·옵트아웃·차별 금지	열람·정정·삭제·처리정지·이동(2024~)
국외 이전	적정성·SCC·BCR 필요	비교적 자유	동의 또는 적정성 인정·계약 등
과징금 상한	전 세계 매출 4% 또는 2천만 유로	위반당 최대 7,500달러(고의)	전체 매출 3% 또는 5천만 원 이상
사고 신고	72시간 이내 감독기관	주(州)법별 상이	72시간 이내 보호위원회+이용자 통지
DPO/CPO	일정 규모 이상 의무	일정 규모 이상 의무	일정 규모 이상 의무

차이가 있어도 실무 코드 레벨에서의 요구는 70% 이상 겹칩니다. "PII를 식별·암호화·최소수집·삭제 가능 상태"로 두는 일은 모든 법의 공통 요구입니다. 따라서 현실적 설계는 가장 까다로운 GDPR 기준에 맞추고, 지역별 차이는 동의·이전·통지에서 분기하는 것이 단순합니다.

1-1. 자주 헷갈리는 용어

• Controller(개인정보처리자) - 처리 목적·수단을 결정. 책임의 1차 주체.
• Processor(수탁자) - Controller 지시 하에 데이터를 처리. 클라우드·SaaS가 흔히 여기에 해당.
• DPA(Data Processing Agreement) - Controller-Processor 간 의무 명시 계약. 누락 시 GDPR 위반.
• DPIA(영향평가) - 고위험 처리 시 사전 평가 의무.

SaaS·LLM API를 쓰는 순간 그 회사가 Processor가 되고, DPA 체결과 적정 보호 조치를 확인할 의무가 생깁니다. 무심코 OpenAI·Anthropic API에 PII를 보내는 것이 실제 사고의 가장 큰 원천 중 하나입니다.

2. 데이터 분류 - PII·민감정보·식별자

모든 프라이버시 통제는 "이 컬럼이 무엇인가"를 아는 데서 시작합니다.

분류	예시	처리 원칙
직접 식별자(Direct Identifier)	이름, 이메일, 전화번호, 주민번호, 사번	암호화 저장, 접근 통제, 마스킹
준식별자(Quasi-Identifier)	생년월일+우편번호+성별, IP, 단말 ID	3개 이상 결합 시 식별 가능 → 가명화
민감정보(Sensitive Data)	건강·유전·생체·범죄·정치·종교·노조·성적 지향	원칙적 처리 금지, 명시 동의 필요
특수 보호 데이터	아동(만14세 미만) 정보	법정대리인 동의 필수, 별도 시스템
비식별 정보(Anonymized)	완전 통계화·재식별 불가	법 적용 외 (단, 입증 책임은 사업자)
가명정보(Pseudonymized)	매핑 키로만 복원 가능	여전히 PII로 취급, 일부 활용 완화

2-1. 데이터 카탈로그 자동화

대형 조직에서 사람이 모든 컬럼을 분류하는 것은 불가능합니다. 자동 스캐너로 카탈로그를 생성하고 분기 검증합니다.

도구	강점	특징
OpenMetadata	오픈소스, 자동 PII 태깅	Airflow·Trino 등 통합 풍부
DataHub	LinkedIn 발 OSS, 메타데이터 표준	대규모 카탈로그
Microsoft Purview	Azure 네이티브	분류·라벨·DLP 통합
BigID	상용, ML 기반 PII 자동 탐지	엔터프라이즈
Spectral·Nightfall	코드·로그 PII 스캔	CI 통합

핵심은 "PII 컬럼·필드에 코드 외부에서 라벨을 부여"하는 것입니다. 라벨을 기준으로 암호화·마스킹·접근통제·삭제 정책이 자동 적용되도록 만들면, 새 테이블이 추가돼도 누락이 없습니다.

3. 저장 시 암호화 - At Rest

모든 PII는 디스크에 평문으로 남으면 안 된다는 것이 출발점입니다. 다만 "어느 층에서 암호화하느냐"가 다릅니다.

층	대표 방식	특징
디스크 전체 암호화	EBS·LUKS·BitLocker	운영 단순, 디스크 분실 보호. 앱·DB 어드민에는 평문 노출.
DB 투명 암호화(TDE)	MySQL InnoDB TDE, PostgreSQL pgcrypto	파일 단위 보호. SQL 결과에는 평문.
컬럼 암호화	JPA AttributeConverter, MySQL AES_ENCRYPT	특정 컬럼만 보호. DB 어드민도 평문 못 봄.
애플리케이션 측 암호화	SDK + KMS DEK	가장 강력. 키가 DB와 분리.
토큰화	외부 토큰 볼트 + 매핑 키	PCI-DSS 카드번호 등에 적합. PII 자체가 시스템에서 사라짐.

3-1. KMS + DEK(Envelope Encryption) 패턴

실무에서 가장 자주 쓰이는 구조입니다.

① KMS에 KEK(Key Encryption Key) 보관 (HSM·KMS에서만 사용)
② 애플리케이션이 KMS에 "DEK 발급" 호출
③ KMS는 DEK(평문)와 DEK(암호문) 한 쌍을 반환
④ 앱은 DEK(평문)으로 PII 암호화 후 즉시 메모리에서 소거
⓹ DB에는 [DEK(암호문) + 암호화된 PII]를 함께 저장
⓺ 복호화 시 KMS에 DEK(암호문) → DEK(평문) 변환 요청

이 구조의 장점은 키 회전 비용이 거의 0이라는 것입니다. KEK만 회전하면 되고, 모든 DEK를 일일이 다시 암호화할 필요가 없습니다. 사고 시 "KMS 접근 권한 회수만으로 즉시 데이터 무력화"가 가능한 것도 큰 강점입니다.

3-2. 키 관리의 7가지 원칙

• 키와 데이터를 절대 한 시스템에 두지 않는다 - DB에 평문 키를 같이 보관하면 암호화 자체가 무의미.
• KEK는 KMS·HSM 안에서만 사용 - 평문 KEK가 절대 메모리·로그에 나오지 않게.
• 최소권한 - kms:Decrypt는 필요한 서비스 IAM에만, 사람은 거의 받지 않음.
• 키 회전 - KEK는 1년 주기, DEK는 발급마다 새것.
• 감사 로그 - KMS 호출 전부 CloudTrail/Vault audit으로 SIEM(#137)에.
• BYOK(Bring Your Own Key) - 규제 산업·국외 이전 시 자체 키 반입 검토.
• 키 폐기 절차 - 사고·계약 종료 시 키 삭제만으로 데이터 영구 무력화(Crypto Shredding).

마지막 원칙은 "잊혀질 권리(Right to be Forgotten)"의 가장 깔끔한 구현 수단입니다. 백업·아카이브에 산재한 데이터를 일일이 지우는 대신, 그 사용자 전용 DEK 하나만 폐기하면 모든 사본이 자동으로 복호화 불가가 됩니다.

4. 전송·사용 시 암호화

4-1. 전송 시(In Transit)

서비스 간 통신은 TLS 1.3 + mTLS가 표준입니다. #134 Zero Trust(Istio·SPIFFE)에서 다룬 메시지 워크로드 ID 기반 mTLS가 그대로 프라이버시 통제 수단입니다. 최소 요구는 다음과 같습니다.

• 외부 노출 엔드포인트는 TLS 1.2 이상, 1.3 권장
• 약한 암호화 스위트(RC4, 3DES, MD5) 비활성화
• HSTS·Certificate Pinning
• 내부 통신도 mTLS - "Trust the network"가 가장 흔한 사고 원인

4-2. 사용 시(In Use) - PET

저장과 전송이 안전해도 처리 중(메모리·CPU)의 평문은 별개 위협입니다. 2026년 기준 실용 단계에 진입한 PET(Privacy-Enhancing Technologies)는 다음과 같습니다.

기술	원리	2026년 실용도
Confidential Computing(TEE)	CPU 안 격리 영역(SGX, SEV-SNP, TDX)에서 처리	실서비스 ○ - Azure·AWS Nitro·GCP CC
FHE(완전동형암호)	암호문 상태 그대로 연산	특정 워크로드 한정 △ - 추론·통계 일부
SMPC(다자간 연산)	참여자가 평문을 보지 않고 공동 연산	금융·헬스 PoC △
차등 프라이버시(DP)	통계에 노이즈 추가, 개인 영향 제한	분석·ML 학습 ○ - Apple·Google 채택
연합학습(FL)	모델만 이동, 원본 데이터는 단말	의료·모바일 ○

대부분의 백엔드 시스템에는 TEE + DP 조합이 현실적 출발점입니다. "GPU·CPU에서 평문이 노출될 수 있다"는 위협이 상수인 환경(클라우드·SaaS·LLM)에서 점점 더 표준이 됩니다.

5. 마스킹·토큰화·해싱·가명화

같은 "가리기"라도 목적에 따라 기술이 다릅니다. 혼용하면 사고가 납니다.

기법	가역성	주 용도	주의
마스킹(Masking)	비가역 표시 / 원본은 별도 보존	화면·로그·CS 화면	UI 마스킹만으로는 보안 X (네트워크 스니핑 등)
해싱(Hashing)	비가역(SHA-256+salt+pepper)	비밀번호·식별자 매칭	비밀번호는 반드시 bcrypt/Argon2id, 일반 SHA 금지
토큰화(Tokenization)	가역(중앙 볼트만)	카드번호·민번 등 "흘러다니면 안 되는 값"	토큰 볼트가 단일 실패점
가명화(Pseudonymization)	가역(키 분리)	분석·연구 목적	여전히 PII로 취급. 결합 시 식별 위험
익명화(Anonymization)	비가역	외부 공개·통계	k-익명성/l-다양성/t-근접성 검증 필요
차등 프라이버시	비가역(노이즈)	학습·집계	ε(엡실론) 예산 관리가 핵심

5-1. 마스킹 표준 패턴

이메일   : se***@example.com        (앞 2자 + ***)
전화번호 : 010-****-1234              (가운데 4자리)
주민번호 : 901225-1******             (뒤 7자리)
카드번호 : 5365-****-****-1234        (PCI-DSS, 앞 6+뒤 4만 노출 가능)
이름     : 홍*동 / 홍**(2자), 홍*동(3자) (성+이름 일부)
주소     : 서울특별시 강남구 ***       (행정동 이하 마스킹)

표시 직전(Presentation Layer) 마스킹과 데이터베이스 저장 마스킹을 구분해야 합니다. 콜센터 화면에서만 가리는 것은 화면 마스킹, DB에 마스킹된 형태로만 저장하는 것은 저장 마스킹(=비가역)입니다. 둘은 적용 위치도, 책임도 다릅니다.

5-2. 토큰화 - 카드번호·민번이 시스템에서 사라지게

PCI-DSS 영역에서는 "카드번호를 우리 DB에서 제거"가 사실상 의무입니다. 결제 게이트웨이가 토큰을 발급하면 우리는 토큰만 저장합니다. 같은 패턴을 PII에도 적용할 수 있습니다.

// 결제: 카드번호 → 토큰
String token = paymentGateway.tokenize("5365-1234-5678-9012");
// 우리 DB에는 token만 남음
order.setCardToken(token); // tok_abc123xyz789

// 사용자 식별자 토큰화 (선택)
String userToken = piiVault.tokenize(user.getEmail());
analyticsEvent.setUserRef(userToken); // 분석 시스템에는 토큰만 흘러감

분석·로그·외부 SaaS에는 토큰만 흘려보내고, 원본 매핑은 토큰 볼트(자체 또는 Skyflow·Privacera·Vault)에만 보관합니다. 사고 시 "분석 데이터셋이 유출됐어도 PII는 새지 않았다"라고 말할 수 있는 유일한 구조입니다.

6. 정보주체 권리 처리 - 열람·정정·삭제·이동

법이 보장하는 권리를 API와 프로세스로 구현해야 실제로 행사될 수 있습니다. "이메일로 신청하세요"만으로는 GDPR 기준 미달입니다.

6-1. 권리별 처리 기한과 SLA

권리	GDPR	PIPA	CCPA
열람(Access)	1개월(연장 2개월)	10일	45일
정정(Rectification)	1개월	10일	45일
삭제(Erasure)	1개월	10일	45일
이동(Portability)	1개월	2024년 시행	—
처리 정지/반대	즉시	10일	15일(Sale 옵트아웃)

6-2. 삭제 요청의 진짜 어려움

코드 한 줄로 끝나지 않습니다.

• 프라이머리 DB - 행 삭제 또는 익명화
• 리드 레플리카·캐시(Redis) - 무효화·복제 지연 고려
• 분석 DW(BigQuery·Redshift·ClickHouse) - 적재 파이프라인에 동기화
• 검색 인덱스(Elasticsearch) - 별도 삭제 큐
• 오브젝트 스토리지(S3) 백업 - 라이프사이클 또는 Crypto Shredding
• 로그·SIEM - 일반적으로 보관기간 내 그대로 두되, 식별자 토큰화로 우회
• 외부 SaaS·LLM 캐시 - 각 서비스 API로 삭제 호출 필요

현실적인 구현 패턴은 이벤트 기반 삭제 파이프라인입니다.

POST /privacy/delete-request → privacy.delete.requested 이벤트 발행
   ↓ (각 서비스가 구독)
   - users-svc      : soft delete + DEK 폐기
   - orders-svc     : 사용자 ID → 가명화 토큰
   - analytics-svc  : DW에서 사용자 행 삭제·재집계
   - search-svc     : 인덱스에서 제거
   - mailing-svc    : 외부 SaaS API 호출
   - audit-svc      : 모든 처리 결과 케이스에 기록
   ↓
사용자에게 "처리 완료 보고서" 자동 생성

각 서비스의 처리 결과를 케이스 ID 하나로 묶고 감사 로그에 남기는 것이 핵심입니다. 사고가 났을 때 "우리는 이 시각에 다음 7개 시스템에서 데이터를 지웠습니다"를 입증할 수 있어야 합니다.

6-3. 데이터 이동권(Portability)

사용자가 요청하면 자기 데이터를 구조화된 기계판독 가능 포맷으로 받을 수 있어야 합니다. JSON·CSV가 표준이고, 다음 항목은 의무입니다.

• 본인이 직접 제공한 데이터(가입 정보, 작성 콘텐츠)
• 서비스 사용 과정에서 관찰된 데이터(로그인 이력, 주문 내역)
• 그 데이터의 컨텍스트(필드명·형식·시각)

"우리 알고리즘이 만들어낸 추론 데이터"는 의무 대상이 아닙니다. 다만 캐릭터·아바타 같은 일부 콘텐츠는 다툼의 소지가 있어 사전 가이드라인을 두는 것이 안전합니다.

7. 동의 관리(CMP)와 다크 패턴 회피

동의는 "체크박스 하나"가 아니라 증거가 남는 프로세스입니다. GDPR/PIPA 모두 동의의 4요건을 요구합니다.

• 자유로운(Free) - 거부해도 서비스 본질이 가능해야 함
• 구체적(Specific) - 목적별 분리 동의
• 명확한 안내(Informed) - 처리자·목적·기간 고지
• 적극적(Unambiguous) - 사전 체크된 박스 금지

7-1. 다크 패턴 - 규제 칼날이 향한 사례

패턴	설명	제재 사례
Pre-checked	동의 체크박스 사전 선택	EU CJEU "Planet49" 판결
Cookie Wall	거부 시 사이트 차단	프랑스 CNIL 과징금
비대칭 버튼	"동의" 강조 / "거부" 숨김	EDPB 가이드라인 위반
Bundled Consent	마케팅·필수를 한 번에 묶음	한국 보호위 시정명령
Forced Action	가입 시 마케팅 강제	다수 과징금

7-2. 동의 기록 스키마

{
  "user_id": "u-4892",
  "purpose": "marketing.email",
  "granted": true,
  "granted_at": "2026-04-25T08:23:11Z",
  "channel": "web",
  "ip": "203.0.113.10",
  "ua": "...",
  "version": "privacy-policy@2026-03-12",
  "locale": "ko-KR",
  "text_hash": "sha256:e4b0c44...",
  "withdrawn_at": null
}

특히 당시 보여준 약관 본문의 해시가 중요합니다. 약관이 갱신돼도 "이 사용자는 어떤 텍스트에 동의했는가"를 입증할 수 있어야 합니다. 동의 철회는 즉시 반영되며, 모든 변경 이력이 시계열로 남아야 합니다.

7-3. 도구

• OneTrust·Cookiebot - 글로벌 표준, 지역별 동의 자동 분기
• TrustArc·Usercentrics - 엔터프라이즈
• OpenCMP·Klaro - 오픈소스
• Transcend·Ketch - 권리 처리 통합 플랫폼

2026년 EU Cookie Pledge 이후 "한 번의 거부로 전 사이트 적용" 흐름이 강화되고 있습니다. 개별 사이트가 자체 다이얼로그를 만드는 시대는 점점 끝나가고, 표준 CMP 채택이 사실상 기본값이 되고 있습니다.

8. 로그·LLM 파이프라인의 PII 누출 방지

실제 사고의 다수가 "코드는 안전한데 로그·분석·LLM에서 새는" 패턴입니다.

8-1. 로그 PII 차단 5계명

• 요청 본문 자동 마스킹 - 이메일·전화·카드번호 정규식 → ***
• 예외 스택트레이스에 객체 직접 출력 금지 - DTO toString이 PII 노출 1순위
• 접근 토큰·시크릿 로깅 금지 - #133 Secrets 영역
• 로그 보관기간 정책 - 액세스 30~90일, 보안감사 1년 등 기준 명문화
• 로그 SIEM에서 PII 자동 탐지·격리 - DLP 룰을 SIEM(#137)에 내장

8-2. LLM·AI 파이프라인 - 가장 신선한 위협면

#129 LLM 가드레일·#130 MCP 가드레일에서 다룬 PII 스캐너가 프라이버시 통제와 직접 맞닿는 지점입니다.

위협	예시	대응
학습 데이터에 PII 포함	DB 덤프를 그대로 파인튜닝	익명화·DP·합성 데이터
프롬프트에 평문 PII	고객 문의를 그대로 LLM 호출	전송 전 PII 스캐너·토큰화
외부 LLM API 로그 보관	OpenAI/Anthropic 30일 보관	Zero-Retention 옵션·DPA 체결
모델이 PII 회상	학습 흔적이 응답으로 새어나옴	출력 PII 스캐너·DP 학습
RAG 인덱스 PII 노출	벡터 스토어에 평문 청크	인덱스 단위 ACL·암호화
에이전트 도구 호출	MCP 서버에 사용자 데이터 무차별 전달	MCP 가드레일(#130) 마스킹 정책

2025~2026년 사이 EU AI Act가 단계적 시행에 들어가면서, LLM을 호출하는 행위 자체가 "개인정보 처리"로 분류되고 처리방침에 기재 의무가 생겼습니다. "AI 기능 추가"는 더 이상 마케팅 결정이 아니라 법적 처리 근거를 정리해야 하는 결정입니다.

9. Spring Boot 실전 코드

9-1. JPA AttributeConverter로 컬럼 암호화

@Converter
public class EncryptedStringConverter implements AttributeConverter<String, String> {

    private final AeadCipher cipher; // KMS DEK 기반

    public EncryptedStringConverter(AeadCipher cipher) {
        this.cipher = cipher;
    }

    @Override
    public String convertToDatabaseColumn(String plain) {
        if (plain == null) return null;
        return cipher.encrypt(plain.getBytes(StandardCharsets.UTF_8));
    }

    @Override
    public String convertToEntityAttribute(String cipherText) {
        if (cipherText == null) return null;
        return new String(cipher.decrypt(cipherText), StandardCharsets.UTF_8);
    }
}

@Entity
public class Member {
    @Id Long id;

    @Convert(converter = EncryptedStringConverter.class)
    private String email;       // 암호화 저장

    @Convert(converter = EncryptedStringConverter.class)
    private String phone;       // 암호화 저장

    @Column(length = 64)
    private String emailHash;   // 검색용 결정적 해시(HMAC-SHA256)
}

이메일로 "내 계정 찾기"가 필요하면 결정적 해시 컬럼을 별도로 둡니다. 검색 키는 HMAC-SHA256(email, secret)이고, 평문 이메일은 암호화돼 있어도 검색이 가능해집니다.

9-2. Spring AOP로 응답 마스킹

@Target({ElementType.FIELD})
@Retention(RetentionPolicy.RUNTIME)
public @interface Masked {
    MaskingType type() default MaskingType.EMAIL;
}

public class MemberDto {
    @Masked(type = MaskingType.EMAIL)
    private String email;

    @Masked(type = MaskingType.PHONE)
    private String phone;
}

@Aspect
@Component
public class MaskingAspect {
    @AfterReturning(pointcut = "@within(org.springframework.web.bind.annotation.RestController)",
                    returning = "result")
    public void mask(Object result) {
        MaskingUtils.applyMaskingByAnnotation(result);
    }
}

응답 직전에 어노테이션 기준으로 자동 마스킹되어, 컨트롤러마다 일일이 마스킹 호출을 빠뜨릴 일이 사라집니다. 화면 마스킹 일관성의 표준 패턴입니다.

9-3. 잊혀질 권리 - 이벤트 기반 삭제

@Service
@RequiredArgsConstructor
public class PrivacyService {

    private final ApplicationEventPublisher eventPublisher;
    private final PrivacyCaseRepository caseRepository;

    @Transactional
    public PrivacyCase requestErasure(Long userId, String reason) {
        PrivacyCase pc = caseRepository.save(
            PrivacyCase.start(userId, RequestType.ERASURE, reason)
        );
        eventPublisher.publishEvent(new PrivacyErasureRequested(pc.getId(), userId));
        return pc;
    }
}

@Component
public class UserErasureHandler {
    @TransactionalEventListener
    public void on(PrivacyErasureRequested e) {
        memberRepository.softDeleteAndAnonymize(e.userId());
        kmsClient.scheduleKeyDeletion("dek-user-" + e.userId(), Duration.ofDays(7));
        privacyCaseRepository.markStep(e.caseId(), "users-svc", StepStatus.DONE);
    }
}

각 서비스가 자신의 영역에서 삭제·익명화·키 폐기를 수행하고, 처리 케이스 한 건의 단계별 상태를 케이스 테이블에 기록합니다. 모든 단계가 완료되면 "처리 완료 보고서"를 사용자에게 발급합니다.

9-4. 동의 모듈

@Entity
public class ConsentRecord {
    @Id @GeneratedValue Long id;
    private String userId;
    private String purpose;        // marketing.email, analytics, etc.
    private boolean granted;
    private Instant grantedAt;
    private Instant withdrawnAt;
    private String ip;
    private String userAgent;
    private String policyVersion;  // privacy-policy@2026-03-12
    private String policyTextHash; // SHA-256
    private String locale;
}

@Service
public class ConsentService {
    public void grant(String userId, String purpose, ConsentContext ctx) { /* save */ }
    public void withdraw(String userId, String purpose) { /* mark withdrawn_at */ }
    public boolean isGranted(String userId, String purpose) { /* current state */ }
}

// 사용 예 - 마케팅 메일 발송 직전
if (!consentService.isGranted(userId, "marketing.email")) return;

모든 처리 시점에 "이 처리 목적에 동의가 살아있는가"를 확인하는 호출이 들어가야 합니다. 빠뜨리면 동의 없는 처리가 되어 PIPA·GDPR 위반입니다.

10. 사고 신고 의무와 흔한 실수

10-1. 신고 타임라인

관할	당국 신고	이용자 통지	관련 조항
EU GDPR	72시간 이내	고위험 시 "부당한 지연 없이"	Art. 33, 34
한국 PIPA	72시간 이내(개인정보보호위)	72시간 이내	제34조
미국 주(州)법	30~90일 (주마다)	주마다	각 주 법

72시간은 "인지한 시점"부터입니다. SOC가 의심 사건을 감지한 시각이 시계의 시작입니다. "확실해진 다음 신고하면 된다"는 흔한 오해이고, 명확하지 않더라도 사실관계가 어느 정도 잡히면 우선 신고 후 보완하는 것이 원칙입니다.

10-2. 흔한 실수 패턴

• 처리방침에 LLM·외부 SaaS를 빠뜨림 - OpenAI·Anthropic·Mixpanel·Sentry 등 모든 Processor를 명시해야 함. 누락 자체가 위반.
• 국외 이전 동의를 받지 않음 - AWS us-east-1을 쓰면 이미 국외 이전. 동의 또는 SCC 등 별도 근거 필요.
• 마케팅 동의와 필수 동의를 한 번에 묶음 - 분리 의무 위반. 한국 보호위 단골 시정명령.
• 로그에 평문 이메일·민번을 출력 - DTO toString·예외 스택. 분기마다 PII 스캐너로 검수.
• 외부 LLM 로그 보관 옵션을 끄지 않음 - 기본값이 30일 보관인 경우가 많음. Zero-Retention 옵션 가입과 DPA 체결 필수.
• 삭제 요청을 운영자가 수동으로 처리 - 시스템화되지 않으면 분기 후 누락이 누적되고, 감사 시 즉시 불합격.
• 분석 DW에 평문 PII가 남음 - 운영 DB만 신경 쓰다 BigQuery·Redshift는 무방비. 적재 단에서 토큰화 필수.
• RAG 벡터 스토어에 PII 청크 - 임베딩 자체로는 평문이 아니지만 재구성 공격 사례가 있음. 인덱싱 전 마스킹/토큰화.
• 아동 정보 별도 처리 부재 - 만 14세 미만이라는 사실만 알면 즉시 별도 시스템·법정대리인 동의 필요.
• 퇴사자 권한 회수 누락 - 사람의 KMS·DB 접근권. #133·#137의 정례화로 차단.

11. 체크리스트

• [ ] 모든 PII 컬럼/필드에 라벨이 부여돼 있고 카탈로그가 자동 갱신된다
• [ ] 직접 식별자는 KMS DEK 기반 컬럼 암호화로 저장된다
• [ ] 결제·민번 등 "흘러다니면 안 되는 값"은 토큰화돼 우리 DB에 평문이 없다
• [ ] 화면 마스킹은 어노테이션 기반으로 일관 적용된다
• [ ] 삭제 요청은 이벤트 기반으로 모든 시스템에 전파되고 케이스 단위로 감사된다
• [ ] 동의는 목적별 분리·약관 해시 포함·철회 시 즉시 반영된다
• [ ] 로그·예외에 PII가 자동 마스킹되고 SIEM이 잔여 누출을 탐지한다
• [ ] 외부 LLM·SaaS는 Zero-Retention·DPA 체결이 완료돼 있다
• [ ] 처리방침에 모든 Processor·국외 이전이 명시돼 있다
• [ ] 사고 시 72시간 이내 신고를 위한 IR 플레이북이 준비돼 있다

12. 보안·프라이버시 7단 방어선

레이어	관점	대표 도구·기법	본 글
OWASP 기본기	코드 취약점	ZAP·Dependency-Check	#131
공급망 무결성	빌드·배포	SBOM·cosign	#132
시크릿 관리	자격증명	Vault·KMS	#133
서비스 통신	네트워크	Istio·SPIFFE·mTLS	#134
런타임 행동	실행 중 위협	Falco·Tetragon	#135
운영 허브	탐지·대응	Elastic·Splunk·Tines	#137
데이터 프라이버시	사람의 데이터	KMS·토큰화·CMP·삭제 파이프라인	오늘

앞의 여섯 층이 "공격자에게서 시스템을 지키는 일"이었다면, 마지막 층은 "우리 자신이 사용자 데이터를 어떻게 다루는지"의 문제입니다. 둘은 종종 같은 도구를 쓰지만 책임의 방향이 정반대입니다.

마치며

데이터 프라이버시 실전의 핵심을 정리합니다.

• 가장 까다로운 GDPR 기준에 맞추는 것이 가장 단순한 설계입니다. 지역별로 다른 법을 따로 만족시키려 하면 분기 폭발이 일어납니다. 공통 70%는 GDPR 수준으로 일괄 적용하고, 동의·국외이전·통지만 지역별로 분기하는 구조가 운영 부담이 가장 적습니다.
• 모든 통제는 데이터 분류에서 시작됩니다. 컬럼·필드별 라벨이 없으면 암호화·마스킹·삭제 정책이 일관되게 적용될 수 없습니다. OpenMetadata·DataHub 같은 카탈로그를 초기부터 도입해 자동 태깅 흐름을 만드는 것이 장기적으로 가장 큰 비용 절감입니다.
• KMS+DEK 봉투 암호화는 단순한 보안 기법이 아니라 잊혀질 권리의 인프라입니다. 사용자별 DEK를 폐기하는 것만으로 모든 백업·아카이브의 데이터가 일제히 복호화 불가가 됩니다. 산재한 사본을 일일이 지우는 시도보다 훨씬 안정적이고 감사하기 쉬운 모델입니다.
• 마스킹·토큰화·해싱·가명화·익명화는 다른 도구입니다. UI에서만 가리는 화면 마스킹과 DB에 비가역으로 저장되는 저장 마스킹이 같은 단어로 불려 사고가 납니다. 가역성·복원 키 위치·재식별 위험을 매번 분리해서 판단해야 합니다.
• 정보주체 권리는 이벤트 기반 파이프라인으로 구현해야 감사가 됩니다. "이메일로 신청하세요"는 GDPR 기준 미달이고, 운영자 수동 처리는 분기 후 반드시 누락이 쌓입니다. 단일 케이스 ID로 모든 시스템의 처리 결과를 묶어두는 설계가 사고 시 자기방어의 핵심 증거가 됩니다.
• 로그·LLM·분석 DW가 실제 사고의 다수 원천입니다. 본 시스템의 암호화에만 집중하다 부수 시스템에서 평문 PII가 새는 패턴이 가장 흔합니다. 적재 단에서 토큰화, 호출 단에서 PII 스캐너, 저장 단에서 자동 마스킹이라는 3중 차단을 갖춰야 합니다.
• 외부 LLM·SaaS 도입은 법적 처리 근거를 새로 정리하는 사건입니다. "AI 기능 추가"가 처리방침·DPA·동의·국외이전 흐름에 모두 영향을 줍니다. 마케팅이 결정한 뒤 법무·보안이 따라가는 순서가 아니라, MCP 가드레일 단계부터 함께 검토되는 구조가 안전합니다.

이로써 보안 6단(OWASP·SBOM·Secrets·Zero Trust·런타임 탐지·SIEM/SOAR)에 프라이버시 한 층을 더해 7단 방어선이 완성됐습니다. 다음 편에서는 이 방어선을 실제 CI/CD 파이프라인에 녹여 매일의 빌드·배포 흐름에서 자동으로 작동하게 만드는 DevSecOps 파이프라인 통합 실전 - Trivy·SBOM·Cosign·OPA·Vault·SIEM을 한 줄의 PR에 연결하기를 다룰 예정입니다. 보안과 프라이버시는 "한 번 설정하고 끝"이 아니라 매 커밋마다 자동으로 검증돼야 비로소 운영의 일부가 됩니다.