데이터 엔지니어 인터뷰 — 데이터 거버넌스 구축

개념과 범위

데이터 거버넌스란 무엇인가요

데이터를 누가, 무엇을, 어떤 규칙으로 다루는지 정하고 지속시키는 체계입니다. 문서를 만드는 일이 아니라 의사결정 구조와 그것을 강제하는 장치를 만드는 일입니다.

크게 네 축으로 봅니다.

축	질문
발견 가능성	어떤 데이터가 있고 어디에 있는가
신뢰성	이 숫자를 믿어도 되는가
책임	문제가 생기면 누구에게 물어보는가
안전성	누가 무엇을 볼 수 있는가

거버넌스가 없으면 어떤 문제가 생기나요

실무에서 가장 먼저 드러나는 증상들입니다.

같은 지표가 대시보드마다 다른 값을 보여줍니다
테이블이 무슨 의미인지 아는 사람이 회사에 없습니다
컬럼 하나를 지우려는데 영향 범위를 몰라 못 지웁니다
개인정보가 어느 테이블에 있는지 파악이 안 됩니다
파이프라인이 조용히 실패했는데 몇 주 뒤에 발견됩니다

거버넌스는 이 문제들을 사후 수습이 아니라 구조로 막으려는 시도입니다.

어디서부터 시작해야 하나요

한 번에 전사 체계를 세우려 하면 대부분 실패합니다. 가장 아픈 곳 하나부터 시작하는 편이 현실적입니다.

핵심 테이블 20개에 오너와 설명을 붙입니다. 전체가 아니라 실제로 많이 쓰이는 것부터
그 테이블들에 품질 검증을 겁니다
리니지를 붙여 영향 범위를 볼 수 있게 합니다
그 다음에 카탈로그·정책·자동화를 확장합니다

조회 로그(BigQuery INFORMATION_SCHEMA.JOBS, Snowflake ACCESS_HISTORY 등)를 보면 실제로 많이 쓰이는 테이블을 알 수 있습니다. 여기서부터 시작하면 투자 대비 효과가 큽니다.

카탈로그와 메타데이터

데이터 카탈로그에는 무엇이 들어가나요

기술 메타데이터 — 스키마, 타입, 파티션, 크기, 갱신 시각
비즈니스 메타데이터 — 이 테이블·컬럼이 무슨 뜻인지, 어떤 업무에 쓰이는지
운영 메타데이터 — 오너, SLA, 최근 실행 상태, 품질 검증 결과
사용 메타데이터 — 누가 얼마나 조회하는지, 어떤 대시보드가 참조하는지

기술 메타데이터는 자동 수집이 가능하지만, 비즈니스 메타데이터는 사람이 채워야 합니다. 이 부분이 항상 병목입니다.

카탈로그가 방치되는 이유는 무엇이고 어떻게 막나요

“입력하세요”라고 하면 아무도 안 합니다. 작동하게 만들려면 몇 가지가 필요합니다.

자동 수집을 최대화 — 사람이 채울 항목을 최소로 줄입니다
워크플로에 끼워 넣기 — 테이블 생성 PR에 설명·오너 필드를 필수로 만듭니다. 코드로 관리하면(dbt의 schema.yml 등) 리뷰 대상이 됩니다
쓸모를 먼저 보여주기 — 검색이 실제로 편해야 사람들이 씁니다. 리니지나 조회 통계처럼 입력하지 않아도 얻는 가치를 먼저 제공합니다
커버리지를 지표로 — 핵심 테이블의 문서화 비율을 측정하고 공개합니다

데이터 리니지는 왜 중요한가요

영향 분석과 원인 추적 두 방향에 씁니다.

앞으로: “이 컬럼을 바꾸면 어떤 대시보드가 깨지나”
뒤로: “이 지표가 이상한데 어느 소스에서 온 값인가”

테이블 수준 리니지만 있어도 상당히 유용하지만, 컬럼 수준까지 있으면 영향 범위를 훨씬 좁게 잡을 수 있습니다.

수집 방법은 몇 가지입니다.

쿼리 로그 파싱 — 실행된 SQL을 분석해 입력·출력 테이블 추출. 자동이지만 정확도 한계
오케스트레이터 통합 — Airflow의 태스크 의존성과 데이터셋 정보
변환 도구 — dbt처럼 의존성이 코드에 드러나는 경우 가장 정확
OpenLineage — 표준 스펙. 여러 도구가 같은 형식으로 리니지를 내보냄

BI 도구까지 연결되어야 “이 컬럼을 쓰는 대시보드”를 알 수 있는데, 여기가 대개 끊겨 있습니다.

어떤 도구를 검토하나요

도구	성격
DataHub	오픈소스, 리니지·메타데이터 통합
OpenMetadata	오픈소스, 품질·거버넌스 기능 포함
Amundsen	오픈소스, 검색 중심
AWS Glue Data Catalog	AWS 네이티브(기술 메타데이터 중심)
GCP Dataplex / Data Catalog	GCP 네이티브
Collibra, Alation	상용, 정책·워크플로 강함

도구 선택보다 누가 운영할지가 더 중요합니다. 오픈소스는 도입 비용이 낮은 대신 운영 인력이 필요합니다.

오너십과 계약

데이터 오너십은 어떻게 정의하나요

두 역할을 나눠 보는 것이 유용합니다.

Data Owner — 그 데이터의 의미와 정책에 책임. 보통 업무 담당 조직
Data Steward / 관리자 — 파이프라인과 품질 운영에 책임. 보통 데이터 팀

“모두의 책임”은 “아무의 책임도 아님”이 됩니다. 테이블마다 사람 이름 또는 팀이 명시되어야 하고, 그 정보가 카탈로그와 알림에 연결되어야 합니다.

데이터 계약(data contract)은 무엇인가요

생산자와 소비자 사이에 스키마와 보장 수준을 명시적으로 합의하는 것입니다. 보통 다음을 담습니다.

스키마(필드, 타입, 필수 여부)
갱신 주기와 신선도 보장
품질 규칙(유일성, 값 범위)
하위 호환 정책과 변경 통보 절차
오너와 연락처

핵심은 문서가 아니라 검증 가능한 형태여야 한다는 점입니다. 계약을 코드로 두고 CI에서 위반을 잡아야 실효가 있습니다. 스키마 레지스트리의 호환성 규칙이 계약을 강제하는 대표적인 장치입니다.

상류 시스템이 통보 없이 스키마를 바꿉니다. 어떻게 대응하나요

기술적 장치와 조직적 합의가 둘 다 필요합니다.

기술적으로는 — 스키마 변경을 감지해 알림을 보내고, 파이프라인이 조용히 깨지는 대신 명시적으로 실패하게 만듭니다. 스키마를 추론에 맡기지 않고 명시적으로 선언해 두면 변경이 바로 드러납니다.

조직적으로는 — 데이터 계약을 맺고, 변경 시 통보 절차를 만들고, 상류 팀의 CI에 소비자 영향 검사를 붙입니다. 상류가 자신의 변경이 무엇을 깨는지 볼 수 있어야(리니지) 동작합니다.

품질

데이터 품질은 어떤 차원으로 측정하나요

차원	확인
완전성	필수 값 누락, 예상 행 수
유일성	키 중복
정합성	참조 무결성, 테이블 간 합계 일치
유효성	값 범위·형식
신선도	기대 시각까지 도착
일관성	시스템 간 같은 값인가

검증 실패 시 파이프라인을 멈춰야 하나요

심각도에 따라 나눠야 합니다. 전부 차단하면 파이프라인이 자주 서고 사람들이 검증을 꺼버립니다. 전부 통과시키면 잘못된 데이터가 대시보드에 뜹니다.

일반적인 구분입니다.

차단(blocking) — 키 중복, 필수 컬럼 전체 NULL, 행 수가 0. 다운스트림에 나가면 확실히 사고
경고(warning) — 행 수가 평소 대비 20% 감소, 새 카테고리 값 등장. 확인은 필요하지만 정상일 수도 있음

차단된 경우 격리(quarantine) 테이블에 넣고 정상 데이터만 진행시키는 방식도 씁니다.

데이터 신선도 SLA는 어떻게 관리하나요

“매일 오전 8시까지 전일 데이터가 준비된다” 같은 약속을 명시하고, 지연 시 알림이 가도록 합니다.

측정은 파이프라인 성공 여부가 아니라 데이터 자체를 봐야 합니다. 잡은 성공했는데 소스가 비어 있어 0건이 적재된 경우, 잡 상태만 보면 정상으로 보입니다.

-- 최신 파티션이 기대 시각보다 늦으면 알림
SELECT MAX(dt) AS latest, CURRENT_DATE() - 1 AS expected
FROM analytics.daily_orders;

데이터 옵저버빌리티는 무엇인가요

규칙을 사람이 다 정의하는 대신, 평소 패턴에서 벗어나는 것을 자동 감지하는 접근입니다. 행 수 추이, NULL 비율, 값 분포, 갱신 간격의 이상치를 봅니다.

규칙 기반 검증을 대체하는 것이 아니라 보완합니다. 예상하지 못한 문제를 잡는 데 유용하지만, 오탐이 많으면 알림 피로로 무시당합니다.

보안과 개인정보

개인정보를 어떻게 식별하고 관리하나요

먼저 어디에 있는지 아는 것이 출발점입니다. 컬럼명 패턴, 값 패턴, 샘플링 기반 분류기로 후보를 찾고 사람이 확인합니다. GCP DLP, AWS Macie 같은 서비스가 이 작업을 돕습니다.

찾은 뒤에는 태그를 붙여 정책과 연결합니다. 태그가 붙으면 자동으로 마스킹되거나 접근이 제한되게 만드는 것이 목표입니다. 사람이 매번 판단하게 두면 반드시 새어 나갑니다.

마스킹, 익명화, 가명화를 구분해보세요

마스킹 — 표시할 때 가림(010-****-5678). 원본은 그대로
가명화(pseudonymization) — 식별자를 대체 값으로 치환. 매핑 테이블이 있으면 복원 가능. 법적으로는 여전히 개인정보
익명화(anonymization) — 복원 불가능하게 만듦. 제대로 하면 개인정보가 아님

익명화는 생각보다 어렵습니다. 직접 식별자를 지워도 여러 준식별자 조합으로 재식별될 수 있습니다(생년월일 + 우편번호 + 성별). k-익명성 같은 개념이 이 문제를 다룹니다.

접근 통제는 어떤 단위로 설계하나요

테이블/데이터셋 수준 — 가장 기본
컬럼 수준 — 민감 컬럼만 제한 (BigQuery 정책 태그, Snowflake 마스킹 정책)
행 수준 — 조직·지역별로 볼 수 있는 행을 제한
동적 마스킹 — 역할에 따라 같은 컬럼이 다르게 보임

원칙은 최소 권한과 역할 기반입니다. 개인에게 직접 권한을 주면 관리가 불가능해집니다. 그룹에 역할을 부여하고 사람은 그룹에 넣습니다.

접근 권한은 부여보다 회수가 어렵습니다. 정기 검토(access review)와 만료 기한이 있는 임시 권한이 필요합니다.

보관 기간과 삭제 요구는 어떻게 처리하나요

법적 요구(개인정보 보호법, GDPR의 삭제권)와 실무가 충돌하는 지점입니다.

보관 정책 — 데이터 유형별 보관 기간을 정하고 자동 만료를 겁니다
삭제 요청 — 특정 개인의 데이터를 찾아 지워야 합니다. 어디에 흩어져 있는지 알아야 가능하므로 리니지와 카탈로그가 전제가 됩니다
백업과 로그 — 본체를 지워도 백업·로그에 남아 있는 경우가 많습니다

레이크하우스 테이블 포맷에서는 타임 트래블 때문에 옛 스냅샷에 삭제된 데이터가 남습니다. 스냅샷 만료 정책과 삭제 요구를 함께 봐야 합니다.

정착

거버넌스를 조직에 정착시키려면 무엇이 필요한가요

기술만으로는 안 됩니다.

마찰을 줄이기 — 규칙을 지키는 것이 어기는 것보다 쉬워야 합니다. 템플릿, 자동 검증, 기본값으로 유도합니다
가시화 — 문서화율, 품질 통과율, SLA 준수율을 측정해 공개합니다
작게 시작하고 확장 — 한 도메인에서 성공 사례를 만든 뒤 넓힙니다
경영진 지원 — 우선순위 경쟁에서 밀리지 않으려면 필요합니다

데이터 메시는 거버넌스와 어떤 관계인가요

데이터 메시는 소유권을 도메인 팀에 분산하는 접근입니다. 중앙 데이터 팀이 병목이 되는 문제를 풀려는 시도입니다.

여기서 거버넌스는 연합형(federated computational governance)이 됩니다. 중앙은 표준(메타데이터 형식, 품질 기준, 보안 정책)을 정하고 플랫폼으로 강제하되, 실제 데이터 제품의 내용은 도메인이 책임집니다.

전제 조건이 만만치 않습니다. 도메인마다 데이터를 다룰 역량이 있어야 하고, 셀프서비스 플랫폼이 갖춰져 있어야 합니다. 조직이 작다면 중앙 집중이 훨씬 효율적입니다.

데이터 엔지니어 인터뷰 — 데이터 마트 구축