Databricks가 출시 첫날 12,000명의 직원에게 프론티어 모델을 배포하는 방법

직원들에게 프론티어 AI 기능을 제공하는 것은 Databricks의 최우선 과제이며, 따라서 새로운 모델이 출시되는 즉시 직원들이 사용할 수 있도록 하는 것이 중요합니다. 동시에 12,000명이 넘는 사람들에게 새로운 모델에 대한 빠른 액세스를 제공하는 것은 다음과 같은 이유로 쉽지 않은 일입니다.

1. 프론티어 모델로 홍보되는 모델이 실제로는 그렇지 않은 경우가 많습니다. 예를 들어, Opus 5.0은 Opus 4.8에 비해 더 비쌌고 엔지니어들 사이에서 정량적 및 정성적 품질 점수 모두 더 낮게 평가되었습니다. 성능이 퇴보하는 모델로 마이그레이션하는 것은 회사에 도움이 되기는커녕 오히려 큰 피해를 줄 수 있습니다. 저희 경험상, 워크로드를 새로운 모델로 대규모 마이그레이션하기 전에 모델을 평가할 때는 세심한 주의가 필요합니다.
2. 새로운 모델을 무분별하게 사용하면 비용이 폭발적으로 증가할 수 있습니다. 비용 완화 조치 없이 대조군에 GPT Astra를 출시했을 때,  개발자 평균 지출이 Astra를 사용하기 전보다 60% 증가했습니다. 사용자 수가 10,000명이 넘는 상황에서 하루아침에 비용이 60% 증가하는 것은 회사가 계획을 세우기 매우 어렵습니다. Astra가 어떤 작업에 특히 뛰어난지 더 잘 이해하게 된 후, 저희는 사용을 유도하여 전체 비용을 크게 줄일 수 있었습니다.

본 블로그 글에서는 대부분의 Databricks 직원들에게 새로운 모델에 대한 출시 첫날 액세스를 제공하는 동시에, 해당 모델이 실제로 장기적으로 유용하게 활용할 수 있는 모델인지 평가하기 위해 도입한 기술들을 소개합니다. 이러한 기술들은 새로운 모델을 적응적으로 출시, 평가 및 통합하기 위해  Unity Gateway에 크게 의존합니다. 9월 21일 주간은 Opus 5, GPT-6 Sol, GPT-Luna가 연달아 출시되면서 이러한 역량을 검증하는 중요한 시험대였습니다. 해당 주간에 Databricks는 모든 직원에게 출시 첫날 액세스를 제공했으며, 3일 차에는 이 모델들이 효율성 프론티어에 있음을 확인하기에 충분한 데이터를 수집하여 더 넓은 인프라에 통합할 수 있었습니다.

모델 출시 라이프사이클

 개념적으로 Databricks의 새로운 모델 출시는 다음과 같은 파이프라인을 거칩니다.

1. 새로운 모델을 모든 직원에게 "실험적" 단계로 즉시 제공합니다.
2. 사용자별 예산을 기반으로 새로운 모델의 사용을 제한합니다.
3. 충분한 데이터를 수집한 후, 모델을 프로덕션으로 승격할지(또는 기본값으로 설정할지) 결정합니다.

1단계: 새로운 모델을 즉시 제공하기

폐쇄형 및 오픈형 모델 제공업체 전반에서 모델 관리를 더 쉽게 만들기 위해, 저희는 모든 내부 사용에 자체 Databricks Unity Gateway를 활용합니다. 이곳은 AI 거버넌스, 비용 관리 및 관측 가능성을 위한 중앙 허브이므로 여기서 시작하는 것이 자연스럽습니다.

Gateway는 모든 직원이 새로 출시된 모델에 액세스할 수 있도록 지원하는 곳입니다. 하지만 서버 측 구성만으로는 충분하지 않습니다. 직원들은 노트북에서 Claude Code, Codex 및 Omnigent 메타 하네스를 사용하고 있으므로, 이들에게 새로운 모델 구성을 배포해야 합니다.

바로 이 부분에서 Unity Gateway CLI (UG CLI)가 역할을 합니다. UG CLI는 모바일 기기 관리를 통해 배포되어 이미 모든 사람의 노트북에서 실행 중입니다. 누군가 Claude Code, Codex 또는 Omnigent를 시작할 때마다 UG CLI가 실행되어 새로운 모델, 도구 및 기술을 확인하고 로컬 하네스의 구성을 업데이트합니다. 또한 UG를 통해 기본 모델과 실험적 모델을 중앙에서 지정하고,  스마트 라우팅을 위한 모델을 준비하며, 각 모델 롤아웃을 평가하기 위한 트레이스를 수집할 수 있습니다.

저희는 Opus 5.5 및 Sol 6에 대한 실험적 구성을 푸시하도록 Unity Gateway를 구성했습니다. 이제 이 모델들은 해당 태그와 함께 표시되므로, 직원들이 이를 선택할 수는 있지만 동급 최고가 아닐 수도 있고 영구적으로 유지되지 않을 수도 있는 새로운 모델임을 이해할 수 있습니다.

Claude Code / 모델 출력에서 Ous 5.5를 실험적(Experimental)으로 명확하게 지정하고 있습니다.

2단계: 사용자별 예산을 사용하여 사용 제한하기

저희는 이전에 AI 지출에 대한 사용자별 예산을 구성하는 방법에 대해 글을 쓴 적이 있습니다. 그 이후로 저희는 총 예산 아키텍처를 확장하여 사용자별로 정의되는 네 가지 주요 예산을 포함하도록 했습니다.

1. 월간 최대 한도: 각 사용자는 모든 모델에 대해 전반적인 월간 지출 한도를 가집니다.
2. 일일 폭주 제한: 모든 사용자는 일일 최대 한도를 가지며, 폭주 세션으로 인한 우발적인 지출을 방지하기 위해 Slack에서 직접 한도를 높일 수 있습니다.
3. [신규!] 품질 프론티어 예산: 월간 예산의 특정 비율을 GPT Astra 및 Claude Fable과 같은 품질 프론티어의 가장 프리미엄 모델에 할당합니다. (Fable은 Anthropic의 데이터 보존 정책으로 인해 현재 내부적으로 배포되지 않았지만, 새로운 정책을 적용하기 위해 긴밀히 협력하고 있습니다.) 이는 이러한 모델이 일상적인 용도로 사용되어서는 안 되며, 다음 품질 계층에 비해 2~3배 높은 비용을 정당화할 수 있도록 고유하게 적합한 특수 작업에 선택되어야 한다는 의도를 반영합니다.
4. [신규!] 실험적 예산: 월간 예산의 또 다른 비율은 검증되지 않은 새로운 모델의 사용에 할당됩니다. 여기서는 도입 속도와 효율성 프론티어에 있지 않은 모델을 널리 노출할 때 발생할 수 있는 부작용 위험 사이의 균형을 맞추는 것을 목표로 합니다.

모델 출시 첫날, 저희는 Unity Gateway를 통해 모든 직원에게 Opus 5.5 및 Sol 6을 제공하고 실험적 예산 태그를 지정했습니다. 그런 다음 몇 일 동안 데이터를 수집하여 실험적 태그를 제거할지, 아니면 개발자가 보는 모델 카탈로그에서 모델을 완전히 제거할지 결정했습니다.

네 가지 예산을 반영한 예산 설정 개요

3단계: 모델 승격 또는 제외하기

모델이 효율성 프론티어에 있는지 확인하기 위해 저희는 세 가지 신호에 의존합니다.

1. 벤치마크 데이터: 저희는 문서 추론, 작업 공간 검색, 자체 Genie 제품과 같은 오프라인 벤치마크뿐만 아니라 두 모델을 나란히 실행하고 풀 리퀘스트 생성에 대한 출력을 비교하는 온라인 벤치마크를 포함하여 일련의 작업을 테스트하는 자체 벤치마크 세트를 보유하고 있습니다. 저희는 이러한 벤치마크를 계속 확장하고 조정하고 있으며, 이상적인 환경에서는 벤치마크만으로도 새로 출시된 모델의 비용과 품질을 신속하게 판단할 수 있습니다.
    
2. 사용자가 보고한 품질: 실험적 모델 출시는 사람들이 새 모델에 대해 어떻게 느끼는지에 대한 풍부한 피드백 데이터를 제공합니다. 파워 유저 그룹은 새로운 모델을 기꺼이 시도하고 Slack 및 설문조사 응답을 통해 서로의 경험을 비교합니다.
    
3. OpenTelemetry 트레이스를 통한 비용 추적: Unity Gateway는 비용 정보와 함께 모든 트레이스를 중앙 위치에 기록합니다. 파일럿 사용자가 이전 세대 모델과 최신 모델에서 세션당 비용을 어떻게 지출했는지 비교할 수 있습니다. 이것이 반드시 품질을 말해주는 것은 아니지만, 비용을 측정하는 좋은 척도가 됩니다.

Opus 5.5 및 Sol 6의 경우, 세 가지 지표 모두 매우 일관된 결과를 보여줍니다.

벤치마크(예: Databricks의 OfficeQA Pro V2)에 따르면, Opus 5.5는 비용/품질 프론티어 상에 확실히 위치해 있으며, 두 축 모두에서 Opus 5보다 크게 개선되었습니다. GPT-6 Sol은 비용과 품질 모두에서 GPT-5.6 Sol과 GPT-5.6 Terra의 중간 정도의 점수를 기록했습니다.

사용자 보고 에 따르면 엔지니어링 및 디버깅 작업(초기 사용자 대부분이 엔지니어임)에서 Opus 5.5는 Opus 5 및 Opus 4.8에 비해 품질이 크게 향상되었으며, 텍스트 작성 스타일도 훨씬 더 선호되는 것으로 나타났습니다. 반면 GPT-6 Sol은 GPT-5.6 Sol에 비해 간혹 품질이 떨어지는 경우가 있습니다.

비용 추적을 통해 얼리 어답터의 사용량을 일주일 전 동일한 그룹의 사용량과 비교할 수 있었습니다. 얼리 어답터는 일반 사용자가 아닌 AI 파워 유저인 경향이 있기 때문에 동일한 코호트를 유지하는 것이 매우 중요했습니다.

새로운 모델을 테스트하는 사용자는 실험 과정에서 세션 수 측면에서 사용량을 늘리는 경우가 있으므로, 비용을 세션당 비용($/session) 기준으로 정규화하고자 했습니다. 하지만 단순한 세션당 비용 비교는 여전히 왜곡된 결과를 초래할 수 있음을 발견했습니다. 세션 분포 자체도 변하고 있었기 때문입니다. 즉, 얼리 어답터들은 새로운 모델을 사용해 일반적인 세션보다 더 어려운 문제를 해결하려고 시도하고 있었습니다.

이에 따라 세션을 단일 턴(single-turn)인지 다중 턴(multi-turn)인지, 그리고 파일 편집이 발생했는지 여부에 따라 계층화한 다음, 그에 맞춰 분포의 가중치를 다시 조정했습니다. 아래 표는 Opus 5.5 대 Opus 4.8, 그리고 GPT-6 Sol 대 GPT-5.6 Sol의 비교 결과를 보여줍니다.

GPT 수치는 가격이 50% 인하되었다는 점을 감안하면 그리 놀라운 일은 아닙니다. 하지만 이전의 Opus 5 사용 경험에 비추어 볼 때, Opus 5.5 역시 실제 워크로드에서 상당한 비용 절감 효과를 보여주었다는 점은 매우 고무적이었습니다.

결정 사항

모델 출시 첫날 직원들에게 Opus 5, GPT-6 Sol 및 Luna를 실험적으로 사용할 수 있는 권한을 제공했습니다. 그리고 3일 이내에 이 모델들이 효율성 프론티어 상에 있음을 확인하기에 충분한 데이터를 수집했으며, 실험 예산에서 제외하여 일반 제공(GA) 모델로 정식 배포하기로 결정했습니다.

다음 주에는 한 걸음 더 나아가, 이전 버전보다 품질은 더 높고 비용은 더 저렴하다는 명확한 강점을 지닌 Opus 5.5를 Claude Code의 기본 모델로 설정할 예정입니다.

GPT-6 Sol을 사용해 본 결과, Codex의 기본 모델로서 GPT-5.6 Sol을 대체하지는 못할 것으로 보입니다. 하지만 5.6 Sol 대비 비용적 우위가 있는 만큼, 스마트 라우터 툴킷에 GPT-6 Sol을 포함할 예정입니다. 

전반적으로 이 플레이북은 모델의 품질과 비용을 신속하게 평가하는 데 매우 효과적이었으며, 가치가 입증된 최신 모델을 빠르게 도입할 수 있도록 지원했습니다. 거의 매일 새로운 모델이 출시되는 지금, 이러한 유연성은 그 어느 때보다 중요합니다.

(이 글은 AI의 도움을 받아 번역되었습니다. 원문이 궁금하시다면 여기를 클릭해 주세요)