보안을 넘어선 거버넌스: 레이크하우스의 지식, 컨텍스트 및 온톨로지

대부분의 조직에 AI를 위한 데이터 거버넌스가 무엇을 의미하는지 물어보면, 보안 관점의 답변을 듣게 될 것입니다. 즉, 데이터를 잠그고, 액세스를 제한하고, 감사를 통과하는 것이죠. 헬스케어 분야에서 보안은 타협할 수 없는 필수 요소이지만, 그것만으로는 충분하지 않습니다. 보안은 누가 데이터에 접근할 수 있는지만 알려줄 뿐입니다. 데이터가 무엇을 의미하는지, 데이터를 신뢰할 수 있는지, 또는 AI 모델이 그 데이터로부터 학습해야 하는지에 대해서는 아무것도 말해주지 않습니다.

저희의 Data Empowerment Program (DEP)은 다른 전제에서 출발합니다. 거버넌스는 단순한 통제가 아니라 지식, 컨텍스트, 온톨로지(ontology)라는 점입니다. 대부분의 팀이 규정 준수를 위한 오버헤드로 취급하는 분류 태그, 비식별화 정책, 모델 카드, 데이터 계약과 같은 산출물들은 사실 기업 데이터 의미론(semantics)의 기초 자료가 됩니다.

이런 관점으로 바라보면 거버넌스와 AI 중 하나를 선택하는 것이 아니라, 거버넌스가 AI 구축을 돕는다는 것을 알게 됩니다. AI 시대에는 거버넌스에 대한 새로운 접근 방식이 도입되어야 합니다. 유일한 질문은 단지 감사를 통과하기 위해 나중에 이 작업을 할 것인가, 아니면 지금 시작하여 AI가 구동될 기반을 마련할 것인가 하는 점입니다.

저희의 목표는 여러분이 이미 수행하고 있는 보안 및 거버넌스 작업이 바로 AI가 구동되는 기반임을 보여주는 것입니다. 데이터를 충분히 잘 거버닝하면, AI는 더 높은 신뢰성을 바탕으로 더 저렴한 모델에서도 구동될 수 있습니다.

거버넌스는 하나의 렌즈를 통해 다섯 가지 핵심 축을 아우르는 더 넓은 시각을 가져야 합니다

모든 거버넌스 산출물이 의미론(semantics)에 기여한다는 렌즈에서 시작해 보세요. 모든 분류 태그는 개념입니다. 모든 모델 카드는 컨텍스트입니다. 모든 데이터 계약은 공유된 정의입니다. 모든 리니지(lineage) 링크는 관계입니다. 그렇게 해석하면, 여러분이 이미 운영 중인 보안 스택은 온톨로지의 초안이 되고, 카탈로그는 그것이 보관되는 곳이 됩니다.

그러면 거버넌스는 단일한 작업이 아니라 하나의 규율이 가진 다섯 가지 측면이 됩니다. 즉, 데이터 자체와 그 통제 방식, 그 위에 구축된 AI, 이를 이해해야 하는 사람들, 이를 비즈니스에 전달하는 제품, 그리고 이 네 가지를 하나로 묶어주는 공유된 컨텍스트입니다. 동일한 렌즈를 다섯 가지 전선에서 바라보는 것입니다.

DEP를 통해 저희는 다섯 가지 핵심 축을 통해 의미론을 구상합니다:

• 데이터 거버넌스(Data Governance) — 카탈로그, 품질, 큐레이션, 리니지, 그리고 PII 분류, 액세스 제어, HIPAA/GDPR, AI 전용 개인정보 보호 위험 등 내장된 보안 및 컴플라이언스.
• 지식(AI/ML) 거버넌스 — 모델 문서화, 거버넌스, 그리고 편향 및 공정성, 설명 가능성, 인간의 감독, EU AI Act 대비 등 책임감 있는 AI(responsible-AI) 표준.
• 데이터 리터러시(Data Literacy) — 교육, 셀프 서비스 지원, 실무자 인증, 그리고 도입률, 사용량 메트릭, 프로그램 ROI 등의 KPI.
• 데이터 관리(Data Management) — 아키텍처, 데이터 엔지니어링, 그리고 스키마 합의, SLAs 및 품질 임계값, 생산자/소비자 의무를 포함해야 하는 데이터 제품 계약.
• 온톨로지(Ontology) — 용어집, 분류 체계(taxonomy), 지식 그래프 - 궁극적으로 AI 의미론적 레이어(semantic layer)로 완성됩니다. 여기에는 LLMs를 위한 컨텍스트, RAG 그라운딩, 챗 쿼리 준비 상태가 포함됩니다.

에이전트를 통한 비전의 실행력 확보

플랫폼이 이를 실행 가능한 것으로 구현해 내지 못한다면, 저희의 다섯 가지 핵심 축 비전은 그저 슬라이드 속의 계획으로 끝날 것입니다. 거버넌스 산출물이 구조화되고 기계가 읽을 수 있는 메타데이터로 존재하게 되면, 이는 단순한 문서에 그치지 않고 에이전트를 위한 지침 세트가 됩니다.

저희가 "에이전"를 언급할 때는 두 가지 방식을 염두에 둡니다. 데이터 제품을 조립하고 전달하는 '빌드 에이전트(build agents)'와 그 위에서 비즈니스 질문에 답하는 '분석 에이전트(analytic agents)'이며, 각각은 단일 데이터 제품에 바인딩됩니다.

먼저 빌드 에이전트부터 살펴보겠습니다. 빌드 에이전트는 소스 매핑부터 ETL, 테스트, 비식별화를 거쳐 프로덕션 릴리스에 이르기까지 데이터 제품의 전달 수명 주기를 자동화합니다. 이들에게 필요한 모든 것은 거버닝된 메타데이터로서 Unity Catalog에 존재합니다. 즉, 소스-타겟 매핑, 비즈니스 정의, 분류 계층, 비식별화 정책, 데이터 계약, 모델 카드 등이 이에 해당합니다. 플랫폼은 태그, 주석, 인증 플래그, 리니지, 용어집 연결 용어 등에서 이를 도출합니다. 카탈로그는 단순히 거버넌스를 문서화하는 곳이 아니라, 에이전트가 실행되는 런타임입니다.

각 에이전트는 루프 형태로 작동합니다. 카탈로그에서 지침을 읽고, 파이프라인 코드 생성, 테스트 스위트 실행, 비식별화된 데이터 생성, 또는 인증된 데이터 세트 배포와 같은 구체적인 작업을 수행한 다음, 그 결과를 테스트 결과, 품질 점수, 리니지 또는 변경 데이터 캡처 등의 증거로 다시 카탈로그에 기록합니다. 이 과정이 반복됩니다.

실제 적용 시에는 De-ID(비식별화) 및 테스트 에이전트를 먼저 배치합니다. 이들은 가장 높은 위험과 가장 번거로운 수작업을 초기에 제거해 줍니다. 효과를 가장 빠르게 볼 수 있는 곳부터 시작하면 초기에 추진력을 얻는 데 도움이 됩니다. 루프를 계속 진행하는 동안, 카탈로그에 설명되어 있지 않은 데이터에 대해 작동하는 에이전트는 없습니다.

최신 카탈로그는 관리자(steward)가 승인할 수 있도록 열 및 테이블 설명을 자동 생성하고, 민감한 필드를 자동으로 분류하며, 수작업 관리 없이도 열 수준의 리니지를 캡처할 수 있으므로 이러한 접근 방식을 확장 가능하게 만듭니다. 사람의 역할은 메타데이터를 직접 작성하는 것에서 승인하는 것으로 전환되며, 이는 바로 인간이 해야 할 판단 작업의 본질입니다.

데이터 및 AI 빌드 수명 주기: 증명 및 지속적인 컨텍스트

빌드 에이전트는 거버닝된 데이터 제품(매핑, 큐레이션, 파이프라인)과 그 위에서 구동되는 분석 에이전트(의미론적 레이어, 프롬프트 구성, 평가 스위트)라는 두 가지 자산을 동시에 릴리스하도록 설계된 엔드투엔드 수명 주기 내에서 작동합니다.

이러한 접근 방식은 파이프라인 중심 엔지니어링(데이터를 A 지점에서 B 지점으로 이동)에서 컨텍스트 중심 엔지니어링(LLMs가 데이터를 이해하고 활용할 수 있도록 지원)으로의 근본적인 패러다임 전환을 의미합니다. 코드 품질만 인증하는 대신, 이 수명 주기의 게이트(gate)는 의미론, 컨텍스트 및 소유권을 검증합니다.

이 프레임워크를 기존 SDLC와 구별하는 두 가지 핵심 특성은 다음과 같습니다:

• 자동 증명 가능성: 신뢰성에 대한 증명은 사후에 급하게 마련하는 감사 대비용 자료가 아니라, 전달 과정에서 자연스럽게 생성되는 부산물입니다.
• 지속적인 컨텍스트 개선: 프로덕션 환경에서의 동작이 AgentOps 루프에 피드백을 제공하여, 실패한 쿼리, 환각(hallucination) 클러스터, 사용자의 비추천(downvote)을 다음 스프린트의 의미론적 백로그로 전환합니다.

사람 관리자는 두 특성 모두에 대한 책임 레이어 역할을 합니다. 즉, 에이전트가 제안하고 사람이 승인합니다. 두 트랙에 걸쳐 다섯 개의 게이트를 관리하는 것이 긴 병목 현상을 만드는 것처럼 보일 수 있지만, 대부분의 게이트는 단 몇 시간 만에 통과할 수 있습니다. 승인은 표준 개발자 도구 내에서 직접 이루어집니다. 티켓이 열리기 전에 자동화된 테스트 스위트가 데이터 품질 결과, 평가 점수, 리니지를 첨부합니다. 공식적인 게이트 회의는 문제를 조사하기 위한 예외적인 조치일 뿐, 표준 운영 절차가 아닙니다.

AI 인증(AI Certification)은 게이트를 움직이는 엔진입니다

이러한 게이트를 임의적이 아닌 객관적으로 만드는 메커니즘은 바로 AI 인증입니다. Unity Catalog에 직접 기록되는 이 인증은 수동으로 작성하는 법적 증명서가 아니라, 쿼리 가능한 자동화된 스코어카드 역할을 합니다. 이는 네 가지 핵심 차원에 걸쳐 릴리스 자격을 제어합니다:

• 자동 점수 산정 vs. 사람의 점수 산정: 거버넌스, 품질, 의미론 점수는 쿼리 가능한 시스템 테이블, 파이프라인 결과, 평가 실행을 통해 자동으로 계산됩니다. 소유권 점수와 최종 배포 승인에는 관리자의 명시적인 서명이 필요합니다.
• 지속적인 만료 처리: 인증은 동적입니다. 스키마 변경, 계약 업데이트 또는 평가 스위트 실패가 발생하면 검사를 다시 실행하여 통과할 때까지 인증이 즉시 취소됩니다.
• 데이터 레이어 강제 적용: 액세스 제어는 애플리케이션 레이어가 아닌 데이터 레이어에서 속성 기반 액세스 제어(ABAC)를 통해 작동합니다. 사용자가 SQL에서 특정 행을 쿼리할 수 없다면, 어떤 에이전트도 벡터 검색이나 임베딩을 통해 이를 검색할 수 없습니다.
• 엄격한 경계 격리: 비프로덕션 환경(SIT, 회귀 테스트, 모델 테스트)은 합성 데이터 또는 비식별화된 데이터만 전적으로 사용합니다. 이를 통해 프로덕션 PHI가 거버닝된 경계를 벗어나지 않도록 보장합니다.

에이전트가 틀렸을 때, 누가 이를 수정하나요?

인증과 게이트는 에이전트가 출시 시점에 신뢰할 수 있었음을 증명합니다. 하지만 거버넌스 리더들이 던지는 질문은 "어떻게 작동하는가"가 아니라 "잘못된 답변을 제공할 때 누구에게 책임이 있는가?"입니다. 그 답변은 운영위원회가 아니라 구체적인 이름이어야 합니다.

이를 해결하기 위해 각 분석 에이전트(예: Databricks Genie Agent)는 지정된 소유자가 있는 단일 거버넌스 데이터 제품에 바인딩됩니다. 기본 메트릭이 잘못 정의되어 에이전트가 잘못된 결과를 반환하는 경우, 이 문제는 AI 엔지니어링 팀의 책임이 아닙니다. 대신 카탈로그 정의를 수정하는 Data Product Owner에게 직접 전달됩니다. 에이전트를 도메인 범위의 인증된 데이터 제품에 바인딩하는 것은 정확도를 높일 수 있는 가장 큰 지렛대이기도 합니다. 인증된 메타데이터를 쿼리하는 집중된 에이전트는 전체 엔터프라이즈 자산에서 추측하는 글로벌 모델보다 일관되게 더 나은 성능을 발휘합니다.

결정적으로, 이 공유 메트릭 정의는 단순히 문서화되는 데 그치지 않고 강제 적용됩니다. 인증된 메타데이터가 카탈로그에 정의되면, 답변 에이전트는 해당 메트릭에서 직접 계산해야 합니다. 이를 통해 정적 문서가 활성 런타임 로직으로 전환됩니다.

AI가 사람의 감독 없이 수행할 수 있는 작업에 엄격한 제한을 두기 때문에 책임이 유지됩니다. 사람의 개입 없이는 어떤 에이전트도 코드를 프로덕션에 배포하거나, 정책을 수정하거나, 분류되지 않은 데이터에서 작동할 수 없습니다. 인증 점수는 자동으로 계산되지만, 최종 출시 게이트에는 항상 사람의 서명이 필요합니다. 카탈로그가 데이터 자산을 명시적으로 설명하지 않는 경우, 시스템은 추측하는 대신 기본적으로 억제(suppression)를 수행합니다. 런타임 시 이 fail-closed 정책은 명확한 경계를 적용합니다:

• 분석 에이전트의 경우: 원시 데이터에 대한 컨텍스트를 추측하거나 추론하는 대신, 에이전트는 명시적으로 답변을 거부하고 투명한 메시지(예: "이 데이터 세트에는 귀하의 요청을 처리하는 데 필요한 활성 인증 또는 시맨틱 매핑이 부족합니다.")를 반환합니다.
• 빌드 에이전트의 경우: 파이프라인 조립 중에 분류되지 않은 스키마나 누락된 계약이 감지되면 스테이징 환경에 도달하기 전에 실행이 자동으로 중단되고, 스튜어드 검토를 위해 매핑되지 않은 자산 플래그를 로깅합니다.

이러한 가드레일을 문서로 정의하는 것은 쉽지만, 실제로 작동하게 하려면 모호한 거버넌스 위원회를 책임이 명확한 네 가지 역할로 대체해야 합니다:

• Data Product Owner: 거버넌스 제품의 정의와 품질을 책임집니다. 답변이 틀렸을 때 단일 연락 창구가 됩니다.
• Data & AI Governance Engineer: 정책을 실행 가능한 카탈로그 메타데이터(분류, 계약, 계보)로 변환하여 규칙이 PDF에 머무르는 대신 런타임에 실행되도록 합니다.
• Steward: 자동화된 결과를 검토하고 출시 게이트를 승인합니다. 자동화가 제안하고 스튜어드가 결정합니다.
• Security / IAM: 비식별화 및 행 수준 권한을 자동으로 구동하는 분류 계층 및 액세스 속성을 소유합니다.

보안을 타협하지 않고 엄격하게 테스트하기

우리가 설명한 수명 주기에는 까다로운 전제 조건이 숨어 있습니다. 이러한 모든 테스트 및 평가 단계는 실행할 실제와 유사한 데이터가 필요하지만, 헬스케어 분야에서는 실제 PHI를 테스트할 수 없습니다. 따라서 보안을 타협하지 않으면서 어디서나 사용할 수 있는 실제와 유사한 테스트 데이터가 필요하다는 과제가 발생합니다.

비식별화는 데이터를 분석적으로 유용하고 안전하게 유지하는 방법입니다. 비식별화 에이전트는 어디서 지식을 얻을까요? 수동으로 관리되는 스프레드가 아닙니다. 엔터프라이즈 도구가 이미 생성한 보안 정책을 기반으로 작동합니다. 흐름은 다음 세 단계로 구성됩니다:

• Discover - 자동화된 검색 스캐너와 InfoSec 정책 엔진이 민감한 열과 파일을 분류합니다.
• Curate - 분류 정보는 큐레이팅된 정책 메타데이터로 카탈로그에 저장되며, 에이전트는 해당 큐레이션을 읽고 실행합니다.
• Execute - 메타데이터를 수집하고 합성 데이터 또는 비식별화된 소스 파일을 생성합니다. HIPAA Safe Harbor를 준수하고, 참조 무결성이 유지되며, 분석이 가능합니다.

보안 및 IAM 팀에게 이것은 상호 호혜적인 관계입니다. InfoSec 정책은 더 이상 PDF에 머무르지 않고 실행 가능해집니다. 분류 계층과 보존 규칙이 비식별화를 자동으로 구동합니다. 그 대가로 보안 팀은 민감한 데이터에 대해 지속적으로 업데이트되는 뷰, 새로 발견된 모든 항목에 대한 fail-closed 보호, 실행할 때마다 감사 증거를 생성하는 잔여 스캔을 얻게 됩니다. 액세스 모델은 처음부터 끝까지 동일하게 유지됩니다. 에이전트의 모든 데이터 검색은 쿼리를 수행하는 사용자의 카탈로그 권한을 상속하므로, RAG 접근 방식은 사용자가 볼 권한이 없는 행의 임베딩을 노출할 수 없습니다. 동일한 ABAC 규칙이 SQL과 벡터 검색 모두에 적용되며, 에이전트는 권한이 있는 서비스 계정이 아니라 쿼리를 수행하는 사용자의 권한으로 작동합니다. 모든 에이전트 프롬프트는 데이터 자체와 동일한 거버넌스 하에 답변에 사용된 계보와 함께 로깅됩니다.

이것이 바로 진정한 해금입니다. 별도의 모델 레지스트리와 별도의 벡터 저장소에 임시로 연결된 데이터 카탈로그가 아니라, 데이터, 모델, 임베딩, 감사 내역 전반에 걸쳐 하나의 권한 모델이 적용되는 것입니다. 거버넌스 작업은 병행 프로젝트가 아니라 AI의 기반이 됩니다.

메트릭 캡처, 결과 증명, 신뢰 확보

이 수명 주기가 지금까지 무엇을 해왔는지 주목해 보세요. 모든 단계, 모든 게이트, 모든 인증이 메트릭을 생성해 왔습니다. 네 가지 인증 차원을 데이터 세트당 하나의 AI 준비도(AI-readiness) 점수로 통합하고, 이를 희망 사항이 아닌 실행 가능한 상태로 만드세요. 시맨틱은 모든 열에 용어집과 연결된 정의가 있고 테이블에 서명된 데이터 계약이 있는 경우에만 100%에 도달합니다. 소유권은 지정된 소유자가 문제에 대응할 때만 100%에 도달합니다.

점수 지정에 따르는 결과는 전체 DEP 프로그램의 비즈니스 사례가 됩니다. 즉, 메트릭은 AI의 결과를 증명하고, 증명은 신뢰를 얻으며, 신뢰는 파일럿을 일상적인 사용으로 전환하는 원동력입니다. 아키텍처 다이어그램이 우아하다고 해서 에이전트를 도입하는 비즈니스 사용자는 없습니다. 지난주에 수치가 정확했고, 그렇지 않았을 때 책임 있는 누군가가 이를 수정했기 때문에 도입하는 것입니다. 이 점수는 애초에 왜 수치가 정확하게 나오는지를 설명합니다. 점수가 높을수록 모델이 추측해야 하는 부분이 줄어듭니다. 카탈로그가 이미 알려주었기 때문에 열의 의미를 유추하거나, 중복을 보완하거나, 조인을 환각(hallucinating)할 필요가 없습니다.

모델 헤드라인을 쫓지 마세요. 모델 경제성을 쫓으세요.

매주 더 크고 비싼 모델이 출시됩니다. 하이프 사이클이 놓치고 있는 점은 다음과 같습니다. 카탈로그가 이미 의미, 품질, 컨텍스트를 제공한다면 모델이 이를 제공할 필요가 없습니다. 더 작거나 오픈 가중치(open-weights) 모델로도 거버넌스 데이터에 대한 보고 및 분석 요구 사항의 대부분을 충족할 수 있습니다.

프론티어 모델은 종종 근본적인 메타데이터 공백을 가리는 데 사용됩니다. 스키마와 비즈니스 규칙이 명시적으로 카탈로그화되면, 더 작은 도메인 특정 모델이 토큰 비용의 아주 일부만으로도 동일한 정확도를 제공합니다.

이는 비용 대비 품질의 선택이지 품질의 한계가 아닙니다. 일상적인 작업의 규모를 적절히 조정하고, 프론티어 모델에 대한 비용은 진정으로 필요한 문제에만 아껴두면 비용 때문에 AI를 중단해야 하는 일은 결코 발생하지 않습니다. 데이터를 수정하세요. 모델 규모를 적절히 조정하세요. 정확도를 유지하세요. 이것이 바로 거버넌스 기반이 AI 전략에 가져다주는 이점입니다. 더 저렴한 AI가 아니라, 멈출 수 없는 AI를 얻게 됩니다.

조치 취하기: 하나의 데이터 제품으로 시작하기

한 번에 전사적인 개편을 시도하지 마세요. 하나의 데이터 제품을 전체 수명 주기에 걸쳐 진행해 보며 모델을 증명하세요:

1. Scan: 단일 대상 스키마에서 자동화된 검색 스캔을 활성화합니다.
2. Define: 완결성, 시맨틱, 품질에 대해 Unity Catalog에서 명시적인 인증 임계값을 설정합니다.
3. Bind: 전용 평가 제품군 및 비식별화된 테스트 경로와 함께 하나의 분석 에이전트를 데이터 세트에 연결합니다.
4. Assign: 정의 및 문제 해결을 책임질 지정된 단일 Data Product Owner를 임명합니다.

루프가 실행되면 인증된 데이터 제품을 한 번에 하나씩 이 프로세스를 반복하세요. 보안은 데이터에 액세스할 수 있는 사람을 알려주지만, 거버넌스는 데이터가 무엇을 의미하는지 그리고 AI가 이를 신뢰할 수 있는지를 알려줍니다.

거버넌스는 데이터 기반 조직 앞을 가로막는 문이 아닙니다. 올바르게 실행된다면, 거버넌스는 조직을 지탱하는 단단한 토대입니다.

(이 글은 AI의 도움을 받아 번역되었습니다. 원문이 궁금하시다면 여기를 클릭해 주세요)