비즈니스 팀이 데이터 팀에 분석 요청을 넣고 며칠씩 기다리는 구조에서 벗어나고 싶은 조직은 많다. BI 플랫폼에 AI 에이전트를 붙이면 자연어로 질문하고 곧바로 쿼리 결과를 받을 수 있다는 점이 매력적으로 보인다. 그런데 실제로 도입을 검토하다 보면, 속도를 얻는 대신 무엇을 통제할 수 없게 되는지가 선명하지 않은 채로 의사결정이 진행되는 경우가 꽤 많다.
이 글은 셀프서비스 분석 범위를 넓히려는 제품 관리자와 IT 의사결정자가 벤더를 고르기 전에 스스로 짚어봐야 할 판단 기준을 다룬다.
AI 에이전트가 쿼리를 생성할 때 무엇이 통제되지 않는가
AI 에이전트 기반 쿼리의 핵심 편의는 사용자가 SQL을 몰라도 데이터를 꺼낼 수 있다는 것이다. 그런데 이 편의는 동시에 쿼리가 어떻게 만들어지는지, 어떤 테이블에 접근하는지, 얼마나 비싼 연산을 실행하는지를 에이전트가 결정하게 만든다.
통제되지 않은 상태에서 나타나는 문제는 크게 두 가지다.
첫째는 데이터 접근 범위다. 에이전트가 웨어하우스에 직접 연결된 구조라면, 사용자 계정 권한 내에 있는 모든 테이블이 잠재적인 조회 대상이 된다. 비즈니스 사용자가 마케팅 성과를 보려다가 개인정보가 섞인 원시 로그 테이블을 에이전트가 참조해 결과를 돌려줄 수 있다. 이 경우 사용자가 의도적으로 접근한 것이 아니어도, 데이터가 노출되었다는 사실은 바뀌지 않는다.
둘째는 쿼리 비용이다. 자연어 질문 하나가 최적화되지 않은 풀 스캔 쿼리로 변환되면, 클라우드 데이터 웨어하우스에서는 예상보다 훨씬 많은 비용이 발생한다. 사용자가 "지난 3년치 전체 주문 트렌드를 보여줘"라고 입력했을 때, 에이전트가 파티션을 무시하고 테이블 전체를 스캔하는 쿼리를 생성하면 한 번의 질문으로 수십만 원어치의 처리량이 나갈 수 있다. 이것이 수백 명의 비즈니스 사용자에게 동시에 열려 있다면, 비용 구조는 예측 불가능해진다.
의미론적 계층이 하는 일과 거버넌스가 더해졌을 때의 차이
의미론적 계층(Semantic Layer)은 비즈니스 개념과 물리적 데이터 테이블 사이를 중개하는 계층이다. "매출"이 어떤 테이블의 어떤 컬럼을 어떻게 집계한 값인지, "활성 사용자"가 어떤 기준으로 정의되는지를 한 곳에 정의해두고, 모든 쿼리가 그 정의를 통과하게 만든다.
여기서 중요한 구분이 있다. 의미론적 계층 자체는 이미 dbt MetricFlow, Cube처럼 여러 도구가 제공한다. 이 도구들은 비즈니스 메트릭을 모델링하고 BI 도구에 제공하는 역할을 한다. 그런데 AI 에이전트가 붙었을 때 필요한 것은 단순히 정의를 제공하는 것이 아니라, 에이전트가 만든 쿼리를 그 정의 안에서 검증하고 벗어났을 때 거부하는 능력이다.
이것이 "거버넌스된 의미론적 계층"과 단순한 의미론적 모델링의 차이다. 거버넌스가 붙으면 에이전트는 정의된 범위 밖의 테이블에 직접 접근하는 쿼리를 만들 수 없고, 특정 사용자 역할이 볼 수 없는 필드를 포함한 결과를 반환할 수 없다. 에이전트가 아무리 자유롭게 쿼리를 생성하더라도, 그 쿼리가 유효한지를 판단하는 로직이 플랫폼 안에 존재한다.
어떤 조직에서 이 계층이 전제조건이 되는가
모든 조직에 동일한 기준이 적용되지는 않는다. 아래 조건 중 해당되는 항목이 많을수록, 거버넌스된 의미론적 계층을 제공하는 플랫폼을 먼저 검토해야 한다.
데이터 접근 범위가 역할마다 달라야 하는 경우. 내부 직원과 외부 파트너, 혹은 부서별로 볼 수 있는 데이터 범위가 다르다면, 에이전트가 생성하는 쿼리도 그 경계를 지켜야 한다. 개인정보 보호나 계약 상의 데이터 공유 제한이 있는 조직은 특히 이 조건에 해당된다.
비기술 사용자가 직접 분석을 실행하는 규모가 크거나, 커질 예정인 경우. 사용자 수가 적고 데이터 팀이 결과를 매번 검토할 수 있을 때는 에이전트가 만든 쿼리 결과의 정합성을 사후에 잡을 수 있다. 하지만 수십, 수백 명이 동시에 자유롭게 쿼리를 실행한다면 사후 검토는 현실적이지 않다. 쿼리 생성 시점에 검증이 이뤄져야 한다.
클라우드 웨어하우스 비용이 이미 예측을 벗어나거나, 사용량 폭증 가능성이 있는 경우. 셀프서비스 분석 도입 후 쿼리 비용이 급격히 올라간 경험이 있는 조직이라면, AI 에이전트를 추가하기 전에 쿼리 라우팅과 비용 통제 구조를 먼저 갖춰야 한다. 파티션 인식 쿼리 라우팅이나 집계 테이블 활용 같은 성능 최적화가 의미론적 계층 수준에서 이뤄지지 않으면, 에이전트가 매번 최적화되지 않은 경로를 선택할 수 있다.
메트릭 정의가 팀마다 다르게 사용되고 있는 경우. 마케팅팀의 "전환율"과 영업팀의 "전환율"이 다른 계산식을 쓴다면, 에이전트가 아무리 빠르게 답을 줘도 그 답이 어느 정의를 따른 것인지 알 수 없다. 의미론적 계층에서 메트릭 정의를 단일화하지 않으면, AI 에이전트는 속도는 빠르지만 신뢰할 수 없는 분석 도구가 된다.
벤더 선택 전에 확인해야 할 질문들
플랫폼 데모를 보기 전에 먼저 내부에서 답해야 할 질문과, 벤더에게 직접 확인해야 할 질문을 구분할 필요가 있다.
내부에서 먼저 정해야 할 것들이 있다. 어떤 사용자 역할이 어떤 데이터 범위까지 볼 수 있는지 현재 정의되어 있는가. 쿼리 비용에 월별 상한이 있는가, 초과 시 어떤 알림 구조가 있는가. 비즈니스 메트릭 정의가 한 곳에 관리되고 있는가, 아니면 팀마다 각자 관리하고 있는가. 이 세 가지에 명확한 답이 없다면, 어떤 BI 플랫폼을 선택해도 거버넌스 문제는 도구 밖에서 반복된다.
벤더에게 확인해야 할 것들도 있다. AI 에이전트가 생성한 쿼리가 실행되기 전에 어떤 검증 단계를 거치는가. 사용자 역할별 데이터 접근 제한이 의미론적 계층 수준에서 적용되는가, 아니면 웨어하우스 권한 설정에만 의존하는가. 파티션 인식 쿼리 라우팅이 지원되는가, 집계 테이블을 자동으로 활용하는가. 메트릭 정의를 변경했을 때 에이전트가 만든 이전 쿼리 결과와의 일관성을 어떻게 관리하는가.
이 질문들에 플랫폼이 명확히 답하지 못하거나 "향후 로드맵에 있다"고만 한다면, 현재 상태에서는 에이전트 기반 쿼리의 위험을 통제할 수단이 없다는 의미로 받아들여야 한다.
거버넌스된 의미론적 계층이 없을 때 단계적으로 나타나는 문제
이 계층 없이 AI 에이전트를 먼저 연결하고 나중에 거버넌스를 붙이겠다는 계획은 현실에서 잘 작동하지 않는다. 순서가 뒤집히면 두 가지 이유에서 어렵다.
하나는 사용자 기대치다. 에이전트가 자유롭게 어떤 질문이든 받아주는 경험을 한 사용자에게 나중에 "이 데이터는 볼 수 없습니다"라는 제한을 추가하면, 기능 축소로 받아들여진다. 초기부터 경계가 설정된 환경에 적응한 것과는 다른 반응이 나온다.
다른 하나는 기술적 재작업이다. 에이전트와 웨어하우스를 직접 연결한 구조 위에 의미론적 계층을 중간에 끼워 넣으려면, 기존 쿼리 흐름을 상당 부분 재설계해야 한다. 데이터 접근 구조를 나중에 바꾸는 비용이 처음부터 갖추는 비용보다 크다.
상황별로 우선순위가 달라지는 지점
거버넌스된 의미론적 계층이 있는 플랫폼을 먼저 검토해야 하는 상황이 있고, 다른 축을 먼저 보는 게 합리적인 상황도 있다.
비즈니스 사용자 범위가 내부 소수 인원이고 데이터 범위가 제한적이며 웨어하우스 비용 관리가 이미 다른 수단으로 이뤄지고 있다면, 거버넌스 계층보다 대시보드 품질이나 도입 속도가 더 중요한 평가 기준이 될 수 있다.
반대로 사용자 범위가 넓고 외부 파트너가 포함되며 메트릭 정의가 분산되어 있고 웨어하우스 비용 예측이 어려운 조직이라면, 거버넌스된 의미론적 계층은 기능 목록의 한 항목이 아니라 도입 가능성의 전제조건이다. 이 경우 해당 계층이 없는 플랫폼은 데모에서 아무리 빠르고 예쁘게 보여도, 실제 운영 환경에서 필요한 통제를 제공하지 못한다.
다음 단계로 해야 할 일은 벤더 데모 일정을 잡는 것이 아니라, 위에서 정리한 내부 질문 세 가지에 지금 답을 적어보는 것이다. 메트릭 정의 현황, 사용자 역할별 접근 범위, 쿼리 비용 상한이 명확하지 않은 상태에서 플랫폼 비교를 시작하면, 데모에서 본 것과 실제 도입 후의 경험 사이 간극을 어디서 메워야 하는지 알기 어렵다.
