AI 코딩 도구는 엄청난 가치를 제공합니다. Databricks에서 에이전트 기반(agentic) 코딩은 우리가 추적하는 모든 속도 지표를 측정 가능하게 개선했으며, 일부 팀에서는 출력량에 있어 한 자릿수(order-of-magnitude)의 성장을 이끌었습니다. 그러나 대규모로 AI 도구를 배포하는 거의 모든 회사가 같은 벽에 부딪혔습니다: * 기하급수적으로 증가하는 비용*. 그 곡선은 지속 가능하지 않습니다. 방치할 경우 결국 수익을 초과하게 될 것입니다. 이러한 지출 폭증은 기업들을 역설적인 상황에 놓이게 했습니다. 한편으로는 AI 혁신을 최대한 추진하고 강력한 도구를 직원들에게 제공하기를 원하면서도, 다른 한편으로는 AI가 제공하는 효율성 증가 자체를 훼손하거나 심지어 되돌릴 수 있는 총 비용 구조와 화해해야 하는 상황입니다.

다행히도, 초기 대규모 도입을 진행했던 여러 기업들이 이 퍼즐을 해결하는 일련의 접근 방식에 수렴했습니다. 이는

새로운 모델이 출시됨에 따라 코딩 비용을 더 효율적인 모델로 전환할 때 가장 강력한 비용 조절 레버(cost lever)입니다. 이 지점은 어느 정도 논의가 필요한데, 단순히 "더 저렴한 모델"이라고 설명하는 방식은 사실 모델의 비용과 품질 사이의 미묘한 관계를 숨기고 있기 때문입니다.

일상적인 용어로 *프런티어 모델 (frontier model)*은 "가장 높은 지능을 가진 모델"을 의미하며, *프런티어 연구소 (frontier labs)*는 주로 정점의 지능을 높이는 데 집중합니다. 프런티어 모델은 이제 수학이나 사이버 보안 분야에서 새로운 문제를 해결할 수 있습니다. 하지만 AI가 대규모로 배포될 때는 다른 유형의 프런티어가 더 중요해집니다. 바로 *효율성 프런티어 (efficiency frontier)*입니다. **효율성 프런티어는 특정 지능 수준에 대해 가장 좋은 가격대 (best price point)를 가진 모델들의 집합으로 정의됩니다. 대부분의 일상적인 코딩은 수학적 증명이나 새로운 보안 통찰력을 필요로 하지 않으므로, 총체적으로 중요한 것은 일반적인 소프트웨어 엔지니어링 작업의 품질 기준을 충족하는 모델의 비용입니다. 이 "효율성 프런티어"는 지능 프런티어보다 훨씬 빠르게 발전하고 있으며, 이전 모델보다 단위 가격당 더 나은 지능을 제공하는 새로운 모델들이 거의 매주 출시되고 있습니다.

더 새롭고 효율적인 모델을 빠르게 채택하는 것은 그 어떤 기술보다 가장 큰 비용 절감 효과를 가져다줍니다. 하지만 이러한 이득을 취하기 위해서는 기업이 먼저 어떤 모델이 실제로 기존에 사용하던 모델(incumbents)보다 뛰어난지 알아야 합니다. 이는 공공 벤치마크(public benchmarks)가 코딩 작업에서의 실제 성능을 나타내는 데 미흡하기 때문에 어려울 수 있습니다. 새로운 모델의 규모를 측정하기 위해, 많은 기업은 자신들의 내부 개발 구성(internal development mix)을 더 잘 대표한다고 믿는 자동화된 평가(automated evaluations) 시스템을 구축해 왔습니다. Databricks는 최근 이러한 벤치마크의 한 사례를 발표했으며, 이를 통해 GLM 모델의 매우 경쟁력 있는 가격 대비 성능(price/performance)을 관찰했습니다. 해당 벤치마크를 바탕으로 우리는 내부 개발자들에게 GLM을 배포했습니다. 종종 새로운 모델이 효율성 프런티어(efficiency frontier)를 진전시키지 못하는 경우도 있으며, 평가는 빈번하게 부정적인 결과를 도출합니다. 예를 들어, Stripe는 Opus 4.7이 Opus 4.6보다 비용은 증가시키면서 품질은 유의미하게 개선하지 못한다는 것을 발견했습니다. 따라서 그들은 Opus 4.7을 내부적으로 사용할 수 없게 결정했습니다. Databricks 또한 Opus 5.0을 4.8과 비교했을 때 유사한 비용 퇴보(cost regressions)를 목격했습니다.

가장 큰 이득은 새로운 모델로 전환하는 데서 오기 때문에, 모델 유연성(model flexibility)을 허용하는 엔드 유저 툴링(end user tooling)을 채택하는 것이 비용을 낮게 유지하는 데 있어 중요한 요소가 되고 있습니다. 특정 모델과 관련하여 가장 흔히 사용되는 도구는 하네스(harness)라고 불립니다. 독점적인 프런티어 모델(Proprietary frontier models)들은 특정 하네스와 잘 작동하도록 공동 설계(co-designed)되는 경우가 점점 늘어나고 있으며, 이는 특정 하네스가 특정 모델과 함께 사용할 때

사용자에게 하네스(harness) 전환을 요청하기. 한 가지 접근 방식은 개발자에게 일련의 하네스(Claude Code, Codex 또는 Cursor)를 제공한 다음, 회사가 비용이 더 낮은 모델로 지출을 이전하고자 할 때 하네스 간의 전환을 요청하는 것입니다. 이를 통해 사용자는 가능한 경우 선호하는 하네스에서 작업할 수 있지만, 이 방식의 단점은 개별 개발자의 전환 비용(switching costs)이 높을 수 있다는 점입니다. 만약 전환 비용이 너무 높아지면, 하네스 자체가 특정 모델 제품군에 대한 사실상의 락인(lock-in)이 되어, 더 경쟁력 있는 모델로 지출을 이동시키는 능력을 제한하게 됩니다.

메타-하네스(meta-harness) 사용하기. 새롭고 점점 더 인기를 얻고 있는 접근 방식은 개발자에게는 공통된 사용자 경험을 제공하면서, 하부의 하네스들(독점 모델 및 오픈 소스 모두 포함)로 요청을 전달하는 *메타-하네스(meta-harness)*를 사용하는 것입니다. 이 방식은 모델/하네스에 대한 독립성을 보장하는 동시에 개발자의 전환 비용을 줄여줍니다. Databricks에서는 Omnigent를 활용하는 개발자들에게 이것이 기본 모드입니다. 우리가 대화한 일부 기업들은 자신들의 개발 툴체인(toolchain)과 통합되는 맞춤형 내부 메타-하네스를 구축하기도 했습니다.

사용자가 직접 작업에 적합한 모델을 선택하도록 요청하는 대신, 점점 더 많은 연구 결과는 자동화된 모델 및 도구 선택이 에이전트 기반 코딩 워크플로우(agentic coding workflows)에서 효율성을 더욱 극대화할 수 있음을 시사합니다. 라우팅(routing) 접근 방식은 대략 세 가지 범주로 나뉩니다:

image9.png

이 기사 전체가 "사용자에게 월간 예산을 할당하고 끝내라"라는 말로 시작해서 끝나지 않았다는 점이 놀라울 수도 있습니다. 특정 지출 임계값에 도달하면 사용을 완전히 차단하는 강제 예산(Hard budgets) 방식은 우리가 인터뷰한 모든 기업에서 대개 최후의 수단으로만 사용됩니다. 강제 토큰 예산이 AI 지출 관리(AI spend management)에 특별히 효과적이지 않은 데에는 두 가지 이유가 있습니다. 첫째, 개발자가 예산 상한선에 도달했을 때 AI 도구에 대한 추가 접근을 차단하는 것은 생산성에 치명적일 수 있습니다. 회사나 직원 모두 실제로 그런 결과를 원하지 않습니다. 둘째, "고액 지출" 사용자 중 적어도 일부는 사실 AI를 통해 엄청난 효율성 향상을 달성하여 막대한 결과물을 만들어내고 있는 사람들입니다. 이러한 사용자들을 저지하는 것은 자기 파괴적인 행동입니다.

대부분의 기업은 강제적인 사용자 지출 상한선 대신, 최종 사용자에 대한 가시성(visibility)에 집중하고 지출이 증가함에 따라 마찰(friction)의 정도를 높이는 더 미묘하고 점진적인 접근 방식을 채택하고 있습니다.

**가시성(Visibility): **우리가 인터뷰한 모든 기업은 사용자에게 현재 진행 중인 지출에 대해 거의 즉각적인 피드백을 제공하는 메커니즘을 갖추고 있었으며, 많은 기업이 더 저렴한 모델을 사용하여 지출을 줄이는 방법에 대한 구체적인 팁이나 인사이트도 제공하고 있었습니다. 사용자가 가장 높은 ROI(투자 대비 효율)를 얻을 수 있는 도구를 선택할 수 있도록, 모든 도구에 걸친 지출 현황을 사용자가 직접 확인할 수 있게 하는 것이 중요합니다.

Managing AI Coding Costs at Scale

활성 지출을 보여주는 Databricks의 개발자 대시보드

사용자가 AI 코딩 에이전트(AI coding agent)에 비교적 간단한 요청(예: "이 버그를 조사하고 수정해 주세요.")을 입력하면, 해당 에이전트는 이후 방대한 양의 관련 컨텍스트 (context)를 수집하고, 수많은 도구 (tools)를 호출하며, 코드베이스 (codebase)를 검색하고, 기업에서 제공하는 기술이나 시스템 정보를 통합합니다. 비용이 많이 드는 LLM 추론 (inference)이 발생할 때쯤이면, 사용자의 초기 발언은 AI 시스템에 입력되는 데이터 중 아주 미미한 부분만을 차지하게 됩니다. 즉, 비용은 사용자가 명시적으로 포함하지 않은 컨텍스트에 의해 좌우된다는 의미입니다. 컨텍스트 팽창 (context bloat)을 줄이는 기술은 아직 초기 단계이지만, 다음과 같은 몇 가지 유망한 접근 방식들이 탐구되고 있습니다:

컨텍스트가 커질 때, 프롬프트 캐싱 (prompt caching) 또한 전반적인 성능에 유의미한 역할을 합니다. 독점적 (proprietary) LLM과 오픈 소스 (open source) LLM 모두 프롬프트 캐싱을 활성화하고 캐시 저장 기간을 조정할 수 있는 설정을 가지고 있습니다. 캐시 쓰기 (cache writes)에는 비용이 발생하지만, 캐시 읽기 (cached reads)는 추론당 비용을 획기적으로 줄일 수 있습니다. 이러한 트레이드오프 (trade-off)는 기업의 특정 워크로드 (workload)에 따라 달라지므로, 전반적인 캐시 적중률 (cache hit rate)을 높이기 위해 기본 캐시 설정을 수동으로 조정하는 것만으로도 전체 비용을 크게 개선할 수 있습니다.

Databricks에서는 우리의 하네스 (harness) 및 캐싱 설정을 비교적 간단하게 튜닝하는 것만으로도, 개발자들에게 관찰되는 품질 저하 없이 생성된 토큰 (tokens) 수와 관련 비용을 거의 50%까지 절감했습니다. 우리는 이 분야의 기술을 계속해서 탐구하고 있으며, 의미 있는 추가 최적화가 여전히 가능할 것이라고 생각합니다.

불필요한 추론 호출을 제거하고 캐시 쓰기를 줄임으로써 세션당 토큰을 획기적으로 감소시킨 사례.

위의 기술들은 여러 가지 암묵적인 기술적 요구사항을 수반합니다. 새로운 모델을 신속하게 활용하기 위해 기업은 "모델 메뉴 (model menu)"가 관리되는 중앙 위치를 보유해야 하며, 최종 사용자는 모델 혼합 (model mixing)을 지원하는 툴체인 (toolchain)을 갖추어야 합니다. 여러 AI 도구에 걸친 예산 가시성을 제공하기 위해서는 통합된 비용 관측성 (cost observability) 기능이 존재해야 합니다. 컨텍스트 팽창 (context bloat)을 관리하기 위해 기업은 전형적인 도구 호출 (toolcall) 출력을 관찰하고 압축 (compression) 또는 컴팩션 (compaction)을 강제할 수 있는 방법이 필요합니다. 이러한 요구사항들은 집합적으로 **AI 게이트웨이 (AI Gateway)**라고 가장 잘 설명되는 새로운 클래스의 인프라 소프트웨어에 의해 해결되고 있습니다. AI 게이트웨이는 다음의 모든 사항이 발생하는 중앙 위치입니다:

Databricks에서는 이러한 모든 기능을 위해 Unity AI Gateway에 크게 의존하고 있습니다.

AI 코딩 비용의 기하급수적인 성장은 피할 수 없는 숙명이 아니라, 해결 가능한 엔지니어링 및 거버넌스 문제입니다. 이를 길들인 기업들은 공통된 플레이북 (playbook)을 공유합니다. 즉, 지능의 경계 (intelligence frontier)보다는 효율성의 경계 (efficiency frontier)를 끊임없이 추구하고, 모델 유연성을 유지하는 도구를 채택하며, 작업을 수행 가능한 가장 저렴한 모델로 지능적으로 라우팅하고, 경직된 예산 대신 가시성과 점진적 마찰 (progressive friction)을 도입하며, 실제 지출의 대부분을 차지하는 토큰 오버헤드 (token overhead)를 절감하는 것입니다. 이러한 기술 중 그 어느 것도 AI 도입을 가치 있게 만들었던 생산성 이득을 희생할 것을 요구하지 않습니다. 이 기술들은 결합되어 조직이 예측 가능한 비용 범위 내에서 광범위하고 마찰이 적은 접근성이라는 이중 명령을 충족할 수 있게 해줍니다.

기업들이 비용을 관리할 수 있는 도구를 제공하기 위해 새로운 인프라 추상화 (infrastructure abstractions) 세트가 등장하고 있습니다. Databricks에서는 비용 관리 스택의 핵심 구성 요소를 오픈 소스 또는 무료 소프트웨어 제품으로 출시했습니다. 중앙 관리를 위한 Unity AI Gateway와 개발자 도구를 위한 Omnigent가 그 예입니다. 수천 개의 기업이 매일 이 구성 요소들을 사용하고 있습니다. 우리는 이 기술 환경이 급격히 진화함에 따라 더 많은 기업이 발견한 내용을 공유하고 기술을 비교해 보기를 권장합니다.

Acknowledgements: 이 기사에 대한 논평과 검토를 제공해 주신 Uber, Stripe, Coinbase, Ramp의 인프라 리더분들께 감사드립니다. 이 기사의 초기 초안에 대해 피드백을 주신 Thrive Capital에도 감사드립니다.