질문에만 답하던 AI가 분석계획을 세우기 시작했다..
“최근 매출이 왜 줄었을까요?”
이런 질문을 받았다고 해보겠습니다.
먼저 매출이 감소한 시점을 확인할 겁니다.
그다음 국가와 플랫폼, 상품, 고객집단으로 나눠 어디에서 감소 폭이 컸는지 살펴보겠죠.
구매자 수가 줄었는지, 고객당 결제금액이 낮아졌는지에 따라서도 이후 분석은 달라집니다.
구매자 수가 줄었다면 신규 유입과 재방문을 봐야 합니다.
고객 수는 비슷한데 결제금액이 낮아졌다면 구매 빈도나 객단가를 확인해야 하고요.
특정 플랫폼에서만 매출이 감소했다면 업데이트와 오류, 결제 실패 같은 운영 이슈도 함께 봐야 합니다.
데이터 분석은 보통 이런 식으로 이어집니다.
하나의 질문에 답하고 끝나는 게 아니라, 앞에서 확인한 결과를 바탕으로 다음 질문을 만듭니다. 처음부터 정답으로 향하는 길을 알고 있는 경우는 많지 않습니다. 데이터를 보면서 가능성이 낮은 가설은 덜어내고, 새로 발견한 변화는 다시 쪼개 봅니다.
지금까지는 분석가가 이 순서를 만들었습니다.
그런데 이제 AI가
다음에 무엇을 볼지 정하는 단계까지 들어오기 시작했습니다.
Databricks는 2026년 9월 2일 모든 Genie Agents에 Agent mode를 적용했다고 발표했습니다.
이전처럼 사용자의 질문을 하나의 SQL로 바꿔 결과를 보여주는 데서 멈추지 않고 Agent mode는 먼저 분석계획을 세우고, 여러 쿼리를 반복해서 실행합니다. 중간 결과를 확인하면서 계획을 수정한 뒤 차트와 근거, 출처가 포함된 보고서를 만듭니다.
예전의 질문이 이랬다면,
“지난달 지역별 매출을 보여주세요.”
Agent mode에 맡길 수 있는 질문은 조금 더 열려 있습니다.
“최근 매출이 감소한 원인을 찾아주세요.”
지역별 매출을 한 번 집계하는 것과 매출 감소의 원인을 찾는 것은 다른 문제입니다.
후자의 질문에는 정해진 분석순서가 없습니다. 어느 지역에서 감소했는지 먼저 볼 수도 있고, 신규 고객과 기존 고객으로 나눠볼 수도 있습니다. 상품 판매량과 고객 수를 먼저 분해한 뒤 범위를 좁히는 접근도 가능합니다.
Agent mode는 이런 하위 질문을 스스로 구성합니다.
첫 번째 쿼리에서 발견한 결과에 따라 두 번째와 세 번째 쿼리가 달라집니다.
분석가가 한 단계씩 SQL을 작성하며 이어가던 탐색 과정의 일부가 AI 안으로 들어간 셈입니다.
Agent mode API도 함께 제공됩니다.
Databricks 화면을 열지 않아도 사내 챗봇, 정기 보고서, 분석 포털, 내부 업무도구와 대시보드에 다단계 분석기능을 연결할 수 있습니다. 대화를 이어가며 후속 질문을 하고, 분석 메시지와 시각화 결과도 API로 가져올 수 있습니다. 응답은 Server-Sent Events 방식으로 전달됩니다.
정해진 지표만 보여주던 자동 보고서에도 변화가 생길 수 있습니다.
매주 월요일 전주 매출을 보여주는 보고서가 있다고 해보겠습니다. 기존에는 매출이 감소해도 미리 설정한 표와 차트만 갱신됐습니다. 원인을 확인하려면 분석가가 데이터를 다시 열어봐야 했죠.
다단계 분석 에이전트가 연결되면 매출 감소를 발견한 뒤 감소가 집중된 국가와 상품군을 찾고, 구매자 수와 객단가를 나눠볼 수 있습니다. 특정 고객집단에서 변화가 컸다면 그 집단의 유입과 재방문, 구매 행동까지 이어서 확인합니다.
단순히 현황을 전달하던 보고서가
1차 원인 탐색까지 맡게 되는 겁니다.
기업에서 필요한 정보가 모두 테이블에 들어 있는 것은 아닙니다.
매출과 고객 수는 데이터베이스에서 찾을 수 있지만, 고객이 왜 떠났는지는 설문조사에 남아 있을 수 있습니다. 오류 발생 건수는 로그에 기록되지만 당시 상황과 대응 내용은 장애 보고서나 회의자료에 정리돼 있기도 합니다.
숫자는 무슨 일이 벌어졌는지 보여줍니다. 문서에는 그 일이 왜 벌어졌는지 추정할 단서가 남아 있습니다.
이번에 확장된 Genie Agents는 Unity Catalog Volume에 저장된 PDF, 문서, 슬라이드, 이미지도 테이블과 함께 분석합니다. 하나의 에이전트에는 최대 10개의 Volume을 연결할 수 있으며, 파일 접근에도 Unity Catalog 권한이 적용됩니다.
예를 들어 테이블에서 이탈 고객이 많은 지역을 찾았다고 해보겠습니다.
기존에는 분석가가 해당 지역의 고객 설문을 따로 찾아 읽어야 했습니다. 설문 내용을 불만 유형별로 분류하고, 정량분석에서 발견한 이탈 증가와 연결하는 과정도 직접 맡았고요.
그런데 이제는, 하나의 대화 안에서 이어갈 수 있습니다.
먼저 이탈이 집중된 지역을 찾고, 해당 지역 고객의 설문 문서를 읽어 반복해서 등장하는 불만을 추립니다. 이후 불만이 발생한 시점과 이탈 증가 시기를 비교해 다음에 확인할 가설을 제안할 수 있습니다.
여기까지만 보면 상당히 편리합니다.
다만 표의 수치와 문서의 의견이 한 보고서에 담겼다고 해서 원인이 확인된 것은 아닙니다.
특정 지역에서 이탈률이 높고 같은 지역의 설문에서 가격 불만이 많이 발견됐다고 해보겠습니다. 그렇다고 가격 때문에 고객이 떠났다고 바로 판단하기는 어렵습니다.
설문 응답자가 전체 이탈 고객을 대표하는지 봐야 합니다. 가격이 바뀐 시점과 이탈이 늘어난 시점도 비교해야 하고요. 가격 변화가 없었던 다른 지역에서는 어떤 일이 벌어졌는지도 확인해야 합니다.
표와 문서를 함께 읽으면 설명은 더 풍부해집니다. 동시에 서로 다른 성격의 자료를 어떤 근거로 연결했는지 검토할 부분도 늘어납니다.
이번 발표를 하나의 기능 추가로만 보면 흐름이 잘 보이지 않습니다.
앞서 Databricks는 Genie One과 Genie Ontology를 통해 사용자의 질문, 회사의 지표 정의, 업무 맥락을 연결하는 구조를 보여줬습니다.
Genie Ontology는 회사에서 사용하는 데이터와 지표가 무엇을 가리키는지 설명합니다.
같은 ‘매출’이라는 표현도 주문금액을 말하는지, 취소와 반품을 제외한 순매출을 말하는지 회사마다 다릅니다. 신규 고객을 가입 기준으로 볼지 첫 구매 기준으로 볼지도 정해야 하고요. 이런 정의가 정리되지 않으면 AI가 정확한 SQL을 작성하더라도 현업에서 사용하는 숫자와 다른 결과가 나올 수 있습니다.
Genie One은 사용자가 자연어로 데이터를 질문하고 답을 활용하는 접점에 가깝습니다. Databricks 공식 문서에서는 Genie Agents를 데이터팀이 신뢰할 수 있는 데이터와 지표, 업무 규칙을 설정하는 도메인별 환경으로 설명합니다.
이번 Agent mode는 그 위에서 실제 분석순서를 구성합니다.
회사의 매출 정의와 고객 구분 기준을 참고해 최초 질문을 여러 하위 질문으로 나누고, 쿼리 결과에 따라 다음 분석을 선택합니다. 지표를 이해하는 단계에서 멈추지 않고, 그 지표를 어떤 순서로 살펴볼지까지 AI가 관여하기 시작한 겁니다.
게임 업데이트 이후 매출이 감소한 상황을 생각해보겠습니다.
Agent mode는 먼저 업데이트 전후의 매출을 비교할 겁니다. 감소가 확인되면 국가와 플랫폼, 신규·기존 이용자, 결제 규모별로 나눠 어느 집단에서 변화가 컸는지 찾을 수 있습니다.
매출 감소가 특정 집단에 집중돼 있다면 해당 이용자의 행동을 이어서 봅니다.
업데이트 이후 접속일수가 줄었는지, 평균 재방문 간격이 길어졌는지 확인합니다. 플레이 시간과 콘텐츠 참여가 함께 감소했는지도 살펴보고요. 특정 콘텐츠에서 실패가 늘었거나 오류를 반복해서 경험하지는 않았는지 로그를 통해 범위를 좁힐 수 있습니다.
분석 흐름은 대략 이렇게 이어집니다.
① 전체 매출이 언제부터 감소했는지 확인합니다.
② 감소 폭이 큰 이용자 집단을 찾습니다.
③ 해당 집단의 접속과 플레이 행동이 어떻게 달라졌는지 봅니다.
④ 실패와 오류 로그에서 반복되는 문제 경험을 찾습니다.
⑤ 결제 빈도와 결제금액이 실제로 함께 줄었는지 다시 확인합니다.
⑥ 업데이트와 이벤트, 프로모션 기간을 비교해 다른 영향을 분리합니다.
여기서 AI가 오류 증가와 매출 감소의 동시 변화를 발견했다고 해보겠습니다.
보고서에는 오류가 주요 원인 후보로 들어갈 가능성이 큽니다.
하지만 같은 시기에 움직였다는 사실만으로 오류가 매출 감소를 만들었다고 단정할 수는 없습니다.
오류를 경험하지 않은 이용자의 매출도 줄었는지 확인해야 합니다. 특정 기기와 버전에서만 오류가 발생했는지, 오류가 나타나기 전부터 플레이 시간이 감소하고 있었는지도 봐야 하고요.
업데이트로 콘텐츠 난도가 높아져 이용자가 이탈했을 수도 있습니다. 보상 구조가 달라지면서 결제할 이유가 줄었을 가능성도 있습니다. 같은 기간에 프로모션이 종료됐다면 매출 감소의 일부는 자연스러운 기저효과일 수 있고요.
AI가 하나의 분석경로를 빠르게 만들어주는 것과
그 경로가 가능한 설명을 충분히 확인했다는 것은 다릅니다.
단일 질문에 답하는 AI라면 결과 수치가 맞는지 확인하는 데 검토가 집중됩니다.
그런데 다단계 분석 에이전트는 그보다 앞을 봐야 합니다.
처음 받은 질문을 어떤 하위 질문으로 나눴는가.
왜 그 집단부터 확인했는가.
각 단계에서 사용한 테이블과 문서, 기간과 필터는 무엇인가.
분석계획에 들어가지 않은 고객집단이나 변수는 없는가.
표의 수치와 문서의 의견을 어떤 기준으로 연결했는가.
상관관계를 원인으로 바꾸어 설명하지는 않았는가.
같은 데이터와 조건으로 사람이 결과를 다시 만들 수 있는가.
에이전트가 제안한 다음 분석이 실제 의사결정으로 이어지는가.
AI가 보여준 분석 결과와 차트는 화면에 남습니다.
반면 처음부터 분석계획에 포함되지 않은 변수는 결과에 나타나지 않습니다.
그래서 틀린 계산을 찾는 것만으로는 부족합니다. 무엇을 아예 확인하지 않았는지도 살펴봐야 합니다.
가령 신규 고객의 재구매율이 낮아진 원인을 찾으면서 유입 채널과 첫 구매 상품은 확인했지만, 쿠폰 유형을 분석계획에서 빠뜨렸을 수 있습니다. 보고서에 나온 수치는 모두 맞더라도 프로모션 혜택이 고객 행동에 미친 영향은 설명되지 않은 채 남습니다.
보고서가 정교해 보일수록 이 부분을 놓치기 쉽습니다.
Genie Code는 Genie Agents를 만들고 관리하는 과정에도 사용됩니다.
에이전트의 목적과 사용자가 물어볼 질문, 연결할 데이터 소스를 설명하면 초기 지침을 구성합니다. 운영을 시작한 뒤에는 틀린 답을 한 대화나 평가 결과를 분석해 지침, 예제 SQL, 지식 설정을 어떻게 고칠지 제안합니다.
사용자의 질문과 피드백을 모아 에이전트가 자주 놓치는 주제도 찾습니다. 다만 제안된 내용을 바로 적용하는 구조는 아닙니다. 작성자가 검토한 뒤 저장해야 합니다.
이 과정을 보면 분석 에이전트를 한 번 만들어두고 계속 쓰기는 어렵다는 점도 드러납니다.
어떤 질문에서 반복해서 잘못된 테이블을 선택하는지 봐야 합니다. 신규 고객과 신규 구매 고객을 혼동하지는 않는지, 월누적 지표를 일별로 더해버리지는 않는지, 특정 국가나 플랫폼을 자주 누락하지는 않는지도 확인해야 합니다.
에이전트가 틀린 답을 줄이는 데 그치지 않고,
어떤 범위에서 안정적으로 답할 수 있는지 계속 관리해야 합니다.
Genie Agents의 대화는 다른 구성원과 공유할 수 있습니다.
공유된 대화에는 이후 추가된 질문과 분석, 수정된 차트가 계속 반영됩니다. 여러 사람이 같은 분석을 이어갈 때는 편리합니다. 다만 의사결정 당시의 근거를 남겨야 하는 상황에서는 별도의 관리가 필요합니다.
월요일 회의에서 본 보고서와 금요일에 다시 연 보고서가 달라질 수 있기 때문입니다.
분석 이후 데이터가 갱신됐을 수도 있습니다. 누군가 후속 질문을 추가해 원인 후보가 달라졌을 수도 있고요. 차트의 필터나 기간이 수정됐다면 같은 링크를 열어도 당시 본 수치를 그대로 확인하기 어렵습니다.
중요한 의사결정에 사용했다면 분석 시각과 데이터 기준일, 적용한 필터, 지표 정의의 버전을 남겨야 합니다. 당시 사용한 보고서와 차트도 스냅숏으로 보관하는 편이 좋습니다.
대화를 계속 발전시키는 것과 특정 시점의 판단 근거를 보존하는 것은 따로 다뤄야 합니다.
AI가 분석계획을 세우고 SQL과 차트, 보고서까지 만든다면 분석가는 무엇을 하게 될까요.
직접 작성하는 쿼리는 줄어들 수 있습니다. 반복 집계와 비교에 쓰던 시간도 짧아질 가능성이 큽니다.
그 대신 다른 부분을 더 오래 보게 될 겁니다.
처음 들어온 질문이 실제 문제를 제대로 담고 있는지 다시 정리해야 합니다. AI가 나눈 하위 질문에 빠진 집단과 변수가 없는지 살펴봐야 하고요. 선택한 비교 기간과 분석 단위가 적절한지도 확인해야 합니다.
결과가 나왔다고 바로 해석하지 않고, 같은 현상을 설명할 다른 가능성을 찾아야 합니다.
마지막에는 분석 결과로 회사가 무엇을 바꿀 수 있는지도 연결해야 하고요.
예전에는 다음 SQL을 직접 작성하면서 분석의 방향을 통제했습니다.
앞으로는 AI가 제안한 분석경로를 보며 왜 이 질문부터 시작했는지, 다른 순서는 없었는지, 어디에서 판단이 너무 빨라졌는지 확인하는 시간이 늘어날 겁니다.
분석가의 역할이 사라진다기보다 관여하는 지점이 달라지는 쪽에 가깝습니다.
SQL 순서를 직접 만드는 일에서, AI가 만든 순서의 빈틈을 찾아내는 쪽으로 이동합니다. 수치를 계산하는 데서 멈추지 않고, 그 수치가 어떤 조건에서 나왔으며 어디까지 의사결정의 근거로 쓸 수 있는지 설명해야 합니다.
이번 발표에는 실제 업무시간이 얼마나 줄었는지,
복잡한 분석에서 어느 정도 정확도를 보였는지 확인할 수 있는 독립 평가가 포함돼 있지 않습니다.
문서 분석도 파일만 연결한다고 같은 품질이 나오는 것은 아닙니다. 파일 형식과 스캔 상태, 문서 구성, 색인 방식에 따라 검색 결과가 달라질 수 있습니다. 필요한 문서를 찾았더라도 문서 안의 의견이 전체 고객이나 사업 상황을 대표하는지는 별도로 판단해야 하고요.
기능이 가능하다는 것과 현업에서 그대로 믿고 사용할 수 있다는 것은 나눠서 봐야 합니다.
그래도 방향은 꽤 분명해졌습니다.
AI는 이제 사용자가 던진 질문에 답하는 데서 멈추지 않습니다.
문제를 여러 단계로 나누고, 다음에 볼 데이터를 선택하고,
표와 문서를 연결한 뒤 하나의 설명으로 정리하기 시작했습니다.
그러면 사람에게 남는 질문도 달라집니다.
“계산이 맞는가?”만 묻기보다 “왜 이 순서로 분석했는가?”를 물어야 합니다.
“어떤 결과가 나왔는가?”와 함께 “무엇을 확인하지 않았는가?”도 봐야 하고요.
AI가 다음 분석을 제안할수록
분석가는 더 많은 답을 만드는 사람이 아니라,
그 답이 만들어진 범위를 확인하는 사람이 됩니다.
정교하게 작성된 보고서 안에서 빠진 질문을 찾고,
함께 움직인 지표를 원인으로 단정하지 않았는지 살펴보고,
마지막에는 회사가 실제로 무엇을 바꿀지 판단해야 합니다.
AI가 SQL을 대신 작성해서 생기는 변화보다,
다음 질문까지 대신 만들기 시작해서 생기는 변화가 더 크게 느껴지는 이유입니다.
Databricks, Genie Agents의 다단계·문서 분석 기능 발표
Databricks Genie Agents
Databricks Agent mode
AI 데이터 분석 에이전트
다단계 데이터 분석
정형·비정형 데이터 결합
Agent mode API
Genie One
Genie Ontology
Genie Code
AI 분석 품질관리
https://cafe.naver.com/ddlelab
#Databricks #GenieAgents #AgentMode #AI데이터분석 #데이터분석에이전트 #에이전틱AI #다단계분석 #정형데이터 #비정형데이터 #분석자동화 #데이터분석가 #AI분석품질관리 #데이터거버넌스 #GenieOne #GenieCode