요약 (TL;DR) — 원시 데이터 웨어하우스 스키마(Schema)를 대상으로 SQL을 더 잘 작성하도록 LLM을 개선하는 데 수년간의 노력이 투입되었지만, 이는 문제의 잘못된 계층을 해결하고 있는 것입니다. 고객, 이탈 이벤트(Churn event), 또는 순매출(Net revenue)이 실제로 무엇을 의미하는지와 같은 비즈니스 로직(Business logic)은 스키마가 아닌 시맨틱 레이어(Semantic layer)에 존재하며, 아무리 많은 프롬프트 엔지니어링(Prompt engineering)을 수행하더라도 컬럼 이름(Column names)만으로는 이를 복구할 수 없습니다. 현재 진행 중인 진정한 변화는 dbt 메트릭(Metrics)과 시맨틱 레이어를 단순한 BI 편의 도구가 아닌, 에이전트(Agents)를 위한 도구 계약(Tool contract)으로 취급하는 것이며, 이는 또한 이들을 거버넌스(Governance)와 가드레일(Guardrails)을 배치하기 위한 자연스러운 장소로 만듭니다.

모든 Text-to-SQL 데모는 똑같아 보입니다. 누군가 평이한 영어 질문을 입력하면, 모델이 쿼리(Query)를 내뱉고, 쿼리가 실행되면 모두가 박수를 칩니다. 하지만 실제 운영 환경에서 400개의 테이블, '활성 사용자(Active user)'에 대한 4가지 정의, 그리고 실제로는 매출까지 4개의 조인(Join) 경로를 가진 서서히 변하는 차원(Slowly-changing dimension)인 customers 테이블이 존재하는 데이터 웨어하우스에 적용되는 순간, 데모는 실패합니다. 모델이 SQL을 작성하는 능력이 떨어졌기 때문이 아닙니다. SQL은 결코 어려운 부분이 아니었기 때문입니다.

어려운 부분은 비즈니스 로직(Business logic)이며, 비즈니스 로직은 스키마(Schema)에 존재하지 않습니다. 그것은 누군가의 머릿속, 18개월 전의 Slack 스레드, 3단계 깊이로 파묻힌 dbt 모델, 또는 아무도 작성했다는 사실을 기억하지 못하는 스프레드시트 매크로(Spreadsheet macro) 속에 존재합니다. 컬럼 이름(Column names)과 외래 키(Foreign keys)를 응시하는 LLM은 추론(Reasoning)을 하는 것이 아니라 고고학(Archaeology)을 하고 있는 것입니다. 모델은 orders.status에 아마도 'completed'와 같은 값이 있을 것이라고 추론할 수는 있지만, 재무팀은 환불된 주문을 매출에서 제외하는 반면 마케팅팀은 이를 포함한다는 사실이나, '활성(Active)'의 의미가 한 팀에게는 지난 28일 동안 로그인한 것을 의미하고 다른 팀에게는 지난 90일 동안 구매를 한 것을 의미한다는 사실은 추론할 수 없습니다. 이것들은 스키마 사실(Schema facts)이 아닙니다. 이것들은 시맨틱 레이어 사실(Semantic layer facts)이며, 모델이 읽을 수 있는 어딘가에 기록되어 있지 않다면 모델은 자신 있게 이를 지어낼 것입니다.

업계가 잘못된 해결책에 걸었던 도박

한동안 제시된 해결책은 다음과 같았습니다: 더 나은 모델, 더 큰 컨텍스트 윈도우 (context windows), 쿼리 이력에 대한 미세 조정 (fine-tuning), 과거 쿼리에 대한 검색 (retrieval) 단계 추가. 이 모든 것들은 미미한 수준에서 도움을 줍니다. 하지만 그 중 어느 것도 실제 간극을 해결하지는 못하는데, 그 이유는 그 간극이 언어적인 것이 아니라 정의적인 (definitional) 것이기 때문입니다. 모델에게 완벽한 구문 (syntax)과 조인 (joins)에 대한 결점 없는 이해력을 제공하더라도, net_revenue는 세금 적용 전 할인을 차감하고 gross_revenue는 그렇지 않다는 사실을 모델이 모른다면 여전히 숫자를 틀리게 계산할 것입니다. 이러한 차이는 해당 지표 (metric)를 소유한 사람들이 단 한 번, 이상적으로는 한 곳에 기록해 둔 비즈니스 결정입니다. 언어 모델에게 매번 원시 테이블 (raw tables)로부터 이를 역공학 (reverse-engineer) 하라고 요구하는 것은, 이미 지표 레이어 (metrics layer)가 중복 작업을 피하기 위해 존재함에도 불구하고 모델에게 그 작업을 다시 하라고 요구하는 것과 같습니다.

데이터 측면이 아닌 모델 측면에서 AI 엔지니어링에 입문했다면 놓치기 쉬운 부분이 바로 이것입니다. 현대적 데이터 스택 (modern data stack)은 LLM이 답변을 필요로 하기 훨씬 전부터 이미 "이 숫자가 무엇을 의미하는가"라는 문제를 해결해 왔습니다. dbt의 지표 정의 (metrics definitions)와 데이터 웨어하우스 (warehouse) 상에 구축된 시맨틱 레이어 (semantic layers)는 대시보드, 분석가, 예약된 보고서와 같은 모든 소비자에게 "이탈률 (churn)이 무엇인가"라는 질문에 대해 매번 다시 유도할 필요 없이 동일한 답변을 제공하기 위해 정확히 존재합니다. 웨어하우스에 질문을 던지는 에이전트 (agent) 또한 하나의 소비자일 뿐입니다. 에이전트 역시 동일한 보장을 받아야 합니다.

시맨틱 레이어를 올바르게 이해했을 때의 실체

시맨틱 레이어 (Semantic Layer)를 보고용 편의 도구가 아닌 API로 재정의하면, 많은 것들이 제자리를 찾게 됩니다. 잘 구축된 시맨틱 레이어는 고정되고 버전이 관리되는 정의를 가진 명명된 지표 (metrics) 및 차원 (dimensions)을 노출합니다: revenue (매출), active_users (활성 사용자), churn_rate (이탈률) 등이며, 각 항목에는 해당 수치를 실제로 관리하는 담당자에 의해 명시적인 필터 (filter), 입도 (grain), 조인 경로 (join path)가 내장되어 있습니다. 에이전트 (agent)가 소스 테이블 (source tables)에 대해 직접 원시 SQL (raw SQL)을 작성하는 대신 해당 레이어를 통해 쿼리할 때, 에이전트는 더 이상 비즈니스 로직을 추측하지 않습니다. 대신 안정적인 계약 (contract)을 가진 함수를 호출하는 것입니다. LLM의 역할은 자신이 실제로 잘하는 영역으로 축소됩니다: 즉, 모호한 자연어 질문을 가장 유사한 지표 및 차원 집합에 매핑하고, 두 명명된 지표 사이에 진정한 모호함이 있을 때 명확히 하기 위한 질문을 던지는 것입니다.

이는 원시 스키마 (raw schema)를 대상으로 하는 Text-to-SQL보다 범주적으로 훨씬 쉬운 문제이며, 구체적이고 구조적인 방식으로 더 쉽습니다. 즉, 정답의 공간이 무한하고 구문적인 (syntactic) 형태가 아니라, 유한하고 명명된 형태이기 때문입니다. 모델이 metric: net_revenue (순매출)와 metric: gross_revenue (총매출) 사이에서 선택하는 것은 의도 분류 (intent classification)를 수행하는 것입니다. 반면, 올려진 삭제 행 플래그 (soft-deleted-rows flag)에 대한 올바른 필터와 정확한 COALESCE를 사용하여 6개의 테이블을 조인하는 코드를 작성하는 것은, 실행해 보고 숫자가 그럴듯해 보이기를 바라는 것 외에는 스스로의 작업을 확인할 방법이 없는 상태에서 불확실성 하의 프로그램 합성 (program synthesis)에 훨씬 가까운 작업을 수행하는 것입니다.

거버넌스 (Governance)는 이 과정에서 자연스럽게 따라옵니다

두 번째로 덜 명확하지만, 에이전트(Agent)가 프로덕션(Production) 환경에 가까워질수록 더 중요해지는 이점이 있습니다. 시맨틱 레이어(Semantic Layer)가 인터페이스가 되면, 그곳은 가드레일(Guardrails)을 배치하기 위한 자연스러운 장소가 됩니다. 왜냐하면 시맨틱 레이어는 데이터 모델(Data Model)과 그에 부착된 비즈니스 의미(Business Meaning)를 모두 이미 이해하고 있는 유일한 레이어이기 때문입니다. 행 수준 보안(Row-level security), 메트릭 수준의 액세스 제어(Metric-level access control), 재무 및 감사 목적으로 고정된 정의(Definitions) — 이 모든 것들은 이미 인간 BI 사용자를 위해 구축된 성숙한 시맨틱 레이어 도구들에 존재합니다. 에이전트를 동일한 레이어를 통해 라우팅(Route)하면, 에이전트는 별도의 설정 없이도 동일한 경계(Boundary)를 상속받습니다. 에이전트는 허용되지 않은 메트릭을 쿼리할 수 없습니다. 왜냐하면 권한이 모델의 프롬프트 지시사항(Prompt instruction)이 아닌, 모델보다 하위 단계에 존재하기 때문입니다. 프롬프트 지시사항은 적대적 압박(Adversarial pressure) 하에서 무시될 수 있지만, 하위 레이어의 권한은 그렇지 않습니다. 이를 데이터 웨어하우스(Warehouse)에 대한 로우 SQL(Raw SQL) 액세스 권한을 가진 에이전트와 비교해 보십시오. 그런 에이전트가 제한된 테이블에 조인(Join)하는 것을 막을 수 있는 유일한 수단은 하지 말라고 지시하는 시스템 프롬프트(System prompt)뿐입니다. 그것은 보안 경계가 아닙니다. 그것은 단지 제안일 뿐입니다.

이것이 바로 "에이전트에게 그냥 읽기 전용(Read-only) SQL 연결을 주면 된다"는 생각이 들리는 것보다 더 나쁜 아이디어인 이유입니다. 읽기 전용은 파괴적인 쓰기(Destructive writes)를 막아주지만, 에이전트가 절반만 이해한 조인(Join)을 바탕으로 계산해서는 안 될 숫자를 도출하고, 이를 이사회 보고서(Board deck)에 넣을 사람에게 매우 자신감 있게 제시하는 상황에 대해서는 아무런 조치도 취하지 못합니다. 여기서의 실패 모드(Failure mode)는 테이블이 삭제되는 것이 아닙니다. 그것은 마치 정답처럼 보이는 틀린 숫자입니다.

단순히 사용하는 것이 아니라 스택(Stack)을 구축하고 있다면 의미하는 바

만약 당신이 데이터 플랫폼을 소유하고 있고, "데이터 웨어하우스(Warehouse)가 LLM과 대화할 수 있게 만들어라"라는 요청을 받고 있다면, SQL 생성 모델을 데이터 웨어하우스에 직접 결합하려는 본능은 저항하려는 본능과 같습니다. 더 높은 레버리지(Leverage)를 가진 움직임은 시맨틱 레이어(Semantic Layer) 자체에 투자하는 것입니다. 즉, 중요한 지표(Metrics)의 이름을 붙이고, 현재 누군가의 머릿속에만 존재하는 정의들을 문서화하며, 하단의 가공되지 않은 테이블(Raw tables) 대신 그 레이어를 에이전트(Agent)를 위한 도구 인터페이스(Tool surface)로 노출하는 것입니다. 이러한 작업은 인간을 위해서도 가치가 있습니다. 에이전트가 안전하게 사용할 수 있을 정도로 충분히 훌륭한 시맨틱 레이어는, 분석가들이 "지난 분기 매출이 얼마였나"라는 질문에 대해 세 개의 서로 다른 대시보드에서 세 개의 서로 다른 답변을 얻는 상황을 방지할 수 있으며, 이것이 바로 시맨틱 레이어를 구축하는 실제 목적이었습니다.

이를 제대로 수행하는 팀은 가장 화려한 Text-to-SQL 모델을 보유하지는 않을 것입니다. 대신 그들은 가장 정직한 지표 레이어(Metrics layer)를 보유할 것이며, 이미 정확하게 답변하는 방법을 알고 있는 질문만을 던지도록 허용된 에이전트를 보유하게 될 것입니다. 이는 "우리 에이전트는 자연어로 어떤 테이블이든 쿼리할 수 있습니다"라는 주장보다 규모가 작고 덜 인상적으로 들릴 수 있습니다. 하지만 이는 실제 이사회 회의라는 실전 상황에서도 살아남을 수 있는 방식입니다.