Databricks 프로비저닝, 공유 워크스페이스를 에이전트 대응형 자판기로 대체

Databricks는 부담이 커진 공유 워크스페이스 모델을 3개 클라우드에서 5,000명 이상의 활성 사용자를 지원하는 프로비저닝 시스템으로 대체했다. 새 Databricks 프로비저닝 시스템은 현장 엔지니어에게 자동 만료되는 격리 환경을 제공해, 관리자가 수동으로 접근 권한을 조율해야 하는 부담을 덜어준다.

회사는 이 내부 애플리케이션을 Field Engineering Vending Machine, 즉 FEVM이라고 부른다. FEVM의 등장은 두 인프라 모델 간의 뚜렷한 긴장을 드러낸다. 하나는 사람들이 장기간 유지되는 환경을 공유하며 충돌을 조정하도록 한다. 다른 하나는 AI 에이전트가 시작한 작업을 포함해 각 작업에 필요한 임시의 관리되는 리소스를 만든다.

이 변화가 중요한 이유는 Databricks의 시장 진출 조직 인력이 현재 7,000명을 넘기 때문이다. 현장 엔지니어는 데모를 구축하고, 고객 문제를 재현하며, 프리뷰 기능을 테스트하기 위해 관리 제어 권한이 필요한 경우가 많다. 이 조직이 3년 전 1,500명 미만에서 확대되면서 공유 워크스페이스의 거버넌스는 더욱 어려워졌다.

당장의 이야기는 내부 인프라 개편이다. 더 큰 이야기는 에이전트가 리소스를 요청하고, 코드를 배포하며, 데이터를 로드하고, 워크플로를 실행할 수 있을 때 누가 클라우드 프로비저닝을 통제하느냐에 관한 것이다. FEVM은 자연어 의도를 클라우드 인프라로 전환하지만, 동시에 관리 작업을 자율 소프트웨어에 더 가깝게 이동시킨다.

Databricks 프로비저닝, 공유 용량에서 임시 환경으로 전환

Databricks는 현장 엔지니어링 조직에서 격리된 인프라를 기본 작업 단위로 만들었다.

이전 모델에서는 소수의 공유 워크스페이스가 현장 조직의 상당 부분을 지원했다. 현장 엔지니어링 인력이 1,500명 미만이었을 때는 수동 유지 관리도 감당할 수 있었다. 그러나 더 넓은 시장 진출 조직이 7,000명 이상의 직원으로 성장하면서 이 방식은 불안정해졌다.

이 조직에는 특이한 접근 권한 요구도 있다. 일반적인 엔터프라이즈 워크스페이스는 소수의 관리자가 다수의 사용자를 관리하는 방식에 의존할 수 있다. 반면 Databricks 현장 엔지니어는 구성, 테스트, 고객별 데모 업무를 수행하므로 관리자 수준의 제어 권한이 자주 필요하다.

같은 환경에서 작업하는 여러 엔지니어는 서로에게 영향을 줄 수 있다. 한 데모를 위해 변경한 설정이 고객 미팅을 준비 중인 다른 엔지니어에게 영향을 미칠 수 있다. 많은 팀이 용량을 공유할 경우 카탈로그, 데이터베이스, 워크로드 제한도 즉각적인 운영 제약이 된다.

동시에 비용 귀속도 약화된다. 공유 워크스페이스는 총 사용량을 보여줄 수 있지만, 어떤 엔지니어·고객 시나리오·실험이 이를 발생시켰는지는 명확히 드러내지 못한다. 예기치 않은 활동이 발생하면 로그와 시스템 전반에 걸친 수동 조사가 필요해진다.

FEVM은 운영 단위를 그룹이 공유하는 워크스페이스에서 목적과 소유자에 연결된 환경으로 바꾼다. 엔지니어는 템플릿, 클라우드 제공업체, 리전을 선택한다. 요청에는 노트북, Lakebase 리소스, 패키지형 자산 같은 추가 요소를 포함할 수 있다.

이후 시스템은 환경을 프로비저닝하고 그 수명주기를 기록한다. 빌더 환경의 기본 수명은 90일이며, 다른 리소스 유형에는 서로 다른 TTL(time-to-live) 설정을 적용할 수 있다. TTL 정책은 임시 리소스가 언제 만료되고 삭제되어야 하는지를 정의한다.

회사의 상세한 FEVM 설명에 따르면, Slack 알림은 프로비저닝 완료 시점, 만료 임박 시점, 삭제 발생 시점을 알려준다. 이러한 가시성은 정리를 비공식적인 책임에서 기록되는 시스템 이벤트로 바꾼다.

FEVM은 일부 리소스를 독립적으로 관리하기도 한다. 카탈로그는 연결된 워크스페이스가 사라진 뒤에도 유지되며, 이후 같은 리전의 다른 워크스페이스에 다시 연결될 수 있다. 이러한 분리는 한 리소스의 수명주기가 주변의 모든 것을 불필요하게 통제하는 일을 막는다.

따라서 핵심 변화는 더 빠른 요청 양식이 아니다. Databricks는 생성, 소유권, 만료, 삭제를 하나의 관리되는 프로세스 안에 넣었다. 이 프로세스는 사람이 인터페이스를 클릭하든 에이전트가 기반 서비스를 호출하든 동일하게 적용된다.

규모가 관리 접근 권한을 핵심 문제로 만들었다

압박의 원인은 광범위한 제어 권한이 필요하면서도, 통상 그 권한이 초래하는 혼란은 받아들일 수 없는 인력이었다.

현장 엔지니어링 팀은 대부분의 내부 비즈니스 조직과 다르게 운영된다. 이들은 중앙 플랫폼 팀을 기다릴 수 없는 구성으로 고객 상황에 신속히 대응해야 한다. 모든 엔지니어를 제한적인 사용자 역할로 묶으면 관리 기능 테스트에 의존하는 업무가 느려질 수 있다.

그러나 수천 명에게 공유 워크스페이스 내 광범위한 접근 권한을 부여하면 또 다른 병목이 생긴다. 각 사용자는 유연성을 얻지만, 모든 변경은 경합, 불분명한 소유권, 우발적 간섭의 가능성을 높인다. 그러면 플랫폼 관리자는 접근 모델이 가속하려 했던 활동을 조율하는 데 더 많은 시간을 쓰게 된다.

FEVM은 제어 권한을 격리된 환경으로 옮겨 이 모순을 해결한다. 엔지니어는 인프라를 구성할 수 있는 능력을 유지하고, 중앙에서 관리되는 템플릿은 시작 조건을 정의한다. 격리는 모든 요청을 수동 티켓 대기열로 보내지 않으면서 각 실험의 영향 범위를 제한한다.

Databricks에 따르면 이 시스템은 AWS, Microsoft Azure, Google Cloud 전반에서 이미 2,600개 이상의 활성 배포를 처리했다. 또한 내부 엔지니어링 행사인 BuildCon 기간 중 하루에 약 1,200건의 프로비저닝 요청을 처리했다.

이 수치는 Databricks가 제시한 것이며 독립적인 검증을 거치지 않았다. 그럼에도 회사가 설계한 워크로드 패턴을 보여준다. 수요는 급증하는 형태로 유입되고, 많은 사용자가 관여하며, 리소스는 무기한 활성 상태로 남아서는 안 된다.

Databricks가 2026년 7월 23일 관련 설명을 공개했을 당시 시스템의 활성 사용자는 5,000명을 넘었다. 회사는 당시 확장성 문제를 겪지 않았다고 밝혔다. 이 주장은 내부 경험을 설명하는 것이지 고객 배포의 성능을 보장하는 것은 아니다.

이 규모는 인프라 셀프서비스의 의미도 바꾼다. 소규모 플랫폼 팀은 비공식적 예외와 직접 지원을 감당할 수 있다. 수천 명의 사용자를 지원하려면 반복 가능한 템플릿, 명시적 소유권, 자동 정리, 그리고 관리자가 나중에 검토할 수 있는 기록이 필요하다.

Backstage 기반 시스템을 포함한 유사한 개발자 포털은 대개 공유 카탈로그를 통해 승인된 서비스와 템플릿을 제공한다. 클라우드 제공업체도 표준화된 인프라용 서비스 카탈로그를 제공한다. FEVM은 이 광범위한 셀프서비스 패턴을 따르되, Databricks의 현장 업무와 에이전트 주도 요청에 맞게 조정했다.

따라서 경쟁 압력은 특정 공급업체 하나보다 수동적인 공유 환경 모델에 더 직접적으로 향한다. 티켓과 장기 유지 샌드박스를 계속 사용하는 내부 플랫폼 팀은 이제 눈에 보이는 대안을 마주한다. 중앙 정책을 포기하지 않고도 승인된 임시 환경을 제공할 수 있다.

다만 임시 인프라가 거버넌스 업무를 없애지는 않는다. 그 업무를 템플릿, ID 제어, 수명주기 정책, 감사 기록으로 옮길 뿐이다. 더 많은 사용자가 이를 더 자주 호출할 수 있으므로 플랫폼 엔지니어는 이 구성 요소들을 신중하게 유지해야 한다.

Databricks도 이러한 운영 현실을 인정한다. 회사는 Git 워크플로, 기업 ID, Slack, 이메일, 멀티클라우드 Terraform을 통합하는 일이 애플리케이션 인터페이스를 만드는 것보다 더 많은 노력이 필요했다고 말한다. 이 인정은 자판기라는 비유보다 더 많은 것을 시사한다.

세련된 요청 상자는 눈에 보이는 가장자리일 뿐이다. 어려운 작업은 그 뒤에 있다. 요청과 함께 ID가 따라가야 하고, 권한은 제한된 범위 안에 머물러야 하며, 유지되어야 할 리소스를 제거하지 않고 삭제가 이뤄져야 한다.

이 메커니즘은 사용자 의도를 멀티클라우드 인프라에 연결한다

FEVM이 중요한 이유는 원시적인 워크스페이스 사양이 아니라 사용 사례를 프로비저닝 요청으로 취급하기 때문이다.

엔지니어는 필요한 모든 리소스를 나열하는 것부터 시작할 필요가 없다. 사용자는 금융 서비스 데모 준비나 지원 이슈 재현처럼 목표를 설명한다. FEVM은 그 목표를 검증된 템플릿에 매핑하고 클라우드와 리전에 대한 구성 선택지를 제공한다.

이 애플리케이션은 React 프런트엔드와 Databricks Apps를 통해 배포되는 Python 백엔드를 사용한다. 애플리케이션 플랫폼은 Databricks 내부에서 애플리케이션을 실행하고 Unity Catalog, SQL, OAuth 인증 같은 서비스와 연결한다.

기반 클라우드 프로비저닝은 Terraform이 수행한다. Terraform은 인프라를 서로 무관한 수동 단계로 생성하는 대신, 팀이 버전 관리되는 구성으로 리소스를 정의하는 인프라형 코드 시스템이다. 그 선언형 워크플로는 AWS, Azure, Google Cloud 전반의 제공업체 API를 통해 리소스를 관리할 수 있다.

FEVM이 요청을 받으면 관련 Terraform 템플릿을 선택해 Git 기반 러너로 보낸다. 워크플로는 권한을 조정하고, 요청된 추가 요소를 프로비저닝하며, 생성된 리소스를 기록한다. 이 설계는 사용자 경험을 인프라 실행 계층과 분리한다.

Lakebase는 시스템의 상태와 구성을 저장한다. Lakebase는 Databricks의 관리형 Postgres 서비스이며, 문서는 AI 에이전트의 애플리케이션 상태를 지원 용도 중 하나로 제시한다. FEVM은 각 리소스가 무엇인지, 소유자가 누구인지, 왜 존재하는지, 언제 만료되는지를 기록한다.

이 상태 기록은 필수적이다. 에이전트는 사람이 별도의 콘솔을 탐색하는 것보다 훨씬 빠르게 여러 종속 작업을 요청할 수 있다. 신뢰할 수 있는 인벤토리가 없다면 자동화는 관리자가 이해하거나 제거할 수 있는 속도보다 더 빠르게 인프라를 만들 수 있다.

인터페이스는 템플릿 카탈로그도 제공한다. Databricks가 설명한 사례에는 AWS의 안정적인 서버리스 환경, 멀티클라우드 구성, Lakebase 자동 확장이 이미 구성된 환경 등이 포함된다. 템플릿은 중앙 팀이 요청이 도착하기 전에 승인된 기본값을 인코딩할 수 있게 한다.

이 구조는 의도에서 행동으로 가는 통제된 경로를 만든다:

• 사람 또는 에이전트가 사용 사례를 제시한다.

• FEVM이 승인된 리소스 패턴을 선택한다.

• 요청자가 허용된 매개변수를 선택한다.

• Terraform이 클라우드 리소스를 생성한다.

• Lakebase가 소유권과 수명주기 상태를 기록한다.

• 알림이 프로비저닝 및 삭제 이벤트를 드러낸다.

• 만료 정책이 임시 인프라를 제거한다.

각 단계는 모호성을 줄인다. 자연어는 목표를 표현할 수 있지만, 승인된 템플릿이 시스템이 실제로 생성할 인프라를 결정한다. 이 경계는 관리되는 에이전트 접근과 클라우드 자격 증명에 연결된 제한 없는 챗봇을 구분한다.

이 메커니즘은 복합 워크플로도 지원한다. Databricks는 한 엔지니어가 에이전트에게 워크스페이스를 만들고, 로컬 Databricks Asset Bundles를 배포하고, Amazon S3에서 데이터를 업로드하며, 대시보드용 hydration 스크립트를 실행해 달라고 요청하는 시나리오를 설명한다.

hydration 스크립트는 새 환경을 필요한 데이터나 구성으로 채운다. 사용자 관점에서는 하나의 요청이 전체 순서를 촉발할 수 있다. 플랫폼 팀 관점에서는 모든 작업에 여전히 인증된 도구, 승인된 매개변수, 관찰 가능한 상태가 필요하다.

바로 이 지점에서 Model Context Protocol이 설계에 들어온다. MCP는 AI 애플리케이션이 공통 인터페이스를 통해 도구와 데이터 소스에 연결할 수 있게 하는 개방형 표준이다. 공식 MCP 개요는 이를 에이전트가 외부 워크플로에 접근하고 작업을 수행하는 방식으로 설명한다.

Databricks는 FEVM이 채팅 인터페이스, 외부 서비스, 에이전트를 위한 중앙 제어 지점으로 MCP를 사용한다고 말한다. 중앙에서 배포된 Claude 스킬은 그래픽 인터페이스를 우회해 FEVM API를 호출할 수 있다. 스킬 파일은 승인된 워크플로를 호출하는 방법을 에이전트에 알려준다.

그렇다고 언어 모델이 인프라를 직접 프로비저닝한다는 뜻은 아니다. 에이전트는 템플릿과 ID 규칙을 적용하는 통제된 서비스에 요청을 제출한다. Terraform, Git 워크플로, FEVM의 백엔드가 실제 영향이 수반되는 작업을 수행한다.

이 분리는 핵심적인 엔지니어링 결정이다. 자연어는 의도를 다루고, 결정론적 인프라 시스템은 실행을 담당한다. 모델은 도구 선택과 조율을 도울 수 있지만, 그 아래의 상태 관리나 수명 주기 제어를 대체하지는 않는다.

에이전트 우선 접근 방식은 잘못된 템플릿의 대가를 키운다

안전한 요청을 쉽게 만드는 동일한 추상화가 구성 오류를 수천 명의 사용자에게 확산시킬 수 있다.

Databricks는 새 템플릿이 검토, 강화, 반복 테스트를 거친다고 말한다. 또한 FEVM이 실제 백엔드 인프라에 대한 관리 작업을 자동화하기 때문에 팀이 보안 예외 체계 아래 운영된다고 언급한다.

이 공개는 핵심 불확실성을 드러낸다. FEVM은 편리한 인터페이스 뒤에 권한을 집중시킨다. 권한, ID 매핑 또는 템플릿에 문제가 있다면 에이전트는 결함 있는 경로를 일관되게, 높은 빈도로 호출할 수 있다.

수동 프로세스는 마찰을 만들지만, 그 마찰은 때때로 운영자가 비정상적인 요청을 알아차릴 시간을 제공한다. 자동화는 이 멈춤을 없앤다. 그 대체 수단으로 정책 검사, 제한된 매개변수, 승인 경계, 완전한 감사 기록이 필요하다.

따라서 템플릿 품질은 보안 경계가 된다. 템플릿은 어떤 네트워크 경로가 존재하는지, 어떤 ID에 접근 권한이 부여되는지, 어떤 데이터를 사용할 수 있는지, 어떤 리소스가 삭제 후에도 남는지를 결정할 수 있다. 검토 품질은 배포 속도만큼 중요하다.

자연어는 또 다른 불확실성을 더한다. 요청은 불완전하거나 모호할 수 있으며, 잘못된 가정에 기반할 수도 있다. FEVM은 요청자가 요구한 범위를 조용히 확장하지 않으면서 의도를 알려진 사용 사례로 변환해야 한다.

Databricks는 실패한 요청, 정책 거부, 잘못된 템플릿 선택, 정리 오류 또는 평균 프로비저닝 시간에 대한 상세 측정치를 공개하지 않았다. 이러한 지표는 배포 건수만으로는 알 수 없는 운영 품질을 더 잘 보여줄 것이다.

회사는 에이전트가 다단계 워크플로를 시작한 뒤 사람이 얼마나 자주 개입해야 하는지도 설명하지 않았다. 데이터 로딩, 번들 배포 또는 후속 스크립트가 실패하면 인프라 요청이 성공하더라도 사용할 수 없는 환경이 만들어질 수 있다.

비용 가시성도 비슷한 수준의 면밀한 검토가 필요하다. FEVM은 리소스를 소유자와 용도에 연결해 비용 귀속을 개선한다. 그러나 공개된 설명에는 이전과 이후의 클라우드 지출, 유휴 리소스 감소량 또는 플랫폼 자체 운영 비용이 제시되지 않았다.

자동 만료는 방치된 인프라를 줄일 수 있지만, 기본 90일은 고가 리소스가 누적되기에 충분히 긴 기간이다. 워크로드 유형마다 다른 제한이 필요하다. 임시 환경이 정기적인 갱신을 통해 영구 환경으로 바뀌지 않도록 연장 정책도 검토해야 한다.

멀티클라우드 지원은 과제를 더 크게 만든다. AWS, Azure, Google Cloud는 각각 다른 ID 시스템, 할당량, 리전 서비스, 장애 양상을 갖고 있다. 공통 요청 인터페이스는 이러한 차이를 사용자에게 숨길 수 있지만, 플랫폼 팀은 여전히 이를 관리해야 한다.

플랫폼 한계도 또 다른 압박 지점이다. Databricks는 Unity Catalog 및 Lakebase 리소스와 관련된 엄격한 한계를 언급한다. 중앙 집중식 수명 주기 관리는 이러한 한도를 피하는 데 도움이 되지만, 한도 자체를 없애지는 않는다. 수요는 여전히 가용 용량을 초과하거나 리전별 경합을 유발할 수 있다.

Postgres 문서에 따르면 Lakebase 자체는 트랜잭션 애플리케이션 상태, 자동 확장, 격리된 브랜치를 지원한다. FEVM의 신뢰성은 여전히 자체 스키마, 조정 프로세스, 복구 로직이 이러한 기능을 어떻게 활용하는지에 달려 있다.

Databricks는 데이터베이스 스키마, 프런트엔드, 상태 관리 변경을 포함해 FEVM을 두 차례 재설계했다고 말한다. 이 이력은 설계에 상당한 반복 작업이 필요했음을 시사한다. 또한 현재 아키텍처를 단순한 참조 구현으로 받아들이지 말아야 한다는 경고이기도 하다.

회사는 AI를 사용해 코딩을 가속했지만, 아키텍처 통제는 사람이 유지했다고 말한다. 권한이 높은 인프라를 관리하는 시스템에서는 타당한 분업이다. 생성된 코드는 구현 속도를 높일 수 있지만, 경계 설정과 장애 복구에 대한 책임은 여전히 사람의 검토에 남는다.

FEVM이 보고한 규모는 직원들이 더 빠른 프로비저닝을 원한다는 점을 보여준다. 하지만 에이전트에서 시작된 요청이 신중히 검토된 사람의 요청과 동일한 신뢰성, 보안 또는 비용 통제를 제공한다는 점까지 증명하지는 않는다. 그러한 주장은 더 긴 운영 데이터와 더 명확한 지표를 필요로 한다.

진짜 상대는 장기 운영되는 공유 워크스페이스다

FEVM은 조정을 격리로 대체하지만, 그만큼 중앙 플랫폼 정책의 중요성을 높인다.

공유 워크스페이스는 처음에는 효율적으로 보인다. 팀은 공통 인프라를 재사용하고, 반복 설정을 피하며, 리소스를 한눈에 보이는 위치에 유지한다. 그러나 대부분의 사용자에게 광범위한 제어가 필요하고 고객 업무에 상호 양립할 수 없는 구성이 요구되면 이러한 장점은 약해진다.

Databricks의 현재 규모에서는 공유 환경이 조정을 보이지 않는 노동으로 바꾼다. 엔지니어는 충돌을 피해야 하고, 관리자는 소유권을 추적해야 하며, 팀은 누가 공통 리소스를 변경할 수 있는지 결정해야 한다. 중요한 데모는 다른 사용자가 같은 환경을 수정하지 않는 데 달려 있을 수 있다.

격리된 프로비저닝은 이 관계를 뒤집는다. 각 엔지니어는 모두와 협상하지 않고도 목적에 맞춘 환경을 받는다. 플랫폼 팀은 개별 워크스페이스 충돌을 중재하는 대신 템플릿과 수명 주기 규칙을 표준화한다.

이 전환은 기업이 활용도를 평가하는 방식도 바꾼다. 공유 환경은 많은 사람이 하나의 워크스페이스를 사용하기 때문에 효율적으로 보일 수 있다. 하지만 이 지표는 대기 시간, 구성 드리프트, 실패한 데모, 조사에 드는 노력을 무시한다.

임시 환경은 시스템이 더 많은 워크스페이스를 만들기 때문에 덜 효율적으로 보일 수 있다. 그러나 소유권이 명확하고 정리가 자동으로 이뤄진다면 운영 낭비를 줄일 수 있다. Databricks는 그 결과를 확립할 만큼 충분한 비용 데이터를 공개하지 않았지만, 이 설계는 측정을 가능하게 한다.

이 패턴은 소프트웨어 제공에 사용되는 일시적 개발 환경을 닮았다. 팀은 브랜치, 테스트 또는 검토를 위해 깨끗한 환경을 만든 뒤 작업이 끝나면 제거한다. FEVM은 데이터 및 AI 필드 엔지니어링에 비슷한 수명 주기를 적용한다.

에이전트 요소는 격리의 필요성을 강화한다. 그래픽 인터페이스를 사용하는 사람은 대체로 작업을 순차적으로 수행한다. 에이전트는 하나의 지시로 여러 도구를 조율하고 여러 리소스를 생성할 수 있다.

이러한 작업을 혼잡한 공유 워크스페이스에 배치하면 예상치 못한 상호작용의 가능성이 커진다. 격리된 환경은 워크플로에 경계가 정해진 위치를 제공한다. 또한 관리자에게 귀속, 만료, 삭제를 위한 더 명확한 단위를 제공한다.

하지만 인벤토리와 정리가 실패하면 격리는 확산을 초래할 수 있다. 해답은 격리만으로 충분하지 않다. 중앙 관리되는 상태, 소유권, 알림, 수명 주기 집행과 결합된 격리가 필요하다.

이 때문에 자판기라는 표현은 유용하면서도 불완전하다. 자판기는 작은 카탈로그를 제시하고 예측 가능한 상품을 제공한다. FEVM은 요청자를 인증하고, 의도를 해석하고, 분산 인프라를 생성하고, 한계를 모니터링하며, 결국 모든 변경을 되돌려야 한다.

이 플랫폼은 단순한 애플리케이션보다 내부 제어 플레인에 가깝다. 제어 플레인은 어떤 리소스가 존재해야 하는지를 결정하고 수명 주기를 조율하는 관리 계층이다. FEVM은 사용자 또는 에이전트와 기반 클라우드 사이에 위치한다.

이 위치는 Databricks에 자체 애플리케이션, 데이터베이스, 거버넌스, 에이전트 기술을 위한 직접적인 테스트 환경을 제공한다. 동시에 성공적인 내부 사용 사례를 더 넓은 플랫폼을 위한 증거로 제시할 유인을 만든다.

독자는 이 두 주장을 구분해야 한다. FEVM은 신뢰할 만한 내부 솔루션일 수 있지만, 모든 기업이 이를 쉽게 재현할 수 있음을 증명하지는 않는다. Databricks의 필드 조직은 전문 역량, 깊은 플랫폼 접근권, 기업 시스템 전반의 통합을 유지할 권한을 갖추고 있다.

다른 기업은 별도의 데이터 플랫폼, ID 제공업체, 티켓 시스템, 정책 엔진, 클라우드 계정에 의존할 수 있다. 이들의 통합 작업은 사용자 인터페이스 구축에 필요한 노력보다 클 수 있다. Databricks 자체 설명에 따르면 이 통합이 FEVM의 엔지니어링 난이도와 가치 상당 부분을 만들었다.

교훈은 모든 기업이 동일한 자판기를 필요로 한다는 것이 아니다. 에이전트 기반 인프라에는 거버넌스가 적용되는 서비스 경계가 필요하다는 것이다. 소프트웨어 에이전트가 복잡한 워크플로를 시작할 수 있게 되면, 장기 운영되는 공유 워크스페이스와 임시 자격 증명을 방어하기는 더 어려워진다.

FEVM이 에이전틱 시대를 맞을 준비가 되었는지 보여줄 세 가지 신호

다음 시험대는 Databricks가 예측 가능한 보안, 정리, 운영 결과를 유지하면서 에이전트 접근을 확대할 수 있는지다.

첫 번째 신호는 FEVM의 자연어 인터페이스를 계획대로 확장하는 일이다. Databricks는 엔지니어가 고객 상황을 설명하면 시스템이 적합한 인프라를 식별하도록 만들고자 한다. 의도 처리의 개선은 사용 사례 기반 프로비저닝이 수동 명세를 대체할 수 있다는 주장을 강화할 것이다.

유의미한 증거는 성공한 요청을 또 한 번 시연하는 것이 아니다. Databricks는 인터페이스가 올바른 템플릿을 얼마나 자주 선택하는지, 언제 추가 설명을 요청하는지, 지원되지 않는 요청을 얼마나 자주 거부하는지, 또는 사람의 수정이 얼마나 자주 필요한지를 보고해야 한다.

낮은 수정률은 에이전트 우선 모델을 뒷받침할 것이다. 빈번한 오분류는 권한이 높은 인프라 작업에서 개방형 언어보다 카탈로그 검색이 여전히 안전하다는 점을 보여줄 것이다.

두 번째 신호는 도구 기반 접근을 위한 더 광범위한 MCP 통합이다. Databricks는 이 통합의 제공을 다음 우선순위 중 하나로 꼽는다. MCP는 더 많은 에이전트 클라이언트가 전용 그래픽 워크플로를 요구받지 않고 공통 도구 인터페이스를 통해 FEVM에 접근할 수 있게 한다.

핵심 질문은 FEVM이 이러한 클라이언트 전반에서 권한 범위를 어떻게 제한하는가다. 강력한 ID 전파, 제약된 도구, 명확한 승인, 완전한 감사 추적은 설계를 강화할 것이다. 광범위한 자격 증명이나 불명확한 위임은 이를 약화시킬 것이다.

보안 팀은 에이전트 작업이 사람인 후원자와 계속 구분되는지도 살펴봐야 한다. 유용한 감사 기록은 직원, 에이전트 세션, 선택된 템플릿, 요청 목적, 생성된 리소스, 이후 삭제를 연결해야 한다.

세 번째 신호는 더 광범위한 시장 진출 조직 전반으로의 확장이다. 더 많은 사용자는 원래 필드 엔지니어링 대상 외부에서도 템플릿이 이해하기 쉬운지 시험하게 된다. 또한 새로운 워크로드 패턴과 지원 수요를 만들 것이다.

도입 수치만으로는 이 문제를 판단할 수 없다. 더 강력한 지표는 프로비저닝 성공률, 사용 가능한 환경까지 걸리는 시간, 정책 거부율, 만료 리소스 정리, 사용 사례당 비용, 사람의 개입 빈도다.

Databricks는 시간이 지나면서 이러한 운영 결과를 공개함으로써 주장을 강화할 수 있다. 반면 실패, 비용, 보안 예외를 설명하지 않은 채 활성 사용자 및 배포 총계에만 집중한다면 주장은 약화될 수 있다.

개발자에게 FEVM은 에이전트가 무제한적인 클라우드 접근 권한을 부여받지 않고도 인프라 도구를 통해 작업할 수 있는 방식을 보여준다. 엔터프라이즈 구매자에게는 에이전트 거버넌스를 위한 구체적인 검증 기준을 제시한다. 모든 작업에는 담당자, 목적, 정책 경로, 만료 규칙이 있어야 한다.

지식 근로자도 이 패턴이 다른 비즈니스 시스템으로 확산될 것이기 때문에 주목해야 한다. 에이전트는 접근 권한을 요청하고, 프로젝트 환경을 구성하며, 컨텍스트를 가져오고, 도구를 조율하게 될 것이다. 통제 계층의 품질은 채팅 인터페이스의 유창함보다 더 중요해질 것이다.

유사한 워크플로를 구축하는 팀은 프로비저닝 서비스 외부에 지속 가능한 문서화 체계도 마련해야 한다. 검색 가능한 지식 베이스는 에이전트의 작업을 검토하는 엔지니어를 위해 템플릿 결정 사항, 인시던트 결과, 운영 컨텍스트를 보존할 수 있다.

Databricks의 프로비저닝은 이미 이례적인 내부 규모로 운영되고 있지만, 가장 중요한 단계는 아직 남아 있다. 자연어 요청이 계속해서 명확한 경계 안에 머무르는지, MCP 접근이 신원을 보존하는지, 더 폭넓은 도입이 위험을 확대하지 않고 성과를 개선하는지 지켜봐야 한다.

이제 모든 플랫폼 팀이 마주한 실질적인 질문은 분명하다. 인프라가 각 리소스를 누가 요청했는지, 왜 존재하는지, 언제 사라질지를 설명할 수 있는가? 에이전트가 이러한 경계 안에서 작동할 수 없다면, 더 빠른 프로비저닝은 더 빠른 불확실성을 만들 뿐이다.