지시의 기술 I · Rule No.5
01 / 14
← → SPACE 이동 · F 전체화면← → SPACE move · F fullscreen　·　RULE №5 · DON'T COMMAND, DESIGN [email protected]
교육 세션 · 명령하지 말고 설계하라Learning session · don't command, design

RULE No.5

명령하지 말고
설계하라.Don't command.
Design.

건축가는 “집 지어줘” 한 마디로 시작하지 않습니다 — 도면을 그리죠. 좋은 결과는 던진 명령이 아니라, 설계된 지시에서 나옵니다. 오늘은 프롬프트를 ‘설계’하는 법 — 맥락·역할·행동·형식·톤. An architect doesn't start with “build me a house” — they draw a blueprint. Good results come not from a tossed command, but from a designed instruction. Today: how to ‘design’ a prompt — context, role, action, format, tone.

As of 2026-06 · 도구·UI는 바뀝니다 — 좋은 지시의 원리는 남습니다. [추론]As of 2026-06 · tools & UI change — the principles of good instruction remain. [inference]

설계 · DESIGNDESIGN
1막 — 같은 일, 다른 결과Act 1 — Same task, different result

시간을 줘도, ‘무엇을’ 모호하면 소용없다.Even given time, a vague ‘what’ wastes it.

> 이거 좀 고쳐줘
> 정리 좀 해줘

// 빈칸이 많으면 —
모델은 아무거나 그럴듯하게 채운다. > just fix this
> clean this up

// too many blanks —
the model fills them with anything plausible.

충분히 생각할 시간을 줘도, 무엇을 시킬지가 모호하면 그 시간이 다 소용없습니다.Even with plenty of thinking time, if what you ask is vague, all that time is wasted.

[추론] s04 콜백 — 생각 시간(s04)과 지시 설계(s05)는 별개의 레버. 둘 다 있어야 결과가 산다. → 오늘은 ‘지시 레버’.[inference] s04 callback — thinking time (s04) and instruction design (s05) are separate levers. You need both for the result to live. → Today: the ‘instruction lever’.

1막 — 모호함이 만드는 손실Act 1 — The cost of ambiguity

빈칸을 남기면, 모델이 임의로 채운다.Leave a blank, and the model fills it at random.

모호함의 3가지 실패3 failures of vagueness
① 엉뚱한 범위 — 시킨 것보다 많거나 적게① Wrong scope — more or less than you asked ② 일관성 없는 형식 — 매번 다른 출력 모양② Inconsistent format — a different shape every time ③ 빗나간 톤·관점 — 독자도 어조도 제각각③ Off tone·viewpoint — wrong reader, wrong voice
버그가 아니다Not a bug

모호한 입력 = 넓은 출력 분포 = 들쭉날쭉. 빈칸을 제약으로 메우면 분포가 좁아진다.Vague input = a wide output distribution = erratic. Fill blanks with constraints and the distribution narrows.

[추론] s03 인과 — 모델은 입력 분포로 출력 분포를 만든다(패턴 생성기). 모호한 입력 = 넓은 분포 = 들쭉날쭉. → 빈칸을 제약으로 메우면 분포가 좁아진다.[inference] s03 causality — the model turns the input distribution into the output distribution (pattern generator). Vague input = wide distribution = erratic. → Fill blanks with constraints and the distribution narrows.

2막 — 나쁜 vs 좋은 ①Act 2 — Bad vs good ①

‘누구로서’ 답할지를 정해준다.Tell it who to answer as.

Before · 명령Before · command
코드 리뷰해줘.review this code.
→
After · 설계After · design
10년차 보안 엔지니어로서, 이 인증 코드를 OWASP 기준으로 리뷰해줘.As a senior security engineer, review this auth code against OWASP.

[추론] 역할 부여는 모델이 끌어올 패턴의 영역을 좁혀, 더 일관된 전문가 관점을 유도한다. → ‘누구로서’가 첫 번째 빈칸. (프롬프트 예시는 2026-06 기준)[inference] Assigning a role narrows the region of patterns the model draws from, inducing a more consistent expert viewpoint. → ‘Who as’ is the first blank. (example prompt as of 2026-06)

2막 — 나쁜 vs 좋은 ②Act 2 — Bad vs good ②

하지 말 것·지킬 것을 못 박는다.Pin down the do's and don'ts.

Before · 명령Before · command
테스트 짜줘.write some tests.
→
After · 설계After · design
기존 함수는 수정하지 말고, pytest로, 엣지 케이스 3개 포함해서 테스트만 추가해.Don't touch the existing functions; add tests only, in pytest, covering 3 edge cases.

[추론] 제약은 출력 공간을 좁혀 ‘엉뚱한 범위’(S03①) 실패를 직접 차단한다. → 빈칸 = 모델의 자유 = 위험. 못 박을수록 예측 가능. (예시는 2026-06 기준)[inference] Constraints narrow the output space and directly block the ‘wrong scope’ (S03①) failure. → A blank = the model's freedom = risk. The more you pin down, the more predictable. (example as of 2026-06)

2막 — 나쁜 vs 좋은 ③Act 2 — Bad vs good ③

결과의 ‘모양’을 미리 정한다.Decide the shape of the output up front.

Before · 명령Before · command
요약해줘.summarize this.
→
After · 설계After · design
3개 불릿으로, 각 줄 15자 이내, 핵심 수치 포함해서 요약해줘.summarize in 3 bullets, each under 15 chars, with key numbers.

[추론] 형식 지정은 후처리·재요청 비용을 없앤다 — 받자마자 쓸 수 있는 모양으로. → ‘모양’을 정하는 것도 설계의 일부. (예시는 2026-06 기준)[inference] Fixing the format removes post-processing and re-ask cost — a shape usable on arrival. → Deciding the ‘shape’ is part of design too. (example as of 2026-06)

2막 — 한눈에 보는 차이Act 2 — The difference at a glance

명령은 빈칸투성이, 설계는 빈칸이 없다.A command is full of blanks; a design fills them.

⚠️ 명령Command ✅ 설계Design
한 줄 던지기One-line toss 맥락+역할+제약+형식Context+role+constraints+format
암묵적 기대Implicit expectation 명시적 기준Explicit criteria
결과 들쭉날쭉Erratic results 결과 일관Consistent results
매번 재요청Re-ask every time 한 번에 사용 가능Usable in one shot

[추론] 차이의 본질은 ‘명시성’. 머릿속 기대를 글로 옮긴 만큼 결과가 좋아진다. → 이 한 장이 1·2막을 잇는 다리. (3막에서 이 명시 항목을 CRAFT로 체계화.)[inference] The essence of the difference is ‘explicitness’. The more you move your mental expectation onto the page, the better the result. → This page is the bridge from Act 1 to Act 2. (Act 3 systematizes these into CRAFT.)

3막 — 왜 효과가 있나Act 3 — Why it works

입력이 분포를 정하고, 분포가 결과를 정한다.Input sets the distribution; the distribution sets the result.

모호한 입력Vague input빈칸 많음many blanks
→
넓은 출력 분포wide output distribution
→
들쭉날쭉erratic
설계된 입력Designed input빈칸 없음no blanks
→
좁은 출력 분포narrow output distribution
→
일관consistent

[추론] s03 콜백 — 모델은 입력으로 다음 토큰 분포를 만드는 패턴 생성기. 설계 = 그 분포를 의도한 쪽으로 좁히는 일. → 그래서 ‘더 똑똑한 모델’보다 ‘더 좋은 입력’이 빠른 지렛대. (같은 모델, 입력만 다름)[inference] s03 callback — the model is a pattern generator that builds a next-token distribution from input. Design = narrowing that distribution toward intent. → So ‘better input’ is a faster lever than ‘a smarter model’. (Same model, only the input differs.)

3막 — 설계의 5요소Act 3 — The 5 parts of a good prompt

좋은 프롬프트는 5개 칸을 채운다 — CRAFT.A good prompt fills 5 slots — CRAFT.

C
맥락ContextContext
배경·데이터·예시를 준다give background·data·examples
예: “이 로그”e.g. “this log”
R
역할RoleRole
누구로서 답할지who it answers as
예: “보안 엔지니어”e.g. “security engineer”
A
행동ActionAction
무엇을·어디까지what·how far
예: “취약점만”e.g. “only the vulns”
F
형식FormatFormat
받을 모양the shape you get
예: “3개 불릿”e.g. “3 bullets”
T
톤ToneTone
독자·어조reader·voice
예: “비전공자용”e.g. “for non-experts”

[추론] CRAFT는 ‘빈칸 체크리스트’를 외우기 쉽게 묶은 통용 니모닉. 명칭·순서는 자료마다 다르나 다루는 축(맥락·역할·행동·형식·톤)은 공통. S04~06의 역할·제약·형식이 R·A·F에 매핑. → 5칸을 의식하면 빈칸이 안 남는다. (CRAFT 명칭은 2026-06 기준 통용 니모닉)[inference] CRAFT is a widely used mnemonic bundling the ‘blank checklist’ for easy recall. Names·order vary by source, but the axes (context·role·action·format·tone) are common. The role·constraints·format from S04–06 map onto R·A·F. → Mind the 5 slots and no blanks are left. (CRAFT is a common mnemonic as of 2026-06)

3막 — 5칸을 다 채우면Act 3 — Fill all 5 slots

한 줄이 5칸으로 — 결과가 달라진다.One line becomes 5 slots — and the result shifts.

BeforeBefore
이 API 문서 좀 정리해줘.clean up this API doc.
→
After · CRAFT 5칸After · 5 CRAFT slots
C 맥락신규 입사자가 처음 읽는 문서야this is the first doc new hires read
R 역할테크니컬 라이터로서as a technical writer
A 행동엔드포인트별 용도만 추려서pull out each endpoint's purpose only
F 형식표 하나로as a single table
T 톤비전공자도 읽게 쉽게easy enough for non-experts

[추론] 같은 작업도 5칸을 채우면 재요청이 사라진다 — 모호함이 만든 왕복 비용 제거. → 설계의 시간은 회수된다(한 번에 쓸 수 있는 결과). (예시는 2026-06 기준)[inference] Fill all 5 slots and re-asking disappears — the round-trip cost vagueness created is gone. → The time spent designing is recovered (a result usable in one shot). (example as of 2026-06)

4막 — 보내기 전 5가지 점검Act 4 — 5 checks before you hit send

이 5가지를 채웠나 — CRAFT로 점검한다.Did you fill these 5 — check with CRAFT.

  1. C
    맥락을 줬나?Gave the context? → 배경·데이터·예시 함께→ with background·data·examples
  2. R
    역할을 정했나?Set the role? → 누구로서→ who it answers as
  3. A
    행동이 구체적인가?Is the action specific? → 무엇을·어디까지→ what·how far
  4. F
    형식을 지정했나?Specified the format? → 받을 모양→ the shape you get
  5. T
    톤을 맞췄나?Matched the tone? → 독자·어조→ reader·voice

[추론] 5항목은 S09 CRAFT 5요소와 1:1 대응. → 프레임워크를 알면 체크리스트가 외워진다.[inference] The 5 items map one-to-one onto the S09 CRAFT elements. → Know the framework and the checklist memorizes itself.

4막 — 한 줄로Act 4 — In one line

그래서 — 명령 한 줄을 설계 한 단락으로.So — turn one command into one designed paragraph.

좋은 프롬프트 = [맥락] + [역할] + [행동] + [형식] + [톤]
  → 빈칸 0개 Good prompt = [Context] + [Role] + [Action] + [Format] + [Tone]
  → 0 blanks

[추론] Rule No.5(설계하라)의 한 줄 요약 — 머릿속 기대를 빈칸 없는 글로 옮기는 일. → 다음 강에서 더 깊은 설계 기법으로.[inference] Rule No.5 (design) in one line — moving your mental expectation onto the page with no blanks. → Next session: deeper design techniques.

4막 — 설계도 과하면 독Act 4 — Over-designing backfires

모호함도 문제지만, 과한 지시도 문제다.Vagueness hurts — but so does over-instruction.

모순된 제약 — 서로 부딪히면 결과가 나빠진다Conflicting constraints — they collide and the result worsens 불필요한 장식 — 말이 많아 핵심을 묻는다Needless decoration — too many words bury the point 단순 작업까지 과설계 — 비용·시간 낭비Over-designing simple tasks — wasted cost·time

[추론] 설계의 목표는 ‘빈칸 제거’지 ‘말 늘리기’가 아니다 — 단순 작업엔 단순한 지시. → s04 ‘난이도에 예산을 맞춘다’와 같은 절제 원리.[inference] The goal of design is ‘removing blanks’, not ‘piling on words’ — a simple task gets a simple instruction. → Same restraint as s04's ‘match the budget to difficulty’.

닫으며 — 명령하지 말고 설계하라Closing — don't command, design

던지지 말고,
도면을 그려라.Don't toss a command —
draw a blueprint.

한 단어로: 명령 → 설계.In one word: command → design.

다음 강 예고 — 지시의 기술 II, 더 깊은 설계 기법.Next up — The Art of Instruction II, deeper design techniques.

RULE No.5

As of 2026-06 · 모델·UI는 바뀌어도 ‘빈칸 없이 설계하라’는 원리는 남습니다. [추론]As of 2026-06 · models & UI change, but the principle — ‘design with no blanks’ — remains. [inference]

강의 노트Lecture notes

5강 · 지시의 기술 ILesson 5 · The Art of Instruction I

Rule No.5 — 명령하지 말고 설계하라Rule No.5 — Don't command, design

강의 요약Summary

같은 일을 시켰는데 어제는 쓸 만한 답이, 오늘은 영 엉뚱한 답이 나옵니다. 왜 그럴까요. 모델이 변덕스러워서가 아니라, 우리가 던진 지시에 빈칸이 너무 많았기 때문입니다. “이 고객 문의 답장 좀 써줘”, “이번 달 매출 정리해줘” 같은 한 줄에는 무엇을, 누구를 위해, 어디까지, 어떤 모양으로 해야 하는지가 다 비어 있습니다. 빈칸이 많으면 모델은 그 자리를 자기 마음대로, 그럴듯한 걸로 채워 버립니다. 그래서 결과가 들쭉날쭉해지는 거죠.You give the same task, and yesterday it came back useful, today it came back completely off. Why? Not because the model is moody, but because the instruction you tossed it had too many blanks. A single line like “write a reply to this customer” or “sum up this month's sales” leaves it all empty — what, for whom, how far, in what shape. When there are many blanks, the model fills them however it likes, with whatever seems plausible. That's why the results come out all over the place.

이 강의의 핵심은 명령과 설계는 다른 일이라는 데 있습니다. 건축가가 “집 지어줘” 한 마디로 시작하지 않고 먼저 도면을 그리듯, 좋은 결과는 툭 던진 명령이 아니라 잘 설계된 지시에서 나옵니다. 명령은 한 줄 던지고 기대는 머릿속에만 두는 것이고, 설계는 그 기대를 빈칸 없이 글로 옮겨 적는 것입니다. 머릿속 기대를 종이에 옮긴 만큼, 딱 그만큼 결과가 좋아집니다. 명령하지 말고 설계하라 — 이것이 Rule No.5의 의미입니다.The heart of this lecture is that commanding and designing are different things. Just as an architect doesn't start with “build me a house” but draws a blueprint first, good results come not from a tossed command but from a well-designed instruction. A command tosses one line and keeps the expectation in your head; a design moves that expectation onto the page with no blanks left. The more you move it from your head onto paper, exactly that much better the result gets. Don't command, design — that is the meaning of Rule No.5.

그렇다면 무엇을 설계해야 할까요. 좋은 지시문이 채우는 칸은 다섯 개이고, 머리글자를 따 CRAFT라고 부릅니다. 첫째 맥락(Context) — 어떤 상황의, 어떤 자료를 두고 하는 일인지 배경을 줍니다. 둘째 역할(Role) — “베테랑 CS 담당자로서”처럼 누구의 눈으로 답할지를 정합니다. 셋째 행동(Action) — 무엇을, 어디까지 할지 범위와 금지선을 못 박습니다. 넷째 형식(Format) — 표인지 세 줄 요약인지, 받을 결과의 모양을 미리 정합니다. 다섯째 톤(Tone) — 누구를 위한, 어떤 어조인지를 맞춥니다. 보내기 전에 이 다섯 칸을 채웠는지 점검하면 빈칸이 남지 않습니다. 다만 과해도 독입니다 — 서로 부딪치는 제약을 주거나, 단순한 일까지 길게 늘어놓으면 오히려 결과가 나빠집니다. 설계의 목표는 빈칸을 없애는 것이지 말을 늘리는 게 아닙니다. 화면도 도구도 계속 바뀌겠지만, 명령 한 줄을 빈칸 없는 설계 한 단락으로 바꾼다는 이 원리는 그대로 남습니다.So what should you design? A good instruction fills five slots, and from their initials we call it CRAFT. First, Context — give the background: what situation, what materials is this work about. Second, Role — decide whose eyes it answers through, like “as a veteran CS agent.” Third, Action — pin down what to do and how far, the scope and the do-nots. Fourth, Format — decide the shape of the result up front, a table or a three-line summary. Fifth, Tone — match for whom and in what voice. Check these five slots before you hit send, and no blank is left. But overdoing it is poison too — give clashing constraints, or pile on words for a simple job, and the result actually gets worse. The goal of design is to remove blanks, not to add words. Screens and tools will keep changing, but this principle — turn one line of command into one paragraph of blank-free design — stays the same.

핵심 개념 5가지Five key concepts

  1. 01

    명령과 설계는 다른 일이다Commanding and designing are different things

    “이 문의 답장 좀 써줘”처럼 한 줄 던지는 것이 명령입니다. 이 안에는 빈칸이 너무 많습니다 — 어떤 상황인지, 누구로서, 어디까지, 어떤 모양으로 써야 하는지가 다 비어 있죠. 빈칸이 많으면 모델은 그 자리를 임의로 채우고, 그래서 결과가 매번 달라집니다. 설계는 그 빈칸을 미리 글로 메우는 일입니다. 건축가가 도면을 그리듯, 머릿속 기대를 종이에 옮긴 만큼 딱 그만큼 결과가 좋아집니다. 모델이 변덕스러운 게 아니라, 지시에 빈칸이 많았던 겁니다.Tossing one line like “write a reply to this inquiry” is a command. It has too many blanks — what situation, as whom, how far, in what shape, all empty. With many blanks, the model fills them at random, so the result changes every time. Designing is filling those blanks in writing ahead of time. Like an architect drawing a blueprint, the more you move the expectation from your head onto paper, exactly that much better the result gets. The model isn't moody — the instruction just had too many blanks.

  2. 02

    맥락(Context) — 어떤 상황·자료인지 배경을 준다Context — give the background and materials

    모델은 우리 매장 사정도, 이번 프로모션도, 그 고객이 누구인지도 모릅니다. 그래서 첫 번째 칸은 맥락입니다 — 어떤 상황에서, 어떤 자료를 두고 하는 일인지 배경을 함께 줍니다. “VIP 고객의 첫 반품 문의야”, “이건 추석 한정 기획전 매출이야”처럼 상황을 한 줄 깔아 주고, 판단의 근거가 될 자료(문의 원문, 매출 표, 리뷰 목록)를 붙여 줍니다. 맥락이 비면 모델은 일반 상식으로 빈칸을 메우고, 그러면 우리 사정과 어긋난 답이 나옵니다.The model doesn't know your store's situation, this promotion, or who that customer is. So the first slot is context — give the background of what situation and what materials this work is about. Lay down one line of situation, like “this is a VIP customer's first return inquiry” or “these are the sales for the Chuseok-limited event,” and attach the materials it should judge from (the original inquiry, the sales table, the list of reviews). When context is empty, the model fills the blank with general common sense, and you get an answer that clashes with your actual situation.

  3. 03

    역할(Role) — 누구의 눈으로 답할지 정한다Role — decide whose eyes it answers through

    두 번째 칸은 역할입니다. “리뷰 분석해줘”라고만 하면 모델은 누구의 눈으로 봐야 할지 모릅니다 — 가볍게 훑는 소비자일 수도, 깐깐한 품질 담당일 수도 있죠. 여기에 “10년차 상품기획 MD로서”, “베테랑 CS 담당자로서” 같은 역할 한 줄을 넣으면, 모델이 끌어올 패턴의 영역이 확 좁아집니다. 그 직무가 볼 법한 관점으로, 더 깊고 일관되게 답하죠. 거창한 직함이 아니라, 이 일을 누가 봐주면 좋겠는지를 한 줄로 정해 주는 것입니다.The second slot is role. Say only “analyze these reviews” and the model doesn't know whose eyes to look through — a casual shopper skimming, or a strict quality officer. Add one line of role like “as a merchandiser with ten years' experience” or “as a veteran CS agent,” and the region of patterns the model draws from narrows sharply. It answers from the viewpoint that job would take — deeper and more consistent. It's not a grand title; it's deciding, in one line, who you'd want to look at this work.

  4. 04

    행동(Action)·형식(Format) — 무엇을·어디까지, 어떤 모양으로Action and Format — what, how far, and in what shape

    세 번째와 네 번째 칸은 행동과 형식입니다. 행동은 무엇을, 어디까지 할지 범위와 금지선을 못 박는 일입니다 — “전체를 손대지 말고 별점 낮은 리뷰의 불만 사유만 추려”처럼요. 범위가 열려 있으면 모델은 시킨 것보다 많거나 적게 손대 버립니다. 형식은 받을 결과의 모양을 미리 정하는 일입니다 — “세 줄 요약으로”, “표 하나로, 사유별 건수 포함”처럼요. 형식을 정하면 매번 같은 모양으로 와서, 받자마자 바로 보고에 쓸 수 있습니다. 다시 다듬거나 “이렇게 말고 저렇게” 되묻는 왕복이 사라집니다.The third and fourth slots are action and format. Action pins down what to do and how far — the scope and the do-nots — like “don't touch the whole thing; just pull the complaint reasons from the low-star reviews.” When the scope is open, the model touches more or less than you asked. Format decides the shape of the result up front — “as a three-line summary,” “as a single table with counts per reason.” Fix the format and it comes back in the same shape every time, ready to drop into a report the moment you get it. The round-trip of reshaping it or asking “not like this, like that” disappears.

  5. 05

    톤(Tone)과 절제 — 어조를 맞추되 과하지 않게Tone and restraint — match the voice, but don't overdo it

    다섯 번째 칸은 톤입니다 — 누구를 위한, 어떤 어조인지. 같은 답장도 “화난 고객을 진정시키는 정중한 사과 톤”과 “내부 보고용 건조한 톤”은 완전히 다른 글이 됩니다. 보내기 전에 맥락·역할·행동·형식·톤, 이 다섯 칸을 채웠는지만 점검하면 빈칸이 안 남습니다. 다만 과해도 독입니다. “짧게 쓰되 다 담아줘”처럼 서로 부딪치는 제약을 주거나, 단순한 일까지 길게 늘어놓으면 오히려 결과가 나빠집니다. 설계의 목표는 빈칸을 없애는 것이지 말을 늘리는 게 아닙니다 — 일의 난이도에 설계의 양을 맞추세요.The fifth slot is tone — for whom and in what voice. The same reply becomes a completely different piece of writing as “a polite apology that calms an angry customer” versus “a dry tone for an internal report.” Just check these five slots before you send — context, role, action, format, tone — and no blank is left. But overdoing it is poison too. Give clashing constraints like “keep it short but include everything,” or pile on words for a simple job, and the result actually gets worse. The goal of design is to remove blanks, not to add words — match the amount of design to the difficulty of the task.

실습 예제Exercise

모호한 명령과 잘 설계한 지시문을 직접 나란히 비교해 봅니다. 코드도, 설정도 필요 없습니다 — Claude 대화창에 먼저 모호한 명령 한 줄을 넣어 보고, 그다음 CRAFT 다섯 칸을 채운 지시문을 넣어, 두 결과가 얼마나 다른지 눈으로 확인하는 연습입니다. 소재는 매장운영·CS에서 매일 마주치는 일 — 배송이 늦어 화가 난 고객의 문의에 답장 초안을 잡는 것입니다. 다섯 칸만 또렷하면 리뷰 분석이든 매출 요약이든 발주 검토든, 어떤 업무 지시도 같은 방식으로 설계할 수 있습니다 — C 맥락 · R 역할 · A 행동 · F 형식 · T 톤.Compare a vague command and a well-designed instruction side by side, yourself. No code, no config — first drop a single vague line into a Claude chat, then drop in an instruction that fills the five CRAFT slots, and see for yourself how differently the two come out. The subject is something CS and store-operations staff face every day: drafting a reply to a customer angry about a late delivery. Once the five slots are sharp, you can design any work instruction the same way — review analysis, sales summaries, purchase-order reviews — C context, R role, A action, F format, T tone.

복사해서 Claude 대화창에 붙여넣기Copy & paste into a Claude chat

[먼저 — 모호한 명령][First — the vague command]

다음 한 줄만 넣어 보세요.Drop in just this one line.

이 고객 문의 답장 좀 써줘: “주문한 지 일주일이 지났는데 아직도 배송이 안 됐어요. 언제 오는 거예요? 너무 화가 나네요.”Write a reply to this customer inquiry: “It's been a week since I ordered and it still hasn't shipped. When is it coming? I'm so angry.”

[그다음 — CRAFT로 설계한 지시문][Then — the CRAFT-designed instruction]

새 대화에서 아래를 통째로 넣어 보세요.In a fresh chat, paste the whole thing below.

  • [C 맥락] 우리는 온라인 패션 쇼핑몰이고, 아래는 배송 지연으로 화가 난 고객의 문의야. 이 고객은 첫 구매 고객이고, 실제 배송은 택배사 사정으로 2~3일 더 걸릴 예정이야.[C Context] We're an online fashion store, and below is an inquiry from a customer angry about a delayed delivery. This is a first-time buyer, and the actual delivery will take 2-3 more days due to the courier.
  • [R 역할] 너는 고객을 진정시키는 데 능숙한 베테랑 CS 담당자야.[R Role] You are a veteran CS agent skilled at calming customers down.
  • [A 행동] 이 문의에 대한 답장 ‘초안’만 잡아줘. 환불이나 보상을 네가 임의로 약속하지는 말고, 약속할 수 있는 범위 안에서만 써. 실제 발송은 사람이 한다.[A Action] Draft only a reply ‘draft’ for this inquiry. Don't promise refunds or compensation on your own — write only within what can be promised. A human does the actual sending.
  • [F 형식] (1) 사과 한 문장 (2) 현재 배송 상황 안내 (3) 다음 행동 안내, 이렇게 세 부분으로 나눠서 줘. 그리고 답장에 꼭 넣어야 하는데 내가 알려주지 않은 정보(주문번호 등)는 맨 아래 ‘확인 필요’ 목록으로 따로 빼줘.[F Format] Split it into three parts: (1) a one-sentence apology, (2) the current delivery status, (3) the next step. And any info the reply must include but I didn't give you (order number, etc.), pull out separately into a ‘needs confirmation’ list at the bottom.
  • [T 톤] 화가 난 고객을 진정시키는, 정중하고 진심 어린 사과 톤으로. 변명하는 느낌은 빼줘.[T Tone] A polite, sincere apology tone that calms an angry customer. Leave out any excuse-making feel.

고객 문의Customer inquiry

“주문한 지 일주일이 지났는데 아직도 배송이 안 됐어요. 언제 오는 거예요? 너무 화가 나네요.”“It's been a week since I ordered and it still hasn't shipped. When is it coming? I'm so angry.”

  1. 모호한 명령 먼저: Claude 대화창에 위 ‘[먼저]’ 블록의 한 줄 명령만 넣어 본다. 답장이 나오긴 하지만, 우리 매장 사정을 모른 채 무료 반품이나 빠른 배송을 멋대로 약속하거나, 톤이 너무 사무적이거나, 매번 길이와 모양이 달라질 것이다. 어디가 비어서 모델이 임의로 채웠는지를 눈으로 확인한다 — 이게 ‘빈칸이 만든 들쭉날쭉’이다.Vague command first: Drop only the one-line command from the ‘[first]’ block into a Claude chat. A reply will come, but it'll promise free returns or fast delivery on its own without knowing your store's situation, sound too bureaucratic, and change in length and shape every time. See with your eyes where it was empty and the model filled it at random — this is “the erraticness blanks create.”
  2. CRAFT로 설계해 비교: 새 대화를 열고 ‘[그다음]’ 블록의 다섯 칸짜리 지시문을 통째로 넣는다. 같은 문의인데 답장이 어떻게 달라지는지 본다 — 우리 사정(2~3일 추가)에 맞고, 사과·상황·다음 행동 세 부분으로 깔끔하고, 임의 약속 대신 ‘확인 필요’ 목록이 따로 빠져 있으면 설계가 통한 것이다. 두 결과를 나란히 두고 차이를 말로 정리해 본다.Design with CRAFT and compare: Open a fresh chat and paste in the five-slot instruction from the ‘[then]’ block whole. See how the reply changes for the same inquiry — if it fits your situation (the extra 2-3 days), is clean in three parts (apology, situation, next step), and pulls missing info into a separate “needs confirmation” list instead of making promises on its own, the design worked. Put the two results side by side and put the difference into words.
  3. 다섯 칸 떼보며 어느 칸이 일을 하나 확인: 설계한 지시문에서 한 칸씩 빼고 다시 돌려본다 — [R 역할]을 빼면 톤이 흔들리고, [F 형식]을 빼면 세 부분 구성이 무너지고, [A 행동]의 ‘임의 약속 금지’를 빼면 모델이 보상을 단정하기 시작한다. 어느 칸을 비우면 어떤 빈칸이 되살아나는지를 직접 보면, 다음부터 내 업무 지시에서 무엇을 못 박아야 하는지가 손에 잡힌다.Peel off the slots to see which one is doing the work: Remove the instruction's slots one at a time and re-run. Drop [R role] and the tone wobbles; drop [F format] and the three-part structure collapses; drop the “no promises on its own” in [A action] and the model starts flatly promising compensation. Seeing for yourself which blank comes back when you empty which slot gives you a feel for what to pin down in your own work instructions from now on.

전체 대본Full transcript

1 · 오프닝 — 명령하지 말고 설계하라1 · Opening — don't command, design

건축가는 “집 지어줘” 한 마디로 일을 시작하지 않습니다. 먼저 도면을 그리죠. 어디에 방을 두고, 어떤 자재를 쓰고, 동선을 어떻게 할지를 설계합니다. 프롬프트도 똑같아요. 좋은 결과는 그냥 던진 명령 한 줄이 아니라, 잘 설계된 지시에서 나옵니다. 오늘은 룰 넘버 파이브, “명령하지 말고 설계하라”를 가지고, 프롬프트를 설계하는 법을 배워보겠습니다. 맥락, 역할, 행동, 형식, 그리고 톤. 이 다섯 가지가 오늘의 도구입니다. 이 강을 마치면, 막연한 한 줄 명령을 다섯 칸 설계로 바꿔 재요청 없는 결과를 받을 수 있습니다.An architect doesn't start a job with “build me a house.” They draw a blueprint first — where the rooms go, what materials to use, how people will move through it. A prompt is the same. Good results come not from a single tossed command, but from a well-designed instruction. Today, under Rule Number Five — “don't command, design” — we'll learn how to design a prompt: context, role, action, format, and tone. These five are today's tools. By the end of this session, you'll be able to turn a vague one-line command into a five-slot design and get results that need no follow-up.

2 · 훅 — 시간을 줘도 모호하면 소용없다2 · Hook — time is wasted if it's vague

지난 시간엔 어려운 문제일수록 생각할 시간을 주라고 했죠. 그런데 한 가지 함정이 있어요. 아무리 충분히 생각할 시간을 줘도, 정작 무엇을 시킬지가 모호하면 그 시간이 다 소용없어집니다. 여기 보세요. “이거 좀 고쳐줘”, “정리 좀 해줘”. 우리가 평소에 정말 많이 던지는 말이죠.Last time we said the harder the problem, the more thinking time you should give. But there's a trap. No matter how much thinking time you give, if what you're asking for is vague, all that time is wasted. Look here: “just fix this,” “clean this up.” These are the kinds of things we toss out all the time.

문제는, 이런 말 안에는 빈칸이 너무 많다는 거예요. 무엇을, 어디까지, 어떤 모양으로 고치라는 건지가 다 비어 있습니다. 그러면 모델은 그 빈칸을 자기 마음대로, 그럴듯한 걸로 채워버려요. 그래서 오늘 기억할 건 이겁니다. 생각할 시간을 주는 레버와, 무엇을 어떻게 시킬지 설계하는 레버는 완전히 별개예요. 둘 다 갖춰야 결과가 삽니다. 오늘은 그중 ‘지시 레버’를 다룹니다.The problem is, sentences like these have too many blanks. What to fix, how far to go, what shape it should take — it's all empty. So the model fills those blanks however it likes, with whatever seems plausible. So here's what to remember today: the lever that gives thinking time and the lever that designs what and how you ask are completely separate. You need both for the result to come alive. Today we work the ‘instruction lever.’

3 · 모호한 지시의 3가지 실패3 · Three failures of vague instruction

모호한 지시는 보통 세 가지 방식으로 어긋납니다. 첫째, 엉뚱한 범위예요. 내가 원한 것보다 훨씬 많이 손대거나, 아니면 너무 적게 하고 멈춰버립니다. 둘째, 일관성 없는 형식이에요. 같은 걸 물어도 어떤 날은 표로, 어떤 날은 줄글로, 매번 출력 모양이 달라집니다. 셋째, 빗나간 톤과 관점이에요. 전문가용으로 쓰랬더니 초보자용으로 쓰거나, 어조가 엉뚱하게 나옵니다.A vague instruction usually goes wrong in three ways. First, the wrong scope — it touches far more than you wanted, or does too little and stops. Second, inconsistent format — ask the same thing and one day you get a table, another day a paragraph; the shape changes every time. Third, off tone and viewpoint — you asked for an expert audience and got a beginner's tone, or the voice just lands wrong.

여기서 핵심은, 이게 모델의 버그가 아니라는 거예요. 지난 강에서 Claude는 사실 저장고가 아니라 패턴 생성기라고 했죠. 입력이 출력의 분포를 정합니다. 그러니까 입력에 빈칸이 많으면, 가능한 출력의 범위가 그만큼 넓어져요. 넓은 분포는 들쭉날쭉한 결과입니다. 거꾸로, 빈칸을 제약으로 하나씩 메우면 그 분포가 좁아지고, 결과가 예측 가능해집니다. 이게 오늘 설계의 출발점이에요.The key here is that this isn't the model's bug. Last session we said Claude is a pattern generator, not a fact vault. The input sets the distribution of the output. So when the input has many blanks, the range of possible outputs widens. A wide distribution means an erratic result. Conversely, when you fill those blanks one by one with constraints, the distribution narrows and the result becomes predictable. That's the starting point of design today.

4 · Before/After ① — 역할 부여4 · Before/After ① — assigning a role

이제 나쁜 프롬프트와 좋은 프롬프트를 나란히 놓고 비교해 볼게요. 첫 번째 빈칸은 역할입니다. 비포를 볼까요. “이 매출 데이터 분석해줘.” 이러면 모델은 누구의 눈으로 봐야 할지를 몰라요. 초보자 관점일 수도, 운영팀 관점일 수도, 아니면 전략 기획 관점일 수도 있죠.Now let's put a bad prompt and a good prompt side by side. The first blank is the role. Look at the “before”: “Analyze this sales data.” Here the model doesn't know whose eyes to look through. It could be a beginner's view, an operations view, or a strategic planning view.

이제 애프터를 보세요. “이천이십사년 사분기 전국 편의점 카테고리별 매출 데이터를 분석해줘. BA 십 년 경력 관점에서 이상치와 성장 기회를 찾아주고, 결과는 임원 보고용 형식으로 정리해줘.” 역할 한 줄을 넣었을 뿐인데, 모델이 끌어올 패턴의 영역이 확 좁아집니다. 시니어 BA가 볼 법한 관점으로, 더 깊고 일관되게 답하죠. 누구로서 답할지를 정하는 것. 이게 우리가 채울 첫 번째 빈칸입니다.Now look at the “after”: “Analyze Q4 2024 national convenience store sales by category. As a BA with ten years of experience, identify anomalies and growth opportunities. Format for an executive report.” Just by adding one line of role, the region of patterns the model draws from narrows sharply. It answers from the viewpoint a senior BA would take — deeper and more consistent. Deciding who it answers as: that's the first blank we fill.

5 · Before/After ② — 제약 명시5 · Before/After ② — stating constraints

두 번째 빈칸은 제약입니다. 비포는 이래요. “재고 현황 보고서 써줘.” 이러면 모델이 에스케이유 데이터를 멋대로 바꾸거나, 모든 품목을 다 나열하거나, 아니면 필요 없는 섹션을 잔뜩 만들 수도 있어요. 범위가 완전히 열려 있으니까요.The second blank is constraints. The “before” goes: “Write a stock inventory report.” Here the model might alter the per-SKU data however it likes, list every single item, or add a whole set of sections you don’t need. The scope is wide open.

애프터를 보세요. “에스케이유별 데이터는 바꾸지 말고, 카테고리 요약만 추가해줘. 회전율이 낮은 품목은 상위 다섯 개만 표로 정리해서.” 하지 말 것, 할 것, 그리고 범위까지 다 못 박았죠. 이렇게 제약을 걸면 출력의 공간이 확 좁아지면서, 아까 봤던 ‘엉뚱한 범위’ 실패를 직접 막아줍니다. 빈칸은 곧 모델의 자유고, 그 자유가 위험이에요. 못 박을수록 결과는 예측 가능해집니다.Now the “after”: “Don’t change the per-SKU data; add a category summary only. List slow-moving items as a table, top five only.” You’ve pinned down what not to do, what to do, and how many. Setting constraints like this sharply narrows the output space and directly blocks that “wrong scope” failure we saw earlier. A blank is the model’s freedom, and that freedom is the risk. The more you pin down, the more predictable the result.

6 · Before/After ③ — 출력 형식 지정6 · Before/After ③ — specifying output format

세 번째 빈칸은 출력 형식입니다. 비포는 “요약해줘.” 한 마디죠. 그러면 어떤 날은 긴 문단으로, 어떤 날은 표로, 어떤 날은 불릿 열 개로 옵니다. 매번 모양이 달라요. 아까 봤던 ‘일관성 없는 형식’ 실패가 바로 여기서 나옵니다.The third blank is the output format. The “before” is just “summarize this.” Then one day it comes as a long paragraph, another day a table, another day ten bullets. The shape changes every time. That “inconsistent format” failure we saw earlier comes straight from here.

애프터를 보세요. “세 개 불릿으로, 각 줄 열다섯 자 이내, 핵심 수치 포함해서 요약해줘.” 받을 결과의 모양을 미리 못 박았죠. 이렇게 하면 일관성이 생길 뿐 아니라, 받자마자 바로 쓸 수 있어요. 다시 다듬거나 “이렇게 말고 저렇게 줘” 하고 재요청하는 비용이 사라집니다. 결과의 모양을 정하는 것도, 엄연히 설계의 일부예요.Now the “after”: “summarize in three bullets, each under fifteen characters, with the key numbers.” You've pinned down the shape of the result in advance. This not only creates consistency — you can use it the moment you get it. The cost of reshaping it or asking again, “not like this, like that,” disappears. Deciding the shape of the result is, squarely, part of the design.

7 · 한 장 비교 — 명령 vs 설계7 · One-page compare — command vs design

지금까지 본 세 가지 비포 애프터를 한 장으로 정리하면 이렇습니다. 왼쪽이 명령이에요. 한 줄 툭 던지고, 기대는 머릿속에만 있고, 그래서 결과는 들쭉날쭉하고, 매번 다시 요청하게 됩니다. 오른쪽이 설계예요. 맥락과 역할과 제약과 형식을 다 적어주고, 기준을 명시하니까, 결과가 일관되고, 한 번에 바로 쓸 수 있습니다.If I put the three before-and-afters we've seen onto one page, here it is. On the left is command: you toss one line, the expectation lives only in your head, so results come out erratic and you re-ask every time. On the right is design: you write out the context, role, constraints, and format, you state the criteria — so results are consistent and usable in one shot.

차이의 본질은 딱 하나, 명시성이에요. 머릿속에 있던 기대를 글로 옮긴 만큼, 딱 그만큼 결과가 좋아집니다. 이 한 장이 오늘 강의의 다리예요. 지금까지 본 이 명시 항목들을, 다음 막에서 외우기 쉬운 다섯 글자로 묶어드리겠습니다.The essence of the difference is just one thing: explicitness. The more you move the expectation from your head onto the page, exactly that much better the result gets. This one page is the bridge of today's talk. In the next act, I'll tie all these explicit items into five easy-to-remember letters.

8 · 왜 설계가 통하나 — 메커니즘8 · Why design works — the mechanism

그럼 왜 설계가 통할까요? 메커니즘은 지난 강에서 본 그대로입니다. Claude는 입력을 받아서, 다음에 올 단어의 확률 분포를 만드는 패턴 생성기예요. 위쪽 흐름을 보세요. 모호한 입력이 들어가면, 가능한 출력의 분포가 아주 넓어집니다. 넓은 분포에서 뽑으니 결과가 들쭉날쭉하죠.So why does design work? The mechanism is exactly what we saw last session. Claude takes the input and builds a probability distribution over the next word — it's a pattern generator. Look at the top flow: when vague input goes in, the distribution of possible outputs gets very wide. Drawing from a wide distribution, the result comes out erratic.

아래쪽 흐름을 보세요. 설계된 입력이 들어가면, 출력 분포가 좁아집니다. 좁은 분포에서 뽑으니 결과가 일관돼요. 두 경우 모델은 완전히 똑같습니다. 입력만 달라요. 그러니까 설계라는 건, 결국 그 출력 분포를 내가 의도한 쪽으로 좁히는 일이에요. 여기서 중요한 통찰이 나옵니다. 더 똑똑한 모델로 갈아타는 것보다, 더 좋은 입력을 주는 게 훨씬 빠른 지렛대라는 거죠.Now look at the bottom flow: when designed input goes in, the output distribution narrows. Drawing from a narrow distribution, the result comes out consistent. In both cases the model is exactly the same. Only the input differs. So design, in the end, is the work of narrowing that output distribution toward what you intend. And here's the key insight: giving better input is a far faster lever than switching to a smarter model.

9 · CRAFT 프레임워크 — 5요소9 · The CRAFT framework — five elements

자, 오늘의 핵심입니다. 지금까지 본 빈칸들을 외우기 쉽게 다섯 글자로 묶어볼게요. 크래프트입니다. 씨는 맥락이에요. 배경, 데이터, 예시를 주는 겁니다. 알은 역할. 누구로서 답할지죠. 에이는 행동이에요. 무엇을, 어디까지 할지입니다.Alright, today's peak. Let me tie the blanks we've seen into five easy letters. It's CRAFT. C is Context — giving background, data, examples. R is Role — who it answers as. A is Action — what to do, and how far.

에프는 형식이에요. 받을 결과의 모양이죠. 티는 톤. 누구를 위한 어떤 어조인지입니다. 맥락, 역할, 행동, 형식, 톤. 이 다섯 칸이에요. 앞에서 본 역할, 제약, 형식이 바로 이 알, 에이, 에프에 들어맞죠. 한 가지만 짚고 갈게요. 크래프트는 공식 표준이 아니라, 널리 쓰이는 암기용 니모닉입니다. 자료마다 이름이나 순서는 조금씩 달라요. 하지만 다루는 축, 그러니까 맥락, 역할, 행동, 형식, 톤은 공통입니다. 이 다섯 칸만 의식하면, 프롬프트에 빈칸이 안 남아요.F is Format — the shape of the result you get. T is Tone — for whom, in what voice. Context, role, action, format, tone. These are the five slots. The role, constraints, and format we saw earlier map right onto this R, A, and F. One thing to flag: CRAFT isn't an official standard — it's a widely used mnemonic for memorizing. The name and order differ a bit across sources. But the axes it covers — context, role, action, format, tone — are common to all. Just stay aware of these five slots, and no blanks are left in your prompt.

10 · CRAFT 적용 한 컷 — Before→After10 · CRAFT in one shot — Before→After

다섯 칸을 다 채우면 한 줄짜리 명령이 어떻게 바뀌는지 한 컷으로 보겠습니다. 비포는 이거예요. “이 에이피아이 문서 좀 정리해줘.” 전형적인 빈칸투성이 명령이죠. 이제 다섯 칸을 차례로 채워볼게요. 맥락 부분, 이 문서는 신규 입사자가 처음 읽는 거야. 역할 부분, 테크니컬 라이터로서. 행동 부분, 엔드포인트별 용도만 추려서.Let me show in one shot how a one-line command transforms when you fill all five slots. The “before” is: “clean up this API doc.” A classic blank-filled command. Now let's fill the five slots in turn. The context part: this is the first doc new hires read. The role part: as a technical writer. The action part: pull out each endpoint's purpose only.

형식 부분, 표 하나로. 그리고 톤 부분, 비전공자도 읽을 수 있게 쉽게. 보세요. 똑같은 “문서 정리”인데, 다섯 칸을 채우니까 완전히 다른 결과가 나옵니다. 무엇보다, 다시 요청할 일이 없어져요. 모호함이 만들던 왕복 비용이 통째로 사라집니다. 설계하는 데 든 몇 초는, 한 번에 바로 쓸 수 있는 결과로 그대로 회수됩니다.The format part: as a single table. And the tone part: easy enough for a non-expert to read. Look — it's the same “clean up the doc,” but filling the five slots produces a completely different result. Above all, there's nothing to re-ask. The round-trip cost that vagueness created vanishes entirely. The few seconds you spent designing come right back as a result you can use in one shot.

11 · 보내기 전 5가지 체크11 · Five checks before you send

이제 실전 체크리스트입니다. 프롬프트를 보내기 전에, 크래프트 다섯 글자로 점검하세요. 씨, 맥락을 줬나? 배경과 데이터, 예시를 같이 줍니다. 알, 역할을 정했나? 누구로서 답할지를 정해줍니다. 에이, 행동이 구체적인가? 무엇을 어디까지 할지를 못 박습니다.Now the practical checklist. Before you send a prompt, check it with the five letters of CRAFT. C — did you give the context? Hand over the background, the data, and examples. R — did you set the role? Decide who it answers as. A — is the action specific? Pin down what to do and how far.

에프, 형식을 지정했나? 받을 결과의 모양을 정합니다. 티, 톤을 맞췄나? 누구를 위한 어떤 어조인지를 정합니다. 보셨죠? 이 다섯 항목이 아까 본 크래프트 다섯 요소와 하나씩 정확히 짝을 이룹니다. 그래서 프레임워크 하나만 알면, 이 체크리스트는 따로 외울 필요도 없어요. 다섯 글자만 떠올리면 됩니다.F — did you specify the format? Decide the shape of the result you'll get. T — did you match the tone? Decide for whom and in what voice. See it? These five items pair up exactly, one by one, with the five CRAFT elements we just saw. So once you know the one framework, you don't even need to memorize this checklist separately. Just recall the five letters.

12 · 한 줄로 굳히기 — 공식12 · In one line — the formula

오늘 배운 걸 한 줄로 정리해볼게요. 좋은 프롬프트는, 맥락 더하기 역할 더하기 행동 더하기 형식 더하기 톤. 이 다섯 칸을 다 채워서, 빈칸을 영 개로 만드는 겁니다. 명령 한 줄을, 설계된 한 단락으로 바꾸는 거예요. 이게 룰 넘버 파이브, “설계하라”를 한 줄로 요약한 거고요. 결국 핵심은, 머릿속에만 있던 기대를 빈칸 없는 글로 옮기는 일입니다.Let me lock today into one line. A good prompt is context plus role plus action plus format plus tone — filling all five slots so the blanks come to zero. You turn one line of command into one designed paragraph. This is Rule Number Five, “design,” summed up in a line. In the end, the core is moving the expectation that lived only in your head onto the page, with no blanks left.

13 · 함정 — 설계의 과유불급13 · The trap — too much design

마지막으로 함정 하나만 짚고 가겠습니다. 모호함이 문제라고 해서, 무조건 길고 빽빽하게 쓰는 게 정답은 아니에요. 과한 지시도 똑같이 문제입니다. 첫째, 모순된 제약이에요. “짧게 쓰되 모든 걸 다 담아줘” 처럼 서로 부딪히는 조건을 주면 결과가 오히려 나빠집니다. 둘째, 불필요한 장식이에요. 말이 너무 많으면 정작 핵심이 묻혀버려요. 셋째, 단순한 작업까지 과하게 설계하는 거예요. 비용과 시간 낭비죠. 설계의 목표는 빈칸을 없애는 거지, 말을 늘리는 게 아닙니다. 지난 강에서 난이도에 생각 예산을 맞춘 것처럼, 작업 난이도에 설계의 양을 맞추세요. 단순한 일엔 단순한 지시면 충분합니다.Finally, let me flag one trap. Just because vagueness is a problem doesn't mean longer and denser is always the answer. Over-instruction is just as much of a problem. First, conflicting constraints. Give clashing conditions like “keep it short but include everything,” and the result actually gets worse. Second, needless decoration. Too many words and the point gets buried. Third, over-designing even simple tasks — that's wasted cost and time. The goal of design is to remove blanks, not to pile on words. Just as last session we matched the thinking budget to the difficulty, match the amount of design to the task's difficulty. For a simple job, a simple instruction is enough.

14 · 마무리 · 다음 강 예고14 · Wrap-up · next lesson

오늘 한 단어만 가져가신다면, 명령에서 설계로, 입니다. 건축가가 도면을 그리듯, 프롬프트도 던지지 말고 설계하세요. 무엇을, 누구로서, 어디까지, 어떤 모양으로, 어떤 어조로. 이 다섯 칸을 채우면 빈칸이 사라지고, 결과가 살아납니다. 도구와 화면은 계속 바뀌겠지만, 빈칸 없이 설계하라는 이 원리는 그대로예요. 다음 시간에는 지시의 기술 그 두 번째, 더 깊은 설계 기법으로 들어가 보겠습니다.If you take one word from today, it's: from command to design. Just as an architect draws a blueprint, don't toss a prompt — design it. What, as whom, how far, in what shape, in what voice. Fill these five slots and the blanks disappear, and the result comes alive. Tools and screens will keep changing, but this principle — design with no blanks — stays the same. Next time, we go into the Art of Instruction, part two: deeper design techniques.