Databricks, 품질과 비용 면에서 데이터 에이전트가 범용 코딩 에이전트를 앞선다고 밝혀

Databricks는 실제 작업 401건에서 자사의 데이터 에이전트가 세 개의 주요 코딩 에이전트를 앞섰으며, 도구 호출 횟수와 운영 비용도 더 적었다고 밝혔다. 이 결과는 에이전틱 AI에 관한 흔한 가정에 이의를 제기한다. 더 많은 탐색, 재시도, 토큰이 언제나 더 나은 답변으로 이어지는 것은 아니다.

Databricks의 핵심 논지는 순수한 모델 역량보다 컨텍스트에 있다. Genie Code는 자신이 작동하는 환경의 상당 부분을 이미 이해한다. 반면 범용 코딩 에이전트는 시간이 흐르는 동안 그 환경을 재구성해야 한다.

이 차이는 중요하다. 엔터프라이즈 데이터 업무는 깔끔한 저장소와 테스트 스위트에서 시작되는 경우가 드물기 때문이다. 에이전트는 올바른 테이블을 찾고, 비즈니스 언어를 해석하며, 계보를 살피고, 어떤 자산이 현재의 사실을 나타내는지 판단해야 한다. 코딩 에이전트도 Model Context Protocol을 통해 동일한 워크스페이스에 접근할 수 있지만, 여전히 대부분의 예산을 검색에 쓸 수 있다.

이에 따라 Databricks는 제품 벤치마크를 AI 아키텍처에 관한 더 폭넓은 주장으로 확장했다. 이 회사는 특화된 컨텍스트가 정확도를 높이는 동시에 리소스 소비를 줄일 수 있다고 주장한다. 이제 프런티어 모델을 기반으로 구축된 시스템을 포함한 범용 코딩 에이전트는 폭넓은 역량이 깊은 통합과 경쟁할 수 있음을 보여야 하는 압박을 받고 있다.

Databricks의 벤치마크가 토큰 경제에 도전하는 이유

Databricks는 Genie Code가 단순히 데이터 질문에 답했다고 보고한 것이 아니다. 품질과 계산 노력 사이의 통상적인 관계가 뒤집혔다고 보고했다.

회사의 에이전트 평가는 실제 내부 Genie Code 세션에서 추출한 독립형 작업 401건을 사용했다. 이 작업들은 데이터 탐색, 코드 생성, 쿼리 수정, 디버깅, 코드 설명, 정밀 조회를 다뤘다.

이는 작은 규모의 text-to-SQL 실험이 아니었다. 일부 작업에서는 답변을 구성하기 전에 관련 테이블, 노트북, 대시보드 또는 보조 문서를 찾아야 했다. 다른 작업에서는 실제 데이터 환경 내의 코드나 쿼리를 수정해야 했다.

Databricks는 모든 작업에 Genie Code와 이름을 공개하지 않은 세 개의 코딩 에이전트를 실행했다. 범용 에이전트는 자체 하니스와 주요 AI 연구소의 최신 모델을 사용했다. 이들 역시 AI 애플리케이션을 도구 및 데이터 소스에 연결하는 개방형 프로토콜인 MCP를 통해 Databricks에 접근할 수 있었다.

모든 시스템에는 작업당 동일하게 20분의 제한 시간이 주어졌다. 독립적인 평가자가 응답이 정확하고 유용한지를 평가했다. 제한 시간 초과는 실패로 처리됐다.

Genie Code의 정확도는 76.6%였다. 가장 근접한 코딩 에이전트는 72.1%에 도달했고, 나머지 두 에이전트는 각각 55.9%와 56.1%를 기록했다.

비용 패턴은 많은 구매자가 예상할 법한 방향과 반대로 움직였다. Genie Code는 가장 근접한 경쟁사 대비 작업당 약 절반만 소비했다. Databricks는 정답 하나당 비용도 해당 경쟁사 결과의 절반 미만이었다고 밝혔다.

이 두 결과는 함께 봐야 한다. 저렴하지만 틀린 결과물을 내는 에이전트는 유용한 효율성을 만든 것이 아니다. 반대로 예측할 수 없는 규모의 컴퓨팅 리소스를 소모하는 정확한 에이전트는 대규모 배포가 어려워질 수 있다.

보도에 따르면 Genie Code는 두 문제를 모두 피했다. 전체 작업 중 회사의 고비용 기준선을 넘은 비율은 16%에 불과했다. 범용 에이전트의 실행에서는 같은 일이 33~40%에서 발생했다.

Databricks는 차이를 수행한 행동의 수와 품질에서 찾았다. Genie Code는 작업당 평균 8.3회의 도구 호출을 기록해 비교 대상의 모든 에이전트보다 적었다. 한 사례에서는 다섯 번의 호출로 올바른 테이블을 찾아 답변을 완료했다.

범용 에이전트가 실패한 이유는 프런티어 모델에 접근하지 못했기 때문이 아니었다. Databricks는 모든 경쟁 시스템이 동일한 광범위한 역량 등급의 모델을 사용했다고 밝혔다. 이들이 실패한 것은 하니스가 워크스페이스 탐색을 길고 불확실한 검색 과정으로 만들었기 때문이라는 설명이다.

따라서 Databricks의 요지는 더 작거나 저렴한 모델이 갑자기 더 똑똑해졌다는 데 있지 않다. 올바른 시스템 아키텍처가 이미 알려진 컨텍스트를 다시 발견하는 데 써야 할 지능의 양을 줄였다는 것이다.

이 주장은 이 글의 핵심 긴장을 만든다. 깊은 컨텍스트가 오류와 리소스 소비를 일관되게 줄인다면, 모델 선택은 에이전트 품질의 한 부분일 뿐이다. 검색, 메모리, 메타데이터, 권한, 그리고 이를 둘러싼 제품 환경이 모델이 자신의 지능을 생산적으로 사용하는지를 결정할 수 있다.

범용 코딩 에이전트는 저장소 밖에서 압박을 받고 있다

범용 코딩 에이전트는 환경이 명시적인 파일, 정의된 목표, 테스트를 제공할 때 가장 강력하다. 엔터프라이즈 데이터 업무는 이 세 가지 이점을 모두 없애는 경우가 많다.

소프트웨어 이슈는 일반적으로 에이전트를 저장소, 실패한 동작 또는 요청된 변경 사항으로 안내한다. 에이전트는 코드를 살피고, 파일을 수정하고, 테스트를 실행할 수 있다. 이러한 테스트는 제안된 해결책이 작동하는지에 관한 비교적 명확한 신호를 제공한다.

데이터 요청은 “활성 계정의 매출”이나 “현재 고객 테이블” 같은 문구로 시작될 수 있다. 어느 문구도 하나의 명확한 객체에 반드시 대응하지는 않는다. 워크스페이스에는 오래된 대시보드, 중복 테이블, 실험용 노트북, 낯선 이름의 열이 있을 수 있다.

에이전트는 먼저 사용자가 무엇을 의미하는지 판단해야 한다. 이어 그 의미를 담고 있는 자산을 찾아야 한다. 마지막으로 어떤 버전을 신뢰해야 하는지 결정해야 한다.

이는 분석이 시작되기도 전에 탐색 문제를 만든다. 범용 코딩 에이전트는 테이블 목록을 조회하고 스키마를 검사할 수 있지만, 접근 권한만으로 조직이 선호하는 지표를 식별할 수는 없다. 또한 특정 대시보드가 지난 분기에 다른 대시보드를 대체했다는 사실도 알려주지 않는다.

MCP는 모델과 외부 시스템 간 연결을 표준화하는 데 도움을 준다. Anthropic의 프로토콜 문서는 MCP를 애플리케이션이 언어 모델에 컨텍스트와 도구를 제공하는 표준 방식으로 설명한다. 이는 중요한 통합 문제를 해결하지만, 통합이 자동으로 이해를 만들어내는 것은 아니다.

Databricks는 경쟁 에이전트에 MCP 접근 권한을 제공했으며, 이는 이 구분을 특히 중요하게 만든다. 이 벤치마크는 연결된 제품과 연결되지 않은 챗봇을 비교한 것이 아니다. 동일한 작업 환경에 대한 접근 권한을 활용하는 서로 다른 방식을 비교했다.

보도에 따르면 범용 에이전트들은 Databricks가 “무작위 보행 탐색”이라고 부르는 방식에 빠졌다. 이들은 자산을 검사하고, 쿼리를 실행하고, 부분적인 단서를 따라갔으며, 때로는 대규모 테이블을 제한 없이 스캔했다. 긴 검색은 토큰 사용량을 늘리고 시간 초과를 낳았다.

이런 행동은 이해할 수 있다. 에이전트에 신뢰할 수 있는 지도가 없을 때 탐색은 대안이 된다. 새로운 도구 결과마다 컨텍스트는 확장되지만, 더 많은 가능성과 모순도 함께 생길 수 있다.

더 긴 추론 기록이 반드시 더 많은 신호를 담는 것은 아니다. 중복된 스키마, 오래된 문서, 관련 없는 쿼리 출력, 이전 추측에서 생성된 추측이 포함될 수 있다. 이후 모델은 도메인 인지 시스템이라면 제외했을 자료를 분류하는 데 추가 토큰을 쓴다.

이 약점은 Databricks를 넘어선 의미를 가진다. 코딩 에이전트 공급업체들은 자사 제품을 광범위한 디지털 작업자로 점점 더 제시하고 있다. 데이터 엔지니어링, 분석, 대시보드 생성, 운영 조사 등은 자연스러운 확장 대상이다.

그러나 이러한 활동은 하나의 저장소에 존재하는 일이 드문 조직 지식에 의존한다. 그 지식은 카탈로그 설명, 쿼리 이력, 노트북, 문서, 대시보드, 대화, 숙련된 직원들의 업무 습관에 분산돼 있을 수 있다.

사람이 기술 자료를 검색할 때도 팀은 이미 같은 문제에 직면한다. 검색 가능한 지식 기반은 단순한 파일 접근이 아니라 관계와 컨텍스트를 보존할 때 유용해진다. 에이전트는 훨씬 더 큰 운영 규모에서 이와 유사한 요구를 마주한다.

이 벤치마크는 범용 코딩 에이전트에 해당 컨텍스트 계층을 개선하라는 압박을 가한다. 이들은 더 강력한 시맨틱 검색, 지속적인 워크스페이스 메모리, 풍부한 메타데이터 지원 또는 데이터 플랫폼과의 파트너십으로 대응할 수 있다.

전제 자체에 이의를 제기할 수도 있다. 동등하게 성숙한 컨텍스트 시스템에 연결된 범용 에이전트라면 격차를 좁힐 수 있다. Databricks는 독립적으로 비교를 재현하는 데 필요한 경쟁 제품, 모델, 프롬프트 또는 모든 구성 세부 사항을 공개하지 않았다.

그 불확실성이 결과를 지우는 것은 아니다. 오히려 경쟁사가 무엇을 입증해야 하는지 분명히 한다. 에이전트가 올바른 출발점을 찾는 데 그 역량을 반복해서 낭비한다면, 폭넓은 모델 역량만으로는 더 이상 충분하지 않다.

시맨틱 컨텍스트가 에이전트의 검색 문제를 바꾼다

Genie Code의 이점은 비용이 큰 탐색이 시작되기 전에 의사결정 공간을 좁히는 데서 나온다.

Databricks는 Genie Code를 분석, 데이터 엔지니어링, 디버깅, 파이프라인, 대시보드 생성을 위한 에이전트로 설명한다. 제품 문서에 따르면 이 시스템은 여러 Databricks 인터페이스에서 Unity Catalog 테이블, 열, 계보와 함께 작동한다.

Unity Catalog는 거버넌스 및 메타데이터 계층 역할을 한다. 데이터 자산과 구조, 관계, 계보, 접근 규칙을 기록한다. 이 정보는 Genie Code에 사용 가능한 테이블 목록 이상의 것을 제공한다.

에이전트는 정확한 텍스트가 아니라 의미를 기반으로 자산을 찾아내는 시맨틱 검색을 사용할 수 있다. 사용자는 공식 테이블 이름을 모른 채 고객 유지율을 요청할 수 있다. 시맨틱 검색은 그 요청을 조직의 유지율 로직과 연결된 테이블, 노트북 또는 대시보드에 연결할 수 있다.

지속적인 메모리는 또 다른 이점을 더한다. Databricks는 Genie Code가 사용자가 의존하는 테이블과 비즈니스 로직을 기억한다고 밝혔다. 이러한 메모리는 에이전트가 세션마다 같은 탐색 과정을 반복하지 않도록 할 수 있다.

깊은 엔터프라이즈 컨텍스트가 이 메커니즘을 완성한다. 비즈니스 용어는 팀마다 다른 정의를 지니는 경우가 많다. “활성 사용자”, “인식 매출”, “해결된 티켓”은 사전적 의미가 아니라 각각 내부 규칙에 따라 달라질 수 있다.

범용 코딩 에이전트도 쿼리와 문서를 통해 이러한 규칙을 추론할 수 있다. Genie Code는 폭넓은 추측을 하기 전에 작업 환경에서 이를 검색하도록 설계됐다.

이 메커니즘은 도구 호출이 줄어들면서 품질이 개선될 수 있는 이유를 설명한다. 호출 하나하나는 관련 없는 결과, 비효율적인 스캔 또는 잘못된 분기가 발생할 또 다른 기회를 만든다. 시스템이 필요한 검증을 건너뛰는 대신 저가치 탐색을 제거할 때 호출 감소는 유용하다.

이 탐색 과정은 지도 유무에 따른 길 찾기와 닮았다. 두 에이전트 모두 같은 워크스페이스를 이동할 수 있다. 한쪽은 목적지, 관계, 신뢰할 수 있는 경로에 관한 정보를 바탕으로 시작한다. 다른 쪽은 문을 열어보며 배치를 학습한다.

독립 연구는 이 문제가 더 넓게 중요하다는 점을 뒷받침한다. Data Agent Benchmark는 작업을 SQL 생성에만 한정하지 않고 이기종 시스템 전반의 데이터 업무를 평가한다. 연구진은 12개 데이터세트, 9개 도메인, 4개 데이터베이스 시스템을 아우르는 54개 쿼리를 구성했다.

해당 연구에서 가장 성능이 높은 프런티어 모델의 pass-at-one 정확도는 38%였다. 작업, 환경, 평가자가 다르므로 이 결과는 Databricks의 내부 평가와 직접 비교할 수 없다. 다만 처음부터 끝까지 이어지는 데이터 업무는 문법적으로 유효한 쿼리를 생성하는 것보다 여전히 훨씬 어렵다는 점을 보여준다.

최근의 또 다른 연구는 오픈 웹 검색과 메타데이터가 풍부한 데이터셋에서 작동하는 시맨틱 에이전트를 비교했다. 시맨틱 메타데이터 연구는 구조화된 검색이 실행 가능하고 기계가 읽을 수 있는 데이터에서 더 높은 정밀도를 보였다고 밝혔다.

기준 시스템은 더 많은 질문에 도달했지만, 사용 가능한 데이터셋 대신 산문형 페이지나 포털 랜딩 페이지를 반환하는 경우가 잦았다. 이러한 트레이드오프는 Databricks의 주장에 담긴 구분과 맞닿아 있다. 폭넓은 탐색은 커버리지를 늘릴 수 있지만, 결과가 실제 운영에 유용할 가능성은 낮출 수 있다.

엔터프라이즈 에이전트에서 관련 있는 무언가를 찾는 것만으로는 충분하지 않다. 선택된 자산은 접근 가능하고, 최신 상태이며, 거버넌스가 적용돼 있고, 의도한 연산과 호환돼야 한다.

Genie Code의 아키텍처는 이러한 기준을 중심으로 설계됐다. 에이전트는 계보를 검토하고, 사용자의 권한 범위 내에서 작업하며, 노트북, SQL, 파이프라인, 대시보드, 머신러닝 워크플로 전반에서 작동할 수 있다.

모델 역시 여전히 중요하다. 요청을 이해하고, 작업을 계획하며, 코드를 작성하고, 결과를 해석하고, 근거가 불완전한 시점을 알아차려야 한다. 다만 주변의 컨텍스트 시스템은 모델이 어떤 문제를 처음부터 해결해야 하는지를 결정한다.

이 때문에 이 벤치마크는 순수한 모델 경쟁이 아니라 아키텍처 비교로 읽는 것이 가장 적절하다. Databricks가 갑자기 모든 경쟁자를 앞선 새로운 파운데이션 모델을 공개한 것은 아니다. 대신 어려운 하나의 환경을 위해 구축한 컨텍스트 계층과 최첨단 모델을 결합했다.

이 접근법은 컴퓨팅의 다른 영역에서 나타나는 특화와 닮아 있다. 범용 프로세서는 다양한 워크로드를 실행할 수 있지만, 특화된 인덱스·컴파일러·스토리지 시스템은 특정 작업에 필요한 일을 줄여 준다. 기반 역량은 여전히 중요하지만, 실질적인 성능은 시스템 설계가 좌우한다.

에이전트에도 같은 논리가 적용된다. 더 큰 컨텍스트 윈도는 더 많은 스키마와 문서를 담을 수 있다. 하지만 어떤 스키마가 권위 있는지 판단하지는 못한다. 더 많은 추론 토큰은 더 긴 조사를 지속할 수 있게 한다. 그렇다고 조사가 올바른 근거에서 시작된다는 보장은 없다.

Genie Code는 토큰 소비가 늘어나기 전에 이러한 선택 문제를 해결하는 것을 목표로 한다. Databricks의 결과가 일반화된다면, 엔터프라이즈 에이전트의 효율성은 시스템이 이미 무엇을 알고 있는지에 점점 더 크게 좌우될 것이다.

Databricks의 수치가 입증하지 못하는 것

이 벤치마크는 신뢰할 만한 메커니즘을 뒷받침하지만, 특화 에이전트와 범용 에이전트 간의 경쟁에 종지부를 찍지는 않는다.

Databricks는 자체 내부 Genie Code 사용 사례를 바탕으로 평가 세트를 만들었다. 이 선택은 제품이 의도한 환경에서 과제를 현실적으로 만든다. 동시에 환경과 과제 분포가 자연스럽게 Genie Code의 설계와 맞아떨어진다는 뜻이기도 하다.

내부 벤치마크는 제품이 사용자의 업무를 처리하는지 보여줄 수 있다. 그러나 동일한 순위가 다른 기업, 플랫폼, 데이터 아키텍처에도 적용된다는 것을 자동으로 보여주지는 못한다.

세 개의 코딩 에이전트는 익명으로 처리됐다. 독자는 각 제품이 어떻게 구성됐는지, 어떤 특정 모델이 실행됐는지, 어떤 프롬프트가 이들을 이끌었는지, 혹은 해당 벤더가 다른 설정을 권장할지를 검토할 수 없다.

에이전트들은 각자의 하니스를 사용했으며, 이는 실제 제품 동작을 반영한다. 그러나 하니스 차이는 원인 귀속을 더 어렵게 만든다. 실패는 모델, 도구 선택 정책, 쿼리 안전장치, 컨텍스트 패키징 또는 타임아웃 관리에서 비롯됐을 수 있다.

독립 심사자 역시 또 하나의 불확실성을 더한다. Databricks는 응답을 정확성과 유용성 기준으로 채점했다고 밝혔지만, 기사에서 전체 과제 세트, 심사 프롬프트 또는 사람의 감사 절차를 공개하지는 않았다.

LLM 기반 평가는 수백 번의 실행에 걸쳐 평가를 확장할 수 있다. 동시에 과제 설명과 참조 답안에 내재한 모호성을 물려받을 수도 있다. 따라서 신뢰할 만한 벤치마크라면 다른 이들이 이견을 검토하고 평가를 반복할 수 있도록 충분한 세부 정보를 공개해야 한다.

기술 업계는 이미 코딩 벤치마크에서 이 문제에 직면하고 있다. OpenAI는 최근 감사 결과 SWE-Bench Pro에 중대한 문제가 발견됐다고 보고했다. 평가 감사는 검토한 과제 중 약 30%가 결함이 있었다고 추정했다.

이 결과가 Databricks의 벤치마크를 무효화하는 것은 아니다. 이는 벤치마크 구축이 모델 성능만큼의 엄밀한 검토를 받아야 하는 이유를 보여준다. 현실적인 과제에도 불충분하게 명시된 지시, 불완전한 참조 자료 또는 채점 공백이 있을 수 있다.

Databricks의 비용 추정치도 비슷한 주의가 필요하다. 회사는 이 수치가 추정 사용자 요금을 나타내며 상대적 관점에서 더 많은 정보를 제공한다고 말한다. 실제 배포 환경은 모델 선택, 공급업체 계약, 캐싱, 쿼리 실행, 플랫폼 제어에 따라 달라질 것이다.

공통의 20분 제한 역시 결과를 형성한다. 비교 가능한 테스트에는 시간 제한이 필요하지만, 이는 실행 가능한 경로를 빠르게 찾는 에이전트에 유리하다. 범용 에이전트는 더 엄격한 쿼리 제한, 더 긴 예산 또는 더 나은 워크스페이스 인덱스가 주어졌을 때 다른 성과를 보일 수 있다.

서로 다른 계층의 성숙도를 비교할 위험도 있다. Genie Code는 Databricks 네이티브 메타데이터와 제품 통합의 이점을 누린다. 범용 인터페이스를 통해 연결된 코딩 에이전트는 두 제품이 기술적으로 모두 워크스페이스에 접근할 수 있더라도 동일한 시맨틱 표현을 받지 못할 수 있다.

구매자 관점에서 이러한 비교가 불공정한 것은 아니다. 사용자는 실험실 수준의 추상적 동등성 아래 놓인 모델이 아니라 완성된 제품을 중요하게 여긴다. 다만 특화 자체가 격차의 모든 부분을 초래했는지에 관한 결론은 제한한다.

이 벤치마크는 Genie Ontology가 전 세계적으로 제공되지 않았다는 이유로 이를 비활성화했다. Databricks는 이 시스템이 비즈니스 개념과 관계를 정리함으로써 Genie Code를 강화할 것으로 기대한다. 고객이 이를 널리 사용하기 전까지, 그 추가 효과는 확립된 결과가 아니라 회사의 기대에 머문다.

보안과 거버넌스도 주목할 필요가 있다. 영속 메모리는 반복적인 탐색을 줄일 수 있지만, 저장된 컨텍스트는 최신 상태를 유지하고 권한을 인식해야 한다. 에이전트는 다른 사용자가 이전에 의존했다는 이유만으로 자산을 노출해서는 안 된다.

Databricks는 Genie Code가 Unity Catalog 권한을 따른다고 말한다. 구매자는 권한이 변경되거나, 테이블이 폐기되거나, 팀 간 지표 정의가 충돌할 때 메모리가 어떻게 동작하는지 여전히 테스트해야 한다.

낡은 시맨틱 컨텍스트는 확신에 찬 오류를 만들 수 있다. 범용 에이전트의 탐색적 행동은 비효율적이지만, 특화 검색 계층이 숨길 수 있는 모순을 드러낼 수 있다. 최선의 시스템은 목표 지향적 검색과 최신성 및 출처 검증을 결합해야 한다.

올바른 결론은 Databricks의 헤드라인보다 더 좁다. Genie Code는 회사의 평가 설계 아래 Databricks 내부 과제 분포에서 이름이 공개되지 않은 세 개의 코딩 에이전트를 앞섰다. 보고된 우위는 그럴듯하고 독립적으로 뒷받침되는 아키텍처 메커니즘과 일치한다.

이 결과가 모든 데이터 에이전트가 모든 코딩 에이전트를 이긴다는 사실을 증명하는 것은 아니다. 또한 범용 에이전트가 동등한 시맨틱 컨텍스트를 확보할 수 없다는 점도 보여주지 않는다.

이 구분이 중요한 이유는 예상되는 경쟁적 대응이 수렴이기 때문이다. 코딩 에이전트는 도메인 특화 메모리와 검색 기능을 추가할 것이다. 데이터 플랫폼은 에이전트를 더 광범위한 코딩 및 운영 업무로 확장할 것이다.

경쟁은 영구적으로 컨텍스트가 없는 범용 에이전트와 특화 제품의 대결로 남지 않을 것이다. 어떤 시스템이 엔터프라이즈 컨텍스트를 가장 효과적으로 구축하고, 업데이트하고, 거버넌스하며, 적용하는지를 겨루는 경쟁이 될 것이다.

비용과 품질은 같은 에이전트 문제가 되고 있다

Databricks의 가장 중요한 주장은 낭비되는 탐색이 같은 사건의 연쇄를 통해 정확도와 비용 모두를 악화시킬 수 있다는 것이다.

에이전트 경제성은 흔히 모델 가격 문제로 논의된다. 팀은 토큰 요금, 컨텍스트 한도, 개별 도구 호출 비용을 비교한다. 이러한 측정치는 중요하지만, 전체 과제에 걸친 에이전트의 행동을 포착하지는 못한다.

저렴한 모델도 불필요한 호출을 수십 번 수행하면 비용이 커질 수 있다. 더 뛰어난 모델도 하니스가 관련 없는 스키마와 실패한 쿼리 결과를 계속 제공하면 리소스를 낭비할 수 있다.

의미 있는 단위는 정확하고 유용한 결과 하나를 얻는 비용이다. Databricks는 품질과 소비를 결합하기 때문에 이 지표를 강조한다. 잘못된 테이블에 빠르게 도달한 에이전트는 절감 효과를 만들어낸 것이 아니다.

탐색 오류는 증폭될 수 있다. 에이전트는 먼저 취약한 후보 테이블을 선택한다. 이어 그 테이블을 대상으로 쿼리를 작성하고, 출력을 해석하고, 불일치를 발견한 뒤 다시 검색을 시작한다. 각 단계는 토큰을 소비하고 또 다른 잘못된 가정이 생길 가능성을 높인다.

대규모 스캔은 추가 위험을 만든다. Databricks는 범용 에이전트의 타임아웃이 대개 매우 큰 테이블에 대해 비효율적이고 제한 없는 쿼리를 실행한 뒤 발생했다고 말한다. 따라서 에이전트는 답을 내지 못한 채 모델 리소스와 데이터 컴퓨팅 리소스를 모두 소모할 수 있다.

시맨틱 컨텍스트는 이 비용 곡선을 상류에서 바꾼다. 에이전트가 쿼리 전에 신뢰할 수 있는 자산을 식별하면, 분석의 전체 분기를 피할 수 있다. 분기가 줄어들면 호출 수, 프롬프트 길이, 출력 크기, 수정 추론도 함께 줄어든다.

이 관계는 품질과 비용을 동일한 검색 문제의 두 가지 표현으로 만든다. 더 나은 근거 정립은 필요한 작업량을 줄인다. 작업량이 줄어들면 에이전트가 방향을 잃을 지점도 줄어든다.

따라서 엔터프라이즈 구매자는 최종 응답뿐 아니라 트레이스도 평가해야 한다. 가장 유용한 질문은 에이전트가 어떻게 출처를 찾았는지, 왜 이를 신뢰했는지, 몇 개의 대안을 살펴봤는지, 그리고 소비가 어디에서 누적됐는지에 관한 것이다.

성공적인 답변도 불안정한 프로세스를 드러낼 수 있다. 에이전트가 길고 무작위적인 탐색 끝에 올바른 결과에 도달했다면, 작은 워크스페이스 변경만으로도 다음 실행이 실패할 수 있다. 더 짧고 근거에 기반한 경로는 감사와 재현이 더 쉽다.

이 접근법은 팀이 컨텍스트 윈도를 바라보는 방식도 바꾼다. 답이 그 안 어딘가에 있을 수 있기 때문에 프롬프트에 더 많은 자료를 넣는 편이 안전해 보일 수 있다. 실제로 과도한 컨텍스트는 비용을 높이고 관련 근거를 구분하기 더 어렵게 만들 수 있다.

정제된 시맨틱 검색은 다른 경로를 제시한다. 메타데이터, 계보, 사용 패턴, 비즈니스 의미를 통해 선택된 더 작은 자산 집합을 모델에 전달한다. 그러면 모델은 워크스페이스 고고학이 아니라 과제 자체에 추론 예산을 쓸 수 있다.

이것이 검증을 없애는 것은 아니다. 데이터 에이전트는 여전히 최신성, 행 수, 쿼리 논리, 출처 간 충돌을 확인해야 한다. 목표는 발견 과정을 통제되지 않은 스캔으로 바꾸지 않고, 검증에 명확한 목적을 부여하는 것이다.

같은 원칙은 영속 메모리에도 적용된다. 선호 테이블을 기억하는 것은 그 메모리가 출처를 포함하고 워크스페이스와 동기화된 상태를 유지할 때에만 시간을 절약한다. 그렇지 않으면 어제의 지름길이 내일의 숨은 오류가 된다.

데이터 에이전트를 고려하는 조직은 메타데이터 품질을 AI 준비도의 일부로 봐야 한다. 부실한 카탈로그 설명, 중복된 지표, 방치된 대시보드, 문서화되지 않은 변환은 모델과 무관하게 모든 에이전트를 제약할 것이다.

특화 제품은 외부 에이전트가 보지 못할 수 있는 네이티브 신호를 활용할 수 있기 때문에 초기 우위를 가진다. 플랫폼 활동은 사람들이 어떤 자산을 사용하는지, 어떤 쿼리가 반복되는지, 데이터가 시스템 간에 어떻게 흐르는지를 보여준다.

범용 코딩 에이전트는 또 다른 장점을 유지한다. 모든 과제를 하나의 플랫폼에 억지로 넣지 않고도 리포지토리, 터미널, 클라우드 콘솔, 티켓, 서비스 전반에서 작업할 수 있다. 많은 실제 사고는 정확히 이러한 폭넓은 역량을 필요로 한다.

새롭게 부상하는 설계 과제는 폭넓은 행동력과 좁고 깊은 전문성을 결합하는 것이다. 에이전트는 시스템 전반을 이동하면서 각 단계에서 도메인 특화 컨텍스트 계층을 참조해야 한다. 제한 없는 탐색도, 고립된 특화도 모든 엔터프라이즈 워크플로를 해결하지는 못한다.

Databricks의 벤치마크는 이러한 미래의 한 측면을 포착한다. 이는 도메인 에이전트가 시맨틱 지도를 갖춘 워크스페이스에 들어가는 반면, 더 광범위한 에이전트는 범용 도구를 들고 도착할 때 어떤 일이 벌어지는지를 보여준다.

보고된 결과는 지도에 유리하게 작용한다. 다음 경쟁에서는 이 지도가 계속 플랫폼 우위로 남을지, 아니면 모든 본격적인 에이전트의 표준 구성 요소가 될지가 관건이 될 것이다.

세 가지 신호가 Databricks의 ‘왜’를 다음 단계에서 시험할 것이다

다음 단계는 재현성, 경쟁사 컨텍스트 시스템, 그리고 외부 고객의 증거에 달려 있다.

첫 번째 신호는 벤치마크 공개다. Databricks는 실제 작업을 기반으로 한 평가를 확대하고 결과를 계속 공개할 계획이라고 밝혔다. 공개적으로 이용 가능하거나 독립적으로 재현 가능한 일부 항목이 마련된다면 비교의 설득력은 훨씬 커질 것이다.

재현에는 작업 정의, 채점 기준, 에이전트 구성, 타임아웃 규칙, 소비량 산정 방식이 포함돼야 한다. 또한 기업 데이터 작업을 어렵게 만드는 모호성은 유지하면서 민감한 정보를 어떻게 제거했는지도 설명해야 한다.

독립 실행에서도 Genie Code의 품질과 효율성 우위가 유지된다면 Databricks의 논거는 더욱 강해진다. 반대로 구성이나 채점 방식에 따라 순위가 크게 바뀐다면, 현재 결과는 제품별 특정 조건에서 나온 스냅샷에 더 가까워 보일 것이다.

두 번째 신호는 범용 코딩 에이전트 공급업체들의 대응이다. 이번 테스트에서 MCP를 통한 접근은 Genie Code의 맥락적 우위를 없애지 못했다. 이제 경쟁사들은 단순히 도구를 노출하는 수준을 넘어, 데이터 자산을 이해하는 시맨틱 검색과 메모리를 갖춰야 한다.

카탈로그 메타데이터, 계보, 지표 정의, 쿼리 이력, 조직별 선호도를 수집하는 코딩 에이전트에 주목할 필요가 있다. 또한 이런 시스템이 변경되는 권한을 준수하고, 특정 소스를 선택한 이유를 설명할 수 있는지도 살펴봐야 한다.

동등한 시맨틱 계층을 제공받은 뒤 Genie Code와 맞먹는 성능을 내는 범용 에이전트가 등장한다면, 영구적으로 분리된 에이전트 범주가 필요하다는 주장은 약화될 것이다. 반면 컨텍스트 아키텍처가 무차별적인 토큰 사용보다 중요하다는 Databricks의 더 근본적인 주장은 강화될 것이다.

세 번째 신호는 Databricks 내부 세션 밖에서의 고객 성과다. 외부 배포 환경에는 더 복잡한 권한 체계, 부실한 메타데이터, 혼합된 플랫폼, 그리고 팀이 한 번도 문서화하지 않은 비즈니스 정의가 존재할 것이다.

가장 유용한 증거에는 작업 완료율, 타임아웃 빈도, 사람의 수정 비율, 도구 호출 분포가 포함될 것이다. 구매자는 데이터 탐색, 디버깅, 파이프라인 생성, 대시보드 작업 전반에서 정확도가 유지되는지도 검토해야 한다.

강력한 외부 결과는 Genie Code의 컨텍스트 우위가 제품을 설계한 환경 밖에서도 유지된다는 점을 보여줄 것이다. 약한 결과는 이 벤치마크가 유난히 유리한 내부 환경을 포착했을 가능성을 시사할 것이다.

Genie Ontology는 이와 관련된 또 다른 시험대다. Databricks는 이것이 전 세계적으로 제공되지 않았다는 이유로 공개 비교에서 이를 비활성화했다. 더 폭넓게 출시되면 공식적인 비즈니스 개념 계층이 결과를 개선하는지, 아니면 새로운 유지보수 부담을 초래하는지가 드러날 것이다.

이 신호들은 데이터 엔지니어에게만 중요한 것이 아니다. 제품 관리자, 분석가, 기업 AI 구매자는 점점 더 에이전트에 의존해 조직의 지식을 행동으로 전환하고 있다. 이들이 직면한 가장 큰 위험이 항상 코드를 작성하지 못하는 모델인 것은 아니다.

더 큰 위험은 잘못된 소스, 구식 정의, 또는 접근할 수 없는 자산을 기준으로 그럴듯한 코드를 작성하는 에이전트다. 이런 오류는 완성도 높아 보이지만 운영 측면에서는 여전히 쓸모없을 수 있다.

Databricks는 분명한 가설을 제시했다. 에이전트가 검색을 시작하기 전에 시맨틱 컨텍스트를 제공하면 소비량은 줄이면서 품질을 높일 수 있다는 것이다. 401개 작업으로 구성된 벤치마크는 이 주장을 뒷받침하지만, 증거는 여전히 제품을 판매하는 회사에서 나온 것이다.

실질적인 대응은 무비판적 수용도, 일축도 아니다. 팀은 자신들의 모호한 워크플로에서 에이전트를 시험하고 각 답변에 이르는 경로를 점검해야 한다. 활동량이나 토큰 규모만이 아니라 올바른 결과를 측정해야 한다.

이것이 진정한 Databricks의 ‘왜’다. 최전선은 더 많은 단계를 수행할 수 있는 모델에서, 어떤 단계가 수행할 가치가 있는지 아는 시스템으로 이동하고 있다. 앞으로 3개월은 이 우위가 Genie Code에 속하는지, 아니면 더 폭넓은 아키텍처적 전환에 속하는지를 보여줄 것이다.