1 · RULE No.91 · Opening — Rule No.9

솜씨 좋은 목수는 톱을 들기 전에 먼저 도면을 그립니다. 한 번 자른 나무는 되돌릴 수 없으니까요. 똑똑한 Claude에게 바로 "이거 만들어줘"라고 하면, 빠르게 시작은 합니다. 그런데 틀린 가정 위에 빠르게 쌓아 올리죠. 오늘은 룰 넘버 나인, "시작 전에 설계하라"를 가지고, 브레인스토밍에서 설계, 구현으로 이어지는 순서와, 이걸 제품 차원에서 강제하는 플랜 모드, 스펙 문서, 파일 맵, 태스크 분해를 살펴보겠습니다.A skilled carpenter draws the plan before lifting the saw — because a cut board can't be uncut. When you tell a smart Claude "just build this," it does start fast. But it builds fast on top of wrong assumptions. Today, under Rule Number Nine — "design before you start" — we'll walk through the order that runs from brainstorming to design to build, and the things that enforce it at the product level: Plan mode, the spec document, the file map, and task decomposition.

2 · 전문가인데 왜 바로 시키면 헤맬까2 · Expert, but why does it stray when told to start?

지난 강까지 우리는 Claude에게 무엇을 아는지를 잘 정리해 줬죠. 역할로, 절차로, 코드 진실로 지식을 구조화해서, 박학한 신입을 분야 전문가로 만들었습니다. 그런데 그 전문가에게 설계도도 없이 그냥 "이거 만들어줘"라고 던지면 어떻게 될까요? 똑똑할수록, 오히려 자신 있게 엉뚱한 방향으로 달려갑니다.Up through the last session, we organized what Claude knows. We structured its knowledge into roles, procedures, and code truth, turning a well-read novice into a domain expert. But what happens when you hand that expert a bare "just build this," with no plan? The smarter it is, the more confidently it sprints in the wrong direction.

장면을 하나 볼게요. "이거 만들어줘" 한 줄을 던지자, Claude가 멈추지 않고 파일을 만들고, 고치고, 또 고칩니다. 그러다 한참 뒤에 "아, 제가 가정한 구조가 요구와 달랐네요" 하면서 되돌리기 시작해요. 빠르게 질주했는데, 늦게야 방향이 틀린 걸 발견한 거죠. 문제는 능력이 아니라, 시작하는 순서입니다. 이 되돌림이 곧 낭비한 컨텍스트고, 낭비한 토큰이고, 틀어진 방향이에요. 오늘은 바로 시키기에서, 먼저 설계하기로 넘어가 봅니다.Let's look at one scene. You toss in "just build this," and Claude — without pausing — creates files, edits them, edits them again. Then, much later, it says "ah, the structure I assumed didn't match the requirement," and starts reverting. It sprinted fast, but only discovered the wrong direction late. The problem isn't capability — it's the order of starting. That reverting is wasted context, wasted tokens, a derailed direction. Today we move from "just tell it" to "design first."

3 · 설계 없이 시작하면 잃는 3가지3 · Three things you lose without a design

설계 없이 바로 시작하면, 크게 세 가지를 잃습니다. 첫째, 방향이에요. 맨 처음 가정이 틀리면, 그 위에 쌓아 올린 코드가 통째로 흔들립니다. 그리고 이 틀린 가정은 늦게 발견할수록 비싸요. 둘째, 컨텍스트입니다. 질주하다 되돌리고, 다시 작업하는 과정이 대화창을 가정과 시도와 번복으로 가득 채워서, 우리가 그렇게 지키려던 컨텍스트를 태워버립니다. 룰 넘버 투를 떠올려 보세요.Start without a design and you lose three things. First, direction. If the very first assumption is wrong, all the code stacked on top of it shakes. And that wrong assumption gets more expensive the later you find it. Second, context. Sprinting, reverting, then reworking fills the chat with assumptions, attempts, and reversals — burning the very context we worked so hard to protect. Think back to Rule Number Two.

셋째는 합의입니다. "알아서 잘 만들어줘"라고만 하면, 무엇을 만들지를 글로 못 박은 적이 없으니까, 사람과 Claude가 서로 머릿속에 다른 그림을 그린 채로 진행하게 돼요. 정리하면, 이건 버그가 아닙니다. 순서 없이 시작한 결과예요. 그래서 해법도 분명합니다. 코딩하기 전에, 의도와 설계를 먼저 맞추는 거죠.Third, alignment. If you only say "make something good," you've never pinned down in writing what to build — so you and Claude proceed with different pictures in your heads. To sum up: this isn't a bug. It's the result of starting without an order. So the fix is clear too — align on intent and design before you code.

4 · 설계의 3단계 — 브레인스토밍 → 설계 → 구현4 · Three stages of design — brainstorm → design → build

그럼 시작은 어떤 순서여야 할까요? 세 단계입니다. 브레인스토밍, 설계, 그리고 구현. 첫 단계 브레인스토밍에서는 무엇을, 왜, 그리고 어떤 선택지가 있는지를 활짝 펼칩니다. 두 번째 설계 단계에서는 무엇을 만들지, 어디에 둘지, 어떤 순서로 갈지를 스펙과 파일 맵으로 못 박아요. 마지막 구현에서야, 합의된 설계대로 코드를 씁니다.So what order should starting follow? Three stages: brainstorm, design, then build. In the first stage, brainstorming, you spread out what, why, and which options exist. In the second, design, you pin down what to build, where to put it, and in what order — using a spec and a file map. Only in the last stage, the build, do you write code, per the agreed design.

여기서 핵심은 두 가지예요. 하나, 앞의 두 단계는 말과 글이라는 싼 매체에서 진행하고, 비싼 매체인 코드는 합의가 끝난 뒤에 손댑니다. 둘, 세 단계를 절대 섞지 마세요. 브레인스토밍하면서 코드를 짜기 시작하면, 다시 첫 슬라이드의 그 질주로 돌아가는 겁니다. 참고로 Claude Code에는 코드를 바로 고치기 전에 계획부터 세우게 하는 워크플로가 있는데요, 그 정확한 이름과 동작은 발표 시점의 공식 문서가 진실입니다. 지금은 2026년 6월 기준이에요.Two things matter here. One: run the first two stages in the cheap media of talk and text, and only touch the costly medium — code — after agreement is done. Two: never mix the three stages. The moment you start coding while brainstorming, you're back to that sprint from the first slide. By the way, Claude Code has a workflow that makes it plan before editing code directly — but its exact name and behavior are whatever the official docs say at the time you present. This is as of June twenty twenty-six.

5 · Plan 모드 — 설계를 강제하는 장치5 · Plan mode — the device that enforces design-first

이 "설계 먼저"를 제품 차원에서 강제해 주는 장치가 있습니다. 바로 플랜 모드예요. 왼쪽 비포를 보면, 일반 모드에서 "만들어줘"라고 하면 Claude가 곧장 파일을 고치기 시작합니다. 우리가 본 그 질주죠. 오른쪽 애프터를 보면, 시프트 탭으로 플랜 모드에 들어갔을 때 Claude가 코드를 전혀 건드리지 않고, 먼저 계획을 제시합니다.There's a device that enforces this "design first" at the product level: Plan mode. On the left, the Before — in normal mode, you say "build it" and Claude starts editing files immediately. That's the sprint we saw. On the right, the After — when you enter Plan mode with Shift+Tab, Claude touches no code at all and presents a plan first.

그러면 사람이 그 계획을 검토하고, 고치고, 승인하죠. 그 승인이 떨어진 뒤에야 구현으로 들어갑니다. 핵심 차이는 한 줄이에요. 편집 권한을 일단 잠그고, 합의부터 한다. 룰 넘버 파이브에서 "명령하지 말고 설계하라"를 배웠는데, 플랜 모드는 그 정신을 한 번의 지시가 아니라, 세션 전체의 흐름으로 끌어올린 겁니다. 한 가지만 기억하세요. 모드 이름이나 진입 방법, 시프트 탭 같은 단축키는 버전마다 바뀔 수 있어요. 발표 시점의 공식 문서가 진실입니다.Then the human reviews that plan, edits it, approves it. Only after that approval does it move into building. The key difference is one line: lock edit access first, agree first. In Rule Number Five we learned "design, don't command" — and Plan mode lifts that spirit from a single instruction up to the flow of the whole session. Just remember one thing: the mode's name, the entry method, shortcuts like Shift+Tab — these can change by version. The official docs at the time you present are the truth.

6 · 스펙 문서 — 가정을 글로 못 박기6 · Spec document — pin assumptions into text

설계의 첫 번째 산출물은 스펙 문서입니다. 왼쪽 비포를 보세요. "알아서 잘 만들어줘"라는 말은, 사람과 Claude가 각자 머릿속에 서로 다른 그림을 그린다는 뜻이에요. 이 암묵적인 가정이 나중에 충돌합니다. 오른쪽 애프터는 다릅니다. 만들기 전에, 짧은 스펙을 한 장 적어서 합의해요.The first output of design is the spec document. Look at the Before on the left. "Just make it good" means the human and Claude each draw a different picture in their heads. These implicit assumptions collide later. The After on the right is different. Before building, you write one short spec page and agree on it.

스펙에는 네 가지를 담습니다. 무엇을 만들지, 그러니까 목표와 완료 기준. 그리고 무엇은 안 만들지, 즉 범위 밖. 어떤 제약이 있는지, 스택이나 규칙 같은 것들. 마지막으로 아직 안 풀린 질문들이에요. 핵심 차이는 이겁니다. 스펙은 코드보다 훨씬 싼 곳에서 틀린 가정을 미리 잡아냅니다. 글은 코드보다 고치기 쉬우니까요. 룰 넘버 파이브에서 한 번의 지시에 의도와 제약을 설계했다면, 작업 단위에서는 그걸 스펙 문서로 글에 못 박는 거예요. 가정은 코드가 아니라 스펙에서 먼저 검증합니다.A spec holds four things. What you'll build — that is, the goal and the done criteria. What you won't build — the out-of-scope. What constraints exist — things like the stack or the rules. And finally, the open questions. The key difference is this: a spec catches wrong assumptions somewhere far cheaper than code, because text is easier to fix than code. In Rule Number Five we designed intent and constraints into a single instruction; at the task level, we pin that into text as a spec document. You verify assumptions in the spec first, not in the code.

7 · 파일 맵 — 어디에 무엇을 둘지 먼저 그리기7 · File map — draw where things go first

설계의 두 번째 산출물은 파일 맵입니다. 코드를 짜기 전에, 어떤 폴더가 새로 생기고, 각자 무엇을 담당하는지를 미리 그려두는 지도예요. 슬라이드에 짧게 발췌해 봤는데요, 예를 들어 reports/monthly 폴더는 월별 매출 보고서를 새로 만드는 곳이고, data/inventory는 재고 데이터인데 여기는 수정만 하고 새 파일을 만들지는 않아요. docs/spec은 앞에서 합의한 바로 그 스펙이다, 이런 식으로요.The second output of design is the file map. Before you write any code, it's a map you draw in advance of which folders will exist and what each one is responsible for. I've put a short excerpt on the slide — for example, reports/monthly is where we create new monthly sales reports, data/inventory holds the inventory data and we edit only here, no new files, and docs/spec is the spec we agreed on earlier. Like that.

파일 맵이 하는 일은 두 가지예요. 하나, Claude가 어디를 건드릴지를 미리 합의하게 합니다. 그러면 손대는 범위가 좁아지죠. 둘, 빠진 부분이나 중복을 코드를 짜기 전에 드러냅니다. 지난 강에서 우리는 이미 있는 지식을 구조화했죠. 구조는 그래프다, 입구와 가지가 있다고 했습니다. 이번 파일 맵은, 앞으로 만들 구조를 미리 그려보는 거예요. 결국 설계 단계의 파일 맵이 곧 구현될 지식 그래프의 밑그림인 셈입니다. 지도가 있으면, Claude는 길을 잃지 않습니다.A file map does two things. One: it makes Claude agree in advance on where it will touch, which narrows the scope of what it changes. Two: it surfaces missing pieces or duplication before any code is written. Last session, we structured knowledge that already existed — we said structure is a graph, with entry points and branches. This file map is drawing, in advance, the structure you're about to build. So the design-stage file map is really the rough sketch of the knowledge graph you'll implement. With a map, Claude doesn't get lost.

8 · 왜 통하나 — 설계가 비용을 줄이는 3원리8 · Why it works — three principles that cut cost

자, 오늘의 핵심입니다. 그래서 설계는 왜 비용을 줄일까요? 설계의 세 산출물이 각각 어떤 낭비를 막는지를 보면 분명해집니다. 첫째, 스펙은 가정을 검증합니다. 틀린 가정을 코드가 아니라 글에서 잡아내니까, 코드를 통째로 재작성할 일이 줄어요. 룰 넘버 쓰리에서 본 환각과 검증 가능성, 기억나시죠? 글로 미리 검증하면 재작성도 줄어듭니다.Alright, here's the core insight. So why does design cut costs? It becomes clear when you see which waste each of design's three outputs prevents. First, the spec tests assumptions. Because it catches a wrong assumption in text rather than in code, you rewrite far less code. Remember hallucination and verifiability from Rule Number Three? Verify in text up front, and rewrites drop too.

둘째, 파일 맵은 범위를 고정합니다. 건드릴 곳을 미리 좁혀두니까, 엉뚱한 파일을 수정하거나 중복을 만드는 일을 막아요. 룰 넘버 식스에서 예시가 분포를 좁힌다고 했는데, 파일 맵은 작업의 분포를 좁히는 거죠. 셋째, 플랜 합의는 되돌림을 예방합니다. 승인 전에는 코드를 아예 안 건드리니까, 질주했다가 번복하는 일이 컨텍스트를 태우지 않아요. 룰 넘버 투, 컨텍스트를 지켜라죠. 이 셋이 합쳐지면, 빠른 질주가 확실한 직진으로 바뀝니다. 설계는, 비싼 코드 대신 싼 글로 문제를 미리 푸는 겁니다.Second, the file map fixes the scope. By narrowing in advance where it will touch, it blocks edits to the wrong files and prevents duplication. Rule Number Six said examples narrow the distribution — the file map narrows the distribution of the work. Third, Plan agreement prevents rework. Since no code is touched before approval, sprinting and then reversing doesn't burn context. That's Rule Number Two, protect the context. Put these three together and a fast sprint turns into a sure, straight line. Design solves the problem up front in cheap text instead of expensive code.

9 · 태스크 분해 — 큰 일을 검증 가능한 작은 단위로9 · Task decomposition — split big work into verifiable pieces

설계의 세 번째 기법은 태스크 분해입니다. 큰 일은 그대로 통째로 맡길 수가 없어요. 검증 가능한 작은 조각들로 쪼개야 합니다. 좋은 분해에는 세 가지 기준이 있어요. 첫째, 검증 가능해야 합니다. 각 조각마다 "이게 됐다"를 확인할 방법이 있어야 해요. 둘째, 독립적이어야 합니다. 조각들이 서로 덜 얽혀 있어야 한 번에 하나씩 처리할 수 있죠. 셋째, 크기가 적당해야 합니다. 한 조각이 너무 크면 다시 쪼개세요.The third design technique is task decomposition. You can't hand off a big task whole — you have to split it into small, verifiable pieces. A good split has three marks. First, it must be verifiable: each piece needs a way to confirm "this is done." Second, it must be independent: the pieces should be loosely coupled so you can handle one at a time. Third, it must be the right size: if a piece is too big, split it again.

왜 하필 이 세 기준일까요? 룰 넘버 쓰리에서, 검증 가능성이 Claude의 강점과 약점을 가르는 경계선이라고 했죠. 그래서 큰 일을 검증 가능하고, 독립적이고, 적당한 크기의 조각으로 쪼개면, 각 조각이 정확히 Claude의 강점 영역 안으로 들어옵니다. 한 가지 분명히 해둘게요. 오늘은 큰 일을 어떻게 쪼개서 적는지, 그 설계 기법까지만 다룹니다. 쪼갠 조각들을 어떤 순서로, 어떻게 병렬로 실제 실행하고 진행을 관리할지는, 바로 다음 강의 주제예요.Why exactly these three? In Rule Number Three, we said verifiability is the line dividing Claude's strengths from its weaknesses. So when you split a big task into verifiable, independent, right-sized pieces, each piece lands squarely inside Claude's strength zone. Let me be clear on one thing: today we cover only how to split a big task and write it down — the design technique. How to actually execute those pieces, in what order, in parallel, and how to track progress, is exactly the topic of the next session.

10 · 언제 설계하고, 언제 그냥 시작하나10 · When to design, when to just start

그런데 여기서 아주 중요한 분기가 있습니다. 모든 일을 다 설계해야 하는 건 아니에요. 기준은 세 가지입니다. 일이 여러 파일과 모듈에 걸쳐 있고, 요구가 불확실하고, 되돌리기가 비싸거나 위험하면, 그때는 설계합니다. 반대로 한 파일에서 한 줄만 고치고, 요구가 명확하고, 되돌리기가 싸면, 그냥 바로 시작하는 게 맞아요. 왜냐하면 설계에도 비용이 들거든요. 작고 명확한 일에까지 스펙을 쓰고 있으면, 그건 과설계, 오버 엔지니어링입니다.But there's a very important fork here. Not everything needs to be designed. The criteria are three. If the work spans many files and modules, the requirements are unclear, and undoing it is costly or risky — then you design. Conversely, if you're fixing one line in one file, the requirements are clear, and undoing is cheap — just dive in. Because design has a cost too. If you're writing a spec even for small, clear work, that's over-engineering.

지난 강에서 파일이냐 프롬프트냐를 가르는 절제의 원리를 배웠죠. 이번에는 그걸 설계냐 바로 시작이냐로 확장한 겁니다. 기억하세요. 이건 위계가 아니라 분기예요. 설계가 항상 더 나은 게 아니라, 일의 크기와 불확실성, 되돌림 비용에 따라 고르는 겁니다. 이 분기가 오늘 강 전체를 하나로 묶는 메타 규칙이에요. 이제 시작 전에 무엇을 설계할지, 체크리스트로 정리해 보겠습니다.Last session we learned the restraint principle dividing file from prompt. This time we extend it into design versus dive-in. Remember: this is a fork, not a hierarchy. Design isn't always better — you choose based on the size, the uncertainty, and the cost of undoing the work. This fork is the meta-rule that ties today's whole session together. Now let's organize what to design before you start, as a checklist.

11 · 시작 전 설계 5체크11 · Five design checks before you start

오늘의 두 번째 정점, 시작 전 설계 다섯 가지 체크입니다. 이 다섯을 적기 전에는 코드를 시작하지 마세요. 첫째, 의도를 맞췄나? 무엇을, 왜 만드는지를 브레인스토밍으로 펼친 뒤에 하나로 모았는지 보세요. 둘째, 스펙을 적었나? 목표와 범위 밖, 제약, 미해결 질문을 글로 못 박았는지. 셋째, 파일 맵을 그렸나? 어디에 무엇을 둘지 합의했는지요.Today's second peak: five design checks before you start. Don't begin coding until you've written these five. One: did you align on intent? Check whether you spread out what and why through brainstorming, then converged on one. Two: did you write the spec? Whether you pinned the goal, the out-of-scope, the constraints, and the open questions into text. Three: did you draw the file map? Whether you agreed on where things go.

넷째, 작은 조각으로 쪼갰나? 검증 가능하고, 독립적이고, 적당한 크기로 나눴는지 확인하세요. 다섯째, 이게 설계할 일인가, 아니면 그냥 바로 할 일인가? 크고 불확실하고 되돌리기 비싸면 설계하고, 작고 명확하면 그냥 시작하세요. 과설계는 금물입니다. 재밌는 건, 이 다섯 가지가 앞에서 본 원리들과 하나씩 정확히 짝을 이룬다는 거예요. 의도는 순서 합의에서, 스펙과 파일 맵은 그 두 산출물에서, 분해는 작은 조각 나누기에서, 설계 여부는 마지막 판단에서 봤죠. 그래서 원리를 알면, 이 체크리스트는 저절로 외워집니다.Four: did you split into small pieces? Check whether you divided them to be verifiable, independent, and the right size. Five: is this something to design, or just to do? If it's big, uncertain, and costly to undo, design it; if it's small and clear, just start. No over-engineering. Here's the fun part: these five map exactly, one by one, onto the principles we saw earlier. Intent came from aligning the order, the spec and file map from those two outputs, decomposition from splitting into small pieces, and the design question from the final judgment. So once you know the principles, this checklist memorizes itself.

12 · 브레인스토밍 스킬 패턴 — 답 대신 질문으로 시작12 · Brainstorming skill pattern — open with a question, not an answer

그럼 설계를 어떻게 끌어낼까요? 시작을 답이 아니라 질문으로 여는 게 핵심입니다. 바로 "만들어줘"라고 하지 말고, "같이 설계해보자"로 여세요. 예를 들면, "구현하기 전에, 접근법을 두세 개 주고 각각의 장단점부터 알려줘"라고 하는 거죠. 그러면 Claude가 코드가 아니라 질문과 옵션, 트레이드오프부터 내놓습니다. 코드는 그다음이에요.So how do you draw the design out? The key is to open the start with a question, not an answer. Don't say "build it" — open with "let's design this together." For example: "before implementing, give me two or three approaches and the trade-offs of each." Then Claude leads with questions, options, and trade-offs instead of code. The code comes after that.

만약 의도가 흐릿해서 막히면, 브레인스토밍으로 의도를 캐는 질문을 Claude가 던지게 하세요. 룰 넘버 파이브의 "명령 대신 설계하는 지시"를, 시작 단계에 그대로 적용하는 겁니다. 그렇게 설계가 서면, 그걸 스펙과 파일 맵으로 적고, 그제서야 플랜을 승인하고 구현으로 들어가요. 한 가지 더. 이 브레인스토밍에서 스펙으로 이어지는 시작 절차를 자주 쓴다면, 지난 강에서 배운 것처럼 스킬로 묶어둘 수도 있습니다. 시작은, 답이 아니라 질문으로 엽니다.If intent is fuzzy and you get stuck, have Claude ask intent-digging questions through brainstorming. You're applying Rule Number Five's "design the instruction, don't command it" right at the starting stage. Once the design stands, write it as a spec and a file map, and only then approve the Plan and move into building. One more thing: if you use this brainstorm-to-spec starting routine often, you can bundle it into a skill, as we learned last session. Open the start with a question, not an answer.

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

오늘 본 걸 한 줄 공식으로 정리해볼게요. 코드 전에, 의도를 맞추고 설계를 적어라. 시작 전 설계는 이렇게 쪼개집니다. 브레인스토밍으로 의도를 맞추고, 스펙으로 가정을 못 박고, 파일 맵으로 범위를 정하고, 작은 조각으로 분해한다. 그제서야 구현으로 들어가는 거예요. 단, 잊지 마세요. 이건 크고, 불확실하고, 되돌리기 비쌀 때만입니다. 작고 명확하면 그냥 바로 시작하세요. 룰 넘버 파이브, 명령하지 말고 설계하라와, 오늘의 룰 넘버 나인이 바로 여기서 만납니다. 한 번의 지시를 설계하던 것에서, 한 작업 전체를 설계하는 것으로요.Let me lock today into a one-line formula. Before any code, align on intent and write the design. Design-before-starting splits like this: align intent through brainstorming, pin assumptions with a spec, set scope with a file map, decompose into small pieces — and only then move into building. But don't forget: this is only when it's big, uncertain, and costly to undo. If it's small and clear, just dive in. Rule Number Five, "design, don't command," and today's Rule Number Nine meet right here — going from designing a single instruction to designing an entire task.

14 · CLOSING — Rule No.914 · Closing — Rule No.9

오늘 한 단어만 가져가신다면, 질주에서 설계로, 입니다. 똑똑한 Claude에게 바로 시키면 빠르게 질주하지만, 늦게야 되돌립니다. 시작 전에 의도를 맞추고 설계를 적으면, 그 되돌림이 줄어요. 그래서 빨리 시작하는 것보다, 옳게 시작하는 것이 결국 더 빠릅니다. 모드 이름이나 명령은 앞으로 바뀌겠지만, 코딩 전에 의도를 맞추고 설계를 적으면 되돌림이 준다는 원리는 그대로예요. 다음 시간에는, 오늘 쪼갠 그 작은 일들을 어떻게 실제로 맡기고 실행할지 — 태스크 분해와 실행을 들여다보겠습니다.If you take one word from today, it's: from sprint to design. Tell a smart Claude to go and it sprints fast — but reverts late. Align on intent and write the design before you start, and that reverting shrinks. So starting right ends up faster than starting fast. The mode names and commands will change, but the principle stays: align on intent and write the design before coding, and rework drops. Next time, we'll look at how to actually hand off and run those small pieces we split today — Task Decomposition and Execution.