Baseten Grid가 던진 질문, 코딩 작업 하나를 끝내는 데 얼마가 들까?

코딩 에이전트가 실패한 테스트를 고치겠다며 깔끔한 변경안을 내놓습니다. 하지만 CI를 통과하지 못해 개발자가 다시 시킵니다. 두 번째 시도에서는 저장소의 더 넓은 부분이 바뀌고, 5분이면 될 줄 알았던 패치를 검토자가 30분 동안 들여다봅니다. 어느 모델이 더 저렴했을까요?

Baseten은 11월 4일 Grid를 공개 프리뷰로 선보였습니다. 승인된 모델을 위한 게이트웨이와 라우터, 사용량과 보호 정책을 한곳에서 관리하는 기능을 묶었습니다. 지원하는 코딩 도구와 모델 사이에 배치하면 팀에서 요청 전반에 공통 정책을 적용할 수 있습니다. 사전 이용 안내 페이지에서는 팀을 대기자 명단으로 안내합니다.

분모를 실제로 끝낸 작업에 둔다

채택된 작업당 비용. Telli.sh 자체 제작.

토큰 가격은 모델 사용량 한 단위에 매긴 값입니다. 팀이 실제로 내보내야 하는 것은 인수 기준을 통과한 결과입니다. 요청을 보내 답변을 받고 실행을 통해 변경 내역을 얻어도 작업은 미완료일 수 있습니다. 이 사건들을 따로 세어야 라우팅 시험에서 쓸 만한 정보를 얻을 수 있습니다.

두 경로가 각각 비슷한 작업 100건을 받는다고 가정해 보죠. 저렴한 경로는 전체 시도에 50달러를 써서 50건을 채택 가능한 수준으로 마칩니다. 다른 경로는 90달러를 써서 90건을 마칩니다. 이 예에서 채택 가능한 결과 한 건당 모델 사용 비용은 둘 다 1달러입니다. 사람의 검토 시간과 도구 요금, 재시도를 기다리는 비용을 더하면 값이 달라질 수 있습니다. 어느 쪽이 더 커질지는 작업에 달려 있습니다.

실패한 시도에 쓴 돈도 분자에 넣으세요. 어려운 요청을 포기하는 경로는 중단된 시도가 집계에서 사라지면 효율적으로 보입니다. 성공의 정의도 고정하세요. 문서 수정은 변경 내역이 승인되면 충분할 수 있습니다. 마이그레이션은 기존 데이터의 테스트와 롤백 경로가 필요합니다.

작업 유형이 중요합니다. 저장소 전체의 API를 마이그레이션하려면 많은 맥락을 파악하고 작은 변경 여러 개를 조율해야 합니다. 한 줄짜리 패치가 더 어려울 때도 있습니다. 미묘한 동시성 버그가 걸려 있을 수 있기 때문입니다. 파일 수와 프롬프트 길이는 내 환경에서 결과를 예측할 때만 유용한 신호입니다.

라우터 실험에서 비용과 통과율을 함께 읽는다

라우팅 실험. Telli.sh 자체 제작.

Baseten의 기술 보고서는 Opus 5.5만 사용하는 방식과 이 모델 및 GLM 5.3 Flash 사이에서 작업을 라우팅하는 방식을 비교합니다. DeepSWE, SWE Atlas QnA, Terminal-Bench를 섞은 평가에서 회사는 평균 비용이 72% 낮으면서 통과율은 Opus만 사용했을 때와 0.8%포인트 이내로 차이 나는 지점을 보고했습니다. 비슷한 비용으로 무작위 배정하는 경우도 비교했습니다. 동전을 던지듯 작업을 보내도 저렴한 모델 비중이 커지면 평균 모델 비용은 떨어질 수 있으므로 이 비교가 중요합니다.

라우팅 임계값은 기대하는 성공 가능성에 얼마까지 지불할지 반영합니다. 비용을 더 우선하면 저렴한 경로로 작업이 많이 갈 수 있습니다. 결과가 더 중요한 곳에서는 다른 설정으로 더 능력 있는 모델에 보낼 수 있습니다. Baseten의 수치는 선택한 모델과 작업, 가격 가정을 전제로 합니다. 실제 팀은 업무 분포도, 실패했을 때 치르는 대가도 다릅니다.

제품 발표는 초기 벤치마크에서 비용이 최대 70% 줄었다는 별도의 반올림 수치를 씁니다. 기술 실험의 72%와 그에 따른 통과율 비교와 구분해서 읽으세요. 기술 보고서에서 얻을 수 있는 것은 비용과 성과가 함께 움직이는 방식입니다. 팀에서 중시하는 값에 맞춰 지점을 고르고 실제 업무에서도 그 지점이 유지되는지 볼 수 있습니다.

게이트웨이는 적용하는 정책을 드러낼 수 있다

Grid 발표에는 승인 모델, 팀 단위 제어, 사용량 확인 기능이 나옵니다. 플랫폼 팀은 조직이 미리 평가한 모델을 개발자에게 제공하면서 사용량이 어떻게 분포하는지 볼 수 있습니다. 경로 선택을 맡기기 전에도 돈이 어디에 쓰이는지 파악하는 데 도움이 됩니다.

실제로는 정할 것이 여러 가지입니다. 어느 제공업체가 사내 코드를 볼 수 있나요? 이 저장소에서 어떤 모델 사용이 승인됐나요? 재시도 비용은 어느 팀이 부담하나요? 장애가 났을 때 누가 경로를 재지정할 수 있나요? 관리자가 제어 범위를 이해한다면 게이트웨이에서 공통으로 적용할 수 있습니다.

모델 게이트웨이와 에이전트 실행 환경은 서로 다른 제어 지점입니다. 게이트웨이는 어느 모델로 요청을 보낼지 결정할 수 있습니다. 자격 증명을 읽거나 파일에 쓰거나 네트워크를 호출할 수 있는지는 도구와 실행 환경이 정합니다. 경로 제한은 실행 권한과 함께 작동할 때 가치가 있습니다. 더 싼 경로에서도 권한이 큰 도구에는 같은 제한이 필요합니다.

증거의 범위도 정해야 합니다. 라우팅 로그는 비용이 왜 변했는지 보여주지만, 추적 기록에는 코드와 경로, 고객 장애의 세부 내용이 포함될 수 있습니다. 플랫폼이 무엇을 기록하고 누가 조회할 수 있으며 얼마나 보관할지 정하세요. 개발자가 정책을 볼 수 없으면 요청이 거부되거나 예상과 다른 경로로 갔을 때 원인을 찾기 어렵습니다.

기본 경로를 바꾸기 전에 라우팅을 시험한다

1. 자주 하는 작업 두세 종류를 고르세요. 일반적인 테스트 수정처럼 단순한 종류와 하위 호환성이 필요한 마이그레이션처럼 어려운 종류를 포함하세요.
2. 시작 전에 채택에 필요한 증거를 정하세요. 코딩 작업이라면 회귀 테스트 통과, 깔끔한 변경 내역, 검토자 승인, 예상 밖 파일 변경 여부가 해당합니다.
3. 현재 기본 모델을 써서 기준선을 기록하세요. 실패, 재시도, 개발자가 수동으로 마무리한 작업까지 넣으세요. 운영 환경의 보안 및 데이터 제약도 유지하세요.
4. 동등한 작업에서 라우팅을 비교하세요. 이용할 수 있다면 계정을 연결하기 전에 공식 문서에서 게이트웨이가 지원하는 도구와 권한을 확인하세요.
5. 언제 상위 모델로 넘길지 정하세요. 첫 시도가 실패하면 두 번째 모델을 쓸 수 있지만 한도 없는 재시도는 처음부터 더 강한 모델을 쓸 때보다 비싸질 수 있습니다. 한도를 정하고 전환한 이유를 남기세요.
6. 틀린 결과의 영향이 큰 작업은 경로를 재지정할 수 있게 하세요. 시험이 끝나면 전체 비용과 채택 수치를 보면서 예외도 함께 살펴보세요.

사내 시험에서는 개발자가 모델을 직접 고른 기간과 라우팅을 적용한 기간의 유사한 일을 비교할 수 있습니다. 전자는 저장소를 잘 아는 개발자의 판단에서 이점을 얻을 수 있습니다. 후자는 정책이 일관되고 사용량을 보기 쉽습니다. 작업별 차이를 기록해야 어느 부분에 자동화가 도움 되고 어디에 사람의 판단이 필요한지 비교할 수 있습니다.

조건을 맞춘 작업 로그를 읽는다

완료한 풀 리퀘스트 한 달치를 살펴보는 것부터 시작할 수 있습니다. 의존성 업데이트, 재현 가능한 테스트가 있는 버그, 여러 저장소에 걸친 변경, 실패한 배포를 조사하는 개방형 요청처럼 처음 의뢰를 기준으로 작업에 태그를 붙이세요. 작업마다 저장소 리비전과 채택 조건을 저장하세요. 안정적인 기준선과 라우터에서 표본을 다시 실행하되 도구와 시간 예산, 테스트 환경을 같게 유지하세요.

의존성 업데이트는 모호성이 낮은 예시입니다. 지정된 의존성이 바뀌고 호환성 점검을 통과하며 풀 리퀘스트에 무관한 수정이 없으면 성공입니다. 결제 계약을 건드리는 일에는 더 엄격한 검토가 필요합니다. 요구사항이 불완전하다면 사람이 해석해야 할 수도 있습니다. 작업 유형을 나누어 보면 평균 지출이 어디서 줄었는지 알 수 있습니다. 저렴한 경로가 의존성 업데이트에는 유리하지만 결제 변경에는 재시도가 필요하다면 두 유형을 다른 경로로 보낼 수 있습니다.

결과를 채택할지 판단하는 데 사람이 쓴 시간도 기록하세요. 기준선이 19달러를 써서 20건 중 19건을 채택시키고 라우터는 9달러에 18건을 채택시킨다고 가정해 보죠. 이 예에서 채택된 결과당 모델 비용은 각각 1.00달러와 0.50달러입니다. 라우팅에 실패한 결과 하나를 고치는 데 검토자가 20분을 더 쓰면 비교가 달라집니다. 조직에서 쓰는 단위에 재작업을 반영하되, 돈과 시간을 같은 측정값처럼 취급할 필요는 없습니다.

라우터가 어떤 작업으로 학습했는지 확인한다

Baseten 기술 글에는 DeepSWE 1.1, SWE Atlas QnA, Terminal-Bench 2.1이 명시돼 있습니다. 연구진은 여러 작업에서 Claude Opus 5.5와 GLM 5.3 Flash를 비교하고, 학습에 쓰지 않은 데이터로 라우터를 평가합니다. 어느 범위까지 결과를 적용할 수 있을지 판단하는 데 중요한 정보입니다. 저장소 위치를 묻는 질문과 셸을 실행하거나 외부 도구를 쓰거나 여러 파일을 수정하는 작업은 비용 구조가 다릅니다. 고객은 실제로 보낼 작업을 대표하는 평가를 구성해야 합니다.

기술 글은 Cost, Balanced, Intelligence가 요청 시 라우팅 임계값을 바꾸는 설정이라고 설명합니다. 이 차이를 이용해 실제 업무에 반영하기 전에 비교할 수 있습니다. 승인받은 고정 작업 묶음을 재실행하면서 설정을 비교하고, 연동에서 선택된 모델을 제공한다면 기록하세요. 결과가 다른 사례를 살피세요. 팀에서 민감하거나 어렵다고 보는 일에 주로 높은 비용이 배정된다면 정책이 쓸모 있을 수 있습니다. 차이가 흔하고 단순한 일에 몰린다면 작업 분류나 정책을 조정할 여지가 있습니다.

오래 걸리고 비싼 사례까지 본다

평균 지연을 보면 여러 모델을 거친 어려운 패치를 기다린 시간이 가려질 수 있습니다. 요청부터 채택까지 실제 걸린 시간을 기록하고 재시도, 상향 전환, 시간 초과, 인수인계를 표시하세요. 첫 모델의 응답 시간만 표시하는 대시보드는 담당자가 다시 시작한 작업도 성과처럼 보이게 할 수 있습니다. 인수인계 이후의 지출과 시간까지 넣으세요.

넓게 켜기 전에 시험의 한도를 정하세요. 작업 전체에 쓸 예산과, 중단하거나 더 강한 모델로 넘길 조건을 두세요. 실패한 시도는 다음 시도가 이어받을 수 있도록 충분한 증거를 남겨야 합니다. 라우터가 다른 모델을 골랐다는 이유로 같은 파일을 다시 읽거나 같은 테스트를 또 실행하는 일은 피하세요. 봐야 할 지표는 작업이 실제로 얼마나 진행됐는지입니다.

도입할 때는 채택 규칙을 자동화할 수 있고 사람이 예외를 확인하기 쉬운 좁은 유형부터 시작하세요. 다음으로 사람이 판단해야 하는 유형을 추가하세요. 채택 작업당 비용, 상향 전환 비율, 검토 소요 시간을 따로 비교하세요. 업무를 바꿔도 이점이 유지되면 기본 경로를 정할 근거가 늘어납니다.

모델이 바뀌어도 기준선을 쓸 수 있게 남긴다

한 주에 모은 결과는 모델이나 도구, 저장소가 바뀌면 유효성이 떨어질 수 있습니다. 라우팅 결정과 함께 모델 식별자, 테스트 리비전, 채택 규칙을 보관하세요. 정책을 바꿀 때는 대표 작업을 소량 다시 실행하세요. 비용이 큰 실패도 몇 건 남겨 두세요. 그런 비용은 평균에서 쉽게 사라집니다.

어느 모델이 선택됐는지 가린 채 결과가 갈린 사례를 검토자에게 보여주세요. 어떤 결과를 채택해야 할지 구분하기 어렵다면 실행 사례를 더 모으기 전에 기준부터 다듬으세요. 팀이 성공을 같은 방식으로 알아볼 수 있을 때 라우팅 정책도 비교하기 쉬워집니다.

업무가 변하면 정책도 나아져야 한다

라우팅은 팀이 작은 선택을 반복하지 않게 해줄 때 가치가 있습니다. 성능과 가격을 같은 작업 단위에서 볼 수 있을 때 특히 유용합니다. 모델과 가격, 저장소는 시간이 지나면 달라집니다. 벤치마크 작업을 보존하고 테스트 묶음을 갱신하면 라우팅 정책도 같이 발전할 수 있습니다.

기획 회의에 가져갈 숫자는 팀이 채택된 작업을 제공하는 데 실제로 낸 비용입니다. 감수한 성능 차이도 함께 설명하세요. 그러면 개발 책임자와 예산 책임자가 같은 근거로 결정할 수 있습니다.

출처

• Baseten의 11월 4일 Grid 프리뷰 발표
• Baseten의 11월 4일 Router 기술 보고서

---

업무의 배경이 된 대화와 결정 사항을 검색 가능한 기록으로 남기려면 Telli.sh 계정을 만드세요.