Skip to main content
원문: Managing AI Coding Costs at Scale 저자: Patrick Wendell, Akshat Bhatia, Vinay Gaba, Erich Elsen, Ivan Zhou 게시일: 2026년 8월 7일

요약

  • AI 코딩 도구는 큰 가치를 만들지만 비용이 기하급수적으로 증가합니다. 방치하면 결국 매출을 넘어섭니다. 목표는 “넓고 마찰 없는 접근”과 “사용자당 거의 고정된 비용 봉투(envelope)“라는 이중 명령(dual mandate)을 동시에 만족시키는 것입니다.
  • Stripe, Coinbase, Uber, Ramp 등 대규모 초기 도입 기업들이 수렴한 4가지 레버는 효율 프런티어 모델 채택, 동적 요청·작업 라우팅, 가시성과 점진적 마찰(하드 캡 대신), 토큰 오버헤드 축소입니다.
  • 이 기법들을 뒷받침하는 중앙 인프라가 AI Gateway 패턴입니다. Databricks는 이 역할을 Unity AI Gateway로, 개발자 도구는 Omnigent로 제공합니다.

Databricks에서 AI 코딩 도구는 실질적인 가치를 만들어 왔습니다. 에이전트 기반 코딩은 우리가 추적하는 모든 속도(velocity) 지표를 개선했고, 일부 팀에서는 자릿수(order-of-magnitude) 단위의 향상을 이끌어냈습니다. 그러나 여기에는 결정적인 문제가 따라옵니다 — 기하급수적으로 증가하는 비용입니다. 통제하지 않으면 이 비용은 언젠가 매출을 넘어섭니다. 조직은 AI 도구 도입을 최대한 넓히고 싶어하지만, 동시에 감당하기 어려운 지출에 직면하는 역설에 놓입니다. Stripe, Coinbase, Uber, Ramp 같은 대규모 초기 도입 기업들은 이 문제를 놓고 비슷한 접근으로 수렴했습니다. 우리는 이를 이중 명령(dual mandate) 이라고 부릅니다 — 마찰을 최소화하면서 AI에 대한 넓은 접근을 제공하되, 전체 비용은 사용자당 대략 고정된 봉투(envelope) 안에 유지하는 것입니다. 기법별 비용 절감 방향성 — 개발자 팀 대상 비공식 설문 기반

코딩 모델의 “효율 프런티어”

여기서 두 가지 개념을 구분해야 합니다. 프런티어 모델(frontier model) 은 전통적으로 “가장 높은 지능”을 가진 시스템을 뜻합니다. 프런티어 연구소들은 수학이나 사이버보안 같은 새로운 난제를 풀기 위해 최고 성능을 끌어올립니다. 반면 효율 프런티어(efficiency frontier) 는 “주어진 지능 수준에서 가장 좋은 가격대를 가진 모델들의 집합”을 의미합니다. 대규모 배포에서는 이쪽이 훨씬 중요합니다. 일상적인 코딩 작업 대부분은 돌파구 수준의 능력을 필요로 하지 않기 때문입니다. 게다가 효율 프런티어는 지능 프런티어보다 더 빠르게 전진합니다 — 능력 대비 비용 비율이 더 나은 새 모델이 거의 매주 출시됩니다.

비용 레버 #1: 오픈소스와 저비용 모델로 이동하기

가장 큰 비용 절감은 더 새롭고 효율적인 모델을 빠르게 채택하는 데서 나옵니다. 다만 기업은 어떤 모델이 기존 모델을 실제로 능가하는지 가려내야 합니다. 공개 벤치마크는 현실 코딩 성능을 잘 나타내지 못하기 때문입니다. Databricks는 수백만 라인 규모의 자체 코드베이스에서 벤치마크를 수행해 GLM 계열 모델이 경쟁력 있는 성능을 낸다는 것을 확인했고, 이를 근거로 내부에 GLM을 도입했습니다. Stripe는 Claude Opus 4.7이 4.6 대비 의미 있는 개선이 없으면서 비용만 늘어난다는 것을 발견하고 도입하지 않았습니다. Databricks도 Opus 5.0을 4.8과 비교했을 때 비용 측면에서 후퇴(regression)가 있음을 관찰했습니다.

하네스와 모델의 유연성

독점 프런티어 모델은 점점 특정 하네스(harness)와 함께 설계(co-design)되고 있어, 락인(lock-in) 위험이 생깁니다. 유연성을 지키는 방법은 두 가지입니다.
  • 사용자에게 하네스를 바꾸게 하기 — 개발자가 선호하는 도구(Claude Code, Codex, Cursor 등)에서 계속 일하게 하면서 기업이 지출을 이동시키는 방식입니다. 단점은 전환 비용이 지나치게 높아질 수 있다는 점입니다. 이 경우 하네스가 사실상 모델 락인이 됩니다.
  • 메타 하네스(meta-harness) 사용하기 — 통합된 사용자 경험을 제공하면서 그 아래의 여러 하네스(독점·오픈소스)로 작업을 디스패치합니다. 개발자 마찰을 줄이면서 독립성을 지킵니다. Databricks는 Omnigent로 이 방식을 씁니다. 다른 기업들은 내부용 메타 하네스를 직접 구축하기도 했습니다.

비용 레버 #2: 동적 요청·작업 라우팅

자동 모델 선택은 사용자가 직접 고르는 것보다 에이전트 코딩의 효율을 더 끌어올릴 수 있습니다. 라우팅은 크게 세 가지 범주로 나뉩니다. 요청·작업 라우팅과 에스컬레이션 패턴
  • 요청 수준 라우팅(Request Level Routing) — 클라이언트와 파운데이션 모델 사이에 상태를 가진 프록시(stateful proxy)를 두고, 각 추론 요청을 처리 가능한 가장 저렴한 모델로 보냅니다. 큰 컨텍스트 워크로드에서는 캐시 고려가 중요합니다. 예로 Cursor Router, OpenRouter의 AutoRouter, Ramp의 Router, 그리고 Unity AI Gateway의 Smart Routing이 있습니다.
  • 작업 수준 라우팅(Task Level Routing, 메타 하네스) — 사용자 작업을 복잡도에 따라 서로 다른 하네스로 디스패치합니다. 단순 이름 변경(renaming)과 개방형 설계 탐색(open-ended design)을 구분하는 식입니다. 디스패처가 필요한 모델 수준을 판단해 작업 전체를 위임합니다. Omnigent가 이 패턴의 예입니다.
  • 에스컬레이션·위임 패턴(Escalation/Delegation) — 하나의 하네스 안에서 비싼 모델과 저렴한 모델을 짝지웁니다. Claude의 Advisor Tool은 저렴한 모델이 주 작업을 수행하다가 필요할 때 에스컬레이션합니다. Cognition의 Devin Fusion은 반대로, 비싼 모델이 작업을 관리하면서 저렴한 대안에 아웃소싱합니다.
Databricks의 AI Gateway Smart Router는 가장 비싼 모델과 거의 동등한 품질을 유지하면서 평균 작업 비용을 30% 이상 꾸준히 낮췄습니다. 다른 기업들도 비슷한 결과를 보고합니다.

비용 레버 #3: 개발자에게 가시성·트립와이어·예산 주기

하드 스펜딩 캡(hard spending cap)은 역효과를 냅니다. 개발자가 예산 상한에 부딪혀 접근이 끊기면 생산성이 손상됩니다 — 기업도 직원도 원치 않는 결과입니다. 게다가 지출이 많은 사용자는 대개 산출물도 그만큼 많아서, 지출 제한은 오히려 자기 파괴적입니다. 그래서 기업들은 가시성과 점진적 마찰을 강조하는 방식을 씁니다.
  • 가시성(Visibility) — 설문에 응한 모든 기업이 사용자에게 거의 실시간으로 지출 피드백을 제공하며, 흔히 모델 선택을 통한 비용 절감 권고도 함께 줍니다. 사용자는 여러 도구에 걸친 자신의 지출을 볼 수 있어야 합니다. ROI가 가장 높은 도구로 선택을 조정하고 싶어할 수 있기 때문입니다.
Databricks의 개발자 대시보드 — 실시간 지출 현황
  • 스펜드 게이트(Spend Gates) — 지출이 늘어남에 따라 개발자가 특정 행동을 하거나 승인을 받도록 하는 장치입니다. 자기 해제(self-clearing) 게이트는 접근을 막지 않고 경고만 합니다. 그 위 단계의 게이트는 관리자 승인을 요구합니다. Databricks는 자기 해제 게이트가 우발적·의도치 않은 지출을 막는 데 유용한 메커니즘임을 확인했습니다.
  • 다운시프팅(Downshifting) — 접근을 완전히 중단하는 대신, 개발자를 더 저렴한 모델로 전환합니다. 큰 지출 없이도 작업을 계속할 수 있게 합니다.
  • 정지(Suspension) — 최후의 수단으로 남겨둡니다. 토큰 접근을 완전히 정지하면, 대개 “AI를 어떻게 효율적으로 활용할 것인가”에 대한 대화가 시작됩니다.

비용 레버 #4: 토큰 오버헤드 줄이기

사용자가 AI 코딩 에이전트에 단순한 요청을 보내도, 시스템은 방대한 컨텍스트를 모으고 수많은 도구를 호출하며 코드베이스를 검색합니다. 결과적으로 사용자의 최초 문장은 추가된 컨텍스트에 비하면 미미해지고, 비용은 사용자가 명시적으로 포함하지 않은 컨텍스트가 지배하게 됩니다. 떠오르는 기법은 다음과 같습니다.
  • 더 잦은 컨텍스트 압축(compression) 강제
  • 토큰 효율적인 하네스 사용, 또는 기존 하네스의 장황함(verbosity)을 줄이도록 튜닝
  • 도구(tool) 감사로 출력 장황함 축소
  • 개발자가 작업을 더 작은 단위로 분해하도록 유도
프롬프트 캐싱(prompt caching)은 성능에 큰 영향을 줍니다. 독점·오픈소스 LLM 모두 캐싱 설정을 지원합니다. 캐시 쓰기(cache write)에는 비용이 들지만, 캐시 읽기(cached read)는 추론당 비용을 크게 낮출 수 있습니다. Databricks에서는 하네스와 캐싱 설정을 비교적 단순하게 튜닝한 것만으로도 생성 토큰 수와 관련 비용을 거의 50% 줄였고, 개발자 관점에서 품질 저하는 관찰되지 않았습니다. 세션당 토큰의 급격한 감소 — 불필요한 추론 호출 제거와 캐시 쓰기 축소

AI Gateway 디자인 패턴

앞의 기법들은 모두 중앙 인프라를 필요로 합니다. 빠른 모델 채택에는 중앙집중식 모델 관리가, 예산 가시성에는 통합된 비용 관측(observability)이, 컨텍스트 최적화에는 도구 호출 출력의 관찰과 강제(enforcement)가 필요합니다. AI Gateway 는 이 요구를 다음으로 해결합니다.
  1. 독점·오픈소스 모델에 대한 용량(capacity) 관리와 프록싱
  2. 점진적 마찰, 모델 다운시프팅 같은 복잡한 정책을 포함한 예산 추적
  3. 최종 사용자 도구에 대한 구성 관리 — 모델 허용 목록(allowlist)과 컴팩션(compaction) 설정 강제
  4. 코딩 세션 트레이스 로깅 — 효율 분석과 벤치마킹
Databricks는 이 모든 기능을 Unity AI Gateway 에 의존합니다.

정리하며

AI 코딩 비용의 기하급수적 증가는 불가피한 것이 아니라 풀 수 있는 엔지니어링·거버넌스 문제입니다. 비용을 성공적으로 관리하는 조직들은 공통된 실천을 공유합니다 — 지능 프런티어보다 효율 프런티어를 추구하고, 유연한 모델 도구를 채택하며, 작업을 처리 가능한 저비용 모델로 지능적으로 라우팅하고, 하드 예산을 가시성과 점진적 마찰로 대체하며, 토큰 오버헤드를 제거합니다. 이 기법들 중 어느 것도 애초에 AI 도입을 가치 있게 만든 생산성 향상을 희생하지 않습니다. 이들을 함께 적용하면, 조직은 예측 가능한 비용 봉투 안에서 넓고 마찰 없는 접근이라는 이중 명령을 만족시킬 수 있습니다. Databricks는 핵심 인프라를 오픈소스 또는 무료 제품으로 공개했습니다 — 중앙 관리용 Unity AI Gateway 와 개발자 도구용 Omnigent 입니다. 수천 개 기업이 매일 이 구성요소들을 사용하고 있습니다. 감사의 말: 논평과 리뷰를 제공해 준 Uber, Stripe, Coinbase, Ramp의 인프라 리더들에게 감사드립니다.