서론

샌프란시스코에서 개최된 Databricks 주최의 Data + AI Summit 2026에 현지 참관하고 왔습니다. 방문객은 3만 명을 넘어섰으며, 174개국에서 사람들이 모이는 AI 계열 컨퍼런스로서는 최대 규모입니다.

이 기사에서는 첫날 오프닝 기조 강연에서 CEO인 Ali Ghodsi 씨가 이야기한 내용의 요약과, 평소 AI 에이전트를 만들고 있는 입장에서 Databricks의 제품군(product)이 강력하다고 느낀 점을 감상으로서 기재하고 있습니다.

제품명이나 상태(GA / Preview)는 집필 시점(2026년 6월 16일)의 정보입니다.

TL;DR

• CEO에 따르면 "AGI는 이미 와 있다. 부족한 것은 지능이 아니라, 사내 데이터를 AI에게 전달하는 'Context'"
• 문맥(Context)을 기업에서 사용하기 위해 넘어야 할 4가지 벽(Choice / Control / Cost / Context). 이것이 모든 제품을 관통하는 축
• 데이터 계층은 지난 1년 동안 착실히 전진 (Lakebase의 브랜칭, Iceberg V3 등)
• 비용과 통제를 하나의 면에서 잡는 것이 Unity AI Gateway
• 본래의 목적은 에이전트 제품(Agent Product)인 Genie. 사내 지식을 사전에 육성하는 Genie Ontology 위에 Genie One / Agents / ZeroOps가 올라감
• 만드는 입장에서 와닿았던 점은, '흩어진 데이터의 통합'과 '성장하는 프로덕트'를 제품의 중심에 두었다는 것

"AI는 이미 똑똑하다. 부족한 것은 'Context'"

강연의 주장은 처음 15분 만에 거의 다 설명되었습니다. 대략적으로 말하자면 다음과 같습니다.

AGI는 이미 와 있다. AI에게 지능의 문제는 없다. 문제는 Context다.

Ghodsi 씨는 최첨단 AI 모델이 Humanity's Last Exam의 절반 가까이를 풀 수 있다는 점을 예로 들며, "2009년에 우리가 정의한 AGI는 이미 달성했다"라고 단언했습니다.

이렇게 똑똑한 AI가 있음에도 불구하고, 사내 업무에는 전혀 침투하지 못하고 있습니다. 진짜 문제는 지능이 아니라고 그는 이어 말했습니다. 모두가 챗봇에 질문하거나 코딩 보조에 사용하고 있을 뿐, 에이전트가 수백 대가 자율적으로 작동하며 협력하는 것과 같은 세계에는 아직 도달하지 못했습니다. 그 원인은 사내에 잠들어 있는 방대한 데이터와 업무 지식을 AI에게 'Context'로서 전달하지 못하고 있기 때문이며, 이것이 모든 병목 현상(bottleneck)이라는 정리였습니다.

그리고 이를 기업에서 실현하기 위해서는 넘어야 할 4가지 벽이 있으며, 기조 강연에서는 이 4가지를 해결하기 위한 제품군(Product)을 소개했습니다.

Choice: 특정 데이터 형식이나 AI 모델에 종속(lock-in)되고 싶지 않다. 최강 모델의 수명은 이제 한 달 정도밖에 되지 않기 때문에 -
Control: 에이전트를 방치할 수는 없다. 통제·보안·감사가 필요하다 -
Cost: 내버려 두면 비용이 천정부지로 솟는다 (「한 분기에 1년 치 AI 예산을 다 써버렸다」는 고객의 이야기도 나왔습니다) -
Context: 사내에 흩어진 데이터와 지식을 AI가 사용할 수 있는 형태로 만든다

반대로 말하면, 이 4가지만 해결할 수 있다면 실제 업무는 Humanity's Last Exam처럼 어렵지 않고 간단한 부품의 조합에 불과한 것들뿐이기에, AI는 사내 업무의 대부분을 수행할 수 있다는 것이 Databricks의 견해입니다.

우선 전체상

강연은 이 4가지 벽을 해결하는 제품을 「데이터 → 거버넌스(governance) → Context → 에이전트 → 앱」 순으로 아래에서부터 쌓아 올리는 형태로 진행되었습니다.

앱 계층 Databricks Apps / Lakewatch / Customer Data Platform
에이전트 계층 Genie One / Agents / Code / ZeroOps / Agent Bricks
Context 계층 Genie Ontology (사내 지식의 그래프)
...

데이터 계층 주변은 지난 1년 동안 조용하지만 착실하게 발전하고 있었습니다.

• 데이터 수집(Ingestion)을 위한 LakeFlow는 커넥터가 100개 이상으로 늘어나, Kafka 없이도 데이터를 직접 흘려보낼 수 있습니다.
• Zerobus가 GA(General Availability)에 도달했습니다. Spark는 실시간 모드에서 레이턴시(Latency)가 10ms까지 단축되었습니다.
• 파일 포맷(File Format) 전쟁으로 계속 화제가 되었던 Delta와 Iceberg도, Iceberg V3를 통해 데이터의 실체를 공유할 수 있게 되면서, Databricks 상에서는 둘 다 동일하게 다룰 수 있는 단계에 가까워지고 있습니다. (단상에 Iceberg의 창시자인 Ryan Blue가 등장하여 "포맷 따위는 신경 쓰지 않아도 되는 세상을 만들자"라고 말한 것이 인상적이었습니다.)

개인적으로 흥미로웠던 것은 Lakebase입니다. Postgres 호환 데이터베이스를 레이크(Lake) 위에 올린 것으로, 거대한 DB라도 1초도 걸리지 않고 클론(Clone)할 수 있는 "브랜칭(Branching)" 기능을 사용할 수 있습니다. Git의 브랜치처럼 데이터베이스를 가지치기하여, 에이전트가 마음껏 실험하게 하고, 결과가 좋지 않으면 되돌리는 방식의 활용이 상정되어 있었습니다. 병렬 에이전트를 전제로 한 새로운 시대의 DB 설계라는 느낌을 받았습니다.

이하에서는 특히 눈여겨보았던 거버넌스(Governance) 계층과 AI 에이전트 제품(AI Agent Product)인 Genie를 심층적으로 살펴보겠습니다.

비용과 통제를 한꺼번에 잡는 Unity AI Gateway

에이전트를 실제로 구동하기 시작하면, 의외로 금방 "비용이 보이지 않고, 멈출 수 없다"라는 벽에 부딪히게 됩니다. 어떤 에이전트가, 어떤 모델을 사용하여, 무엇에 얼마만큼의 토큰(Token)을 소모했는지 파악하기 어렵습니다. 정신을 차려보면 예산을 모두 써버리는 상황이 발생할 수 있습니다.

이에 대한 Databricks의 해답이 Unity AI Gateway였습니다. Unity Catalog의 일부로 제공되는, AI를 위한 검문소와 같은 것으로, 사내의 모델, 에이전트, MCP, 코딩 도구를 한곳에 집약하여 통치합니다. 게다가 "누가 어디에 접근할 수 있는가"뿐만 아니라, "무엇을 해도 되는가"까지 깊숙이 개입하여 제어하는 사상으로 설계되었다고 합니다.

비용 측면에서는 토큰 단위로 누가 얼마를 사용했는지 안분(Allocation)하여, 사용자별로 예산과 상한선을 설정할 수 있습니다. 한도를 초과하면 자동으로 중단할 수 있으며, 태스크에 따라 저렴한 모델과 높은 모델을 똑똑하게 배분하는 라우팅(Routing) 기능도 포함되어 있습니다. 통제 측면에서는 SQL로 "이 작업은 허용, 이것은 거부, 이것은 승인이 필요함"과 같이 정책을 작성할 수 있는 service policies (Beta)와, 입출력을 LLM으로 감시하는 가드레일(Guardrail)이 마련되어 있었습니다. 상호작용은 MLflow의 트레이싱(Tracing)을 통해 전부 기록되며, 수상한 움직임은 보안용 Lakewatch로 추적할 수 있게 되어 있었습니다.

솔직히 기능의 세밀함 자체는 공식 문서를 읽으면 알 수 있는 내용이지만, 비용과 통제를 "동일한 하나의 면"에서 잡을 수 있다는 설계 사상이 은근히 크다고 생각했습니다. 후반부의 소감에서 조금 더 다루겠습니다.

에이전트를 지속적으로 똑똑하게 만드는 메커니즘

개인적으로 가장 몰입했던 섹션은 이 에이전트 제품 발표 부분이었습니다. Databricks가 보유한 에이전트인 Genie에서는 AI 자체를 똑똑하게 만드는 것이 아니라, AI에게 전달할 컨텍스트(Context)의 설계를 철저하게 연마하고 있었습니다.

그 중심이 Genie Ontology입니다. 요즘의 에이전트는 질문을 할 때마다 사내 문서를 그 자리에서 뒤지러 갑니다. 링크를 따라가고, 또 다른 문서를 읽고... 이렇게 끝없이 루프를 돌기 때문에 느리고, 비용이 많이 들며, 정확도도 떨어집니다. Ghodsi 씨는 이를 "파일 이름을 바꿔달라고 부탁했더니 10분이 걸리고 5달러가 청구되었다"라는 농담으로 표현했습니다.

Genie Ontology는 이러한 탐색을 중단시킵니다. 미리 백그라운드에서 사내 데이터, 문서, 태그, 앱, 그리고 "누가 어떤 정보를 자주 접하는가"라는 사람의 정보까지 포함하여 지식 그래프(Knowledge Graph)를 구축해 둡니다. 게다가 이것은 사용될수록 성장하는 구조입니다. 중요도 계산에는 웹 세계에서 Google이 수행했던 PageRank의 사내 버전 같은 OntoRank라는 알고리즘을 사용한다고 합니다. 연결 대상도 Lakehouse나 DB뿐만 아니라 Google Drive, SharePoint, 이메일, 캘린더까지 포함합니다.

이 Context (문맥) 위에 올라타는 것이 Genie의 에이전트 군단입니다. Genie One은 전 직원이 사용할 수 있는 'AI 동료(라고 표현했습니다)'입니다. 기존의 Genie가 Databricks 내의 데이터만 볼 수 있었던 것과 달리, 이제는 사내외 데이터, 구조화/비구조화 데이터, 분석/운영 데이터를 가로질러 접근할 수 있게 되었습니다. 데이터 기반의 강력한 권한을 모든 사람에게 배포하지 않아도, 비즈니스 사용자가 안전하게 질문할 수 있으며, 모바일 앱도 제공되어 스마트폰으로 사용할 수 있다는 점이 인상적이었습니다.

Genie Agents는 자신의 대화를 그대로 재사용 가능한 에이전트로 만들어 팀에 배포할 수 있는 메커니즘입니다. '인사 문서에 답변하는 담당자'를 만들어 전사에 배포하는 것과 같은 일을 비엔지니어(Non-engineer)도 할 수 있습니다.

그리고 엔지니어 관점에서 가장 든든하다고 느낀 것은 Genie ZeroOps (Summit 이후 Private Preview 예정)였습니다. 이것은 운영을 대신해 주는 상주 에이전트입니다. 심야에 파이프라인 (Pipeline)이 중단되면, 스스로 먼저 이를 감지하고, Unity Catalog의 리니지 (Lineage)를 추적하여 원인을 특정하며, 수정 코드까지 작성해 줍니다. 게다가 이를 곧바로 운영 환경에 적용하는 것이 아니라, 제로 카피 (Zero-copy)로 복제한 샌드박스 (Sandbox) 내에서 실제 데이터로 테스트한 뒤, 문제가 없으면 알림을 보내줍니다. 그다음 인간이 내용을 확인하고 승인하기만 하면 되는 흐름이었습니다. 이것이 정말 높은 정밀도로 구현된다면, 데이터 기반 운영을 해본 사람이라면 누구라도 매력을 느낄 제품 (Product)이 될 것이라고 생각했습니다.

에이전트를 만들어온 입장에서 느낀 Databricks의 강점

여기서부터는 평소 에이전트 기능을 구현하고 있는 입장에서의 소감입니다.

한 가지는, '지능이 성장하는 제품'의 어려움에 정면으로 맞서고 있다는 느낌을 받았습니다.

제가 에이전트를 제품 (Product)으로 만들 때 가장 고생했던 점은 결국 두 가지였습니다. 하나는 여기저기 흩어진 데이터를 어떻게 통합하여 에이전트에게 전달할 것인가 하는 점입니다. 다른 하나는 사용할수록 자율적으로 학습하여 메모리 (Memory)나 Context (문맥)를 쌓아가며 '성장하는' 제품으로 만들 수 있는가 하는 점입니다.

특히 후자가 본질이라고 생각합니다. 왜냐하면 성장하지 않는다면 굳이 우리가 직접 만들 이유가 거의 없기 때문입니다. 매번 백지 상태에서 시작해야 한다면 범용 모델 (Foundation Model)을 그대로 호출하는 것으로 충분합니다. 자사의 Context를 쌓아가며 사용할수록 똑똑해지기 때문에 비로소 제품으로서 존재 가치가 생깁니다. 이 부분을 만들어낼 수 있느냐에 따라 에이전트의 가치가 결정된다고 느껴왔습니다.

이번 Databricks는 바로 그 지점을 하나의 철학으로 묶어내고 있었습니다. 성장하는 Context로서의 Genie Ontology, 흩어진 데이터를 모으는 Lakehouse와 Lakebase를 토대로 한 에이전트의 메모리 (Memory). 이것들은 별개의 기능이 아니라, '에이전트가 사용할 데이터를 어떻게 만들고, 어떻게 키우며, 어떻게 전달할 것인가'라는 일관된 설계로 이어져 있었습니다. 모델 그 자체가 범용화 (Commodity)되어 가는 상황 속에서, 정말 차이를 만드는 것은 전달하는 Context의 질이라는 점을 다시 한번 느꼈습니다.

또 다른 하나는 비용 문제입니다.

지금은 아직 구독형 (Subscription) 방식으로 토큰 (Token)을 비교적 넉넉하게 사용할 수 있습니다. 하지만 이것이 결국 사용량 기반 과금 (Pay-as-you-go) 방식으로 기울어지는 것은 피할 수 없다고 생각합니다. 그렇게 되었을 때 요구되는 것은, 태스크 (Task)의 난이도나 요구되는 품질에 따라 모델을 구분하여 사용하고, 각각에 과하거나 부족함이 없는 메모리 (Memory)와 Context를 전달하는 운영입니다. 간단한 태스크에 최상위 모델과 전체 Context를 사용한다면 예산을 순식간에 낭비하게 될 것입니다.

이를 전제로, 우선 '어디에서 무엇에 얼마를 쓰고 있는지'가 가시화되어야 하며, 상한선이나 라우팅 (Routing)을 제어할 수 있는 토대가 필요합니다. Unity AI Gateway처럼 비용과 통제를 동일한 측면에서 관리할 수 있는 기반을 조기에 확보해 두는 것은, 앞으로 서서히 차이를 만들어낼 것이라고 느꼈습니다.

마치며

거칠게 요약하자면, Databricks가 말하고자 한 것은 "AI의 지능은 이미 충분하다. 승부는 AI에게 전달하는 데이터와 Context의 질에서 결정된다"는 것이었습니다. 사내에 흩어진 정보를 모아 에이전트가 사용할 수 있는 형태로 정돈하고, 비용과 통제까지 일관되게 관리한다. 그 '에이전트가 사용할 수 있는 데이터 기반'을 통째로 제공하는 것이 앞으로 Databricks가 지향하는 방향성이라는 생각이 들었습니다.

참석하면서 가장 깊이 공감했던 점은, 제가 현장에서 줄곧 애를 먹어왔던 '데이터 통합 (Data Integration)'과 '성장하는 메커니즘 (Mechanism for growth)'을 제품의 핵심에 제대로 배치했다는 것이었습니다. 솔직한 소감으로는, 바로 이 지점에서 경쟁력을 느꼈습니다.

참고

• Introducing Genie One, Genie Agents, and Genie Ontology | Databricks Blog
• Introducing Genie ZeroOps: Put your data and AI operations on autopilot | Databricks Blog
• What's new in Unity AI Gateway | Databricks Blog
• Unity AI Gateway | Databricks Documentation
• Databricks Announces OpenSharing | Databricks
• Agent Bricks: Data + AI Summit 2026 | Databricks Blog
• Data + AI Summit 2026 공식 사이트

Discussion