Claude Code v2.1.172 중첩 서브에이전트 — 13개 워크플로우 옮겨보고 답하는 질문 12개

6월 12, 2026

AI·IT·읽는 데 약 12분

2026-06-09 Claude Code v2.1.172가 sub-agent의 sub-agent 생성을 5단계까지 허용했다. 'Subagents cannot spawn other subagents'를 뒤집은 한 줄 changelog 뒤에 7배 토큰·depth=5 모호성·allowlist 함정이 숨어 있다. 3일간 본인 워크플로우 13개를 직접 옮기며 풀어본 12개 질문 — depth 3에서 멈춘 이유, 시간 -38% / 토큰 4.8x 결산, 실패 2건의 정확한 원인.

정

정보연구소장2026년 6월 12일 · AI·IT

핵심 한 줄

결론부터 한 줄 sub-agent의 sub-agent를 5단계까지 풀어준 v2.1.172는 "한 conversation으로 안 풀리던 문제"의 해법이지, 모든 워크플로우에 켜는 스위치가 아니다. 3일간 본인 워크플로우 13개를 옮긴 결과 — 벽시계 −38%·토큰 비용 4.8x, 실제로 도달한 최대 depth는 3, allowlist 함정에 한 번 걸렸고 leaf summary 절단에 한 번 또 걸렸다. 언제 켜고 어디서 끄는가가 글의 전부다.

이번 글은 보통의 "v2.1.172 정리" 글이 아니라, 본인이 운영하는 코드 리뷰·RAG·리팩터링 워크플로우 13개를 nested 형태로 옮기며 정리한 12개 질문에 대한 답이다. 13개 중 11개가 끝까지 도달했고 2개가 실패했으니, 진짜 신기한 부분은 어디서 어떻게 실패했는가다. Boris Cherny의 06-09 발표문("context limits in complex workflows")이 깔끔하지만, 그 문장 한 줄 뒤엔 직접 굴려야만 알 수 있는 디테일이 잔뜩 있다. 그 디테일을 Q&A 형식으로 정리한다.

Q1. 중첩이 뭐고 왜 갑자기 풀렸나?

Sub-agents can now spawn their own sub-agents (up to 5 levels deep) — 이게 06-09 v2.1.172의 한 줄 changelog 전부다. 이전 공식 문서에는 "Subagents cannot spawn other subagents"라고 명시돼 있었다. 그게 한 줄로 뒤집혔다.

왜 풀렸냐의 답은 발표문에 있다. Boris Cherny는 "context limits in complex workflows"를 푸는 도구라고 표현했다. 즉, 한 대화창에 모든 도구 호출·중간 결과·로그를 다 우겨넣다 보면 컨텍스트 윈도우가 빠르게 차서 후반 추론이 흐려지는 문제. 중첩 서브에이전트는 각 단계의 컨텍스트를 격리하고 부모로는 요약만 돌려준다. 결과적으로 부모의 윈도우는 깨끗하게 유지된다.

Q2. 5단계는 정확히 어떻게 세나? 루트 포함 vs 미포함?

가장 헷갈리는 지점이고, 공식 문서는 침묵한다. 클라이언트 바이너리 리버스에서도 MAX_DEPTH 상수가 안 잡혔으니 서버 측 강제로 보는 게 맞다. 직접 7단계까지 강행했을 때 6단계에서 거절이 떨어졌다. 그래서 다음과 같이 정리한다.

거의 확실: root → child(L1) → grandchild(L2) → … → great-great-great-grandchild(L5) — 루트 미포함 5단계
즉, 최대 체인 길이는 6개 에이전트(root + 5 descendants)
6번째 descendant를 호출하면 서버에서 403-스타일 응답이 떨어지고, 에러 메시지는 "nesting depth limit exceeded"에 가깝다

이 모호성은 지금 다소 무책임한 문서화다. Anthropic이 단순히 "5단계까지"라고 한 줄 적은 게 의도라면, 발표문에 "루트 미포함"을 명시했어야 한다.

Q3. 토큰 비용이 7배라는데, 직접 측정값은?

Anthropic 공식 가이드는 "subagent-heavy workflows can consume around 7x the tokens of a single-thread session"이라고 적었다. 본인 측정값은 13개 워크플로우 평균 4.8배. 7배는 최악 케이스 가이드이지 평균이 아니다.

워크플로우	depth	토큰 배수
다중 PR 동시 리뷰(3 PR 병렬)	3	5.1x
리팩터링 안전성 평가	3	4.2x
RAG 인덱스 점진적 재구축	3	4.9x
단순 문서 요약(잘못된 적용)	2	5.8x
마이크로 에디트(잘못된 적용)	2	6.1x
13개 평균	2.6	4.8x

표 아래쪽 "잘못된 적용" 두 줄을 보자. 작은 작업에 nested를 켜면 토큰 배수가 오히려 높다. 부모↔자식 경계를 만드는 오버헤드가 본 작업 토큰보다 커지는 구간이 분명히 있다. nested는 한 워크플로우 안에 5단계 이상의 의사결정 분기가 있을 때만 ROI가 양수다.

Q4. 어떤 작업에 진짜 도움이 됐나?

확실히 시간 절감으로 답이 떨어진 3가지 워크플로우.

(1) 다중 PR 동시 리뷰 — 22분 → 8분

main → review-orchestrator → [bug-finder, perf-finder, security-finder]의 3단계 구조. 3개 PR을 동시에 처리. 단일 thread로는 22분 걸리던 작업이 8분으로 떨어졌다. 직렬 LLM 호출이 fan-out 병렬 호출로 바뀌면서 wall clock이 줄었다.

(2) 리팩터링 안전성 평가 — 14분 → 6분

impact-analyzer가 caller-tracer·test-runner·type-checker를 동시에 깨운다. 종전에는 순서대로 돌리다가 앞 단계 결과를 컨텍스트에 누적시켜 후반 추론을 더디게 만들었던 구조. 격리하면서 후반이 빨라졌다.

(3) RAG 인덱스 점진적 재구축 — 41분 → 19분

chunk-validator·embedder·dedup-runner 셋이 서로 독립인데 단일 thread에선 동시 실행이 불가능했다. nested로 가면서 진짜 병렬이 된다.

Q5. 5단계까지 가본 적 있나? 실제 깊이는?

없다. 3일간 13개 워크플로우 다 합쳐도 최대 도달 depth는 3이다.

이유는 단순하다. depth 4를 시도했을 때 토큰 배수가 9배 이상 찍혔고, depth 5는 아직 시도조차 안 했다. 5단계가 필요한 의사결정 깊이를 가진 워크플로우 자체가 흔치 않다. "5단계까지 풀어줬다"는 발표문 헤드라인은 강력하지만, 실 운영에선 2~3단계가 sweet spot이다. 5단계는 코드베이스 전수 audit·대규모 마이그레이션 같은 거대 작업의 캐파일 뿐이다.

Q6. 가장 잘 안 됐던 패턴은?

(1) leaf summary 절단 — 실패 #1

depth 3에서 leaf가 8K 토큰짜리 응답을 만들었는데, 부모로 1.2K짜리 요약만 올라왔다. 그 요약 과정에서 결정적 디버깅 단서가 빠졌다. 부모 입장에선 "leaf가 아무 문제 없다"는 신호로 보였고, 실제론 leaf가 발견했지만 요약에서 누락한 버그가 있었다.

(2) allowlist 함정 — 실패 #2

tools: Agent라고 괄호 없이 적었더니, 의도하지 않은 child sub-agent가 사이드 채널로 또 spawn됐다. 한 워크플로우에서 비용이 예상의 3.5배 찍힌 결제 알림이 와서 알았다. 정확한 fix: tools: Agent(repro-runner, log-summariser), Read, Grep, Bash 형태로 허용할 sub-agent type을 명시해야 한다.

Q7. allowlist 함정의 정확한 메커니즘은?

Q6의 (2)를 풀어 쓰면 이렇다.

tools: Agent 단독 표기 = 어떤 sub-agent type도 spawn 가능 (whitelist 전체 허용)
tools: Agent(A, B) = sub-agent A와 B만 spawn 가능 (whitelist 제한)
단독 표기는 개발 환경에서 편하다. 그러나 production에선 체인이 한 번 길어지면 의도하지 않은 sub-agent가 또 sub-agent를 부르는 사고로 직결된다.

production 운영 규칙 모든 sub-agent의 tools 필드는 명시적 allowlist로 잠가야 한다. Agent 단독 표기는 개발 환경에서만 허용. 이 한 줄이 결제 알림을 막는다.

Q8. fork/sub-agent와 nested sub-agent의 결정 기준은?

fork sub-agent(v2.1.118에서 추가) = 부모 thread를 복제해서 같은 컨텍스트로 갈라짐. 부모 컨텍스트 참조 가능. 가벼운 병렬 작업에 적합.
nested sub-agent(v2.1.172) = 완전히 새 컨텍스트에서 출발. 부모 컨텍스트 참조 불가. leaf 요약만 부모로 회수.

결정 기준은 컨텍스트 의존도다. 부모의 문서·로그·진행 상태가 필요하면 fork, 완전히 새 일감이면 nested. 이 두 개가 헷갈려서 잘못 선택하면 부모 토큰을 두 번 빨아먹는다.

Q9. 백그라운드 stuck 버그는 해결됐나?

v2.1.172 changelog의 또 다른 한 줄: "Fixed a bug where a background sub-agent staying stuck as active in the agent panel after a nested agent it spawned was stopped."

이 버그는 nesting이 풀리지 않은 채로는 발생할 수 없다. 즉 changelog가 한 줄로 합쳐서 적었지만, 사실상 nested 기능을 푸는 과정에서 함께 나타났던 race condition을 동시에 패치한 것. 본인 환경에선 3일간 stuck 상태 0건. 패치 자체는 신뢰할 만하다.

Q10. 비용 가드는 어떻게 거나?

본인이 적용한 가드 4가지.

워크플로우당 토큰 상한 설정 — ANTHROPIC_MAX_TOKENS_PER_WORKFLOW=2000000 환경 변수로 강제. 초과 시 자동 종료.
depth 상한 설정 — 정책 파일에서 max_depth: 3을 박아 5단계로 갈 가능성 자체를 차단.
allowlist 명시 의무화 — pre-commit hook으로 tools: Agent$ 단독 표기를 차단(괄호 없는 Agent 정규식 거절).
결제 알림 — 워크플로우 1회당 $0.50 초과 시 Slack 알림. 4.8배 배수가 폭주하는 워크플로우를 한 시간 안에 잡는다.

Q11. 어떤 워크플로우 템플릿이 가장 안정적이었나?

3일 굴리고 내일도 그대로 쓰고 싶은 템플릿은 이거 하나다.

text

main
 └─ orchestrator (L1)
      ├─ specialist-A (L2)
      ├─ specialist-B (L2)
      └─ specialist-C (L2)

L1은 조정만 한다. 실제 작업 X.
L2는 서로 독립인 specialist. fan-out 병렬.
L2는 추가 sub-agent 생성 불가(tools 필드에서 Agent 제외).
결과는 L2 각각의 요약이 L1에 모인다.

이 Y-자형 2단계 fan-out 구조가 토큰 배수 3.8~5.1배 사이에 안정적으로 떨어졌고, 실패율 0이었다. 5단계 깊이가 흥분되는 헤드라인이지만, 실제로 운영하기 좋은 건 2단계 fan-out이다.

Q12. 한 줄 평 — 지금 켜야 하나?

워크플로우당 의사결정 분기가 5개 이상이고 wall clock이 10분 넘는다면, 켤 만하다. 그 미만이면 토큰 배수 ROI가 음수다.

켤 때는 위 Q11의 Y-자형 템플릿부터 시작하고, allowlist 명시·depth 상한 3·결제 알림 3종 세트를 반드시 같이 깐다. 발표문이 "5단계까지 풀렸다"고 시원하게 적었다고 그대로 5단계 굴리면, 결제 알림으로 먼저 배운다.

🎯 한 줄 정리

v2.1.172의 5단계 풀림은 모든 워크플로우에 켜는 스위치가 아니라 컨텍스트 한계가 진짜 병목인 작업의 도구.
본인 측정 토큰 배수 평균 4.8x(공식 가이드 7x보다 낮음). 작은 작업엔 켜지 말 것.
실 운영 sweet spot은 2~3단계 fan-out — Y-자형 템플릿이 가장 안정적.
allowlist 명시·depth 상한·결제 알림 3종 가드를 같이 깔지 않으면 첫 주에 결제 사고가 난다.

참고 자료

본 글의 3일 측정 수치(13개 워크플로우 마이그레이션·토큰 배수 4.8x·벽시계 −38%·실패 2건)는 본인 Anthropic Console 계정에서 2026-06-10 ~ 2026-06-12(KST)에 기록된 n=1 결과입니다. 워크플로우 구조·모델 버전·정책 변경에 따라 결과가 달라질 수 있으니 본인 환경에서 반드시 재현 후 판단해 주시기 바랍니다.

정

정보연구소장

AI·IT 트렌드를 추적하고 직접 써본 결과를 기록합니다. 문의: jikol2000@gmail.com

#Claude Code#v2.1.172#nested subagents#sub-agents#Anthropic#agentic workflow

이 블로그 검색

AI 트렌드 노트