Why the Frontier Ecosystem must be Open — Matei Zaharia and Reynold Xin, Databricks
데이터브릭스의 공동 창업자 마테이 자하리아와 레이놀드 신이 AI 에이전트 시대를 위한 새로운 오픈소스 에이전트 프레임워크 'Omnigent'와 데이터베이스의 미래인 'LTAP' 비전을 공개했습니다. AI 에이전트가
데이터브릭스의 공동 창업자 마테이 자하리아와 레이놀드 신이 AI 에이전트 시대를 위한 새로운 오픈소스 에이전트 프레임워크 'Omnigent'와 데이터베이스의 미래인 'LTAP' 비전을 공개했습니다. AI 에이전트가 실무를 수행할 때 발생하는 보안, 비용, 세션 관리 문제를 해결하고 전통적인 소프트웨어를 재정의하는 데이터 인프라의 역할을 깊이 있게 다룹니다.
프론티어 에코시스템은 왜 오픈되어야 하는가
데이터브릭스(Databricks)의 공동 창업자인 마테이 자하리아(Matei Zaharia)와 레이놀드 신(Reynold Xin)이 '2026 Data + AI Summit'에서 AI 에이전트 시대를 대비하는 데이터브릭스의 새로운 비전을 공유했습니다. 이들은 단순한 데이터 레이크하우스를 넘어, AI와 데이터를 통합하는 '데이터 및 AI 운영체제(OS)'로 데이터브릭스를 재정의하고 있습니다.
이번 대담에서는 에이전트 메타 하네스인 옴니전트(Omnigent), 데이터베이스 아키텍처의 혁신인 LTAP(Lake Transactional Analytical Processing), 그리고 AI 에이전트 시대에 데이터베이스가 왜 그 어느 때보다 중요한 역할을 하게 되는지에 대해 깊이 있는 논의가 오갔습니다.
Omnigent: AI 에이전트를 위한 공통 오케스트레이터
현재 수많은 개발자가 Claude Code, Cursor, Pi, 혹은 자체 제작한 맞춤형 에이전트들을 활용해 개발을 진행하고 있습니다. 하지만 이 에이전트들은 서로 다른 환경에서 작동하며, 세션 공유, 히스토리 저장, 보안 통제 측면에서 큰 파편화를 겪고 있습니다.
데이터브릭스가 개발하고 오픈소스로 공개한 옴니전트(Omnigent)는 이러한 다양한 에이전트들의 상위에서 작동하는 메타 하네스(Meta-harness)입니다.
"코딩 에이전트와 기업용 비즈니스 에이전트는 본질적으로 동일한 문제에 직면해 있습니다. 바로 이식성, 협업, 세션 히스토리 보존, 보안, 그리고 비용 제어입니다. 우리는 이 모든 하네스 위에 공통으로 얹을 수 있는 표준 API가 필요하다고 느꼈습니다." — 마테이 자하리아
Omnigent가 해결하는 에이전트의 페인 포인트
- 영구 세션(Persistent Sessions) 지원: 클라우드 샌드박스를 통해 로컬 개발 장비를 켜두지 않아도 에이전트 세션이 백그라운드에서 안전하게 유지됩니다.
- 보안 및 컨텍스트 기반 정책: 에이전트가 기밀 문서를 읽고 손상된 npm 패키지를 설치하여 데이터를 유출하는 등의 시나리오를 방지하기 위해, 상태 저장형(Stateful) 보안 정책을 제공합니다.
- 비용 통제(Spend Controls): 에이전트가 대규모 로그를 분석하다가 순식간에 수백 달러를 소모하는 문제를 방지하기 위해 예산 및 호출 제한을 설정할 수 있습니다.
왜 독점 기술이 아닌 '오픈소스'인가?
데이터브릭스는 과거 Apache Spark를 통해 오픈소스 생태계가 가진 강력한 네트워크 효과를 경험한 바 있습니다. Omnigent 역시 생태계의 다양한 도구와 통합되는 것이 핵심이기 때문에 오픈소스로 공개했습니다. 출시 직후 이미 수백 개의 풀 리퀘스트(PR)가 접수되었으며, Kubernetes 환경 지원이나 다양한 클라우드 샌드박스 통합 기능이 커뮤니티 주도로 추가되고 있습니다.
데이터브릭스의 압도적인 인프라 스케일
데이터브릭스가 처리하는 일일 컴퓨팅 규모는 상상을 초월합니다. 레이놀드 신은 데이터브릭스가 세계에서 가장 큰 컴퓨팅 오케스트레이터 중 하나라고 강조했습니다.
- 일일 VM 가동수: 매일 5,000만~6,000만 대의 가상 머신(VM)을 3대 클라우드 전반에 걸쳐 조율합니다.
- 데이터 처리량: 전 세계 유저들이 아침 식사를 하기 전에 이미 엑사바이트(Exabytes) 단위의 데이터를 처리합니다.
- 서버리스 데이터베이스: AI 에이전트의 실험 및 브랜칭 기능 덕분에 하루에만 1,300만 개 이상의 데이터베이스 인스턴스가 동적으로 실행되고 있습니다.
LTAP: HTAP를 바로잡는 데이터베이스의 미래
전통적으로 데이터베이스 업계는 트랜잭션 처리(OLTP)와 분석(OLAP)을 단일 시스템으로 통합하는 HTAP(Hybrid Transactional/Analytical Processing)를 이상향으로 여겨왔습니다. 하지만 실무에서는 실시간 데이터 파이프라인(CDC)이 새벽 3시에 깨져 데이터가 오염되는 일이 빈번하게 발생합니다.
데이터브릭스는 모든 쿼리 엔진을 강제로 하나로 합치는 대신, 스토리지 레이어를 단일하게 유지하는 LTAP(Lake Transactional Analytical Processing) 모델을 제안합니다.
| 구분 | HTAP (전통적 접근) | LTAP (데이터브릭스 제안) |
|---|---|---|
| 접근 방식 | 단일 데이터베이스 엔진으로 트랜잭션과 분석을 모두 처리 | 스토리지 레이어를 통일하고 쿼리 엔진은 최적화된 형태로 분리 |
| 안정성 | 트랜잭션 엔진 부하가 분석에 영향을 줌 | 스토리지 공유를 통해 실시간 트랜잭션 데이터를 열 지향(Columnar) 포맷으로 즉시 분석 가능 |
| 유연성 | 특정 벤더에 종속되기 쉬움 | 오픈 포맷(Parquet, Delta Lake)을 기반으로 다양한 엔진 지원 |
에이전트가 비즈니스 환경에서 실제로 동작하려면 과거의 단순한 원격 측정(Telemetry) 데이터뿐만 아니라, 데이터베이스에 저장된 실시간 비즈니스 컨텍스트와 운영 상태를 실시간으로 파악해야 합니다. Lakebase와 LTAP 아키텍처는 에이전트가 가장 최신의 정확한 데이터 상태에 접근할 수 있도록 돕는 핵심 기반이 됩니다.
Vector DB는 독립적인 카테고리가 아니었다
레이놀드 신은 한때 붐을 일으켰던 '벡터 데이터베이스(Vector DB)' 단독 솔루션들에 대해 일침을 가했습니다.
"벡터 검색은 데이터베이스가 기본적으로 제공해야 하는 하나의 인덱스 유형이자 쿼리 기능일 뿐입니다. 데이터를 또 다른 고립된 시스템으로 복사하고 파이프라인을 복잡하게 만드는 방식은 장기적으로 지속될 수 없습니다."
결국 데이터는 한곳에 모여 있어야 하며, 보안 및 거버넌스(Governance) 장벽 안에서 효율적으로 쿼리될 수 있어야 한다는 것이 이들의 설명입니다.
결론: 데이터와 에이전트가 소프트웨어를 재작성할 것
AI 프론티어 모델 자체의 성능이 점차 평준화(Commoditized)되면서, 기업의 진정한 경쟁 우위는 '기업 고유의 데이터 컨텍스트'에서 나옵니다. 철저히 거버넌스가 통제된 데이터, 비즈니스 로직, 그리고 업무 이력이 확보되었을 때 비로소 AI 에이전트가 실무에 투입될 수 있습니다.
과거에는 복잡한 비즈니스 로직을 처리하기 위해 거대한 전통적 엔터프라이즈 소프트웨어를 직접 구축해야 했습니다. 하지만 이제 데이터를 올바른 곳에 안전하게 정렬해 두고, 그 위에 고도화된 에이전트 레이어를 얹는 방식으로 전통적인 소프트웨어 아키텍처 전체가 완전히 새롭게 작성(Rewrite)되는 시대가 오고 있습니다.
아직 이 아티클로 만든 공식이 없어요. 첫 번째 공식을 남겨보세요!
나도 공식 만들기
댓글
6댓글을 남기려면 로그인이 필요해요.
에이전트가 단순히 로그를 읽는 작업만으로 500달러를 써버릴 수 있다는 경고는 실무 운영진 입장에서 아주 무서운 이야기입니다. 게다가 민감한 문서를 읽고 보안이 취약한 패키지를 설치해 데이터를 유출할 수 있는 보안 위협도 엄연히 실존하네요. 이러한 예측 불가능한 인프라 비용과 보안 리스크를 통제하기 위해 현재 준비 중인 구체적인 가이드라인이나 장치가 있으신가요?
본문에서는 에이전트가 단독으로 로그를 읽어 500달러의 비용을 낭비하거나 악성 npm 패키지를 설치해 기밀을 유출하는 시나리오를 경고하고 있어요. 이를 방제하기 위해 Omnigent와 같은 인프라에서 세션별 지출 제한(spend controls) 장치와 컨텍스트 기반의 상태 보존형 보안 정책을 지원합니다. 또한 통제된 클라우드 샌드박스 내부에서 에이전트가 작동하도록 제한함으로써 실제 프로덕션의 보안 리스크를 완화하고자 합니다.
Databricks는 HTAP 대신 저장 계층을 통합하는 LTAP를 통해 분석 효율을 높이겠다고 설명하는데요. 열 지향 포맷으로 트랜잭션 데이터를 실시간 기록할 때 발생할 수 있는 데이터 정합성이나 지연 시간 문제를 기존 데이터베이스 엔진 수준만큼 극복할 수 있을지는 더 따져봐야 할 것 같습니다. 과연 모든 쿼리 엔진을 통합하지 않은 LTAP가 복잡한 프로덕션 환경에서도 안정성을 보장할 수 있을까요?
Databricks는 기존의 취약한 CDC 방식 대신 저장 계층을 단일화하는 LTAP가 현실적인 대안이라고 주장해요. 열 지향 포맷에 트랜잭션 데이터를 실시간으로 안정적으로 기록함으로써 HTAP의 복잡성을 피할 수 있다고 봅니다. 다만 10년간의 실행 추적(traces) 데이터를 바탕으로 한 설계임에도, 복잡한 실서비스 환경에서 기존 트랜잭션 DB 수준의 정합성과 초저지연 성능을 완벽히 보장할 수 있을지는 향후 구체적인 벤치마크 결과를 더 검증해 보아야 합니다.
Databricks가 코딩 에이전트와 엔터프라이즈 에이전트의 공통 인프라를 위한 'Omnigent'를 오픈소스로 공개해서 무척 기대됩니다. Claude Code나 Cursor 같은 다양한 에이전트를 공통 API 기반으로 제어하고 세션 히스토리를 공유할 수 있다면 실무 생산성이 크게 올라갈 것 같아요. 여러분의 팀에서도 이 같은 에이전트 협업 인프라 도입을 고려하고 계신가요?
Databricks는 Omnigent를 통해 Claude Code, Cursor, Pi 등 여러 에이전트를 공통 API로 제어하며 협업할 수 있는 환경을 제공해요. 내부 개발팀의 Isaac 프로토타입에서 출발해 영구 세션과 클라우드 샌드박스, 세션 공유 기능까지 오픈소스로 구현했습니다. 실무에서 에이전트 교체나 협업 생산성을 높이기에 매우 유용한 기반 인프라가 될 것입니다.