Day 4 - 데이터 거버넌스: 카탈로그·계보·공유·감사

데이터 카탈로그: 찾기의 출발점

데이터 거버넌스는 "데이터를 어떻게 찾고, 믿고, 나누고, 추적하는가"를 다룬다. 그 첫 단계가 카탈로그다. 카탈로그는 데이터 자산의 메타데이터(스키마·위치·소유자·태그)를 한곳에서 관리한다.

[S3 데이터] --크롤러--> [Glue Data Catalog: 데이터베이스/테이블/파티션]
                              ↑ 같은 정의를 함께 사용
        [Athena] [Redshift Spectrum] [EMR] [Glue ETL]

• Glue Data Catalog 는 데이터베이스·테이블·파티션의 메타데이터를 담는다. 데이터 자체는 S3 등에 그대로 있다.
• 크롤러는 데이터 저장소를 훑어 스키마와 파티션을 추론해 테이블로 등록한다.
• 카탈로그가 없으면 같은 S3 데이터에 엔진마다 스키마를 따로 정의하게 되고, 한쪽만 고쳐져 결과가 어긋난다. 공유 카탈로그는 "한 번 정의, 모든 엔진 사용"이다.

• 지문이 "엔진 간 스키마 일관성"이면 Glue Data Catalog, "데이터 자산을 검색하고 접근을 신청·승인"이면 비즈니스 카탈로그 쪽이다.

스키마를 누가 관리하나: 크롤러와 Schema Registry

• Schema Registry 는 Avro, JSON(JSON Schema), Protobuf 형식을 지원하고 사용료가 없다. 프로듀서와 컨슈머가 같은 스키마로 직렬화·역직렬화하도록 라이브러리(SerDe)를 제공한다.
• 스키마를 "프로듀서와 컨슈머 사이의 계약"으로 삼는 것이 목적이다. 컨슈머는 호환되는 변경에는 깨지지 않게 된다.

• BACKWARD 에서 필수 필드를 추가하면 거부된다. 새 컨슈머가 그 필드가 없는 옛 메시지를 읽지 못하기 때문이다. 선택 필드로 추가하면 통과한다.
• "컨슈머를 먼저 배포하고 프로듀서를 나중에"가 BACKWARD, "프로듀서를 먼저"가 FORWARD 에 맞는 배포 순서다.

데이터 계보(Lineage): 신뢰의 근거

계보는 데이터가 어디서 와서 어떤 변환을 거쳐 어디로 갔는지의 기록이다.

• Amazon DataZone 의 데이터 계보는 OpenLineage 와 호환된다. 카탈로그에 추가된 Glue 테이블과 Redshift 는 자동으로 계보가 수집되도록 설정할 수 있고, Glue 5.0 이상의 Spark 잡은 실행 시 계보 이벤트를 보내도록 구성할 수 있다. 그 밖의 시스템은 API 로 계보 이벤트를 직접 넣는다.
• 계보 노드는 데이터셋(테이블·뷰)과 잡(실행)이며, 컬럼 수준 계보도 볼 수 있다. 이벤트마다 버전이 남아 "지난달에는 어떤 경로였는지"를 비교할 수 있다.
• 머신러닝 쪽에는 별도로 SageMaker ML Lineage Tracking 이 있다. 데이터셋 → 학습 → 모델 → 엔드포인트로 이어지는 ML 워크플로 단계의 계보를 기록한다. 지문이 "모델이 어떤 데이터로 학습됐는지"를 물으면 이쪽이다.
• 어제의 GDPR 삭제와 연결된다. 한 고객의 데이터를 지워야 할 때 사본이 어느 테이블·추출 파일에 있는지 알려 주는 것이 계보다.

💡 관련 이론: 계보가 없으면 스키마 변경은 "바꿔 보고 깨지는 곳을 기다리는" 일이 된다. Week 8 의 장애 사례(업스트림 컬럼명 변경으로 다운스트림 잡 실패)는 변경 전에 계보로 영향 범위를 봤다면 막을 수 있었다.

데이터 공유 네 가지

AWS Data Exchange

• 데이터 제공자가 만든 데이터셋을 구독하거나, 내 데이터를 제품으로 게시하는 서비스다. AWS Marketplace 의 데이터 제품뿐 아니라, 마켓플레이스 없이 특정 계정에 접근권을 주는 데이터 권한 부여(data grant) 도 있다.
• 데이터셋 유형에 따라 전달 방식이 다르다. 파일 유형은 구독자가 자기 S3 로 내보내 복사본을 갖는다. Amazon S3 데이터 액세스 유형은 제공자의 버킷을 직접 읽고, Amazon Redshift 유형은 ETL 없이 읽기 전용으로 조회하며, API 유형은 호출해서 받는다. Lake Formation 데이터 권한 유형은 문서상 미리 보기다.
• "Data Exchange 는 항상 데이터를 복사해 준다"는 옛 설명이다. 파일 유형에만 해당한다.

AWS Clean Rooms

• 여러 당사자가 원본을 서로 노출하지 않고 공동 분석한다. 데이터는 AWS 밖으로 옮기지도, 한곳에 모으지도 않고 각자의 위치에서 읽힌다.
• 협업(collaboration)을 만들고 멤버를 초대한 뒤, 각자 구성된 테이블(configured table) 을 연결하고 그 테이블에 분석 규칙을 건다. 분석 규칙은 어떤 SQL 을 허용할지와 출력 제약(예: 집계만 허용)을 정한다.

• 쿼리 비용을 누가 낼지도 협업 생성자가 정한다. 쿼리하는 멤버와 비용을 내는 멤버가 다를 수 있다.

당사자 A 데이터 ┐
                ├──> [Clean Rooms 협업: 합의된 집계 쿼리만] ──> 결과만 반환
당사자 B 데이터 ┘     (원본은 서로 못 봄)

Redshift 데이터 공유(datashare)

• 클러스터·서버리스 워크그룹·계정·리전을 넘어 복사 없이 라이브 데이터를 공유한다. 프로듀서에서 커밋된 변경은 컨슈머의 새 트랜잭션에서 바로 보인다(트랜잭션 일관성).
• 공유 단위는 스키마, 테이블, 뷰(일반·지연 바인딩·구체화 뷰), SQL UDF 다. 읽기뿐 아니라 쓰기 권한도 줄 수 있다.
• 전형적 용도는 ETL 전용 클러스터가 여러 BI 클러스터에 데이터를 나눠 주는 구조다. 워크로드가 격리되고 비용을 워크로드별로 따로 본다.

-- 프로듀서
CREATE DATASHARE sales_share;
ALTER DATASHARE sales_share ADD SCHEMA sales;
ALTER DATASHARE sales_share ADD TABLE sales.orders;
GRANT USAGE ON DATASHARE sales_share TO ACCOUNT '444455556666';
 
-- 컨슈머(다른 계정): 공유를 데이터베이스로 붙인 뒤 조회
CREATE DATABASE sales_from_prod FROM DATASHARE sales_share
  OF ACCOUNT '111122223333' NAMESPACE 'a1b2c3d4-5678-90ab-cdef-111122223333';
SELECT COUNT(*) FROM sales_from_prod.sales.orders;

• 스냅샷 공유와 다르다. 스냅샷은 특정 시점의 사본을 복원하는 것이어서 최신 데이터가 아니고 저장 비용도 든다.

💡 관련 이론: Data Exchange 는 "데이터(또는 접근권)를 건네주는" 모델, Clean Rooms 는 "데이터를 건네지 않고 합산 결과만 얻는" 모델이다. 지문에 "서로의 원본을 볼 수 없어야 한다"가 있으면 버킷 공유, datashare, Data Exchange 는 모두 탈락한다. 상대가 원본 행을 읽게 되기 때문이다.

감사: 누가 언제 무엇을

{
  "eventName": "GetObject",
  "userIdentity": { "arn": "arn:aws:sts::111122223333:assumed-role/RegionAnalyst/alice" },
  "requestParameters": { "bucketName": "lake-curated", "key": "sales/dt=2026-06-25/part-0.parquet" },
  "eventTime": "2026-06-25T09:14:02Z"
}

• 위와 같은 데이터 이벤트가 있어야 "어떤 역할이 언제 어떤 객체를 읽었는지"를 입증할 수 있다. 관리 이벤트만으로는 "버킷 정책을 누가 바꿨나"까지만 답한다.
• 데이터 이벤트는 양이 많다. 모든 버킷에 켜지 말고 민감 버킷·접두사로 좁힌다.
• Redshift 감사 로깅은 세 가지 로그를 낸다. 접속 로그(인증 시도·접속·해제), 사용자 로그(사용자 정의 변경), 사용자 활동 로그(실행 전 쿼리 문). 감사 로깅을 켜는 것만으로는 앞의 둘만 나오고, 쿼리 문까지 남기려면 파라미터 enable_user_activity_logging 을 따로 켜야 한다. "감사 로깅을 켰는데 쿼리가 안 남는다"의 원인이다.
• Redshift API 호출(클러스터 생성·수정)은 CloudTrail 에, 데이터베이스 안에서의 SQL 활동은 감사 로그에 남는다. 층이 다르다.
• CloudTrail Lake 는 이벤트를 저장해 SQL 로 조회하게 하고, Security Hub 는 여러 보안 서비스의 발견을 한곳에 모은다. 감사 로그는 운영 계정과 분리된 계정의 버킷에 모아 변경하지 못하게 둔다.

CloudTrail 관리 이벤트는 기본으로 기록되지만 S3 객체 수준 접근(데이터 이벤트)은 양과 비용 때문에 기본으로 꺼져 있다. 사고가 난 뒤에 켜면 사고 시점의 기록은 없다. 민감 버킷은 미리 켜 두어야 한다.

거버넌스 통합

[카탈로그] 찾기 → [계보] 신뢰 → [공유] 협업 → [감사] 추적
   Glue         DataZone       Clean Rooms       CloudTrail
   Catalog      Lineage        Data Exchange     감사 로그
                               datashare

증상 → 원인 → 조치

지문 단서 → 정답 판별표

내일은 이번 주의 네 축(접근 제어·암호화·민감 데이터 보호·거버넌스)을 하나의 종단 시나리오로 묶어 복습한다.

📖 용어

• 데이터 카탈로그 : 데이터가 어디에 어떤 구조로 있는지 적어 둔 메타데이터 저장소.
• 크롤러 : 데이터 저장소를 훑어 스키마를 추론하고 카탈로그에 테이블로 등록하는 Glue 기능.
• Schema Registry : 스트림 데이터의 스키마를 버전별로 보관하고 호환되지 않는 변경을 막는 Glue 기능.
• 호환성 모드 : 새 스키마 버전이 이전 버전과 어떤 방향으로 호환돼야 등록을 허용할지 정하는 규칙.
• 계보(lineage) : 데이터가 어디서 와서 어떤 변환을 거쳐 어디로 갔는지의 기록.
• 영향 분석 : 무언가를 바꾸기 전에 그 변경이 닿는 다운스트림을 계보로 확인하는 일.
• datashare : Redshift 에서 복사 없이 다른 클러스터·계정에 공유하는 객체 묶음.
• 분석 규칙 : Clean Rooms 에서 테이블에 어떤 쿼리와 출력을 허용할지 정한 제약.
• 차등 프라이버시 : 결과에 수학적으로 조정된 잡음을 넣어 개인이 식별되지 않게 하는 기법.
• 데이터 이벤트 : 객체 읽기·쓰기처럼 데이터 자체에 대한 접근 기록. CloudTrail 에서 직접 켜야 남는다.