[Paper Review] Analytic Agent for Enterprise API

LLM 활용 혁신 예측

Beyond Text-to-SQL: An Agentic LLM System for Governed Enterprise Analytics APIs

Gundeep Singh, Parsa Kavehzadeh, Jing Xia, Xue-Yong Fu, Julien Bouvier Tremblay, Md Tahmid Rahman Laskar, Vincent Lum, Shashi Bhushan TN (Dialpad Inc.)

arXiv 2026 ↗

배경

엔터프라이즈 분석(enterprise analytics)은 조직의 데이터를 의사결정에 활용할 수 있도록 접근 가능하게 만드는 것을 목표로 한다. 그러나 비전문(non-technical) 사용자에게는 전통적인 비즈니스 인텔리전스(BI) 도구의 복잡한 인터페이스와 도메인 전용 언어라는 장벽이 존재한다. LLM 기반 접근법이 Text-to-SQL 성능을 개선했으나 이는 단발성(single-shot) 파이프라인, 넓은 분석 생태계와의 통합 부재, 데이터 거버넌스를 강제하지 못한다는 점으로 인해 기업 환경에서의 한계가 존재한다.

ReAct, Toolformer과 같은 에이전트 프레임워크가 다단계 워크플로우에 대한 조율 가능성을 보였으나 기업 분석 API 위에서 시맨틱 파싱, 거버넌스 인지 도구 사용, 다단계 추론을 통합한 사례는 없었다. 이 공백(research gap)이 본 연구의 계기가 된다.

문제

논문이 해결하고자 하는 Big Question은 "비전문가가 자연어만으로 기업의 분석 데이터에 안전하게, 거버넌스를 지키면서 접근할 수 있는가"이다. 특히 원시 DB(SQL)이 아닌 거버넌스가 적용된 API 상에서 이것이 네이티브하게 가능한지, 구체적으로는 자연어 의도(intent)를 거버넌스 기업 분석 API에 대한 안전한 상호작용으로 번역하는 LLM Agent를 실제 산업 배포 환경에서 구축하고 그 정확도와 실행 안정성을 정량적으로 평가할 수 있는지 묻는다.

방법

본 논문은 LLM을 비즈니스 로직의 저장소가 아닌 안정적 구조 인터페이스 위의 플래너로만 사용하는, 4개의 LLM 서브시스템으로 구성된 에이전트 시스템 Analytic Agent를 통해 접근한다. SQL 직접 접근을 배제하고, 문제를 "적절한 API 엔드포인트 선택 + 스키마 준수 요청 생성"으로 전환한다. 논문은 API가 SQL보다 나은 이유로 세 가지를 든다. 테넌트 스코핑이나 마스킹과 같은 보안 불변식을 강제하고, 지표의 의미를 제품이나 리포트 간에 일관되게 유지하도록 비즈니스 로직을 캡슐화하며, 검증, 로깅, 캐싱을 갖춘 안정적 실행 표면을 제공한다는 것이다.

방법론의 핵심은 시스템 아키텍처이다. 사용자의 자연어 질의가 오케스트레이션 계층의 조율에 따라 나머지 3개의 전문 에이전트를 순차적으로 통과하며, 쿼리 실행 검증에 실패하면 재시도 루프가 도는 구조이다.

1. Orchestration
Parse → Targets → Query → Viz → Done 순서로 진행하며, 해결된 타깃과 시간 창을 세션에 유지하고 명확화 질문은 흐름당 최대 1회로 제한한다.

2. Target grounding
"Seattle의 Support 팀"처럼 불완전한 표현을 사용자의 접근 권한으로 필터링된 조직 메타데이터에 대한 퍼지 매칭으로 구체적 엔티티에 대응시키고, 진행 전 권한을 확인한다.

3. Database querying
시간 기반 요청은 LLM 추론이 아니라 결정론적 날짜 처리 함수를 사용하여 Hallucination을 줄인다.
예측 가능한 오류는 프로그래밍적으로, 모호한 오류는 LLM으로 처리하는 2단계 오류 처리를 사용한다.

4. Visualization
시각화를 자유 텍스트 생성이 아니라 규칙 기반 구조 생성 문제로 다룬다.

• 시계열 → 선
• 범주 → 막대
• 비율 → 파이
• 분포 → 히스토그램

차트도 데이터와 동일한 권한을 따르며 민감한 정보는 마스킹한다.

결과

평가는 완전 일치(exact-match) 대신, 사실 정합성을 자동으로 측정하는 지표인 AlignScore와 GPT, Claude 두 모델을 심판으로 사용하는 LLM-as-a-judge 이진 판정을 함께 사용한다.

모델	실행 성공률	AlignScore	E2E 정확도
Gemini-2.5-Pro	96.67%	60.03	77.22%
Gemini-2.5-Flash	94.44%	49.74	71.67%
Gemini-2.5-Flash-Lite	44.44%	23.07	16.12%

• 심판별 E2E 정확도(부록): Pro는 GPT-5.2 76.67 / Claude 77.78, Flash 70.00 / 73.33, Flash-Lite 15.56 / 16.67
• 심판 평균 점수: GPT-5.2 54.08, Claude-Opus-4.6 55.93. 절대적 점수는 다르지만 상대적 모델 순위에는 두 심판이 강하게 동의한다.
• 배포는 성능, 비용, 지연의 균형을 고려해 Gemini-2.5-Flash를 선택하고, Google Cloud Run의 컨테이너형 Python 마이크로서비스로 운영된다.
• 필드 정의 캐싱으로 평균 생성 지연 22% 감소(24.84s → 19.31s), 입력 처리 비용 64% 감소

참고: 본문 3.4절에는 Flash-Lite의 E2E 정확도가 17.41%로 서술되어 있으나, Table 1 / Table 2(15.56 / 16.67의 평균)와는 16.12%로 나타나 표와 본문 사이에 수치 불일치가 있다.

논의

이 논문의 핵심 발견은 '구조적 유효성은 필요조건이지만 충분조건이 아니다' 정도로 요약할 수 있다. Flash-Lite는 44.44%의 요청을 실행 가능하게 생성하지만 E2E 정확도는 16%에 그친다. 즉 페이로드가 검증을 통과해도 엔드포인트 선택, 타깃 그라운딩, 시간 필터링이 틀릴 수 있으며, 복잡한 기업 스키마에서 이를 처리하려면 모델 용량(capacity)이 중요하다는 것이다. 따라서 '실제 배포 환경에서 거버넌스 API 에이전트가 가능한가'에 대해 Pro나 Flash급 모델로는 실용적 수준(E2E 71-77%)에서 가능하다는 긍정적인 답변을 제시한다.

저자들이 강조하는 아키텍처 측면의 특성은 LLM을 비즈니스 로직의 저장소로 두지 말고 플랫폼이 소유한 안정적 구조 인터페이스 상의 플래너로만 사용하라는 것이다. 인증, 지표 정의, 감사 로깅, 렌더링은 모델 바깥에서만 사용하고 모델은 의도 해석과 도구 선택만 담당하게 해 실패 진단을 쉽게 만든다는 논리이다. 이 부분에 대해서 비판적으로 읽을 시 몇 가지 한계가 존재한다.

• 90개의 use case는 논문이 자인하는 한계이며, 통계적 일반화에는 제약이 존재한다.
• LLM-as-a-judge 방식의 한계로 인해 심판 모델 자체의 편향이나 오류 가능성이 남고, AlignScore 60은 절대치로 높다고 보기는 어렵다.
• 실험에서는 전문가가 작성한 단일 API 페이로드를 정답으로 삼는다. 그러나 실무에서 동등하게 타당한 다른 페이로드가 있을 수 있기에 정답의 단일성 가정은 비약으로 해석될 여지가 있다.

또한 초록과 본문의 방향성은 일치하지만 초록은 성공 수치를 앞세우는 반면, 본문의 더 흥미로운 통찰이 실행 가능성과 정확성의 괴리와 책임을 분리하는 아키텍처에 있다는 점에서 초록이 논문의 방법론적 기여를 과소평가할 수 있다. 또한 필드 정의 캐싱만으로 지연을 22%, 입력 처리 비용을 64% 줄였다는 결과는 이 시스템의 기여가 정확도뿐 아니라 실제 서비스 운영에 필요한 비용 및 지연 최적화에도 있음을 보여준다. 이는 '실전 배포 사례'로서의 성격을 뒷받침한다.

종합하면, 기업 분석을 SQL이 아니라 거버넌스 API 위에서 다루는 4-에이전트 LLM 시스템 Analytic Agent를 제안하고, "LLM은 비즈니스 로직의 저장소가 아니라 안정적 인터페이스 위의 플래너여야 한다"는 프로덕션 아키텍처 교훈을 제시한 실전 배포 사례 논문이다. 화려한 신규 기법보다 책임 분리라는 엔지니어링 원칙으로 신뢰성을 확보했다는 점에서 실제 서비스에 LLM을 사용하고자 할 때 특히 참고할 만하다.