Databricks, AI 코딩 비용 70% 절감

• AI 코딩 도구는 생산성을 크게 높이지만, 규모가 커질수록 비용이 기하급수적으로 증가함

  • Databricks에서는 추적하는 모든 개발 속도 지표가 개선됐고, 일부 팀은 산출물이 10배 늘어남

  • 그러나 비용 증가를 방치하면 결국 매출을 넘어설 수 있어, 직원에게 강력한 도구를 폭넓게 제공하면서도 사용자당 총비용을 대략 고정된 범위에 묶어야 함

  • Databricks와 Stripe, Coinbase, Uber, Ramp의 경험을 종합하면 모델 효율화, 자동 라우팅, 점진적 예산 통제, 토큰 절감으로 접근성과 비용 예측 가능성을 함께 확보할 수 있음

• 일부 비용 절감책은 기존 소프트웨어로 적용할 수 있지만, 클라이언트를 수정하거나 모델 간 트래픽을 전환하려면 새 인프라가 필요함

  • Databricks는 사용자용 메타 하네스 Omnigent와 Unity AI Gateway를 오픈소스 또는 무료로 제공 중

코딩 모델의 효율 프런티어

• 가장 큰 비용 절감 수단은 출시되는 새 모델 중 필요한 품질을 더 낮은 가격에 제공하는 모델로 빠르게 전환하는 것

  • 일반적인 ‘프런티어 모델’은 수학·사이버보안의 새로운 문제까지 해결하는 최고 지능 모델을 뜻하지만, 대규모 도입에서는 주어진 지능 수준에서 가격이 가장 좋은 모델 집합인 ‘효율 프런티어’가 더 중요함

  • 일상적인 소프트웨어 개발 대부분은 수학 증명이나 새로운 보안 통찰까지 요구하지 않으므로, 통상적인 개발 작업의 품질 기준을 충족하는 데 드는 총비용이 핵심

  • 지능 대비 가격이 더 나은 모델이 거의 매주 나오면서 효율 프런티어는 지능 프런티어보다 훨씬 빠르게 전진하고 있음

• 비용 수단 1: 공개 벤치마크 대신 내부 업무를 반영한 평가로 오픈소스·저비용 모델을 선별함

  • 공개 벤치마크는 실제 코딩 성능을 제대로 보여주지 못하는 경우가 많아 여러 회사가 내부 개발 작업 구성을 반영한 자동 평가를 구축함

  • Databricks의 내부 업무형 벤치마크 사례에서는 GLM 모델이 가격 대비 성능에서 매우 경쟁력 있게 나타나 개발자에게 배포함

  • 새 모델이 항상 효율 프런티어를 개선하는 것은 아님

    • Stripe에서는 Opus 4.7이 Opus 4.6보다 비용은 늘면서 품질이 의미 있게 좋아지지 않아 내부 제공을 보류함

    • Databricks에서도 Opus 5.0을 4.8과 비교했을 때 비용이 악화되는 결과가 나옴

하네스와 모델 선택의 유연성

• 모델 전환이 가장 큰 절감 효과를 내므로, 특정 모델에 종속되지 않는 사용자 도구가 중요해짐

  • 코딩 에이전트의 사용자 도구인 하네스는 특정 모델과 함께 최적화되는 추세라, 하네스 선택이 사실상 모델 계열 종속으로 이어질 수 있음

• 모델 독립성을 유지하는 방법은 여러 하네스를 직접 전환하게 하거나 공통 경험을 제공하는 메타 하네스를 쓰는 것

  • Claude Code, Codex, Cursor 등을 제공하고 저비용 모델로 옮길 때 개발자가 하네스를 바꾸게 하면 선호 도구를 쓸 수 있지만, 전환 부담이 커질수록 경쟁력 있는 모델로 비용을 이동하기 어려워짐

  • 메타 하네스는 공통 사용자 경험을 유지하면서 요청을 독점·오픈소스 하네스로 분배해 모델과 하네스 선택의 독립성 및 낮은 전환 비용을 함께 제공함

    • Databricks에서는 Omnigent를 쓰는 개발자의 기본 방식이며, 자체 개발 도구 체인에 맞춘 사내 메타 하네스를 만든 회사도 있음

• 비용 수단 2: 요청이나 작업의 난도에 맞춰 가장 저렴하게 처리할 수 있는 모델·도구로 자동 라우팅함

  • 요청 단위 라우팅은 상태를 유지하는 프록시가 하네스와 기반 모델 사이에서 각 추론 요청을 처리할 수 있는 최저비용 모델을 선택함

    • 대규모 컨텍스트에서는 콜드 캐시 비용이 매우 높으므로 서버 측 캐싱 상태까지 고려해야 함

    • 초기 사례로 Cursor Router, OpenRouter AutoRouter, Ramp의 Router 기능, Unity AI Gateway의 Smart Routing이 있음

  • 작업 단위 라우팅은 메타 하네스가 ‘컴포넌트 이름을 X에서 Y로 변경’ 같은 단순 작업과 ‘지연 시간을 줄일 설계 고려사항 탐색’ 같은 복잡한 작업을 구분해 전체 작업을 적합한 모델·하네스에 위임함

    • Omnigent가 이 방식을 지원함

  • 에스컬레이션·위임 방식은 고가의 고지능 모델과 저렴한 작업 모델을 하나의 하네스에서 조합함

    • Claude Advisor Tool은 저비용 모델이 주도하다 더 강한 성능이 필요하다고 판단하면 상위 모델로 에스컬레이션함

    • Cognition Devin Fusion은 반대로 고비용 모델이 메인 루프를 맡고 일부 작업을 저비용 모델에 선택적으로 위임함

  • Databricks의 AI Gateway Smart Router는 사용 모델군에서 가장 비싼 모델과 대체로 같은 품질을 유지하면서 평균 작업 비용을 꾸준히 30% 넘게 줄였고, 다른 회사에서도 비슷한 결과가 나옴

• 비용 수단 3: 일률적인 하드 한도보다 비용 가시성과 단계별 제약을 적용함

  • 일정 금액에서 AI 사용을 완전히 차단하는 하드 예산은 대체로 최후 수단

    • 한도에 도달한 개발자의 접근을 끊으면 생산성이 크게 떨어져 회사와 직원 모두 원하지 않는 결과가 됨

    • 지출이 많은 사용자 중에는 AI로 막대한 효율과 산출물을 달성한 사람도 있어, 이들의 사용을 억제하면 오히려 손해

  • 대부분의 회사는 지출이 늘어날수록 마찰을 점진적으로 높이는 방식을 택함

    • 거의 실시간으로 현재 비용을 보여주고, 저렴한 모델을 이용해 지출을 줄이는 방법도 안내함

    • 여러 도구의 비용을 한눈에 보여줘 개발자가 투자 대비 효과가 가장 높은 도구를 선택할 수 있게 함

• 지출 단계가 올라가도 즉시 차단하지 않고 경고, 승인, 저비용 모델 전환, 일시 중단 순으로 대응 가능

  • 자체 해제 가능한 지출 게이트는 기준을 넘는 소비 속도를 경고해 실수나 의도하지 않은 비용을 막는 데 유용함

  • 더 높은 단계에서는 관리 체계 등을 통한 명시적 예산 승인을 요구할 수 있음

  • 게이트에 도달하면 토큰 접근을 전면 중단하는 대신 훨씬 저렴한 모델로 낮춰 계속 작업하게 할 수 있음

  • 모든 토큰 접근을 막는 기능도 남겨두지만 대체로 임시 조치이며, AI를 더 효율적으로 활용하는 방법을 논의하는 출발점으로 사용함

• 비용 수단 4: 사용자가 입력하지 않은 컨텍스트와 도구 호출이 지배하는 토큰 오버헤드를 줄임

  • ‘이 버그를 조사해 수정해 달라’는 짧은 요청도 에이전트가 대량의 컨텍스트 수집, 도구 호출, 코드 검색, 회사 제공 스킬·시스템 정보 통합을 수행하므로 실제 추론 시 사용자 문장은 입력 데이터의 극히 일부에 불과함

  • 아직 초기 단계지만 다음 방법을 시도 중

    • 활성 컨텍스트를 더 자주 압축하고, 토큰 효율이 높은 하네스를 쓰거나 기존 하네스의 발화를 줄임

    • 자주 쓰는 도구의 출력을 점검해 장황함을 줄이고, 개발자가 작업을 더 작은 단위로 나눠 컨텍스트 범위를 축소함

  • 컨텍스트가 커지면 프롬프트 캐싱도 전체 비용에 큰 영향을 줌

    • 독점·오픈소스 LLM 모두 캐싱 활성화와 보관 기간 조정 기능을 제공함

    • 캐시 쓰기에는 비용이 들지만 캐시 읽기는 추론당 비용을 크게 낮출 수 있어, 회사별 워크로드에 맞게 기본 설정을 조정하고 적중률을 높여야 함

  • Databricks에서는 하네스와 캐싱 설정을 비교적 간단히 조정해 생성 토큰 수와 관련 비용을 거의 50% 줄였으며, 개발자가 체감한 품질 저하는 관찰되지 않음

  • 불필요한 추론 호출과 캐시 쓰기를 줄인 뒤 세션당 토큰이 급감했으며, 추가 최적화 여지도 남아 있음

AI Gateway 설계 패턴

• 여러 비용 절감 기법을 함께 운영하려면 모델, 예산, 도구 설정, 세션 데이터를 중앙에서 관리하는 AI Gateway가 필요함

  • 새 모델을 신속히 도입하려면 중앙 모델 메뉴와 모델 혼용이 가능한 사용자 도구 체인이 필요함

  • 여러 AI 도구의 예산을 보여주려면 통합 비용 관측 기능이, 컨텍스트 비대화를 관리하려면 일반적인 도구 호출 출력을 관찰하고 압축을 강제하는 기능이 요구됨

  • AI Gateway가 담당하는 범위

    • 독점·오픈소스 기반 모델의 용량 관리와 접근 프록시

    • 점진적 마찰과 저비용 모델 전환을 포함한 예산 추적·집행

    • 모델 허용 목록, 압축 설정 등 사용자 도구의 로컬 구성을 중앙 관리

    • 효율 분석과 벤치마크에 활용할 코딩 세션 추적 기록

  • Databricks는 이 기능 전반에 Unity AI Gateway를 활용 중

• AI 코딩 비용 증가는 불가피한 현상이 아니라 엔지니어링과 거버넌스로 해결할 수 있는 문제

  • 최고 지능보다 효율 프런티어를 지속적으로 추적하고, 모델 유연성을 유지하며, 처리 가능한 최저비용 모델로 작업을 라우팅해야 함

  • 하드 예산 대신 비용 가시성과 점진적 마찰을 적용하고, 실제 지출의 큰 부분을 차지하는 토큰 오버헤드를 줄이면 생산성 향상을 희생하지 않고도 폭넓고 마찰이 적은 접근을 예측 가능한 비용 범위에서 제공 가능

  • Databricks는 중앙 관리를 위한 Unity AI Gateway와 개발자 도구 Omnigent를 오픈소스 또는 무료 제품으로 공개했으며, 현재 수천 개 회사가 매일 사용 중

^{source https://www.databricks.com/blog/managing-ai-coding-costs-scale}

HN에서는 AI 코딩 비용을 얼마나 줄였는지보다, 절감 과정에서 개발 생산성과 코드 품질을 지킬 수 있는지가 더 중요한 쟁점이었다. 저렴한 모델로 바꾸고 사용량에 한도를 두는 것만으로는 충분하지 않다. 자사 코드에서 성능을 검증하지 않은 채 비용만 낮추면, 부족한 결과를 바로잡는 데 개발자 시간이 더 들 수 있기 때문이다.

판단은 조직 규모와 작업 성격에 따라 달라졌다. 소규모 팀과 개인 개발자는 인건비에 비하면 고성능 모델 사용료가 저렴하며, 사람이 요구사항과 설계, 검토를 주도하면 높은 생산성을 얻을 수 있다고 봤다. 반면 복잡한 대형 코드베이스에서는 에이전트가 불필요한 추상화와 기능을 덧붙여 구조를 비대하게 만들 수 있다는 경험도 제시됐다. 빠른 기능 추가에는 유리해도 장기 유지보수가 중요한 영역에서는 범위를 좁힌 변경에 활용해야 한다는 판단이다.

비용을 좌우하는 요소로는 모델 가격뿐 아니라 컨텍스트 관리도 꼽혔다. 지나치게 많은 검색 결과와 반복적인 도구 호출, 사용하기 어렵게 설계된 API가 토큰을 낭비한다. 작업 도중 모델을 바꾸면 캐시 효율이 떨어질 가능성도 살펴야 한다. 실제 세션 기록을 분석해 불필요한 왕복을 줄이고, 반복 절차를 예측 가능한 작업으로 분리하는 편이 실질적인 절감에 가깝다.

결국 기업이 확인할 기준은 가장 싼 모델이 아니라 자사 업무에서의 비용 대비 품질이다. 저장소에 맞는 평가 체계를 마련하고 개발자별 비용과 체감 품질을 함께 측정해야 한다. 생성한 코드의 양보다 검토 부담과 유지보수성까지 확인해야 라우팅과 사용량 제한도 생산성을 해치지 않는 운영 수단이 될 수 있다.