BigQuery Governance Agent란, 컬럼 계보 기반 데이터 거버넌스 자동화 방법

AS-IS: 거버넌스는 왜 항상 뒤늦게 따라오나

데이터 팀이라면 다들 겪는 순간이 있어요. 누군가 테이블을 열었는데 cust_seg_flg 같은 컬럼명을 보고 이게 뭔지, 써도 안전한지 물어보고 다녀야 하는 상황이죠. 원문은 이걸 수천 개 테이블과 뷰로 곱하면 거버넌스 부채의 진짜 비용이 나온다고 설명합니다. 컴플라이언스 실패가 아니라 데이터로 정직하게 일하려는 모든 사람에게 매일 부과되는 세금이라는 거예요. 기존 거버넌스 도구는 대부분 사후 대응형이라 문제를 스캔하고 리포트를 받고 티켓이 열리고 3주 뒤에야 컬럼 설명이 채워지는 식이었습니다. 원시 테이블이 조인, 필터링, 변형을 거쳐 뷰가 되고 그 뷰가 또 다른 뷰의 재료가 되는 파이프라인 구조에서, 컬럼의 의미와 PII 여부, 품질 기준 같은 원래 맥락은 함께 이동하지 않고 어딘가에서 유실됩니다. 그 결과 소수의 골드 테이블만 잘 관리되고 그 아래로 갈수록 문서화와 태깅 수준이 떨어지는 익숙한 패턴이 생깁니다. 실제 데이터 품질이 나빠진 게 아닌데도, 데이터의 신뢰도가 '누가 최근에 메타데이터를 손봤는가'로 결정되는 구조적 왜곡이 생기는 거예요.

실무에서 실제로 하는 네 가지 일

Governance Agent의 핵심 아이디어는 컬럼 단위 lineage로 컬럼의 출처를 찾아내고, 사람이 다시 만들어내지 않아도 이미 상위에 존재하는 거버넌스 메타데이터를 전파하는 것입니다. 구체적으로 네 가지를 처리해요.

첫째, 설명 전파입니다. transactions.customer_id처럼 상위에 명확한 설명이 있고 하위 뷰가 조인 몇 단계를 거쳐 그 컬럼을 그대로 가져온다면 에이전트가 lineage를 추적해 같은 설명을 제안합니다. 반면 SUM()이나 CASE WHEN, COALESCE처럼 단순 통과가 아닌 변형이 걸려 있으면 실제 SQL을 읽고 그 변형을 반영한 설명을 새로 작성해요. 즉 '복붙'이 아니라 SQL 파싱을 거친 조건부 전파라는 점이 실무적으로 중요합니다.

둘째, 비즈니스 용어집 매핑입니다. cust_seg_flg 같은 기술적 컬럼명과 실제 비즈니스 용어가 다른 경우가 많아서 의미 유사도로 통제된 용어집에 매핑하고, PDF 정책이나 스펙, 마크다운 문서 같은 비정형 문서를 읽어 명시적 정의를 찾기도 합니다.

셋째, 정책 태그 전파인데 리스크 관점에서 가장 무겁게 다뤄지는 부분이에요. 상위에서 PII로 태그된 컬럼이 어느 경로로 흘러가는지 추적해 같은 태그를 하위에도 권장하고, 현재 누가 읽기 권한을 가졌는지와 마스킹 규칙까지 함께 요약합니다. 여기서 실무적으로 중요한 분기가 하나 있는데, 변형이 값을 그대로 통과시키는 형태인지 아니면 집계, 익명화를 거쳐 더 이상 개인을 식별할 위험이 없는 형태인지를 구분해서 판별한다는 점이에요. 이 판별이 틀리면 과잉 태깅(불필요한 접근 제한)이나 누락(실제 PII 노출) 둘 다 문제가 되기 때문에, 이 경로가 에이전트 설계에서 가장 보수적으로 다뤄집니다.

넷째, 신뢰도와 데이터 품질 점수입니다. 모든 뷰를 처음부터 미지수로 취급하는 대신 상위 소스의 Data Quality and Profiling 결과를 상속하고, 중복 제거나 null 처리 같은 변형이 품질을 실제로 개선했다면 그만큼 점수를 가산합니다.

이 네 가지 모두 적용 전에 신뢰 임계값을 거치도록 설계됐고, 근거가 약하면 자동 전파 자체가 일어나지 않습니다. 이건 편의 기능이 아니라 '틀린 메타데이터를 대량으로 퍼뜨리지 않기 위한' 안전장치로 읽어야 해요.

lineage가 끊긴 구간은 문서로 보완

lineage는 강력하지만 완전하지는 않습니다. 새로 수집된 데이터셋이나 일회성 임포트, lineage 추적 체계보다 먼저 존재했던 테이블처럼 깔끔한 상위 소스가 없는 경우가 실무에선 꽤 흔해요. 이런 테이블에 대해 에이전트는 PDF 정책, 제품 스펙, 마크다운 설계 문서, 스프레드시트, 데이터 사전 스크린샷 같은 자체 문서를 근거로 삼습니다. 문서를 전달하는 방식은 세 가지로 나뉘는데, 짧은 문서는 전체 텍스트를 프롬프트에 직접 넣고, 50페이지짜리 데이터 분류 정책처럼 긴 문서는 청크로 나눠 임베딩한 뒤 해당 컬럼과 관련된 부분만 검색해서 매번 문서 전체를 다시 읽는 비용을 피합니다. 조직에 Vertex AI Search로 이미 색인된 문서 저장소가 있다면 그걸 직접 질의하는 방식도 가능해요. 이 세 가지 경로 중 어떤 걸 쓰느냐가 곧 비용 구조를 결정한다는 점을 실무에서는 눈여겨봐야 합니다. 문서 하나하나를 매번 통째로 프롬프트에 넣는 방식은 문서 수가 늘어날수록 토큰 비용이 선형으로 늘어나기 때문에, 청크 임베딩과 검색 기반 접근이 규모가 커질 때의 현실적인 선택지가 됩니다.

여기서 가장 눈여겨볼 지점은 근거 활용 방식이 상당히 보수적으로 설계됐다는 거예요. 문서에 컬럼이 명확히 정의돼 있지 않으면 모델이 추측하지 말고 '정의되지 않았다'고 밝히고 멈추도록 지침이 명시적으로 주어집니다. 특히 PII 여부처럼 잘못 판단했을 때 규제 리스크로 이어지는 항목은 이 멈춤 조건이 더 엄격하게 걸려 있고요. 실무에서 이런 도구를 도입할 때 가장 먼저 확인해야 할 게 바로 이 '멈추는 기준'이 얼마나 보수적인지입니다. 자동 전파율이 높다고 좋은 도구가 아니라, 틀렸을 때의 비용이 큰 영역(PII, 접근 권한)에서 얼마나 신중하게 멈추는지가 실제 신뢰도를 결정해요.

언제 쓰고 언제 안 쓰나

골드 테이블 몇 개는 잘 관리되지만 그 아래 수백-수천 개 뷰가 방치된 조직, 즉 상위 문서화 수준은 높은데 전파가 안 되는 구조에서 가장 효과가 큽니다. 반대로 lineage 추적 체계 자체가 아직 없거나 상위 테이블마저 문서화가 안 된 조직이라면 이 도구가 전파할 원본 메타데이터 자체가 없는 셈이라 효과가 제한적입니다. 또한 PII 판별처럼 결과가 규제, 법적 책임과 직결되는 영역에서는 에이전트의 제안을 최종 승인 없이 그대로 적용하는 방식은 원문이 설계한 '신뢰 임계값 통과 후에도 사람이 확인하는' 구조와 어긋나므로 권장되지 않습니다.

왜 중요한가

거버넌스 부채는 사고가 터지기 전까지 안 보이는 비용이라 예산 우선순위에서 항상 밀립니다. 이 프로젝트는 거버넌스를 감사 이벤트가 아니라 파이프라인이 돌아가는 동안 배경에서 계속 갱신되는 상태로 재정의하려는 시도라는 점에서, 단순 태깅 자동화 도구 이상의 의미가 있습니다.