Skip to main content
원문: Using AI Functions in Your Data Warehouse: Top Use Cases 저자: Srikant Das, Ismail Makhlouf 게시일: 2026년 8월 14일

요약

  • AI Functions는 데이터를 별도의 AI 환경으로 옮기지 않고, 표준 SQL 쿼리 안에서 모델을 직접 호출해 AI를 데이터 곁으로 가져옵니다.
  • Unity Catalog 거버넌스, SQL 네이티브 단순함, 통합 과금, 작업별 특화 함수라는 이점을 기본으로 제공합니다.
  • 이 글은 문서 인텔리전스, 감성 분석, 다국어 번역, 분류·라우팅, 영업 통화 추출, 생성형 초안 작성이라는 6가지 사용 사례와 프로덕션 팁을 다룹니다.

대부분의 조직에서 데이터 웨어하우스에는 정형 데이터가, 데이터 레이크에는 비정형 데이터가 보관됩니다. 이 방식은 정형 데이터를 대규모로 소비하며 매일 정해진 리포트를 서빙하는 분석 워크로드에는 잘 맞습니다. 그러나 AI 워크로드에는 다른 입력이 필요합니다. AI 모델은 리뷰, 지원 티켓, PDF 같은 비정형 데이터를 파싱하고, 이를 정형 데이터와 결합해 모델을 학습·구축·서빙해야 하는 경우가 많습니다. 그래서 지원 티켓의 감성을 얻고자 하는 분석가는 행(row)을 외부 서비스로 내보내고, 예측을 기다린 뒤, 그 결과를 다시 손으로 테이블에 이어 붙여야 합니다. 느리고, 스키마가 바뀌면 깨지며, 불필요한 보안·거버넌스 리스크를 들여옵니다. AI Functions는 데이터를 별도의 AI 환경으로 옮기는 대신 AI를 데이터 곁으로 가져와 이 문제를 해결합니다. 표준 SQL 쿼리 안에서 모델을 호출하므로, 추론 과정 전체가 기존 파이프라인과 Unity Catalog 거버넌스 안에 머무릅니다. 이 아키텍처는 데이터 웨어하우스에서 AI를 다루는 방식을 근본적으로 바꿉니다.
  • 거버넌스는 기본: AI FunctionsUnity Catalog 권한을 준수하므로 데이터가 안전하고 비공개로 유지됩니다. 모델은 여러분이 명시적으로 허용한 데이터에만 접근합니다.
  • SQL 네이티브 단순함: SELECT 문을 쓸 수 있다면 AI로 무언가를 만들 수 있습니다. 계획 수립, 병렬화, 재시도 같은 복잡성은 Databricks가 관리하므로 클러스터 관리나 외부 오케스트레이션을 걱정할 필요가 없습니다. 수백만 행에 추론을 돌리는 것도 한 행에 돌리는 것만큼 쉽고, 같은 쿼리가 다시 쓸 필요 없이 그대로 확장됩니다.
  • 통합 과금: 서로 다른 대시보드를 대조하는 복잡함을 없앱니다. AI 사용량은 표준 Databricks SQL 웨어하우스 비용과 나란히 system.billing.usage에 드러납니다.
  • 특화 함수: 더 적은 비용으로 더 나은 결과를 얻습니다. ai_classify, ai_extract, ai_translate, ai_parse_document 같은 작업별 특화 함수를 사용하면, 범용 추론에 과도하게 비용을 치르는 대신 특정 작업에 맞춰진 모델을 활용할 수 있습니다.
AI Functions로 정형 데이터와 비정형 데이터를 결합하는 구조 이 AI 함수들은 노트북, Lakeflow Spark Declarative Pipelines, Workflow 등 Databricks 어디에서나 사용할 수 있습니다. 다만 이 글에서는 Databricks Lakehouse에서 이 함수들을 호출하는 데 초점을 맞춥니다. 아래 사용 사례들은, 데이터 웨어하우스의 정형 데이터를 (웨어하우스 밖에서 가져오든 여러분이 직접 GenAI 함수로 생성하든) 비정형 데이터와 결합해야 하는 워크로드에 이 AI 함수들을 어떻게 녹여 넣을 수 있는지 보여 줍니다.

사용 사례 1: 문서 인텔리전스 — 원시 파일에서 정형 행으로

ai_parse_document는 PDF나 이미지 같은 원시 바이너리 파일 내용을 읽을 수 있는 텍스트로 변환하는 수집 다리 역할을 합니다. 파싱된 뒤에는 ai_extract가 특정 키와 값을 세밀하게 추출합니다. 이 결합 접근법은 스키마 변경 때마다 깨지곤 하는 취약한 커스텀 OCR 파이프라인이나 서드파티 파싱 서비스를 필요 없게 만듭니다. 이 사용 사례에서는 인보이스가 담긴 Databricks 볼륨을 ai_parse_document로 가리킵니다. 인보이스가 파싱되면 ai_parse_document는 결과를 JSON으로 만들어 내고, 이 결과는 다시 ai_extract 함수로 전달됩니다. 여기서 우리는 인보이스에서 어떤 엔터티를 추출할지 정의합니다. 그 결과는 인보이스에서 원하는 필드가 추출된 정형 테이블입니다. 이제 리니지(lineage)가 원시 PDF에서 추출된 행까지 하나의 쿼리 플랜 안에서 이어집니다. 사람들이 이를 위해 손으로 만들던 다리 — Python OCR 서비스, LLM 호출, JSON 평탄화 단계 — 가 모두 쿼리 하나로 접힙니다. 데모 노트북: 문서 인텔리전스

사용 사례 2: 고객 피드백 감성 분석

ai_classify 함수는 제로샷(zero-shot) 분류를 수행해, 모델 학습 없이도 자유 텍스트 피드백을 사용자가 정의한 특정 레이블 집합으로 매핑합니다. 이 과정은 혼란스러운 비정형 텍스트를 거버넌스되고 쿼리 가능한 컬럼으로 바꿔, 감성과 토픽 데이터를 BI 대시보드와 경영 리포트에서 즉시 활용할 수 있게 만듭니다. 이 예시에서는 bronze.nps_responses 테이블의 고객 리뷰를 positive, negative, neutral, mixed로 분류하려 합니다. 데모 노트북: 감성 분석

사용 사례 3: 다국어 데이터의 인라인 번역

ai_translate를 사용하면 다국어 데이터를 쿼리 계층 안에서 곧바로 하나의 대상 언어로 정규화할 수 있습니다. 이는 데이터 사일로와 파편화를 막아, 모든 다운스트림 분석(분류와 추출 포함)이 영어 데이터만 처리하는 것이 아니라 전 세계 데이터셋 전체를 동시에 다룰 수 있게 합니다. 이 예시에서는 서로 다른 고객 리뷰에서 감성을 추출한 뒤, 이를 영어로 번역합니다. 데모 노트북: 번역과 정규화

사용 사례 4: 대규모 분류와 라우팅

운영 효율에 초점을 맞춘 ai_classify는 지원 티켓이나 통화 녹취 같은 자유 형식 입력을 실행 가능한 범주로 변환합니다. 수집 시점에 들어오는 피드백의 의도와 긴급도를 파악함으로써, 적절한 팀이나 자동 응답 시스템으로의 자동·지능형 라우팅을 가능하게 합니다. 아래 사용 사례에서는 테이블에서 서로 다른 지원 티켓을 수집한 뒤, ai_classify로 티켓의 사용자 의도와 긴급도를 판단합니다. 데모 노트북: 분류와 라우팅

사용 사례 5: ai_extract로 영업 통화 정형 추출

ai_extract 함수는 영업 통화 녹취 같은 긴 형식의 콘텐츠에서 반정형 정보를 캐내어, 서사형 텍스트를 개별적이고 정형화된 필드로 변환하도록 설계되었습니다. 이는 정성적 정보를 BI 도구에 곧바로 넣어, 대화 내용을 딜 단계(deal stage)나 리스크 플래그(risk flag) 같은 쿼리 가능한 지표로 바꿔 주는 큰 가치를 제공합니다. 이 사용 사례에서는 긴 녹취를 캐내어 다음 단계(next step), 딜 단계, 리스크 플래그, 리스크 사유(risk reason)를 식별합니다. 그러면 영업 담당자는 그 미팅에서 나온 녹취의 결과를 바탕으로 실제 행동을 취할 수 있습니다. 데모 노트북: 영업 통화 추출

사용 사례 6: ai_query로 생성형 초안 작성

ai_query는 가장 범용적인 함수이자 나머지 함수들의 토대입니다. 접근 권한이 있는 어떤 Databricks 호스팅 Foundation Model 서빙 엔드포인트로든 프롬프트를 보낼 수 있고, 각 행에 대해 모델의 답변을 돌려줍니다. 이 사용 사례에서는, 어떤 계정이 갱신(renewal) 준비가 되었는지 보여 주는 가상의 gold.renewal_signals 테이블의 모든 고객 계정에 대해 ai_query로 갱신 아웃리치 이메일 초안을 작성할 수 있습니다. 프롬프트를 직접 작성하므로 모델이 할 수 있는 무엇이든 수행할 수 있고, 그렇기에 더 구체적인 함수들이 다루지 못하는 경우까지 처리합니다. 데모 노트북: 생성형 초안 작성

프로덕션을 위한 프로 팁

  • 첫날부터 잡(job)에 태그 달기: AI Functions의 비용을 올바른 잡에 귀속시킬 수 있습니다.
  • 작업별 특화 함수를 먼저 시도하기: ai_classify, ai_extract, ai_parse_document, ai_translate 중 어느 것도 맞지 않을 때만 ai_query를 사용하세요.
  • 정형 출력 요청하기: ai_query에서는 정형 출력을 위해 responseFormat을 사용하세요. DDL STRUCT 스키마를 넘기면 원시 문자열 대신 타입이 지정된 필드를 얻습니다. JSON-schema/json_object 포맷은 여전히 JSON 문자열을 반환합니다.
  • 모델 선택에 의도를 담기: 모든 Foundation Model은 비용, 성능, 지원 입력 포맷 등에서 트레이드오프가 있습니다. 어떤 사용 사례에 어떤 모델을 선택할지 의도적으로 정하세요.
  • 확장 전에 샘플링하기: 최소 10,000행을 먼저 돌려 출력을 읽어 본 뒤 나머지를 돌리세요. 비용-정확도 트레이드오프는 사용 사례마다 다릅니다.
  • 프롬프트를 코드처럼 다루기: 버전 관리하고, 풀 리퀘스트에서 리뷰하고, 주석을 다세요. 이 워크플로에서 프롬프트는 비즈니스 로직이 담긴 하나의 변환입니다.

이것이 데이터 웨어하우스 전략에 갖는 의미

여섯 가지 사용 사례를 관통하는 실마리는 하나입니다. AI가 웨어하우스의 나머지와 같은 곳에서 실행된다는 것 — 하나의 플랫폼, 하나의 거버넌스 모델, 하나의 청구서, 하나의 파이프라인 집합입니다. 기존 SQL ETL의 어떤 줄이든, 이를 호스팅할 시스템을 따로 세울 필요 없이 AI 단계를 곧바로 집어넣을 수 있습니다. 그리고 곁에서 데이터를 번역·스코어링·분류하던 각 Python 스크립트는 한 줄짜리 대체 대상이 됩니다. 그러니 컬럼 하나로 시작하세요. 지금 쓰는 서비스가 가장 취약한 워크로드를 골라 SELECT로 다시 쓰고, 10,000행에 돌려 보고, 돌아오는 결과를 읽어 보세요. 짧은 스프린트 한 번이면 그것이 맞는지 알게 될 것이고, 데이터를 밖으로 실어 보내 쓰기 위해 치르던 추가 오버헤드도 멈추게 될 것입니다.

데모 노트북

각 노트북에는 인라인 샘플 데이터, 단계별 SQL, 그리고 기대되는 출력이 함께 들어 있습니다.

함께 읽기