이 글은 제가 원래 Zenn에 (일본어로) 게시했던 기사의 영어 버전입니다.

"역할별 에이전트(agent)로 업무를 분할하면 품질과 비용이 모두 개선될 것이다" — 이것이 제가 구축한 자동화된 기술 블로그 파이프라인(pipeline)의 전제였습니다. 하지만 측정 결과는 그 반대였습니다. 서브 에이전트(subagents)를 11개에서 0개로 줄였을 때, 총 토큰(token) 사용량은 실제로 27.7% 증가했지만, 기사 한 편을 제작하는 비용은 87.7% 감소했습니다. 이것은 코드를 전혀 작성하지 못하는 사람이 오직 Claude Code 프롬프트(prompt)만으로 이 파이프라인을 구축하고, 측정된 수치를 바탕으로 설계를 뒤집은 실전 기록입니다.

문제: 에이전트가 많을수록 더 좋을 것이라고 가정했습니다

이 파이프라인은 여러 개의 블로그를 무인으로 생성하기 위해 제가 — 순수하게 Claude Code 프롬프트만으로 — 구축한 사내 시스템입니다. 프로그래머가 작성한 코드는 단 한 줄도 없습니다. 저는 예약 시스템, 게임, 메뉴 바 앱도 같은 방식으로 만듭니다.

기술 블로그 파이프라인의 첫 번째 버전은 전문가 집단을 조정하는 수장(chief)이 포함된 **7-에이전트 설정(7-agent setup)**이었습니다.

• chief (오케스트레이션 (orchestration))
• keyword (주제 선정 (topic selection))
  )
• research (1차 자료 조사 (primary-source research))
• outline (구조 (structure))
• writer (초안 작성 (drafting))
• publish (제출을 위한 포맷팅 (formatting for submission))
• qa (점수 산정 (scoring) — 독립적인 프로세스)

자연스럽게 느껴졌습니다. 인간 팀은 역할을 나눌 때 더 전문화되므로, "주제 선정자"와 "작가"를 나누면 각자가 자신의 업무에 집중할 수 있을 것이라 확신했습니다. 그것이 이론이었습니다.

측정: 기사당 41.7달러가 실제로 어디로 가고 있었는가

이 7-에이전트 설정 하에서 실제로 완료된 기사 한 편의 토큰 내역을 계산해 보았습니다 (로컬 이미지 생성에 관한 실전 기사, 본문 약 4,000자, 다이어그램 2개, 2026-07-14 발행). 결과는 다음과 같습니다.

최종 출력물(기사 본문)은 약 4,000 토큰에 불과했습니다. 즉, 총 토큰 사용량은 결과물 대비 약 1,738배였습니다. 이를 더 자세히 분석하면, 청구된 토큰(5,455,523)의 79%가 "캐시 재읽기 (cache re-reads)"였습니다. 즉, 실행이 에이전트 경계를 넘을 때마다 동일한 공유 컨텍스트(시스템 프롬프트 (system prompt), 기술 정의 (skill definitions), 역할 정의 (role definitions))를 매번 다시 읽었던 것입니다.

결정적인 요인은 설계 전제였습니다. 각 단계가 "한 번에 하나씩, 순서대로" 실행되었습니다. 다시 말해, 병렬 토론도 없었고 교차 검증 (cross-checking)도 없었습니다. 7개의 본체로 나누는 것은 동일한 모델이 동일한 소스 자료를 바탕으로 판단을 내린다는 사실을 바꾸지 못했습니다. 분할은 비용만 발생시켰을 뿐, 판단의 품질에는 아무런 기여를 하지 못했습니다.

결과: 토큰은 27.7% 증가했으나, 비용은 87.7% 감소

그래서 저는 7개 에이전트 설정을 폐기하고(자매 파이프라인은 9개의 에이전트를 사용했습니다), 6개의 단계 — ① 주제 (topic) → ② 주요 소스 (primary sources) → ③ 개요 (outline) → ④ 초안 작성 (drafting) → ⑤ QA → ⑥ 제출 (submission) — 를 "단계 (steps)"로서 위에서 아래로 실행하는 단일 세션으로 통합했습니다. QA만이 별도의 프로세스로 남았습니다 (이에 대해서는 아래에서 더 자세히 다루겠습니다). 아래 차트는 기존 설계와 새로운 설계 하에서 동일한 기사를 완료할 때까지 실행하여 측정한 비교 결과입니다.

A diverging bar chart showing that consolidating subagents from 11 to 0 changed total tokens +27.7%, cache writes -76.1%, cache reads +55.0%, and cost -87.7%.

기사 한 건, 완료 실행 vs 완료 실행 (내부 측정 기록 기준, 2026-07-17).

언뜻 보기에 수치는 모순되어 보입니다. 총 토큰은 6,954,254 → 8,880,984로 27.7% 증가했습니다. 캐시 읽기 (Cache reads) 또한 5,455,523 → 8,457,896으로 55.0% 증가했습니다 (전체 워크플로우의 컨텍스트가 하나의 세션에 실려 가기 때문에 읽기가 실제로 누적됩니다). 그럼에도 불구하고 비용은 $41.68 → $5.12로 87.7% 감소했습니다.

그 이유는 캐시 "쓰기 (writes)"와 캐시 "읽기 (reads)" 사이의 가격 차이 때문입니다. 실행이 에이전트 경계(agent boundary)를 넘을 때마다 새로운 컨텍스트 재-프리필 (re-prefill, 캐시 쓰기)이 발생하며, 이 작업은 1,402,348 → 334,689 토큰으로 76.1% 감소했습니다. 내부 운영 로그에 따르면, 쓰기 작업은 읽기 작업보다 대략 12.5배 더 비쌌습니다 ($3.75/M vs $0.30/M — Anthropic의 공식 가격표가 아닌 내부 추정치). 읽기가 아무리 증가하더라도 쓰기가 76% 감소한다면 결과적으로는 이득입니다.

왜 "쓰기"가 그렇게 비쌀까요? 프롬프트 캐싱 (Prompt caching)은 공유된 서문 (시스템 프롬프트, 기술 정의, 역할 정의)을 한 번 프리필하여 KV 캐시 (KV cache)에 로드하고, 그 이후부터는 이를 "읽기"만 합니다. 읽기는 이미 캐시된 접두사 (prefix)를 재사용하기 때문에 저렴합니다. 하지만 서브 에이전트 (subagent)를 생성할 때, 부모의 KV 캐시는 그대로 상속되지 않습니다. 자식 에이전트는 동일한 공유 서문을 다시 로드하여 캐시에 다시 "쓰기"를 해야 합니다. 이것이 바로 재-프리필 (re-prefill)이며, 캐시 쓰기에 프리미엄 요금이 부과되는 이유입니다. 에이전트 경계마다 발생하는 높은 재-쓰기 (re-write) 비용이 누적되었던 것입니다. 통합을 통해 이러한 재-쓰기 횟수를 직접적으로 줄일 수 있었습니다.

그렇긴 하지만, 솔직히 말해서 그 비용 차이 전부가 통합의 효과만은 아닙니다. 내부 분석 결과 통합 자체가 약 40%를 차지했고, 나머지 약 60%는 모델 선택 (Opus → Sonnet)의 영향이었습니다. 이는 단순히 "에이전트를 삭제했더니 마법처럼 저렴해졌다"는 뜻이 아니라, "에이전트 경계에서의 재-프리필 비용을 줄이는 동시에 모델을 재검토했다"는 결합된 결과입니다.

그럼에도 불구하고 분리해 둔 단 한 가지

QA (질의응답/품질 검사)는 제가 통합하지 않은 유일한 단계로, 별도의 프로세스(저렴한 모델을 통한 독립적인 스코어링)로 유지했습니다. 이유는 간단합니다. 생성 모델이 자신의 출력물에 직접 점수를 매기게 하면, 평가는 생성의 편의성 쪽으로 치우치게 됩니다. 본인이 쓴 글에 스스로 솔직하게 75점을 줄 수 있느냐의 문제입니다. 저는 이를 분리 비용을 지불할 가치가 있는 몇 안 되는 예외 중 하나로 취급합니다.

이로부터 추출할 수 있는 일반적인 규칙은 단 한 문장으로 요약됩니다: "이 단계가 진정으로 병렬적으로 토론하고 교차 검증(cross-checking)을 수행하고 있는가, 아니면 단순히 한 번에 하나씩 순차적으로 진행되고 있는가?" 만약 후자라면, 에이전트 경계(agent boundary)는 프리필(prefill) 비용만 발생시키는 장식에 불과합니다. 만약 전자라면(독립적인 시각이 필요한 단계라면), 비용을 지불하더라도 분리할 가치가 있습니다.

재현 가능한 교훈

만약 당신의 파이프라인이 "역할별로 에이전트를 분리"하고 있다면, 먼저 해당 단계가 실제로 병렬적이고 독립적인 판단을 내리는지 확인하십시오. 그렇지 않다면, 에이전트 경계는 컨텍스트 재프리필(context re-prefill)을 유발하는 값비싼 파일 전달(file hand-off)일 뿐입니다. 각 단계가 자신의 차례를 기다리며 직렬(serially)로 실행되는 설계에서, 분리는 비용 낭비에 불과합니다.

다음 두 가지 질문으로 각 단계를 분류하면 결론은 빠르게 나옵니다:

1. 이 단계가 여러 후보를 병렬로 경합(race)시키는가? — 만약 '아니오'라면, 분리는 병렬성을 만들어내지 못하며 경계의 재프리필 비용만 남게 됩니다. 이를 통합하십시오.
2. 이 단계에 독립적인 검증자(생성자(generator)와 이해관계가 다른 시각을 가진 존재)가 필요한가? — 만약 '예'라면, QA(품질 보증)처럼 비용을 지불하고 분리할 가치가 있습니다.

두 질문 모두에 '아니오'인 단계는 통합하십시오. 둘 중 하나라도 '예'인 단계만 경계를 유지합니다. 반대로, 단계들이 진정으로 동시에 실행되고 서로의 중간 결과에 따라 동적으로 분기(branch)한다면 — 즉, 여러 후보를 동시에 경합시키고 부분적인 결과에 따라 다음 단계를 전환한다면 — 그 경계는 프리필 이상의 역할을 수행하고 있는 것입니다. 단순히 한 번에 하나씩 전달만 하는 단계는 통합하고, 진정으로 동시성(concurrency), 독립성(independence), 또는 동적 분기(dynamic branching)가 필요한 단계만 분리하십시오. 그것이 기준점입니다.

사실, 이 글 자체가 "에이전트가 많을수록 더 똑똑해진다"라는 초기 직관이 측정을 통해 뒤집힌 기록입니다. 분리는 공짜가 아닙니다.