에이전트를 병렬로 구동하기──의존 그래프로 설계하는 실행 모델

「막연한 직렬화」가 되고 있지는 않은가

Claude Code로 하네스 (Harness)를 구축하기 시작하면, 에이전트나 도구 호출 (Tool calling)이 막연하게 직렬 (Serial)로 흐르기 쉽다.

Fetch 소스A → Fetch 소스B → Fetch 소스C → 통합 → 출력

이것은 쓰기 편하다. 절차를 위에서부터 적으면 되기 때문이다. 하지만 "B는 A의 결과가 필요한가?"라고 물었을 때, 답이 "아니오, 서로 다른 URL에 대한 fetch이므로 관계없음"인 경우가 많다.

의존 관계 (Dependency)가 없는데도 직렬로 처리하는 것은 타성에 의한 것이다.

반대로 "무엇이든 병렬로 하면 된다"라는 발상도 위험하다. Planner → 구현 → Evaluator의 하네스를 병렬로 구성하면, Planner의 계획 없이 구현이 실행되고, 아직 구현도 끝나지 않은 코드를 Evaluator가 검증하려고 시도하게 된다.

무엇을 병렬화할 수 있고, 무엇이 반드시 직렬이어야 하는가. 그 판단 기준이 바로 "의존 그래프 (Dependency Graph)"다.

TL;DR

• "B는 A의 출력을 필요로 하는가?"가 Yes → 직렬 필수, No → 병렬화 가능
• 병렬화 패턴은 두 가지: 동일 턴 내의 도구 병렬 발화(Parallel tool invocation)와 백그라운드 에이전트 병렬 기동
• Planner→구현→Evaluator가 직렬 필수인 이유는 앞 단계의 출력이 다음 단계의 입력 (Input)이기 때문
• 멀티 소스 리서치 (Multi-source research)가 병렬화 가능한 이유는 각 소스가 서로 독립적이기 때문

의존 그래프로 생각하기

병렬화 판단은 단 한 질문으로 끝난다.

"이 태스크의 출력은 다른 태스크의 시작에 필요한가?"

이 질문이 Yes라면, 그 두 태스크 사이에는 "의존 엣지 (Dependency edge)"가 존재한다. 의존 엣지가 있는 한 직렬로 처리할 수밖에 없다.

왼쪽: Planner가 작성한 구현 계획이 없다면 구현 에이전트는 무엇을 만들어야 할지 알 수 없다. 구현이 완료되지 않았다면 Evaluator는 검증 대상을 가질 수 없다. 각 단계가 다음 단계의 입력을 만든다. 직렬 필수.

오른쪽: 여러 웹사이트를 가져와서 리포트를 만드는 경우, 사이트 A의 fetch는 사이트 B의 결과를 필요로 하지 않는다. 어떤 순서로 가져오든 통합 단계로 넘기는 내용은 변하지 않는다. 병렬화 가능.

의존 그래프를 머릿속에 그린 뒤 구현한다. 그것만으로도 "타성에 의한 직렬화"를 의식적으로 전환할 수 있다.

패턴 1: 동일 턴 내의 도구 병렬 발화

가장 간편한 병렬화는 하나의 응답(Response)에서 여러 도구 호출을 동시에 발화시키는 것이다.

Claude Code는 한 턴에서 여러 function_calls를 병행하여 실행할 수 있다. 보통 도구 호출을 하나씩 작성하면 순차적 (Sequential)으로 실행된다. 여러 도구 호출을 동일 블록에 나열하면 병렬 실행이 된다.

나쁜 예와 좋은 예

# ❌ 직렬 실행 (의존이 없는데도 순차적으로 fetch)
WebFetch("https://example.com/source-a")
# → 완료를 기다린 후 다음으로
...

적용 예: 주간 리포트의 멀티 소스 리서치

주간 기술 리포트를 작성할 때, 여러 뉴스 소스를 참조하고 싶은 경우가 있다.

# SKILL.md (주간 리포트 생성 스킬)의 실행 단계
## 단계 1: 멀티 소스 취득 (병렬)
다음 세 가지를 동일 턴에서 발화할 것:
...

SKILL.md에 "병렬로 발화할 것"이라고 명시하는 것이 중요하다. 적어두지 않으면 Claude는 타성에 의해 직렬로 실행할 가능성이 있다.

패턴 2: 백그라운드 에이전트 병렬 기동

더 무거운 처리 (여러 개의 독립된 에이전트 실행)에는 run_in_background=True를 사용한다.

기본적인 사용법

# ❌ 직렬 에이전트 호출 (의존이 없어도 순서를 기다림)
Agent(subagent_type="researcher", prompt="소스 A를 분석해 주세요")
# → 완료까지 대기
...

SKILL.md에서의 기술 패턴

SKILL.md에서 병렬 기동을 지시할 경우, 의사 코드 (Pseudo-code) 형식으로 의도를 명시한다.

# SKILL.md (병렬 리뷰 스킬)
## 실행 흐름
### 페이즈 1: 병렬 리뷰 기동 (병렬 · 백그라운드)
...

"페이즈 1은 병렬, 페이즈 2는 페이즈 1에 대한 의존 엣지가 있음"이라는 구조를 명시함으로써, Claude가 올바른 실행 순서를 유지할 수 있다.

왜 3-에이전트 하네스는 직렬 필수인가

여기서 다시 한번 확인하자. Planner → 구현(Implementation) → Evaluator의 3-에이전트 하네스(Harness)는 왜 병렬화할 수 없는가.

의존 그래프(Dependency Graph)를 그려보면 명확하다.

이것은 의존성이 없는데도 직렬로 되어 있는 '타성에 의한 직렬'이 아니다. 구조적으로 직렬이어야만 하는 하네스다.

반대로 말하면, "Planner가 설계하고, 구현 A와 구현 B가 서로 독립된 모듈을 만들며, 마지막에 Evaluator가 둘 다를 검증한다"는 형태라면, 구현 A와 B 사이에는 의존성이 없으므로 병렬화할 수 있다.

Planner와 구현 사이, 구현과 Evaluator 사이에는 의존 엣지(Dependency Edge)가 있다. 하지만 구현 A와 구현 B 사이에는 없다. 이 그림을 머릿속에 그려두면 어디를 병렬화할 수 있는지 한눈에 알 수 있다.

병렬화해서는 안 되는 패턴

의존 그래프의 사고방식은 "어디를 병렬화할 수 있는가"뿐만 아니라 "무엇이 직렬 필수인가"를 명시한다.

간과하기 쉬운 직렬 의존의 예를 들어보겠다.

의존 엣지가 있는데도 병렬화를 시도하려는 패턴

# ❌ 잘못된 병렬화 지시
## 페이즈 1 (병렬)
- Agent A: 데이터베이스 스키마 설계
...

# ✅ 올바른 직렬화
## 페이즈 1 (직렬)
- Agent A: 데이터베이스 스키마 설계
...

"B는 A의 출력을 전제로 하고 있는가?"라는 질문을 잊지 않는다면 이 실수는 방지할 수 있다.

요약: 의존 그래프로 '타성에 의한 직렬'을 전환하기

• **"이 태스크의 출력이 다른 태스크의 시작에 필요한가?"**가 Yes라면 → 직렬 필수, No라면 → 병렬화 가능
• 동일 턴 병렬 발화: 의존성이 없는 여러 도구 호출(Tool Call)을 동일 블록에 나열
• 백그라운드 에이전트 병렬 기동: run_in_background=True로 독립된 에이전트를 동시에 기동하고, 완료 후에 통합
• SKILL.md에 명시하기: "병렬로 발화할 것", "페이즈 1 완료 후에 실행할 것"을 적지 않으면, Claude는 타성에 의해 직렬로 실행함
• 직렬 필수 판별법: 전 단계의 출력이 다음 단계의 입력(Input)이라면 의존 엣지가 있으며 직렬 필수임

의존 그래프는 도구가 아니라 사고방식이다. 새로운 하네스를 설계할 때, "이 태스크 군에서 의존 엣지는 어디에 있는가?"라고 묻는 것을 습관화하라. 그것만으로도 병렬화할 수 있는 부분을 자연스럽게 깨달을 수 있게 된다.

하네스 설계의 전체 모습은 Claude Code 하네스 엔지니어링 실전 Playbook에서 해설하고 있다.

Discussion