분담의 실측
3개 에이전트가 같은 작업 공간에서 돈 7개월치 이벤트를 집계하면 이렇게 갈렸다.
| 에이전트 | 이벤트 | 비중 | 주로 맡은 일 |
|---|---|---|---|
| Claude | 81,764 | 61% | 설계·리뷰·문서·의사결정 지원 |
| Codex | 43,557 | 33% | 코드 양산·반복 작업·빌드 |
| Gemini/Antigravity | 6,972 | 5% | IDE 내 보조·이미지/에셋 파이프라인 |
수치는 추정이 아니라 로그 집계값이다(출처 하단). 한 가지가 분명하다 — 균등 분배가 아니다. 61:33:5는 "골고루 써보자"가 아니라, 작업마다 비용 구조가 달랐다는 뜻이다.
왜 이렇게 갈렸나
세 모델을 번갈아 쓴 이유는 "어느 게 더 똑똑한가"가 아니었다. 틀렸을 때의 비용이었다.
- 설계·리뷰(되돌리기 비쌈) → 추론이 강하고 맥락을 길게 끄는 모델로. 한 번의 잘못된 구조 결정이 며칠을 잡아먹으니 여기서 토큰을 아끼지 않았다. → Claude 61%.
- 양산·반복(되돌리기 쌈) → 빠르고 저렴한 호출로 횟수를 버는 모델로. 25개를 동시에 돌려 3개를 건지는 식의 작업은 단가가 핵심. → Codex 33%.
- IDE 보조·에셋(맥락이 화면 안에) → 에디터에 붙은 모델로. → Gemini/Antigravity 5%.
실패 — 모델보다 런타임이 먼저 깨진다
분담을 자동화하려다 배운 게 하나 있다. 모델을 고르기 전에 런타임이 발목을 잡는다.
매일 1편을 자동 생성하는 헤드리스 파이프라인을 짜는데, bun으로 빌드된 claude 실행 파일이 print + 도구 사용(2턴 이상) 모드에서 즉사했다.
error_during_execution
TypeError: null is not an object (evaluating 'H.effortLevel')
같은 프롬프트를 node 기반 claude로 던지니 정상 동작했다. 모델은 동일한데 빌드 바이너리가 달랐다. "어떤 모델"을 고민하기 전에 "어떤 런타임에서 도는가"가 자동화의 첫 관문이었다.
그래서 어떻게 고르나
분담의 진짜 기준은 모델명이 아니라 인계 가능성이었다. 세 모델이 같은 작업 원장(파일·컨벤션·상태)을 읽고 이어 붙을 수 있으면, 누가 와도 일이 굴러갔다. 모델 비교표보다 "이 결과를 다음 에이전트가 5초 안에 이어받을 수 있나"가 분담을 결정했다.
다음 노트
다음엔 이 분담을 코드로 강제한 라우팅 규칙(되돌리기 비용 기준 dispatcher)을 푼다. 모델 셋을 한 손에 묶는 비용은 API가 아니라 컨벤션의 일관성이었다.
Editor's note: agent_event_counts(Claude 81,764 / Codex 43,557 / Gemini·Antigravity 6,972, 총 132,293)는 작업 로그 집계 실측. 분담 해석·effortLevel 런타임 사건은 실제 관찰 기반이며 일부 일반화. 모델·제품 평가는 로그 관찰 범위로 한정. 이 글은 AI 에디터가 실측 로그로 작성, 식별자 전부 익명.
