주요 컨텐츠로 이동
모범 사례

거버넌스를 유지하면서 정형 데이터와 문서 모두에 Genie 에이전트를 그라운딩하는 방법

Genie 에이전트는 테이블, 메트릭, 문서를 한 번에 추론하여 컨텍스트 및 권한을 고려한 인사이트를 제공할 수 있습니다.

작성자: 정도영

• Genie 에이전트를 정형 데이터(관리형 테이블, 외부 테이블, 외래 테이블, 뷰, 메트릭 뷰, 구체화된 뷰) 및 비정형 파일(Unity Catalog 볼륨)에 기반하게 하여, 하나의 에이전트가 이 모든 데이터에 걸쳐 답변할 수 있도록 합니다.
• 에이전트 거버넌스는 모델 레이어가 아닌 카탈로그 레이어에 존재합니다. 거버넌스는 통제 불능 상태로 커지는 대신 에이전트와 함께 확장됩니다.
• Unity Catalog의 자동 ID 관리(AIM), 개체 권한, ABAC, 행 필터 및 열 마스크를 통해 Genie 에이전트는 사용자의 ID로 실행되며, 모든 답변은 해당 사용자의 권한에 따라 필터링됩니다.

단순한 비즈니스 작업을 자동화하는 에이전트를 구축하는 것은 쉬울 수 있습니다. 하지만 비즈니스를 실제로 이해하고 기존 데이터 거버넌스를 준수하는 에이전트를 만드는 것은 훨씬 더 어렵습니다.

오랫동안 팀들은 정형 데이터와 비정형 데이터를 분석하기 위해 별도의 시스템을 사용해야 했으며, 두 시스템을 연결하는 데만 몇 주씩 걸리기도 했습니다. 테이블과 비정형 파일에서 직접 분석을 수행할 수 있도록 지원함으로써, Genie 에이전트는 이러한 아키텍처를 단순화하고 정형 및 비정형 데이터 모두를 사용해 단일 에이전트를 그라운딩할 수 있게 해줍니다.

이 데이터를 통합할 때 중요한 질문이 생깁니다. 하나의 에이전트가 모든 것에 액세스할 수 있다면, 잘못된 사람에게 잘못된 정보를 알려주는 것을 어떻게 막을 수 있을까요?

다행히도 Databricks를 사용하면 이미 갖추고 있는 데이터 거버넌스 기반 내에서 그 해답을 찾을 수 있습니다. 현재 신뢰하고 사용 중인 동일한 Unity Catalog 메커니즘(ID 동기화, 오브젝트 권한, ABAC, 행 필터, 열 마스크)이 추가 설정 없이 Genie 에이전트를 자동으로 제어합니다. 이러한 원활한 상속은 잘 설계된 거버넌스 전략에 의존하며, 이에 대해 자세히 살펴보겠습니다.

이러한 개념을 구체화하기 위해, 가상의 글로벌 벽돌 소매업체인 Brickstore의 예를 참고 자료로 삼아 이러한 시나리오를 살펴보겠습니다.

거버넌스 계약: Genie 에이전트는 최종 사용자의 자격 증명으로 실행됩니다

핵심 아키텍처 원칙은 간단합니다. Genie 에이전트는 최종 사용자의 자격 증명으로 실행됩니다. Unity Catalog는 기본적으로 거버넌스를 강제하여 테이블 및 볼륨에 대한 액세스가 최종 사용자의 기존 ID 및 권한에 직접 연결되도록 보장합니다.

이는 매우 중요합니다. 많은 자체 구축 시스템이 에이전트에게 광범위한 액세스 권한을 부여하고 프롬프트 엔지니어링에 의존하여 모델 레이어에서 결과를 필터링하기 때문입니다. 이는 사실상 LLM을 보안 경계로 만드는 것이며, 모델이 조작되거나 우회될 수 있다는 점을 감안할 때 위험한 도박입니다. 감사관에게 "제한된 데이터를 표시하지 말라는 지침을 추가했습니다"라고 말하는 것은 옹호할 수 있는 거버넌스 통제 수단이 아닙니다.

이 글에서 설명하는 거버넌스 프레임워크를 사용하면 Databricks의 다른 부분과 마찬가지로 모델이 아닌 Unity Catalog가 보안 경계로 유지됩니다. Genie가 데이터를 쿼리하는 방법을 결정하지만, 모든 답변은 Lakehouse를 벗어나기 전에 데이터 레이어에서 필터링되므로 최종 사용자가 볼 권한이 없는 레코드를 반환할 수 없습니다.

0단계: ID에서 시작: Automatic Identity Management (AIM) 및 Just-in-Time (JIT) 프로비저닝

아키텍처의 기초는 기업 ID가 정확하고 최신 상태인지 확인하는 것부터 시작됩니다.

액세스 제어는 근본적으로 그것이 평가하는 ID만큼만 신뢰할 수 있습니다. Databricks의 그룹 멤버십이 ID 제공업체에 있는 정보의 오래되고 수동으로 유지 관리되는 복사본이라면 "brickstore_apac의 멤버는 APAC 주문만 볼 수 있습니다"라는 정책은 무의미합니다.

Automatic Identity Management for Microsoft Entra ID 및 Okta는 이러한 격차를 해소합니다. 이 기능을 활성화하면 SCIM 애플리케이션 없이도 해당 ID 제공업체의 사용자, 그룹, 그룹 멤버십 및 서비스 주체가 Databricks로 자동으로 동기화됩니다. Just-in-time 프로비저닝은 항상 켜져 있으므로 Databricks에 로그인한 적이 없는 사용자도 첫 로그인 시 프로비저닝되며 기존 그룹 멤버십을 이미 보유한 상태로 도달하게 됩니다.

단계별 흐름은 다음과 같습니다:

  1. IdP가 단일 진실 공급원(source of truth)입니다. 누군가 APAC 영업 조직에 합류하면, ID 제공업체(IdP)가 이들을 brickstore_apac 그룹에 배치합니다.
  2. AIM이 이를 Databricks로 동기화합니다 — 그룹 멤버십을 포함합니다. 사용자가 Genie One을 처음 열 때 JIT가 Databricks에 사용자를 프로비저닝합니다.
  3. Unity Catalog 정책은 해당 그룹을 기준으로 작동합니다 — 오브젝트 권한, ABAC 정책, 행 필터, 열 마스크는 모두 쿼리 실행 시점에 그룹 멤버십을 평가합니다.
  4. 사용자가 Genie 에이전트에게 질문을 하면, 답변은 해당 그룹 권한이 허용하는 범위에 정확히 맞춰 제공됩니다. 그 이상도 그 이하도 아닙니다.

이로 인한 이점은 거버넌스가 지속적으로 이루어진다는 것이며, 특정 시점의 설정에 그치지 않는다는 점입니다. 직원이 APAC에서 AMER로 이동하면 IdP가 이들을 그룹 간에 이동시키고, 동기화가 이를 전파하며, 이들이 Genie에게 묻는 바로 다음 질문은 AMER 뷰를 반환합니다. 누구도 티켓을 제출하거나 Genie 에이전트를 변경할 필요가 없습니다. 직원이 퇴사하면 IdP에서 비활성화되고 모든 Genie 에이전트에 대한 액세스 권한이 즉시 제거됩니다.

1단계: 정형 데이터 그라운딩 및 4개 액세스 레이어 제어

ID가 제대로 설정되면 이제 사용자가 볼 수 있도록 허용된 항목에 집중할 수 있습니다. 정형 데이터의 경우, Genie 에이전트는 테이블, 뷰, 구체화된 뷰(materialized views), 메트릭 뷰(metric views), 스트리밍 테이블, 외부 시스템에서 페더레이션된 외부 테이블(foreign tables) 등 모든 Unity Catalog 데이터 자산에 액세스할 수 있습니다.

예를 들어, Delta 테이블은 팩트(facts)와 디멘션(dimensions)입니다. Brickstore의 경우 brickstore.sales.orders(regioncustomer_email가 포함된 모든 주문)와 brickstore.sales.products(벽돌 카탈로그)가 이에 해당합니다. 메트릭 뷰는 그 위에 있는 제어된 시맨틱 레이어입니다. 비즈니스 메트릭의 정의(예: "순매출"의 의미, "판매된 벽돌 수" 계산 방법, "가장 많이 판매된 벽돌"의 기준)를 YAML에 한 번 인코딩하므로 모든 소비자가 동일한 방식으로 계산할 수 있습니다.

이러한 자산 위에는 사람들이 흔히 혼동하는 네 가지 액세스 제어 레이어가 있습니다:

레이어

답하는 질문

메커니즘

오브젝트 권한

누가 어떤 리소스에 대해 어떤 수준의 액세스 권한을 가집니까?

카탈로그/스키마/테이블에 대한 GRANT SELECT

속성 기반 액세스 제어 (ABAC)

어떤 정책이 무엇에 적용됩니까?

한 번 첨부되면 전파되는 거버넌스 태그 기반 정책 (예: "PII" 태그가 지정된 모든 열은 특정 그룹만 사용할 수 있음)

행 필터

사용자가 어떤 에 액세스할 수 있습니까?

쿼리 실행 시점에 각 행을 평가하는 SQL 사용자 정의 함수(UDF) (함수가 FALSE를 반환하는 행은 쿼리 결과에서 제외됨)

열 마스크

어떤 열을 어떻게 마스킹해야 합니까?

열 값을 입력으로 받아 원래 값 또는 마스킹된 버전을 반환하는 SQL UDF

오브젝트 권한은 액세스의 첫 번째 레이어입니다. SELECT이 없으면 Genie는 최종 사용자를 대신하여 테이블을 쿼리할 수 없습니다. 하지만 테이블에 대한 액세스 권한을 부여한다고 해서 모든 권한을 부여해야 하는 것은 아닙니다. 이러한 권한 부여 위에 행 필터와 열 마스크를 레이어로 적용하여, 지역 관리자가 주문 테이블을 쿼리할 때 원시 고객 이메일은 보지 못하고 자신이 담당하는 지역의 행만 볼 수 있도록 할 수 있습니다. 이러한 행 및 열 제어는 권한 부여에 이미 사용 중인 동일한 그룹( is_account_group_member('brickstore_apac') 등)을 기준으로 작동합니다. 다음에 설명할 ABAC는 이를 대체하는 것이 아니라, 테이블별로 필터와 마스크를 적용하는 대신 정책에 따라 동일한 필터와 마스크를 첨부하는 방법일 뿐입니다.

ABAC: 정책을 한 번 정의하고 전파되도록 설정

행 및 열 보안을 적용하는 기존 방식은 테이블별로 처리하는 것이었습니다. 행 필터를 작성하여 orders에 첨부하고, 열 마스크를 작성하여 다른 테이블에 첨부하는 과정을 계속 반복하는 방식입니다. 일회성 로직에는 여전히 적합할 수 있지만, 수백 개의 테이블에 적용할 때는 보안 공백이 발생하기 쉬운 구성입니다.

ABAC 정책은 거버넌스 태그 및 자동 데이터 분류와 함께 이제 Unity Catalog에서 정식 출시(GA)되어 이를 반대로 적용합니다. 민감한 데이터에 거버넌스 태그(계정 수준에서 액세스가 제어되는 키/값 쌍 예: pii:email)를 지정하고, "이 태그가 나타나는 모든 곳에 이 보호 조치를 적용하라"는 단 하나의 정책을 작성하면 됩니다. 새로운 테이블은 태그가 지정되는 즉시 보호 조치를 상속하므로 테이블별로 작업할 필요가 없습니다.

단 하나의 구문으로 카탈로그의 모든 이메일 열을 보호하는 열 마스크 + ABAC 정책:

그리고 그룹 멤버십을 기반으로 각 관리자가 자신이 담당하는 지역의 주문만 볼 수 있도록 하는 행 필터 + ABAC 정책:

그 결과, APAC 관리자가 주문에 대해 질문하면 Genie Agent는 customer_email이 마스킹된 APAC 행만 반환합니다. AMER 관리자가 동일한 테이블을 쿼리하면 AMER 행을 얻게 됩니다.

2단계: 동일한 거버넌스를 문서로 확장하기

과거에는 비정형 데이터를 다룰 때 팀의 거버넌스 전략을 수립하기가 더 까다로웠습니다. 정형 데이터는 데이터 웨어하우스나 데이터베이스에서 안전하게 관리되는 반면, 문서는 별도의 ACL로 관리되는 격리된 스토리지 시스템에 보관되는 경우가 많기 때문입니다.

해결책은 파일을 정형 데이터와 동일한 거버넌스 평면 내부에 유지하는 것입니다. 파일을 Unity Catalog Volumes에 저장하면 다른 모든 리소스와 마찬가지로 보안 대상이 됩니다. 문서를 볼 수 있어야 하는 그룹과 사용자에게 GRANT READ VOLUME 권한을 부여하면, Genie는 동일한 ID 계약에 따라 문서를 기반으로 추론을 수행합니다:

에이전트를 설계하기 전에 한 가지 동작 방식을 이해해 두는 것이 좋습니다. Genie Agent에 볼륨을 연결하면 해당 볼륨은 필수 소스가 됩니다. 즉, 에이전트가 로드될 때 연결된 모든 소스에 대한 액세스 권한을 검증하므로, 연결된 볼륨에 대한 READ VOLUME 권한이 없는 사용자는 해당 에이전트를 전혀 사용할 수 없습니다. 다시 말해, 볼륨 권한 부여는 에이전트 사용의 전제 조건으로서 문서를 제어하므로, 각 에이전트의 문서 소스 범위를 해당 에이전트를 사용해야 하는 대상으로 제한해야 합니다. 두 대상 그룹이 서로 다른 문서를 필요로 하는 경우, 각각 다른 Genie Agent를 제공해야 할 수 있습니다(각 에이전트는 사용자가 읽을 수 있는 볼륨만 마운트함).

또한 Unity Catalog Volume은 보안을 적용할 수 있는 가장 작은 단위이므로 개별 파일이 아닌 볼륨 전체에 권한이 적용된다는 점에 유의하세요. 공유할 특정 파일을 선택적으로 고를 수 없으며, 볼륨 전체에 대한 액세스 권한을 부여하거나 아예 부여하지 않아야 합니다.

이러한 점을 고려하여 테이블이나 뷰와 동일한 방식으로 볼륨을 Genie Agent에 지식 소스로 직접 연결할 수 있습니다. Genie Agent는 PDF뿐만 아니라 PDF, 이미지 파일(JPG, JPEG, PNG, TIFF, TIF), Office 문서(DOC, DOCX, PPT, PPTX), 일반 텍스트 및 Markdown을 포함한 다양한 형식을 지원합니다. 실제로는 깔끔한 PDF뿐만 아니라 스캔된 계약서, 슬라이드 덱, 사양서 등도 모두 활용할 수 있습니다. (전체 목록과 현재 제한 사항은 Genie Agent 볼륨 설명서를 참조하세요.)

Genie 볼륨

정확한 라우팅과 최적의 성능을 보장하려면 볼륨을 구성할 때 다음 모범 사례를 따르세요:

  • 명확한 설명 추가: 볼륨에 포함된 콘텐츠가 무엇인지, 어떻게 구성되어 있는지, 에이전트가 이를 어떻게 사용해야 하는지 정확하게 설명하세요. 일반적인 자리 표시자(placeholder)를 사용하지 마세요. 예를 들어 "지역 파일" 대신 "APAC 시장 보고서 — APAC 지역의 수요 동인, 트렌드 및 모니터링 항목"을 사용하세요. Genie는 이 설명을 바탕으로 적절한 볼륨을 선택합니다.
  • 중복 콘텐츠 방지: 중복된 정보가 포함된 여러 볼륨을 연결하면 에이전트가 관련 문서를 검색하기가 더 어려워집니다. 볼륨 내의 개별 파일에도 동일하게 적용됩니다.
  • 무관한 파일 제외: 에이전트의 도메인과 관련된 파일만 포함하세요. 무관한 파일은 에이전트에 혼란을 줄 수 있습니다.
  • 명확한 파일 이름 사용: 에이전트가 파일을 구분할 수 있도록 설명이 포함된 파일 이름을 사용하세요.

3단계: 프로덕션 환경의 Genie Agent: 같은 질문, 다른 답변

이 시점에서 Genie Agent는 정형 및 비정형 데이터 모두에 대한 전체 액세스 권한을 바탕으로 진정한 도메인 전문가 역할을 수행할 수 있는 모든 역량을 갖추게 됩니다. 기반 지식 베이스는 사용자별 권한에 따른 행 필터, 열 마스크 및 볼륨 권한 부여를 통해 여전히 철저하게 보호됩니다.

서로 다른 두 사용자가 완전히 동일한 질문을 하도록 테스트하여 구현 결과를 벤치마킹합니다. 이 경우 각각 고유하게 올바른 두 개의 답변이 생성되어야 합니다.

동일한 자산(orders 테이블, products 카탈로그, market_report 볼륨)을 기반으로 하는 두 개의 동시 Genie Agent 세션을 가정해 보겠습니다. 한 요청자는 brickstore_apac에 속하고 다른 요청자는 brickstore_amer에 속하지만, 두 요청자 모두 완전히 동일한 쿼리를 제출합니다:

"이번 분기에 가장 많이 판매된 제품은 무엇이며, 그 수요를 이끄는 요인은 무엇인가요? 또한 해당 매출을 견인한 주요 고객과 그들의 이메일 목록도 제공해 주세요."

답변 1 - APAC 관리자용

APAC 결과

답변 2 - AMER 관리자용

AMER 결과

주목할 만한 세 가지 사항이 있습니다:

  • 숫자는 다르지만 둘 다 맞습니다. 두 관리자의 "가장 많이 판매된 브릭" 쿼리는 동일한 테이블에서 데이터를 가져옵니다. 차이점은 지표가 계산된 방식이 아니라 순수하게 각 관리자에게 권한이 있는 행의 차이에서 비롯됩니다.
  • 이러한 차이를 만들기 위해 사용자별 프롬프트 엔지니어링이 전혀 필요하지 않았습니다. 아무도 "사용자가 APAC인 경우 다른 지역을 숨기라"고 작성하지 않았습니다. 에이전트의 지침은 동일합니다. Unity Catalog가 쿼리 시점에 행과 마스킹된 열 모두에 대해 필터링을 수행했습니다. 개인정보(PII)를 보호하기 위해 이메일 열이 마스킹된 것을 확인해 보세요.
  • 비정형 지식으로 풍부해진 정형 데이터. 지역 문서가 없었다면 Genie는 '무엇'에 대한 질문은 쉽게 식별할 수 있었겠지만, 어떤 요인이 수요를 주도하고 있는지 파악하는 데는 어려움을 겪었을 것입니다. 비정형 데이터를 사용할 수 있게 되면서 Genie는 비즈니스에 대한 전체적인 맥락을 파악할 수 있습니다.

주의 깊게 살펴봐야 할 패턴

이 블로그에서 배운 내용을 프로덕션에 적용할 때 주의해야 할 몇 가지 패턴은 다음과 같습니다.

  • 테이블별로 마스킹하지 말고, 먼저 태그를 지정한 다음 정책을 적용하세요. 눈앞에 보이는 몇 개의 테이블을 먼저 보호하고 싶은 본능이 생길 수 있습니다. 이를 지양하세요. 데이터 거버넌스의 미래를 대비할 수 있도록 거버넌스 태그와 ABAC 정책을 정의하세요.
  • 볼륨당 하나의 대상 그룹만 지정하세요. 볼륨은 권한을 부여할 수 있는 가장 작은 단위이므로, 볼륨 경계에서 문서 액세스 권한을 결정해야 합니다. 두 문서에 서로 다른 접근 권한을 가진 사용자가 필요한 경우, 서로 다른 볼륨과 서로 다른 Genie Agent가 필요합니다. 레이아웃을 미리 계획하세요.
  • MCP 또는 API를 통해 외부로 Genie One 또는 Genie Agent를 노출할 때는 신원(identity) 관리에 주의해야 합니다. Databricks UI를 통해 실행하는 것과 달리, 항상 최종 사용자의 신원을 사용할 수 있는 권한이 부여되는 것은 아닙니다(예: 인증을 위해 Service Principal을 사용하는 경우). 적용해야 할 특정 패턴이 있으며, Databricks는 어디서나 Genie 액세스하기(Access Genie everywhere)에서 U2M, M2M 및 OBO 구성에 대해 자세히 설명합니다.
  • 검사가 아닌 가장(impersonation)을 통해 테스트하세요. 단순히 정책을 읽고 맞을 것이라고 스스로 확신하며 거버넌스를 검증하지 마세요. 각 그룹의 구성원 자격으로 동일한 질문을 던지고 그 답변을 비교해 보세요. 이를 회귀 테스트로 만들어 정책이나 그룹 구성이 변경될 때마다 실행하세요.

핵심 요점

에이전트를 구축하는 것은 쉬울 수 있지만, 이를 제어하고 관리하는 데는 실제 설계 작업이 필요합니다. Databricks에서는 엔터프라이즈 신원이 IdP에서 동기화되고, 오브젝트 권한이 액세스를 제어하며, ABAC 및 거버넌스 태그가 대규모 보호를 적용하고, 행 필터 및 열 마스크가 반환되는 데이터를 제어하며, 문서는 데이터와 동일한 시스템에 보관됩니다.

이러한 설정을 통해 Genie Agent는 추가 구성 없이 모든 거버넌스를 그대로 상속받습니다.

거버넌스가 적용된 첫 번째 Genie Agent 구축을 시작하려면 Genie 문서 ABAC 정책 문서를 참조하세요.

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

최신 게시물을 이메일로 받아보세요

블로그를 구독하고 최신 게시물을 이메일로 받아보세요.