열네 배 차이와 오탐 서른 건 — 서브 에이전트 모델 분업을 측정한 한 사람
매달 찍히는 API 영수증을 볼 때마다 서브 에이전트한테 Opus를 먹이는 게 맞나 속이 쓰렸다.
AI 에이전트를 좀 굴려본 개발자라면 누구나 한 번쯤 마주치는 현실적인 고민이다. “정말 이 사소한 잡무까지 값비싼 상위 모델을 태워야 할까?” 특히 서브 에이전트를 적극적으로 돌리는 환경에서는 더 절실하다. 부모 에이전트의 잔심부름을 대신 처리해 주는 게 서브 에이전트인데, 그 잔심부름 하나하나마다 Opus의 비싼 토큰비를 꼬박꼬박 상납하고 있으면 지갑 잔고는 정직하게 증발한다.
r/ClaudeCode에 바로 이 물음에 대해 직접 발로 뛰어 숫자로 답을 내놓은 글이 올라왔다. 한 개발자가 자기 실제 프로덕션 프로젝트에서 Opus 5.5가 이미 해결했던 6개의 과제를 골라, 글자 하나 안 바꾼 프롬프트와 동일한 파일, 동일한 high effort 설정으로 Sonnet 5.5와 Haiku 5.5에게 다시 풀게 했다. 뜬구름 잡는 인위적인 벤치마크가 아니라, 실제 운영 중인 사내 코드베이스에서 나온 피 같은 실측 데이터라 훨씬 와닿는다.
코드 검색: 성능이 같으면 싼 놈이 장땡이다
첫 번째 과제는 신규 기능을 추가하기 위해 수정이 필요한 관련 소스코드 파일을 프로젝트 전체에서 모조리 찾아내는 것이었다. 정답 기준 실제로 고쳐야 할 타깃 파일은 총 48개였다.
세 모델의 검색 결과와 청구된 토큰 비용을 비교해 보면 이렇다:
| 모델 | 발견한 파일 수 (48개 중) | 소모 비용 |
|---|---|---|
| Opus 5.5 | 45개 | $6.17 (약 8,500원) |
| Sonnet 5.5 | 44개 | $1.38 (약 1,900원) |
| Haiku 5.5 | 44개 | $0.44 (약 600원) |
결과가 충격적이다. 품질 차이가 사실상 0에 수렴한다. 45개와 44개는 실무적으로 아무 의미 없는 오차 범위다. 그런데 비용 차이는 자그마치 14배다.
이런 단순 코드 탐색 과제는 깊은 논리적 ‘추론’이 아니라 넓은 텍스트를 훑는 ‘패턴 매칭’이다. 모델의 깊은 뇌세포가 쓰일 구석이 거의 없다. 그러니 비싼 두뇌를 쓸 이유가 전혀 없고, 가장 저렴한 Haiku 5.5를 쓰는 게 압도적인 이득이다.
웹 리서치와 팩트체크: 진짜 악몽이 시작되는 곳
하지만 똑같은 실험을 웹 리서치와 팩트체크 영역으로 옮겨오는 순간, 등골이 서늘해지는 대반전이 펼쳐진다.
공식 개발자 룰북 및 Google 도움말 문서를 대조하며 팩트를 수집하는 3개의 과제에서 사실관계가 틀린 ‘할루시네이션(거짓 정보)’ 발생 건수는 Opus 1건, Sonnet 3건, Haiku 10건이었다. 특히 Google Play 계정 정책의 핵심 규정 12개를 정확히 맞힌 개수는 Opus가 12개 만점을 받은 반면, Haiku는 고작 5개만 건졌다.
특히 소름 돋았던 대목이 하나 있다. Haiku는 모 리그의 공식 룰북 PDF 링크가 파싱되지 않고 막히자, 사용자에게 에러를 알리지도 않고 조용히 “지난 시즌 규칙”을 위키에서 긁어와서 마치 최신 규정인 것처럼 뻔뻔하게 보고서를 써냈다. 이런 게 실무에서 가장 위험한 시한폭탄이다. 문장 형식과 서식은 완벽해서 대충 훑어보면 아무런 의심 없이 통과되기 십상이다.
블로그 글 두 편을 검수시키는 팩트체크 과제는 더 가관이었다. 실제 오탈자와 오류를 잡아낸 수는 Opus 8건, Sonnet 7건, Haiku 4건이었다. 진짜 심각한 문제는 ‘오탐(False Positive)’이었다. 멀쩡하게 맞는 문장을 “틀렸다”며 엉뚱하게 딴지를 건 횟수가 Opus는 0건, Sonnet은 6건, Haiku는 무려 30건에 달했다.
작성자의 표현을 빌리자면, “만약 Haiku의 검수 결과를 그대로 믿고 반영했다면 멀쩡한 글의 절반을 쓰레기통에 처박았을 것”이라고 한다.
단순 토큰 비용만 보면 웹 리서치 과제 5건을 수행하는 데 Opus는 $3.93가 들었고 Haiku는 $0.12밖에 안 들었다. 33배나 싸다. 하지만 Haiku가 싸질러놓은 30건의 오탐과 잘못된 가짜 정보를 사람이 다시 눈알 빠지게 검증하고 교정해야 하는 ‘인건비 시간’을 계산기에 넣는 순간, 이야기는 완전히 달라진다(싼 게 비지떡이라는 조상님들 말씀이 틀린 게 하나 없다).
왜 여기에 주목해야 할까
이 실험의 진짜 가치는 “어떤 모델이 짱이냐”는 유치한 승패 가르기가 아니라, 과제 유형별로 모델을 어떻게 지능적으로 라우팅할 것인가에 대한 명쾌한 기준을 세워줬다는 점이다.
- 코드 파일 검색, 단순 린트, 구조 파악: 무조건 저렴한 Haiku 5.5 몰아주기 (비용 14배 절감)
- 외부 문서 리서치, 팩트체크, 보안 검증: 타협 없이 최고 두뇌인 Opus 5.5 투입 (오탐과 구라 방지)
- 그 사이의 일반적인 코딩과 리팩토링: 든든한 Sonnet 5.5 배치
서브 에이전트가 일상화된 지금, 비용 절감의 핵심 단위는 ‘모델 하나를 고르는 눈’이 아니라 ‘적재적소에 일감을 쏴주는 라우팅 파이프라인’으로 넘어갔다.
재미있는 건 레딧 커뮤니티의 반응이었다. 이런 정밀한 실측 데이터가 공개됐음에도 베스트 댓글은 “난 복잡한 거 싫어하는 단순한 남자라 무조건 Opus에 올인한다”, “Opus 5.5 쓰면서 한 번도 토큰 한도에 걸려본 적 없다”는 상남자식 반응이었다.
이것도 틀린 말은 아니다. 월 정액 구독제를 쓰는 개인 개발자라면 머리 아프게 라우팅 짜느니 그냥 Opus 하나로 싹 밀어버리는 게 정신건강에 이롭다. 하지만 토큰당 과금되는 API로 서비스를 굴리는 스타트업이나 엔터프라이즈라면 14배의 비용 차이는 회사의 명운을 가를 수 있다. 요금제 환경에 따라 각자의 정답이 다른 셈이다.
정리
서브 에이전트 시대의 비용 최적화는 단순한 ‘지출 아끼기’가 아니라 정교한 ‘배치 예술’이다.
찾고 긁어오는 발품 팔이는 가장 저렴한 일꾼에게, 팩트를 가리고 검증하는 냉철한 심사는 가장 영리한 두뇌에게 맡겨야 한다. 무작정 아끼겠다고 하위 모델만 돌리면 엉터리 결과물 수습하느라 내 야근 시간만 늘어나고, 무작정 최고급 모델만 난사하면 지갑이 비명을 지른다.
내 에이전트 시스템에서 서브 에이전트들이 지금 무슨 일을 하고 있는지, 오늘 당장 라우팅 설정 파일부터 열어봐야겠다.