데이터베이스가 에이전트의 운영체제가 되기 시작했다

“에이전트”라는 명사는 이제 부족하다

SIGMOD 2026의 공식 accepted-paper 목록은 PACMMOD Round 1–4 구조를 유지하고 있으며, 현재 시점에서 새로운 acceptance round가 추가된 정황은 확인되지 않는다.[1] 그 사이 더 의미 있는 변화는 VLDB 2026에서 일어났다. 본행사를 앞두고 공개된 워크숍 프로시딩에는 Agentic Data Systems, Systems for Data-centric Agents with Human-in-the-loop, Agents+Graphs, Biomedical Data Management Systems, Composable Data Management Systems가 나란히 자리한다.[2][3]

표면만 보면 “LLM 에이전트가 유행한다”는 평범한 결론을 내릴 수 있다. 그러나 논문 제목을 한 단계 아래로 내려가 읽으면 다른 풍경이 보인다. ContextPipe는 컨텍스트 조립을 query execution처럼 다루고, AgentTrails는 실행 로그를 provenance graph로 바꾸며, DemandPrep은 데이터 정제를 action allocation 문제로 재정의한다. BioDMS에서는 임상 에이전트의 안전을 사후 필터가 아니라 constraint-first runtime으로 옮긴다. CDMS keynote는 아예 DBMS 코드를 에이전트가 합성하는 미래를 논한다.[6][8][7][10][11]

프롬프트는 문자열이 아니라 실행계획이다

장기 실행 에이전트는 매 턴마다 system prompt, tool schema, conversation history, retrieved memory, skill instruction, runtime identity를 한 번의 모델 호출에 담아야 한다. 문제는 단순한 길이가 아니다. context window라는 하드 예산이 있고, provider별 prefix cache가 있으며, 데이터의 volatility가 서로 다르다. 무엇을 남기고, 무엇을 압축하며, 어떤 순서로 배치할지 결정해야 한다.[6]

ContextPipe는 이 문제를 관계형 데이터베이스의 query execution과 구조적으로 닮았다고 본다. 그래서 에이전트 context assembly를 Plan → Bind → Optimize → Execute → Feedback의 다섯 단계로 나눈다. structured ContextSource catalog를 두고, deterministic cache-aware optimizer가 순서·압축·spill·cache marker를 결정하며, 결정 과정은 EXPLAIN ANALYZE 스타일 trace로 남긴다.[6]

초기 평가는 SWE-bench Pro의 Qutebrowser subset에서 수행되었다. 저자들은 append-only context construction과 비교해 total token volume 31%, LLM call 23%, response time 9%를 줄였다고 보고한다. 다만 KV cache-hit ratio가 낮아지는 비용도 함께 발생했다.[6] 이 마지막 문장이 중요하다. 좋은 연구는 비용 하나를 지우고 승리를 선언하지 않는다. 무엇을 아꼈고 무엇을 잃었는지 같이 적는다.

그래프를 많이 만들수록 좋은가

IBM 연구진의 How Much Structure Should Agentic Graph Memory Build for Text Retrieval?은 질문 자체를 잘 고른 논문이다. heavy event/schema-rich KG, lightweight entity-centric graph, model/prompt-optimized extraction, Wikidata-aligned construction, token-free graph, flat retrieval baseline을 같은 retrieval·reader 조건에서 비교하며, “검색 전에 구조를 얼마나 미리 만들 것인가”를 structure-boundary 문제로 정의한다.[9]

저자들이 보고한 핵심 결과는 양극단이 서로 다른 이유로 실패한다는 것이다. 구조를 지나치게 많이 만들면 downstream stack이 쓰지 않는 abstraction에 token budget을 소비하고, 그래프를 거의 없애면 multi-hop evidence composition이 약해진다. 검증된 설정에서는 prompt/model 최적화를 거친 lightweight entity-centric graph가 high-structure baseline보다 더 높은 answer quality를 보이면서 construction cost를 10배 이상 줄였다.[9]

로그는 시간 순서이고, provenance는 인과 구조다

에이전트의 tool call을 시간 순으로 저장하면 무슨 일이 일어났는지는 남는다. 하지만 왜 특정 artifact가 만들어졌고, 어떤 출력이 다음 행동의 입력이 되었으며, 여러 실행에서 어떤 패턴이 반복되었는지는 잘 보이지 않는다. AgentTrails는 이 약점을 정면으로 다룬다.[8]

AgentTrails는 raw trajectory를 structured provenance graph로 변환한다. tool call은 computational action, input/output은 data artifact가 된다. 여러 provenance graph를 shared canvas에 놓고 반복되는 tool·artifact·dependency structure를 정렬한 joined quotient graph를 만들며, 그 위에서 pattern extraction, downstream analysis, skill abstraction을 수행한다.[8]

이 흐름이 자리 잡으면 agent evaluation의 기본 단위도 바뀐다. 단순한 (prompt, response) 쌍으로는 장기 작업의 품질을 설명하기 어렵다. 앞으로는 task → tool calls → intermediate artifacts → dependency graph → result 전체가 하나의 평가 객체가 될 가능성이 크다.

정제의 강도는 단조롭게 효용을 높이지 않는다

기존 data cleaning pipeline은 이상한 값을 발견하면 수리하는 방향으로 움직이는 경우가 많다. 그러나 downstream task의 관점에서는 “의심스럽다”와 “바꿔야 한다”가 같은 말이 아니다. 드문 경계 사례를 고치다가 의미 있는 분포를 지울 수도 있고, 모든 cleaner를 적용하다가 유효한 row를 손상시킬 수도 있다.

DemandPrep은 upstream action allocation과 downstream operator-grounded execution을 분리한다. allocator는 candidate unit을 그대로 둘지, REPAIR·DELETE·REPLACE 같은 data-side action family로 보낼지 결정한다. executor는 reusable operator registry를 통해 실제 연산을 수행하고 provenance를 남긴다.[7]

논문은 5개 native-error dataset과 40개 mixed-error injected setting을 평가한다. 저자들은 DemandPrep이 대부분의 aggregate row에서 1위 또는 2위를 기록했고, 우세한 설정에서 strongest fixed cleaner 대비 상대 gain이 native row 6.8%, injected row 13.7%에 이른다고 보고한다. selective branch는 aggregate row 10개 중 6개에서 No-op보다 개선되었으며, validation 이후에는 No-op 아래로 내려가지 않았다.[7]

여기서 agentic하다는 말은 LLM을 한 번 더 호출한다는 뜻이 아니다. 행동 여부와 행동 강도를 task feedback으로 조정하는 의사결정 계층을 둔다는 뜻에 가깝다.

런타임 실패를 모델 실패로 오해하지 말 것

From Guardrails to Compilers는 임상 AI agent의 취약성을 “모델만 더 좋아지면 해결될 문제”로 보지 않는다. 저자들은 의료 agent의 substrate가 constraint enforcement, provenance tracking, policy-aware federation 같은 first-class data primitive를 갖추지 못한 것을 runtime failure로 본다.[10]

제안은 명료하다. tool call, retrieval, semantic operator, final recommendation을 모두 constrained, provenance-tracked query plan으로 compile한다. 임상 guideline의 computable subset, ontology axiom, federation-aware access policy를 하나의 specification으로 표현하고, safety·security·auditability가 “나중에 검사되는 성질”이 아니라 plan construction에서 성립하도록 만든다.[10]

이 설계는 의료에만 갇히지 않는다. 신약개발, 자율 실험실, AI Co-Scientist처럼 잘못된 tool call 하나가 비용과 과학적 결론을 함께 흔드는 환경에서는 constraint-aware planner + provenance-aware executor + evidence validator + policy-aware data layer가 모델 크기와 별개의 핵심 연구축이 될 수 있다. 다만 이것은 현재 논문들이 완전히 입증한 결론이 아니라, 여러 시스템 설계에서 공통으로 읽히는 연구적 추론이다.

옵티마이저의 자동화에서 시스템 코드의 합성으로

Immanuel Trummer의 VLDB 2026 CDMS keynote Towards AI-Generated Database Management Systems는 Claude Code 같은 현대적 code-generation framework가 C/C++ 규모의 코드베이스 생성도 실용적 수준으로 끌어올렸다는 배경에서 출발한다. 발표의 중심 사례인 GenDB는 target database, workload, hardware 특성에 맞춘 complex SQL processing code를 생성하는 multi-agent system으로 소개된다.[11]

중요한 것은 “LLM이 DBMS 전체를 곧 대체한다”는 식의 과장이 아니다. 실제로 더 흥미로운 질문은 어떤 operator·kernel·storage reader·query-processing path가 자동 합성의 적절한 단위인가이다. 같은 CDMS 프로그램에 Synthesizing Database Kernels, The AI Frontier for Composable Data Systems, Agentic Regeneration of High Performance Storage Readers와 같은 주제가 모이는 것은 우연으로 보기 어렵다.[3]

이 화살표를 역사적 필연으로 읽으면 곤란하다. 자동 생성된 코드의 correctness, performance portability, regression, security, maintenance는 여전히 거대한 문제다. 그러나 연구 단위가 knob와 plan을 넘어 code artifact로 이동했다는 사실 자체는 분명한 신호다.

현재 시점에서 무엇이 새롭고, 무엇은 아직 기다려야 하는가

SIGMOD 2026은 이미 종료되었고, 공식 accepted-paper 페이지에는 기존 Round 1–4 논문이 유지되고 있다.[1] 반면 VLDB 2026은 8월 31일–9월 4일 보스턴에서 열릴 예정이며, 본행사 프로그램과 워크숍 프로시딩이 구체화되면서 agentic data systems의 세부 연구문제가 명확해졌다.[2][3]

ICDE 쪽에서 다음 큰 변화가 예상되는 지점은 ICDE 2027 Research Track 1차 결과다. 공식 일정상 1차 author rebuttal은 8월 8–15일에 진행되었고, accept/reject notification은 2026년 9월 10일 예정이다.[12] 따라서 지금 당장 ICDE 2027 accepted papers를 근거로 새로운 트렌드를 단정하는 것은 시기상조다.

Agent-Native Data System이라는 관점

현재의 연구를 하나의 식으로 압축하면 다음과 같이 볼 수 있다. 이것은 특정 논문이 제시한 공식 정의가 아니라, 이 글에서 여러 연구를 연결하기 위해 만든 분석적 프레임이다.

이 관점의 장점은 “에이전트가 똑똑한가”라는 모호한 질문을 시스템 연구가 다룰 수 있는 문제로 쪼갠다는 데 있다. context는 budget과 cache의 문제이고, memory는 physical design과 retrieval의 문제이며, provenance는 lineage와 reproducibility의 문제다. constraint는 policy와 transaction-like safety의 문제이고, execution은 optimizer와 runtime의 문제다.

데이터베이스 분야가 수십 년 동안 해 온 일은 결국 상태를 명시하고, 비용을 계산하고, 실행을 계획하고, 실패를 복구하고, 결과의 근거를 남기는 일이었다. 장기 실행 AI 에이전트가 필요로 하는 것도 놀랍도록 비슷하다. 새 기술의 이름이 달라졌다고 해서 오래된 원리가 쓸모없어지는 것은 아니다. 오히려 반대다. 복잡성이 커질수록 오래된 원리는 새로운 자리를 얻는다.

아직 ‘분야의 승리’를 선언할 때는 아니다

주의할 점도 분명하다. 이 글에서 강조한 여러 결과는 VLDB workshop paper 또는 preliminary evaluation에서 나온 것이다. 특히 ContextPipe의 평가는 특정 SWE-bench Pro subset에 기반하고, graph-memory 결과도 고정된 retrieval/reader 조건 아래에서 얻어진다. DemandPrep 역시 특정 data-preparation benchmark 설정의 결과다. 따라서 이들을 산업 전반의 일반 법칙으로 확대해서는 안 된다.

그럼에도 이 자료들이 가치 있는 이유는 숫자의 크기보다 문제를 정의하는 방식에 있다. context를 optimizer 문제로, memory를 physical-design 문제로, trace를 provenance 문제로, 안전을 compiler/runtime 문제로, data preparation을 action-allocation 문제로 바꾸는 순간 새로운 실험 설계와 시스템 primitive가 생긴다. 학술적 전환은 대개 바로 그 지점에서 시작한다.