작성자: Rohit Agrawal, Shuyu Cao, Darming Zhao, Zack Siegel , 아론 데이비슨
• Databricks에서는 모든 코딩 에이전트를 Unity AI Gateway로 라우팅하여 대규모로 AI 지출을 관리하며, 팀이 모든 모델과 도구에 걸쳐 예산, 가시성 및 정책을 적용할 수 있는 단일 창구를 제공합니다.
• 일일 및 월간 예산을 별도로 설정하여 급증하는 AI 지출을 방지하는 동시에, 승인 병목 현상 대신 셀프 서비스 예산 증액을 통해 엔지니어의 생산성을 유지함으로써 혁신과 비용 통제의 균형을 맞춥니다.
• 검증된 이 거버넌스 모델은 중앙 집중식 지출 통제, 통합된 관측 가능성, 데이터 기반 정책 적용을 결합하여 개발자의 작업 속도를 늦추지 않고 AI 도입을 확장합니다.
Databricks에서는 엔지니어링에 AI를 적극적으로 도입하면서 소프트웨어를 개발하는 방식이 빠르게 변화하고 있습니다. 수천 명의 엔지니어가 매일 Claude Code, Codex, Cursor 등을 혼합하여, 종종 여러 개를 동시에 사용 하며 코딩 에이전트를 활용하고 있습니다. 이러한 도입은 매우 훌륭하지만 새로운 문제를 야기합니다. 바로 코딩 에이전트 비용이 이제 R&D에서 가장 빠르게 증가하는 지출 항목 중 하나가 되었으며, 단 한 번의 제어 불가능한 자동화 루프로 인해 오후 한나절 만에 한 달 치 예산을 모두 써버릴 수 있다는 점입니다.
이 게시물에서는 고객에게 제공하는 것과 동일한 Unity AI Gateway Budgets를 사용하여 내부적으로 이 문제를 어떻게 해결했는지 공유합니다. Databricks의 모든 코딩 에이전트는 도구나 모델에 관계없이 게이트웨이를 통해 트래픽을 라우팅하므로, 개별 코딩 에이전트 관리 콘솔을 건드리지 않고도 전체 플릿에 걸쳐 단일 지출 정책을 적용할 수 있습니다.
이를 배포하면서 얻은 주요 교훈은 다음과 같습니다.
어떻게 여기까지 오게 되었는지 자세히 살펴보겠습니다.
참고: 이 게시물에 표기된 달러 금액은 예시일 뿐이며 실제 내부 수치가 아닙니다.
비용 관리 여정을 시작할 때 우리는 정확히 하나의 한도만 설정했습니다. 모든 엔지니어에게 기본 월별 지출 한도(예: $500)를 부여하고, 한도에 도달하면 증액 요청을 제출하도록 한 것입니다. 서류상으로는 합리적으로 들리지만, 실제로는 이 전략이 모든 과정에서 마찰을 일으킨다는 사실을 발견했습니다.
이 한도가 제어 불가능한 지출을 방지하는 유일한 보호 장치이기도 했기 때문에, 모든 한도 증액 역시 동일하게 $500 단위로 이루어졌습니다. 사용량이 많은 사용자는 새로운 한도에 도달할 때마다 매번 새로운 요청을 제출해야 했고(한 달에 여러 번인 경우도 있음), $2500를 초과하는 경우에는 수동 검토가 필요했습니다. 더 심각한 것은 모든 증액이 영구적이었다는 점입니다. 비용이 많이 드는 실수를 한 번 저질렀거나 지출이 많은 프로젝트에서 작업한 엔지니어가 큰 한도를 무기한 유지하게 되면서, 비용이 많이 드는 실수에 취약한 조직의 비율이 조용히 늘어났습니다. 또한, 엔지니어가 고객 장애를 디버깅하기 위해 AI를 사용하는 것과 같이 시간이 중요한 중요한 작업을 위해 스스로 차단을 해제할 수 있는 비상 절차(break glass process)가 없었습니다.
당사의 규모에서는 매달 500명에서 1,000명 사이의 엔지니어가 한도에 도달하고 있었습니다. 이는 수백 개의 티켓, 수백 번의 업무 중단, 그리고 매우 불만에 찬 #ai-devtools Slack 채널을 의미했습니다.
무언가를 설계하기 전에 우리는 AI 지출에 대해 실제로 믿고 있는 바를 기록했고, 이는 두 가지 원칙으로 요약되었습니다:
이를 기록해 보니 모순이 드러났습니다. 제어 불가능한 지출을 잡으려면 몇 시간의 실수만으로도 한도가 초과될 만큼 한도가 작아야 합니다. 하지만 한도가 그렇게 작으면 정상적인 월별 사용을 끊임없이 방해하게 됩니다. 단 하나의 숫자로는 이 두 가지 작업을 모두 수행할 수 없습니다.
우리는 엔지니어가 방해받지 않고 지출할 수 있도록 하되, 실제로 중요한 두 가지 종류의 낭비인 단기적 낭비와 장 기적 낭비에 대해서만 개입한다는 단순한 원칙을 바탕으로 구조를 재조정했습니다.
이 두 가지 실패 모드에 대한 해결책은 Unity AI Gateway의 두 가지 예산에 매핑됩니다:
제어 불가능한 지출을 방지하기 위한 일일 한도. 이 한도는 월별 지출에 비해 의도적으로 작게 설정됩니다. 엔지니어가 이 한도에 도달하더라도 문제가 있다고 가정하지 않습니다. 엔지니어는 Slack 알림을 받고 지출이 의도된 것임을 확인하면 한도가 자동으로 한 단계 증액됩니다. 승인도, 티켓도, 대기도 필요 없습니다. 지출이 실수였다면 이 알림이 바로 그들에게 필요한 경고가 됩니다. 일일 예산은 매일 저녁 사용량이 가장 적은 시간에 리셋되며, 매월 초에 완전히 초기화됩니다.
비정상적인 지출을 관리하기 위한 월별 한도. 이 한도는 일반적인 엔지니어가 도달할 일이 없도록 충분히 높게 설정됩니다. 이 한도를 넘는다는 것은 누군가가 동료들보다 훨씬 더 많은 지출을 요청하고 있음을 의미하며, 이는 괜찮지만 특정 비즈니스 우선순위와 연계되어야 합니다. 이러한 증액은 중앙 집중식 승인 위원회 대신 관리자 승인을 거치며, 끝없는 소액 증액 대신 몇 개의 굵직한 등급으로 제공됩니다. 그리고 결정적으로 프로젝트 기간으로 시간 제한이 설정됩니다. 프로젝트가 끝나면 한도는 원래대로 복원됩니다.
두 한도는 고정된 비율을 통해 결합된 상태를 유지합니다. 당사의 배포 환경에서는 월별 예산을 근무일로 나눈 값이 일일 임계값보다 훨씬 낮기 때문에, 한 달 동안 원활하게 지출하는 엔지니어는 일일 한도를 전혀 초과하지 않습니다. 관리자가 대형 프로젝트를 위해 누군가의 월별 한도를 인상하면 일일 한도와 증액분도 비례하여 확장되므로, 제어 불가능한 지출 방지 기능이 번거로움 없이 유의미하게 유지됩니다.
내부적으로 특정 시점의 유효 한도는 간단하게 설명할 수 있습니다. 사용자의 지출은 두 예산 모두의 지배를 받으므로, 이번 달 현재까지의 사용량에 제어 불가능 방지 증액분 1회를 더한 값과 월별 최대 한도 중 더 작은 값으로 제한됩니다. 사용자가 차단되면 이 공식을 통해 어떤 상황에 처해 있는지 정확히 알 수 있습니다. 제어 불가능 한도에 도달한 경우 셀프 서비스 확인 후 사용을 재개할 수 있습니다. 월별 최대 한도에 도달한 경우 관리자와 논의해야 합니다.
일일 한도는 차단 해제가 진정으로 마찰 없이 이루어질 때만 효과가 있으므로, 우리는 대부분의 설계 노력을 이 경로에 집중했습니다. 엔지니어가 실제로 경험하는 과정은 다음과 같습니다.
사용자가 일일 한도의 약 90%를 초과하면 차단되기 전에 한도 인상 자격을 얻게 됩니다. 컨텍스트(오늘 지출한 금액, 남은 여유 한도)와 지출이 의도된 것임을 확인하는 단일 버튼이 포함된 Slack 알림이 전송됩니다. 이 버튼을 클릭하면 일일 한도가 즉시 한 단계 인상됩니다. 동일한 셀프 인상 기능은 내부 예산 포털과 CLI에서도 제공되며, CLI는 남은 일일 및 월별 할당량과 함께 둘 중 하나를 인상할 수 있는 링크를 출력합니다.
하루에 수행할 수 있는 셀프 확인 횟수에는 제한이 없습니다. 실제로 과중한 워크로드를 실행하는 엔지니어는 하루에 두세 번 증액을 확인할 수 있으 며, 이는 전혀 문제가 되지 않습니다. 각 확인은 "예, 제가 맞으며 의도적으로 수행하는 작업입니다"라고 말하는 인간의 의도적인 신호입니다. 관리되지 않는 cron 작업은 Slack 버튼을 클릭할 수 없습니다. 여기서 증액 단위의 크기가 중요합니다. 너무 작으면 알림이 소음이 되어 사람들이 생각 없이 클릭하게 만들고, 너무 크면 가드가 제 역할을 하지 못하게 됩니다. 우리는 월별 예산에 맞춰 원활하게 지출하는 엔지니어에게는 알림이 전혀 표시되지 않도록 크기를 조정했습니다.
한도가 사용자별로 임의의 값으로 유동적으로 변하게 두는 대신, 두 예산 모두 게이트웨이의 그룹 멤버십으로 구현된 소수의 고정된 등급을 통해 이동합니다. 모든 사람은 기본 등급에서 시작하며, 등급이 올라갈 때마다 고정된 단계만큼 임계값이 인상됩니다. 이를 통해 시스템의 가독성을 유지할 수 있습니다. 그룹 목록을 보면 누가 기본값보다 얼마나 더 높은 한도를 가지고 있는지 바로 알 수 있습니다.
두 예산은 각기 다른 역할에 맞게 서로 다른 방식으로 등급을 이동합니다.
일일 등급은 자동으로 조정됩니다. 모든 사용자는 기본 등급에서 한 달을 시작합니다. 사용자가 직접 확인(self-acknowledgement)할 때마다 등급이 한 단계씩 올라가며, 지출이 현재 한도에 가까워지면 예약된 작업(scheduled job)이 하루 최대 한 번 사용자의 등급을 선제적으로 올려주어 일반적인 사용이 중단되지 않도록 합니다. 월말이 되면 또 다른 작업이 실행되어 모든 사용자를 기본 등급으로 초기화합니다. 지난달에 많이 사용했더라도 이번 달의 여유 한도(headroom)로 이월되지 않습니다.
월간 등급은 신중하게 조정됩니다. 등급은 대략 2배, 5배에서 사실상 무제한까지 몇 단계만 존재하며, 등급을 올리려면 관리자나 상위 관리자의 승인이 필요합니다. 등급 상향은 이를 정당화하는 프로젝트 범위로 제한되며, 보통 1개월, 3개월 또는 6개월 동안 유지된 후 원래대로 복구됩니다. 이렇게 굵직한 단계로 구성하면 아무도 검토하지 않는 소액 증액 대신 지출에 대한 실질적인 논의를 유도할 수 있습니다. 월간 등급을 올리면 일일 증가분도 비례하여 확장되므로, 폭주 방지 장치(runaway guard)가 적절히 조정된 상태를 유지합니다.
맞춤형 인프라가 거의 없이도 이 방식이 작동하는 이유는 Unity AI Gateway가 이미 모든 것을 모니터링하고 있기 때문입니다. Claude, GPT, Gemini 또는 오픈 소스 모델 등 모든 코딩 에이전트의 모든 요청은 사용자 ID로 귀속되며 한 곳에서 측정됩니다. 게이트웨이에 구성된 예산은 엔지니어가 사용하는 모든 도구에 적용되며, 지출은 적용 가능한 예산을 초과할 수 없습니다. 이 마지막 특징 덕분에 추가 비용 없이 "두 한도 중 최소값" 동작을 구현할 수 있습니다. 두 예산을 모두 정의하면 두 예산이 언제나 동시에 적용됩니다.
일일 및 월간 등급은 예산의 사용자별 임계값 재정의(thresholds overrides)를 서로 다른 그룹에 할당하여 구현됩니다. 그리고 등급 상향은 일일 자동화, 사용자 직접 확인, 관리자 승인을 통해 사용자를 더 높은 등급의 그룹에 구성원으로 추가함으로써 이루어집니다.
게이트웨이가 이 모든 사용량 데이터를 Unity Catalog에 저장하기 때문에 관측 가능성(observability) 측면의 이점도 비용 없이 누릴 수 있습니다. 관리자는 자체 코딩 에이전트 벤치마크를 구축한 것과 동일한 Lakehouse 테이블에서 팀 수준의 지출을 확인할 수 있으며, 재무 부서는 5개의 청구서 대신 단 하나의 청구서만 받게 됩니다.
중단 중심의 승인 대기열(interrupt-driven approval queue)이 사라졌습니다. 새로운 모델에서는 사용량이 가장 많은 극소수의 사용자만 일일 한도에 도달할 것으로 예상되며, 이 경우에도 단 한 번의 확인 클릭으로 해결됩니다. 월간 한도 증액은 엔지니어마다 반복되던 번거로운 작업에서 관리자가 프로젝트 범위에 맞춰 가끔 결정하는 드문 일로 바뀌었습니다.
이에 못지않게 중요한 점은 엔지니어들이 사용량을 제한(rationing)하지 않게 되었다는 것입니다. 이러한 가드레일의 목적은 AI 사용량을 줄이는 것이 아니었습니다. 무제한으로 발생하는 비용에 대한 두려움을 없애고 도입을 계속 확대하기 위함이었습니다. 이제 지출은 예방 차원에서 제한하는 대상이 아니라, 데이터를 기반으로 유연하게 조정하는 대상이 되었습니다.
사용 패턴이 진화함에 따라 수치를 계속 조정하고 있으며, 내부적으로 입증된 패턴은 Budgets 제품 자체에 반영되고 있습니다. 여기에는 기본 일일 예산 주기, 예산 주기와 함께 만료되는 임시 재정의, 사전 정의된 재정의 그룹보다 더 유연하게 예산 API를 통해 최종 사용자가 직접 일일 임계값을 높일 수 있는 권한 모델 등이 포함됩니다.
또한 더 스마트 한 모델 라우팅을 통해 비용이 많이 드는 경로를 애초에 줄이는 작업을 진행 중입니다. 이를 통해 일상적인 작업은 효율적인 모델에서 처리하고, 프런티어 모델(frontier models)은 꼭 필요한 작업에만 사용할 수 있도록 합니다. 이에 대한 자세한 내용은 후속 게시물에서 다루겠습니다.
조직에서 코딩 에이전트를 확장하고 있는데 도구마다 자체 예산 콘솔이 있다면, 저희가 직접 사용한 것과 동일한 해결책을 적용해 보세요. 현재 모든 Databricks 고객은 Unity AI Gateway에서 코딩 에이전트 지원을 이용할 수 있습니다. 시작하려면 문서를 확인해 보세요.
(이 글은 AI의 도움을 받아 번역되었습니다. 원문이 궁금하시다면 여기를 클릭해 주세요)
블로그를 구독하고 최신 게시물을 이메일로 받아보세요.