한 개발자가 작업 유형에 따라 Opus, Sonnet, Haiku로 작업을 라우팅함으로써 월간 Claude API 지출을 약 35% 절감했습니다. 또한, 오류 발생 시 비용이 큰 작업에 Opus를 예약함으로써 어려운 작업의 품질도 향상되었습니다.

주요 사실 (Key facts)

• 작업 유형별 라우팅 후 월간 API 지출 약 35% 감소
• Sonnet으로의 기본 하향 설정이 비용 절감의 대부분을 견인
• Haiku는 린트 수정(lint fixes), 이름 변경(renames), 커밋 메시지(commit messages), 로그 요약(log summaries)을 처리
• Opus는 아키텍처(architecture), 레이스 컨디션(race conditions), 보안 리뷰(security reviews)를 위해 예약
• 에스컬레이션 규칙: 2번의 검증 실패 시 작업을 한 단계 상위 티어로 이동

dev.to에 글을 올린 이 개발자는 린트 수정부터 다중 파일 리팩토링(multi-file refactors)까지 매일 수십 개의 작업을 처리하는 완전 자율 코딩 에이전트(fully autonomous coding agent)를 운영하고 있습니다. 몇 달 동안 모든 작업은 동일한 최상위 모델로 전송되었습니다. 작업 유형에 따라 Claude Opus, Sonnet, Haiku로 작업을 분할한 지 한 달 만에, 월간 API 지출은 약 35% 감소했고, 평균 지연 시간(latency)은 줄었으며, Opus가 단순 작업(busywork)에 주의력을 낭비하지 않게 되면서 어려운 작업의 품질은 향상되었습니다 [dev.to의 개발자 게시물에 따르면].

라우팅 로직은 의도적으로 단순합니다. 동적 분류기(dynamic classifier)가 아닌 카테고리 조회(category lookup) 방식입니다. Haiku는 린트 수정, 임포트 정렬(import sorting), 이름 변경, 커밋 메시지와 같이 기계적이고 모호함이 적은 작업을 처리합니다. Sonnet은 불분명한 모든 작업에 대한 기본 작업마당(workhorse)입니다. Opus는 아키텍처 결정, 레이스 컨디션, 보안 리뷰, 인증/데이터 무결성(auth/data integrity)을 처리합니다. 이 개발자는 실시간으로 라우팅을 결정하는 "메타 에이전트(meta-agent)"를 구축하려 시도했으나 포기했습니다: "정답이 변하지 않는 80%의 작업에 대해서는 정적 규칙(Static rules)이 동적 라우터(dynamic router)보다 낫습니다."

핵심 요약 (Key Takeaways)

• 한 개발자가 Opus, Sonnet, Haiku에 작업을 라우팅(routing)함으로써 Claude API 지출을 35% 절감했습니다.
• Opus가 단순 반복 작업(busywork)을 처리하는 것을 중단함에 따라, 어려운 작업에서의 품질이 향상되었습니다.

하향 기본 설정(defaulting down)이 상향 라우팅(routing up)보다 나은 이유

Model Routing Explained: How Apps Choose Between GPT, Claude, and Op…

가장 큰 비용 동인은 Haiku 사용량이 아니었습니다. 바로 기본 설정(default)을 변경하는 것이었습니다. 해당 개발자는 "(상향이 아닌) 하향으로 기본 설정을 변경하는 이 단 하나의 습관 변화가 Haiku 사용량보다 더 많은 비용 절감을 가져왔습니다"라고 기록했습니다. "만약을 대비해" 불분명한 작업을 Opus 대신 Sonnet으로 보내는 것만으로도, 일상적인 작업에 지불하던 최상위 등급의 가격 프리미엄을 제거할 수 있었습니다.

이는 Anthropic이 더 많은 모델 계층(model tiers)을 출시함에 따라 주목할 만한 패턴입니다. 지식 그래프(knowledge graph)에 따르면, Opus 4.8을 탑재한 Claude Code는 SWE-bench Verified에서 88.6%, SWE-bench Pro에서 69.2%를 기록했지만, 이러한 벤치마크는 최상위 성능을 측정하는 것이지 비용 효율성을 측정하는 것은 아닙니다. 에이전트 기반 워크로드(agentic workload)의 경제성은 모델의 원시 품질(raw model quality)이 아니라 라우팅 규율(routing discipline)에 달려 있습니다.

안전 장치는 에스컬레이션 규칙(escalation rule)입니다. 만약 Haiku 또는 Sonnet 작업이 검증(validation)에 두 번 실패하면, 자동으로 한 단계 상위 계층으로 이동합니다. "검증 실패"란 테스트 스위트(test suite)가 여전히 실패하거나, 디프(diff)가 깔끔하게 적용되지 않거나, 후속 확인에서 변경 사항이 부분적으로만 완료된 것으로 표시되는 경우를 의미합니다. 이를 통해 첫 번째 시도에서 작업의 정확한 분류에 모든 것을 걸지 않고도, 저가형 계층을 공격적으로 저렴하게 사용할 수 있습니다.

개발자의 수치는 단 한 달간의 운영을 통해 자가 보고된 것이며, 게시물에는 절대적인 달러 금액이나 작업 횟수가 공개되지 않았습니다. 35%라는 수치는 방향성을 나타내는 것입니다. 라우팅을 통한 절감액은 주어진 워크로드 내에서 사소한 작업과 어려운 작업의 혼합 비율에 따라 달라질 것입니다. 하지만 구조적인 통찰은 유효합니다. "모든 것에 최상의 모델을 사용하는 것"은 전략이 아니라, 전략의 부재입니다.

주목해야 할 점

Anthropic의 가격 계층(pricing tiers)이 이러한 라우팅 계산의 매력도를 높이거나 낮추는 방향으로 변화하는지, 그리고 Claude Code와 같은 에이전트 프레임워크(agent frameworks)가 네이티브 라우팅(native routing) 또는 에스컬레이션(escalation) 기능을 추가하는지 주시하십시오. 개발자가 언급한 35%라는 수치는 한 달간의 결과입니다. 작업 구성(task mix)이 더 어려운 작업으로 이동함에 따라 이러한 비용 절감이 지속될지는 장기적인 보고서를 통해 확인될 것입니다.

출처: dev.to

원문은 gentic.news에 게시되었습니다.