비싼 모델은 계획만, 싼 모델이 코드를 — 멀티에이전트 비용 실측기
에이전트 하나로 끝낼 일을 여러 에이전트한테 쪼개서 줄까, 말까. 개발 커뮤니티에서 꽤 오래 답이 안 나온 질문이다. r/LocalLLM에 올라온 한 글이 이 논쟁에 조금 다른 걸 들고 나왔다. 경험담이 아니라 숫자. 같은 과제를 네 가지 구성에 똑같이 시켜보고, 시간과 비용, 통과한 테스트 수까지 적어 놨다.
논쟁을 숫자로 옮기다
이 글쓴이는 며칠 전 멀티에이전트 오케스트레이션을 쓰느냐는 질문을 다른 서브레딧에 던졌다. 조회수 8.3만, 댓글이 60개 넘게 붙었다. 답은 제각각이었다. 코드 작성은 에이전트 하나로 충분하다. 조사성 과제는 여러 명이 낫다. 멀티는 토큰을 갉아먹는다. 에이전트끼리 서로의 작업을 밟는다. 그래도 리드가 한 명 있으면 무너지지 않는다. 다들 각자 경험에서 나온 말이었고, 같은 과제를 놓고 비교한 숫자를 가진 사람은 없었다.
그래서 댓글에서 바로 뽑은 네 가지 구성에 동일한 일을 시켰다.
- Claude Code 단독 — Opus 5.5가 처음부터 끝까지 혼자 진행
- Codex CLI 단독 — GPT 5.5가 같은 지시로 단독 진행
- Paseo 에이전트 팀 — 비싼 리드가 싼 워커에게 구조화된 인계 프롬프트로 일을 넘김
- Atomic Agent 퓨전 모드 — 클라우드의 Opus 5.5가 계획을 세우고, 같은 맥에서 돌아가는 로컬 Qwen 3.8 27B(Q4)가 실제 코드를 작성
과제는 지출 관리 앱이다. 저장소, 은행 CSV 임포터, JSON API, CLI, HTML 월간 리포트 다섯 파트. 임포터가 받는 CSV는 일부러 지저분하게 만들었다. 날짜 포맷이 섞여 있고, 유로랑 파운드가 섞였고, 환불 행과 중복 행, 아예 깨진 행까지 있다. 다섯 파트가 설정 파일 하나를 공유하기 때문에 에이전트들이 서로 부딪힐 여지도 남겨뒀다. 채점은 에이전트들이 한 번도 본 적 없는 히든 테스트 38개로 했다. 실행은 M5 맥 한 대, 각 구성당 한 번씩.
나온 숫자
| 구성 | 모델 | 시간 | 히든 테스트 | API 비용 |
|---|---|---|---|---|
| Codex | GPT 5.5 | 5분 38초 | 38/38 | $1.32 |
| Claude Code | Opus 5.5 | 6분 57초 | 38/38 | $1.27 |
| Paseo 팀 | Opus 5.5 리드 | 5분 25초 | 38/38 | $1.13 |
| Atomic Agent 퓨전 | Opus 계획 + 로컬 Qwen 실행 | 3분 11초 | 38/38 | $0.40 |
네 구성 모두 38개 테스트를 다 통과했다. 병합 충돌은 어디에서도 일어나지 않았고, 입력 파일을 건드린 에이전트도 없었다. 갈린 건 시간과 비용이다. 퓨전 모드가 가장 빨랐고, 청구서는 3분의 1 수준.
두 가지 반전
“멀티에이전트는 토큰을 잡아먹는다”는 말이 이번엔 틀렸다. 워커를 로컬 GPU에 둔 구성이 가장 적은 금액을 냈다. 비싼 모델은 판단에만 쓰고, 코드라는 몸 노동은 토큰값이 없는 로컬 모델에 시키면 이런 차이가 나온다. 오케스트레이션의 매력이 병렬 속도가 아니라 역할 분리에 있다는 얘기다.
재미있는 쪽은 Paseo다. 리드 모델이 과제를 훑어보더니 작다고 판정했는지, 워커를 한 명도 안 띄우고 혼자 전부 해치웠다. 그 셋업을 공유한 원작자의 설명과 정확히 같은 동작이다. 간단한 건 직접 한다. 과제를 나눌지 말지 스스로 판단하는 오케스트레이터. 이게 버그가 아니라 기능이라는 걸 보여준 사례다.
다만 이 숫자를 그대로 받아들이긴 어렵다. 각 구성을 한 번씩만 돌렸고, 과제 규모도 실제 일 중 가장 작은 쪽에 가깝다. 글쓴이도 다음 라운드는 나누는 게 당연한 크기로 하겠다고 밝혔다. 작은 과제에서 이긴 구성이 큰 과제에서도 이길지는 아직 모르는 일이다.
왜 주목할까
이 글이 눈에 띄는 건 퓨전 모드가 이겨서가 아니다. 커뮤니티에서 오래 자료 없이 굴러오던 통념을 같은 과제 위에 올려놓고 하나씩 결과를 댔기 때문이다. 싱글이 코딩에 낫다는 말은 이 규모에선 맞았다. 멀티가 토큰을 태운다는 말은 워커를 로컬에 두면 뒤집혔다. 에이전트가 서로 밟는다는 것도 이번엔 해당 없었다. 통념이 틀려서가 아니라, 전제가 과제 크기에 달려 있다는 걸 숫자가 보여준 셈이다.
로컬 모델을 워커로 쓰는 발상도 눈여겨볼 만하다. 클라우드 구독료만으로 에이전트를 돌리던 흐름에, 이미 집에 있는 GPU를 노동력으로 투입하는 선택지가 붙은 것이다. 비용이 토큰당 과금이 아니라 전기요금이 되면, 에이전트가 실수를 고치느라 반복 호출하는 것도 부담이 아니다. 모델이 조금 못살아도 여러 번 시킬 수 있다는 계산이 성립한다.
정리
API 비용은 3분의 1, 통과한 테스트는 같다. 싱글로 갈지 멀티로 갈지는 취향 문제가 아니라 과제 크기와 비용 구조의 문제에 가까워지고 있다. 이 실험 하나로 결론이 나는 것도 아니고, 표본이 한 번뿐인 건 분명하다. 그래도 숫자를 직접 뽑아 통념을 검증해본 절차 자체가 참고할 만하다. GPU가 굴러다니는 집이라면, 다음 과제 후보를 뽑아 같은 방식으로 재볼 만하다. 어느 쪽이 이기든 이번엔 남의 경험담이 아니라 내 환경의 숫자를 갖게 된다.