지난 시간엔 일꾼 하나를 잘 설계했습니다. 그런데 일이 크고 복잡해지면 — 한 명으로는 안 됩니다. 오늘은 잘 만든 일꾼 여럿을 하나의 팀으로 조율합니다. Last time we designed one worker well. But when the job gets big and complex — one isn't enough. Today we coordinate many good workers into a single team.
As of 2026-06 · 오케스트레이션·하네스의 옵션 이름·도구는 버전마다 바뀝니다 — ‘혼자 말고 팀으로’라는 원리가 진실. [추론]As of 2026-06 · orchestration & harness option names and tools change by version — the principle ‘don't work solo, build a team’ is the truth. [inference]
더 똑똑한 한 명이 아니라 — 역할을 나눈 ‘팀’이 답이다.Not a smarter single worker — a ‘team’ with split roles is the answer.
[추론] 한 세션에 모든 일을 몰면 (a) 컨텍스트가 차며 흐려지고 (b) 만든 자가 자기 결과를 검증하는 자기채점이 되고 (c) 독립 작업도 직렬로 처리돼 느리다. 더 큰 모델이 아니라 ‘나뉜 팀’이 푸는 문제. → 오늘의 질문: 언제·어떻게 팀으로 나누나.[inference] Pile every task into one session and (a) context fills and fogs over (b) the maker self-grades its own result (c) independent tasks run serially and slow. Not a bigger model but a ‘split team’ solves this. → Today's question: when and how do you split into a team?
오케스트레이터는 직접 다 하지 않는다 — 나눠 맡기고, 합친다.The orchestrator doesn't do it all — it delegates and combines.
[출처: code.claude.com/docs/en/sub-agents] 서브에이전트는 자신만의 컨텍스트에서 위임받은 작업을 수행하고 결과를 반환하는 별도 에이전트다 — 오케스트레이터(메인)는 일을 쪼개 배분하고 결과를 취합한다. 옵션·호출 방식은 2026-06 기준, 공식 문서로 현행 확인(대표 예).[source: code.claude.com/docs/en/sub-agents] A sub-agent is a separate agent that works in its own context and returns the result of a delegated task — the orchestrator (main) splits, assigns, and gathers results. Options & call syntax are as of 2026-06; confirm live via the official docs (representative example).
[출처: code.claude.com/docs/en/sub-agents] 서브에이전트는 별도 컨텍스트 윈도우에서 작업하므로, 그 중간 과정은 메인 컨텍스트를 차지하지 않고 결과만 반환된다 — 이것이 ‘컨텍스트 격리’의 핵심. → 길고 지저분한 작업일수록 격리해서 결과만 받는다.[source: code.claude.com/docs/en/sub-agents] A sub-agent works in a separate context window, so its intermediate process doesn't occupy the main context — only the result returns. That's the core of ‘context isolation’. → The longer & messier the task, the more it pays to isolate and take only the result.
책상이 차면 주의가 분산되고, 오래된 내용이 현재 작업을 방해한다 (컨텍스트 로트).A full desk scatters attention, and old material interferes with the current task (context rot).
각자 작은 책상에서 또렷하게, 오케스트레이터는 결과만 모은다 (로트 지연).Each works sharply on a small desk; the orchestrator just gathers results (rot delayed).
토큰을 아끼는 게 아니라 — 컨텍스트를 보호하는 것.Not saving tokens — protecting context.
[출처: trychroma.com/research/context-rot] [출처: anthropic.com/engineering/effective-context-engineering-for-ai-agents] 컨텍스트를 많이 쓸수록 어텐션이 분산되고 오래된 무관한 내용이 현재 작업을 방해해 성능이 약간 저하된다(컨텍스트 로트). 격리하면 각 컨텍스트가 작게 유지돼 이를 늦춘다. (‘격리가 늦춘다’ 연결은 추론.)[source: trychroma.com/research/context-rot] [source: anthropic.com/engineering/effective-context-engineering-for-ai-agents] The more context you use, the more attention scatters and old irrelevant material interferes, degrading performance a little (context rot). Isolation keeps each context small and delays this. (The ‘isolation delays it’ link is inference.)
[추론] 서로 의존하지 않는 작업을 여러 서브에이전트에 동시에 맡기면(병렬 fan-out) 전체 시간이 ‘합산’이 아니라 ‘가장 오래 걸리는 것’에 가까워진다 — 단, 서로의 결과에 의존하면 직렬이 맞다. 실제 단축 폭은 작업·환경마다 다름(구체 배수 단정 금지).[inference] Hand independent tasks to several sub-agents at once (parallel fan-out) and total time approaches ‘the longest one’, not ‘the sum’ — but if they depend on each other, serial is correct. Actual speedup varies by task & environment (no specific multiple claimed).
오케스트레이터는 ‘무엇을’만 알고 — ‘어떻게’의 잡음은 서브 안에 머문다.The orchestrator knows only the ‘what’; the ‘how’ noise stays inside the sub-agent.
[추론] 컨텍스트 격리의 메커니즘: 각 서브에이전트는 자신의 컨텍스트 윈도우에서 도구 출력·시행착오 같은 ‘과정’을 처리하고, 오케스트레이터에게는 압축된 ‘결과’만 올린다 — 과정의 토큰이 메인에 누적되지 않으므로 메인은 또렷하게 유지된다. → 잡음은 가두고, 결과만 흐르게.[inference] The isolation mechanism: each sub-agent handles the ‘process’ — tool output, trial and error — in its own context window, and sends the orchestrator only the compressed ‘result’. Process tokens never stack up in the main, so the main stays sharp. → Cage the noise, let only the result flow.
같은 에이전트가 자기 걸 검증하면 자기채점 — 별도 검증자가 봐야 약점이 보인다.If the same agent checks its own work, that's self-grading — a separate verifier sees the weak spots.
[추론] 생산자-검증자(producer–verifier) 패턴: 결과를 만든 에이전트가 자기 결과를 채점하면 자기채점 편향이 생기므로, 별도 검증 에이전트가 비판적으로 점검하게 한다 — s11 ‘do–verify(결과를 다시 읽기)’를 ‘만든 자/보는 자 분리’로 확장한 것. 검증 체계·품질 게이트의 세부 설계는 다음 강(s15) 소관.[inference] The producer–verifier pattern: if the agent that made the result grades it, self-grading bias appears, so a separate verification agent checks it critically — extending s11's ‘do–verify (re-read the result)’ into ‘separate maker from checker’. The verification system & quality-gate details belong to the next lesson (s15).
매번 말로 조율하지 말고 — 대본에 적어 반복 가능하게.Don't re-coordinate by talking each time — write it into a script so it repeats.
[출처: code.claude.com/docs/en/headless] 하네스(workflow 스크립트)는 에이전트 호출 순서·전달·분기를 정해 둔 대본으로, Claude Code를 프로그램적으로(headless) 호출해 팀을 반복 가능하게 굴린다. 호출 방식·플래그는 2026-06 기준, 공식 문서로 현행 확인(대표 예).[source: code.claude.com/docs/en/headless] A harness (workflow script) fixes the agent call order, hand-offs, and branching, calling Claude Code programmatically (headless) to run the team repeatably. Call syntax & flags are as of 2026-06; confirm live via the official docs (representative example).
| 원칙Principle | 무엇을 정하나What it pins down |
|---|---|
| 역할 분리Role split | 누가 무엇을 맡나who takes what |
| 인터페이스Interface | 입력·반환의 결과 계약the input·return result contract |
| 검증 게이트Verification gate | 검증자를 끼울 지점where the verifier slots in |
| 중단·실패 처리Stop·failure handling | 멈추고 사람에게 넘길 곳where to halt and hand to a human |
[추론] 하네스 설계 4원칙 — (1) 역할 분리(s13 단일 에이전트 설계를 구성원으로), (2) 인터페이스/결과 계약(입력·반환을 명확히 해야 결과를 안전히 합칠 수 있음), (3) 검증 게이트(생산자-검증자를 어디 끼울지), (4) 중단·실패 처리(s13 중단 조건의 팀 버전). → 4가지를 적어 두면 팀이 매번 같게 굴러간다.[inference] The four harness principles — (1) role split (the single agent from s13 becomes a member), (2) interface / result contract (clear input·return so results combine safely), (3) verification gate (where to slot the producer–verifier), (4) stop·failure handling (the team version of s13's stop conditions). → Write the four down and the team runs the same way every time.
[추론] 5항목은 각각 슬라이드 03·06·10·08·10의 내용과 대응 — 나눌지·병렬·결과계약·검증자·중단. 팀은 ‘많이 부르면 좋은 것’이 아니라 ‘나눌 가치가 있을 때 설계하는 것’.[inference] The five map onto slides 03·06·10·08·10 — split-or-not·parallel·result contract·verifier·stops. A team isn't ‘good because you call more’ — it's ‘designed when it's worth splitting’.
[추론] Rule No.2(컨텍스트를 지켜라 — 격리)·No.10(작은 일들로 — 분할)·No.13(환경을 설계하라 — 단일 에이전트)·No.14(팀을 만들어라 — 조율)가 만나는 지점. → 팀을 설계할 줄 알면, 무엇을 나누고 무엇을 합칠지 자동으로 보인다.[inference] Where Rule No.2 (protect context — isolation) · No.10 (small tasks — splitting) · No.13 (design the environment — single agent) · No.14 (build a team — coordination) all meet. → Once you can design a team, what to split and what to combine becomes obvious.
[추론] 결과는 ‘더 똑똑한 한 명’이 아니라 ‘잘 나뉜 팀’에서 온다 — 혼자는 흐려지고·자기채점하고·느리지만, 팀은 격리로 또렷하고·검증이 분리되고·병렬로 빠르다. 단, 작은 일까지 팀으로 만들면 조율 비용만 늘어난다. → 나눌 가치가 있을 때 팀.[inference] The result comes not from ‘a smarter single worker’ but from ‘a well-split team’ — solo fogs·self-grades·slows, while a team is sharp via isolation·separated verification·parallel speed. But forcing even small jobs into a team only adds coordination cost. → A team when it's worth splitting.
한 단어로: 나눔 → 격리 → 검증 → 대본.In a word: split → isolate → verify → script.
이 강도 오케스트레이터 + 7개 팀으로 만들어졌다. 다음 강 예고 — 팀을 굴렸으니, 이제 품질과 신뢰를 설계할 차례 (Rule No.15).This lesson was built by an orchestrator + 7 teams. Next up — you ran the team, now design quality and trust (Rule No.15).
[추론] 이 코스는 오케스트레이터 + 7개 서브에이전트(구조 감독·집필·슬라이드·팩트체크·발음검수·음성·다국어)로, 심화 리서치는 멀티에이전트 리서치 하네스(fan-out → 검증 → 종합)로 제작됐다. As of 2026-06.[inference] This course was built by an orchestrator + 7 sub-agents (structure·writing·slides·fact-check·pronunciation·audio·i18n), and the deep research ran on a multi-agent research harness (fan-out → verify → synthesize). As of 2026-06.