프로젝트 설계법 · 시작 전에 설계하라 · 시작을 누르면 음성과 함께 슬라이드가 자동 재생됩니다. Project Design · design before you start · Press start and slides advance with narration.
목수도 톱을 들기 전에 도면을 그립니다. 오늘은 시작하는 순서 — 브레인스토밍 → 설계 → 구현, 그리고 이를 강제하는 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]
능력이 아니라, 시작하는 순서의 문제입니다.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'.
첫 가정이 틀리면 그 위에 쌓은 코드가 통째로 흔들린다 — 늦게 발견할수록 비싸다.If the first assumption is wrong, all the code on top shakes — the later you find it, the costlier.
질주 → 되돌림 → 재작업이 대화창을 태운다 (Rule No.2).Sprint → revert → rework burns the chat (Rule No.2).
[추론] 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.
앞 두 단계는 싼 매체(말·글), 비싼 매체(코드)는 합의 뒤에.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.
> 만들어줘 → 곧장 파일을 고치기 시작> build it → starts editing files immediately/plan → 코드는 건드리지 않고 계획부터 제시/plan → presents a plan without touching code핵심 차이 — 편집 권한을 '잠그고' 합의부터.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'.
핵심 차이 — 스펙은 '코드보다 싼 곳'에서 틀린 가정을 잡는다.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.
지도가 있으면, 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.
[추론] 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.
[추론] 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.
설계에도 비용이 든다 — 작고 명확한 일까지 스펙 쓰면 '과설계'.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.
[추론] 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.
[추론] 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.
[추론] 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.
한 단어로: 질주 → 설계.In one word: sprint → design.
다음 강 예고 — 태스크 분해 & 실행: 쪼갠 작은 일들을 어떻게 실제로 맡길지.Next up — Task Decomposition & Execution: how to actually hand off the small tasks.
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]