1 · RULE No.14 — 오프닝1 · Rule No.14 — Opening

지난 시간에 우리는 일꾼 하나를 잘 설계하는 법을 배웠죠. 역할은 좁게, 도구는 최소로, 멈춤과 실패는 미리, 그리고 테스트. 그런데 일이 점점 커지고 복잡해지면, 아무리 잘 만든 일꾼이라도 혼자서는 벅찹니다. 그렇다고 한 명한테 다 떠안기면 책상이, 그러니까 컨텍스트가 흐려져요. 그래서 오늘은 잘 만든 일꾼 여럿을 하나의 팀으로 조율하는 법, 룰 넘버 포틴, "혼자 쓰지 말고 팀을 만들어라"를 다뤄 보겠습니다. 멀티에이전트와 하네스예요. 이 강을 마치면, 큰 업무를 여러 역할로 나눠 동시에 진행시키고 결과를 한데 모을 수 있습니다.Last time we learned how to design one worker well: a narrow role, minimal tools, stops and failures planned in advance, and testing. But as the job grows bigger and more complex, even the best-built worker struggles alone. And if you pile everything onto one of them, the desk — the context — gets foggy. So today, under Rule Number Fourteen, "don't work solo — build a team," we'll cover how to coordinate many good workers into one team: multi-agents and the harness. By the end of this lesson, you'll be able to split a big job into multiple roles, run them at the same time, and bring the results together.

2 · 한 명한테 다 시켰더니2 · What happened when we piled it on one

한 가지 장면을 볼게요. 신상품 입점 검토를 한 세션에, 그러니까 일꾼 하나한테 다 시켰습니다. 경쟁사 가격 조사하고, 상품 설명 초안 쓰고, 마진 검증하고, 입점 품의서까지 전부요. 처음엔 잘 굴러가는 것 같아요. 그런데 작업이 길어질수록 세 가지가 무너집니다. 첫째, 앞에서 정해 둔 가격 근거나 결정이 흐려져요. 둘째, 설명을 쓴 바로 그 일꾼이 자기 마진 계산도 검증하게 됩니다. 셋째, 서로 상관없는 일까지 한 줄로 줄을 서서 느려져요.Let's look at one scene. A new product onboarding review — in a single session, one worker — I asked it to do everything: check competitor prices, draft the product description, verify the margin, and put together the entry proposal. At first it seems to run fine. But the longer the work goes, three things break down. One: the pricing evidence and decisions set earlier get foggy. Two: the very worker that wrote the description ends up verifying its own margin calculation. Three: even unrelated tasks line up in a single queue and slow everything down.

지난 시간에 일꾼을 아주 잘 설계했는데도 이런 일이 생깁니다. 왜냐하면 "한 명을 잘 만드는 것"과 "여럿을 팀으로 나누는 것"은 전혀 다른 문제거든요. 일이 커지면, 더 똑똑한 한 명을 찾을 게 아니라 역할을 나눈 팀이 답입니다. 그래서 오늘의 질문은 이거예요. 언제, 그리고 어떻게 팀으로 나누는가.This happens even when you designed the worker really well last time. Because "making one worker great" and "splitting many into a team" are completely different problems. When the job grows, the answer isn't to find a smarter single worker — it's a team with split roles. So today's question is this: when, and how, do you split into a team?

3 · 오케스트레이터 + 서브에이전트3 · Orchestrator + sub-agents

그럼 팀이 어떻게 생겼는지 보겠습니다. 가운데 조율하는 한 명이 있어요. 이걸 오케스트레이터라고 부릅니다. 오케스트레이터는 직접 모든 일을 하지 않아요. 대신 일을 잘게 쪼개서, 전문 일꾼들에게 나눠 맡깁니다. 이 전문 일꾼들이 바로 서브에이전트예요. 신상품 입점 예시라면, 한 명은 가격 조사, 한 명은 설명 초안, 한 명은 마진 검증. 그리고 오케스트레이터가 이 결과들을 모아 입점 품의서로 취합합니다.So let's see what a team looks like. In the center there's one coordinator. We call it the orchestrator. The orchestrator doesn't do all the work itself. Instead, it splits the job into small pieces and hands them out to specialist workers. Those specialists are the sub-agents. In the new product onboarding example: one does competitor price research, one drafts the product description, one checks the margin. Then the orchestrator gathers those results and compiles them into the entry proposal.

공식 문서를 보면 서브에이전트는 자신만의 컨텍스트에서 위임받은 작업을 하고, 그 결과를 돌려주는 별도의 에이전트라고 정의돼 있어요. 그러니까 오케스트레이터는 일을 쪼개서 배분하고, 돌아온 결과를 합치는 역할입니다. 호출 방식이나 옵션 이름은 2026년 6월 기준이고 버전마다 바뀌니까, 자세한 건 공식 문서로 확인하세요. 핵심만 기억하면 됩니다. 한 명에게 다 몰지 말고, 조율자 한 명과 전문가 여럿으로 나눈다.The official docs define a sub-agent as a separate agent that works in its own context and returns the result of a delegated task. So the orchestrator splits and assigns the work, then combines the results that come back. The exact call syntax and option names are as of June twenty twenty-six and change by version, so check the official docs for specifics. Just remember the core: don't pile it on one — split it into one coordinator and several specialists.

4 · 서브에이전트는 결과만 돌려준다4 · Sub-agents return only the result

여기서 진짜 중요한 포인트가 나옵니다. 서브에이전트는 일을 다 한 다음에, 과정 전부가 아니라 결과만 돌려줘요. 지난 강의 책상 비유를 다시 가져와 볼게요. 만약 한 세션에 다 쌓으면, 검색하면서 나온 출력, 시행착오, 중간 메모가 전부 오케스트레이터의 책상에 그대로 쌓입니다. 책상이 금방 꽉 차고 흐려지죠.Here comes the truly important point. After a sub-agent finishes its work, it returns only the result — not the entire process. Let me bring back the desk metaphor from last time. If you pile everything into one session, every search output, every trial and error, every interim note stacks right up on the orchestrator's desk. The desk fills and fogs over fast.

그런데 서브에이전트로 격리하면 달라요. 서브에이전트는 자기 책상에서 아무리 길고 지저분하게 일해도, 오케스트레이터한테는 깔끔하게 압축된 결과만 올려보냅니다. 그래서 오케스트레이터의 책상은 깨끗하게 유지돼요. 이게 바로 컨텍스트 격리입니다. 길고 지저분한 작업일수록, 따로 격리해서 결과만 받는 게 유리합니다.But isolating it in a sub-agent changes things. No matter how long and messy the sub-agent's work is on its own desk, it sends up only a clean, compressed result to the orchestrator. So the orchestrator's desk stays clean. This is exactly context isolation. The longer and messier the task, the more it pays to isolate it and take back only the result.

5 · 왜 격리가 이득인가5 · Why isolation pays

그럼 왜 책상이 깨끗한 게 그렇게 중요할까요. 두 번째 강에서 본 그 흐려짐, 기억하시죠. 책상이 차서 흐려지는 것. 주의가 분산되고, 오래된 내용이 지금 하는 일을 방해합니다. 성능이 조금씩 떨어져요. 그게 한 사람한테 다 시킬 때 생기는 문제였는데, 사실 팀에서도 똑같이 일어납니다. 오케스트레이터가 서브에이전트들의 과정을 전부 받으면, 그 책상도 금방 차거든요.So why does a clean desk matter so much? Remember that fogging we saw in lesson two — the desk filling up and getting foggy. Attention scatters, and old material interferes with what you're doing now. Performance degrades a little. That was the problem when you ask one worker to do everything — but the same thing happens in a team too. If the orchestrator receives all the process from every sub-agent, its desk fills up fast as well.

격리는 바로 이 문제를 늦춥니다. 작업을 서브에이전트들로 나누면, 각자의 책상이 작게 유지돼요. 작은 책상에서는 일이 또렷하죠. 그리고 오케스트레이터는 지저분한 과정은 안 받고 결과만 모으니까, 책상이 천천히 찹니다. 그래서 격리는 속도를 위한 게 아니라 품질을 위한 설계예요. 두 번째 강에서 배운 룰 넘버 투, 기억나시죠. 토큰을 아끼지 말고, 컨텍스트를 보호하라. 격리가 바로 그겁니다.Isolation is exactly what delays this problem. When you split work across sub-agents, each desk stays small. On a small desk, the work stays sharp. And since the orchestrator takes in only results, not the messy process, its desk fills slowly. So isolation isn't a design for speed — it's a design for quality. Remember Rule Number Two from early on? Don't save tokens — protect context. Isolation is precisely that.

6 · 병렬 실행 = 속도6 · Parallel execution = speed

팀의 또 다른 이점은 속도입니다. 서로 상관없는 일을 한 줄로 줄 세우면, A 끝나고 B 하고 그다음 C 하느라 시간이 전부 합산돼요. 이게 직렬입니다. 그런데 A, B, C가 서로 상관없는 일이라면, 세 명한테 동시에 맡길 수 있어요. 이걸 병렬, 또는 팬 아웃이라고 부릅니다. 그러면 전체 시간이 셋을 합한 게 아니라, 가장 오래 걸리는 하나에 가까워져요.Another benefit of a team is speed. If you line up unrelated tasks in a single queue — finish A, then B, then C — the times all add up. That's serial. But if A, B, and C are unrelated, you can hand them to three workers at once. We call this parallel, or fan-out. Then the total time isn't the sum of the three — it gets close to the single longest one.

여기서 딱 한 가지 조건이 있어요. 병렬은 서로 의존하지 않는 작업에만 됩니다. 만약 B가 A의 결과를 받아야 시작할 수 있다면, 그건 동시에 할 수가 없죠. 그럴 땐 직렬이 맞습니다. 그리고 정확히 몇 배 빨라진다고 단정하진 마세요. 줄어드는 폭은 일과 환경마다 다르거든요. 핵심은, 일을 맡기기 전에 의존성부터 따져서, 독립적인 것만 동시에 돌린다는 겁니다.There's exactly one condition. Parallel only works for tasks that don't depend on each other. If B can't start until it gets A's result, you can't run them at the same time — then serial is correct. And don't claim a specific speedup multiple. How much it shrinks depends on the task and the environment. The point is: before you assign work, check the dependencies first, and run only the independent ones at once.

7 · 컨텍스트 격리는 어떻게 작동하나7 · How context isolation works

그럼 격리가 정확히 어떻게 작동하는지 들여다볼게요. 각 서브에이전트는 자기만의 책상, 그러니까 자기만의 컨텍스트 윈도우를 가지고 있어요. 검색하다 나온 긴 출력, 이것저것 해본 시행착오, 중간 과정. 이 모든 잡동사니는 그 서브에이전트의 책상 위에서만 처리됩니다. 오케스트레이터의 책상으로는 넘어오지 않아요.So let's look at exactly how isolation works. Each sub-agent has its own desk — its own context window. Long search outputs, all the trial and error, the intermediate steps: all of this clutter is handled only on that sub-agent's desk. None of it crosses over to the orchestrator's desk.

오케스트레이터한테 올라오는 건 압축된 결과뿐이에요. 그러니까 오케스트레이터는 "무엇을" 했는지만 알고, "어떻게"의 시끄러운 잡음은 서브에이전트 안에 갇혀 있는 거죠. 이게 핵심입니다. 과정의 토큰이 메인 책상에 쌓이지 않으니까, 메인은 계속 또렷하게 유지됩니다. 잡음은 안에 가두고, 결과만 위로 흐르게. 이렇게 설계하는 거예요.What rises up to the orchestrator is only the compressed result. So the orchestrator knows just "what" was done, while the noisy "how" stays locked inside the sub-agent. This is the key. Because the process tokens never stack up on the main desk, the main stays sharp. Cage the noise inside, let only the result flow up. That's how you design it.

8 · 생산자-검증자 패턴8 · The producer–verifier pattern

자, 오늘 원리의 심장입니다. 처음 콜드 오픈에서 봤던 문제 중에, 만든 자가 자기 걸 검증한다는 게 있었죠. 글을 쓴 바로 그 일꾼한테 "잘 썼는지 검토해 줘"라고 하면, 사람도 그렇듯이 자기 글의 약점은 잘 안 보입니다. 이걸 자기채점이라고 해요. 편향이 생깁니다.Alright, the heart of today's principle. Among the problems we saw in the cold open, one was the maker verifying its own work. If you ask the very worker that wrote the draft to "review whether it's good," then — just like with people — it can't see the weak spots in its own writing. We call this self-grading, and it creates bias.

그래서 만드는 에이전트와 검증하는 에이전트를 나눕니다. 생산자가 초안을 만들면, 별도의 검증자가 비판적인 눈으로 점검하고, 문제가 있으면 다시 고치게 해요. 이걸 생산자-검증자 패턴이라고 부릅니다. 열한 번째 강에서 배운 "결과를 다시 읽기", 그 검증 루프를 한 단계 더 밀어붙인 거예요. 만든 자 말고, 다른 자에게 검증을 맡긴다. 다만 검증을 얼마나 촘촘한 체계로 설계하느냐, 품질을 어떻게 보장하느냐는 다음 시간에 따로 다룹니다. 오늘은 "검증자를 따로 둔다"까지예요.So we split the agent that makes from the agent that checks. The producer creates the draft, a separate verifier checks it with a critical eye, and if there's a problem, it sends it back to be fixed. We call this the producer–verifier pattern. It's pushing the "re-read the result" verification loop from lesson eleven one step further. Hand verification not to the maker, but to someone else. How elaborately you design that verification system, and how you guarantee quality — that's a separate topic for next time. Today we go only as far as "place a separate verifier."

9 · 하네스 = 팀을 굴리는 대본9 · The harness = the script that runs the team

그런데 이런 팀을 매번 말로 조율하면 너무 번거롭겠죠. "이제 가격 조사해, 됐어? 그럼 설명 초안 작성자한테 줘, 이제 마진 검증해…" 매번 이러면 반복도 안 되고 실수도 생겨요. 여러분이 매번 입으로 '이거 먼저, 그다음 저거' 지시하던 걸, 체크리스트 문서 한 장으로 적어 둔 것 — 그게 하네스입니다. 이 대본을 하네스, 또는 워크플로우 스크립트라고 불러요.But coordinating a team like this by talking every single time would be exhausting. "Now do the price research — done? Then give this to the description drafter — now verify the margin…" Doing this each time can't be repeated and invites mistakes. Instead of saying 'do this first, then that' every time by mouth — you write it all down in one checklist document. That's a harness, or a workflow script.

화면의 장면을 보세요. 가격 조사를 호출해서 경쟁사 가격을 수집하고, 그 데이터를 설명 초안 작성자에게 넘기고, 마진 검증자를 불러서 통과했는지 확인하고, 통과하면 품의 취합을 호출한다. 이렇게 누가, 언제, 무엇을 하는지를 절차로 굳혀 둔 거예요. 핵심은, 조율을 머릿속이나 대화가 아니라 대본에 적는다는 겁니다. 그러면 다음 신상품 입점 때도, 그다음에도 똑같이 돌릴 수 있어요. 지난 강의 "일꾼을 바꾸지 말고 일터를 설계하라"가 여기서도 이어집니다.Look at the scene on screen. Call the price research and collect competitor prices, hand that data to the description drafter, call the margin verifier to check whether it passed, and if it passes, call the proposal compiler. We've frozen who does what and when into a procedure. The point is: you write the coordination into a script, not into your head or a chat. That way, you can run exactly the same process for the next new product onboarding, and the one after that. Last time's "don't swap the worker, design the workplace" carries straight through here.

10 · 하네스 설계 4원칙10 · Four principles of harness design

그럼 좋은 하네스는 무엇을 정해 둘까요. 네 가지입니다. 첫째, 역할 분리. 누가 무엇을 맡는지 정합니다. 지난 시간에 잘 설계한 단일 에이전트가 여기서 팀 구성원으로 들어와요. 둘째, 인터페이스. 각 서브에이전트가 무엇을 입력받고 무엇을 반환하는지, 결과 계약을 명확히 해야 합니다. 이게 명확해야 돌아온 결과를 안전하게 합칠 수 있어요.So what does a good harness pin down? Four things. One: role split — decide who takes what. The single agent you designed well last time enters here as a team member. Two: interface — be clear about what each sub-agent takes as input and what it returns, the result contract. Only when this is clear can you safely combine the results that come back.

셋째, 검증 게이트. 아까 본 생산자-검증자를 어느 지점에 끼울지 정합니다. 넷째, 중단과 실패 처리. 막히면 어디서 멈추고 사람에게 넘길지를 미리 정해 둬요. 이건 지난 시간에 배운 중단 조건의 팀 버전입니다. 이 네 가지, 역할 분리, 인터페이스, 검증 게이트, 중단과 실패 처리. 이걸 대본에 적어 두면, 팀이 매번 같은 방식으로 안정적으로 굴러갑니다.Three: the verification gate — decide where to slot in that producer–verifier we just saw. Four: stop and failure handling — decide in advance where to halt and hand off to a human when it gets stuck. This is the team version of the stop conditions you learned last time. These four — role split, interface, verification gate, and stop-and-failure handling — once you write them into the script, the team runs the same stable way every time.

11 · 팀을 짜기 전 5점검11 · Five checks before you build a team

자, 오늘의 핵심입니다. 팀을 짜기 전에 다섯 가지만 점검하세요. 첫째, 이거 정말 나눌 일인가? 팀에는 조율 비용이 들어요. 작고 단순한 일이면 그냥 혼자 하는 게 빠릅니다. 둘째, 독립적인 작업이 있나? 서로 상관없으면 병렬로 동시에, 의존하면 직렬로. 셋째, 결과 계약을 정했나? 각 서브에이전트가 뭘 받고 뭘 돌려줄지를 명확히 해 두세요.Alright, here's the core insight. Before you assemble a team, check just five things. One: is this really worth splitting? A team has coordination cost. If the job is small and simple, doing it solo is faster. Two: are there independent tasks? If they're unrelated, run them in parallel; if they depend on each other, serial. Three: did you set the result contract? Be clear about what each sub-agent takes in and what it returns.

넷째, 검증자를 따로 뒀나? 만든 자가 자기 걸 채점하지 않도록, 별도의 검증자를 둡니다. 다섯째, 막히면 어디서 멈출지를 대본에 적었나? 중단과 실패 처리를 미리 정해 두세요. 여기서 정말 중요한 건, 팀은 많이 부른다고 좋은 게 아니라는 점이에요. 나눌 가치가 있을 때 설계하는 겁니다. 작은 일은 혼자, 크고 독립적이고 검증이 필요한 일은 팀으로. 이게 룰 넘버 포틴의 진짜 핵심입니다.Four: did you place a separate verifier? So the maker doesn't grade its own work, put a separate verifier in. Five: did you write into the script where it stops when stuck? Decide your stop-and-failure handling in advance. Here's what really matters: a team isn't better just because you call more agents. You design it when it's worth splitting. Small jobs solo; big, independent, verification-needing jobs as a team. That's the real heart of Rule Number Fourteen.

12 · 팀 설계를 한 줄 행동으로12 · Team design in one line

다섯 가지를 한 줄로 굳혀 볼게요. 나눌 가치가 있으면, 격리하고, 독립 작업은 병렬로 돌리고, 검증자를 따로 두고, 막힐 때 멈출 지점을 정해서, 이걸 전부 대본에 적어 반복한다. 오늘 배운 게 사실 앞에서 쌓아온 규칙들이 만나는 지점이에요. 컨텍스트를 지켜라가 격리로, 작은 일들로 쪼개라가 분할로, 환경을 설계하라가 단일 에이전트로, 그리고 오늘의 팀을 만들어라가 조율로. 팀을 설계할 줄 알면, 무엇을 나누고 무엇을 합칠지가 자동으로 보입니다.Let me lock the five into one line. If it's worth splitting, isolate it, run independent tasks in parallel, place a separate verifier, decide where it stops when stuck — and write all of it into a script to repeat. What you learned today is actually where the rules we've been stacking up all meet. Protect context becomes isolation, break it into small tasks becomes splitting, design the environment becomes the single agent, and today's build a team becomes coordination. Once you know how to design a team, what to split and what to combine becomes obvious on its own.

13 · 혼자 떠안기 vs 팀으로 나누기13 · Solo vs team — the comparison

맨 처음 콜드 오픈에서 봤던 그 장면, 한 명한테 다 시켰던 거 기억나시죠. 이제 결론으로 돌려받아 볼게요. 혼자 다 떠안으면 컨텍스트가 흐려지고, 자기가 만든 걸 자기가 채점하고, 일이 직렬로 줄을 서서 느립니다. 반대로 팀으로 나누면 어떻게 될까요. 격리 덕분에 각자 또렷하게 일하고, 검증이 분리돼서 약점이 보이고, 독립적인 일은 병렬로 돌아서 빠릅니다.That scene from the very first cold open, where we piled it all on one — remember? Now let's take it back as our conclusion. Carry it all solo, and context fogs over, it grades its own work, and tasks queue up serially and run slow. Split into a team, and what happens? Thanks to isolation, each works sharply; verification is separated, so the weak spots show; and independent tasks run in parallel and fast.

그러니까 좋은 결과는 더 똑똑한 한 명에서 나오는 게 아니라, 잘 나뉜 팀에서 나옵니다. 다만 한 가지만 잊지 마세요. 작은 일까지 굳이 팀으로 만들면 조율 비용만 늘어요. 나눌 가치가 있을 때, 그때 팀을 만드는 겁니다.So good results don't come from a smarter single worker — they come from a well-split team. Just don't forget one thing: forcing even small jobs into a team only adds coordination cost. When it's worth splitting — that's when you build the team.

14 · 마무리 — Rule No.1414 · Closing — Rule No.14

오늘 한 단어, 아니 네 단어만 가져가신다면 이겁니다. 나눔, 격리, 검증, 그리고 대본. 나눌 가치가 있으면 나누고, 컨텍스트는 격리하고, 검증은 만든 자 말고 다른 자에게 맡기고, 이 조율을 대본에 적는다. 그런데 사실 한 가지 고백할 게 있어요. 여러분이 방금 본 이 강의 자체가, 바로 멀티에이전트와 하네스의 결과물입니다.If you take one word — no, four words — from today, it's these: split, isolate, verify, and script. Split when it's worth splitting, isolate the context, hand verification to someone other than the maker, and write that coordination into a script. But there's actually something to confess. This very lesson you just watched is itself the product of multi-agents and a harness.

이 코스는 조율하는 오케스트레이터 한 명과, 일곱 개의 전문 팀으로 만들어졌어요. 구조를 감독하는 팀, 집필하는 팀, 슬라이드를 만드는 팀, 팩트를 체크하는 팀, 발음을 검수하는 팀, 음성을 다루는 팀, 그리고 다국어를 맞추는 팀. 게다가 심화 리서치는 멀티에이전트 리서치 하네스로 했습니다. 검색을 팬 아웃으로 펼쳐서 출처를 모으고, 적대적으로 검증하고, 인용을 종합하는 방식이죠. 우리가 오늘 가르친 그대로 만든 거예요. 자, 팀을 굴리는 법을 배웠으니, 다음 시간엔 그 결과물의 품질과 신뢰를 어떻게 설계하는지를 다룹니다. 룰 넘버 피프틴, 신뢰는 설계하는 것이다.This course was built by one coordinating orchestrator and seven specialist teams: a team that supervises structure, a team that writes, a team that builds slides, a team that fact-checks, a team that reviews pronunciation, a team that handles audio, and a team that aligns the languages. On top of that, the deep research was done with a multi-agent research harness — fanning searches out, gathering sources, verifying adversarially, and synthesizing the citations. We built it exactly the way we taught today. Now that you've learned how to run a team, next time we'll cover how to design the quality and trust of what it produces. Rule Number Fifteen: trust is something you design.