1 · 오프닝 — 예시가 설명보다 강하다1 · Opening — Examples beat explanations

누군가에게 요리 하나를 알려준다고 해볼게요. 백 단어로 빛깔이며 농도며 담는 모양을 설명하는 것보다, 완성된 접시를 한 번 보여주는 게 훨씬 빠르고 정확합니다. 프롬프트도 똑같아요. 좋은 결과는 긴 설명이 아니라, 잘 고른 예시 한 개에서 나옵니다. 오늘은 룰 넘버 식스, "예시가 설명보다 강하다"를 가지고, 예시로 시연하는 법을 배워보겠습니다. 보여주기, 부정에서 긍정으로 뒤집기, 그리고 맥락과 예시의 비중. 이 세 가지가 오늘의 도구입니다.Say you're teaching someone a dish. Rather than describing the color, the consistency, the plating in a hundred words, showing them the finished plate once is far faster and more accurate. A prompt is the same. Good results come not from long explanation, but from one well-chosen example. Today, under Rule Number Six — "examples beat explanations" — we'll learn how to demonstrate with examples: showing, flipping a "don't" into a "do," and the balance between context and example. These three are today's tools.

2 · 훅 — 같은 의도, 다른 전달2 · Hook — Same intent, different delivery

지난 시간엔 좋은 프롬프트는 다섯 칸, 그러니까 크래프트를 빈칸 없이 채우는 설계라고 했죠. 그런데 한 가지 함정이 있어요. 그 칸을 '설명'으로만 길게 채우면, 길어질수록 오히려 빗나갑니다. 여기 보세요. "항목을 깔끔하게, 적절히 정리하되, 줄바꿈은 알아서, 단 너무 길지 않게, 그리고…" 우리가 형식을 시킬 때 정말 자주 하는 말이죠.Last time we said a good prompt is a design that fills five slots — CRAFT — with no blanks left. But there's a trap. If you fill those slots with explanation alone, stretched out long, the longer it gets, the more it actually misses. Look here: "organize the items neatly, appropriately, break lines as you see fit, but not too long, and…" This is the kind of thing we say all the time when we ask for a format.

문제는, 이렇게 말로 풀수록 모델이 해석해야 할 게 늘어난다는 거예요. "깔끔하게"가 정확히 뭐지? "적절히"는 어느 정도지? "너무 길지 않게"는 몇 줄이지? 말이 길어질수록 빈칸이 줄기는커녕, 해석할 거리가 늘어납니다. 그래서 오늘 기억할 건 이거예요. 지난 강이 '무엇으로 칸을 채울까'였다면, 오늘은 '그 칸을 어떻게 채워야 가장 강하게 전달되나'입니다. 답은 하나예요. 설명하지 말고, 보여주세요. 오늘은 그 '전달 레버'를 다룹니다.The problem is, the more you spell it out in words, the more the model has to interpret. What exactly is "neatly"? How much is "appropriately"? How many lines is "not too long"? The longer the words run, far from reducing the blanks, the more there is to interpret. So here's what to remember today: if last session was about what to fill the slots with, today is about how to fill them so they land hardest. The answer is one thing: don't tell — show. Today we work that 'delivery lever.'

3 · 설명의 3가지 함정3 · The three traps of explanation

설명은 보통 세 군데에서 샙니다. 첫째, 모호한 말이에요. "깔끔하게", "적절히", "자연스럽게" 같은 말은 듣기엔 좋은데, 사람마다 떠올리는 그림이 다 달라요. 모델도 마찬가지죠. 둘째, 누락이에요. 우리가 머릿속에 가진 규칙을 말로는 절대 다 적지 못합니다. 적지 않은 암묵 규칙이 계속 새어나가요. 셋째, 길이 자체가 노이즈가 됩니다. 설명이 길어질수록, 정작 가장 중요한 한 가지가 그 안에 묻혀버려요.Explanation usually leaks in three places. First, vague words. "Neatly," "appropriately," "naturally" — they sound good, but everyone pictures something different. So does the model. Second, omission. We can never write out in words all the rules we carry in our heads; the unwritten, implicit rules keep leaking. Third, length itself becomes noise. The longer the explanation runs, the more the single most important thing gets buried inside it.

여기서 핵심은, 이게 모델의 버그가 아니라 '말'이 가진 한계라는 거예요. 지난 강의들에서 봤듯이 Claude는 입력으로 출력의 분포를 만드는 패턴 생성기죠. 모호한 말이 들어가면 가능한 출력의 분포가 넓어지고, 결과가 들쭉날쭉해집니다. 그런데 예시는 달라요. 예시는 그 넓은 분포를 한 점으로 콕 찍어줍니다. 그래서 결론은 단순해요. 말로 못 박을 것 같으면, 보여주세요.The key here is that this isn't the model's bug — it's a limit of words themselves. As we saw in earlier sessions, Claude is a pattern generator that builds the output distribution from the input. When vague words go in, the distribution of possible outputs widens and the result turns erratic. But an example is different. An example pins that wide distribution to a single point. So the conclusion is simple: when you can't nail it down in words, show it.

4 · Before/After ① — 형식을 예시로4 · Before/After ① — Format as an example

이제 설명과 예시를 나란히 놓고 비교해 볼게요. 첫 번째는 형식입니다. 비포를 보세요. "각 항목을 대시로 시작하고, 콜론 뒤에 값을 쓰고, 들여쓰기는 두 칸으로, 그리고…" 이렇게 형식을 말로 풀면, 듣는 쪽은 이걸 하나하나 머릿속에서 조립해야 해요. 한 군데만 어긋나도 결과가 틀어집니다.Now let's put telling and showing side by side. The first is format. Look at the "before": "start each item with a dash, put the value after a colon, indent two spaces, and…" When you spell out a format in words like this, the listener has to assemble it piece by piece in their head. One slip anywhere, and the result is off.

이제 애프터를 보세요. "이 형식으로:" 하고 고객 안내 카드 형식을 딱 보여줍니다. 처리 방법은 한 줄, 예상 소요는 한 줄. 이게 끝이에요. 예시 한두 줄을 보여주면 해석할 게 아예 없어집니다. 모델은 그냥 보여준 패턴을 그대로 따라 하면 되니까요. 이걸 흔히 퓨샷, 그러니까 예시를 몇 개 보여주는 방식이라고 부릅니다. 마법은 아니고, 널리 쓰이는 프롬프팅 방법이에요. 핵심은 이거예요. '말하기'가 첫 번째 함정이고, '보여주기'가 그 탈출구입니다.Now look at the "after": you say "in this format:" and show a customer notice card layout. How we handle it — one line. Expected time — one line. That's it. Show one or two lines of example and there's nothing left to interpret — the model just copies the pattern you showed. This is often called few-shot, meaning you show a few examples. It's not magic; it's a widely used prompting method. The point is this: telling is the first trap, and showing is the way out.

5 · Before/After ② — 부정 지시의 한계5 · Before/After ② — The limit of negative instruction

두 번째는 부정 지시입니다. 비포를 보세요. "이모지 쓰지 마. 너무 길게 쓰지 마. 격식 차리지 마." 우리가 톤을 잡을 때 정말 자주 하는 말이죠. 그런데 잘 보면, 이건 전부 '하지 말 것'만 말하고 있어요. 그럼 정작 '뭘 하라'는 거지는 텅 비어 있습니다.The second is negative instruction. Look at the "before": "no emoji. don't write too long. don't be formal." This is the kind of thing we say all the time when setting a tone. But look closely — it's all about what not to do. What you actually should do is left completely empty.

금지만 하면, 금지하지 않은 나머지 공간이 통째로 남아요. 그 넓은 공간을 모델이 자기 마음대로 채워버립니다. 이제 애프터를 보세요. "이런 톤으로:" 하고 예시를 줍니다. "안녕하세요, 핵심만 세 줄로 정리했습니다." 원하는 톤을 직접 보여준 거죠. 부정은 목표 근처의 일부만 잘라낼 뿐, 어디로 가라고는 안 합니다. 긍정과 예시는 목표 지점을 콕 찍어줘요. 그러니까 '하지 마라'를 만나면, '대신 이렇게 하라'를 예시로 바꿔주세요.When you only ban, all the space you didn't ban is left wide open, and the model fills that space however it likes. Now look at the "after": you say "in this tone:" and give an example — "Hi, here are the key points in three lines." You've shown the tone you want, directly. A ban only cuts away part of the area near the target; it never says where to go. The positive plus an example pins the target point exactly. So whenever you hit a "don't," turn it into a "do this instead," shown as an example.

6 · Before/After ③ — 좋은 예시 vs 나쁜 예시6 · Before/After ③ — Good example vs bad example

세 번째는 한 단계 더 들어갑니다. 예시가 강하다고 했는데, 그럼 아무 예시나 보여주면 될까요? 그렇지 않아요. 비포를 보세요. 나쁜 예시입니다. 실제 작업과는 동떨어졌거나, 한쪽으로 치우친 예시예요. 예를 들어 전부 짧고 쉬운 케이스만 보여주는 거죠. 그러면 모델은 "아, 이건 짧게만 처리하면 되는 일이구나" 하고 그 편향을 그대로 배워버립니다.The third one goes a step deeper. We said examples are powerful — so does any example do? No. Look at the "before": a bad example. It's off from the real task, or skewed to one side — say, showing only short, easy cases. Then the model learns, "Ah, this is a job I just handle briefly," and picks up that bias exactly as shown.

이제 애프터를 보세요. 좋은 예시입니다. 실제 작업과 닮았고, 다양한 경우를 담았고, 까다로운 엣지 케이스도 하나 넣었고, 예시끼리 형식이 일관돼요. 모델은 보여준 예시의 패턴을 그대로 따라 합니다. 그러니 편향된 예시를 주면 편향된 출력이 나오고, 골고루 대표하는 예시를 주면 골고루 대표하는 출력이 나와요. 그래서 좋은 예시의 조건은 셋입니다. 대표성, 다양성, 그리고 형식 일관. 예시는 아무거나가 아니라, 골라서 보여주는 거예요.Now look at the "after": a good example. It resembles the real task, it covers a range of cases, it includes one tricky edge case, and the examples are consistent in format with each other. The model imitates the pattern of the examples you show, exactly. So give it a biased example and you get biased output; give it examples that represent the range, and you get output that represents the range. That's why a good example has three conditions: representativeness, diversity, and format consistency. You don't show just any example — you choose it.

7 · 한 장 비교 — 설명 vs 예시7 · One-page comparison — telling vs showing

지금까지 본 걸 한 장으로 정리해 볼게요. 왼쪽이 설명이에요. 듣는 쪽이 해석을 해야 하고, 말로 못 적은 암묵 규칙은 누락되고, 길어질수록 노이즈가 끼고, 같은 말도 매번 다르게 이해됩니다. 오른쪽이 예시예요. 해석이 필요 없고, 말로 못 적는 암묵 규칙까지 보여주는 걸로 전달되고, 짧아도 정확하고, 보여준 패턴을 그대로 모방합니다.Let me put everything we've seen onto one page. On the left is telling. The listener has to interpret, the implicit rules you couldn't write down get dropped, noise creeps in as it gets longer, and the same words are understood differently each time. On the right is showing. No interpretation needed, even the implicit rules you can't put into words get carried by the example, it's accurate even when short, and the shown pattern is imitated as-is.

차이의 본질은 딱 하나, 해석 부담이에요. 보여준 만큼, 모델이 혼자 짐작해야 할 일이 줄어듭니다. 이 한 장이 오늘 강의의 다리예요. 그런데 한 가지 의문이 남죠. 도대체 왜, 예시는 이렇게까지 잘 통할까요? 다음 막에서 그 메커니즘을 들여다보겠습니다.The essence of the difference is just one thing: the burden of interpretation. The more you show, the less the model has to guess on its own. This one page is the bridge of today's talk. But one question remains: why, exactly, do examples work this well? In the next act, we'll look inside that mechanism.

8 · 왜 예시가 통하나 — 메커니즘8 · Why examples work — the mechanism

그럼 왜 예시가 통할까요? 메커니즘은 지난 강의들에서 본 그대로입니다. Claude는 의미를 깊이 '이해'한 다음에 답하는 게 아니라, 다음에 올 토큰을 확률로 이어붙이는 패턴 생성기예요. 흐름을 보세요. 먼저 예시로 '이 입력에는 이 출력'이라는 한 쌍을 보여줍니다. 그러면 모델은 그 안에 깔린 패턴을 인식해요.So why do examples work? The mechanism is exactly what we saw in earlier sessions. Claude doesn't deeply 'understand' the meaning and then answer — it's a pattern generator that strings together the next token by probability. Look at the flow. First you show a pair with an example: "for this input, this output." Then the model recognizes the pattern underneath it.

여기가 핵심이에요. 설명은 그 패턴을 '말로' 좁히려고 애쓰는 거고, 예시는 그 패턴을 '직접' 한 점으로 찍어주는 거예요. 지난 강에서 입력이 출력 분포를 정한다고 했죠. 예시는 그 분포를 가장 빠르게, 가장 좁게 만드는 입력입니다. 새 입력이 들어오면 모델은 방금 인식한 그 패턴을 그대로 적용하고, 그래서 일관된 출력이 나와요. 이게 바로, 설명 백 단어보다 잘 고른 예시 한 개가 더 강한 이유입니다.Here's the key. Explanation tries to narrow that pattern with words; an example pins that pattern directly to a single point. Last session we said the input sets the output distribution. An example is the input that makes that distribution narrow fastest and tightest. When a new input comes in, the model applies the pattern it just recognized, as-is, and out comes a consistent output. This is exactly why one well-chosen example beats a hundred words of explanation.

9 · 부정 → 긍정 전환 — 메커니즘9 · Don't → do — the mechanism

앞에서 본 부정 지시도 같은 원리로 설명됩니다. 왼쪽을 보세요. "이모지 쓰지 마." 이건 출력 공간에서 이모지가 있는 영역만 잘라낸 거예요. 그런데 잘라내고 남은 공간이 여전히 어마어마하게 넓습니다. 그 넓은 공간 어디로 갈지는 아무것도 안 정해줬어요. 그러니 모델은 그 안에서 또 아무거나 그럴듯한 걸 고릅니다.The negative instruction we saw earlier is explained by the same principle. Look at the left: "no emoji." This just cuts out the region of the output space that has emoji. But the space left after that cut is still enormously wide, and you've said nothing about where in it to go. So the model again picks whatever seems plausible inside it.

오른쪽을 보세요. "이런 톤으로 써" 하고 예시를 줍니다. 이건 그 넓은 공간 안에서 목표 지점을 딱 한 점으로 찍어준 거예요. 금지는 공간을 비우기만 하고, 시연은 그 공간을 채웁니다. 그래서 변환 규칙은 아주 단순해요. 프롬프트에서 '하지 마'를 발견하면, 그 자리에 '그럼 대신 무엇을'을 예시로 적어주세요. '하지 마'를 '이렇게 해'로 번역하는 겁니다.Look at the right: you say "write in this tone" and give an example. This pins the target to a single point inside that wide space. A ban only empties the space; a demonstration fills it. So the conversion rule is very simple. When you spot a "don't" in your prompt, write in its place "then what to do instead," as an example. You're translating "don't" into "do this."

10 · 콘텍스트 vs 예시 비중10 · Context vs example balance

그럼 예시만 잔뜩 주면 항상 좋을까요? 여기서 균형을 잡아야 합니다. 맥락은 '왜 이 일을 하는지'를 알려주고, 예시는 '어떻게 만드는지'를 보여줍니다. 둘은 서로를 대체하는 게 아니라 보완하는 사이예요. 작업 성격에 따라 비중이 달라집니다. 낯설고 새로운 작업이면, 배경부터 줘야 하니까 맥락 비중을 올리세요. 반대로 특정 형식이나 스타일을 그대로 재현하는 일이면, 예시 비중을 올리는 게 답입니다.So is it always best to just pile on examples? Here you have to strike a balance. Context tells it why you're doing this; examples show it how to make it. The two don't replace each other — they complement each other. The balance shifts with the nature of the task. For an unfamiliar, new task, you need to give the background first, so raise the context. Conversely, when the job is to reproduce a specific format or style exactly, raising the examples is the answer.

그리고 아주 단순한 작업이면, 맥락도 예시도 최소로 가세요. 둘 다 과하면 오히려 노이즈가 됩니다. 지난 강에서 단순한 일엔 단순한 지시면 충분하다고 했던 것과 똑같은 절제 원리예요. 한 가지만 기억하세요. 예시는 강하지만 만능은 아닙니다. 맥락 없는 예시는 엉뚱하게 오해될 수 있어요. 그러니까 예시 하나만 던지는 게 아니라, '왜'와 '어떻게'를 함께 주는 겁니다.And for a very simple task, keep both context and examples minimal. Too much of either becomes noise. It's the same restraint principle as last session, when we said a simple job needs only a simple instruction. Remember one thing: examples are powerful, but not all-powerful. An example without context can be misread badly. So you don't just toss out one example — you give the 'why' and the 'how' together.

11 · 좋은 예시 5가지 체크11 · Five checks for a good example

자, 오늘의 핵심입니다. 예시를 넣기 전에 다섯 가지만 통과시키세요. 첫째, 대표성. 이 예시가 실제 할 작업과 닮았나요? 장난감 같은 예시 말고, 진짜 쓸 케이스로 보여주세요. 둘째, 다양성. 쉬운 경우만 말고, 까다로운 엣지나 반례도 담았나요? 한쪽으로 치우치면 모델도 그쪽으로 쏠립니다. 셋째, 형식 일관. 예시가 여러 개라면, 그 예시들끼리 형식이 똑같나요? 모양을 통일해야 모델이 헷갈리지 않아요.Alright, today's peak. Before you add an example, make it pass just five checks. One: representativeness. Does this example resemble the real task you'll do? Not some toy example — show a case you'd actually run. Two: diversity. Beyond the easy cases, did you include a tricky edge or a counter-case? Skew to one side and the model leans that way too. Three: format consistency. If you have several examples, are they identical in format with each other? Unify the shape so the model doesn't get confused.

넷째, 긍정형. '하지 마라'가 아니라 '이렇게 하라'를 보여주고 있나요? 금지가 보이면 시연으로 바꾸세요. 다섯째, 최소성. 예시를 꼭 필요한 만큼만 넣었나요? 예시가 과하면 맥락을 밀어내고 노이즈가 됩니다. 재밌는 건, 이 다섯 가지가 앞에서 본 원리들과 하나씩 정확히 짝을 이룬다는 거예요. 형식 시연, 좋은 예시 조건, 긍정 전환, 그리고 비중. 그래서 원리를 알면, 이 체크리스트는 저절로 외워집니다.Four: positive form. Are you showing "do this" rather than "don't"? When you see a ban, turn it into a demonstration. Five: minimality. Did you add only as many examples as truly needed? Too many examples push out the context and become noise. Here's the fun part: these five pair up exactly, one by one, with the principles we saw earlier — format demonstration, the conditions of a good example, the positive flip, and the balance. So once you know the principle, this checklist memorizes itself.

12 · 한 줄로 굳히기 — 공식12 · Locking it into one line — the formula

오늘 배운 걸 한 줄로 정리해볼게요. 강한 지시는, 맥락 더하기 예시 더하기 긍정형, 빼기 장황한 설명입니다. 왜 하는지 맥락을 주고, 어떻게 만드는지 예시로 보여주고, '하지 마'가 아니라 '이렇게 해'로 적고, 그러면서 군더더기 설명은 덜어내는 거예요. 핵심은 한 문장입니다. 보여주면, 해석이 사라진다. 말로 못 박을 것 같으면, 보여주세요.Let me lock today into one line. A strong instruction is context plus example plus the positive form, minus the long-winded telling. Give the context of why, show by example how, write "do this" instead of "don't," and trim away the padding of explanation. The core is one sentence: show it, and interpretation vanishes. When you can't nail it down in words, show it.

13 · 함정 — 예시도 과하면 독13 · The trap — too many examples poison

마지막으로 함정 하나만 짚고 가겠습니다. 예시가 강하다고 해서, 무조건 많이 넣는 게 정답은 아니에요. 첫째, 편향된 예시. 한쪽으로 치우친 예시만 보여주면 결과도 그쪽으로 쏠립니다. 둘째, 과다 예시. 예시를 너무 많이 넣으면 정작 중요한 맥락을 밀어내고 노이즈가 돼요. 셋째, 모순된 예시. 서로 다른 패턴을 동시에 보여주면 모델이 혼란스러워합니다. 예시의 목표는 패턴을 한 점으로 찍는 거지, 양으로 밀어붙이는 게 아니에요. 지난 강의 '필요한 만큼'과 똑같은 절제 원리죠. 예시는 골라서, 필요한 만큼. 질이 양을 이깁니다.Finally, let me flag one trap. Just because examples are powerful doesn't mean piling on more is always the answer. First, biased examples — show only one-sided examples and the result tilts that way. Second, too many examples — overload them and they push out the very context that matters, turning into noise. Third, conflicting examples — show different patterns at once and the model gets confused. The goal of an example is to pin the pattern to a single point, not to bulldoze with volume. It's the same restraint principle as last session's "only as much as needed." Choose your examples, only as many as needed. Quality beats quantity.

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

오늘 한 단어만 가져가신다면, 설명에서 시연으로, 입니다. 요리를 백 단어로 설명하느니 한 접시를 보여주듯, 프롬프트도 말로 풀지 말고 보여주세요. 원하는 형식은 한 줄로 보여주고, '하지 마'는 '이렇게 해'로 뒤집고, 예시는 골라서 필요한 만큼만. 그러면 모델이 해석할 일이 사라지고, 결과가 정확해집니다. 도구와 화면은 계속 바뀌겠지만, 보여주는 것이 말보다 강하다는 이 원리는 그대로예요. 다음 시간에는 기억 설계 그 첫 번째, 같은 걸 매번 설명하지 않으려면 어떻게 해야 하는지를 다뤄보겠습니다.If you take one word from today, it's: from telling to showing. Just as you'd show one plate rather than describe a dish in a hundred words, don't spell out a prompt in words — show it. Show the format you want in one line, flip "don't" into "do this," and choose your examples, only as many as needed. Then there's nothing left for the model to interpret, and the result turns accurate. Tools and screens will keep changing, but this principle — showing is stronger than telling — stays the same. Next time, we go into Memory Design, part one: how to stop explaining the same thing every single time.