데이터 거버넌스·Lineage·PII 완전 가이드: OpenLineage, Collibra·Atlan·DataHub, Unity·Polaris, GDPR·한국 개인정보법 (2025)

Season 5 Ep 7 — Ep 1–6에서 데이터는 점점 많아지고 복잡해졌다. Ep 7은 그 반대 축 — "어떻게 다스릴 것인가". 데이터를 관리하지 않으면 데이터가 회사를 지배한다.

• Prologue — "우리 회사에 고객 이메일이 몇 군데에 있나?"
• 1장 · 데이터 거버넌스 정의
  • 1.1 거버넌스의 4축
  • 1.2 왜 지금 중요한가
  • 1.3 거버넌스의 스펙트럼
• 2장 · OpenLineage — 계보의 표준
  • 2.1 정체성
  • 2.2 구조
  • 2.3 통합
  • 2.4 예시 이벤트
  • 2.5 가치
• 3장 · 데이터 카탈로그 4대
  • 3.1 Collibra
  • 3.2 Atlan
  • 3.3 DataHub
  • 3.4 Alation
  • 3.5 기타
  • 3.6 비교
• 4장 · 기술 카탈로그 — Unity/Polaris/Glue
  • 4.1 Unity Catalog
  • 4.2 Polaris
  • 4.3 AWS Glue Data Catalog
  • 4.4 Nessie / Gravitino
  • 4.5 비즈니스 vs 기술 카탈로그
• 5장 · PII — 정의와 탐지
  • 5.1 PII 정의
  • 5.2 자동 탐지 도구
  • 5.3 탐지 방식
  • 5.4 분류 등급
• 6장 · PII 보호 — 마스킹·토큰화·암호화
  • 6.1 마스킹
  • 6.2 토큰화(Tokenization)
  • 6.3 해싱·익명화
  • 6.4 암호화
  • 6.5 Dynamic Masking 예 (Snowflake)
• 7장 · 규제 — GDPR, 한국 PIPA, AI Act
  • 7.1 GDPR (EU, 2018–)
  • 7.2 한국 개인정보보호법(PIPA)
  • 7.3 한국 AI 기본법 (2024–)
  • 7.4 기타 규제
  • 7.5 공통 원칙
• 8장 · Data Subject Request (DSR)
  • 8.1 요청 유형
  • 8.2 구현 난이도
  • 8.3 실무 패턴
  • 8.4 AI·학습 데이터
• 9장 · AI 시대의 거버넌스 확장
  • 9.1 모델 카탈로그
  • 9.2 프롬프트·에이전트 카탈로그
  • 9.3 학습 데이터 출처 추적
  • 9.4 AI 결과 감사
  • 9.5 규제와의 연결
• 10장 · 실전 아키텍처 — 거버넌스 통합
  • 10.1 레이어
  • 10.2 정책 예
  • 10.3 감사
  • 10.4 자동화
• 11장 · 한국 기업 거버넌스 현실
  • 11.1 현황
  • 11.2 규제 대응
  • 11.3 도전 과제
  • 11.4 참고 사례
• 12장 · 실패 사례 8선
  • 12.1 PII가 BI 대시보드에 노출
  • 12.2 계보 없는 장애 대응
  • 12.3 삭제 요청 1개월 처리
  • 12.4 소유자 불명 테이블 수천 개
  • 12.5 카탈로그 있지만 비어있음
  • 12.6 접근 권한 파편화
  • 12.7 외주 인력이 PII 전체 접근
  • 12.8 AI 학습 데이터 출처 불명
• 13장 · 안티패턴 10선
  • 13.1 "거버넌스는 나중에"
  • 13.2 카탈로그만 있고 소유자 없음
  • 13.3 PII 탐지 정규식 몇 줄
  • 13.4 백업 규제 무관심
  • 13.5 Lineage를 수작업 문서로
  • 13.6 Data Contract 없이 상류 마구 변경
  • 13.7 외부 공유 통제 부재
  • 13.8 감사 로그 단기 보관
  • 13.9 카탈로그 도구 여러 개 병행
  • 13.10 AI·ML 영역을 거버넌스 밖
• 14장 · 체크리스트 — 데이터 거버넌스 12가지
• 15장 · 다음 글 예고 — Season 5 Ep 8: "Observability 2025 (Logs·Metrics·Traces + LLM)"

Prologue — "우리 회사에 고객 이메일이 몇 군데에 있나?"

2025년 CTO에게 가장 답하기 어려운 질문:

• 고객 이메일은 몇 개 테이블·시스템에 있나?
• 그 중 PII 마스킹이 된 건 얼마나 되나?
• 사용자가 "내 데이터를 지워 달라"고 하면 어디부터 지워야 하나?
• 이 대시보드의 숫자는 어느 원천 데이터에서 온 건가?

4개 질문 모두 "몰라요"라면, 이 회사는 규제 리스크와 제품 품질 리스크를 동시에 가지고 있다. 이 글은 그 네 질문에 답할 수 있게 만드는 도구와 프로세스를 정리한다.

1장 · 데이터 거버넌스 정의

1.1 거버넌스의 4축

• 카탈로그: 우리에게 어떤 데이터가 있나
• Lineage: 어디서 와서 어디로 가나
• 품질(Quality): 믿을 수 있는 데이터인가
• 보안·규제(PII·RBAC): 누가 볼 수 있고 얼마나 보관하나

1.2 왜 지금 중요한가

• 데이터 스택 분절(Ep 1–6)로 관리 복잡도 폭증
• EU AI Act, GDPR, 한국 개인정보보호법의 강화
• AI 모델이 데이터를 학습·추론 → 저작권·PII 이슈
• 고객·직원의 데이터 권리 행사 증가

1.3 거버넌스의 스펙트럼

• 카탈로그: 읽기 중심, 직원 탐색
• Active governance: 정책 강제, 위반 차단
• Federation: 멀티 클라우드·멀티 DB 통합 관리

2장 · OpenLineage — 계보의 표준

2.1 정체성

• 2020 오픈소스, LF AI & Data 재단
• 데이터 계보(Lineage)의 인더스트리 표준 스펙
• Python·Java·OpenAPI 참조 구현

2.2 구조

• Job: 실행 단위(Airflow DAG·dbt run·Flink job)
• Run: Job의 실행 인스턴스
• Dataset: 입력·출력 데이터셋
• Event: START/COMPLETE/FAIL 이벤트

2.3 통합

• Airflow, dbt, Spark, Flink, Dagster, Prefect 지원
• Marquez(레퍼런스 메타 저장소)
• Datakin → Astronomer가 SaaS 지원
• DataHub·Atlan·Collibra가 OpenLineage 수신

2.4 예시 이벤트

{
  "eventType": "COMPLETE",
  "job": {"name": "dbt.fact_orders"},
  "run": {"runId": "..."},
  "inputs": [{"name": "raw.orders"}, {"name": "raw.customers"}],
  "outputs": [{"name": "analytics.fact_orders"}]
}

2.5 가치

• 자동 계보 수집 → 사람의 문서 작성 부담 감소
• 도구 간 이식 가능
• 장애 분석·영향도 평가

3장 · 데이터 카탈로그 4대

3.1 Collibra

• 2008, 벨기에 → 엔터프라이즈 거버넌스 최강자
• 금융·공공·제약 특화
• 비즈니스 용어집(Glossary)·정책 관리 강점

3.2 Atlan

• 2018 인도 → 모던 데이터 스택 친화
• dbt·Snowflake·Databricks 통합 탁월
• 협업·UX가 우수

3.3 DataHub

• 2020 LinkedIn → Apache
• 오픈소스, 자체 호스팅 가능
• Acryl Data(상용 SaaS) 지원

3.4 Alation

• 2012 → 엔터프라이즈 협업 카탈로그
• Data Intelligence Platform 포지셔닝

3.5 기타

• Secoda, Castor(→ CoreView), OpenMetadata, Amundsen(Lyft)
• Informatica Data Governance, IBM Watson Knowledge Catalog

3.6 비교

4장 · 기술 카탈로그 — Unity/Polaris/Glue

4.1 Unity Catalog

• Databricks의 거버넌스 레이어
• 2024 오픈소스화 (Unity Catalog OSS)
• Table·Volume·Model·Function 통합
• Delta·Iceberg 모두 지원

4.2 Polaris

• Snowflake 오픈 Iceberg REST 카탈로그
• 2024 오픈소스
• 외부 엔진에서 접근 가능
• 거버넌스 + 카탈로그 결합

4.3 AWS Glue Data Catalog

• AWS의 기본 카탈로그
• Iceberg·Delta·Hudi 지원
• Lake Formation과 결합해 권한·감사

4.4 Nessie / Gravitino

• Nessie: Git 같은 브랜치·태그
• Gravitino: 메타데이터 연합 (여러 카탈로그 통합)

4.5 비즈니스 vs 기술 카탈로그

• 기술 카탈로그: 엔진·쿼리가 쓰는 메타
• 비즈니스 카탈로그: 사람이 쓰는 의미·소유자·SLA
• 2025년 둘의 연결(OpenLineage·OpenMetadata)이 표준

5장 · PII — 정의와 탐지

5.1 PII 정의

• Personally Identifiable Information
• 직접 식별(이름·주민번호·카드번호)
• 간접 식별(생년월일+지역·IP·쿠키 ID)
• 민감 정보(건강·종교·성향)

5.2 자동 탐지 도구

• AWS Macie, Google DLP, Azure Purview: 클라우드 DLP
• Privacera, BigID, OneTrust: 엔터프라이즈 전문
• Presidio (Microsoft): 오픈소스
• Snowflake Data Classification: DW 내장

5.3 탐지 방식

• 정규식(카드·주민번호)
• 사전 기반(이름·주소)
• ML 분류기(문맥 포함)
• 컬럼 샘플링 + 엔트로피 분석

5.4 분류 등급

• Public / Internal / Confidential / PII / Sensitive PII / Regulated
• 등급별 접근·로그 보존·암호화 정책 차등

6장 · PII 보호 — 마스킹·토큰화·암호화

6.1 마스킹

• 이메일: john@***.com
• 카드: **** **** **** 1234
• 이름: 홍*동 또는 홍OO
• Dynamic Data Masking: 쿼리 시 사용자별 다르게 보여줌

6.2 토큰화(Tokenization)

• PII를 무의미한 토큰으로 대체, 별도 금고(Vault)에 매핑 저장
• 분석 가능성 유지하면서 유출 시 영향 최소화
• Vault: HashiCorp Vault, AWS KMS + 자체 서비스

6.3 해싱·익명화

• SHA-256 등 일방향 해시: 분석 가능, 원본 복원 불가
• k-anonymity, l-diversity, differential privacy
• 의료·공공 데이터에 활용

6.4 암호화

• At rest: S3 SSE, 디스크 암호화
• In transit: TLS
• Column-level: Parquet Modular Encryption
• Field-level: 애플리케이션에서 암호화 후 저장

6.5 Dynamic Masking 예 (Snowflake)

CREATE MASKING POLICY mask_email AS (val STRING)
RETURNS STRING ->
  CASE WHEN CURRENT_ROLE() IN ('ADMIN') THEN val
       ELSE REGEXP_REPLACE(val, '.+@', '***@')
  END;

ALTER TABLE customers MODIFY COLUMN email
  SET MASKING POLICY mask_email;

7장 · 규제 — GDPR, 한국 PIPA, AI Act

7.1 GDPR (EU, 2018–)

• 데이터 주체 권리(접근·삭제·이동·정정·처리 거부)
• Legal basis(동의·계약 등) 명시 필요
• DPIA(영향평가), DPO(보호책임자)
• 위반 시 글로벌 매출의 4% 또는 2천만 유로

7.2 한국 개인정보보호법(PIPA)

• 2011 제정, 2020·2023 개정
• 개인정보 처리 동의·목적 명시
• 2023 개정: 데이터 주체 권리 강화(열람·삭제·이동)
• 과징금 매출 3% 상한 도입
• 개인정보보호위원회 감독

7.3 한국 AI 기본법 (2024–)

• 고위험 AI 사전 영향평가
• 책임 있는 AI 개발·운영 지침
• 사업자 보고 의무

7.4 기타 규제

• 미국 HIPAA, GLBA, CPRA(캘리포니아)
• 싱가포르 PDPA, 일본 APPI
• 섹터별: 금융감독원, 의료법, 전자금융감독규정

7.5 공통 원칙

• 목적 제한: 수집 목적 외 사용 금지
• 최소 수집: 필요한 만큼만
• 보유 기간: 목적 달성 후 파기
• 주체 권리: 열람·정정·삭제·이동
• 투명성: 처리 현황 공개

8장 · Data Subject Request (DSR)

8.1 요청 유형

• Access: 내 데이터 열람
• Rectification: 정정
• Erasure(Right to be forgotten): 삭제
• Portability: 타 서비스로 이동
• Object: 처리 거부

8.2 구현 난이도

• Warehouse의 해당 사용자 row 삭제
• Lakehouse Iceberg의 row-level delete
• 백업·로그의 처리
• ML 학습 데이터에 포함된 경우(재학습?)
• 제3자 공유된 데이터

8.3 실무 패턴

• 데이터 지도(Data Map): PII가 있는 테이블·위치 목록
• Unique ID: 사용자별 고유 ID로 전 시스템 검색
• DSR 워크플로우 툴: OneTrust·TrustArc·Osano
• 로그·백업 정책: 법정 기간 후 자동 파기

8.4 AI·학습 데이터

• 훈련 데이터에서 개인 삭제는 원칙상 어려움
• 해결책: 가명화·익명화·Synthetic data
• Machine unlearning 연구 진행 중

9장 · AI 시대의 거버넌스 확장

9.1 모델 카탈로그

• 회사가 쓰는 모델 목록
• 버전·데이터·성능·라이선스·감사
• MLflow·Databricks Model Registry·Weights & Biases·HuggingFace Hub

9.2 프롬프트·에이전트 카탈로그

• 시스템 프롬프트 버전
• 에이전트 툴·권한
• Ep 11(LLMOps) 연장

9.3 학습 데이터 출처 추적

• 저작권·라이선스 문서화
• 데이터셋 카드(Dataset Card)
• 감사 요청 시 원본 근거 제시

9.4 AI 결과 감사

• 응답 로그·인용·의사결정 근거
• Postmortem을 위한 재현 가능성

9.5 규제와의 연결

• EU AI Act: 고위험 모델의 품질관리·문서
• 한국 AI 기본법: 영향평가

10장 · 실전 아키텍처 — 거버넌스 통합

10.1 레이어

• 수집: Kafka·Fivetran·Airbyte → OpenLineage 이벤트
• 변환: dbt·Spark → OpenLineage 자동 방출
• 저장: Iceberg·Delta + 카탈로그(Unity/Polaris/Glue)
• 거버넌스: DataHub/Atlan/Collibra 수신·통합
• 정책: Unity/Lake Formation/Ranger/OPA
• PII: Macie/Privacera/DLP

10.2 정책 예

• Raw: 원본, 접근 제한, 보관 90일
• Silver: 마스킹 + 토큰화, 1년
• Gold: 집계, 권한 기반 마스킹, 3년+
• 백업: 암호화, 법적 기간 후 자동 파기

10.3 감사

• 모든 쿼리·DDL 로그
• 접근 이상 탐지(비정상 시간·IP·양)
• 분기별 감사 보고서

10.4 자동화

• PR 머지 시 거버넌스 체크 CI
• 새 테이블 → 자동 분류·소유자 지정
• 접근 요청 → 승인 워크플로우

11장 · 한국 기업 거버넌스 현실

11.1 현황

• 금융·공공: 자체 구축 + Collibra/Informatica 혼용
• 대기업: DataHub 오픈소스 → 내부 포크
• 중견·스타트업: Atlan·Secoda 도입 증가
• 관측성·PII 전용 도구는 초기 단계

11.2 규제 대응

• 개인정보보호위원회 감사·과징금 사례 증가
• 금융보안원 가이드라인
• 공공 데이터 3법(개인정보·신용정보·정보통신망)

11.3 도전 과제

• 망분리 환경의 카탈로그 구축
• 한국어 메타데이터 지원
• 레거시 DW의 이력 자동 수집 어려움
• 인력 부족: 거버넌스 전담 인력 희소

11.4 참고 사례

• 토스: 내부 데이터 플랫폼에 DSR·카탈로그 통합
• 카카오: PII 자동 분류 파이프라인
• 네이버: 거버넌스 표준 팀 + 자체 카탈로그
• 삼성 SDS·LG CNS: 기업 고객용 거버넌스 SI 패키지

12장 · 실패 사례 8선

12.1 PII가 BI 대시보드에 노출

Dynamic masking 없이 실명 노출 → 감사 지적.

12.2 계보 없는 장애 대응

"이 지표가 틀린 이유"를 반나절 찾음.

12.3 삭제 요청 1개월 처리

수동 작업, 여러 시스템 동시 삭제 실패.

12.4 소유자 불명 테이블 수천 개

누구에게 물어봐야 할지 모름.

12.5 카탈로그 있지만 비어있음

초기 구축 후 유지 안 해서 현실과 괴리.

12.6 접근 권한 파편화

10개 DB 각각 RBAC, 중앙 관리 실패.

12.7 외주 인력이 PII 전체 접근

감사 위반.

12.8 AI 학습 데이터 출처 불명

저작권 분쟁·규제 조사 시 무기력.

13장 · 안티패턴 10선

13.1 "거버넌스는 나중에"

규모 커질수록 뜯어고치기 어려워짐. 초기부터 기초 깔기.

13.2 카탈로그만 있고 소유자 없음

문서가 있을 뿐 책임이 없음.

13.3 PII 탐지 정규식 몇 줄

ML 분류기·샘플링 병행 필요.

13.4 백업 규제 무관심

"파기 기한이 지났지만 백업에 남아있음" 사고.

13.5 Lineage를 수작업 문서로

자동 수집(OpenLineage) 도입.

13.6 Data Contract 없이 상류 마구 변경

소비자 전원 파손.

13.7 외부 공유 통제 부재

S3 버킷 공개, 이메일 첨부파일.

13.8 감사 로그 단기 보관

규제 요구 미충족.

13.9 카탈로그 도구 여러 개 병행

통합 없이 중복 관리.

13.10 AI·ML 영역을 거버넌스 밖

2025년엔 이게 최대 리스크.

14장 · 체크리스트 — 데이터 거버넌스 12가지

• 데이터 카탈로그(비즈니스 + 기술) 통합
• OpenLineage 기반 Lineage 자동 수집
• 테이블·모델 소유자·SLA 명시
• PII 자동 탐지·분류 파이프라인
• 마스킹·토큰화·암호화 정책
• DSR 워크플로우와 처리 기한
• 권한·감사 로그 중앙화
• 데이터 계약 · 변경 프로세스
• 법적 보관·파기 정책
• AI·ML 영역 거버넌스(모델·데이터 출처)
• 규제 매핑(GDPR·PIPA·AI Act·섹터 규제)
• 직원 교육·경영진 보고

15장 · 다음 글 예고 — Season 5 Ep 8: "Observability 2025 (Logs·Metrics·Traces + LLM)"

거버넌스가 "데이터를 어떻게 관리"라면, Observability는 "시스템과 데이터가 실제로 어떻게 돌고 있는가".

• OpenTelemetry의 성숙
• Metric·Log·Trace 3대 시그널의 통합
• Grafana Cloud·Datadog·New Relic·Splunk·Honeycomb·SigNoz
• Tempo·Loki·Mimir·Jaeger·Zipkin
• LLM 관측성 (LangFuse·LangSmith·Phoenix·Helicone, Ep 6 연장)
• SLO·SLI와 error budget
• 카오스 엔지니어링과 회복력
• 한국 기업의 관측성 스택
• "관측성은 보험이 아니라 제품 품질"

"관측성 없으면 운영 없다" — 2025년 인프라의 기본값.

다음 글에서 만나자.

요약: 2025년 데이터 거버넌스는 카탈로그 + Lineage + 품질 + PII·규제 4축. OpenLineage가 계보의 표준이 됐고, Collibra·Atlan·DataHub·Alation이 카탈로그의 4대 옵션, Unity·Polaris·Glue가 기술 카탈로그를 담당한다. PII는 탐지·분류·마스킹·토큰화·암호화 5단계로 관리되며, GDPR·한국 PIPA·AI Act가 규제 삼각 편대. AI 시대의 거버넌스는 모델·프롬프트·학습 데이터까지 확장됐고, 데이터 주체 권리(DSR)는 자동화 워크플로우가 필수. 한국 기업은 망분리·한국어 메타·레거시 통합이 도전 과제이며, 거버넌스 전담 인력 확보가 차세대 경쟁력. "관리하지 않으면 관리당한다" — 데이터 거버넌스의 2025년 법칙.