LLM으로 SQL을 직접 작성하려는 시도는 2022년부터 꾸준히 이어졌습니다. 보통 DB Schema를 프롬프트에 통째로 넘겨 질문에 맞는 SQL을 추출하는 등 다양한 패턴을 사용합니다.

실제 실무 시나리오를 분석하면 정해진 패턴을 반복하는 경우가 많습니다. 가장 세밀한 granularity를 가진 fact 테이블을 두고 그 위에서 Semantic Layer 로 연산을 조립하면 훨씬 안정적이고 유연하게 운용할 수 있습니다.

사용자가 “최근 7일 동안 특정 광고그룹에서 비용이 높은 키워드의 CPA와 ROAS를 보여줘"라고 입력했을 때 LLM은 SQL을 직접 작성하지 않습니다. 대신 질문을 해석해 Dimension, Metric, Filter, Order, Comparison 이라는 다섯 가지 의미 요소로 명확하게 분해합니다.

LLM은 분해한 의미 요소를 정해진 Tool Call 인자 형식으로 추출합니다.

{
  "days": 7,
  "dimensions": ["keyword_id", "keyword_name"],
  "metrics": ["cost", "conversions", "cpa", "roas"],
  "filters": [
    {
      "field": "adgroup_name",
      "operator": "contains",
      "value": "특정 광고그룹"
    }
  ],
  "order_by": {
    "field": "cost",
    "direction": "desc"
  }
}

이 인자를 전달받은 내부 Tool이 Python 코드나 쿼리 빌더로 SQL을 조립하여 간단하게 실행합니다.

정확도 100%의 SQL 조립과 자율성의 균형

Semantic Layer 를 거쳐 조립된 SQL은 구문 오류 없이 100% 정확하게 작동합니다. LLM의 역할이 사라진 것이 아니라 작동하는 지점이 옮겨간 셈입니다. 쿼리문 문법을 고민하는 대신 데이터의 의미 구조를 조립하는 작업에 집중하므로 훨씬 안정적입니다.

엔지니어링 자산으로 되살아나는 데이터 모델링

데이터 엔지니어가 구축해 온 파이프라인 관리 노하우는 에이전트 시대에 다시 핵심 역할을 맡습니다. AI 도입으로 기존 전문성이 사라지는 대신 Human Layer 가 설계한 시맨틱 구조가 안전장치로 작동하며, 오랫동안 쌓아온 데이터레이크 설계 경험도 그대로 유용하게 활용됩니다.

정교한 Semantic Layer 하나만 갖춰도 에이전트는 충분히 다양하고 정확한 분석을 수행합니다. 데이터 스키마를 직접 보여주기보다 조립 도구를 쥐어주는 편이 훨씬 유연합니다.

요약

  • DB Schema 전체를 LLM에 전달해 SQL을 만들어내는 방식보다, 정교한 fact 테이블 위에 Semantic Layer를 올리는 구조가 안정적입니다.
  • LLM은 SQL 문법을 작성하는 대신 Dimension, Metric, Filter, Order, Comparison 인자를 추출하여 Tool Call 형태로 전달합니다.
  • 엔지니어가 사전에 정의한 Semantic Layer 덕분에 조립된 SQL은 구문 오류 없이 100% 실행 정확도를 보장받습니다.