이론이 현장에서 증명될 때 —
비로소 실력이 된다.When theory proves itself in the field —
that's when it becomes real skill.

1 · 도입 — 케이스 스터디1 · Intro — Case study

안녕하세요. 드디어 스무 강 중 열아홉 번째에 왔습니다. 이번 강의 제목은 "케이스 스터디 — 이 강의 자체가 사례다"입니다. 지금까지 우리는 룰 넘버 원부터 룰 넘버 에이틴까지, 원칙과 메커니즘을 배웠죠. 오늘은 그 원칙들이 실제 현장에서 어떻게 작동했는지, 네 가지 사례로 살펴봅니다. 그리고 네 번째 사례는 조금 특별합니다. 바로 여러분이 지금 보고 있는 이 강의 자체예요.Welcome. We've reached lesson nineteen of twenty. Today's title: "Case study — this course is the case." So far we've worked through Rules from Number One to Number Eighteen — principles and mechanisms. Today we look at how those principles played out in four real cases. And the fourth case is a little special: it's this course itself, the one you're watching right now.

2 · 원칙은 현장에서 증명된다2 · Principles proven in the field

원칙만 배우면 이런 느낌이 들 때가 있죠. "알 것 같은데, 실제로 어떻게 써야 하지?" 이건 이론을 배운 것과 현장에서 쓸 수 있는 것 사이의 거리예요. 오늘은 그 거리를 줄이는 시간입니다. 우리가 배운 Rules가 실제 어떤 상황에서, 어떤 조합으로, 어떤 결과를 만들어 냈는지. 네 가지 사례로 보겠습니다.When you learn principles alone, sometimes there's this feeling: "I think I understand it, but how do I actually use it?" That's the gap between knowing theory and being able to use it in the field. Today is about closing that gap. We'll look at which situations our Rules applied to, in which combinations, and with what results — through four cases.

오늘의 사례는 이렇습니다. 첫 번째는 대규모 매출 데이터 분석. 두 번째는 보고서 자동화 파이프라인. 세 번째는 팀 AI 활용 체계 구축. 그리고 네 번째는 이 하우 투 클로드 코스 자체입니다. 각 사례마다 문제, 접근법, 적용한 Rule, 그리고 결과를 보겠습니다.Here are today's cases. First: large-scale sales data analysis. Second: report automation pipeline. Third: team AI adoption framework. And fourth: this very How_to_claude course. For each case we'll cover the problem, the approach, the Rules applied, and the result.

3 · 케이스 1 — 대규모 매출 데이터 분석3 · Case 1 — Large-scale sales data analysis

첫 번째 케이스입니다. 수만 건의 매출 데이터를 분석해야 하는 상황이에요. 처음에는 전체를 한꺼번에 넘기고 "분석해 줘"라고 했습니다. 그런데 컨텍스트가 넘치고, 앞에서 한 결정이 뒤에서 잊혀지고, 같은 패턴인데 처리가 달라지는 문제가 생겼어요. 이건 두 번째 강에서 배운 컨텍스트 로트, 그리고 열 번째 강에서 배운 작업 분해 없이 덤볐을 때 생기는 전형적인 실패입니다.The first case: a sales dataset with tens of thousands of rows that needs analysis. The first attempt was to hand the whole thing over and say "analyze this." But the context overflowed, decisions made early were forgotten later, and the same patterns ended up processed differently. This is the classic failure of context rot from lesson two, and of charging in without the task decomposition from lesson ten.

그래서 접근법을 바꿨습니다. 룰 넘버 나인, 먼저 이해하고. 전체 구조와 의존성을 파악하는 것부터 시작했어요. 그다음 룰 넘버 텐, 작은 일들로 쪼개기. 카테고리·기간 단위로 나눠서 순서를 정하고, 각 단계마다 검증을 거쳤습니다. 마지막으로 룰 넘버 포틴, 서브에이전트 팀으로. 서로 의존하지 않는 데이터 집합은 병렬로 분석해서 속도를 높였어요. 한 번에 실패했던 작업이 단계적으로 완료됐고, 오류 없이 통과했습니다.So the approach changed. Rule Number Nine: understand first. It started by mapping the whole structure and dependencies. Then Rule Number Ten: break into small tasks. Split by category and time period, ordered the steps, and validated at each stage. Finally Rule Number Fourteen: sub-agent team. Datasets that didn't depend on each other were analyzed in parallel for speed. The work that failed all at once completed step by step, and passed cleanly.

4 · 케이스 2 — 보고서 자동화 파이프라인4 · Case 2 — Report automation pipeline

두 번째 케이스는 보고서 자동화 파이프라인입니다. 데이터가 바뀔 때마다 보고서를 손으로 업데이트하면, 언제나 보고서가 뒤처지고 오류가 생깁니다. 처음에는 클로드한테 "보고서 업데이트해 줘"라고 매번 요청했어요. 그런데 이건 일꾼을 반복 사용하는 거지, 문제를 근본적으로 푸는 게 아니에요. 출력이 매번 다르고, 형식이 통일되지 않고, 다음 사람이 쓸 수 없었습니다.The second case is a report automation pipeline. Every time the data changes, manual report updates mean reports are always behind and errors creep in. The first approach was to ask Claude to "update the report" each time. But that's repeatedly using a worker — it doesn't solve the underlying problem. Output varied each time, format wasn't consistent, and the next person couldn't use it reliably.

그래서 먼저 룰 넘버 파이브, 명령하지 말고 설계하라. 보고서가 어떤 형식이어야 하는지를 제약으로 먼저 설계했습니다. 그리고 룰 넘버 식스, 예시가 설명보다 강하다. 원하는 출력 샘플을 직접 보여줘서 형식 계약을 명확히 고정했어요. 마지막으로 룰 넘버 서틴, 환경을 설계해라. 클로드를 일꾼으로 반복 쓰는 게 아니라, 데이터가 갱신될 때마다 자동으로 보고서가 생성되고 검증되는 파이프라인 자체를 설계했어요. 결과는요. 보고서가 데이터와 항상 동기화되고, 수동 작업이 사라지고, 형식 위반이 생기면 자동으로 걸러졌습니다.So first, Rule Number Five: design, don't just command. The output format was designed as a constraint up front — what the report had to look like was defined before anything else. Then Rule Number Six: examples beat explanations. A sample output was shown directly to lock in the format contract clearly. And finally Rule Number Thirteen: design the environment. Instead of repeatedly using Claude as a worker, the design shifted to a pipeline that automatically generates and verifies reports whenever the data is updated. The result: reports always in sync with data, manual work gone, and format violations caught automatically.

5 · 케이스 3 — 팀 AI 활용 체계 구축5 · Case 3 — Team AI adoption framework

세 번째 케이스는 팀 AI 활용 체계 구축입니다. AI 도구를 팀에 도입할 때, 팀원마다 쓰는 방식이 달라서 결과 품질이 들쭉날쭉하고, "이 결과를 믿을 수 있나?" 하는 질문이 매번 나왔어요. 누군가는 검토를 철저히 하고, 누군가는 그냥 씁니다. 이건 개인 역량 문제가 아니에요. 신뢰를 설계하지 않은 문제입니다.The third case is building a team AI adoption framework. When introducing AI tools to a team, different members used them differently, so result quality was inconsistent, and the question "can we trust this output?" came up every time. Some people reviewed thoroughly, others just used the output as-is. This isn't a skill problem — it's the problem of not designing trust.

그래서 룰 넘버 피프틴, 신뢰는 설계하는 것. AI가 생성한 결과물이 팀 업무에 쓰이기 전에 통과해야 하는 검증 게이트를 팀 공통 체크리스트로 만들었습니다. 그리고 룰 넘버 식스틴, 개인 도구가 팀 인프라가 되려면. 잘못된 결과가 나왔을 때 그냥 고치고 넘어가는 게 아니라, 왜 실패했는지를 기록하고 팀 전체가 공유하는 거버넌스를 만든 겁니다. 개인이 혼자 쌓은 노하우를 팀 자산으로 전환하는 것, 그게 룰 넘버 식스틴의 핵심이에요. 결과는요. 팀 전체가 같은 기준으로 AI 결과를 검토하게 됐고, 같은 실수가 반복되는 일이 크게 줄었습니다.So: Rule Number Fifteen, trust is designed. A team-shared verification checklist was created — a trust gate that AI-generated output must pass before being used in team work. And Rule Number Sixteen, from personal tool to team infrastructure. When bad output appeared, instead of just fixing and moving on, the team built governance to document why it failed and share it across the team. Converting individually held know-how into shared team assets — that's the core of Rule Number Sixteen. The result: the whole team reviewing AI output to the same standard, and the same mistakes recurring far less often.

6 · 케이스 4 — How_to_claude 코스 자체6 · Case 4 — The How_to_claude course itself

네 번째 케이스는 조금 다릅니다. 제가 직접 만든 이 강의 자체예요. 하우 투 클로드 코스는 스무 개의 세션, 한국어와 영어, 슬라이드, 내레이션, 그리고 실험까지 포함하는 큰 프로젝트입니다. 만약 이 모든 걸 하나의 세션에서, 한 명한테 다 시켰다면 어떻게 됐을까요? 앞에서 정한 원칙이 뒤에서 흐려지고, 슬라이드 형식이 강마다 달라지고, 근거 태그가 어느 순간부터 사라지겠죠.The fourth case is a little different. It's this course I made myself. The How_to_claude course is a large project — twenty sessions, Korean and English, slides, narration, and experiments included. What would have happened if all of that were assigned to one worker in a single session? The principles set early would have gotten foggy later, slide formats would have varied from lesson to lesson, and evidence tags would have disappeared at some point.

그래서 룰 넘버 포틴을 그대로 적용했습니다. 오케스트레이터 한 명과 일곱 개의 전문 팀. 구조를 감독하는 팀, 집필하는 팀, 슬라이드를 만드는 팀, 팩트를 체크하는 팀, 발음을 검수하는 팀, 음성을 다루는 팀, 그리고 다국어를 맞추는 팀입니다. 결과는 지금 보시는 이 강의예요. 스무 강 전체가 같은 원칙, 같은 형식, 같은 근거 체계로 완성됐습니다. 이 강의가 룰 넘버 포틴의 실전 사례입니다.So Rule Number Fourteen was applied as-is. One orchestrator and seven specialist teams: a structure team, a writing team, a slides team, a fact-check team, a pronunciation team, an audio team, and a localization team. The result is the course you're watching right now. All twenty lessons completed with the same principles, same format, and same evidence system. This course is the real-world case of Rule Number Fourteen.

7 · 패턴 분석 1 — 성공 사례의 공통점7 · Pattern 1 — Traits of success

네 가지 사례를 돌아보면 성공한 쪽에는 공통점이 있습니다. 첫째, 먼저 이해하고 쪼갰어요. 전체를 파악하지 않고 바로 작업에 뛰어들면 나중에 방향이 틀어집니다. 둘째, 형식을 미리 고정했어요. 결과가 어떤 모양이어야 하는지를 먼저 정해야, 나중에 결과들을 안전하게 합칠 수 있거든요.Looking back at the four cases, the successful ones share common traits. First: they understood and decomposed first. Diving into the work without grasping the whole leads to misalignment later. Second: they pinned the format early. You need to define what the output should look like before you can safely combine results later.

셋째, 검증을 만든 자에게 맡기지 않았어요. 만든 사람이 자기 걸 검토하면 약점이 잘 안 보입니다. 별도의 검증 단계가 있어야 품질이 유지됩니다. 그리고 넷째, 실패를 기록했어요. 같은 실수를 두 번 하는 건 기록의 문제예요. 실패 케이스를 자산으로 만들면, 시스템이 시간이 갈수록 더 좋아집니다. 이 네 가지가 성공한 사례들의 공통된 뼈대였습니다.Third: they didn't hand verification to the maker. The person who made it can't easily see its own weak spots — a separate verification step is what keeps quality up. And fourth: they documented failures. Repeating the same mistake twice is a documentation problem. Turn failure cases into assets and the system gets better over time. These four were the shared skeleton of the successful cases.

8 · 패턴 분석 2 — 실패 패턴8 · Pattern 2 — Failure patterns

반대로 실패한 쪽을 보면 패턴도 있습니다. 첫째, 한 번에 너무 많이 넘겼어요. 컨텍스트가 차서 흐려지는 건 시간 문제입니다. 둘째, 형식 없이 출력을 받았어요. 결과가 매번 다른 모양이면 나중에 합칠 수가 없어요. 셋째, 만든 쪽에 검증을 맡겼어요. 자기채점은 항상 관대합니다. 넷째, 실패를 그냥 넘겼어요. 기록하지 않으면 같은 실수가 반복됩니다.Looking at the failures, there are patterns there too. First: too much at once. Context filling and fogging is only a matter of time. Second: output received without a format. If the result looks different each time, you can't combine them later. Third: verification handed to the maker. Self-grading is always generous. Fourth: failures just brushed past. Without documentation, the same mistakes repeat.

그런데 이 네 가지 실패의 뿌리는 사실 하나예요. 설계보다 실행을 먼저 한 겁니다. "더 좋은 프롬프트를 쓰면 해결되겠지"라고 생각한 거죠. 그런데 프롬프트 최적화는 임시방편이에요. 근본 문제는 시스템의 부재입니다. 개인 기술이 좋아지는 게 아니라, 누가 써도 일정 수준 이상이 나오는 시스템을 만드는 게 답이에요.But all four failure roots come down to one thing: execution before design. The thinking was "a better prompt will fix it." But prompt optimization is a patch. The underlying problem is the absence of a system. The answer isn't getting better individually — it's building a system that produces above a consistent threshold no matter who uses it.

9 · 패턴 분석 3 — Rule 조합 전략9 · Pattern 3 — Rule combination strategy

케이스들을 보면서 하나 눈에 띄는 게 있었습니다. 하나의 Rule만 쓰는 경우는 없었어요. 항상 조합이었습니다. 복잡한 작업을 분해해야 할 때는 룰 넘버 나인, 텐, 포틴이 함께 왔어요. 반복 가능한 출력이 필요할 때는 룰 넘버 파이브, 식스, 서틴이 함께 작동했고요. 팀 단위 품질 관리엔 룰 넘버 피프틴과 식스틴이 함께 작동했습니다.Looking across the cases, one thing stood out: no single Rule was used alone. It was always a combination. Decomposing complex work brought Rule Numbers Nine, Ten, and Fourteen together. Repeatable output had Rule Numbers Five, Six, and Thirteen working together. Team quality control had Rule Numbers Fifteen and Sixteen working in tandem.

장기 프로젝트에서는 더 많은 Rules가 함께 작동했어요. 룰 넘버 투로 컨텍스트를 지키고, 룰 넘버 포틴으로 팀을 구성하고, 룰 넘버 피프틴으로 신뢰를 설계하고, 룰 넘버 식스틴으로 팀 거버넌스와 공유 체계를 만드는 식으로요. 이 표는 고정된 정답이 아니에요. 자기 상황에서 어떤 Rules가 함께 작동하는지를 찾는 출발점입니다. 조합을 찾는 능력 자체가 숙련의 증거예요.In long-running projects, more Rules worked together: Rule Number Two to protect context, Rule Number Fourteen to assemble the team, Rule Number Fifteen to design trust, and Rule Number Sixteen to build team governance and sharing systems. This table isn't a fixed answer — it's a starting point for finding which Rules work together in your own situation. The ability to find the right combination is itself a sign of mastery.

10 · 패턴 분석 4 — 상황별 Rule 선택10 · Pattern 4 — Choosing Rules by situation

어떤 Rule을 먼저 꺼낼지를 상황별로 정리해 봤습니다. 지금 컨텍스트가 흐려지고 있다면 가장 먼저 룰 넘버 투를 꺼내세요. 컨텍스트를 보호하는 방법을 점검하는 게 먼저입니다. 출력이 매번 다르고 형식이 통일되지 않는다면, 룰 넘버 파이브를 꺼내세요. 명령을 더 잘하는 게 아니라, 원하는 출력을 제약으로 먼저 설계하는 겁니다.Let me map out which Rule to reach for first by situation. If context is getting foggy right now, reach for Rule Number Two first — reviewing how you're protecting context is the priority. If output varies every time and format isn't consistent, reach for Rule Number Five. The answer isn't better commands — it's designing the desired output as a constraint first.

팀이 AI 결과를 믿지 못한다면 룰 넘버 피프틴입니다. 신뢰는 개인이 "더 잘 쓰면" 생기는 게 아니라, 시스템으로 설계해야 생깁니다. 그리고 같은 실수가 반복된다면 룰 넘버 식스틴. 개인 노하우가 팀 인프라로 전환되지 않은 겁니다. 실패 케이스를 기록하고 공유하는 거버넌스가 없으면 팀 평균은 절대 올라가지 않아요. 기억하세요. 이건 첫 번째로 꺼낼 Rule이에요. 반드시 다른 Rules와 조합해서 써야 합니다.If the team doesn't trust AI output, that's Rule Number Fifteen. Trust doesn't come from individuals "getting better at it" — it has to be designed into the system. And if the same mistakes keep repeating, that's Rule Number Sixteen. Individual know-how hasn't been converted into team infrastructure. Without governance for recording and sharing failure cases, the team average never rises. Remember: these are first Rules to reach for. You always need to combine them with other Rules.

11 · 실천 1 — 나만의 케이스 스터디 만들기11 · Practice 1 — Build your own case study

이제 실천으로 넘어가겠습니다. 오늘 본 네 가지 사례는 저의 케이스예요. 그런데 여러분한테 가장 유용한 케이스는 여러분 자신의 것입니다. 지금 당장 할 수 있는 걸 드리겠습니다. 최근에 AI와 함께 한 작업 중에서 가장 잘 됐던 것 하나를 골라보세요. 그리고 그걸 한 장으로 정리해 보세요. 문제가 무엇이었는지, 어떻게 접근했는지, 어떤 Rule이 작동했는지, 그리고 결과가 어땠는지.Now let's move to practice. The four cases we saw today are my cases. But the most useful case for you is your own. Here's something you can do right now: pick one thing from recent AI work that went really well. Then summarize it on one page — what was the problem, how did you approach it, which Rules worked, and what was the result.

그다음, 그게 재현 가능한지 점검해 보세요. "한 번 잘 됐다"는 경험은 운일 수 있어요. 다음에 같은 상황이 왔을 때 같은 접근법을 쓸 수 있어야 진짜 케이스가 됩니다. 그리고 팀이 있으면 공유하세요. 남의 케이스도 내 자산입니다. 팀이 케이스를 쌓아가면 시스템 자체가 배워 나갑니다.Then check whether it's reproducible. "It worked once" can be luck. It becomes a real case only when you can use the same approach the next time the same situation comes. And if you have a team, share it. Someone else's case is your asset too. When a team accumulates cases, the system itself learns.

12 · 실천 2 — Rule 활용 자가진단12 · Practice 2 — Self-diagnosis

자가진단을 한번 해볼게요. 지금 자신한테 가장 솔직하게 물어보세요. 컨텍스트가 자주 흐려집니까? 그렇다면 컨텍스트 관리 영역이 약한 겁니다. 형식 없이 출력을 받다가 나중에 합치지 못한 적이 있습니까? 그렇다면 프롬프트와 구조 설계 영역이에요. 혼자 몰아서 쓰다가 품질이 들쭉날쭉해진 적이 있습니까? 에이전트와 팀 설계 영역이 필요합니다.Let's do a self-assessment. Ask yourself as honestly as you can right now. Does your context get foggy often? Then context management is your weak area. Have you ever received output without a format and then couldn't combine it later? That's the prompt and structure design area. Have you ever piled everything on one and had quality go up and down? That's the agent and team design area.

검증 없이 AI 결과를 그냥 쓰다가 문제가 생긴 적이 있습니까? 그렇다면 신뢰와 평가 설계 영역이 부족한 겁니다. 중요한 건, 모든 걸 다 잘해야 한다고 생각하지 마세요. 약한 곳을 하나만 골라서 다음 주에 집중하는 것만으로도 충분합니다. 한 번에 다 바꾸려면 지쳐서 아무것도 못 바꿔요.Have you ever used AI output without verifying and run into a problem? Then trust and evaluation design is where you're thin. The important thing: don't think you have to do everything well. Picking just one weak area and focusing on it next week is enough. Trying to change everything at once leads to burnout and changing nothing.

13 · 실천 3 — 팀 공유 방법13 · Practice 3 — Sharing with your team

마지막 실천은 팀 공유입니다. 케이스를 나만 갖고 있으면, 내가 팀을 떠나는 순간 사라져요. 그리고 팀의 평균이 올라가지 않습니다. 반대로 케이스를 팀이 공유하면, 그 케이스는 공유 자산이 됩니다. 한 사람이 발견한 패턴을 팀 전체가 씁니다. 그러면 팀이 시간이 갈수록 더 좋아지는 시스템이 만들어져요.The final practice is team sharing. If you keep cases to yourself, they disappear the moment you leave the team. And the team average doesn't rise. On the flip side, when the team shares cases, those cases become shared assets. A pattern one person found gets used by the whole team. That creates a system where the team gets better over time.

거창하게 시작할 필요는 없어요. 최소한 한 달에 한 번, 내 케이스 하나를 팀에 공개해 보세요. 어떤 상황이었는지, 어떤 접근법이 통했는지, 그리고 다음엔 어떻게 할 것인지. 이것만으로도 팀의 집단 지식이 쌓입니다. 그리고 팀원의 케이스도 여러분의 자산이 됩니다. 이게 룰 넘버 식스틴, 개인 도구가 팀 인프라가 되는 가장 작은 첫 걸음이에요.You don't need to start big. At minimum, once a month, share one of your cases with the team — what the situation was, which approach worked, and what you'd do differently next time. Even this alone accumulates collective knowledge for the team. And your teammates' cases become your assets too. This is the smallest first step of Rule Number Sixteen: converting a personal tool into team infrastructure.

14 · 마무리 — 이론이 현장에서 증명될 때14 · Closing — when theory is proven in the field

오늘 배운 걸 한 문장으로 정리하겠습니다. 케이스는 문제, 접근법, Rule, 결과의 네 요소로 이뤄집니다. 그리고 그게 재현 가능할 때, 비로소 내 패턴이 됩니다. 이론은 원리를 알려줘요. 현장은 그 원리가 정말 작동하는지를 보여줍니다. 그리고 내 케이스는 그 원리를 내 상황에 맞게 구체화한 거예요. 이 세 단계가 모여야 진짜 실력이 됩니다.Let me summarize today in one sentence. A case is made of four elements: problem, approach, Rule, and result. And when it's reproducible, it becomes your pattern. Theory tells you the principle. The field shows whether that principle actually works. And your own case makes that principle concrete for your specific situation. All three stages together are what make real skill.

그리고 사실 오늘 가장 중요한 사례는 이 강의 자체였습니다. 이 하우 투 클로드 코스는 룰 넘버 포틴, 멀티에이전트로 만들어졌어요. 오케스트레이터와 일곱 개의 전문 팀이 스무 강을 만든 겁니다. 원리를 가르치는 강의가 그 원리로 만들어진 거예요. 다음 강, 스무 번째이자 마지막 강에서는 지금까지 배운 스무 개의 Rule을 하나의 지도로 완성합니다. 처음부터 끝까지의 여정을 한눈에 봅니다. 거기서 뵙겠습니다.And actually, the most important case today was this lesson itself. This How_to_claude course was built with Rule Number Fourteen — by multi-agent. An orchestrator and seven specialist teams made twenty lessons. The lesson teaching the principle was itself made by that principle. In the next lesson — the twentieth and final one — we'll complete all twenty Rules learned so far as one unified map. We'll see the whole journey from beginning to end at a glance. See you there.