바로가기YTtrendAIHRD자동화논문영상리포트
논문 메모 · 2026년 7월 9일

데이터 분석 AI는 표 하나보다 messy한 현장을 견뎌야 한다

논문 『Data Analysis in the Wild: Benchmarking Large Language Models Against Real-World Data Complexities』를 읽고

대표 이미지

DataGovBench 논문은 실제 공공데이터처럼 큰 다중 표, 메타데이터, 외부지식, 탐색적 인사이트가 얽힌 조건에서 LLM 데이터 분석 능력을 평가한다.

제일 먼저 든 생각

데이터 분석 자동화를 말할 때 가장 위험한 착시는 “표를 주면 답을 낼 수 있다”는 믿음이다. 실제 업무의 데이터는 표 하나가 아니다. 여러 탭과 파일이 얽혀 있고, 컬럼 이름은 불친절하며, 단위와 집계 수준이 섞이고, 외부 지식을 끌어와야 하고, 때로는 사용자가 질문조차 선명하게 주지 않는다.

이 논문은 바로 그 지점을 벤치마크로 만든다. DataGovBench는 공공 오픈데이터에서 온 복잡한 다중 표 데이터셋을 바탕으로, LLM과 에이전트가 단순 질의응답을 넘어 실제 데이터 분석에 가까운 일을 얼마나 해내는지 본다.

DataGovBench의 표 질의응답과 인사이트 생성 평가 구조를 카드형 인포그래픽으로 정리한 그림

DataGovBench는 작은 표의 사실 검색이 아니라, 다중 표·메타데이터·외부지식·탐색적 인사이트 생성을 함께 평가한다.

작은 표 QA로는 현장 분석을 못 재현한다

논문은 기존 데이터 분석 벤치마크가 주로 작은 표에서 사실을 찾는 과제에 머물렀다고 본다. 하지만 현실의 분석 업무는 훨씬 지저분하다. 질문이 여러 하위 질문으로 나뉘고, 답이 텍스트일 수도 시각화일 수도 있으며, 데이터 사전과 외부 문서를 함께 봐야 한다.

DataGovBench는 두 가지 과제를 둔다. 첫째는 Table QA다. 복잡하고 분해 가능한 질문에 대해 텍스트 답이나 시각화를 만들어야 한다. 둘째는 Table Insight다. 특정 질문 없이도 전문가 수준의 탐색적 발견과 요약을 생성해야 한다. 이때 정답 근거로는 사람이 검증한 QA 쌍과 데이터셋에 붙은 전문가 보고서를 활용한다.

“현재 데이터 분석용 LLM 평가 벤치마크는 실제 환경을 충분히 반영하지 못하는 경우가 많다.”

“Current benchmarks for evaluating Large Language Models (LLMs) in data analysis often fail to reflect real-world settings.”

이 문장은 Power BI나 업무 분석 자동화에도 그대로 걸린다. 자연어 질의로 차트 하나를 만드는 능력과, messy한 데이터셋에서 분석 가능한 질문을 만들고 검증하는 능력은 다르다.

에이전트가 붙어도 절대 점수는 아직 낮다

논문 결과는 기대와 경고가 같이 있다. 구조화된 Answer Agent를 붙이면 Table QA에서 기본 LLM보다 나아졌다. 예를 들어 Gemini 2.5 Flash에서는 Whole setting 기준 약 27%, Individual setting 기준 약 25%의 상대 개선이 있었다. 하지만 절대 점수는 여전히 낮았다. 최고 Whole score도 0.4 아래에 머물렀다.

Table Insight에서는 Claude Sonnet 4.6이 에이전트 접근에서 가장 나은 성과를 보였지만, Insight-level score는 0.35 아래, Summary-level score는 0.5 아래였다. 논문은 이것을 실제 데이터 분석 자동화가 아직 요구 수준에 멀다는 신호로 읽는다.

“에이전트 지원이 있어도 최신 상위 모델들이 두 과제 모두에서 낮은 정확도를 보였다.”

“Extensive evaluation of state-of-the-art models reveals a crucial performance gap, as even top models achieve low accuracy despite agentic support.”

이 결과를 AI 데이터 분석의 실패 선언으로 읽을 필요는 없다. 오히려 어디에 안전장치를 둬야 하는지 알려주는 지도에 가깝다.

원문 첫 페이지

원문 첫 페이지. 연구는 Data.gov 등 공공데이터를 바탕으로 Table QA와 Table Insight 과제를 구성했다.

실패는 대부분 “계산”보다 “맥락 처리”에서 온다

오류 분석도 실무적으로 유용하다. Gemini 2.5 Flash와 Answer Agent 조건에서 틀린 답을 분석했을 때, 가장 큰 오류는 조건 필터 오류(32.4%)였다. 예를 들어 남성·여성·전체처럼 집계와 세부 값이 함께 있는 데이터에서 적절한 필터를 적용하지 못해 중복 계산하는 식이다. 그다음은 변환 오류(23.2%)였다. 날짜 형식, 숫자 문자열, 데이터 wrangling에서 깨지는 문제다.

이 부분은 실제 분석가가 매일 겪는 일과 닮았다. 분석 자동화에서 어려운 것은 평균을 계산하는 함수가 아니라, 어떤 행을 빼야 하는지, 어떤 단위가 섞였는지, 어떤 표가 기준표인지, 어떤 외부 설명을 봐야 하는지를 판단하는 일이다.

논문은 LLM 에이전트의 두 가지 부족한 능력도 짚는다. 하나는 표 데이터에 대한 narrative-level reasoning, 즉 중앙 분석 논지를 잡는 능력이다. 다른 하나는 복잡한 표에서 정확한 사실을 가져오는 능력이다. 이는 “답변 생성”보다 “분석 이야기와 근거 선택”이 더 어려운 병목이라는 뜻이다.

Deciflow에 붙이면 분석 자동화의 합격선을 다시 정해야 한다

이 논문을 실무 자동화로 가져오면, 자연어 데이터 분석 봇의 합격선을 낮고 구체적으로 잡아야 한다. 처음부터 “알아서 인사이트를 찾아줘”를 맡기기보다, 다음처럼 역할을 나누는 편이 안전하다.

Power BI나 평가 자동화에서도 마찬가지다. 좋은 자동화는 버튼 하나로 멋진 차트를 뽑는 것이 아니라, 데이터가 분석 가능한 상태인지 먼저 묻고, 틀리기 쉬운 조건 필터와 변환을 사람에게 보이게 만드는 것이다.

작은 실험

다음 분석 자동화 실험에서는 LLM에게 바로 결론을 묻지 말고, “분석 전 검수 카드”를 먼저 만들게 해볼 수 있다. 카드에는 사용한 표, 제외한 행, 필터 조건, 변환한 컬럼, 외부 지식이 필요한 지점, 신뢰 낮은 결론을 적게 한다.

그다음 사람이 검수 카드만 보고 “이 분석을 계속 진행해도 되는가”를 판단한다. 이 작은 단계가 없으면 AI는 그럴듯한 인사이트를 빠르게 만들 수 있지만, 어디서 잘못됐는지 추적하기 어려워진다. 이 논문이 보여준 것은, 데이터 분석 AI의 병목이 답변 유창성이 아니라 복잡한 데이터 맥락을 견디는 능력에 있다는 점이다.

조심해서 읽을 점

DataGovBench는 공공데이터와 논문이 설계한 평가 방식에 기반한다. 모든 기업 데이터, 모든 BI 업무, 모든 평가 자동화 상황을 대표한다고 말할 수는 없다. 또 자동 평가 지표가 전문가 판단 전체를 대체한다고 보기도 어렵다. 다만 복잡한 다중 표와 탐색적 인사이트를 평가 과제로 만든 점은, 실제 업무형 데이터 분석 AI를 점검하는 데 좋은 기준선을 제공한다.

원문 정보

원문 논문: Data Analysis in the Wild: Benchmarking Large Language Models Against Real-World Data Complexities