Paper
OmniTable: A Unified Wide-Table System for Petabyte-Scale LLM Data Curation and Exploration
Executive Reading
이번 DB-Agent 연구추적에서 의미 있는 신규 신호는 새 acceptance가 아니라 VLDB 2026의 공식 수상 결과다. OmniTable이 Best Industry Paper로 선정되면서, LLM 데이터 관리 연구의 무게중심이 단순한 semantic operator나 agent orchestration을 넘어 AI-ready data substrate 자체로 내려가고 있음을 보여준다.
OmniTable은 대규모 LLM 학습 데이터 준비를 수많은 독립 테이블과 ETL pipeline의 집합으로 취급하지 않는다. “Logical Unification + Physical Separation”이라는 원리 아래 feature를 하나의 논리적 wide-table 안에서 보이게 하되, 실제 저장과 실행은 물리적으로 분리한다. 그 위에서 dependency, execution planning, operator fusion, lineage, heterogeneous CPU/GPU execution, fault tolerance, storage layout을 시스템이 관리한다.
Best IndustryVLDB 2026 award
35+ PBproduction training data
14 → 2.5 dhuman-in-loop curation cycle
5.6×reported cycle reduction
핵심은 “LLM을 DB에서 어떻게 호출할 것인가”보다 더 아래에 있다. Agent가 데이터를 스스로 선택·정제·변환·재사용하려면, 먼저 versioned·dependency-aware·lineage-tracked data asset을 관리할 수 있는 substrate가 필요하다.
Part I · Award Signal
새 논문보다 중요한 것은 “무엇이 실제 산업적 가치로 인정됐는가”이다
2026년 9월 3일 확인 기준, OmniTable은 VLDB 2026 공식 Conference Awards의 Best Industry Paper로 새롭게 등재되었다.
§1 · What changed
논문은 PVLDB Vol. 19, No. 12, pp. 4276–4289 (2026)에 정식 게재되어 있다. 이번 tracking에서 중요하게 볼 점은 새로운 acceptance 목록이 하나 더 늘어난 것이 아니라, VLDB가 산업 현장에서 실제로 검증된 LLM data curation infrastructure에 상을 부여했다는 사실이다.
“Agent가 데이터를 더 잘 이해하도록 만드는 연구”와 “Agent가 사용할 데이터를 더 잘 관리하는 연구”는 분리된 문제가 아니다. OmniTable의 수상은 후자가 독립된 시스템 연구축으로 충분히 중요하다는 신호다.
첨부 자료의 추적 결과에서는 같은 기간 SIGMOD·ICDE에서 이전 실행 이후 새롭게 확정된 동급의 LLM/data-agent 관련 acceptance는 확인되지 않았다. 따라서 이번 업데이트는 OmniTable 한 건에 집중하는 것이 오히려 정보밀도가 높다.
§2 · Paper identity
Status
PVLDB Vol. 19, No. 12, 4276–4289, 2026. VLDB 2026 Best Industry Paper.
Part II · Data Substrate
수많은 ETL pipeline을 하나의 wide-table로 보되, 실행은 분리한다
논리적 단순성과 물리적 최적화를 동시에 얻는 것이 OmniTable의 설계 중심이다.
§3 · Logical Unification + Physical Separation
대규모 LLM training corpus는 web, code, PDF, SFT처럼 형식과 처리연산이 다른 데이터가 혼재한다. 전통적인 pipeline 관점에서는 각각의 데이터셋, intermediate feature, quality signal, transform 결과가 서로 다른 테이블·job·script에 흩어진다. OmniTable은 이 파편화를 하나의 논리적 wide-table abstraction으로 감싼다.
그러나 논리적으로 하나라고 해서 물리적으로 모든 것을 하나의 테이블 파일에 저장한다는 뜻은 아니다. 실제 storage, materialization, CPU/GPU operator execution은 workload 특성에 맞춰 분리된다. 즉 사용자와 상위 시스템에는 unified relation을 제공하면서, engine 내부에서는 cost와 hardware에 따라 실행전략을 달리한다.
Dependency
feature 간 선후관계와 재사용 가능성을 resolution한다.
Planning + Fusion
execution planning과 operator fusion으로 불필요한 materialization과 반복실행을 줄인다.
Lineage
feature가 어떤 source·version·transform에서 생성됐는지 추적한다.
CPU / GPU
heterogeneous execution을 통해 연산 성격에 맞는 자원을 선택한다.
Fault Tolerance
장시간 대규모 curation workload에서 실패 복구를 시스템 책임으로 둔다.
Storage Layout
접근패턴과 workload에 맞춰 physical layout을 자동 최적화한다.
§4 · Feature becomes a data asset
이 설계의 더 중요한 함의는 feature를 일회성 pipeline output으로 보지 않는다는 데 있다. feature는 versioned·dependency-aware·lineage-tracked first-class asset이 된다. 어떤 feature를 이미 계산했는지, 어떤 upstream asset에 의존하는지, 어떤 버전에서 생성됐는지, 다시 쓸 수 있는지가 데이터 관리의 직접 대상이 된다.
이렇게 보면 LLM data curation은 “스크립트를 실행해 파일을 만든다”는 작업이 아니라, provenance를 가진 파생 data asset을 지속적으로 생성·재사용하는 데이터베이스 문제로 재정의된다.
Part III · Production Scale
35 PB라는 숫자의 의미는 크기보다 반복 가능한 curation cycle에 있다
OmniTable의 산업적 의미는 scale만이 아니라 human-in-the-loop loop를 얼마나 빠르게 다시 돌릴 수 있는가에서 드러난다.
§5 · Reported production evidence
| Evidence | Reported scale / result | Why it matters |
|---|---|---|
| Managed data | 35 PB+ | web·code·PDF·SFT를 포함하는 production LLM training data substrate라는 점을 뒷받침한다. |
| Curation workflow | Human-in-the-loop | 완전 자동화가 아니라 사람이 quality 판단과 iteration에 개입하는 실제 workflow를 대상으로 한다. |
| Curation cycle | 약 14일 → 2.5일 | 같은 pipeline을 빠르게 다시 구성·실행·검증하는 iteration speed가 시스템 가치의 핵심임을 보여준다. |
| Reduction | 5.6× | 단일 operator latency가 아니라 end-to-end curation cycle 관점의 개선이다. |
이 수치는 “GPU를 더 빠르게 썼다”는 결과로만 읽으면 좁다. 실제 가치는 dependency를 추적하고, 중간산출물을 재사용하고, execution을 계획하고, lineage를 보존하면서 다음 curation iteration까지 걸리는 시간을 줄였다는 데 있다. AI data system에서 latency의 단위가 query 한 번이 아니라 dataset evolution cycle로 이동하고 있다는 뜻이다.
§6 · What is not claimed
Evidence boundary
첨부 자료가 제공하는 근거는 OmniTable의 production-scale 운영과 curation-cycle 단축이다. 이를 곧바로 autonomous data agent의 성능으로 해석할 수는 없다. OmniTable은 agent 자체라기보다, 향후 agent가 안정적으로 사용할 수 있는 하위 데이터 계층으로 읽는 것이 정확하다.
Part IV · From Data Curation to Data Agents
Agent가 “무슨 feature가 필요한가”를 결정하려면 DBMS가 그 이후를 책임져야 한다
OmniTable의 data-management 의미는 semantic operator보다 아래에서 agent workflow 전체의 reproducible execution substrate를 제공한다는 데 있다.
§7 · Agent-ready execution chain
Industrial-scale data-agent substrate\[\text{Data Agent}\rightarrow\text{Declarative Data/Feature Request}\rightarrow\text{Dependency DAG}\rightarrow\text{CPU/GPU Execution}\rightarrow\text{Versioned + Provenance-aware Assets}\]
이 흐름에서 agent는 모든 ETL implementation detail을 직접 조립하지 않는다. agent가 필요한 feature 또는 data transformation을 선언하면, DBMS가 dependency resolution, materialization, reuse, lineage, heterogeneous execution을 담당하는 구조가 된다. agent의 planning space와 DBMS의 execution space를 분리하는 셈이다.
1 · Intent
Agent가 분석·학습·검증에 필요한 feature를 결정한다.
2 · Declarative request
필요한 data/feature를 구현절차 대신 선언형으로 요청한다.
3 · Dependency graph
DBMS가 upstream dependency와 재사용 가능한 intermediate를 찾는다.
4 · Execution
CPU/GPU, fusion, fault tolerance, layout을 실행계획으로 결정한다.
5 · Asset memory
결과를 versioned·lineage-tracked asset으로 남겨 다음 agent cycle이 재사용한다.
§8 · Why provenance is agent memory infrastructure
agent memory를 대화 history나 vector store로만 보면 data-system 역할을 놓치기 쉽다. data agent에게 중요한 기억은 “어떤 답을 냈는가”뿐 아니라 어떤 source version을 어떤 transformation으로 처리해 어떤 feature를 만들었는가이다. OmniTable의 lineage는 이러한 실행기억을 data asset 수준에서 제공한다.
따라서 source가 제안하는 OmniTable + LLM-AutoDP + agent memory/provenance + cost-based agent optimizer의 결합은 자연스럽다. 상위 agent가 feature need를 판단하고, 데이터 계층이 dependency와 reuse를 관리하며, optimizer가 execution cost를 최소화하는 폐루프를 만들 수 있기 때문이다.
Part V · Research Agenda
다음 연구문제는 self-evolving AI data pipeline이다
OmniTable은 완성된 data agent가 아니라, data agent 연구가 산업 규모로 올라가기 위해 필요한 substrate의 실증 사례다.
§9 · High-value research questions
Agent가 feature를 선택하면 DBMS가 자동으로 materialization strategy까지 최적화할 수 있는가?
필요 feature의 logical dependency와 compute/storage reuse를 하나의 cost model에서 다루는 문제가 된다.
Agent memory를 versioned data asset lineage와 결합하면 재현 가능한 long-horizon data work가 가능한가?
대화기억과 실행기억을 분리하고, 후자를 DBMS가 관리하는 새로운 agent memory abstraction이 필요하다.
CPU/GPU heterogeneous execution을 agent-level planning cost와 함께 최적화할 수 있는가?
LLM/tool-call 비용과 data operator 비용을 통합한 cost-based optimizer로 확장될 수 있다.
새 dataset version이 도착했을 때 필요한 feature만 선택적으로 재계산하는 self-evolving pipeline을 만들 수 있는가?
dependency graph, provenance, invalidation, partial recomputation을 agent decision과 연결해야 한다.
§10 · A plausible system synthesis
Research synthesis derived from the tracking note\[\text{Agent Feature Decision}+\text{OmniTable Data Substrate}+\text{Memory/Provenance}+\text{Cost-based Optimizer}\Longrightarrow\text{Self-evolving AI Data Pipeline}\]
여기서 self-evolving은 모델이 스스로 코드를 무제한 변경한다는 뜻으로 쓰지 않는다. 새로운 data source와 feature request가 들어올 때 dependency와 provenance를 바탕으로 필요한 계산을 결정하고, 이전 asset을 재사용하며, 결과를 다시 versioned asset으로 축적하는 지속적 데이터 준비의 폐루프를 뜻한다.
§11 · Tracking boundary
What was excluded
2026년 9월 2일 공개된 Git4Data: Database-Native Version Control for AI Agents 같은 신규 arXiv 연구는 흥미롭지만, 첨부 자료 확인 시점에 SIGMOD/PVLDB/VLDB/ICDE 게재가 확인되지 않았기 때문에 이번 venue-focused 업데이트에서는 제외되었다. 또한 SIGMOD·ICDE에서 이전 실행 이후 새로 확정된 동급의 LLM/data-agent acceptance도 발견되지 않았다.
이번 업데이트의 가장 중요한 결론은 단순하다. Data Agent 시대의 핵심 DBMS 연구대상은 agent가 생성하는 SQL만이 아니라, agent가 계속해서 사용할 data asset의 dependency·version·lineage·reuse를 산업 규모에서 어떻게 관리할 것인가이다.
Primary Sources
Official references
01
VLDB 2026 Conference Awards
Official award page02
OmniTable: A Unified Wide-Table System for Petabyte-Scale LLM Data Curation and Exploration
Official PVLDB PDFSource boundary
본 게시물은 첨부된 DB-Agent 연구추적 메모의 전체 내용을 웹 읽기 흐름으로 재구성했다. Best Industry Paper 상태, 35 PB+, 14일→2.5일, 5.6×, OmniTable의 기능 목록과 연구적 연결은 첨부 자료가 명시한 범위 안에서만 사용했다. self-evolving AI data pipeline은 첨부 자료가 제시한 연구방향을 설명하기 위한 분석적 synthesis이며 OmniTable 논문 자체의 추가 실험결과로 제시하지 않는다.