배경 및 맥락
기업이 agent를 붙이기 시작하면 가장 먼저 부딪히는 문제는 모델 성능보다 데이터와 도구 접근 제어다. 누가 어떤 index를 조회할 수 있는지, 어떤 외부 MCP 서버를 호출할 수 있는지, usage와 비용을 어디서 감시할지, 여러 subagent를 어떻게 조합할지가 실제 운영 병목이 된다.
Databricks는 이번 문서 공개에서 이 문제를 단순 SDK 예제가 아니라 플랫폼 구조로 풀고 있다. Lakehouse, Vector Search, Genie, external MCP, custom MCP, coding agent를 모두 Unity AI Gateway와 Databricks Apps 중심으로 묶으려는 흐름이 분명하다.
핵심 내용
Unity AI Gateway는 agent, LLM endpoint, MCP server, coding agent를 위한 중앙 거버넌스 계층으로 소개됐다. 문서상으로는 usage 분석, permission 설정, guardrail 적용, provider 간 capacity 관리, inference table 기반 audit, traffic splitting까지 지원한다. MCP 문서에서는 managed MCP, external MCP, custom MCP를 모두 Unity Catalog permission과 managed OAuth 아래 두고, AI Gateway에서 통합 가시성을 제공한다고 설명한다.
동시에 multi-agent 문서는 Databricks Apps orchestrator가 Databricks Apps agent, Genie Space, serving endpoint를 각각 subagent/tool로 취급하고, OpenAI Agents SDK 기반 템플릿으로 라우팅하게 만든다. 즉 Databricks는 agent를 데이터 질의 보조 도구가 아니라, lakehouse-native orchestration runtime으로 끌어올리고 있다.
경쟁 구도 / 비교
많은 벤더가 MCP를 연결 표준으로 수용하고 있지만, Databricks의 차별점은 이를 데이터 거버넌스 체계와 직접 결합한다는 점이다. 별도 agent 플랫폼 위에 데이터 커넥터를 붙이는 방식과 달리, Databricks는 permission, OAuth, audit, structured/unstructured retrieval, multi-agent routing을 같은 플랫폼면에 놓는다.
이는 향후 enterprise AI에서 데이터 플랫폼 업체가 agent control plane의 주도권까지 가져갈 수 있음을 의미한다. 특히 BI/SQL/Vector Search 자산이 이미 Databricks에 있는 조직일수록 별도 agent infra보다 이 통합 경로가 더 매력적일 수 있다.
의미
기술적으로는 agent engineering이 애플리케이션 레벨 orchestration을 넘어 data governance 레이어와 합쳐지고 있다. 산업적으로는 lakehouse vendor들이 LLM hosting을 넘어 agent policy plane까지 경쟁 범위를 넓히고 있다는 신호다.
실무적으로는 AI팀과 데이터 플랫폼팀의 경계가 더 흐려진다. 앞으로는 prompt와 workflow만 설계할 것이 아니라, MCP 설치 승인, subagent permission, usage audit, structured/unstructured data access policy를 하나의 배포 단위로 관리해야 한다.