1 · RULE No.101 · Opening — Rule No.10

산을 한 번에 옮길 순 없습니다. 그런데 돌 하나씩은 옮길 수 있죠. 9강에서 우리는 큰 일을 작은 조각으로 쪼개 적는 법을 배웠습니다. 오늘은 그 조각들을 실제로 한 번에 하나씩 맡기고, 끝까지 완주시키는 법을 다룹니다. 할 일 목록 체크박스 플랜, 중간 검증, 컨텍스트가 찰 때 대응, 에이전트에게 넘기기, 그리고 실패했을 때 되살리는 법까지요. 룰 넘버 텐, 큰 일이 아니라 작은 일들을 줘라.You can't move a mountain all at once. But you can move it one stone at a time. In Session 9 we learned how to split a big job into small pieces and write them down. Today we cover how to actually hand those pieces off one at a time and run them to completion — the to-do list checkbox plan, mid-task verification, what to do when the context fills up, handing pieces off to an agent, and how to recover when it stalls. Rule Number Ten: give it small tasks, not one big one.

2 · 쪼갰는데 통째로 던지면2 · Hook — You split it, then dumped it whole

9강에서 우리는 큰 일을 검증 가능한 작은 조각으로 쪼개 적는 법을 배웠죠. 그래서 다섯 조각으로 잘 나눠 놨습니다. 카테고리 정리, 재고 집계, 매출 보고서 작성, KPI 검증, 최종 보고. 그런데 여기서 "이 다섯 개 다 해줘" 하고 한 덩어리로 던지면 어떻게 될까요? Claude는 멈추지 않고 일, 이, 삼번을 쭉 해 나갑니다. 그러다 네 번째 조각에서 가정이 틀린 걸 발견해요.In Session 9 we learned how to split a big job into small, verifiable pieces. So we've nicely cut it into five: category cleanup, inventory tally, sales report, KPI check, final submission. But then we dump all five as one lump — "do all five." What happens? Claude doesn't stop; it rolls straight through one, two, three. And then, on the fourth piece, it discovers an assumption was wrong.

문제는 여기서부터예요. 어디까지 했는지를 머릿속, 그러니까 컨텍스트에만 들고 있었기 때문에, 대화가 길어진 지금은 그게 흐려져 있습니다. "음, 어디까지 했더라…" 하면서 절반만 끝낸 채 헤매요. 쪼갠 보람도 없이, 똑똑할수록 자신 있게 길을 잃습니다. 핵심은 이겁니다. 문제는 분해가 아니라, 실행하는 방식이에요. 그래서 오늘은 통째 실행에서, 한 번에 하나씩 그리고 진행을 밖에 적기로 바꿔봅니다.And here's where it breaks down. Because it held "where am I" only in its head — in the context — and the conversation has now run long, that memory has gone foggy. "Hmm, where was I…" — and it wanders, half-finished. All that splitting wasted, and the smarter it is, the more confidently it loses its way. Here's the key: the problem isn't the decomposition, it's the way you execute. So today we switch from running it all at once to one at a time, with progress kept outside.

3 · 통째로 던지면 잃는 3가지3 · Three things you lose running it all

통째로 던지면 정확히 세 가지를 잃습니다. 첫째, 진행 상태예요. 어디까지 했는지를 머릿속, 그러니까 컨텍스트에만 두면, 대화가 길어질수록 흐려져서 끝난 걸 또 하거나 빠뜨립니다. 둘째, 검증 시점입니다. 중간에 멈춰서 확인하지 않으면, 네 번째 조각이 틀려도 모른 채로 다섯 번째, 여섯 번째를 그 위에 쌓아요. 그래서 틀린 걸 늦게, 비싸게 발견합니다.Dump it all at once and you lose exactly three things. First, progress. If "where am I" lives only in its head — in the context — it fades as the conversation grows, so it redoes finished work or drops pieces. Second, verify points. If it never stops mid-task to check, then even when the fourth piece is wrong, it stacks the fifth and sixth on top, unaware. So the mistake gets caught late, and expensively.

셋째, 완주입니다. 한 번에 다 하려다 보면 큰 덩어리는 끝맺기가 어려워서, 절반만 하고 멈추기 쉬워요. 여기서 중요한 건, 이게 Claude의 버그가 아니라는 점입니다. 한꺼번에 시킨 결과예요. 그러니 해법도 분명합니다. 한 번에 하나씩 하고, 진행은 밖에 적고, 조각마다 검증한다. 오늘 강의는 이 세 문장을 풀어가는 겁니다.Third, completion. Trying to do it all at once, a big lump is hard to finish, so it tends to stop halfway. And here's what matters: this isn't a Claude bug. It's the result of asking for it all at once. So the fix is just as clear — do one at a time, keep progress outside, and verify each piece. Today's whole talk is unpacking those three sentences.

4 · 실행의 단위4 · The unit of execution

분해는 9강에서 끝냈습니다. 검증 가능하게, 독립적으로, 적당한 크기로 쪼개는 기준은 9강 소관이고요. 오늘 핵심은 분해가 아니라 실행 단위예요. 좋은 실행은 이렇게 흐릅니다. 쪼갠 조각 하나를 맡기고, 그게 됐는지 확인하고, 그다음 조각으로 넘어간다. 그리고 이걸 반복하죠.The decomposition was finished in Session 9. The criteria for splitting — verifiable, independent, right-sized — belong to Session 9. Today's focus isn't decomposition, it's the unit of execution. Good execution flows like this: hand off one split piece, check that it worked, then move to the next piece. And repeat.

Claude Code는 이렇게 작업을 여러 단계로 나눠 진행하는 워크플로를 지원합니다. 정확한 도구 이름이나 동작은 버전마다 바뀌니까, 발표 시점의 공식 문서가 진실이에요. 우리가 외울 건 메커니즘입니다. 큰 일 하나를 통째로 던지는 게 아니라, 작은 일들을 순서대로. 이 한 번에 하나씩이 바로 룰 넘버 텐의 동작하는 형태입니다.Claude Code supports this kind of workflow — breaking work into multiple steps and progressing through them. The exact tool names and behaviors change version to version, so the official docs at presentation time are the truth. What we memorize is the mechanism: not one big job dumped whole, but small tasks in order. This "one at a time" is exactly what Rule Number Ten looks like in action.

5 · 할 일 목록 도구 — 체크박스 플랜5 · The to-do list — checkbox plan

그래서 등장하는 게 할 일 목록 도구입니다. 화면처럼, 도구명은 투두 라이트나 투두 리스트 같은 형태인데, 이것도 제품 기능이라 버전마다 바뀝니다. 발표 시점 공식 문서가 진실이에요. 동작은 단순합니다. Claude가 큰 일을 받으면 먼저 할 일 목록을 적고, 한 번에 하나만 진행 중으로 두고, 끝나면 체크 표시를 한 다음 다음으로 넘어가요.So here comes the to-do list tool. As on screen, the tool name takes a form like To-do-Write or To-do-List — and this too is a product feature that changes by version. The official docs at presentation time are the truth. The behavior is simple: when Claude takes a big job, it first writes a to-do list, keeps only one item in progress at a time, and once that's done, checks it off and moves to the next.

여기서 핵심은 이 목록이 어디에 있느냐예요. 진행 상태를 대화 흐름, 그러니까 머릿속에 두는 게 아니라 목록이라는 도구 안에 빼서 적어두는 겁니다. 2강에서 본 점진적 공개의 실행판이라고 보시면 돼요. 진행을 밖에 적으면, 대화가 아무리 길어져도 끝난 걸 또 하거나 빠뜨리지 않고, 길을 잃지 않습니다. 그래서 큰 일은 시작하자마자 먼저 체크박스 플랜으로 만드는 게 첫걸음이에요.The key here is where this list lives. Progress isn't kept in the conversation flow — in its head — it's pulled out and written into a tool, the list. Think of it as the execution version of progressive disclosure from Session 2. Write progress outside, and no matter how long the conversation runs, it won't redo or drop finished work, and it won't lose its way. So the first step with a big job is, right away, to turn it into a checkbox plan.

6 · 한 번에 하나씩 + do-verify 루프6 · One at a time + do-verify loop

왼쪽이 통째 실행입니다. 일번부터 오번까지 멈추지 않고 쭉 달려요. 그러다 보면 사 번 조각이 틀렸어도 모른 채로 오 번을 그 위에 쌓습니다. 오른쪽이 우리가 원하는 모습이에요. 실행하고 검증하는 반복, 두 베리파이 루프입니다. 조각 하나를 끝낼 때마다 멈춰서 "이 조각, 제대로 됐나?"를 확인해요. 테스트를 돌리든, 출력을 눈으로 보든, 사람이 검토하든요.On the left is running it all. It races from one through five without stopping. So even when piece four is wrong, it stacks five on top, unaware. On the right is what we want — the do–verify loop. Each time it finishes a piece, it stops and checks, "did this piece actually work?" — by running a test, eyeballing the output, or having a human review it.

핵심 차이는 한 줄이에요. 틀린 조각 위에 더 쌓기 전에 멈춘다. 기억하실 게, 우리는 9강에서 각 조각을 검증 가능하게 쪼개 놨습니다. 그러니 조각마다 멈춰서 확인하면, 틀린 가정을 코드로 더 굳히기 전에 바로 잡을 수 있어요. 이게 이전 강의들에서 본 검증 가능한 일에 강하다는 원리를 실행 중에 살리는 방법입니다. 그래서 실행은 한 번에 하나씩, 실행–검증 루프로.The key difference is one line: stop before stacking on a wrong piece. Remember, in Session 9 we split each piece to be verifiable. So if it stops to check each piece, it can catch a wrong assumption before hardening it into more code. This is how you keep alive, during execution, that principle from earlier — strong on verifiable work. So execute one at a time, in a do–verify loop.

7 · 진행 상태를 도구가 들고 있다7 · The tool holds the progress

할 일 목록이 왜 그렇게 강력한지를 한 번 더 짚어볼게요. 진행 상태를 대화창, 그러니까 컨텍스트가 들고 있는 게 아니라 목록이라는 도구가 들고 있으면 두 가지가 가능해집니다. 첫째, 대화가 아주 길어져서 앞부분이 흐려져도, 남은 할 일은 목록에 그대로 남아 있어요. 둘째, 컨텍스트를 정리하거나 아예 새 세션을 열어도, 어디까지 했는지를 목록에서 복원할 수 있습니다.Let me underline once more why the to-do list is so powerful. When progress is held not by the chat window — the context — but by a tool, the list, two things become possible. First, even if the conversation runs so long that the early part goes foggy, the remaining tasks stay right there in the list. Second, even if you clean up the context or open a brand-new session, you can restore where you were from the list.

이건 지난 강에서 본 원리 그대로예요. 컨텍스트는 유한하니까, 오래 들고 있어야 할 상태는 머릿속이 아니라 밖에 둔다. 그래서 할 일 목록을 Claude의 외장 메모리라고 부르는 겁니다. 한 가지 경계를 둘게요. 도구가 정확히 어떻게 동작하는지, 다른 도구는 뭐가 있는지는 다음 강 소관입니다. 오늘은 진행을 밖에 두는 흐름까지만요.This is exactly the principle from an earlier session. The context is finite, so state you need to hold for a long time goes outside, not in its head. That's why we call the to-do list Claude's external memory. Let me set one boundary: exactly how the tool works, and what other tools exist, belongs to the next session. Today we go only as far as the flow of keeping progress outside.

8 · 작은 단위 실행이 비용을 줄이는 3원리8 · Three reasons small units cut cost

그럼 왜 작은 단위 실행이 통할까요? 세 가지 효과가 각각 다른 낭비를 막기 때문입니다. 첫째, 조각마다 검증하면 빠른 발견이 됩니다. 틀린 조각을 바로 잡아서 그 위에 더 못 쌓게 하죠. 지난 강에서 본 검증 가능성이 여기서 살아납니다. 둘째, 체크박스 플랜은 길 안 잃기예요. 진행이 컨텍스트 밖에 있으니까, 대화가 길어져도 끝난 걸 또 하거나 빠뜨리지 않습니다. 컨텍스트 보호, 점진적 공개와 정확히 이어지죠.So why does small-unit execution work? Because three effects each block a different kind of waste. First, verifying each piece gives you fast detection. You catch a wrong piece right away so nothing else gets stacked on it — the verifiability from earlier comes alive here. Second, the checkbox plan means no getting lost. Because progress lives outside the context, even a long conversation won't redo or drop finished work. This connects exactly to context protection and progressive disclosure.

셋째, 작은 조각은 쉬운 복구입니다. 어디서 멈춰도 남은 체크박스에서 이어 하면 돼요. 통째로 던졌다면 어디부터 다시 해야 할지조차 모르죠. 정리하면, 작은 단위는 늦은 발견, 길 잃기, 복구 불가, 이 세 가지 낭비를 실행 중에 막아주는 겁니다. 이 셋이 합쳐져서 통째 질주를 끝까지 완주로 바꿔요. 그래서 작은 일들로 나눠야 실행이 싸집니다.Third, small pieces mean easy recovery. Wherever it stalls, you just resume from the remaining checkboxes. Dump it all at once and you don't even know where to restart. To sum up: small units block three wastes during execution — late detection, getting lost, and no way to recover. Together, the three turn an all-at-once sprint into running it to completion. That's why splitting into small tasks makes execution cheaper.

9 · 컨텍스트가 찰 때 — 정리하고 이어 달리기9 · When the context fills — clean up and keep running

긴 실행을 하다 보면 컨텍스트가 차오릅니다. 컨텍스트 윈도우는 유한하니까요. 이때 세 가지로 대응합니다. 이건 지난 강에서 본 컨텍스트 보호를 실행 중에 적용하는 거예요. 첫째, 요약입니다. 지금까지의 결정과 진행을 짧게 압축해서 다시 적고, 장황한 중간 과정은 버려요. 둘째, 도구 출력 정리입니다. 이미 끝난 조각의 큰 도구 출력은 결론만 남기고 비웁니다.During a long run, the context fills up — the context window is finite. When it does, you respond in three ways. This is applying the context protection from earlier, but during execution. First, summarize: compress the decisions and progress so far into something short, and drop the verbose middle. Second, clear tool results: for already-finished pieces, keep only the conclusion from their big tool outputs and empty the rest.

셋째, 새 세션을 열고 인계하는 겁니다. 너무 흐려지기 전에 새 세션을 시작하고, 남은 할 일 목록을 그대로 넘겨요. 앞에서 본 외장 메모리가 바로 여기서 빛납니다. 핵심 차이는 이 한 줄이에요. 진행은 밖에 적혀 있으니, 컨텍스트는 비워도 된다. 참고로 자동으로 정리하거나 요약하는 기능, 자동 압축·정리, 영어로는 컴팩션이라고 부르는데, 정확한 동작과 명칭은 버전마다 다르니 발표 시점 공식 문서가 진실입니다.Third, open a new session and hand off. Start a fresh session before it gets too foggy, and carry over the remaining to-do list as is. The external memory we saw earlier shines right here. The key difference is this one line: progress is written outside, so the context can be cleared. By the way, the feature that auto-cleans or auto-summarizes — often called auto-compaction — has exact behavior and naming that differ by version, so the official docs at presentation time are the truth.

10 · 에이전트에게 넘기기10 · Delegating to an agent

모든 조각을 직접 한 번에 하나씩 할 필요는 없습니다. 여기서 분기가 생겨요. 왼쪽, 직접 하는 게 맞는 경우는 조각이 작거나, 조각들이 서로 얽혀서 순서가 중요하거나, 사람이 중간중간 검증해야 할 때입니다. 오른쪽, 서브에이전트(메인 대화와 분리된 별도 일꾼)에게 위임하는 게 맞는 경우는 조각이 크고 독립적이라 별도 컨텍스트에서 통째로 돌릴 만하고, 결과만 받아서 검증하면 되고, 메인 대화의 컨텍스트를 아끼고 싶을 때예요.You don't have to do every piece yourself, one at a time. Here a fork appears. On the left, doing it yourself fits when the piece is small, when pieces are interlocked so order matters, or when a human has to verify along the way. On the right, delegating to a subagent fits when the piece is big and independent enough to run whole in its own context, when you just receive and verify the result, and when you want to spare the main conversation's context.

위임이라는 건 조각 하나를 컨텍스트째 통째로 떼어서 주는 거예요. 그러면 메인 대화는 가볍게 유지되죠. 컨텍스트 보호, 그리고 지난 강에서 독립적으로 쪼갠 조각과 정확히 맞물립니다. 한 가지 경계를 분명히 할게요. 에이전트를 어떻게 설계하고 구성하느냐는 다음 강들 소관입니다. 오늘은 언제 넘기느냐, 그 실행 패턴까지만이에요. 자, 그럼 다음은 멈췄을 때 어떻게 되살리느냐입니다.Delegation means lifting one piece off whole, with its own context, and handing it over. That keeps the main conversation light. It locks in exactly with context protection and the independently-split pieces from the previous session. Let me make one boundary clear: how you design and configure an agent belongs to later sessions. Today we go only as far as when to hand off — the execution pattern. So, next: how to recover when it stalls.

11 · 실패 복구 패턴11 · Recovery pattern

실행은 멈출 수 있습니다. 중요한 건 멈췄을 때 어떻게 되살리느냐예요. 왼쪽은 무너지는 복구입니다. "전부 다시 해줘" 하면서 처음부터 다시 시키는 거죠. 그러면 이미 끝난 것도 또 하고, 컨텍스트만 더 태웁니다. 오른쪽이 이어 하는 복구예요. 첫째, 남은 할 일 목록을 먼저 봅니다. 어디까지 완료 표시가 됐는지 확인해요. 둘째, 막힌 그 조각만 더 작게 다시 쪼개거나 가정을 고칩니다.Execution can stall. What matters is how you recover when it does. On the left is collapsing recovery — "redo everything," starting over from scratch. That redoes already-finished work and just burns more context. On the right is resuming recovery. First, look at the remaining to-do list — check how far the done-marks go. Second, take only the stuck piece and re-split it smaller, or fix the assumption.

셋째, 컨텍스트가 흐려졌으면 요약하거나 새 세션을 열어서 정리하고, 남은 체크박스만 인계합니다. 넷째, 거기서부터 다시 한 번에 하나씩 재개해요. 핵심 차이는 한 줄입니다. 복구의 핵심은, 어디까지 했는지가 밖에 적혀 있는 것. 진행을 밖에 적어둔 보람이 바로 여기서 나옵니다. 그러니 실패는 되돌리기가 아니라 이어 하기예요.Third, if the context has gone foggy, summarize or open a new session to clean up, and hand off only the remaining checkboxes. Fourth, resume from there, one at a time again. The key difference is one line: recovery works because where you got to is written outside. The payoff of keeping progress outside shows up right here. So failure isn't undoing — it's continuing.

12 · 실행 5체크12 · Five execution checks

자, 오늘의 완성형입니다. 실행할 때 다섯 가지만 지키면, 중간에 멈추지 않습니다. 첫째, 체크박스 플랜을 먼저 적었나? 큰 일은 무조건 할 일 목록으로 시작해서 진행을 밖에 둡니다. 둘째, 한 번에 하나씩인가? 여러 조각을 동시에 던지지 말고, 한 조각만 진행 중으로 두세요. 셋째, 조각마다 검증했나? 다음으로 가기 전에 실행하고 검증하는 루프를 돌려서, 틀린 채로 멀리 가지 않게 합니다.Alright, today's peak. While you run it, keep just five things and it won't stall halfway. One: did you write the checkbox plan first? Always start a big job as a to-do list, keeping progress outside. Two: one at a time? Don't dump several pieces at once — keep only one piece in progress. Three: did you verify each piece? Run the do–verify loop before moving on, so you don't travel far while wrong.

넷째, 컨텍스트가 차면 정리했나? 요약하고, 도구 출력을 정리하고, 필요하면 새 세션을 열되 진행은 목록에 인계합니다. 다섯째, 넘길 일인가 직접 할 일인가? 크고 독립적이면 에이전트에게 넘기고, 작고 서로 얽혔으면 직접 하세요. 여기서 중요한 경고가 하나 있습니다. 작고 단순한 일까지 플랜을 만들고 위임하면 그건 과잉 관리예요. 재밌는 건, 이 다섯 가지가 앞에서 본 원리와 하나씩 정확히 짝을 이룬다는 겁니다. 그래서 원리를 알면, 이 체크리스트는 저절로 외워져요.Four: did you clean up when the context filled? Summarize, clear tool outputs, and open a new session if needed — but hand off progress in the list. Five: hand off or do it yourself? Big and independent goes to an agent; small and interlocked, do it yourself. And here's one important warning: making a plan and delegating even for small, simple jobs is over-management. The fun part is, these five map one by one onto the principles we saw earlier. So once you know the principles, this checklist memorizes itself.

13 · 한 줄 공식13 · One-line formula

다섯 가지를 한 줄 공식으로 정리해볼게요. 실행은, 진행을 밖에 적고, 한 번에 하나씩 하고, 조각마다 검증하고, 컨텍스트가 차면 정리해서 인계하고, 크고 독립적이면 위임한다. 그러면 통째 질주가 아니라 끝까지 완주가 됩니다. 단, 한 가지만 잊지 마세요. 작고 단순해서 한 줄로 끝낼 일까지 플랜을 만들고 위임하면, 그건 과잉 관리예요. 룰 넘버 나인 시작 전에 설계하라와, 오늘의 룰 넘버 텐이 바로 여기서 만납니다. 쪼갠 조각을 실제로 한 번에 하나씩 실행하는 거죠. 원리를 알면, 무엇을 밖에 적고 무엇을 넘길지가 보입니다.Let me lock the five into one formula. Execution is: keep progress outside, do one at a time, verify each piece, clean up and hand off when the context fills, and delegate if a piece is big and independent. Then it's not an all-at-once sprint — it's running to completion. But don't forget one thing: planning and delegating even a small, simple job you could finish in one line — that's over-management. Rule Number Nine, design before you start, and today's Rule Number Ten meet right here: you actually run the split pieces, one at a time. Once you know the principles, you can see what to write outside and what to hand off.

14 · 닫으며 — Rule No.1014 · Closing — Rule No.10

오늘 한 단어만 가져가신다면, 한꺼번에 다, 에서 한 번에 하나씩, 입니다. 산은 한 번에 못 옮겨도 돌 하나씩은 옮길 수 있어요. 큰 일을 통째로 던지지 말고, 작은 일들을 한 번에 하나씩, 진행은 밖에 적고, 조각마다 검증하세요. 그러면 끝까지 완주합니다. 다음 시간에는 Claude Code 도구 마스터입니다. 말로 일일이 시키지 말고, 도구를 써라. 그 이야기를 들고 다시 오겠습니다.If you take one word from today, it's: from all at once to one at a time. You can't move the mountain in one go, but you can move it one stone at a time. Don't dump a big job whole — give it small tasks one at a time, keep progress outside, and verify each piece. Then it runs to completion. Next time: mastering the Claude Code tools. Don't spell everything out in words — use the tools. I'll be back with that story.