프로젝트 설계법 · Rule No.9
01 / 14
← → SPACE 이동 · F 전체화면← → SPACE move · F fullscreen · RULE №9 · DESIGN BEFORE YOU START Privacy[email protected]
교육 세션 · 시작 전에 설계하라Learning session · design before you start

RULE No.9

시작 전에
설계하라.
Design
before you start.

목수도 톱을 들기 전에 도면을 그립니다. 오늘은 시작하는 순서 — 브레인스토밍 → 설계 → 구현, 그리고 이를 강제하는 Plan 모드·스펙·파일 맵·태스크 분해. The carpenter draws the plan before lifting the saw. Today, the order of starting — brainstorm → design → build, and what enforces it: Plan mode, spec, file map, task split.

As of 2026-06 · 명령·모드 이름은 바뀝니다 — '코딩 전에 의도를 맞추고 설계를 적는다'는 원리는 남습니다. [추론]As of 2026-06 · commands & mode names change — but the principle 'align on intent and write the design before coding' stays. [inference]

설계 · DESIGNDESIGN
1막 — 똑똑할수록 빨리 헤맨다Act 1 — The smarter it is, the faster it strays

전문가로 만들어 놨는데, 왜 '바로 시키면' 헤맬까?You made it an expert — so why does it stray when you 'just tell it to build'?

> 이거 만들어줘

(파일 생성… 수정… 또 수정…)

아, 제가 가정한 구조가 요구와 달랐네요 — 되돌릴게요
> just build this

(creating files… editing… editing again…)

Ah, the structure I assumed didn't match the requirement — reverting

능력이 아니라, 시작하는 순서의 문제입니다.Not a capability problem — a starting-order problem.

[추론] s08 콜백 — 지식을 잘 줘도, 설계 없이 시작하면 틀린 가정을 코드로 굳힌 뒤 되돌린다. 되돌림 = 낭비한 컨텍스트·토큰·방향. → 오늘은 '바로 시키기'에서 '먼저 설계하기'로.[inference] s08 callback — even with knowledge given well, starting without a design hardens a wrong assumption into code, then reverts. Reverting = wasted context·tokens·direction. → Today: from 'just tell it' to 'design first'.

1막 — 바로 시작의 대가Act 1 — The cost of diving in

설계 없이 시작하면, 세 가지를 잃는다.Start without a design and you lose three things.

① 방향① Direction

첫 가정이 틀리면 그 위에 쌓은 코드가 통째로 흔들린다 — 늦게 발견할수록 비싸다.If the first assumption is wrong, all the code on top shakes — the later you find it, the costlier.

② 컨텍스트② Context

질주 → 되돌림 → 재작업이 대화창을 태운다 (Rule No.2).Sprint → revert → rework burns the chat (Rule No.2).

③ 합의 — 글로 못 박지 않으면 사람과 Claude가 다른 그림을 그린다③ Alignment — without writing it down, you and Claude picture different things

[추론] s02·s03 콜백 — 설계 없는 시작은 틀린 가정을 늦게 발견하고(방향), 되돌림으로 컨텍스트를 태우며(Rule No.2), 사람·Claude가 다른 그림을 그린다(합의 부재). → 코딩 전에 의도와 설계를 먼저 맞춘다.[inference] s02·s03 callback — starting without a design finds wrong assumptions late (direction), burns context via rework (Rule No.2), and leaves human·Claude with different pictures (no alignment). → Align intent and design before coding.

2막 — 일을 시작하는 순서Act 2 — The order of starting work

시작 = 세 단계를 '순서대로' — 브레인스토밍 → 설계 → 구현.Starting = three stages in order — brainstorm → design → build.

① 브레인스토밍① Brainstorm
무엇을·왜·어떤 선택지 (의도·옵션 펼치기)what·why·which options (open up intent·options)
② 설계② Design
무엇을·어디에·어떤 순서 (스펙·파일 맵으로 못 박기)what·where·in what order (pin it down with spec·file map)
③ 구현③ Build
합의된 설계대로 코드code, per the agreed design

앞 두 단계는 싼 매체(말·글), 비싼 매체(코드)는 합의 뒤에.First two stages in cheap media (talk·text); the costly one (code) comes after agreement.

[출처: docs.anthropic.com/en/docs/claude-code/common-workflows] · [추론] Claude Code는 코드를 바로 고치기 전에 계획을 먼저 세우는 워크플로(예: Plan 모드)를 지원한다. 정확한 모드명·발동 방식은 발표 시점 공식 문서가 진실(2026-06 기준). → 싼 매체에서 먼저 합의하고, 코드는 마지막에.[source: docs.anthropic.com/en/docs/claude-code/common-workflows] · [inference] Claude Code supports a workflow that plans before editing code (e.g. Plan mode). The exact mode name·trigger is whatever the official docs say at present (as of 2026-06). → Agree in cheap media first; code last.

2막 — 설계를 강제하는 모드Act 2 — A mode that enforces design

Plan 모드 = '읽고 계획만, 아직 손대지 마' 모드.Plan mode = 'read and plan only — don't touch yet'.

Before · 바로 편집Before · edit right away
> 만들어줘 → 곧장 파일을 고치기 시작> build it → starts editing files immediately
질주…sprint…
After · Plan 모드After · Plan mode
/plan → 코드는 건드리지 않고 계획부터 제시/plan → presents a plan without touching code
사람이 검토·승인한 뒤에야 구현builds only after you review·approve

핵심 차이 — 편집 권한을 '잠그고' 합의부터.The key difference — 'lock' edit access, agree first.

[출처: docs.anthropic.com/en/docs/claude-code/common-workflows] · [추론] Claude Code의 Plan 모드는 코드를 수정하지 않고 계획을 먼저 세워 사람의 검토를 받게 하는 흐름이다. 정확한 모드명·진입 방법(/plan 등)·동작은 발표 시점 공식 문서가 진실(2026-06 기준). → 큰 일은 'Plan 먼저, 편집은 승인 후'.[source: docs.anthropic.com/en/docs/claude-code/common-workflows] · [inference] Plan mode plans before editing and routes it through human review. The exact mode name·entry (/plan etc.)·behavior is whatever the official docs say at present (as of 2026-06). → For big work: 'Plan first, edit after approval'.

2막 — 무엇을 만들지 글로Act 2 — Put the 'what' in writing

머릿속 그림 대신, 스펙 한 장으로 합의하라.Replace the mental picture with one spec page.

Before · 암묵적 가정Before · implicit assumptions
"알아서 잘 만들어줘""just make it good"
서로 다른 그림을 가정…each assumes a different picture…
After · 스펙 문서After · spec doc
무엇을 목표·완료 기준
무엇은 아닌지 범위 밖
제약 스택·규칙
미해결 질문
the what goal·done criteria
the what-not out of scope
constraints stack·rules
open questions

핵심 차이 — 스펙은 '코드보다 싼 곳'에서 틀린 가정을 잡는다.The key difference — a spec catches wrong assumptions 'somewhere cheaper than code'.

[추론] s05 콜백 — 단일 프롬프트에서 '의도·제약'을 설계했듯, 작업 단위에선 '스펙 문서'로 목표·범위·제약·미해결 질문을 글로 못 박는다. 글은 코드보다 고치기 싸다. → 가정은 코드가 아니라 스펙에서 먼저 검증한다.[inference] s05 callback — as we designed 'intent·constraints' into a single prompt, at the task level we pin goal·scope·constraints·open questions into a 'spec doc'. Text is cheaper to fix than code. → Verify assumptions in the spec first, not the code.

2막 — 어디에 무엇을Act 2 — Where things go

코드를 짜기 전에, '파일 지도'를 먼저 그려라.Draw the file map before you write the code.

파일 맵 · 발췌File map · excerpt
src/auth/ — 로그인·세션 (새로 만듦)
src/api/ — 엔드포인트 (여기만 수정)
docs/spec — 위에서 합의한 스펙
src/auth/ — login·session (new)
src/api/ — endpoints (edit here only)
docs/spec — the spec we agreed above

지도가 있으면, Claude가 길을 잃지 않는다.With a map, Claude doesn't get lost.

[추론] s08 콜백 — s08이 '이미 있는 지식을 구조화'였다면, s09 파일 맵은 '앞으로 만들 구조를 미리 그리기'. 어디에 무엇을 둘지 코드 전에 합의하면, 건드릴 범위가 좁아지고 빠짐·중복이 드러난다. → 코드 전에 지도부터.[inference] s08 callback — if s08 'structured existing knowledge', the s09 file map 'draws the structure you're about to build, in advance'. Agree where things go before code, and the touched scope narrows while gaps·duplication surface. → Map first, code later.

3막 — 왜 설계가 싼가Act 3 — Why design is cheaper

설계는 셋을 한다 — 가정 검증·범위 고정·되돌림 예방.Design does three things — test assumptions·fix the scope·prevent rework.

설계의
세 산출물스펙·파일 맵·Plan 합의
Design's
three outputsspec·file map·Plan agreement
스펙 → 가정 검증Spec → test assumptions
틀린 가정을 '글'에서 잡아 코드 재작성을 면한다 (환각·재작성↓)catch wrong assumptions in 'text', skip the code rewrite (less hallucination·rewrite)
파일 맵 → 범위 고정File map → fix the scope
건드릴 곳을 좁혀 엉뚱한 수정·중복을 막는다 (분포 좁히기)narrow what's touched, block stray edits·duplication (narrowing the distribution)
Plan 합의 → 되돌림 예방Plan agreement → prevent rework
승인 전엔 코드를 안 건드려 질주→번복이 컨텍스트를 안 태운다 (Rule No.2)no code touched before approval, so sprint→reversal doesn't burn context (Rule No.2)

[추론] s02·s03·s06 콜백 — 스펙은 가정을 글에서 검증하고(환각·재작성↓), 파일 맵은 범위를 좁히며(분포 좁히기), Plan 합의는 되돌림을 막는다(컨텍스트 절약). 셋이 합쳐 '빠른 질주'를 '확실한 직진'으로. → 설계는 비싼 코드 대신 싼 글로 미리 푼다.[inference] s02·s03·s06 callback — spec verifies assumptions in text (less hallucination·rewrite), the file map narrows scope (narrowing the distribution), Plan agreement prevents rework (saves context). Together they turn a 'fast sprint' into a 'sure straight line'. → Design solves it up front in cheap text, not expensive code.

3막 — 큰 일을 쪼개기Act 3 — Breaking the big task down

큰 일은 그대로 못 맡긴다 — '검증 가능한 조각'으로 쪼개라.You can't hand off a big task whole — split it into verifiable pieces.

큰 목표그대로 못 맡김Big goalcan't hand off whole
① 작은 조각① small piece
② 작은 조각② small piece
③ 작은 조각③ small piece
검증 가능 — '됐다'를 확인할 방법verifiable — a way to confirm 'done' 독립적 — 한 번에 하나씩independent — one at a time 적당한 크기 — 크면 다시 쪼갬right size — split again if too big

[추론] s03 콜백 — Claude는 '검증 가능한 일'에 강하다. 큰 일을 검증 가능·독립·적당 크기의 조각으로 쪼개면, 각 조각이 강점 영역에 들어온다. (실행·오케스트레이션은 s10 소관 — 여기선 '쪼개 적기'까지.) → 큰 일은 검증 가능한 조각으로 설계한다.[inference] s03 callback — Claude is strong on 'verifiable work'. Split a big task into verifiable·independent·right-sized pieces and each lands in its strength zone. (Execution·orchestration is s10's job — here we only 'split and write down'.) → Design big work into verifiable pieces.

3막 → 4막 다리 · 핵심 분기Bridge to Act 4 · the core fork

크고·불확실·되돌리기 비싸면 '설계', 작고·명확·되돌리기 싸면 '바로'.Big, uncertain, costly-to-undo → design. Small, clear, cheap-to-undo → dive in.

여러 파일·모듈 → 설계 / 한 파일 한 줄 → 바로Many files·modules → design / one line in one file → dive in 요구 불확실 → 설계 / 요구 명확 → 바로Requirements unclear → design / clear → dive in 되돌리기 비쌈·위험 → 설계 / 되돌리기 쌈 → 바로Costly·risky to undo → design / cheap to undo → dive in

설계에도 비용이 든다 — 작고 명확한 일까지 스펙 쓰면 '과설계'.Design has a cost too — speccing small, clear work is 'over-engineering'.

[추론] s08 콜백·확장 — s08이 '파일 vs 프롬프트'였다면 s09는 '설계 vs 바로 시작'. 설계에도 비용이 든다 → 크고·불확실·되돌리기 비쌀 때만 설계. 작고 명확한 일을 설계하면 과설계. → 다음: 시작 전 무엇을 설계할지 체크.[inference] s08 callback·extension — if s08 was 'file vs prompt', s09 is 'design vs dive-in'. Design costs too → design only when big·uncertain·costly to undo. Speccing small, clear work is over-engineering. → Next: a checklist of what to design before you start.

4막 — 코딩 전 5점검Act 4 — Five checks before you code

이 5가지를 적기 전엔, 코드를 시작하지 마라.Don't start coding until you've written these five.

  1. 1
    의도를 맞췄나?Did you align on intent? → 무엇을·왜를 브레인스토밍으로 펼친 뒤 하나로→ spread out what·why by brainstorming, then converge
  2. 2
    스펙을 적었나?Did you write the spec? → 목표·범위 밖·제약·미해결 질문을 글로→ goal·out-of-scope·constraints·open questions, in text
  3. 3
    파일 맵을 그렸나?Did you draw the file map? → 어디에 무엇을 둘지 합의→ agree on where things go
  4. 4
    작은 조각으로 쪼갰나?Did you split into small pieces? → 검증 가능·독립·적당 크기→ verifiable·independent·right size
  5. 5
    설계할 일인가, 바로 할 일인가?Design it, or just do it? → 작고 명확하면 바로 (과설계 금지)→ if small and clear, dive in (no over-engineering)

[추론] 5항목은 각각 슬라이드 04~10의 원리와 1:1 대응(의도=S04, 스펙=S06/08, 파일 맵=S07/08, 분해=S09, 설계 여부=S10). → 원리를 알면 체크리스트가 외워진다.[inference] Each of the 5 maps one-to-one onto the principles in slides 04–10 (intent=S04, spec=S06/08, file map=S07/08, split=S09, design-or-not=S10). → Know the principles and the checklist memorizes itself.

4막 — 설계를 끌어내는 법Act 4 — Drawing the design out

바로 '만들어줘' 대신, '같이 설계하자'로 열어라.Open with 'let's design this together', not 'build it'.

> 구현 전에, 접근법 2~3개와 그 장단점부터 줘 > before building, give me 2–3 approaches with their trade-offs
답 대신 질문·옵션·트레이드오프부터 (코드는 나중)questions·options·trade-offs first (code comes later) 막히면 브레인스토밍으로 의도를 캐는 질문을 (s05 콜백)when stuck, have it ask intent-digging questions (s05 callback) 설계가 서면 스펙·파일 맵으로 적고 → Plan 승인 → 구현once it stands, write spec·file map → approve Plan → build

[추론] s05·s08 콜백 — s05 '명령 대신 설계하는 지시'를 시작 단계에 적용: 답 대신 질문·옵션을 먼저 받는다. 자주 쓰는 시작 절차(브레인스토밍→스펙)는 스킬로 묶을 수도 있다(s08). → 시작은 답이 아니라 질문으로 연다.[inference] s05·s08 callback — apply s05's 'design the instruction, don't command' at the start: take questions·options first, not answers. A frequent starting routine (brainstorm→spec) can be bundled into a skill (s08). → Open the start with a question, not an answer.

4막 — 한 줄로 굳히기Act 4 — Lock it into one line

그래서 — 코드 전에 의도를 맞추고, 설계를 적어라.So — align on intent and write the design before any code.

시작 전 설계 = [브레인스토밍으로 의도] + [스펙으로 가정] + [파일 맵으로 범위] + [작은 조각으로 분해]
  → 그제서야 구현
단, 크고·불확실·되돌리기 비쌀 때만 (작고 명확하면 바로)
Design before starting = [intent via brainstorm] + [assumptions via spec] + [scope via file map] + [split into small pieces]
  → then build
but only when big·uncertain·costly to undo (small and clear → dive in)

[추론] Rule No.5(명령하지 말고 설계하라)와 Rule No.9(시작 전에 설계하라)의 교차점 — 한 번의 지시 설계에서 한 작업 전체의 설계로. 단, 작고 명확하면 그냥 시작(과설계 금지). → 알면, 무엇을 코드 전에 적을지 보인다.[inference] Where Rule No.5 (design, don't command) and Rule No.9 (design before you start) meet — from designing a single instruction to designing a whole task. But if small and clear, just start (no over-engineering). → Once you know it, you can see what to write before code.

닫으며 — 시작 전에 설계하라Closing — design before you start

빨리 시작하는 것보다,
옳게 시작하는 것이 빠르다.
Starting right
beats starting fast.

한 단어로: 질주 → 설계.In one word: sprint → design.

다음 강 예고 — 태스크 분해 & 실행: 쪼갠 작은 일들을 어떻게 실제로 맡길지.Next up — Task Decomposition & Execution: how to actually hand off the small tasks.

RULE No.9

As of 2026-06 · 모드 이름·명령은 바뀌어도 '코딩 전에 의도를 맞추고 설계를 적으면 되돌림이 준다'는 원리는 남습니다. [추론]As of 2026-06 · mode names·commands change, but the principle stays: align on intent and write the design before coding, and rework drops. [inference]