Claude 서브 에이전트(subagents)를 6개 이상 추가하자 파이프라인이 더 느려졌지만, 진짜 문제는 동시성(concurrency)이 전혀 아니었습니다.

제 광고 분석 SaaS(ad analytics SaaS)의 비용 로그를 마침내 확인했을 때, 파일 이름 변경, Slack 메시지 포맷팅, JSON 파싱, 12개 캠페인 성과 보고서 해석 등 모든 작업이 Sonnet을 호출하고 있었습니다. 모두 동일한 모델이었습니다. Sonnet 4.5는 입력 토큰 100만 개당 $3, 출력 토큰 100만 개당 $15가 소요됩니다. Haiku 3.5는 $0.80/$4입니다. 순수하게 모델 선택만으로도 동일한 토큰 사용량 대비 3~4배의 비용 차이가 발생합니다.

저는 작업을 세 가지 단계(tiers)로 나누었습니다. 판단이 필요 없는 포맷/파싱/추출 작업은 Haiku, 패턴 인식 및 다단계 도구 사용(multi-step tool use)은 Sonnet, 아키텍처 결정(현재 12개 중 1개의 워커이며 수동으로 실행)은 Opus를 사용합니다. 라우팅 결정 자체는 Haiku가 들어오는 작업을 약 100토큰 내외로 분류함으로써 이루어지며, 호출당 비용은 약 $0.00008입니다. 이는 잘못된 모델 할당을 피함으로써 얻는 절감액에 비하면 무시해도 될 수준(noise)입니다.

직관에 반하는 발견: 작업의 복잡성(task complexity)보다 컨텍스트 길이(context length)가 더 중요했습니다. 저는 복잡한 작업에는 Sonnet이 필요할 것이라고 예상했습니다. 하지만 실제로 발견한 것은, 컨텍스트가 2,000토큰 미만으로 압축되었을 때는 Haiku가 놀라울 정도로 어려운 작업도 잘 처리했지만, 컨텍스트가 5,000토큰을 넘어가면 단순한 작업에서도 무너진다는 것이었습니다. 따라서 이제 제 라우터에서는 작업 유형이 아닌 컨텍스트 길이가 첫 번째 분기 기준이 되었습니다.

const modelMap: Record<Tier, string> = {
  1: "claude-haiku-3-5",
  2: "claude-sonnet-4-5",
...

6개월간 프로덕션에서 운영한 결과: API 지출이 월 $180-200에서 $95-110로 감소했습니다. 정확히 50% 절감된 것은 아닙니다. Haiku 재시도(retries, 호출의 약 8%가 Sonnet으로 폴백됨)가 비용을 일부 상쇄하기 때문입니다. 하지만 재시도 비용을 고려하더라도, 이 라우팅 시스템은 투입 비용 대비 여러 배의 이득을 가져다줍니다. 모든 것을 Sonnet으로 기본 설정하여 재시도율을 0%로 만들려는 시도는 8%의 재시도를 허용하는 것보다 더 많은 비용이 들 것입니다.

또한 배포 3일 후 D1 too many variables 에러를 겪었습니다. 각 7개의 컬럼을 가진 100개의 라우팅 로그 행을 배치(batching) 처리하려 했더니 SQLite의 999개 변수 제한을 초과했습니다. 배치 크기를 30으로 줄여 문제를 해결했습니다. 이는 라우팅 문제가 아니라, 실제 상황을 고려하지 못한 로깅(logging) 가정이 초래한 문제였습니다.

태스크의 90%에 대해 LLM 라우팅 호출을 완전히 건너뛰기 위해 테스트 중인 규칙 기반 사전 필터(rule-based pre-filter)와, Opus가 실제로 파이프라인 포함을 정당화하는 시점이 언제인지에 대한 미결 과제를 포함한 전체 분석 내용은 riversealab에서 확인할 수 있습니다.

전체 포스트 보기 →