2026년 VLDB workshop proceedings에서 눈에 띄는 변화는 “LLM이 데이터베이스를 얼마나 잘 호출하는가”가 아니다. 더 근본적인 질문은 에이전트의 행동 자체를 데이터시스템의 대상으로 다루기 시작했다는 데 있다. 계획은 실행계획이 되고, 기억은 상태가 되며, 로그는 provenance가 되고, 실패는 recovery 문제로 바뀐다.
첨부 메모는 2026년 8월 22일 기준 VLDB 2026 Workshop Proceedings가 공개되면서 Agentic Data Systems·DASHSys·NOVAS에서 LLM/데이터 에이전트 관련 연구들의 공식 accepted/proceedings 상태를 확인할 수 있게 되었다고 정리한다. 본회의는 2026년 8월 31일–9월 4일 개최 예정이라는 시점 정보도 함께 담고 있다.
VLDB 커뮤니티의 agent 연구는 “LLM application”에서 “database-native agent system”으로 이동하고 있다. 핵심 primitive는 context assembly, workflow planning, operator grounding, persistent state, provenance, verification, recovery, semantic optimization이다.
이 글은 첨부된 vldb-trends.md의 전체 내용을 재구성한 기술 에세이다. 수치·accepted/proceedings 상태·논문별 설명은 첨부 메모의 서술을 기준으로 했으며, 이 글 작성 과정에서 논문 원문이나 외부 웹 자료를 추가 검증해 보강하지 않았다.
에이전트는 이제
데이터베이스의 ‘사용자’만이 아니다
The database research question moves inward: from serving agents to managing their execution.
초기의 LLM–database 연구를 단순화하면 질문은 명확했다. 자연어를 SQL로 바꿀 수 있는가, 필요한 table을 찾을 수 있는가, database를 tool처럼 호출할 수 있는가. 이 질문은 여전히 중요하다. 그러나 첨부 메모가 모아 놓은 VLDB 2026 workshop 논문들은 관심의 무게중심을 한 단계 안쪽으로 옮긴다.
이제 관리 대상은 table과 tuple만이 아니다. agent context, tool call, workflow state, intermediate artifact, failure trajectory, semantic intent 자체가 query·verification·optimization의 대상이 된다. database community가 오랫동안 다뤄 온 execution plan, provenance, transaction state, operator semantics, recovery 개념이 agentic system에 다시 등장하는 이유다.
LLM + DB API
LLM이 SQL이나 tool call을 만들고 DB는 결과를 반환하는 구조다.
Agent execution as data
계획·실행·state·trajectory·artifact를 저장하고 검증하고 비교하는 시스템 문제로 확장된다.
Control & semantics
optimizer, provenance, recovery, admissible operator, state verification이 핵심이 된다.
이 변화가 중요한 까닭은 agent의 오류가 더 이상 “모델이 틀린 문장을 만들었다”로만 설명되지 않기 때문이다. 잘못된 context를 조립할 수도 있고, 올바른 tool을 잘못된 순서로 호출할 수도 있으며, write-path에서 겉보기 output은 맞아도 실제 data state는 틀릴 수 있다. 사용자의 분석 의도를 문법적으로는 실행 가능한 workflow로 만들었지만 의미적으로는 엉뚱하게 operationalize할 수도 있다.
Text-to-SQL을 ‘한 번의 생성’에서
‘경험을 재사용하는 탐색’으로
Experience-guided decompositional search reframes query synthesis as an adaptive data-system loop.
첨부 메모가 첫 번째로 강조하는 논문은 VLDB 2026 ADS/DATAI의 ExpeSQL: An Efficient, Experience-Guided Decompositional Search Framework for Text-to-SQL이다. 이 연구의 핵심은 Text-to-SQL을 stateless generation으로 보지 않는 데 있다.
첨부 메모에 따르면 공개 초안은 BIRD-dev에서 67.5% execution accuracy를 보고하며, Alpha-SQL과 유사한 정확도에서 token generation을 최대 87%, latency를 96% 줄였다고 설명한다. 이 수치를 그대로 받아들이기보다 구조적 의미를 보는 편이 더 중요하다.
Text-to-SQL을 매번 처음부터 풀면 LLM의 비용과 오류도 매번 반복된다. ExpeSQL의 framing은 이전 실패와 성공을 persistent experience로 축적한다. 여기서 query synthesis는 자연어 생성 문제가 아니라 adaptive search + execution feedback + reusable state 문제가 된다.
Agentic Analytics를
실행계획으로 다루기
Workflow-centric analytics borrows the compiler–validator–optimizer–executor discipline from databases.
DeepEye: A Workflow-Centric Agentic Data System for Steerable Data Analytics는 첨부 메모가 보여 주는 변화 가운데 가장 데이터베이스다운 사례다. heterogeneous structured/unstructured source를 orchestration하고, 복잡한 intent를 autonomous AgentNodes와 deterministic ToolNodes로 나눈다.
핵심 engine은 Compiler–Validator–Optimizer–Executor로 구성된다. 이름만 보아도 의도가 분명하다. 사용자의 자연어 요청을 곧바로 “대답”으로 바꾸지 않고, 먼저 실행 가능한 workflow로 compile한다. 그 workflow가 admissible한지 validate하고, 더 나은 실행 순서를 optimize한 뒤, 마지막에 execute한다.
불확실성을 맡는 노드
추론과 선택이 필요한 부분을 autonomous agent가 처리한다.
결정성을 맡는 노드
정해진 operator나 tool execution을 deterministic하게 수행한다.
이 분리는 중요하다. 모든 것을 LLM에게 맡기면 workflow의 어느 부분이 deterministic guarantee를 갖는지 알기 어렵다. 반대로 모든 것을 fixed pipeline으로 만들면 open-ended analytical intent를 수용하기 힘들다. DeepEye의 framing은 이 둘을 하나의 execution graph 안에서 조합한다.
따라서 agentic analytics를 ChatBI의 연장선으로만 보면 핵심을 놓친다. 첨부 메모가 강조하듯, 중요한 변화는 검증·최적화 가능한 dataflow execution plan으로 분석 workflow를 다룬다는 데 있다.
로그가 아니라 provenance graph를 남긴다
Trust and reuse require a data model for what the agent actually did.
DASHSys의 AgentTrails: Towards Trust and Reuse for Agentic Tasks는 agent 실행 기록을 어떻게 보관해야 하는지 묻는다. chronological log만 남기면 “무슨 일이 일어났는가”는 볼 수 있어도 “어떤 tool call이 어떤 artifact를 만들었고, 그 결과가 다음 결정에 어떻게 영향을 주었는가”를 구조적으로 비교하기 어렵다.
첨부 메모에 따르면 AgentTrails는 chronological agent log를 tool call과 input/output artifact 사이의 dependency를 표현하는 structured provenance graph로 바꾼다. 여러 실행은 quotient graph로 정렬해 비교하고, debugging, pattern extraction, skill reuse를 지원한다.
이 접근이 암시하는 바는 분명하다. 장기 agent memory를 단순한 conversation history나 vector store로만 보면 부족할 수 있다. 무엇을 했는지뿐 아니라 왜 그 artifact가 생겼고 어떤 action chain을 거쳤는지를 query할 수 있어야 한다.
정답 문자열이 맞아도
데이터 상태가 틀릴 수 있다
Write-path agents force evaluation to move from output matching to state verification.
VLDB 2026 ADS/DATAI의 “Skill Issues”: Data-Centric Optimization of Lakehouse Agents는 agent 성능을 model parameter만의 문제로 보지 않는다. skill/environment artifact와 실제 lakehouse state가 performance를 결정하는 대상으로 들어온다.
첨부 메모는 이 연구가 task–verifier pair를 생성하고 isolated sandbox에서 candidate skill을 실행한 다음, trajectory와 실제 lakehouse state를 함께 검증한다고 정리한다. 초기 25개 task 평가에서는 optimized skills가 accuracy를 31.9% 개선했다고 보고한다.
여기서 데이터시스템 관점의 핵심은 write-path evaluation이다. read-only query라면 최종 text나 returned table이 맞는지 비교할 수 있다. 하지만 agent가 table을 만들고, data를 수정하고, pipeline state를 바꾸는 순간 output string만으로는 correctness를 판단할 수 없다.
말한 것이 맞는가
응답 텍스트나 표면적인 결과를 비교한다.
어떻게 수행했는가
tool sequence와 intermediate decision이 정책·제약을 지켰는지 본다.
실제로 무엇이 바뀌었는가
lakehouse의 persistent state가 의도한 post-condition을 만족하는지 검증한다.
이렇게 보면 verifier는 benchmark의 보조 도구가 아니라 execution semantics의 일부가 된다. agent 평가를 “answer correctness”에서 post-state correctness로 확장하는 셈이다.
실행 가능하다는 것과
의도를 이해했다는 것은 다르다
Operationalization failure exposes the missing semantic layer between analytical concepts and executable operations.
NOVAS의 Exploring the Semantic Gap in Agentic Data Systems: A Formative Study of Operationalization Failures in Analytical Workflows는 agent-generated workflow가 정상적으로 실행되더라도 사용자 intent를 제대로 operationalize하지 못할 수 있다는 문제를 다룬다.
첨부 메모에 따르면 finance·HR·public safety의 236 analytical intents에서 153개의 반복적 failure를 분석했고, 실패를 다섯 유형으로 정리한다.
| Failure type | What goes wrong | Data-system implication |
|---|---|---|
| Comparative grounding | 비교 대상이나 기준을 잘못 설정한다. | 비교 의미를 operator parameter 수준에서 명시할 semantic grounding이 필요하다. |
| Process reasoning | 업무 절차의 순서·상태 전이를 잘못 이해한다. | workflow semantics와 process constraints를 실행계획에 반영해야 한다. |
| Quantitative reasoning | 수량·분모·집계 조건을 잘못 operationalize한다. | metric definition과 admissible aggregation을 명시적으로 관리할 필요가 있다. |
| Role confusion | 행위자·책임·관점이 뒤섞인다. | role-aware schema/ontology와 권한 semantics가 필요하다. |
| Policy grounding | 규칙·정책 조건을 workflow에 잘못 연결한다. | policy를 자연어 배경지식이 아니라 executable constraint로 다뤄야 한다. |
이 결과에서 보이는 간극은 schema grounding보다 넓다. column 이름을 올바르게 찾았다고 해서 분석 의도를 올바르게 구현한 것은 아니다. analytical concept → admissible operation 사이에 richer semantic layer가 필요하다는 것이 첨부 메모의 해석이다.
추가 proceedings 제목들이 만드는 하나의 지도
첨부 메모는 이 흐름을 보강하는 논문 제목으로 ContextPipe, DemandPrep, TSAutoBox, Structured State Management for Agentic Data Pipelines, TransForm, SemJoin, RUBICON을 함께 제시한다. 메모에는 이들의 상세 방법이나 수치가 들어 있지 않으므로 여기서는 제목이 시사하는 연구 축만 정리한다.
| Paper | Theme visible in source memo | Broader DB primitive |
|---|---|---|
| ContextPipe | Long-horizon agent의 database-inspired context assembly | context selection / assembly |
| DemandPrep | demand-driven data preparation과 agentic action allocation | operator allocation / preparation planning |
| TSAutoBox | industrial time-series task automation을 위한 localized multi-agent | domain workflow orchestration |
| Structured State Management | agentic data pipeline의 structured state | state model / persistence |
| TransForm | MCP tool output의 dynamic format selection | representation / physical-format choice |
| SemJoin | semantic join optimization | semantic operator optimization |
| RUBICON | messy enterprise data를 위한 agentic AI | robust enterprise-data execution |
이 묶음의 공통점은 agent를 model-centric application으로 보지 않는다는 데 있다. context, state, format, join, operator, recovery처럼 database system이 잘하는 문제를 agent runtime의 핵심으로 끌어들인다.
VLDB 2026이 보여 주는
Agentic Data Systems의 연구문제
The frontier is not “more agents”; it is better data-system semantics for agent execution.
첨부 메모 전체를 하나의 연구지도처럼 읽으면, 향후 agentic data system이 해결해야 할 문제는 적어도 일곱 축으로 정리된다.
- 01Context assembly. long-horizon task에서 어떤 context를 언제 조립해야 하는가.
- 02Workflow compilation. open-ended intent를 검증 가능한 execution graph로 어떻게 바꿀 것인가.
- 03Operator grounding. agent의 action을 명시적 operator와 제약으로 어떻게 연결할 것인가.
- 04State management. intermediate artifact와 persistent environment state를 어떤 model로 관리할 것인가.
- 05Provenance and reuse. trajectory를 queryable graph로 만들고 debugging·skill extraction에 어떻게 재사용할 것인가.
- 06Verification and recovery. output뿐 아니라 post-state와 policy compliance를 검증하고 failure에서 어떻게 backtrack할 것인가.
- 07Semantic optimization. 사용자 analytical concept를 admissible operation으로 바꾸는 semantic layer와 optimizer를 어떻게 설계할 것인가.
이 축들은 서로 독립적이지 않다. provenance가 있어야 failure diagnosis가 쉬워지고, explicit state가 있어야 write-path verification이 가능하며, operator semantics가 있어야 workflow optimizer가 제대로 작동한다. context assembly도 결국 어떤 state와 provenance를 다음 decision에 투입할지 고르는 문제다.
그래서 “multi-agent system”이라는 이름만으로는 시스템의 연구 기여를 충분히 설명하기 어렵다. 어떤 data model을 새로 정의했는가, 어떤 operator가 필요한가, 어떤 cost/verification semantics를 도입했는가, failure를 어떤 state transition으로 다루는가를 물어야 한다. 데이터베이스 커뮤니티가 agentic AI에서 맡을 수 있는 역할이 바로 여기에 있다.
현재 시점의 경계
첨부 메모는 이번 확인에서 SIGMOD 2026과 ICDE 2026 쪽에 기존 기준선 이후 새로 확정된 main-track acceptance 변화는 별도로 확인하지 못했고, 가장 의미 있는 신규 공식 업데이트는 VLDB 2026 workshop proceedings 공개였다고 명시한다. 따라서 이 글의 범위도 VLDB 2026 workshop에서 포착된 agentic data systems 흐름에 한정한다.
또한 이 메모는 proceedings의 여러 제목을 넓게 훑는 update 성격의 자료다. ExpeSQL, DeepEye, AgentTrails, Skill Issues, semantic-gap 연구에 대해서는 핵심 구조와 일부 수치가 제시되어 있지만, 추가 제목들에는 상세 method·experimental protocol·limitation이 포함되어 있지 않다. 그러므로 이 글은 그 빈칸을 일반지식으로 채우지 않았다.