AI 데이터 분석 에이전트에 테이블을 다 보여주면 안 되는 이유: 검증된 질의 표면 계약 5단계

핵심 요약

• 분석 에이전트의 신뢰성은 연결한 테이블 수보다 승인된 데이터 경로의 명확성에서 나옵니다.
• 허용 소스, 함수·지표·사전 집계 뷰, 대표 질문, 최소 권한, 버전·승인을 하나의 운영 산출물로 관리해 보세요.
• 권한이 부족한 질문과 금지 열을 묻는 질문도 배포 전 평가에 넣어야 실제 운영에서 예측 가능한 동작을 만들 수 있습니다.
• 이 계약은 데이터 최신성 검토와 별개입니다. 최신 데이터라도 정의·권한·계산 경로가 불명확하면 답변을 신뢰하기 어렵습니다.

왜 전체 테이블 공개가 답이 아닐까요?

자연어로 “이번 주 순매출과 환불 영향은?”이라고 묻는 사람은 조인 순서나 열 이름을 알고 싶어 하지 않습니다. 일관된 업무 정의로 답을 받고 싶어 합니다. 그런데 원본 테이블을 넓게 열면 에이전트는 비슷한 이름의 열, 서로 다른 시간 기준, 검증되지 않은 조합 중 하나를 선택할 수 있습니다. 그 결과는 그럴듯해 보여도 검토와 재현이 어려워집니다.

반대로 질문이 통과할 경로를 작게 정하면, 팀은 무엇을 답할 수 있고 무엇을 사람에게 넘겨야 하는지 합의할 수 있습니다. Microsoft Fabric의 데이터 에이전트 문서는 선택한 데이터 소스와 조직별 instructions·examples·guidance를 구성 요소로 설명하고, Git과 배포 파이프라인으로 구성을 추적하는 방식을 안내합니다. 이는 제품 하나의 사용법이라기보다, 분석용 AI에 업무 문맥을 임의로 넓히지 말아야 한다는 실무적 힌트를 줍니다.

질의 표면 계약의 5요소

질의 표면 계약은 거대한 규정집이 아닙니다. 한 업무 도메인에서 에이전트가 사용할 수 있는 데이터 경로를 한 장으로 설명하는 카드입니다. 처음에는 매출, 환불, 운영 현황처럼 한 도메인만 고르는 편이 좋습니다.

1. 허용 데이터 소스: semantic model, 승인된 테이블, shortcut 또는 사전 집계 뷰를 적습니다. 원본 전체가 아니라 질문에 필요한 표면만 적습니다.
2. 승인된 계산 경로: 순매출처럼 정의가 중요한 값은 검증된 함수·지표·뷰로 지정합니다. Fabric 변경 이력은 Eventhouse의 사용자 정의 함수와 materialized view를 에이전트가 발견·질의할 수 있는 사례를 소개합니다.
3. 대표 질문과 답변 한계: 가능한 질문, 필터, 허용 기간, 모르는 경우의 응답을 함께 적습니다.
4. 최소 권한: 역할별 원본 접근, RLS/CLS 기대 결과, 거절되어야 하는 질문을 명시합니다.
5. 버전·담당자·갱신 기준: 계약 버전, owner, 갱신 주기, 변경 승인자와 되돌림 조건을 남깁니다.

질문 하나를 경로로 설계하는 예시

예를 들어 “이번 주 순매출과 환불 영향은?”을 허용하려면, 에이전트가 원시 주문·환불 테이블을 즉석에서 추측해 조인하도록 둘 필요가 없습니다. 아래처럼 질문과 경로를 연결해 두면 답변의 범위와 한계가 분명해집니다.

여기서 중요한 것은 특정 플랫폼의 명칭이 아닙니다. dbt는 MCP 서버 사례에서 정의된 metrics와 dimensions를 governed context로 제공하고, 지표·차원을 조회한 뒤 지표를 질의하는 도구 흐름을 제시합니다. 즉, AI에 필요한 것은 ‘더 많은 스키마’보다 정의된 업무 표면일 수 있습니다.

최소 권한과 실패 조건을 함께 설계하세요

권한은 “읽기 권한이 있으면 끝”이라고 정리하기 어렵습니다. Fabric의 공유·권한 문서는 공유된 에이전트를 사용하려면 기본 데이터 접근도 필요하며, RLS와 CLS가 유지되고 데이터 소스별 최소 유효 권한이 부족하면 질의가 실패할 수 있다고 설명합니다. 실제 권한 모델은 플랫폼과 데이터 소스마다 다르므로, 팀의 역할별 기대 동작을 직접 확인해야 합니다.

따라서 권한 부족은 예외가 아니라 평가 시나리오입니다. 예를 들어 임원 역할에는 지역 합계가 보이지만, 운영 담당자에게 다른 지역의 세부 정보가 보이면 안 된다는 식으로 예상 결과를 적어 두세요. 민감 열을 묻거나 승인되지 않은 기간·조합을 요구하는 질문도 명확하게 거절하거나 사람 검토로 전환되어야 합니다.

변경·배포·평가를 운영 흐름으로 만드세요

처음 계약을 만들었다고 끝나지 않습니다. 데이터 소스, 지표 정의, 예시 질문, 정책이 바뀌면 답변도 바뀔 수 있습니다. 그래서 dev-test-prod 환경의 설정 차이를 비교하고, 변경마다 승인 owner와 되돌림 기준을 남기는 편이 좋습니다. Git 기반 변경 추적과 배포 파이프라인을 언급하는 Fabric 문서는 이런 운영 흐름을 구성할 수 있는 한 가지 예입니다.

배포 전에는 적어도 네 종류의 질문을 같은 계약으로 평가해 보세요. 정상 질문은 승인된 지표로 답해야 하고, 경계 질문은 제한을 설명해야 하며, 권한 부족과 금지 열 질문은 기대한 방식으로 차단되거나 사람 검토로 넘어가야 합니다. 이 평가 결과가 쌓이면 에이전트의 품질을 단순한 데모가 아닌 운영 가능한 기준으로 볼 수 있습니다.

도입 전 체크리스트

• 한 번에 모든 도메인을 열지 않고, 첫 업무 도메인 하나를 정했나요?
• 허용 데이터 소스와 승인된 함수·지표·뷰를 구분했나요?
• 대표 질문마다 필터, 시간 범위, 답변 한계를 적었나요?
• 민감 열과 금지 조인을 명시했나요?
• 역할별 최소 권한과 RLS/CLS 기대 결과를 확인했나요?
• 권한 부족 질문이 어떻게 끝나야 하는지 정했나요?
• 계약 버전, 담당자, 갱신 기준, 승인자를 남겼나요?
• 정상·경계·권한 부족·금지 열·정의 충돌 질문을 평가했나요?
• 환경별 설정 차이와 되돌림 기준을 검토했나요?
• 답변 결과를 누가 어떤 기준으로 검토할지 정했나요?

다음에 연결할 운영 장치

질의 표면 계약은 데이터가 답변 가능한 상태인지 확인하는 과정과 함께 써야 합니다. FLOWIT의 AI 데이터 에이전트 데이터 품질 릴리스 게이트에서 최신성·규모·기대값을 먼저 점검한 뒤, 이 글의 계약으로 사용할 경로를 제한해 보세요. 답변이 나온 뒤에는 답변 근거 패킷처럼 정의·시점·필터를 검토 가능한 형태로 남기면 좋습니다. 계산과 규칙 판정의 경계를 더 넓게 다루고 싶다면 추론과 결정적 함수의 경계도 함께 참고하실 수 있습니다.

자주 묻는 질문

질의 표면 계약은 작은 팀에도 필요한가요?

네. 처음에는 한 도메인과 대표 질문 3~5개만 적어도 충분합니다. 규모보다 “어떤 데이터 경로를 믿고 운영할지”를 합의하는 일이 핵심입니다.

사전 집계 뷰를 쓰면 항상 더 정확한가요?

그렇지 않습니다. 사전 집계 뷰는 정의·갱신 시점·포함 범위가 검토되어 있을 때 유용합니다. 계약에 갱신 기준과 답변 한계를 적는 이유도 여기에 있습니다.

권한 부족 질문은 단순 오류로 처리해도 되나요?

단순 오류보다, 접근할 수 없는 이유와 다음 검토 경로를 일관되게 안내하는 편이 좋습니다. 다만 민감한 권한 구조 자체를 노출하지 않도록 응답 범위는 따로 정해야 합니다.

기존 BI 지표가 있다면 무엇부터 옮겨야 하나요?

가장 자주 묻고 정의가 안정된 지표부터 시작해 보세요. 지표 이름, 계산 경로, 허용 차원, 예외 조건을 카드에 넣고 대표 질문으로 평가하면 됩니다.

계약이 바뀌면 이전 답변도 다시 검토해야 하나요?

영향을 받는 질문과 지표를 식별할 수 있도록 계약 버전과 변경 이력을 남겨 두는 것이 좋습니다. 중요한 의사결정에 쓰인 답변은 변경 후 재확인 절차를 두세요.

참고 자료

• Microsoft Fabric 변경 이력 — Eventhouse 사용자 정의 함수, materialized view, shortcut table 관련 데이터 에이전트 업데이트를 확인했습니다.
• Microsoft Fabric data agent concepts — 데이터 소스, instructions·examples·guidance, Git 및 배포 흐름, 권한 개념을 확인했습니다.
• Microsoft Fabric data agent sharing and permission management — 공유된 에이전트의 데이터 접근, RLS/CLS, 최소 유효 권한 조건을 확인했습니다.
• dbt MCP server와 Claude — 정의된 metrics·dimensions를 AI에 제공하는 governed context 사례를 참고했습니다.