요약 (TL;DR) — 자연어 BI 에이전트(Natural-language BI agents) 덕분에 누구나 SQL을 작성하지 않고도 데이터 웨어하우스(Warehouse)에 질문할 수 있게 되었지만, 그 밑단의 분석 레이어(Analytics layer)는 여전히 여타 프로덕션 시스템과 동일한 엄격함, 즉 버전이 관리되는 지표 정의(Versioned metric definitions), 테스트된 변환(Tested transformations), 그리고 검토 가능한 로직(Reviewable logic)을 필요로 합니다. 위험 요소는 에이전트가 잘못된 SQL을 작성하는 것이 아닙니다. 소유권이 없는 시맨틱 레이어(Semantic layer)를 대상으로 그럴듯한 SQL을 작성하고, 이사회 보고서(Board deck)가 틀릴 때까지 아무도 이를 알아차리지 못한다는 점입니다. 분석 엔지니어링(Analytics engineering)의 역할은 작아진 것이 아니라 오히려 더 커졌습니다.

이제 모든 BI 벤더들은 채팅창을 탑재하여 출시하고 있습니다. 평범한 영어로 질문하면 차트가 돌아옵니다. 데모는 항상 똑같습니다. 누군가 "지난 분기 지역별 매출은 얼마였나요?"라고 입력하면 4초 만에 막대그래프가 나타납니다. 진심으로 인상적인 장면입니다. 하지만 이는 여러분의 데이터 스택(Data stack)에서 가장 위험한 4초이기도 합니다. 왜냐하면 그 데모에서 그 누구도 가장 중요한 질문을 던지지 않기 때문입니다: 그것이 어떤 "매출(Sales)"을 사용했는가?

위험 요소는 에이전트가 아닙니다. 에이전트가 물려받는 모호함입니다

분석 엔지니어(Analytics engineers)들은 지난 몇 년 동안 dbt 모델을 구축하고, 지표를 한 번 정의하며, 데이터 웨어하우스와 일치하지 않는 스프레드시트 기반의 "섀도우 메트릭(Shadow metrics)"과 벌이는 영원한 전쟁과 싸워왔습니다. 그 전쟁은 주로 규율(Discipline)을 통해 승리해 왔습니다: 풀 리퀘스트(Pull requests), 테스트, 그리고 "활성 사용자(Active user)"나 "순매출(Net revenue)"이 무엇을 의미하는지에 대한 단일 진실 공급원(Single source of truth)을 구축하는 방식 말입니다.

에이전트 기반 BI(Agentic BI)는 이러한 규율을 보이지 않게 만듦으로써 이를 무너뜨릴 위협이 됩니다. 데이터 웨어하우스 위에 자리 잡은 LLM(Large Language Model)은 특정 스키마(Schema)에서는 revenue가 환불을 제외하지만, 다른 스키마에서는 환불을 포함한다는 사실을 알지 못합니다. 또한 재무팀에게 "지난 분기(Last quarter)"는 회계 분기(Fiscal quarter)를 의미하지만, 마케팅팀에게는 달력 기준 분기(Calendar quarter)라는 사실도 알지 못합니다. 그럼에도 불구하고 모델은 자신 있게 쿼리를 생성할 것입니다. 왜냐하면 그럴듯한 SQL을 생성하는 것이 바로 이 모델들이 잘하는 일이기 때문입니다. 쿼리는 실행될 것입니다. 차트는 렌더링될 것입니다. 숫자는 틀릴 것이지만, 마치 올바른 숫자만큼이나 신뢰할 수 있는 것처럼 보일 것입니다.

이것은 모델의 품질이 스스로를 해결할 수 있을 만큼 빠르게 개선될 것이라는 가설에 관한 이야기가 아닙니다. 비즈니스 정의의 모호함은 언어의 문제가 아니라 조직의 문제입니다. 그리고 아무리 규모를 확장(Scaling)하더라도, LLM이 읽을 수 있는 곳 어디에도 기록되지 않은 내용을 알게 만들 수는 없습니다.

시맨틱 레이어(Semantic Layer)가 이제 핵심 지지대가 되었습니다

메트릭 레이어(Metric layers), 시맨틱 레이어(semantic layers), 무엇이라 부르든 — dbt의 metrics, Cube, LookML, headless BI 등 — 이들은 과거에는 메트릭을 한 번 정의하여 다섯 개의 대시보드에서 재사용할 수 있게 해주는 '있으면 좋은(nice-to-have)' 기능이었습니다. 하지만 에이전트 중심의 워크플로우(agent-driven workflow)에서, 이들은 단순한 편의 기능을 넘어 자연어와 진실 사이를 잇는 실제 인터페이스가 됩니다.

여기서 변화가 일어납니다. 인간 분석가가 SQL을 작성할 때는 스키마(schema)가 커버하지 못하는 빈틈을 비즈니스에 대한 그들의 정신적 모델(mental model)로 채웁니다. 그들은 2년 동안 화요일 매출 검토 회의에 참석해 왔기 때문에 "매출(sales)"이 순매출(net sales)을 의미한다는 것을 알고 있습니다. 에이전트에게는 화요일 매출 검토 회의가 없습니다. 에이전트가 아는 것은 테이블 이름, 컬럼 주석(column comments), 그리고 메트릭 정의(metric definitions)에 인코딩된 것뿐이며, 그 외에는 아무것도 모릅니다. 만약 여러분의 시맨틱 레이어가 빈약하다면, 에이전트의 유창함은 이를 보완하지 못합니다. 오히려 이를 숨길 뿐입니다.

이는 "AI 기반 BI"를 위한 진정한 인프라 투자가 더 나은 모델이나 더 세련된 채팅 UI가 아니라는 것을 의미합니다. 그것은 모든 메트릭 정의를 명시적이고, 버전 관리(versioned)가 가능하며, 기계가 읽을 수 있는(machine-readable) 형태로 만들기 위한, 화려하지는 않지만 매우 필수적인 추진력입니다. 이는 운영 환경(production)에 배포되는 설정 파일(config file)에 기대하는 것과 동일한 엄격함이어야 합니다. 왜냐하면 이제 그것이 바로 설정 파일이기 때문입니다.

메트릭 정의를 API 계약(API Contract)처럼 취급하세요

에이전트가 여러분의 메트릭을 대상으로 쿼리를 생성해야 한다면, 해당 메트릭은 모든 안정적인 API가 필요로 하는 속성을 갖추어야 합니다:

• 메트릭당 **단일한 정형 정의 (A single canonical definition)**가 필요합니다. 다섯 개의 대시보드 아래에서 약간씩 다른 이름으로 중복된 로직이 존재해서는 안 됩니다.

• **버전 관리 (Versioning)**가 필요합니다. 재무팀이 "이탈 고객 (churned customer)"의 정의를 재정의했을 때, 과거의 보고서들이 새로운 규칙에 따라 과거 데이터를 조용히 재계산하기 시작하는 일을 방지해야 합니다.

• 드리프트 (drift)를 포착하는 **테스트 (Tests)**가 필요합니다. 이는 여러분이 이미 dbt 모델에서 실행하고 있는 어설션 테스트 (assertion testing)와 같은 종류로, 메트릭 출력이 고정된 데이터셋의 검증된 값과 일치하는지 확인하도록 확장된 형태여야 합니다.

• **소유권 (Ownership)**이 필요합니다. 즉, 특정 팀이 프로덕션 API의 스키마 (schema)를 소유하는 것과 마찬가지로, 특정 메트릭이 무엇을 의미하는지에 대해 책임을 지는 팀이 있어야 합니다.

이 중 그 어떤 것도 분석 엔지니어링 (analytics engineering) 분야에서 새로운 조언은 아닙니다. 새로운 점은 이를 건너뛰었을 때 발생하는 비용입니다. 에이전트가 등장하기 전에는 잘못된 메트릭 정의가 하나의 잘못된 대시보드를 만들어냈고, 이는 날카로운 분석가가 검토 과정에서 잡아낼 수 있었습니다. 하지만 이제 잘못된 메트릭 정의는 누군가가 채팅 인터페이스에 던지는 모든 즉석 질문 (ad hoc question)에 걸쳐, 중간 검토 단계 없이 영원히 복제됩니다. 소유되지 않은 메트릭의 폭발 반경 (blast radius)이 단 하나의 보고서에서 무제한의 보고서로 확장된 것입니다.

에이전트는 구문에는 능숙하지만, 판단력은 부족합니다

이 시스템들이 실제로 무엇을 잘하고 있는지 정확하게 짚고 넘어갈 가치가 있습니다. 텍스트-투-SQL (Text-to-SQL) 생성은, 가공되지 않은 테이블 조사 (raw table introspection)가 아니라 실제 시맨틱 레이어 (semantic layer)에 기반한다면 이제 진정으로 강력해졌습니다. 깨끗한 메트릭 정의와 명확한 질문이 주어진다면, 에이전트는 금요일 오후의 중간급 분석가보다 더 신뢰성 있게 정확하고 효율적인 SQL을 작성할 것입니다.

하지만 에이전트가 할 수 없는 것은 어떤 질문에 어떤 메트릭이 적절한지에 대한 판단을 내리는 것입니다. 왜냐하면 그 판단은 데이터가 아니라, 사람들의 머릿속과 슬랙 (Slack) 스레드에 존재하는 컨텍스트 (context)였기 때문입니다. "이 보고서에 총매출 (gross revenue)을 사용할 것인가, 순매출 (net revenue)을 사용할 것인가"는 SQL 문제가 아닙니다. 이는 쿼리가 생성되기 전에 해결되고 코드화되어야 하는 비즈니스 문제이지, 모델이 쿼리 시점에 추론해야 하는 문제가 아닙니다.

이는 업계가 구조화된 출력 (Structured Output) 및 RAG (검색 증강 생성)를 통해 반복적으로 학습해 온 것과 동일한 교훈입니다. 모델에게 올바른 형태의 출력이나 올바른 근거 문서 (Grounding Documents)를 제공한다고 해서 자동으로 올바른 의미를 갖게 되는 것은 아닙니다. 구문 (Syntax)과 검색 (Retrieval)은 이미 해결된 문제입니다. 의미론 (Semantics)은 영원히 지속되는, 화려하지 않은 작업이며, 이는 자동화되어 사라지는 것이 아니라 오히려 그 실체가 드러날 뿐입니다.

분석 엔지니어 (Analytics Engineers)가 다음에 실제로 구축해야 할 것

실질적인 시사점은 우선순위의 재조정입니다. 이제 또 다른 대시보드를 만드는 것은, 사람이 만들든 에이전트가 생성하든 모든 미래의 대시보드가 참조하게 될 메트릭 레이어 (Metric Layer)를 감사하고 통합하는 것보다 레버리지(Leverage)가 낮습니다. 구체적으로는 다음과 같습니다:

• 핵심 메트릭이 정의된 모든 곳을 인벤토리화하여 한 곳으로 통합하고, 에이전트가 직면하는 시맨틱 레이어 (Semantic Layer)만을 유일한 허용 소스로 만드세요.

• 메트릭에 대한 회귀 테스트 (Regression Tests)를 작성할 때, 차트를 눈으로 훑어보는 방식이 아니라 결제 계산을 테스트하는 방식처럼 작성하세요.

• 메트릭 레이어에 대해 에이전트가 생성한 모든 쿼리를 로그로 남기고, 모호하거나 최근에 정의가 변경된 부분을 건드리는 쿼리들을 검토하세요.

• 인터페이스에서 모호함 해소 (Disambiguation)를 명시적으로 만드세요. 만약 "매출 (Revenue)"이 두 가지 유효한 의미를 가진다면, 에이전트는 추측하는 것이 아니라 질문해야 합니다.

이 중 그 어떤 것도 흥미로운 작업은 아닙니다. 멋진 데모가 될 수도 없습니다. 하지만 이는 분석 팀의 속도를 높여주는 에이전트와, 누군가 알아차리기 세 번의 클릭 전부터 틀려 있었던 숫자들에 맞서 분석 팀을 최후의 방어선으로 만드는 에이전트 사이의 차이를 만듭니다. 채팅창이 분석 엔지니어링의 규율에 대한 필요성을 없앤 것이 아닙니다. 단지 실패 모드 (Failure Mode)를 "잘못된 대시보드"에서 "신뢰하는 사람에게, 대규모로, 완전한 확신을 가지고 전달되는 잘못된 답변"으로 옮겼을 뿐입니다.