에이전트 오케스트레이션 · 보너스Agent Orchestration · Bonus
01 / 13
← → SPACE 이동 · F 전체화면← → SPACE move · F fullscreen · BONUS · CHOOSE THE SHAPE [email protected]
보너스 · 팀의 모양을 고르다Bonus · choosing the team's shape

BONUS RULE

팀을 만들 줄 알면,
이제 그 모양을 골라라.
Once you can build a team,
choose its shape.

14강에서 ‘혼자 말고 팀을’ 배웠죠. 그런데 팀을 만드는 것과 그 모양을 잘 고르는 것은 다른 문제예요 — 오늘은 모양을 읽고 맞는 패턴을 고르고, 그 선택마저 자동화하는 법. Lesson 14 taught you to build a team. But building one and choosing its shape well are different problems — today, read the shape, pick the right pattern, and automate the choice.

20강 본편을 마친 분들을 위한 보너스·심화 특별편 — 14강의 직접 후속입니다. A bonus deep-dive for those who finished the main 20 — a direct sequel to Lesson 14.

As of 2026-06 · 패턴 이름·도구(LangGraph·GPTSwarm·DSPy 등)는 버전마다 바뀝니다 — ‘일의 모양을 읽고 맞는 패턴을 고른다’는 안목이 진실. [추론]As of 2026-06 · pattern names & tools (LangGraph·GPTSwarm·DSPy, etc.) change by version — the eye to ‘read the shape of the work and pick the right pattern’ is the truth. [inference]

모양 · SHAPESHAPE
1막 — 둘 다 ‘팀’을 썼는데Act 1 — Both used a ‘team’, yet…

둘 다 14강대로 ‘팀’으로 나눴는데 — 하나는 엉키고, 하나는 느렸다.Both split into a ‘team’ like Lesson 14 — one tangled, one crawled.

[A] 입점 4단계(조사→초안→검증→품의)를 5명에게 동시에
… 검증: “초안이 아직 안 왔는데요?” — 앞 결과를 못 받아 엉킴

[B] 서로 독립인 카테고리 5개 조사를 굳이 한 줄로 직렬
… 줄줄이 차례를 기다리느라 느리다 — 독립인데 줄 세움
[A] 4 entry steps (research→draft→verify→proposal) to 5 people at once
… verify: “the draft isn't here yet?” — tangles, upstream output missing

[B] 5 independent category researches forced into a single line
… each waits its turn, so it crawls — independent work, queued

둘 다 나누긴 했어요. 문제는 ‘나눴느냐’가 아니라 — ‘어떤 모양으로’ 나눴느냐.Both did split. The question isn't ‘whether you split’ — it's ‘into what shape’.

[추론] A=의존성 있는 일을 병렬로 던져 엉킴(뒷 단계 입력 누락), B=독립인 일을 직렬로 세워 느림. 둘 다 ‘팀’을 썼지만 모양이 틀렸다. (s14 신상품 입점 콜드오픈·s14 병렬/직렬 정합.) → 오늘의 질문: 어떤 모양으로 나누나.[inference] A = dependent work thrown in parallel, so it tangles (missing upstream input); B = independent work queued serially, so it crawls. Both used a ‘team’, but the shape was wrong. (Consistent with lesson 14's new-product-entry cold open & its parallel/serial split.) → Today's question: into what shape do you split?

1막 — 오늘의 질문Act 1 — Today's question

14강은 ‘나눌까’를 가르쳤다. 오늘은 — ‘어떤 모양으로 나눌까’.Lesson 14 taught ‘whether to split.’ Today — ‘into what shape.’

14강Lesson 14
나눌까 말까Whether to split
오늘 (보너스)Today (bonus)
어떤 모양으로Into what shape

같은 팀이라도 모양(배선)을 잘못 고르면 느리거나 틀린다 — 그래서 ‘고르는 안목’이 필요하다.Even the same team, with the wrong shape (the wiring), runs slow or wrong — so you need ‘the eye to choose’.

[추론] 분할 ‘여부’가 아니라 분할 ‘형태(배선)’가 속도·정확도를 가른다 — s14가 깔지 못한 ‘모양 고르기’가 오늘의 주제. (s14 직접 후속.)[inference] Not ‘whether’ to split but the ‘form (the wiring)’ of the split decides speed & accuracy — ‘choosing the shape’, which lesson 14 didn't cover, is today's subject. (A direct sequel to lesson 14.)

2막 — 패턴 6종 카탈로그Act 2 — The six-pattern catalog

팀의 모양은 크게 여섯 가지다.A team's shape comes in six kinds.

패턴Pattern 한 줄 비유One-line analogy 14강?In L14?
① 프롬프트 체이닝① Prompt chaining 컨베이어 벨트 (A 출력 → B 입력)Conveyor belt (A's output → B's input) 신규New
② 라우팅② Routing 안내데스크 (유형별 배정)Front desk (route by type) 신규New
③ 병렬화 (fan-out)③ Parallelization (fan-out) 동시에 — 또는 여러 번 → 투표At once — or repeat → vote 복습Review +투표 신규+voting new
④ 오케스트레이터-워커④ Orchestrator-workers 팀장이 동적으로 쪼갬A lead splits on the fly 복습Review
⑤ 평가자-최적화 루프⑤ Evaluator-optimizer 작가 + 편집자 반복Writer + editor, looping △ 14강 씨앗△ seeded in L14
⑥ 자율 에이전트⑥ Autonomous agent 끝 조건만 주고 스스로Give the end-condition, self-drives 13강 확장extends L13

[출처: anthropic.com/research/building-effective-agents] (2026-06 기준) Anthropic ‘Building Effective Agents’는 워크플로우 5종(프롬프트 체이닝·라우팅·병렬화·오케스트레이터-워커·평가자-최적화) + 별도 범주 ‘에이전트(autonomous)’로 정리 — ‘6패턴’이라는 공식 분류가 아님. 위 6칸 = 그 5종 + 자율 에이전트를 한 표로 묶은 본 강의 정리[추론]. 병렬화 하위형은 원문상 Sectioning(쪼개 동시)·Voting(여러 번→투표) — ‘투표’와 ①②가 14강에 없던 새 모양, 나머지는 14강 복습에 이름표.[source: anthropic.com/research/building-effective-agents] (as of 2026-06) Anthropic's ‘Building Effective Agents’ lists 5 workflows (prompt chaining·routing·parallelization·orchestrator-workers·evaluator-optimizer) + a separate category, ‘agents (autonomous)’ — not an official ‘6-pattern’ taxonomy. The 6 cells above = those 5 plus the autonomous agent, grouped into one table by this lesson [inference]. Parallelization's sub-types in the source are Sectioning (split & run at once) and Voting (repeat → vote) — ‘voting’ and ①② are shapes lesson 14 didn't have; the rest are L14 review with name tags.

2막 — 어떤 일엔 어떤 패턴Act 2 — Which pattern for which job

일의 ‘모양’을 보면, 맞는 패턴이 보인다.Read the job's ‘shape’ and the right pattern appears.

일의 모양The job's shape 맞는 패턴The right pattern
A 끝나야 B 시작 (순서 의존)A must finish before B (ordered) 프롬프트 체이닝Prompt chaining
들어온 게 유형별로 갈림Incoming work splits by type 라우팅Routing
서로 독립인 게 여러 개Several independent pieces 병렬화 (fan-out)Parallelization (fan-out)
정답 불확실 / 틀리면 비쌈Answer uncertain / costly if wrong 평가자 루프 + 교차검증 3~5Evaluator loop + 3–5 cross-checks
범위 크고, 쪼개는 것 자체가 일Large scope; splitting is itself the work 오케스트레이터-워커Orchestrator-workers

[추론] 패턴은 외우는 게 아니라 ‘일의 모양’에서 읽는 것(14강 화법 계승). 이 표가 강의 핵심 자산 — 손에 남는 결론. 교차검증 3~5는 전역 검증 원칙 계승.[inference] Patterns aren't memorized — they're read off the ‘shape of the work’ (carrying lesson 14's framing). This table is the lesson's core asset — the takeaway that stays in hand. The 3–5 cross-check carries the global verification principle.

2막 — 모양을 읽는 네 가지 질문Act 2 — Four questions to read the shape

네 가지만 순서대로 물으면, 모양이 나온다.Ask four questions in order, and the shape emerges.

① 단계 의존성?예 → 체이닝① Step dependency?yes → chaining
② 유형 분기?예 → 라우팅② Type branching?yes → routing
③ 독립이 여럿?예 → 병렬③ Many independent?yes → parallel
④ 채점·고비용?예 → 평가자 루프④ Scorable / costly?yes → evaluator loop

범위가 크면 — 오케스트레이터-워커가 위 과정을 대신 돌린다.If the scope is large — orchestrator-workers runs this whole process for you.

[추론] 플로우차트는 매핑표(S05)의 ‘순서판’ — 위에서부터 차례로 물으면 자동으로 한 패턴에 도착. 표는 찾아보기, 플로우차트는 걸어가기. (전역 자동검증 발동 기준과 동형 — 고위험·불확실은 교차검증.)[inference] The flowchart is the ‘ordered version’ of the mapping table (S05) — ask in order from the top and you arrive at one pattern automatically. The table is for looking up; the flowchart is for walking through. (Isomorphic to the global auto-verification trigger — high-risk / uncertain → cross-check.)

2막 — 흔한 실수, 콜드오픈 해부Act 2 — Common mistakes, dissected

모양을 잘못 고르면 — ‘지정’이 오히려 해롭다.Pick the wrong shape — and structure backfires.

장면 A의 실수Scene A's mistake

의존성을 무시하고 병렬로 던짐 → 뒷 단계가 앞 결과를 못 받아 엉킨다.Ignored the dependency and threw it in parallel → later steps miss upstream output and tangle.

장면 B의 실수Scene B's mistake

독립인데 직렬로 줄 세움 → 시간 낭비, 느리다.Independent work queued serially → wasted time, slow.

세 번째 함정 — 단순한 일에 오케스트레이터 과잉(조율 비용만↑). 지정 자체가 품질을 올리는 게 아니라, 맞는 패턴이 올린다.A third trap — over-using an orchestrator on simple work (only coordination cost ↑). Structure itself doesn't raise quality — the right pattern does.

[추론] 콜드오픈(S02) A·B를 해부 + 14강 ‘나눌 가치 있을 때만’의 연장(과잉 조율 경계). 틀린 패턴 강요는 무지정보다 해로울 수 있다(s21 Rule No.1 계승 — 구조를 믿지 말고 맞는지 검증).[inference] Dissecting cold-open (S02) A·B + extending lesson 14's ‘only when it's worth splitting’ (guarding against over-coordination). Forcing the wrong pattern can be worse than no structure (carrying s21's Rule No.1 — don't trust the structure, verify it fits).

3막 — 오늘의 심장: 플래너Act 3 — The heart: the planner

패턴을 외우지 말고 — 실행 전에 ‘추천’받아 고른다.Don't memorize patterns — get a recommendation before you run.

> 플랜: 신상품 입점 — 조사 · 초안 · 검증 · 품의
[플래너] 추천 — 조사 5개 → 병렬 / 초안 → 체이닝 / 검증 → 평가자 루프
좋아, 검증만 교차검증으로 (승인 · 일부 수정)
실행 ▸ 이 모양으로 — 마음에 들면 하네스에 박제
> Plan: new-product entry — research · draft · verify · proposal
[Planner] suggests — 5 researches → parallel / draft → chaining / verify → evaluator loop
ok, just cross-check the verify step (approve · minor edit)
Run ▸ in this shape — if you like it, bake into the harness

사람은 매핑표를 외울 필요 없이 검토자가 된다. 마음에 들면 이 단계를 하네스로 박제 → 매번 자동으로 전략표가 뜬다. 별도 프레임워크 0개 — ‘이 플랜에 맞는 실행 패턴을 단계별로 추천해’면 끝.You don't memorize the table — you become the reviewer. Like it? Bake the step into the harness → the strategy table shows up automatically every time. Zero extra frameworks — just ‘recommend the execution pattern for this plan, step by step’.

[추론] 플랜과 실행 사이에 ‘전략 추천’ 한 스텝을 끼운다(사용자 아이디어에서 출발). 13강 ‘환경을 설계하라’·14강 ‘조율은 대본에’ 정합. 추천 결과는 사람이 승인·수정(자동 강행 아님 — Rule No.1).[inference] Insert one ‘strategy recommendation’ step between plan and execution (starting from a user idea). Consistent with lesson 13 ‘design the environment’ & lesson 14 ‘coordinate via a script’. The recommendation is approved/edited by a human (not auto-forced — Rule No.1).

3막 — 프론티어: 배선마저 학습Act 3 — Frontier: the wiring, learned

한 발 더 — 배선 자체를 AI가 데이터로 진화시킨다.One step further — AI evolves the wiring itself from data.

GPTSwarm

에이전트=노드, 연결=엣지인 그래프에서 ‘어떤 연결이 점수를 올리나’를 학습 → 연결을 강화·가지치기.In a graph of agents (nodes) & connections (edges), it learns ‘which connection raises the score’ → reinforces & prunes edges.

ICML 2024 · Oral
DSPy

프롬프트·가중치를 metric(채점 함수)을 향해 자동 튜닝.Auto-tunes prompts & weights toward a metric (a scoring function).

Stanford NLP

결정적 한계 — ‘채점할 수 있는 태스크’에서만 작동합니다(예: 수학·코딩 같은 객관 채점 태스크). 채점이 모호하면(‘가계부 깔끔히’) 헛돌아요 → 연구·벤치마크 단계, 범용 실무 도구는 아직 아닙니다.A decisive limit — it works only on scorable tasks (e.g. objective ones like math/coding). When scoring is fuzzy (‘tidy up my budget’) it spins its wheels → a research/benchmark stage, not yet a general tool.

[출처: arxiv.org/abs/2402.16823] (GPTSwarm: ‘Language Agents as Optimizable Graphs’, ICML 2024 Oral) · [출처: github.com/metauto-ai/GPTSwarm] · [출처: github.com/stanfordnlp/dspy] (Stanford NLP) · [출처: dspy.ai/learn/optimization/optimizers/] (optimizer는 사용자 지정 metric을 maximize — 채점 함수 필수). DSPy는 프롬프트·가중치를, GPTSwarm은 그래프 토폴로지를 metric 향해 최적화 → 둘 다 ‘채점 가능성’ 전제 → 18강 ‘측정하지 않으면 개선할 수 없다’와 직접 연결. ‘범용 실무 도구는 아직 아님(연구·벤치마크 단계)’은 [추론]. 구체 벤치마크 수치 단정 금지.[source: arxiv.org/abs/2402.16823] (GPTSwarm: ‘Language Agents as Optimizable Graphs’, ICML 2024 Oral) · [source: github.com/metauto-ai/GPTSwarm] · [source: github.com/stanfordnlp/dspy] (Stanford NLP) · [source: dspy.ai/learn/optimization/optimizers/] (the optimizer maximizes a user-specified metric — a scoring function is required). DSPy tunes prompts & weights, GPTSwarm tunes graph topology, both toward a metric → both presume ‘scorability’ → directly linked to lesson 18 ‘you can't improve what you don't measure’. ‘Not yet a general practical tool (research/benchmark stage)’ is [inference]. No hard benchmark numbers asserted.

3막 — 지금 너의 위치Act 3 — Where you stand now

수동 배선에서 자동 최적화까지 — 너는 이미 왼쪽에 있다.From manual wiring to auto-optimization — you're already on the left.

수동 배선제어 쉬움 · 실무 표준
LangGraph · Claude Agent SDK
CrewAI · AutoGen
Manual wiringeasy control · the standard
LangGraph · Claude Agent SDK
CrewAI · AutoGen
DSPy프롬프트·가중치 튜닝DSPytunes prompts & weights
GPTSwarm연구 프론티어GPTSwarmresearch frontier

실무는 왼쪽~가운데. 이 코스 독자는 이미 Claude Code 하네스로 왼쪽을 쓰는 중 — 새 프레임워크보다, 가진 걸 잘 쓰는 게 먼저. 자동 최적화는 방향 감각용.Practice lives left-to-center. You're already on the left via the Claude Code harness — use what you have well before chasing a new framework. Auto-optimization is for a sense of direction.

[추론] 스펙트럼 위치·도구 이름은 2026-06 기준 대표 예(공식 문서/리포로 현행 확인). 자동 최적화는 권장이 아니라 방향 감각 — 14강 하네스로 이미 ‘수동 배선’을 실천 중임을 회수.[inference] Spectrum positions & tool names are representative examples as of 2026-06 (confirm live via official docs/repos). Auto-optimization isn't a recommendation but a sense of direction — recalling that lesson 14's harness already has you practicing ‘manual wiring’.

4막 — 모양 고르기 5문항Act 4 — Five questions to choose the shape

팀을 짜기 전, 이 5가지로 모양을 고른다.Before you assemble, choose the shape with these five.

  1. 1
    단계 간 의존성을 그렸나?Did you map the step dependencies? → 있으면 체이닝, 없으면 병렬→ if any, chaining; if none, parallel
  2. 2
    유형 분기가 있나?Is there type branching? → 있으면 라우팅→ if so, routing
  3. 3
    채점되나 / 틀리면 비싼가?Is it scorable / costly if wrong? → 평가자 루프 + 교차검증→ evaluator loop + cross-check
  4. 4
    실행 전 전략을 추천받았나?Did you get a strategy recommendation first? → 오케스트레이션 플래너→ the orchestration planner
  5. 5
    이 선택을 대본(하네스)에 적었나?Did you write the choice into a script (harness)? → 조율은 대화가 아니라 대본에 (14강)→ coordinate via a script, not chat (L14)

[추론] 5문항 = S05/S06(①②③) · S08(④) · S08·S10(⑤) 대응. 패턴은 많이 쓰면 좋은 게 아니라 ‘맞는 모양’을 고를 때 좋다. (s14 5점검·s13 5점검 패턴 계승.)[inference] The five map onto S05/S06 (①②③) · S08 (④) · S08·S10 (⑤). Patterns aren't good because you use many — they're good when you pick the ‘right shape’. (Carrying the 5-check pattern from lessons 14 & 13.)

4막 — 한 문장으로Act 4 — In one sentence

만들 줄 아는 건 시작, 모양을 고르는 안목이 그다음, 자동화가 프론티어.Building is the start, choosing the shape is the eye, automating is the frontier.

팀 만들기 = 시작 → 모양 고르기 = 안목 (오늘) → 자동화 = 프론티어
  전제 — 자동화는 ‘채점 가능한 일’ 위에서만 작동
Build a team = start → Choose the shape = the eye (today) → Automate = the frontier
  Premise — automation works only on ‘scorable’ work

[추론] 13강(환경 설계)·14강(팀)·18강(측정)이 보너스 룰에서 만나는 지점 — 단, 자동화(프론티어)는 ‘채점 가능’을 전제(18강). 안목 없이 자동화부터 가면 헛돈다.[inference] Where lesson 13 (designing the environment), 14 (the team), & 18 (measurement) meet in the bonus rule — but automation (the frontier) presumes ‘scorability’ (lesson 18). Jump to automation without the eye and it spins its wheels.

닫으며 · 모양을 고르는 사람Closing · the one who chooses the shape

혼자 말고 팀을 — 그리고 이제,
그 팀의 모양을 골라라.
Not solo but a team — and now,
choose that team's shape.

맨 처음 두 장면 기억나시죠 — A는 의존성을 그렸어야, B는 독립성을 봤어야 했어요. 둘 다 답은 ‘모양’이었습니다.Remember the first two scenes — A should have mapped the dependency, B should have seen the independence. Both answers were ‘the shape’.

14강이 ‘혼자 말고 팀을’이었다면, 오늘은 ‘그 팀의 모양을 골라라’ — 그 선택마저 추천받고(플래너), 언젠간 데이터로 자동화(프론티어)합니다.If lesson 14 was ‘build a team’, today is ‘choose its shape’ — and even that choice gets recommended (the planner), then automated from data (the frontier).

사실 이 보너스 강도 — 집필과 팩트체크를 동시에(병렬 fan-out) 돌리고, 바깥 사실이라 교차검증을 끼워 만들었어요. 오늘 배운 ‘모양 고르기’를, 이 강이 스스로 한 거죠.This bonus lesson, too — writing & fact-check ran at once (parallel fan-out), with a cross-check slotted in for outside facts. The ‘shape-choosing’ taught today, it did to itself.

모양 · SHAPESHAPE

[추론] 20강 완결 구조 유지, s21은 보너스/심화 특별편(14강 직접 후속). 자동 최적화는 ‘채점 가능’ 전제이자 방향 감각 — 지금은 ‘모양을 고르는 안목 + 플래너’까지가 실무. lead3 자기참조는 14강(S14)의 ‘이 강도 팀이 만들었다’(팀의 존재)와 다른 각도 — ‘제작의 패턴 선택’(병렬 fan-out + 교차검증)을 공개해 s21 주제(모양 고르기)를 자기시연(반복 아님).[inference] The 20-lesson finale stays; s21 is a bonus/deep-dive special (a direct sequel to lesson 14). Auto-optimization presumes ‘scorability’ and is a sense of direction — for now, ‘the eye to choose the shape + the planner’ is the practical edge. lead3's self-reference is a different angle from lesson 14 (S14)'s ‘this lesson was built by a team’ (the team's existence) — it discloses the production's pattern choice (parallel fan-out + cross-check) to self-demonstrate s21's theme (choosing the shape), not to repeat it.

보너스 · 강의 노트Bonus · Lecture notes

보너스강 · 에이전트 오케스트레이션Bonus Lesson · Agent Orchestration

팀을 만들 줄 알면, 이제 그 모양을 골라라Once you can build a team, choose its shape

강의 요약Summary

14강에서 우리는 "혼자 쓰지 말고 팀을 만들어라"를 배웠습니다. 그런데 막상 팀을 꾸려 보면 금방 알게 됩니다. 팀을 만들 줄 아는 것과, 그 팀을 어떤 모양으로 짤지 잘 고르는 것은 전혀 다른 문제라는 걸요. 순서가 있는 일을 다섯 명에게 동시에 던지면 뒷사람이 앞사람 결과를 못 받아 엉키고, 서로 상관없는 일을 굳이 한 줄로 세우면 동시에 끝낼 수 있었던 시간이 통째로 낭비됩니다. 둘 다 분명히 "나눴는데" 하나는 엉키고 하나는 느렸던 이유는, 나눴느냐가 아니라 어떤 모양으로 나눴느냐였습니다.In Lesson 14 we learned "don't work solo — build a team." But once you actually assemble a team, you quickly discover something: knowing how to build a team and choosing the right shape for it are entirely different problems. Throw an ordered job at five people simultaneously, and the later steps never receive the earlier results — everything tangles. Force unrelated jobs into a single queue, and time that could have been spent finishing at once gets wasted waiting in line. Both teams clearly did "split" the work, yet one tangled and one crawled — because the problem was never whether you split, but what shape you split into.

그래서 이 보너스강은 팀의 모양을 여섯 가지로 정리한 카탈로그와, 일의 모양만 보면 맞는 패턴이 바로 보이는 매핑 표, 그리고 헷갈릴 때 위에서부터 순서대로 물으면 되는 네 가지 질문을 손에 쥐여 드립니다. 순서가 있으면 컨베이어 벨트(체이닝), 유형별로 갈리면 안내데스크(라우팅), 서로 독립이면 동시에(병렬), 정답이 애매하거나 틀리면 비싸면 작가와 편집자(평가자 루프), 범위가 너무 크면 팀장(오케스트레이터-워커)입니다. 콜드오픈의 두 실패도 이 표 하나로 설명됩니다 — 체이닝이 답인 일에 병렬을 씌우거나, 병렬이 답인 일에 체이닝을 씌운 것뿐입니다.So this bonus lesson puts a six-shape catalog, a mapping table that reveals the right pattern just by looking at the job's shape, and a four-question checklist for when you're unsure — all in your hands. An ordered job is the conveyor belt (chaining); work that splits by type is the reception desk (routing); independent pieces go at once (parallel); a fuzzy or costly-to-get-wrong answer calls for the writer-and-editor (evaluator loop); and a scope too big to slice by hand goes to the team lead (orchestrator-workers). Both cold-open failures are explained by this one table — one job needed chaining and got parallel, the other needed parallel and got chaining.

여기서 한 단 더 올라갑니다. 표와 네 질문을 매번 머리로 돌리는 대신, 실행 전에 플래너에게 단계별 패턴을 추천받고, 사람은 그걸 검토·승인하는 검토자가 되는 것입니다. 이건 새 프레임워크가 아니라 "이 플랜에 맞는 실행 패턴을 단계별로 추천해줘" 한마디로 충분합니다. 그리고 연구의 최전선에서는 GPTSwarm이나 DSPy처럼 그 배선 자체를 데이터로 진화시키는 시도도 있지만, 이건 정답을 점수로 채점할 수 있는 일에서만 작동합니다 — 18강의 "측정하지 못하면 개선할 수 없다"와 정확히 같은 이야기입니다.From here we climb one more step. Instead of running the table and the four questions in your head every time, you get a per-step pattern recommendation from a planner before you execute, and you become the reviewer who checks and approves it. This isn't a new framework — one line, "recommend an execution pattern for each step of this plan," is enough. And at the research frontier, attempts like GPTSwarm or DSPy evolve the wiring itself from data — but this only works on jobs where the answer can be scored, which is exactly Lesson 18's "if you can't measure it, you can't improve it," restated.

실무 스펙트럼에서 대부분의 일은 사람이 직접 그리는 왼쪽 끝(수동 배선)에서 반자동인 가운데(DSPy) 사이에 있고, 14강에서 만든 하네스가 바로 그 수동 배선입니다. 그러니 새 도구를 서두르기보다 가진 걸 잘 쓰는 게 먼저입니다. 오늘의 한 문장은 이겁니다 — 만들 줄 아는 건 시작, 모양을 고르는 안목이 그다음, 자동화가 프론티어. 순서를 거꾸로 가면, 즉 안목 없이 자동화부터 욕심내면 헛돕니다. 패턴은 많이 쓴다고 좋은 게 아니라, 맞는 모양을 고를 때만 좋습니다.On the practical spectrum, most real work sits between the far left (manual wiring, drawn by hand) and the semi-automatic middle (DSPy), and the harness you built in Lesson 14 is exactly that manual wiring. So using what you already have well comes before rushing to install something new. Today's sentence is this: building is the start, the eye to choose the shape comes next, and automating that choice is the frontier. Reverse the order — reach for automation without the eye first — and it just spins. Patterns aren't good because you use more of them; they're good only when you pick the one that fits.

핵심 개념 5가지Five key concepts

  1. 01

    팀의 모양, 여섯 가지 카탈로그The team's shape: a six-part catalog

    팀의 모양은 크게 여섯 가지입니다. 컨베이어 벨트(한 사람의 결과물이 다음 사람의 재료가 되는 체이닝), 안내데스크(들어온 일을 유형별로 알맞은 곳에 배정하는 라우팅), 동시에 던지기(서로 상관없는 일을 한꺼번에 맡기는 병렬, 그리고 같은 질문을 여러 번 시켜 투표로 정하는 변형), 팀장(가운데서 상황을 보며 그때그때 나눠 맡기는 오케스트레이터), 작가와 편집자(초안과 비평을 주고받으며 다듬는 평가자-최적화 루프), 끝 조건만 주기(단계를 안 짜 주고 알아서 움직이게 두는 자율 에이전트). 이 여섯은 "Anthropic이 정한 절대 분류"가 아니라, 정해진 길을 따르는 다섯 워크플로우에 스스로 길을 정하는 에이전트를 더해 한 표로 묶은 것입니다.A team's shape comes in six broad kinds. The conveyor belt (chaining, where one person's output becomes the next person's material), the reception desk (routing, assigning incoming work to the right place by type), throwing things out at once (parallel, for unrelated jobs, plus a variant that asks the same question several times and settles it by vote), the team lead (the orchestrator, watching the situation and divvying work out on the fly), the writer and editor (the evaluator-optimizer loop, passing a draft and critique back and forth), and giving only the end condition (the autonomous agent, moving on its own without a scripted sequence). These six aren't "Anthropic's official taxonomy" — they're five workflows that follow predefined paths, plus the self-directing agent, bundled into one table for convenience.

  2. 02

    패턴은 외우지 말고, 일의 모양에서 읽어라Don't memorize patterns — read them off the job's shape

    패턴 이름을 다 외울 필요는 없습니다. 대신 일을 먼저 들여다보고 네 가지만 순서대로 물으면 됩니다. 첫째, 단계끼리 의존성이 있나(앞이 끝나야 뒤가 되나) — 그렇다면 체이닝. 둘째, 들어오는 일이 유형별로 갈리나 — 그렇다면 라우팅. 셋째, 서로 독립인 일이 여러 개인가 — 그렇다면 병렬. 넷째, 정답을 채점할 수 있거나 틀리면 비싼 일인가 — 그렇다면 평가자 루프에 교차검증을 더합니다. 표는 급할 때 곁눈질로, 네 질문은 헷갈릴 때 한 발씩 걸어가는 길입니다. 범위가 너무 커서 이 질문 자체가 벅차면, 그 판단을 팀장(오케스트레이터-워커)에게 맡깁니다.You don't need to memorize every pattern name. Instead, look at the job first and ask just four questions in order. First, do the steps depend on each other — does the back need the front to finish? If so, chaining. Second, does the incoming work split by type? If so, routing. Third, are there several independent pieces? If so, parallel. Fourth, can the answer be scored, or is being wrong costly? If so, the evaluator loop plus cross-checking. The table is for glancing up when you're in a hurry; the four questions are the path you walk step by step when unsure. If the scope is too big for a person to even work through these questions, hand that very judgment to the team lead — the orchestrator-workers.

  3. 03

    틀린 모양은 안 나누느니만 못하다The wrong shape can be worse than not splitting at all

    콜드오픈의 두 팀을 해부하면 답이 보입니다. 첫 번째 팀은 순서가 있는 일인데 의존성을 무시하고 동시에 던져서 엉켰고(체이닝이 답인데 병렬을 골랐고), 두 번째 팀은 서로 독립인 일인데 굳이 한 줄로 세워서 느려졌습니다(병렬이 답인데 체이닝을 골랐습니다). 세 번째 함정도 있습니다 — 작고 단순한 일에 팀장과 서브에이전트까지 거창하게 붙이면, 일은 그대로인데 조율하는 품만 늘어납니다. 14강의 "나눌 가치가 있을 때만 나눠라"는 경계가 여기서도 그대로 적용됩니다. 패턴을 지정한다고 품질이 오르는 게 아니라, 맞는 패턴을 골라야 오릅니다.Dissect the cold open's two teams and the answer becomes clear. The first team had an ordered job, ignored the dependency, threw it out at once, and tangled — chaining was the answer, but they picked parallel. The second team had independent pieces, forced them into a single queue, and it crawled — parallel was the answer, but they picked chaining. There's a third trap too: bolting a grand team lead and sub-agents onto a small, simple job — the work stays the same while coordination overhead piles up. Lesson 14's caution, "split only when it's worth splitting," applies here just the same. Quality doesn't rise because you assigned a pattern — it rises only when you pick the right one.

  4. 04

    오케스트레이션 플래너 — 추천받고, 검토하고, 대본에 박제The orchestration planner — recommend, review, freeze into the harness

    표와 네 질문을 매번 머리로 돌리는 대신, 실행 전에 계획(조사·초안·검증·품의)을 적고 플래너에게 단계별 패턴을 추천받습니다. "조사 다섯 개는 독립이니 병렬로, 초안은 조사 다음이니 체이닝으로, 검증은 평가자 루프로" 하는 식으로 전략표가 미리 나옵니다. 사람은 이걸 그냥 따르는 게 아니라 검토자로서 승인하거나 고칩니다 — "검증만 더 중요하니 결과를 여러 개 받아 교차검증하자"처럼요. 이게 1강 Rule No.1, 결과를 그냥 믿지 말라는 것의 실천입니다. 마음에 드는 방식이 나오면 14강의 하네스, 즉 대본에 박제해 다음번에도 자동으로 뜨게 합니다. 별도 프레임워크는 필요 없고, "이 플랜에 맞는 실행 패턴을 단계별로 추천해줘" 한마디면 충분합니다.Instead of running the table and four questions in your head every time, write the plan (research, draft, verify, proposal) and get a per-step pattern recommendation from a planner before you execute. It comes out as a ready strategy sheet: "the five research items are independent, so parallel; the draft comes after research, so chain it; verification gets the evaluator loop." A person doesn't just follow this — they review it as a reviewer and approve or adjust it, like "verification matters most, let's take several results and cross-check." This is Rule No.1 from Lesson 1 — don't just trust the output — put into practice. Once you land on an approach you like, freeze it into Lesson 14's harness, the script, so it comes up automatically next time. No new framework needed — one line, "recommend an execution pattern for each step of this plan," is enough.

  5. 05

    자동 최적화의 조건 — 채점할 수 있어야 한다The condition for auto-optimization — it must be scorable

    연구 최전선에서는 팀의 배선 자체를 AI가 데이터로 진화시키는 시도가 있습니다. GPTSwarm은 에이전트를 점, 연결을 선으로 본 그래프에서 점수를 올리는 연결을 학습해 강화하고, DSPy는 사람이 손으로 다듬는 대신 프롬프트와 가중치를 점수를 향해 자동으로 튜닝합니다. 하지만 결정적인 조건이 있습니다 — 이건 정답을 점수로 채점할 수 있는 일에서만 작동합니다. 수학·코딩 문제처럼 맞고 틀림이 객관적인 일에는 통하지만, "가계부를 보기 좋게 정리해줘"처럼 무엇이 더 나은지 모호한 일에는 헛돕니다. 실무 스펙트럼은 왼쪽(수동 배선, LangGraph·CrewAI) → 가운데(DSPy, 반자동) → 오른쪽(GPTSwarm, 완전 자동)으로 이어지는데, 실무는 거의 왼쪽~가운데 사이에 있고, 여러분이 만든 하네스가 이미 그 왼쪽입니다. 오른쪽 끝은 "언젠가 저런 것도 있다"는 방향 감각으로 충분합니다.At the research frontier, there are attempts to have AI evolve the team's wiring itself from data. GPTSwarm treats agents as dots and connections as lines in a graph, learning and reinforcing the connections that raise the score; DSPy automatically tunes prompts and weights toward a target score instead of a person hand-tuning them. But there's a decisive condition — this only works on jobs where the answer can be scored. It works for objectively right-or-wrong jobs like math or coding, but spins its wheels on something fuzzy like "tidy up my household ledger nicely." The practical spectrum runs from the left (manual wiring — LangGraph, CrewAI) through the middle (DSPy, semi-automatic) to the right (GPTSwarm, fully automatic); real work sits almost entirely between left and middle, and the harness you've already built is that left end. The far right is enough to know as a sense of direction — "someday, there's that too."

실습 예제Exercise

오늘 배운 4질문과 오케스트레이션 플래너를, 여러분이 실제로 반복하는 다단계 업무 하나에 그대로 걸어 봅니다. 코드나 새 도구는 필요 없습니다 — Claude 대화창에 여러분의 실제 업무를 계획 형태로 적고, 아래 지시문을 그대로 붙여 넣어 단계별 패턴 추천을 받아 봅니다. 핵심은 추천을 그냥 따르는 게 아니라, 검토자로서 각 단계의 모양이 맞는지 직접 확인하는 감각을 기르는 것입니다.Apply today's four questions and the orchestration planner to a real, repeated multi-step job of your own. No code or new tools needed — write your actual work as a plan in a Claude chat, paste the instruction below, and get a per-step pattern recommendation. The point isn't to accept the recommendation as-is; it's to build the instinct to review, as the reviewer, whether each step's shape is actually right.

복사해서 Claude 대화창에 붙여넣기Copy & paste into a Claude chat

다음 두 가지를 순서대로 해줘. ## 1단계 — 내 업무를 계획으로 쪼개기 내가 반복하는 다단계 업무는 이거야: [여기에 실제 업무를 3~6단계로 적어줘. 예: 경쟁사 조사 → 초안 작성 → 마진 검증 → 품의서 제출] 각 단계를 한 줄씩 나열하고, 단계 사이에 순서(의존성)가 있는지, 서로 독립인 단계가 있는지, 유형별로 나뉘는 단계가 있는지 먼저 파악해서 알려줘. ## 2단계 — 단계별 실행 패턴 추천 방금 파악한 계획에 맞춰, 각 단계마다 어떤 실행 패턴이 맞는지 추천해줘. 다음 여섯 가지 중에서 골라: 체이닝(순서 의존), 라우팅(유형 분기), 병렬(서로 독립), 평가자 루프(정답이 애매하거나 틀리면 비쌈 — 교차검증 포함), 오케스트레이터-워커(범위가 너무 큼), 자율 에이전트(끝 조건만 있으면 됨). 추측하지 말고, 왜 그 패턴을 골랐는지 이유를 각 단계마다 한 줄로 밝혀줘. 애매한 단계가 있으면 "애매함"이라고 솔직히 말해줘.

  1. 계획 적기: 여러분이 실제로 반복하는 업무를 계획으로 쪼갠다. 단계마다 순서가 있는지, 독립인지, 유형이 갈리는지를 스스로도 먼저 한번 생각해 본 다음 Claude의 답과 비교한다.Write the plan: split a real, repeated task of yours into steps. Before comparing with Claude's answer, first think through yourself whether each step is ordered, independent, or splits by type.
  2. 추천 받기: 2단계 지시문으로 단계별 패턴 추천을 받는다. 추천 각각에 대해 "왜 이 모양인가"의 이유가 오늘 배운 네 질문(의존성·유형·독립성·채점 가능성) 중 어디에 해당하는지 스스로 짚어 본다.Get the recommendation: use the step-2 instruction to get a per-step pattern recommendation. For each recommendation, check for yourself which of today's four questions — dependency, type-split, independence, scorability — the reasoning actually maps to.
  3. 검토자로 승인·수정: 추천을 그대로 따르지 말고, 이 일에서 정말 중요한 단계(틀리면 비싼 단계)가 있다면 "여러 결과를 받아 교차검증해줘"로 직접 고쳐 지시한다. 마음에 드는 최종 방식이 나오면, 다음번 같은 업무에도 쓸 수 있도록 프로젝트 CLAUDE.md나 스킬에 그대로 적어 둔다 — 이게 오늘 배운 걸 하네스에 박제하는 것이다.Approve or revise as reviewer: don't just accept the recommendation — if there's a step in this job that really matters (costly if wrong), explicitly revise it to "get several results and cross-check." Once you land on a final approach you like, write it into your project's CLAUDE.md or a skill so it's ready for the same job next time — that's freezing today's lesson into the harness.

전체 대본Full transcript

1 · 보너스 룰1 · Bonus rule

이십 강까지, 코스 본편을 끝까지 따라오신 분들을 위한 보너스 한 단입니다. 십사 강에서 우리는 "혼자 쓰지 말고 팀을 만들어라"를 배웠죠. 그런데 막상 팀을 꾸려 보면 금방 알게 됩니다. 팀을 만들 줄 아는 것과, 그 팀을 어떤 모양으로 짤지 잘 고르는 것은 전혀 다른 문제라는 걸요. 오늘은 그 다음 한 단을 올라갑니다. 일의 모양을 읽고 거기 맞는 패턴을 고르는 법, 그리고 그 고르는 일마저 추천받아 자동화하는 법이에요. 보너스 룰은 이겁니다. 팀을 만들 줄 알면, 이제 그 모양을 골라라.This is a bonus step for those of you who followed the main course all the way through Lesson Twenty. In Lesson Fourteen we learned "don't work solo — build a team." But once you actually put a team together, you quickly notice something: knowing how to build a team and choosing the right shape for that team are completely different problems. Today we climb one more step — how to read the shape of the work and pick the matching pattern, and then how to automate even that choice by getting a recommendation. The bonus rule is this: once you can build a team, now choose its shape.

2 · 둘 다 '팀'인데2 · Both used a 'team'

두 장면을 보여드릴게요. 둘 다 십사 강에서 배운 대로, 일을 혼자 안 하고 "팀"으로 나눴습니다. 첫 번째 팀. 신상품 입점 일을 다섯 명한테 나눠 줬어요. 그런데 이 일은 순서가 있죠. 경쟁사 가격을 조사해야 설명 초안을 쓰고, 초안이 있어야 마진을 검증하고, 그게 끝나야 품의서를 올립니다. 앞이 끝나야 뒤가 시작되는 일이에요. 그런데 이걸 다섯 명한테 동시에 던졌더니, 검증을 맡은 사람이 이럽니다. "저, 초안이 아직 안 왔는데요?" 뒷사람이 앞사람 결과를 못 받아서 전부 엉켜 버립니다. 두 번째 팀. 이번엔 서로 상관없는 카테고리 다섯 개의 경쟁사 조사예요. 가전, 식품, 의류, 따로따로 봐도 되는 일이죠. 그런데 굳이 한 줄로 줄을 세웠습니다. 하나 끝나고 다음, 또 그다음. 동시에 끝낼 수 있는 일을 차례로 기다리느라, 기다리는 시간이 통째로 쌓여서 한참 느려집니다.Let me show you two scenes. In both, just like Lesson Fourteen taught, the work wasn't done solo — it was split into a "team." First team. A new product onboarding job, handed out to five people. But this job has an order: you research competitor prices before you draft the description, you need the draft before you verify the margin, and only then do you file the proposal. Each step needs the one before it. Yet all five were thrown out at the same time — and the person assigned to verification says, "Um, the draft hasn't arrived yet?" The later steps never get the earlier results, and the whole thing tangles up. Second team. This time it's competitor research for five unrelated categories — appliances, food, clothing — each fine to look at on its own. But they were lined up in a single queue: finish one, then the next, then the next. Work that could have finished at once waits its turn, and the waiting piles up until it crawls.

자, 두 팀 다 분명히 "나누긴" 했어요. 십사 강에서 배운 대로 팀으로 만들었죠. 그런데 하나는 엉키고, 하나는 느렸습니다. 왜일까요? 문제는 나눴느냐가 아니었어요. 어떤 모양으로 나눴느냐였습니다. 순서가 있는 일을 동시에 던지면 엉키고, 서로 상관없는 일을 줄 세우면 느려져요. 그래서 오늘의 질문은 이겁니다. 팀으로 나누되, 어떤 모양으로 나눌 것인가.Now, both teams clearly did split the work. They built a team, exactly like Lesson Fourteen said. Yet one tangled and one crawled. Why? The problem wasn't whether they split. It was what shape they split into. Throw an ordered job out all at once and it tangles; line up unrelated jobs and it crawls. So today's question is this: split into a team, yes — but into what shape?

3 · 오늘의 질문3 · Today's question

십사 강은 "나눌까, 말까"를 가르쳤어요. 작고 단순한 일은 혼자, 크고 독립적인 일은 팀으로. 그 판단까지였죠. 오늘은 그 다음을 묻습니다. 나누기로 했다면, 어떤 모양으로 나눌까. 방금 봤듯이, 같은 팀이라도 모양을 잘못 고르면 느려지거나 아예 틀립니다. 그러니까 팀을 만들 줄 아는 것만으로는 부족하고, 일을 보고 맞는 모양을 골라내는 안목이 필요해요. 그 안목을 오늘 두 장의 표와 네 개의 질문으로 손에 쥐여 드릴게요.Lesson Fourteen taught "whether to split." Small, simple jobs solo; big, independent jobs as a team. It stopped at that judgment. Today we ask the next question. If you've decided to split — into what shape? As we just saw, even the same team, given the wrong shape, runs slow or comes out wrong. So knowing how to build a team isn't enough; you need the eye to look at a job and choose the matching shape. Today I'll put that eye in your hands — with two tables and four questions.

4 · 패턴 6종 카탈로그4 · The six-pattern catalog

그럼 팀의 모양에는 어떤 것들이 있는지 카탈로그를 펼쳐 볼게요. 크게 여섯 가지인데, 비유로 빠르게 지나가겠습니다. 첫째, 컨베이어 벨트. 한 사람의 결과물이 다음 사람의 재료가 되어 줄줄이 이어지는 모양이에요. 조사 결과가 초안으로, 초안이 검증으로 넘어가죠. 이걸 프롬프트 체이닝이라고 부릅니다. 둘째, 안내데스크. 들어온 일을 보고 "이건 환불 담당, 저건 기술 담당" 하고 유형별로 알맞은 곳에 배정하는 모양이에요. 라우팅이라고 합니다. 셋째, 동시에 던지기. 서로 상관없는 일을 여러 사람한테 한꺼번에 맡기는 모양이죠. 십사 강에서 본 병렬, 팬 아웃이 이거예요. 여기에 한 가지 변형이 있는데, 같은 질문을 일부러 여러 번 시켜 보고 그 답들을 모아 투표로 정하는 방식도 있습니다.So let's open the catalog of team shapes. There are six broad kinds, and I'll run through them quickly with metaphors. One: a conveyor belt. One person's output becomes the next person's material, linked in a chain — research feeds the draft, the draft feeds the verification. This is called prompt chaining. Two: a reception desk. You look at what came in and route it to the right place — "this one's for refunds, that one's for tech." That's routing. Three: throwing things out at once. Handing unrelated jobs to several people simultaneously — this is the parallel, the fan-out, we saw in Lesson Fourteen. There's a variation, too: deliberately asking the same question several times and then settling it by a vote among the answers.

넷째, 팀장. 일을 어떻게 쪼갤지 미리 정하지 않고, 가운데 팀장이 상황을 보며 그때그때 나눠 맡기는 모양이에요. 십사 강의 오케스트레이터, 바로 그 사람입니다. 다섯째, 작가와 편집자. 한 사람이 초안을 쓰면 다른 사람이 비평하고, 그걸 받아 또 고치고, 이렇게 주고받으며 다듬는 모양이에요. 십사 강의 생산자-검증자를 한 단계 더 밀어붙인, 평가자-최적화 루프입니다. 여섯째, 끝 조건만 주기. 단계를 일일이 짜 주지 않고 "이 조건이 되면 끝"만 정해 준 뒤 알아서 움직이게 두는, 자율 에이전트예요. 한 가지 꼭 짚고 갈게요. 이 여섯 가지를 "Anthropic이 정한 여섯 패턴"이라고 외우시면 안 됩니다. Anthropic은 정해진 길을 따르는 워크플로우를 다섯 가지로 정리하고, 거기에 스스로 길을 정하는 "에이전트"를 따로 구분해요. 우리는 그 다섯에 자율 에이전트를 더해, 한 표로 보기 좋게 여섯 칸으로 묶은 겁니다. 그중 앞의 두 개, 컨베이어 벨트와 안내데스크, 그리고 투표는 십사 강엔 없던 새 모양이에요. 나머지는 복습에 이름표를 붙인 거고요.Four: a team lead. Instead of deciding up front how to slice the work, a lead in the center watches the situation and divvies it out on the fly. That's the orchestrator from Lesson Fourteen — the very same one. Five: a writer and an editor. One person writes a draft, another critiques it, the draft comes back to be revised, and they pass it back and forth until it's polished. That's the producer–verifier from Lesson Fourteen pushed one step further — the evaluator-optimizer loop. Six: giving only the end condition. Instead of scripting every step, you set just "stop when this is met" and let it move on its own — an autonomous agent. One thing to be careful about: don't memorize these as "Anthropic's six patterns." Anthropic organizes workflows that follow predefined paths into five kinds, and separately distinguishes the "agent" that directs its own path. We've added the autonomous agent to those five and bundled them into six neat cells in one table. Of these, the first two — the conveyor belt and the reception desk — plus voting are new shapes that weren't in Lesson Fourteen. The rest are review, with name tags attached.

5 · 매핑 치트시트5 · The mapping cheatsheet

이제 카탈로그를 외우는 대신, 찾아보는 표로 바꿔 볼게요. 일의 모양만 보면 맞는 패턴이 바로 보이도록요. 첫째, 앞이 끝나야 뒤가 시작되는 일, 순서가 있는 일이면 컨베이어 벨트, 체이닝입니다. 둘째, 들어오는 게 유형별로 갈리는 일이면 안내데스크, 라우팅이에요. 셋째, 서로 상관없는 일이 여러 개면 동시에, 병렬입니다. 넷째, 정답이 또렷하지 않거나 틀리면 대가가 큰 일이면 작가와 편집자, 평가자 루프를 쓰고, 중요하면 여러 결과를 세에서 다섯 개쯤 받아 서로 교차검증합니다. 다섯째, 범위가 너무 커서 어떻게 쪼갤지부터가 일이면 팀장한테 맡기는 오케스트레이터-워커예요.Now, instead of memorizing the catalog, let's turn it into a lookup table — so that just looking at the shape of a job points to the matching pattern. One: if the back can't start until the front finishes — an ordered job — it's the conveyor belt, chaining. Two: if what comes in splits by type — the reception desk, routing. Three: if there are several unrelated jobs — at once, in parallel. Four: if the answer isn't clear-cut, or being wrong is costly — use the writer-and-editor, the evaluator loop, and when it matters, take several results, say three to five, and cross-check them against each other. Five: if the scope is so big that even figuring out how to slice it is the job — hand it to the team lead, the orchestrator-workers.

여기서 가장 중요한 한마디. 패턴은 외우는 게 아니에요. 일의 모양에서 읽어내는 겁니다. "이 일은 순서가 있나? 유형이 갈리나? 독립이 여럿인가?" 이렇게 일을 먼저 들여다보면, 표가 알아서 패턴 하나를 가리켜요. 그래서 이 표가 오늘 강의에서 손에 남는 핵심 자산입니다. 패턴 이름을 다 못 외워도 괜찮아요. 이 표 하나만 곁에 두고 찾아보면 되니까요.Here's the most important line. Patterns aren't something you memorize. They're something you read from the shape of the work. "Does this job have an order? Does it split by type? Are there several independent pieces?" Look at the job first, and the table points to a single pattern on its own. That's why this table is the keeper from today's lesson — the thing that stays in your hands. It's fine if you can't memorize every pattern name. Just keep this one table nearby and look it up.

6 · 4질문 플로우차트6 · The four-question flowchart

방금 표가 찾아보기였다면, 이번엔 걸어가기예요. 위에서부터 네 가지만 순서대로 물으면, 자동으로 한 모양에 도착합니다. 첫 번째 질문. 단계끼리 의존성이 있나요? 앞이 끝나야 뒤가 되나요? 그렇다면 컨베이어 벨트, 체이닝입니다. 아니면 다음 질문으로. 두 번째 질문. 들어오는 일이 유형별로 갈리나요? 그렇다면 안내데스크, 라우팅이에요. 세 번째 질문. 서로 독립인 일이 여러 개인가요? 그렇다면 동시에, 병렬입니다. 네 번째 질문. 정답을 채점할 수 있거나, 틀리면 비싼 일인가요? 그렇다면 작가와 편집자, 평가자 루프에 교차검증을 더합니다.If the table was looking it up, this is walking it through. Ask just four questions, top to bottom, and you arrive at one shape automatically. First question: do the steps depend on each other? Does the back need the front to finish first? If so — the conveyor belt, chaining. If not, next question. Second question: does the incoming work split by type? If so — the reception desk, routing. Third question: are there several independent pieces? If so — at once, in parallel. Fourth question: can the answer be graded, or is being wrong costly? If so — the writer and editor, the evaluator loop, with cross-checking added.

같은 결정인데 표현이 두 가지예요. 표는 급할 때 곁눈질로 찾아보는 거고, 이 네 질문은 헷갈릴 때 한 발씩 걸어가는 길입니다. 둘 중 편한 걸 쓰시면 돼요. 그리고 한 가지. 일의 범위가 너무 커서 이 질문들을 사람이 일일이 따지기도 벅차다면, 그때는 팀장, 오케스트레이터-워커한테 맡깁니다. 이 따져 보는 과정 자체를 팀장이 대신 돌려 주거든요.It's the same decision in two forms. The table is for glancing up when you're in a hurry; these four questions are the path you walk, step by step, when you're unsure. Use whichever suits you. And one more thing: if the scope is so big that even working through these questions is too much for a person to do by hand, then hand it to the team lead, the orchestrator-workers. The lead runs that very weighing-up process for you.

7 · 흔한 실수 — 콜드오픈 해부7 · Common mistakes — dissecting the cold open

이제 맨 처음 두 장면이 왜 망했는지, 콜드 오픈을 해부해 볼게요. 첫 번째 팀의 실수. 순서가 있는 일인데 의존성을 무시하고 동시에 던졌어요. 그러니까 뒷사람이 앞사람 결과를 못 받아서 엉킨 겁니다. 답은 체이닝이었는데 병렬을 고른 거죠. 두 번째 팀의 실수는 정반대예요. 서로 독립인 일인데 굳이 한 줄로 줄을 세웠어요. 동시에 끝낼 수 있는 걸 차례로 기다리느라 느려진 겁니다. 답은 병렬이었는데 체이닝을 고른 거고요.Now let's dissect the cold open — why those first two scenes failed. The first team's mistake: it was an ordered job, but they ignored the dependency and threw it out all at once. So the later people never got the earlier results, and it tangled. The answer was chaining, but they chose parallel. The second team's mistake is the exact opposite. The pieces were independent, yet they were forced into a single queue. Work that could have finished at once waited its turn and slowed down. The answer was parallel, but they chose chaining.

세 번째 함정도 있어요. 작고 단순한 일인데 굳이 팀장에 서브에이전트까지 거창하게 붙이는 거예요. 그러면 일은 그대로인데 조율하는 품만 늘어납니다. 십사 강에서 "나눌 가치가 있을 때만 나눠라" 했던 그 경계가 여기서도 똑같이 적용돼요. 그래서 오늘 가장 중요한 한 줄은 이겁니다. 패턴을 지정한다고 품질이 올라가는 게 아니라, 맞는 패턴을 골라야 올라갑니다. 틀린 모양을 억지로 씌우면, 차라리 안 나누느니만 못할 수도 있어요. 일 강의 룰, 결과를 그냥 믿지 말라는 말이 여기서도 살아 있는 거죠. 구조를 씌웠다고 안심하지 말고, 그게 맞는 모양인지 확인하세요.There's a third trap, too: taking a small, simple job and grandly bolting on a team lead and sub-agents anyway. The work stays the same, but the coordination effort piles up. The caution from Lesson Fourteen — "split only when it's worth splitting" — applies here just the same. So today's single most important line is this: quality doesn't rise because you assigned a pattern — it rises when you pick the right one. Force the wrong shape on a job, and you can end up worse off than not splitting at all. Rule Number One from the very first lesson — don't just trust the result — is alive here too. Don't relax just because you've imposed a structure; check that it's the right shape.

8 · 오케스트레이션 플래너8 · The orchestration planner

여기가 오늘의 심장입니다. 사실 표도 네 질문도, 매번 머리로 돌리면 번거롭잖아요. 그래서 한 걸음 더 갑니다. 패턴을 외우지 말고, 실행 전에 추천을 받는 거예요. 화면을 보세요. 먼저 할 일을 플랜으로 적습니다. 조사, 초안, 검증, 품의. 그러면 플래너가 단계마다 모양을 추천해 줘요. "조사 다섯 개는 서로 독립이니 병렬로, 초안은 조사 다음이니 체이닝으로, 검증은 평가자 루프로." 방금 우리가 표와 네 질문으로 했던 그 판단을, 실행 전에 한 장의 전략표로 미리 뽑아 주는 겁니다.This is the heart of today. Honestly, running the table and the four questions in your head every time is a hassle. So we go one step further: instead of memorizing patterns, you get a recommendation before you run. Look at the screen. First you write the work down as a plan — research, draft, verify, proposal. Then the planner recommends a shape for each step: "The five research items are independent, so run them in parallel; the draft comes after research, so chain it; verification gets the evaluator loop." The very judgment we just made with the table and the four questions, pulled out in advance as a single strategy sheet.

그러면 사람은 모든 패턴을 외울 필요가 없어요. 검토자가 되는 거죠. "좋아, 다 괜찮은데 검증만 더 중요하니까 결과를 여러 개 받아 교차검증하자." 이렇게 승인하거나 고치면 됩니다. 추천을 그냥 따르는 게 아니라, 사람이 보고 정한다는 게 중요해요. 일 강의 룰, 결과를 그냥 믿지 말라는 거요. 그리고 마음에 드는 방식이 나오면, 그걸 십사 강에서 배운 하네스, 그러니까 대본에 박제해 둡니다. 그러면 다음번 비슷한 일에도 전략표가 자동으로 떠요. 여기서 좋은 소식. 이걸 하려고 무슨 새 프레임워크를 깔 필요가 전혀 없습니다. 그냥 "이 플랜에 맞는 실행 패턴을 단계별로 추천해 줘" 한마디면 됩니다. 별도 도구, 영 개.That way, you don't have to memorize every pattern. You become the reviewer. "Good — this all looks fine, but verification matters most, so let's take several results and cross-check." You approve it, or you adjust it. The point is you don't just follow the recommendation — you look it over and decide. That's Rule Number One: don't just trust the result. And when you land on an approach you like, you freeze it into the harness — the script — from Lesson Fourteen. Then the strategy sheet comes up automatically for the next similar job. Now the good news: you don't need to install any new framework to do this. Just one line — "recommend an execution pattern for each step of this plan" — is enough. Zero extra tools.

9 · 프론티어 — 자동 최적화9 · Frontier — auto-optimization

여기서 한 발만 더 나가 볼게요. 지금까지는 사람이 모양을 골랐죠. 추천을 받더라도 최종 결정은 사람이었고요. 그런데 연구 쪽에서는, 그 배선 자체를 인공지능이 데이터로 진화시키는 시도가 있습니다. 두 가지만 이름을 가볍게 짚을게요. 하나는 지피티 스웜. 에이전트를 점으로, 그 사이 연결을 선으로 본 그래프를 두고, "어떤 연결이 점수를 올리는지"를 학습해서 좋은 연결은 강화하고 쓸모없는 연결은 잘라 냅니다. 또 하나는 디에스파이. 사람이 프롬프트를 손으로 다듬는 대신, 프롬프트와 가중치를 정해진 점수를 향해 자동으로 튜닝해 줘요. 둘 다 "팀의 모양을 사람이 아니라 데이터가 고른다"는 방향이에요.Let's take just one more step. Up to now, a person chose the shape — even with a recommendation, the final call was human. But in research, there are attempts to have AI evolve that wiring itself from data. Let me name two, lightly. One is GPTSwarm. It treats agents as dots and the connections between them as lines — a graph — and learns "which connections raise the score," strengthening the good ones and pruning the useless ones. The other is DSPy. Instead of a person hand-tuning prompts, it automatically tunes the prompts and weights toward a set score. Both point the same way: the team's shape is chosen by data, not by a person.

그런데 여기 결정적인 조건이 하나 있어요. 이 자동 최적화는 "정답을 점수로 채점할 수 있는 일"에서만 작동합니다. 수학 문제나 코딩 문제처럼, 맞고 틀림을 객관적으로 매길 수 있는 일이요. 점수를 매길 함수가 있어야 어느 쪽이 더 나은지를 기계가 판단하거든요. 반대로 "가계부를 보기 좋게 정리해 줘"처럼 무엇이 더 나은지 채점이 모호한 일에는, 이 방식이 헛돕니다. 어디로 가야 좋은지 신호 자체가 없으니까요. 그래서 이건 지금 당장 실무에 들이라는 도구가 아니라, 아직 연구하고 벤치마크하는 단계예요. "이런 방향이 가능하구나" 하는 감각용입니다. 그리고 이 대목이 십팔 강과 곧장 이어져요. 측정하지 못하면 개선할 수 없다. 채점할 수 없으면 자동 최적화도 못 한다는 말이, 결국 같은 이야기거든요.But there's one decisive condition here. This auto-optimization only works on jobs where the answer can be scored. Jobs like math problems or coding problems, where right and wrong can be judged objectively. You need a scoring function for the machine to decide which side is better. By contrast, for something like "tidy up my household ledger nicely," where what counts as better is fuzzy, this approach spins its wheels — there's no signal telling it which way is good. So this isn't a tool to bring into your daily work right now; it's still at the research-and-benchmark stage. It's for a sense of direction — "so this kind of thing is possible." And this is exactly where Lesson Eighteen connects: if you can't measure it, you can't improve it. "If you can't score it, you can't auto-optimize it" is, in the end, the very same statement.

10 · 실무 스펙트럼 — 너의 위치10 · The practical spectrum — where you stand

그럼 지금 우리가 어디쯤 있는지, 한 줄로 펼쳐 볼게요. 왼쪽 끝은 수동 배선입니다. 사람이 팀의 모양을 직접 그리는 방식이에요. 랭그래프나 크루 에이아이 같은 도구들이 여기 있고, 제어하기 쉬워서 지금 실무의 표준이에요. 가운데가 디에스파이. 모양의 뼈대는 사람이 정하되 안쪽 프롬프트는 자동으로 다듬는, 반자동이죠. 오른쪽 끝이 지피티 스웜. 연결 자체를 데이터로 진화시키는, 연구 프론티어예요. 왼쪽에서 오른쪽으로 갈수록 사람이 정하는 몫은 줄고, 기계가 정하는 몫이 늘어납니다.So let me lay out, in one line, roughly where we stand. The far left is manual wiring — where a person draws the team's shape directly. Tools like LangGraph or CrewAI live here; they're easy to control, and they're today's working standard. In the middle is DSPy: a person sets the skeleton of the shape, but the prompts inside get tuned automatically — semi-automatic. The far right is GPTSwarm, evolving the connections themselves from data — the research frontier. As you move left to right, the share a person decides shrinks, and the share the machine decides grows.

여기서 중요한 건 여러분의 위치예요. 실무는 거의 다 왼쪽에서 가운데 사이에 있습니다. 그리고 이 코스를 끝까지 들은 여러분은, 사실 이미 왼쪽을 쓰고 있어요. 십사 강에서 만든 하네스, 그 대본이 바로 수동 배선이거든요. 그러니까 새 프레임워크를 급히 깔기보다, 가진 걸 잘 쓰는 게 먼저입니다. 오른쪽 끝의 자동 최적화는 "언젠가 저런 것도 있다"는 방향 감각으로 알아 두시면 충분해요.What matters here is your position. Almost all real work sits between the left and the middle. And you, having taken this course to the end, are already using the left. The harness you built in Lesson Fourteen — that script — is exactly manual wiring. So rather than rushing to install a new framework, using well what you already have comes first. The auto-optimization on the far right is enough to know as a sense of direction — "someday, there's that too."

11 · 모양 고르기 5문항11 · Five questions to choose the shape

자, 오늘의 핵심을 다섯 가지 점검으로 묶어 볼게요. 팀을 짜기 전에 이것만 물어보세요. 첫째, 단계 사이의 의존성을 그려 봤나요? 앞이 끝나야 뒤가 되면 체이닝, 서로 상관없으면 병렬입니다. 둘째, 들어오는 일에 유형 분기가 있나요? 있으면 안내데스크, 라우팅이에요. 셋째, 정답을 채점할 수 있거나, 틀리면 비싼 일인가요? 그렇다면 작가와 편집자, 평가자를 따로 두고, 중요하면 여러 결과를 세에서 다섯 개 받아 교차검증하세요.Alright, let me tie today's core into five checks. Before you assemble a team, just ask these. One: did you map the dependencies between steps? If the back needs the front, chain it; if they're unrelated, parallel. Two: does the incoming work split by type? If so, the reception desk — routing. Three: can the answer be scored, or is being wrong costly? If so, place a separate writer-and-editor, an evaluator, and when it matters, take several results — three to five — and cross-check them.

넷째, 실행하기 전에 전략을 한 번 추천받고 골랐나요? 머리로만 정하지 말고, 플래너한테 단계별 추천을 받아 검토자로서 승인하세요. 다섯째, 그 선택을 대본에, 하네스에 적어 뒀나요? 십사 강에서 배웠죠. 조율은 대화가 아니라 대본에 적는다. 다음에도 똑같이 굴러가게요. 마지막으로 꼭 기억하실 게 있어요. 패턴은 많이 쓴다고 좋은 게 아니에요. 맞는 모양을 고를 때 좋은 겁니다. 화려한 모양보다, 이 일에 맞는 모양. 그게 전부예요.Four: before running, did you get a strategy recommendation and choose from it? Don't decide it all in your head — get a per-step recommendation from the planner and approve it as the reviewer. Five: did you write that choice into the script, the harness? You learned it in Lesson Fourteen — coordination goes into a script, not a chat, so it runs the same way next time. And finally, one thing to hold onto: patterns aren't better because you use more of them. They're good when you pick the right shape. Not the fanciest shape — the one that fits this job. That's all there is to it.

12 · 한 문장으로12 · In one sentence

오늘 배운 걸 한 문장으로 굳혀 볼게요. 팀을 만들 줄 아는 건 시작입니다. 일의 모양을 읽고 맞는 패턴을 고르는 안목이 그다음이고, 그 선택마저 데이터로 자동화하는 게 프론티어예요. 시작, 안목, 프론티어. 십삼 강의 환경 설계, 십사 강의 팀, 십팔 강의 측정이 이 한 줄에서 만납니다. 다만 순서를 거꾸로 가지 마세요. 자동화는 채점할 수 있을 때만 되는 거라, 안목 없이 자동화부터 욕심내면 헛돕니다. 만들 줄 알고, 고를 줄 알고, 그다음이 자동화예요.Let me lock today into one sentence. Knowing how to build a team is the start. The eye to read the shape of the work and pick the matching pattern comes next, and automating even that choice from data is the frontier. Start, eye, frontier. Lesson Thirteen's designing the environment, Lesson Fourteen's team, and Lesson Eighteen's measuring all meet in this one line. Just don't run the order backwards. Automation only works when you can score, so reaching for automation without the eye first just spins. Be able to build, be able to choose — and then automation.

13 · 닫으며 — 회수와 자기참조13 · Closing — callback and self-reference

맨 처음 두 장면, 기억나시죠. 이제 답을 돌려받을게요. 첫 번째 팀은 의존성을 그렸어야 했어요. 순서가 있는 일이었으니까요. 두 번째 팀은 독립성을 봤어야 했고요. 서로 상관없는 일이었으니까요. 둘 다, 답은 결국 "모양"이었습니다. 십사 강이 "혼자 쓰지 말고 팀을 만들어라"였다면, 오늘은 한 단을 더 올려 "그 팀의 모양을 골라라"였어요. 그리고 그 고르는 일마저 실행 전에 추천받고, 언젠가는 데이터로 자동화까지 갑니다. 이십 강까지 본편을 다 마친 분들을 위한, 보너스 한 단이었어요.Those first two scenes — remember them? Let me hand back the answers now. The first team should have mapped the dependency — it was an ordered job. The second team should have seen the independence — the pieces were unrelated. For both, the answer, in the end, was "shape." If Lesson Fourteen was "don't work solo — build a team," today went one step up: "choose that team's shape." And even that choosing gets a recommendation before you run, and someday goes all the way to being automated from data. This was a bonus step, for those of you who finished the main course all the way through Lesson Twenty.

마지막으로 작은 고백 하나. 사실 이 보너스 강 자체도 오늘 배운 대로 만들어졌어요. 집필과 팩트체크를 한 줄로 세우지 않고 동시에, 병렬로 돌렸고요. 바깥세상 사실, 그러니까 지피티 스웜이나 디에스파이 같은 건 틀리면 비싸니까, 일부러 교차검증을 끼워 넣었습니다. 오늘 표에서 "정답이 중요하면 교차검증"이라고 했던, 바로 그 모양이죠. 즉, 오늘 가르친 모양 고르기를 이 강이 직접 해 본 거예요. 여러분도 다음에 큰일을 맡기실 때, 딱 한 가지만 떠올리세요. 나누기 전에, 이 일은 어떤 모양일까. 그거면 충분합니다.One last small confession. This bonus lesson itself was made exactly the way we learned today. Writing and fact-checking weren't lined up in a queue — they ran at the same time, in parallel. And the outside-world facts — things like GPTSwarm and DSPy — are costly to get wrong, so we deliberately slotted in cross-checking. That's the very shape the table called for: "when the answer matters, cross-check." In other words, the shape-choosing we taught today, this lesson did itself. So next time you hand off something big, recall just one thing: before you split, what shape is this job? That's enough.

참고References

본 강의는 14강(멀티에이전트 & 하네스)과 18강(평가 & 벤치마킹)의 개념을 전제로 확장합니다. GPTSwarm·DSPy는 연구 프론티어 사례로 방향 감각용으로만 소개되며, 실무 도입을 권장하는 내용이 아닙니다.This lesson builds on concepts from Lesson 14 (Multi-agent & Harness) and Lesson 18 (Evaluation & Benchmarking). GPTSwarm and DSPy are introduced only as research-frontier examples for a sense of direction, not as a recommendation for production adoption.