Databricks의 공동 창립자 Patrick Wendell이 AI 코딩 비용이 기하급수적으로 증가하는 이유와, 엔지니어링 리더가 팀의 작업 속도를 낮추지 않고 상승 곡선을 꺾을 수 있는 방법을 설명 합니다.
작성자: 캐서린 브라운
이번 대담에서 Catherine Brown은 Patrick과 함께 Databricks가 AI 코딩 에이전트에 적극적으로 투자했을 때 일어난 일에 대해 이야기합니다. 사용량 증가에 따라 초기에 비용이 어떻게 폭증했는지, 실제로 단가 비용을 최대 90%까지 낮춘 요인은 무엇이었는지, 그리고 왜 모든 엔지니어링 조직이 개발자와 모델 사이에 제어 계층을 두어야 하는지 다룹니다. 이 제어 계층은 Databricks 자체의 AI 비용 문제를 해결하기 위한 내부 솔루션으로 시작하여 Unity Gateway의 영감이 되었습니다.
Catherine: Databricks의 AI 제품을 총괄하면서 내부적으로 AI 도입을 주도해 오셨는데요. 왜 이 과제가 개인적으로도 그토록 중요한 우선순위가 되었나요?
Patrick: 엔지니어링 산출물이 우리 비즈니스의 주요 병목 요소이기 때문입니다. 모든 기업은 엔지니어링 팀이 더 빠르게 움직이길 원하며, 생산성을 의미 있게 향상시킬 수 있는 수단을 제공할 수 있다면 그 가치는 매우 큽니다. 초기 대화형 제품들도 어느 정도 유용했지만, 약 1년 전 진짜 뛰어난 코딩 모델들이 등장하면서 ROI가 비로소 크게 전환되었습니다.
Catherine: AI 툴을 통해 실제로 생산성 향상 효과를 얻고 있는지 어떻게 확인하시나요?
Patrick: 저희는 풀 리퀘스트, 배포된 기능, 코드 줄 수 등 다양한 산출물 지표를 추적합니다. 개별 지표만으로는 완벽하지 않습니다. 저는 R&D를 하나의 거대한 머신으로 생각합니다. 리소스를 투입하면 기능과 코드가 산출되며, 얼마나 더 많은 결과물이 나오는지 측정할 수 있죠. 종합적으로 볼 때, 동일한 팀으로 산출물을 거의 두 배 가까이 늘리고 있습니다. AI 중심으로 프로세스를 개편한 팀들은 그보다 훨씬 빠른 속도로 나아가고 있습니다.
Catherine: Databricks가 AI 코딩 툴을 처음 도입했을 때 시행착오는 무엇이었나요?
Patrick: 재미있게도 처음에는 반대의 문제가 있었습니다. 아무도 새로운 툴을 시도하려 하지 않았죠. 그래서 제가 직접 사람들을 설득하고 다녔습니다. 결국 다른 기업들과 마찬가지로 모든 장벽을 제거했습니다. 가장 비싼 모델을 원하는 만큼의 토큰으로 마음껏 쓰게 했죠. 좋은 의도에서 시작한 일이었습니다. 사람들이 첫 고비를 넘기도록 도우려 했던 것이죠.
하지만 사람들이 실제로 사용하기 시작하면서 비용 곡선이 기하급수적으로 상승했습니다. 이제 이러한 툴은 계정당 고정 비용이 아닌 사용량 기반 요금제이므로, 단 한 명의 사용자도 이론적으로 한도 없이 비용을 지출할 수 있습니다. 가장 비싼 모델로 작은 루프를 실행해 두고 점심을 먹으러 갈 수도 있는 것이죠. 그 루프가 정말 가치 있는 작업을 수행 중일 수도 있지만, 단지 토큰을 낭비하는 것일 수도 있습니다. 매출은 늘 지 않는데 비용만 기하급수적으로 증가한다면 결국 문제에 봉착하게 됩니다. 한때는 비용 상승이 도입의 본래 목적이었던 효율성 이점을 상쇄할 지경에 이르기도 했습니다.
그때 제가 직접 깊이 관여하기 시작했습니다. Coinbase, Uber, Stripe 등 AI를 대규모로 도입하고 있던 다른 기술 기업의 리더들과 의견을 나누었죠. 놀랍게도 많은 기업이 유사한 접근 방식을 고민하고 있었습니다. 현재 Databricks의 인당 토큰 지출은 전체 사용량과 가치가 계속 상승함에도 불구하고 거의 평탄한 수준을 유지하고 있습니다.
Catherine: 대부분 기업의 첫 반응은 엄격한 지출 한도를 설정하는 것입니다. 이것을 시도해 보셨을 텐데, 어떤 결과가 나왔나요?
Patrick: 당연히 먼저 고려하게 되는 조치이며, 통제 메커니즘 자체는 필요합니다. 하지만 엄격한 차단은 좋지 않은 경험을 제공합니다. 작업 중간에 끊기게 되면 흐름이 깨지고 몇 시간의 작업 결과물을 잃을 수도 있습니다. 그리고 한도에 도달하는 사람들은 대개 가장 뛰어난 퍼포먼스를 내는 사용자들입니다. 이들을 차단하면 일부는 개인 계정을 사용하기 시작하고, 결국 관찰 가능성조차 사라지게 됩니다.
그래서 저희는 단계적으로 제약을 가하는 방식으로 전환했으며, Unity Gateway가 이 모든 과정을 처리합니다. 먼저 경고를 보내고, 승인 절차를 거친 후, 작업을 계속할 수 있도록 더 저렴한 모델로 다운시프트합니다. 실제로 차단하는 것은 최후의 수단입니다. 또한 모든 구성원에게 절감 팁과 함께 개별 지출 내역을 정기적으로 전송합니다. 이것만으로도 약 10%의 비용이 절감됩니다. 제가 아는 한 기업 은 모든 풀 리퀘스트에 모델과 비용을 직접 명시합니다. 사소한 작업에 비싼 모델을 사용하면 공개적으로 드러나게 되는 셈이죠. 아주 훌륭한 방식이라고 생각합니다.
Catherine: 비용 절감을 위한 4가지 레버에 대해 글을 쓰신 적이 있는데요. 그중 어떤 것이 가장 큰 영향을 미쳤나요?
Patrick: 저희가 가장 선호하는 방식은 다소 평범합니다. 더 뛰어나고 저렴한 모델이 계속 출시되면 트래픽을 그쪽으로 이동시키는 것입니다. 자체 모델 제공업체와 오픈소스 벤더를 통틀어 매주 5개 정도의 모델이 출시됩니다. 모든 모델이 비용 측면에서 진전을 이루는 것은 아니지만, 1~2주에 하나 정도는 의미 있는 개선을 보여줍니다. 이는 전반적인 수준을 높여줍니다. 아무것도 변경할 필요 없이 동일한 산출물을 더 적은 비용으로 얻을 수 있습니다. 복잡한 라우팅도 필요 없습니다.
체감 속도를 말씀드리자면, 최근 출시된 저렴한 모델 중 하나는 약 9개월 전 최고 성능 모델이 하던 작업을 작업당 비용의 약 1% 수준으로 처리합니다. 1년도 되지 않아 100배나 감소한 것입니다. 아직 예비 결과이지만 흐름은 명확합니다.
핵심은 실제로 전환을 실행해야 한다는 점입니다. 새로운 모델이 나왔는데 사내에서 아무도 쓰지 않는다면 아무 소용이 없습니다. 그래서 저희는 새 모델을 신속하게 평가하고 성능이 충분하면 워크로드를 빠르게 전환하는 역량을 키웠습니다. 모든 작업이 Unity Gateway를 거치기 때문에 단 한 곳에서 전환을 완료할 수 있고, 개발자는 아무것도 변경할 필요가 없습니다. 이것이 가장 큰 영향을 미친 조치였으며, 단독으로 50% 이상의 비용 절감 효과를 냈습니다. 여기에 라우팅, 지출 시각화, 토큰 오버헤드 단축까지 더해 일부 사례에서는 단가 비용을 최대 90%까지 낮췄습니다.
Catherine: 팀에서 Databricks의 수백만 줄에 달하는 코드베이스를 대상으로 코딩 에이전트 벤치마킹을 진행했는데요. 공개 벤치마크를 그대로 신뢰하지 않는 이유는 무엇인가요?
Patrick: 공개 벤치마크는 실제 보유한 코드에 대해 많은 것을 알려주지 못합니다. 평가 과제가 학습 데이터에 유출되기도 하고, 대규모 엔터프라이즈 코드베이스의 실제 형태와도 다릅니다. 그래서 저희는 리포지토리의 실제 풀 리퀘스트를 기반으로 자체 벤치마크를 구축하고 테스트를 직접 실행하여 평가합니다. LLM을 평가자로 사용하지 않는 이유는 정확한 답보다 그럴듯하게 보이는 답에 더 높은 점수를 주는 경향이 있기 때문입니다.
일부 결과는 사람들을 놀라게 했습니다. 오픈소스 모델인 GLM 5.2는 작업당 비용이 약 3분의 1 수준이면서도 Opus 4.8과 동일한 품질을 기록했습니다. 토큰당 가격이 1.7배 저렴한 한 모델은 더 많은 토큰을 소모하는 바람에 작업당 실제 비용이 더 많이 들었습니다. 또한 모델을 둘러싼 코딩 툴 환경인 하네스(harness) 역시 모델 못지않게 중요했습니다. 동일한 모델이라도 하네스가 다르면 비용 차이가 2배 이상 벌어졌습니다. 하네스 및 캐싱 설정을 조정하는 것만으로도 비용을 50% 가깝게 절감했습니다.
Catherine: 가장 저렴한 모델과 가장 비싼 모델의 격차는 100배에 달할 수 있습니다. 엔지니어링 리더들은 이러한 격차를 어떻게 바라보아야 할까요?
Patrick: 자동차에 비유해 볼 수 있습니다. 람보르기니가 있고, 혼다가 있고, 자전거가 있습니다. 모든 이동에 람보르기니가 필요한 것은 아니며, 대부분의 코딩 작업에는 가장 거대한 모델이 필요하지 않습니다.
Astra가 좋은 예입니다. 약 3,500명의 전체 엔지니어에게 Astra를 도입했으며, 저희가 알기로는 이러한 도입 사례를 공개적으로 공유한 첫 번째 기업입니다. 시스템 설계와 같은 고난도 작업에는 확실히 뛰어났습니다. 하지만 지출이 약 60% 증가했고, 기존 모델로도 충분히 처리할 수 있는 일상적인 작업에는 별다른 도움이 되지 않았습니다. 지출의 상당 부분은 다른 모델을 사용했어야 할 작업에 Astra를 사용하면서 발생한 낭비였습니다. 그래서 Unity Gateway 내에서 Astra 전용 예산을 별도로 부여했습니다. 난이도가 높은 문제에만 사용하도록 한 것이죠.
장기적으로 이것이 어느 방향으로 흘러갈지는 알 수 없습니다. 저렴한 모델이 일상적인 작업을 점점 더 많이 대체하고 있지만, 동시에 사람들도 AI에 더욱 어려운 문제를 맡기고 있습니다. 그것이 바로 핵심입니다. 어느 방향으로든 유연하게 조율할 수 있는 능력이 필요합니다.
Catherine: AI 비용은 구매의 문제가 아니라 인프라의 문제라고 주장하셨는데 요. 예산 설정이나 정책만으로는 왜 이 문제를 해결할 수 없나요?
Patrick: 예산도 도움이 되지만, 예산 자체가 어떤 요청을 어떤 모델로 처리할지 결정해주지는 못합니다. 그것이 바로 라우팅입니다. 구성 요소의 이름을 바꾸는 작업은 저렴한 모델로 보내고, 까다롭고 개방적인 문제는 성능이 뛰어난 모델로 보냅니다. Databricks의 Smart Router는 가장 비싼 모델 수준의 품질을 유지하면서 평균 작업 비용을 30% 이상 절감합니다. 또한 사용자에게 언제 더 비싼 모델을 써야 할지 일일이 판단하도록 요구하지 않아도 되게 해줍니다. 그 과정이 자동으로 이루어지기 때문입니다.
이 모든 것을 구현하려면 개발자와 모델 사이에 제어 계층이 필요합니다. 저희는 필요에 의해 이 계층을 구축했습니다. Claude Code, Codex, Cursor, 메타 하네스인 Omnigent 등 어떤 툴을 사용하든 모든 코딩 툴 트래픽이 단일 게이트웨이를 통과합니다. 이를 통해 비용이 어디로 흘러가는지 실제로 파악할 수 있었습니다. 이후 모든 고객이 동일한 문제를 겪고 있음을 깨닫고 이를 Unity Gateway라는 제품으로 출시했습니다. 현재 수천 명의 고객이 이 제품을 사용하고 있습니다.
Catherine: 라우팅 기술 역시 모델 자체만큼이나 치열한 경쟁 분야가 될까요?
Patrick: 저희의 의견도 같습니다. 모델의 마진이 줄어들수록 어떤 용도로 어떤 모델을 사용할지 파악하는 것이 매우 흥미로운 과제가 됩니다. 라우팅 모델은 매우 작고 빨라야 합니다. 또한 이를 잘 수행하기도 어렵습니다. 이러한 모델을 실제로 활용하는 측면에서는 여전히 많은 연구 과제가 존재하며, 이를 올바르게 해결하는 것에 상당한 IP가 있다고 생각합니다.
Catherine: 계속 늘어나는 AI 비용으로 고민하는 CTO에게 한 가지 조언을 해준다면 무엇인가요?
Patrick: 비용이 어디로 가고 있는지 파악하세요. 대부분의 기업은 투자 대비 효과는 커녕 팀별 또는 모델별로 AI에 얼마를 지출하고 있는지 파악하지 못합니다. 모델 앞에 게이트웨이를 두어 모든 트래픽이 한 곳을 거치도록 설정하면 이를 한눈에 볼 수 있습니다. 그 이후의 모든 작업은 훨씬 쉬워집니다. 그리고 속도를 줄이지 마세요. 생산성 향상은 실제로 일어납니다. 하지만 이러한 비용은 복리로 누적되므로, 방치하다 보면 지불해야 할 비용이 생각보다 훨씬 커질 것입니다.
엔지니어링 리더들에게 전하는 Patrick의 메시지는 AI 생산성과 비용 관리 중 하나를 선택할 필요가 없다는 것입니다. 이를 잘 실천하고 있는 기업들은 최고 수준의 모델에 대한 광범위한 접근성을 유지하고, 자사 코드로 새로운 모델을 테스트하며, 성능이 충분하다면 즉시 더 저렴한 모델로 이전하고, 개발자들에게 장벽 대신 가시성을 제공합니다. 이 모든 것의 밑바탕에는 AI 지출을 직접 확인하고 제어할 수 있게 해주는 단일 제어 레이어인 게이트웨이가 있습니다. Databricks에서는 이 레이어가 Unity Gateway가 되었습니다.
Databricks가 자체 AI 코딩 비용을 관리하는 방법에 대해 자세히 알아보려면 Patrick의 블 로그 "Managing AI Coding Costs at Scale"을 읽어보고 Databricks Unity Gateway를 체험해 보세요.
(이 글은 AI의 도움을 받아 번역되었습니다. 원문이 궁금하시다면 여기를 클릭해 주세요)
블로그를 구독하고 최신 게시물을 이메일로 받아보세요.