이 기사에 대하여

MIKE(@mikenevermiss) 씨가 2026년 7월 27일에 공개한 장문의 기사 **"Graph Engineering: How to Stop Building AI Agents That Wait in Line"**를 분석합니다.

원문은 "에이전트 시스템을 체인(직선)이 아닌 그래프로 설계해야 한다"라는 주장을, Claude Code의 dynamic workflows를 구현 사례로 전개한 것입니다. 약 22만 회 조회되었습니다.

기사 내의 주요 사실은 Anthropic 공식 기술에 의거하고 있으므로, 이 기사에서는 1차 정보로 사실 확인을 거친 후 정리했습니다.

• A harness for every task: dynamic workflows in Claude Code (Anthropic, 2026년 6월 2일)
• 공식 문서: Orchestrate subagents at scale with dynamic workflows

먼저 한 줄로 요약하자면 다음과 같습니다.

에이전트에게

공정을 추가하는 것을 멈추고, 형태를 바꿔라. 속도·비용·신뢰성을 가장 크게 좌우하는 것은 모델이 아니라 토폴로지(Topology, 그래프의 형태)이다.

제1부 — 왜 '한 줄 서기'는 무너지는가

누구나 처음에는 체인을 작성한다

조금 복잡한 일을 에이전트에게 시키려고 하면, 대개 이런 형태가 됩니다.

파일 읽기 → 요약하기 → 규칙과 대조하기 → 리포트 작성하기

각 공정이 하나의 프롬프트(Prompt)입니다. 이전 공정이 끝날 때까지 다음 공정은 기다립니다. 자연스러운 형태입니다. 우리가 타이핑하는 순서 그 자체이기 때문입니다.

짧은 작업이라면 이것으로 충분합니다. 망가지기 시작하는 것은 작업이 길어질 때, 옆으로 확장될 때, 그리고 에이전트에게 자신의 업무를 채점하게 했을 때입니다.

Anthropic이 명명한 3가지 실패 모드

공식 기사는 하나의 컨텍스트 윈도우(Context Window) 안에서 에이전트를 길게 작동시킬 때 발생하는 일을 세 가지로 분류하고 있습니다.

중요한 점은, 이 세 가지 모두 공정을 추가한다고 해서 해결되지 않는다는 점입니다.

한 줄로 세워둔 채 공정만 늘리면, 동일한 컨텍스트가 더욱 무거워질 뿐입니다. 해결책은 형태를 바꾸는 것 — 작업 단위마다 새로운 깨끗한 컨텍스트를 부여하고, 신뢰하기 전에 검증을 거치는 것입니다.

공식 기사의 표현도 동일합니다. 워크플로우는 "각각 고유한 컨텍스트 윈도우와 초점이 맞춰진 고립된 목표를 가진 별개의 서브 에이전트(Sub-agent)"를 편성함으로써 이에 대응합니다.

"and then" 테스트

자신이 작성한 체인 중 얼마나 많은 부분이 정말로 필요한지 밝혀내는 간단한 진단법이 있습니다.

공정 사이의 "그리고 다음에(and then)" 하나하나에 대해 질문합니다.

다음 공정이 이전 공정의 출력을 실제로 읽고 있는가?

원문의 예가 이해하기 쉽습니다. "파일을 요약하고, 그다음에 내일 날씨를 조사해줘" — 이 두 가지 사이에는 아무런 관계가 없습니다. 날씨는 요약을 소비하지 않습니다. 독립된 두 가지 작업을 일직선 스크립트가 멋대로 사슬로 묶어놓은 것뿐입니다. 그 대기 시간은 아무런 가치가 없습니다.

체인도 그래프이다 (단, 최소 규모이며 가장 취약하다)

이 부분이 인지의 전환점입니다.

일직선 체인은 그래프가 아닌 것이 아닙니다. 그릴 수 있는 것 중 가장 작고, 가장 취약한 그래프입니다. 분기가 없는 외길이며, 어떤 노드(Node)도 입구가 하나, 출구가 하나뿐입니다. 중복성(Redundancy)은 제로입니다.

• 어딘가 한 곳이 막히면 하류(Downstream)는 전부 멈춘다.
• 그리고 상류(Upstream)는 결과물을 둘 곳이 없는 채로 남겨진다.

고쳐야 할 것은 길이가 아닙니다. 너비입니다.

제2부 — 어휘: 노드와 에지

그래프의 구성 요소는 단 두 가지입니다. 에이전트 설계의 혼란 대부분은 이 두 가지를 혼동하는 데서 옵니다.

노드 = 경계가 있는 하나의 작업

1개의 에이전트, 명확하게 구분된 하나의 작업, 1개의 입력, 1개의 출력.

"고객과의 상호작용을 처리한다"는 노드가 아닙니다. 너무 광범위합니다. "이 티켓 1건을 분류한다", "이 파일 1개를 특정 종류의 버그에 대해 조사한다" — 이 정도의 입도(granularity)여야 합니다.

에지 = 의존 관계. 그뿐입니다.

에지가 의미하는 것은 "이 노드의 출력이 저 노드의 입력이 된다"는 것입니다. 그 이상의 의미는 없습니다.

따라서 다음과 같습니다.

에지를 진짜로 만드는 것은, 데이터가 실제로 그곳을 통과하는 것뿐입니다.

이미 만들어 버린 에이전트에 대해 이 검사를 할 수 있습니다.

두 공정 사이에 그은 모든 화살표에 대해,

거기를 통과하는 구체적인 데이터를 지목할 수 있는가?

지목할 수 없다면, 그 두 공정은 독립적입니다. 그 사이에 있는 대기는 순수한 오버헤드입니다.

노드에는 계약이 필요하다

노드를 큰 그래프에 통합하여 안전하게 사용하는 것은, **계약 (contract)**을 가지고 있을 때뿐입니다.

• 경계가 정해진 입력
• 정의된, 가급적이면 검증된 출력 형태

즉, 다음 공정이 파싱하며 "망가지지 않았기를 기도하는" 식의 자유 텍스트가 아니라, **그대로 사용할 수 있는 구조화된 데이터 (structured data)**를 반환하는 것입니다.

이것이 있으면 에지의 양 끝에 있는 에이전트를 교체할 수 있습니다. 여러 노드를 병렬로 실행하더라도, 출력이 예상과 조금 다르다고 해서 전체가 조용히 무너지는 일이 발생하지 않습니다.

제3부 — 6가지 유형

노드와 에지가 명확해지면, 실제 에이전트 시스템은 아주 적은 수의 형태로 거의 모두 커버할 수 있습니다. 권장하는 순서대로 나열합니다.

1. Fan-out (부채꼴로 펼치기)

독립된 작업이 N개 있다면, 순서를 기다리게 하지 않고 동시에 실행합니다.

여기서 유효한 설계 규율은 **내결함성 (fault tolerance)**입니다. 하나의 노드가 실패하더라도 배치 (batch) 전체를 침몰시켜서는 안 됩니다. 실패한 단위는 크래시(crash)가 아니라 빈 값으로 반환되도록 만들고, 다음 단계로 넘어가기 전에 빈 값을 제거합니다.

2. Fan-in (barrier로 모으기)

펼쳐진 것들은 무언가가 모으지 않으면 의미가 없습니다. barrier는 상류의 결과가 모두 갖춰질 때까지 다음으로 진행할 수 없는 지점입니다.

그리고 중요한 것은, 이것은 예외이지 기본값이 아니라는 점입니다. 모든 것이 갖춰지는 것이 정말로 필요한 경우에만 사용합니다.

• 모든 소스를 가로지르는 중복 제거
• 리스트 전체의 랭킹 (ranking)
• "1건도 돌아오지 않았으므로 조기 종료한다"는 판단

3. Diamond (다이아몬드)

Fan-out과 Fan-in을 조합한, 제대로 된 에이전트 시스템의 거의 모든 배후에 있는 형태입니다. 펼치고, 일하게 하고, 요약한다.

세 부분으로 나누어 이름을 붙일 가치가 있습니다.

① fan out: 폭을 확보 (에이전트 여러 개)
② reduce: 일반적인 코드 몇 줄로 압축 (평탄화, 중복 제거)
③ synthesize: 완전한 압축 세트가 필요한 마지막 1개의 에이전트

②가 핵심입니다. 리스트를 평탄화하는 것도 중복을 제거하는 것도 결정론적인 (deterministic) 코드로 충분합니다. 에이전트는 필요 없습니다. 중앙의 에지는 비용이 들지 않으며, 아래의 barrier만이 대기할 가치가 있습니다.

4. Routing (라우팅/분배)

모든 경로가 고정되어 있다고 할 수는 없습니다. **라우터 노드 (router node)**가 결과를 보고 다음에 어떤 에지를 발화시킬지 결정합니다. 지원 티켓을 분류하여 적절한 담당자에게 보내거나, 변경 규모를 보고 가벼운 리뷰를 할지 전면 감사를 할지 선택합니다.

여기에 중요한 설계 판단이 있습니다.

분류는 에이전트의 판단에 맡겨도 좋습니다. 하지만 라우팅 자체는 일반적인 코드로 작성하십시오.

그렇게 하면 동일한 입력은 매번 동일한 경로를 통과합니다. 모델의 머릿속에 판단이 매몰되어 예측할 수 없는 분기가 발생하는 일이 없습니다.

5. Verification (검증)

그래프의 진정한 레버리지는 에이전트를 늘려 작업을 시키는 것이 아닙니다. 찾아낸 것에 대한 확신을 얻기 위해 주변에 둘러싸는 구조입니다.

검증자는 에지 위에 앉아, 결과가 하류로 내려가는 것을 허용하기 전에 가로막습니다. 그 유일한 업무는 그 발견을 반증하려고 시도하는 것입니다. 살아남으면 통과시키고, 살아남지 못하면 리포트에 올라가지 않습니다.

제1부의 세 가지 실패 모드를 떠올려 보세요. 자기 우대 편향(Self-preference bias)은 "자신의 업무를 스스로 채점하게 할 때" 발생합니다. 다른 컨텍스트를 가진 별도의 에이전트에게 반증하게 하는 것이 그 구조적인 대책입니다.

6. 수렴하는 사이클

업무량이 사전에 파악되지 않는 경우가 있습니다. 버그 찾기처럼, 하나를 발견하면 세 개가 더 보이는 식의 업무입니다. 이를 위해서는 이전 노드로의 제어된 루프(Loop)가 필요합니다.

위험 요소는 명확합니다. 종료 조건(Exit condition)이 없는 사이클은, 같은 지점을 재발견하며 예산만 소진하는 무한 루프가 됩니다.

실제로 작동하는 것은 loop-until-dry입니다.

몇 라운드 연속으로 새로운 것이 나오지 않을 때까지 계속한다. 그리고 멈춘다.

그리고 여기가 치명적으로 중요한 디테일입니다.

새로운 발견을 대조할 대상은, **"확인된 것"이 아니라 "지금까지 본 전부"**로 설정해야 합니다.

기각된 결과를 기록하지 않으면, 그것은 매 라운드 다시 떠오르게 됩니다. 루프는 같은 막다른 길을 재발견하기 위해 영원히 돈을 지불하게 될 것입니다.

공식 6가지 패턴과의 대응

원문은 이 6가지 형태가 Anthropic이 dynamic workflows를 위해 명명하고 문서화한 6가지 패턴과 깔끔하게 대응한다고 지적합니다. 공식 문서에서도 확인되었습니다.

tournament는 기억해 둘 가치가 있습니다. 공식 문서에서는 1,000행이 넘는 정렬(Sort)을 예로 들고 있는데, 이유는 명확합니다 — 비교 판단은 절대 평가보다 신뢰할 수 있기 때문입니다. 명명, 랭킹, 순위 매기기와 같이 "절대적이라기보다 상대적인" 판단에 적합합니다.

제4부 — 구현에서 정말 효과적인 4가지 포인트

(1) 실패를 격리하라. 쓰기(Write)도 격리하라

병렬 실행 시 망가지는 방식은 두 가지이며, 대책도 다릅니다.

두 번째 방식은 Claude Code에서 worktree의 격리 형태로 제공됩니다. 공식 문서에서도 워크플로우는 "에이전트가 어떤 모델을 사용할지, 서브 에이전트를 자신의 worktree에서 실행할지"를 결정할 수 있다고 명시하고 있습니다.

단, 주의할 점이 있습니다. 이것은 해당 기능이 필요한 특정 토폴로지(Topology)를 위한 안전벨트이지, 모든 그래프에 강제해야 하는 세금이 아닙니다. 격리에는 설정과 디스크 비용이 따릅니다.

(2) 모델을 그래프 전체에서 계층화하라

모든 노드가 동일한 무게를 가진 것은 아닙니다.

1개 필드를 추출하거나, 1개의 티켓을 분류함 → 경계가 명확하고 반복적임 → 저렴한 모델
최종 리포트를 합성하거나, 쟁점을 판정함 → 판단이 필요한 곳 → 최상의 모델

그리고 이것은 의도적으로 수행하지 않으면 일어나지 않습니다.

기본적으로 생성된 모든 노드는 그것을 시작한 세션의 모델을 상속받습니다. 계층화는 노드마다 명시했을 때만 실현됩니다.

(3) 토폴로지는 비용 레버(Cost Lever)이다

이 부분이 가장 많이 실수하는 지점이며, 가장 큰 비용이 발생하는 지점입니다.

barrier(장벽)는 다른 9개가 순식간에 끝나더라도, 하류(Downstream)의 모든 공정이 가장 느린 하나가 끝날 때까지 기다리게 만듭니다.

반면, 각 아이템을 동기화 지점 없이 독립적으로 모든 단계에 흘려보내면, 빠른 아이템은 느린 아이템보다 3단계 앞서 나갈 수 있습니다. 뒤에서 유휴 상태(Idling)로 대기할 이유가 없습니다.

기본값은 "독립적으로 흘려보내기"입니다. barrier를 사용하는 것은, 그 단계가 완전한 세트 없이는 정말로 진행할 수 없을 때뿐이어야 합니다. 전체를 가로지르는 중복 제거, 총 개수에 따른 조기 종료, 다른 모든 발견과의 비교 등이 해당됩니다.

그리고 원문의 지적이 뼈아픕니다.

"이 방식이 코드가 더 깔끔하다"는 이유는 포함되지 않습니다.

불필요한 대기 시간은 실측 가능한 시간입니다. 그 방식을 채택하려면 타당한 이유가 필요합니다.

(4) 어떻게 구동하는가

Claude Code에서의 실제 구동 방법입니다.

전제 조건도 확인해 둡니다. 공식 문서에 따르면, dynamic workflows는 Claude Code v2.1.154 이후, 모든 유료 플랜, Anthropic API, Amazon Bedrock, Google Cloud의 Agent Platform, Microsoft Foundry에서 사용할 수 있습니다. Pro 플랜에서는 /config의 Dynamic workflows 항목에서 직접 활성화해야 합니다.

애초에 워크플로우는 무엇이 다른가

공식 문서의 정리가 정확하므로, 그대로 파악해 둡니다. subagents / skills / agent teams / workflows의 차이는, 누가 계획(plan)을 가지고 있는가입니다.

즉 워크플로우는 계획을 코드로 옮기는 것입니다. 루프(loop)도 분기(branching)도 중간 결과도 스크립트가 유지하므로, Claude의 컨텍스트에는 최종적인 답만 남습니다.

제5부 — 그래프가 조용히 망가지는 지점

원문에서 언급하는 함정들입니다. 모두 "작동은 하고 있지만 돈을 계속 쓰고 있는" 타입의 고장 방식입니다.

6번 항목에 대해서는, Anthropic 자체의 가이드가 솔직합니다.

대부분의 태스크에 5명의 리뷰어 패널은 필요하지 않습니다.

그래프는 다른 모든 아키텍처 설계 결정과 마찬가지로, 그 구성 비용을 벌어다 주어야 합니다. 빠른 한 번의 프롬프트는, 빠른 한 번의 작업에 대해서는 여전히 올바른 도구입니다. 공식 문서도 워크플로우는 "토큰을 현저히 많이 사용할 수 있으며", "복잡하고 가치 높은 태스크에 가장 적합하다"고 명시하고 있습니다.

제6부 — 그래프를 "그리는 것"에서 "기르는 것"으로

손으로 그린 그래프는 일직선인 체인(chain)보다 큰 진전이지만, 그것이 한계는 아닙니다.

원문이 가리키는 다음 프론티어는, 그래프를 손으로 그리지 않는 것입니다. 목적을 기술하고, 시스템 스스로가 태스크를 분해하게 하며, fan-out의 폭을 선택하게 하고, 그 실행에 맞춘 구성 스크립트를 작성하게 하는 것. 모든 케이스에 맞기를 바라는 고정된 형태가 아니라 말입니다.

이는 그래프를 개인의 습관에서 공유 자산으로 바꾸는 것이기도 합니다. 성공적인 실행 스크립트는 저장하여 리포지토리에 넣고, 팀원이 이름으로 호출할 수 있게 만듭니다. 처음 만든 사람만의 것이 아니게 됩니다.

실제로 시도해 볼 가치가 있는 6가지 형태

원문에서 제시하는 구체적인 예시입니다. 괄호 안은 대응하는 공식 패턴입니다.

검증할 수 없었던 점

솔직하게 말씀드립니다.

원문에서는 실례로 "Bun의 런타임을 Zig에서 Rust로 다시 작성한 작업이 바로 이 형태였다"라고 언급하고 있으나, 이 건은 1차 정보로 확인할 수 없었습니다. 기사 주장의 골격에는 영향을 미치지 않지만, 사실로서 인용하는 것은 피해야 합니다.

3가지 실패 모드, 6가지 패턴 이름, worktree 격리, 모델 상속(model inheritance) 동작, 토큰 제한(token limit), /config에서의 활성화 — 이들은 모두 Anthropic 공식 기사 및 공식 문서에서 확인되었습니다.

요약

원문 마지막 문장이 이러한 전환을 잘 나타내고 있습니다.

"A prompter asks a question. An architect draws a graph."
(프롬프터는 질문을 던진다. 아키텍트는 그래프를 그린다.)

— MIKE (@mikenevermiss)

공정을 늘리는 것이 아닙니다. 다가오는 작업마다 "이것은 어디서 갈라져야 하고, 어디서 합류해야 하는가"를 묻는 것입니다.

참고

• MIKE @mikenevermiss — "Graph Engineering: How to Stop Building AI Agents That Wait in Line" (2026년 7월 27일)
• Anthropic — A harness for every task: dynamic workflows in Claude Code (2026년 6월 2일, Thariq Shihipar・Sid Bidasaria)
• 공식 문서: Orchestrate subagents at scale with dynamic workflows
• Anthropic — Building multi-agent systems: when and how to use them (그래프가 과잉이 되는 시점은 언제인가, 라는 대조적인 질문)
• Anthropic — Building verification loops in Claude Code with skills

Discussion