서론

Claude Code로 서브 에이전트(sub-agent)를 병렬로 실행하는 운용을 수개월간 지속하며, 온갖 실패를 경험했습니다. 가장 큰 사건은 75개의 병렬 팬아웃(fan-out)으로 5.25M 토큰을 소비하여, 429(Rate Limit) 및 이용 한도 초과로 중단된 건입니다.

영어권에서는 「The 5 Failure Modes of Multi-Agent Claude Systems」와 같이 실패 유형을 정리하는 움직임이 시작되었지만, 일본어로는 아직 체계적인 기사를 찾아볼 수 없기에, 실측치를 포함한 실패 5가지 유형과 대책을 정리합니다. 멀티 에이전트(multi-agent)를 "이제 막 늘리려는" 단계에 있는 분들에게 가장 도움이 될 것입니다.

유형 1: 팬아웃(Fan-out)의 원가 계산을 하지 않음 (최대 비용의 실패)

실측: 75개의 병렬 서브 에이전트 = 5.25M 토큰. 에이전트 1개당 약 70K 토큰의 고정비(시스템 프롬프트, 도구 정의, 컨텍스트) × 에이전트 수가 지배적인 항목이 되어, 태스크의 내용보다 "기동 비용"으로 예산이 낭비되었습니다. 결과는 429 에러의 폭풍과 시간제 과금 한도 초과였습니다.

대책은 에이전트 수를 "태스크의 수"가 아니라 "Rate Limit/한도 엔벨로프(envelope) 안에 들어오는가"를 기준으로 결정하는 것입니다.

• 검증(verify/judge) 페이즈를 생성 페이즈에 통합 —— 에이전트 수의 최대 절감
• 독립 검증은 배치(batch)화 한다 (1건당 1개로 하지 않음)
• 단순 작업 에이전트는 소형 모델을 명시적으로 지정한다
• 병렬도를 좁혀서 파동을 나누어 429 에러를 회피한다

체감상 기준으로는 병렬 서브 에이전트는 2~15개가 실용적인 범위였습니다. 코디네이터(coordinator)형(관리역이 하위 에이전트를 묶는 구성)은 전달 비용으로 인해 3~4배의 토큰이 소모되므로, 묶을 가치가 있을 때만 사용합니다.

유형 2: 병렬 에이전트가 동일한 파일을 건드리게 함

병렬화 시 가장 재현성이 높은 사고입니다. 기존 파일의 동시 편집은, 나중에 도착한 에이전트가 먼저 도착한 에이전트의 변경 사항을 덮어써서 지워버립니다. 제 환경에서는 3개의 서로 다른 프로젝트에서 독립적으로 재발했습니다. 병렬로 실행되는 동안 각 에이전트는 서로의 변경 사항을 알지 못하므로, 이는 확률의 문제가 아니라 구조의 문제입니다.

운용 규칙은 간단합니다:

유형 3: 서브 에이전트의 "완료 보고"를 믿음

서브 에이전트의 완료 통지는, 약 3할의 빈도로 도중에 끊긴 불완전한 보고가 돌아왔습니다 (제 운용에서의 체감치). "done"이라고 말하고 있는데 결과물이 절반뿐이거나, 커밋되지 않았거나, 테스트를 통과하지 못하는 등 —— 보고와 실체의 괴리입니다.

대책은 보고를 검증에 사용하지 않는 것입니다. 완료 판정은 git log / git diff / 테스트 실행 출력으로 직접 확인합니다. 에이전트의 자기 신고는 진행 상황의 힌트일 뿐, 증거가 아닙니다.

관련된 함정으로, 서브 에이전트에는 출력 토큰 상한이 있으며, 사고(thinking) 과정도 상한을 소모하기 때문에, 높은 추론 에포트(effort)를 지정한 서브 에이전트가 "너무 많이 생각하다가 출력 없이 종료"되는 경우가 있습니다 (claude-code#78460). 탐색 계열의 에이전트는 에포트를 낮게 설정하는 것이 안정적입니다.

유형 4: 모니터링을 서브 에이전트에게 맡김

장시간 작업의 모니터링을 서브 에이전트에게 맡기면, 서브 에이전트의 턴이 종료됨과 동시에 모니터링만 무언으로 소멸합니다 (작업 본체는 살아있는데, 깨어나는 메커니즘만 상실됨. claude-code#82409). "모니터링을 시켰는데 아무런 보고가 오지 않는다"의 정체가 이것이었습니다.

모니터링 및 대기는 부모(메인 세션) 측의 책무로 한다는 것이 원칙입니다. 자식은 "수행하고 결과를 반환한다"는 순수 함수적인 사용법에 집중하면, 이러한 조용한 소멸과 무관해질 수 있습니다.

유형 5: 역할 설계를 도구에 맡기고 구조로 생각하지 않음

"일단 에이전트를 늘리자"라고 하면, 늘린 만큼 유형 1~4의 문제 발생 가능성이 증가합니다. 영어권의 정리에서도 coordinator 패턴의 기초나 agent teams와 subagents의 구분 사용법처럼 "구조를 먼저 결정하는" 방향으로 수렴하고 있습니다.

저의 판단 기준은 딱 두 가지입니다:

• A의 완료가 B의 착수 조건이 아니다 + 동일 파일 동시 변경 없음 $\rightarrow$ 병렬로 만들 가치가 있음
• 둘 중 하나라도 어긋남 $\rightarrow$ 직렬로 전환 (병렬의 겉보기 속도보다, 재작업 제로가 총 비용 면에서 더 저렴함)

요약 (5가지 유형과 대책 대응표)

멀티 에이전트 (Multi-agent)는 "지능의 배증 장치"가 아니라 "설계 실수의 배증 장치"였습니다. 구조를 먼저 결정한 뒤에 에이전트 수를 늘린다면, 제대로 된 속도 향상을 경험할 수 있습니다.

여러분의 환경에서 발생한 실패 사례(및 에이전트 수·토큰 실측값)를 댓글로 들려주세요. 실측값이 모일수록 이 유형 표는 더욱 유용해질 것입니다.

실측값은 저자의 Claude Code 운용 기록(2026년)에서 추출한 수치입니다. 요금 및 제한 사항의 사양은 변경될 수 있으므로, 에이전트 수의 기준은 본인의 환경에서 재측정하시기 바랍니다.

Discussion