Harness Engineering — 17장: 열 필의 말을 함께 달리게 하는 법

한 필의 말에서 말떼로 — 문제는 지능보다 Context의 물리적 한계다

앞선 Harness는 대부분 한 Agent를 다뤘다. 그러나 실제 프로젝트에서 프런트엔드·백엔드·데이터베이스·테스트·문서를 한 Agent가 동시에 붙잡으면 Context가 포화되고 성능이 급격히 떨어진다. 원문은 약 100만 token 부근을 뚜렷한 천장으로 다시 상기시킨다.

≈1M

Context Ceiling

단일 Agent가 모든 영역을 함께 기억하고 판단하게 할수록 물리적 Context 한계가 곧 작업 품질의 한계가 된다.

여러 Agent의 진짜 장점

여러 Agent를 쓰는 이유는 같은 두뇌를 복제하기 위해서가 아니다. 각 Agent가 자신만의 독립된 Context window를 갖고 맡은 범위를 깊게 처리하게 만들기 위해서다. 문제는 곧바로 한 단계 올라간다. “누가 이 Context들을 조정할 것인가?”

Frontend Backend Database Test Docs

다중 Agent의 본질은 계산량보다 분업에 있다. 하나의 Context에 모든 세계를 집어넣는 대신, 여러 작은 세계를 만들고 그 사이의 관계를 설계한다.

Boris Cherny — 가장 단순한 오케스트레이터는 사람이다

Claude Code 창시자인 Boris Cherny는 일상적으로 10–15개의 Claude Code 세션을 병렬로 유지한다고 원문은 설명한다. 고급 분산 시스템이 아니라 사람이 직접 Context 사이를 오가며 조율하는 가장 원초적인 다중 Agent 패턴이다.

10–15 concurrent sessions

원문: 팀 내부에서 “the single biggest productivity unlock”이라고 평가

Terminal · 5개

1–5 번호를 붙이고 za, zb, zc 같은 shell alias로 빠르게 전환한다.

Browser · 5–10개

브라우저 세션을 추가로 유지하며 여러 작업을 동시에 진행한다.

Mobile Sessions

아침에 시작해 두었다가 나중에 확인하는 모바일 세션도 함께 사용한다.

Git Worktree

각 세션은 독립 worktree에서 실행되어 코드 충돌을 피한다.

Analysis Worktree

일부 엔지니어는 로그·쿼리 분석만 하고 코드는 쓰지 않는 전용 worktree를 따로 둔다.

worktree 분리

한 작업에 하나의 독립 작업 디렉터리를 배정해 변경 충돌을 차단한다.

세션 시작

각 worktree에서 Claude Code를 실행하고 번호를 붙여 전환 비용을 낮춘다.

독립 작업 배정

각 세션은 서로 간섭하지 않는 모듈이나 기능 하나를 맡는다.

사람이 통합

사람이 결과를 검토하고 충돌을 해결하고 최종 코드를 합친다.

장점 · 완전한 통제

사람이 모든 분기와 통합 지점을 직접 보고 조절한다.

단점 · 의존성이 사람 머릿속에만 존재

항상 세션을 지켜봐야 하며, 작업 간 관계가 시스템에 명시적으로 기록되지 않는다.

이 방식은 세련되지 않았지만 강하다. 오케스트레이션의 첫 단계는 자동화가 아니라 독립된 작업 공간과 사람이 감당할 수 있는 조정 범위를 만드는 일이다.

Anthropic의 3-Agent — 계획하고, 만들고, 의심한다

사람이 계속 조율하지 않으려면 역할 자체를 구조화해야 한다. 원문은 생성적 적대 신경망에서 영감을 받은 Planner / Generator / Evaluator의 세 Agent 구조를 소개한다.

Planner 1–4문장 Prompt를 완전한 제품 사양으로 확장.
제품 맥락과 상위 기술 설계에 집중.

→

Generator Sprint 단위로 기능을 하나씩 구현.
구현을 점진적으로 누적.

→

Evaluator Playwright MCP로 실제 앱·API·DB 상태를 검증.
설계 품질·독창성·완성도를 평가.

각 Sprint 시작 전 Generator와 Evaluator는 Sprint Contract를 합의한다. 사용자 스토리의 모호한 “완료”를 테스트 가능한 구현 기준으로 바꾸는 계약이다. Planner는 지나치게 상세한 기술 지시를 피한다. 세부 지시가 많을수록 하류 Agent에서 오류가 연쇄될 수 있기 때문이다.

원문의 핵심 통찰은 평가자에 있다. 생성자에게 자기비판을 잘 시키는 것보다, 엄격하고 독립적인 평가자를 따로 공학화하는 편이 쉽다. 역할 분리는 비판을 성격이 아니라 구조로 만든다.

구성	시간	비용	결과
단일 Agent · Solo	20분	$9	핵심 기능이 사용할 수 없는 수준
3-Agent · Full Harness	6시간	$200	완전히 사용할 수 있는 애플리케이션

비용은 20배 이상 높았지만 원문은 이를 “더 비싸게 더 잘 만든다”는 문제가 아니라 “비용을 쓰지 않으면 애초에 완성할 수 없었다”는 차이로 해석한다. 또한 Sonnet 4.5에서 Opus 4.6으로 모델이 발전하면서 Sprint 메커니즘은 제거되고, Evaluator도 매 Sprint가 아니라 전체 종료 후 한 번 평가하는 구조로 단순화되었다. 모델의 발전이 오케스트레이션 복잡성을 다시 줄인 사례다.

역할을 나누는 이유는 사람이 많아서가 아니라 편향을 분리하기 위해서다. 계획·생성·평가를 한 Context에 묶지 않을 때 평가자는 생성자의 자기합리화로부터 자유로워진다.

세 개의 창이면 충분한 ‘가난한 사람의 3-Agent’

복잡한 플랫폼을 구축하지 않아도 Planner / Generator / Evaluator의 구조적 이점은 일상 작업에서 재현할 수 있다. 원문은 세 개의 독립 대화만으로 핵심을 구현하는 방법을 제시한다.

Planner · Plan Mode

복잡한 작업은 먼저 Plan Mode에서 상세 구현 계획을 만든다. 원문은 한 Claude가 계획을 작성하고 두 번째 Claude가 staff engineer 역할로 그 계획을 리뷰하는 방법을 추천한다.

Shift+Tab 두 번 · 원문 설명

Generator · Normal Mode

계획을 승인한 뒤 Normal / auto-accept mode로 돌아와 구현한다. 일이 틀어지면 억지로 밀어붙이지 않고 다시 Plan Mode로 돌아가 재계획한다.

잘못된 방향을 실행력으로 덮지 않음

Evaluator · Fresh Context

작업이 끝나면 완전히 새로운 대화를 열고 결과를 붙여 넣은 뒤 “모든 문제를 찾아라”라고 요청한다. 새 Context는 첫 Agent가 만든 코드에 대한 자기편향을 공유하지 않는다.

독립 평가를 가장 싸게 만드는 방법

복잡한 아키텍처보다 먼저 가져올 수 있는 것은 역할 분리다. 세 개의 창만 있어도 계획과 실행과 검증을 서로 다른 시선으로 나눌 수 있다.

Agent Teams와 병렬 Agent — 함께 달리는 것과 따로 달리는 것은 다르다

원문은 Claude Code Agent Teams를 Agent끼리 직접 통신하는 내장형 다중 Agent 구조로 소개한다. 반면 Cursor와 Codex CLI의 병렬 방식은 통신 구조와 Context 독립성에서 다른 특성을 가진다.

Claude Code · Agent Teams

한 Session이 Team Lead가 되어 작업을 나누고 결과를 종합한다. Teammate끼리 Lead를 거치지 않고 직접 통신할 수 있으며, 각 Agent는 독립 Context window를 가진다.

장점: Boris 방식보다 조율 자동화

적합: 병렬 조사 · 독립 모듈 개발

적합: 경쟁 가설 기반 디버깅

Cursor 2.0 · 최대 8개 병렬 Agent

원문 기준 동시 실행 수는 많지만 각 Agent는 독립적으로 일하고 Agent 간 직접 통신 메커니즘은 없다.

병렬성은 높음

조율 채널은 없음

“여덟 필의 말이 각자 달림”

Codex CLI · Subagents

부모 Agent의 Sandbox 정책과 승인 설정을 상속하고, 주 Agent의 Context 안에서 실행되며 결과를 위로만 보고한다.

적합: 탐색적 하위 작업

부적합: 장시간 독립 작업

독립 Context보다 상위 Context 종속성이 큼

병렬성은 숫자가 아니다. Agent가 서로 말할 수 있는가, 각자 독립된 Context를 갖는가, 결과가 어디로 합쳐지는가가 실제 오케스트레이션의 형태를 결정한다.

Writer / Reviewer — 가장 실용적인 다중 Agent는 하나가 쓰고 하나가 의심하는 구조다

다중 Agent라고 해서 항상 복잡한 통신이 필요한 것은 아니다. 원문은 가장 실용적인 패턴으로 Writer / Reviewer의 두 세션을 제시한다. 서로 다른 Context를 사용하는 것만으로 자기평가 편향을 줄일 수 있다.

Writer

첫 Agent가 코드를 작성한다. 구현에 몰입하지만 자기 결과에 대한 편향도 함께 갖는다.

→

Reviewer

완전히 새로운 Context의 두 번째 Agent가 결과를 검토해 문제를 찾는다.

for file in $(cat files.txt); do
  claude -p "Migrate $file from React to Vue. Return OK or FAIL." \
    -allowedTools "Edit,Bash(git commit *)"
done

이 구조는 대규모 배치에도 확장할 수 있다. 파일별 작업을 독립 프로세스로 나누면 하나의 실패가 다른 작업을 오염시키지 않고, 병렬성은 실행 가능한 프로세스 수만큼 늘어난다.

Stripe Minions — 기업 규모의 오케스트레이션은 파이프라인이 된다

원문은 기업형 오케스트레이션의 대표 사례로 Stripe Minions를 다시 호출한다. 하나의 Slack 메시지가 Minion 실행을 시작하고, 코딩·테스트·PR 생성까지 연결된 표준 파이프라인이 사람의 개입을 최소화한다.

Slack요청 메시지

→

Trigger Minion작업 시작

→

Auto Coding자동 구현

→

Auto Test자동 검증

→

PR Review인간 검토 대기

1,300+ PR / week

원문: 매주 자동 생성·병합되는 규모.

0 수기 코드

AI 생성 PR의 코드 작성은 전부 Agent가 담당.

<10s devbox start

warm pool에서 표준 개발 환경 기동.

Human final review

모든 AI PR은 여전히 사람의 검토를 거침.

오케스트레이션 아래에는 오래된 인프라가 있다

각 Minion은 표준화된 AWS EC2 devbox에서 실행되고 Stripe 전체 코드 트리와 예열된 Bazel·타입 검사 캐시를 가진다. 원문은 Minions가 작동하는 첫 번째 이유가 모델이 아니라 LLM 이전부터 인간 엔지니어를 위해 축적한 개발 인프라라고 강조한다.

전체 코드 트리

예열된 Bazel cache

광범위한 테스트 + synthetic E2E

Blue / Green + 빠른 rollback

기업 규모의 오케스트레이션은 Agent 숫자보다 기반 시설의 규격화에 달려 있다. 표준 환경과 자동 검증이 없으면 많은 Agent는 생산성이 아니라 많은 불확실성을 동시에 만든다.

언제 다중 Agent를 써야 하는가 — 복잡도는 문제보다 먼저 커지면 안 된다

원문은 다중 Agent의 유혹을 경계한다. 한 번의 LLM 호출로 풀 수 있는 일은 Agent를 쓰지 않고, 한 Agent로 풀 수 있는 일은 여러 Agent로 나누지 않는다. 오케스트레이션은 필요할 때만 한 단계씩 올린다.

상황	추천 패턴	이유
버그 하나 수정 · 기능 하나 추가	Single Agent	Context가 충분하고 병렬 처리 필요가 없음
모듈 하나 리팩터링	Single Agent + Plan Mode	전체 시야가 필요해 분할하면 Context를 잃을 수 있음
독립 모듈 5개 동시 수정	수동 다중 세션 · Boris 방식	작업이 독립적이고 Agent 간 통신이 필요 없음
코드 작성 + 코드 리뷰	Writer / Reviewer	자기평가 편향 제거
복잡한 Full-stack 앱을 처음부터 구축	Planner / Generator / Evaluator	프런트·백엔드를 가로지르며 계획과 독립 검증이 필요
대규모 Migration / Batch 처리	Pipeline Script	작업이 반복적이고 독립적으로 병렬화 가능
주 1,000+ PR 기업 규모	Stripe Minions형 플랫폼	전용 인프라와 표준화된 자동 검증이 필요

원문의 결론은 “가장 강력한 구조”를 고르라는 말이 아니다. 오케스트레이션의 복잡도는 작업의 복잡도와 맞아야 한다.
세 개의 대화창으로 끝낼 수 있는 일에 Agent Teams를 세우지 않는다. 가장 단순한 방식으로 시작하고, 정말 필요해질 때만 다음 층으로 올라간다.

다중 Agent의 성숙함은 많은 Agent를 쓰는 데서 드러나지 않는다. 언제 한 Agent로 돌아가야 하는지 아는 데서 드러난다. 분업은 필요를 따라야 하고 구조는 문제보다 앞서 커지지 않아야 한다.

여러 말이 함께 달리면
먼저 빨라지는 것은 발굽 소리다.
방향은 그 다음 문제다.

누구는 앞길을 보고,
누구는 길을 만들고,
누구는 잘못된 길을 의심해야 한다.
그리고 어느 지점에서는 사람이 다시 전체를 보아야 한다.

오케스트레이션은 많은 힘을 모으는 기술이 아니다.
서로 다른 힘이 서로를 망치지 않도록 관계를 설계하는 기술이다.

한 필이면 되는 길에 열 필을 풀어놓지 않는다.
열 필이 필요한 길에서만
그 열 개의 Context 사이에 고삐를 건다.

이 웹페이지는 첨부 문서 《Harness Engineering》의 §17 「编排层：让十匹马同时跑 / Orchestration: Running Ten Horses at Once」 (PDF 89–94쪽)에만 근거해 재구성했다. 95쪽에서 §18이 시작되는 것을 확인해 17장의 범위를 분리했다. 단일 Agent의 Context 한계, Boris Cherny의 10–15개 병렬 세션과 Git worktree 방식, Anthropic의 Planner / Generator / Evaluator 및 Sprint Contract, Solo 대 Full Harness 비용 비교와 모델 발전에 따른 Sprint 제거, 세 개 대화창으로 구현하는 간이 3-Agent 패턴, Claude Code Agent Teams·Cursor 병렬 Agent·Codex Subagents, Writer / Reviewer와 배치 스크립트, Stripe Minions 파이프라인과 기반 인프라, 마지막 다중 Agent 선택 기준표까지 원문 내용만으로 구성했다. 제품 기능·버전·수치·도구 상태는 외부에서 갱신하지 않고 첨부 문서의 시점과 표현을 보존했다.