에이전트 시대를 위한 프로비저닝: Databricks가 셀프 서비스 인프라 자판기를 구축한 방법

Databricks의 필드 엔지니어링 조직은 고객의 성공을 돕기 위해 존재합니다. 이는 데모를 제작하고, 문제를 재현하며, 실제 워크로드에서 기능을 테스트하고, (갑작스러운 요청에도) 잠재 고객에게 플랫폼에서 무엇이 가능한지 정확히 보여줄 준비를 갖추는 것을 의미합니다. 단 일주일 만에 가능성의 판도가 근본적으로 바뀔 수 있는 AI 시대에는 이러한 역할이 그 어느 때보다 중요해졌습니다. Databricks가 성장함에 따라, 필드 조직이 빠르고 거버넌스가 유지되며 비용을 의식하는 방식으로 일할 수 있도록 지원하는 일이 더욱 중요해졌고, 동시에 더 까다로워졌습니다.

이 문제를 해결하기 위해 우리는 '필드 엔지니어링 자판기(Field Engineering Vending Machine)', 줄여서 FEVM을 구축하기 시작했습니다. 여느 훌륭한 자판기와 마찬가지로 개념은 간단합니다. 필요한 것을 말하면 얻을 수 있고, 사용이 끝나면 사라집니다. 무엇보다 중요한 점은 FEVM이 Databricks 네이티브 구성 요소를 핵심으로 하고, 에이전트를 최우선으로 고려하여 구축되었다는 것입니다.

규모 확장에 따른 성장통

불과 3년 전만 해도 필드 엔지니어링 조직은 1,500명 미만이었습니다. 소수의 공유 워크스페이스가 대부분의 사용 사례를 처리했고, 수동 유지보수를 통해 시스템이 제법 원활하게 운영되었습니다. 하지만 Databricks는 빠르게 성장했습니다. 현재 GTM 조직은 7,000명이 넘으며, 필드 엔지니어링이 그 중 상당 부분을 차지하고 있습니다. 특정 규모에서 작동하던 인프라는 규모가 달라지면 다른 설계가 필요합니다.

Databricks 워크스페이스는 소수의 관리자가 다수의 사용자를 관리하도록 최적화되어 있으며, 이는 대부분의 기업 배포 환경에 적합합니다. 하지만 필드 엔지니어링은 요구사항이 다릅니다. 실제로 업무를 수행하려면 거의 모든 사람에게 관리자 수준의 권한이 필요합니다. 데모 환경 구성, 프리뷰 기능 테스트, 고객 맞춤형 시나리오 실행 등 모든 작업에는 관리자 권한이 제공하는 제어 능력이 필요하기 때문입니다.

규모가 커짐에 따라 공유 워크스페이스에서 작업을 조율하는 것은 실제 운영상의 복잡성을 초래합니다. 중요한 데모 순간에 여러 엔지니어가 동일한 환경에서 작업하면 서로의 작업을 방해할 수 있으며, 카탈로그, Lakebase 인스턴스, 동시 워크로드 등에 대한 플랫폼 제한 사항이 보이지 않는 문제가 아니라 실질적인 당면 과제가 됩니다. 사용량이 증가하고 소유권이 불분명해짐에 따라 비용 귀속을 추적하기도 점점 더 어려워집니다.

관찰 가능성(observability) 문제도 이러한 어려움을 가중시켰습니다. 공유 워크스페이스에서 예기치 않은 일이 발생했을 때, 언제, 왜, 무슨 일이 일어났는지 추적하려면 수동 조사가 필요했습니다. 우리는 처음부터 모든 프로비저닝 작업을 투명하게 공개하고, 감사 가능하며, 책임 소재를 명확히 할 수 있는 모델이 필요했습니다.

FEVM을 탄생시킨 통찰력은 간단했습니다. 모든 엔지니어가 단 몇 분 만에 프로비저닝되고, 중앙에서 거버넌스가 관리되며, 자동으로 정리되는 자신만의 격리된 환경을 가질 수 있다면 어떨까?

Databricks를 위한, Databricks 기반 구축

Databricks Apps를 사용할 수 있게 되었을 때, 기회는 명확해졌습니다. 우리는 작업당 하나의 잡(job)을 할당하여 개별적으로 실행하고, 항상 실제 상황보다 조금씩 뒤처지는 방식으로 환경을 유지해 왔습니다. Apps는 이 모든 것을 단일 인터페이스 뒤로 추상화할 수 있는 방법을 제공했습니다. 쉬운 영어로 달성하려는 목표를 말하면, 어떤 인프라를 프로비저닝할지 시스템이 알아서 판단하는 방식입니다.

이것이 FEVM의 핵심 설계 원칙인 '사용 사례 기반 프로비저닝'이 되었습니다. 사용자는 단순히 "워크스페이스"를 요청하지 않습니다. 금융 서비스 고객을 위한 데모 제작, 지원 문제 재현, 해커톤 세션 진행 등 자신이 하려는 작업을 설명하면 그 목적에 맞게 구성된 환경을 제공받게 됩니다. 이 모든 것은 MCP를 핵심으로 하여 추상화되어 있으므로 채팅, 외부 서비스, 에이전트가 모두 단일 제어 지점에서 서비스됩니다. Claude와 같은 도구의 등장으로, 이제 간단한 .md 스킬 파일을 추가하는 것만으로 명령줄에서 쉬운 영어로 새 환경을 요청하고 몇 분 후에 로그인할 수 있습니다. 사용자 관점에서는 더 복잡한 워크플로도 이와 마찬가지로 매우 간단해집니다.

이 앱은 React 프론트엔드와 Python 백엔드로 구축되었으며, Databricks Apps를 통해 배포됩니다. 백그라운드에서는 Terraform이 실행되어 AWS, Azure, GCP 전반에서 실제 클라우드 리소스 프로비저닝을 처리합니다. Lakebase에서 실행되는 상태 및 구성 데이터베이스는 모든 리소스(리소스의 종류, 소유자, 용도, 만료 시점)를 추적합니다.

Databricks Apps 개발 경험 자체는 간단했습니다. 더 복잡한 작업은 Git 기반 워크플로 실행 연결, 기업 시스템 전반의 ID 처리, 실제 백엔드 인프라에 대한 관리 작업 자동화가 보안 경계 내에서 유지되도록 보장하는 등 더 넓은 에코시스템에 통합하는 것이었습니다. 바로 이러한 이유로 우리는 여러 보안 예외 사항 하에 운영되고 있으며, 모든 단계에서 안전한 관리를 설계하기 위해 신중을 기해 왔습니다. 새로운 템플릿은 새로운 위협 벡터를 노출하지 않도록 반복적으로 검토, 강화 및 테스트됩니다.

앱의 기능

필드 엔지니어가 FEVM을 열면 검색 인터페이스가 나타납니다. 템플릿 카탈로그를 탐색하여 적절한 환경 유형(예: AWS의 안정적인 서버리스, 멀티 클라우드 설정, Lakebase 오토스케일링이 사전 구성된 환경 등)을 찾고 거기서부터 구성을 시작할 수 있습니다. 클라우드 제공업체와 리전을 선택하고, 구축하려는 대상을 설명하고, 이름을 지정한 다음(또는 임의의 이름 수락), 배포합니다.

최근에는 사용자가 중앙에서 게시된 claude 스킬을 활용할 수 있도록 에이전트 우선(agent-first) 워크플로를 활성화했습니다. 이는 에이전트가 UI를 거치지 않고 기본 FEVM API로 직접 이동하여 자동화할 수 있도록 지원하는 방식으로, 점점 더 인기를 얻고 있는 옵션입니다. 이는 다단계 및 다중 도구 워크플로에서 특히 강력합니다. 예를 들어, 사용자는 에이전트에게 새 워크스페이스를 실행하고, 로컬에서 개발한 여러 DABs를 배포하고, S3에 있는 일부 데이터를 업로드한 다음, 대시보드를 채우기 위한 하이드레이션(hydration) 스크립트를 실행하도록 지시할 수 있습니다. 이러한 유형의 초개인화된 설정은 강력한 에이전트 프레임워크 없이는 불가능했을 것이며, Databricks Apps는 이를 매우 간단하게 만들어 줍니다.

사용자나 에이전트가 새 리소스를 요청하면, 백그라운드에서 앱은 적절한 terraform 템플릿을 가져와 Git Runner에 전달하고, 권한을 조정한 다음, Lakebase, 노트북 또는 UC Volume에 호스팅된 사전 패키지 자산과 같이 사용자가 요청한 "애드온"을 추가합니다. 빌더 환경은 기본적으로 90일 동안 유지되며 연장 옵션을 사용할 수 있고, 다른 리소스 유형은 TTL을 구성할 수 있습니다.

프로비저닝이 완료되면 Slack 알림이 전송됩니다. 리소스 만료일이 다가오면 또 다른 알림이 전송됩니다. 삭제되면 다시 알림을 받게 됩니다. 투명성은 첫날부터 핵심 설계 목표였습니다. 모든 수명 주기 이벤트가 시각화되어 엔지니어는 항상 리소스의 상태를 파악할 수 있습니다.

우리는 동일한 인터페이스를 통해 공유 리소스도 관리합니다. 예를 들어, 독립형 카탈로그는 연결된 워크스페이스와 독립적인 수명 주기를 갖습니다. 워크스페이스를 삭제해도 카탈로그는 유지되며, 동일한 리전에 새 워크스페이스를 실행하면 카탈로그가 자동으로 다시 연결됩니다. 이러한 리소스 수준의 수명 주기 관리가 중요한 이유는 Unity Catalog와 Lakebase 모두 엄격한 플랫폼 제한이 있기 때문입니다. 수백 명의 엔지니어가 활발하게 리소스를 프로비저닝하는 상황에서 중앙 집중식 제어는 이러한 제한이 걸림돌이 되지 않도록 막아주는 역할을 합니다.

앱 내의 관리자 레이어를 통해 우리 팀은 UI에서 직접 클라우드별 워크스페이스 제한 조정, 활성 배포 감사, 기본값 조정 등 글로벌 구성을 관리할 수 있습니다.

예상보다 빠르게 입증된 규모 확장성

내부 엔지니어링 이벤트 중 하나인 BuildCon 기간 동안 FEVM은 단 하루 만에 약 1,200건의 프로비저닝 요청을 처리했습니다. 조직 전반의 엔지니어들이 조율 오버헤드나 리소스 경합 없이 환경을 실행하고, 작업을 수행한 후 만료되도록 두었습니다. 현재 활성 사용자가 5,000명이 넘음에도 불구하고 아직 확장성 문제를 겪지 않았습니다. 이 글을 쓰는 시점을 기준으로 3개 클라우드에 걸쳐 2,600개 이상의 활성 배포를 관리하고 있습니다!

이 수치는 단순한 스트레스 테스트로서뿐만 아니라 개념 증명(PoC)으로서도 큰 의미가 있습니다. FEVM의 가설은 적시(just-in-time) 격리 프로비저닝이 대규모 공유 환경의 마찰을 대체할 수 있다는 것이었습니다. 단 하루 동안의 호출 횟수는 수요가 항상 존재했으며, 엔지니어들에게는 단지 마찰 없이 실행할 수 있는 도구가 필요했을 뿐이라는 점을 확인시켜 줍니다.

우리가 만들어가는 에이전트 중심의 미래

Databricks가 지향하는 더 넓은 비전은 에이전트 우선(agent-first)의 필드 엔지니어링 조직입니다. 엔지니어가 고객의 상황을 쉬운 언어로 설명하면, 에이전트가 적절하게 구성된 환경을 실행하고, 관련 계정 컨텍스트를 검색하고, 문제를 재현하거나 데모를 구축한 후, 고객에게 바로 전달할 수 있는 요약본을 반환하는 것입니다. FEVM은 이를 가능하게 하는 인프라 레이어입니다.

여기까지 오기 위해 우리는 데이터베이스 스키마 재설계, 프론트엔드 재구축, 상태 관리 방식 재고 등 앱의 아키텍처를 두 번이나 재구성했습니다. 코딩 속도를 높이기 위해 AI를 활용했지만, 아키텍처에 있어서는 시종일관 주도권을 유지했습니다. 그 결과 대규모로 안정적으로 실행할 수 있다고 신뢰할 수 있는 시스템이 탄생했습니다.

우리가 배운 점

이번 구축을 이끈 몇 가지 원칙은 다음과 같습니다.

• 사용자가 사람이든 에이전트이든 관계없이 항상 사용자를 최우선으로 생각하고 구축해야 합니다. 저희는 CUJ에서 출발하여 해당 여정을 해결하는 기능을 설계하기 위해 열심히 노력했습니다. 이를 통해 실제로 해결해야 할 과제가 무엇인지, 그리고 단순한 내부적 편향은 무엇인지 객관적으로 파악할 수 있었습니다.
• 투명성은 나중에 덧붙이는 것이 아니라 하나의 핵심 기능입니다. 프로비저닝, 만료, 삭제 등 모든 수명 주기 이벤트를 투명하게 공개하는 것이 실제 고객 업무를 위해 이 도구에 의존하는 엔지니어들과 신뢰를 쌓는 방법입니다.
• 에코시스템 통합은 까다로운 작업입니다. Databricks Apps 개발 경험은 빠르고 직관적이었지만, FEVM을 Git, Slack, 이메일, 기업 ID 및 멀티 클라우드 Terraform에 연결하는 데 대부분의 엔지니어링 노력이 투입되었으며, 바로 그곳에서 가장 큰 가치가 창출되었습니다.

Databricks를 위한 제품을 Databricks에서 직접 구축하세요. FEVM의 거의 모든 기능은 플랫폼 자체에서 실행됩니다. 이를 통해 대규모 환경에서 무엇이 효과적인지 직접 파악할 수 있으며, 우리가 판매하는 제품 경험을 가장 가까이에서 체감할 수 있습니다.

향후 계획

저희는 세 가지 사항에 집중하고 있습니다. 바로 자연어 프로비저닝 인터페이스 확장, 도구 기반 액세스를 위한 MCP 통합 출시, 그리고 더 광범위한 GTM 조직 전반으로 지원을 확장하는 것입니다. 에이전트가 오늘날 필드 엔지니어들이 수행하는 업무를 더 많이 담당하게 됨에 따라, FEVM은 단순한 프로비저닝 도구를 넘어 에이전트가 실행되는 리소스 레이어, 즉 에이전트 기반 워크플로(agentic workflow)의 핵심 인프라가 될 것입니다.

FE Vending Machine에 대한 자세한 내용은 Data and AI Summit 2026의 브레이크아웃 세션인 에이전트 시대를 위한 프로비저닝: Databricks가 셀프 서비스 인프라 자판기를 구축한 방법에서 확인하실 수 있습니다.

Databricks에서 프로덕션급 앱을 구축하는 방법에 대해 자세히 알아보려면 Databricks Apps, Lakebase 및 Agent Bricks를 확인해 보세요.

(이 글은 AI의 도움을 받아 번역되었습니다. 원문이 궁금하시다면 여기를 클릭해 주세요)