1 · RULE No.111 · Opening — Rule No.11

Claude Code의 진짜 힘은 채팅창에서 말을 주고받는 데 있지 않습니다. 파일을 읽고, 고치고, 명령을 실행하는, 환경을 직접 만지는 도구에 있어요. 배시, 리드, 에딧, 라이트, 그렙. 오늘은 룰 넘버 일레븐, "말로 하지 말고 도구를 써라"를 가지고 이 도구함을 열어보겠습니다. 한 문장만 먼저 기억하세요. 말은 보고서고, 도구는 사실입니다.The real power of Claude Code isn't in trading words in a chat box. It's in the tools that touch the environment directly — reading files, editing them, running commands. Bash, Read, Edit, Write, Grep. Today, under Rule Number Eleven — "don't tell it, use the tools" — we're going to open that toolbox. Remember one sentence first: talk is a report, a tool is a fact.

2 · 시켰는데 왜 안 했지?2 · Hook — why didn't it do it?

한 가지 장면을 볼게요. "그 파일의 버그 좀 고쳐줘"라고 시켰더니, Claude가 "네, 고쳤습니다"라고 아주 시원하게 답합니다. 그런데 실제 파일을 열어보면, 아무것도 안 바뀌어 있어요. 분명히 고쳤다고 말했는데 말이죠. 왜 이런 일이 생길까요?Let's look at one scene. I tell it, "fix the bug in that file," and Claude answers cheerfully, "Done — fixed it." But when you actually open the file, nothing has changed. It clearly said it fixed it. So why does this happen?

답은 간단합니다. Claude가 "고쳤습니다"라고 말은 했지만, 파일을 실제로 바꾸는 에딧 도구를 호출하지 않았기 때문이에요. 말과 행동은 다릅니다. 10강에서 한 조각 하고 멈춰서 확인하라고 했죠? 그런데 그 확인을 도대체 무엇으로 할까요? 바로 도구입니다. 그래서 오늘의 질문은 이거예요. 언제가 말이고, 언제가 도구인가.The answer is simple. Claude said "fixed it," but it never called the Edit tool that actually changes the file. Talk and action are different things. In Session 10 we said to do one piece, then stop and verify, right? But verify with what, exactly? With tools. So today's question is this: when is it just talk, and when is it a tool?

3 · 말 vs 도구 — 정확성의 출처3 · Talk vs tool — where accuracy comes from

왜 도구가 말보다 정확한지부터 보겠습니다. Claude가 그냥 말로만 답할 때는, 컨텍스트에 남아 있던 예전 내용이나, "이쯤이면 이렇겠지" 하는 확률 추측에 기댑니다. 10강에서 본 그 확률 예측이죠. 파일이 그새 바뀌었어도 Claude는 모르고, 자신 있게 옛날 내용을 말할 수 있어요.Let's start with why tools are more accurate than talk. When Claude answers by talk alone, it leans on stale content left in its context, or on a probability guess — "it's probably like this." That's the same probability prediction we saw in Session 10. Even if the file changed in the meantime, Claude doesn't know, and it can confidently report the old contents.

반대로 리드나 그렙 같은 도구를 쓰면, Claude는 추측하는 게 아니라 디스크에 있는 실제 파일의 지금 상태를 그대로 돌려받습니다. 파일 내용, 명령 출력, 검색 결과. 전부 환경의 실제 상태예요. 그래서 같은 질문이라도 말보다 도구가 사실에 훨씬 가깝습니다. 사실이 필요하면, 떠올리지 말고 도구로 확인하세요. 물론 도구 결과도 백 퍼센트는 아닌데, 그 얘기는 뒤에서 하겠습니다.By contrast, when Claude uses a tool like Read or Grep, it isn't guessing — it gets back the actual, current state of the real file on disk. File contents, command output, search results. All of it is the real state of the environment. So for the same question, a tool is far closer to fact than talk. When you need a fact, don't recall it — confirm it with a tool. Of course, tool results aren't a hundred percent either, but we'll get to that later.

4 · 5개 핵심 도구 지도4 · Map of the five core tools

이제 도구함을 펼쳐 볼게요. 핵심 도구 다섯 개만 알면 됩니다. 리드는 파일을 읽고, 그렙은 어떤 패턴이 어디 있는지 찾고, 에딧은 파일의 일부만 고치고, 라이트는 새 파일을 만들거나 통째로 갈아엎고, 배시는 예를 들어 매출 씨에스브이 파일을 열어 합계를 내거나 엑셀 파일을 변환하는 것 같은 컴퓨터 명령을 실행합니다. 셸이라는 말이 낯설면 이렇게 기억하세요. 컴퓨터에 명령을 직접 내리는 창입니다. 읽고, 찾고, 고치고, 만들고, 실행하고. 딱 이 다섯 동사예요.Now let's open the toolbox. You only need five core tools. Read reads a file, Grep finds where a pattern is, Edit changes just a part of a file, Write creates a new file or overwrites the whole thing, and Bash runs computer commands — for example, opening a sales CSV to total up the numbers, or converting an Excel file. If "shell" sounds unfamiliar, think of it as the window where you give commands directly to your computer. Read, find, edit, create, run. Just these five verbs.

이 도구들은 Claude Code가 파일과 셸을 직접 다룰 수 있게 해주는 내장 도구입니다. 한 가지만 기억하세요. 일에 맞는 도구를 이름으로 떠올릴 수 있어야, 제대로 시킬 수 있어요. 그리고 도구 이름이나 동작은 이천이십육 년 유월 기준이고 버전마다 바뀌니까, 정확한 건 공식 문서나 슬래시 헬프로 확인하시면 됩니다.These are built-in tools that let Claude Code work with files and the shell directly. Remember just one thing: you can only direct the work well if you can call the right tool to mind by name. And the tool names and behaviors are as of June twenty twenty-six and change by version, so check the current set with the official docs or slash-help.

5 · Read vs Write·Edit — 점진적 공개와 컨텍스트5 · Read vs Write·Edit — progressive disclosure and context

도구를 쓸 때 한 가지 비용을 기억해야 합니다. 도구도 컨텍스트를 먹어요. 특히 큰 파일을 통째로 리드하면, 그 내용이 전부 책상 위에 올라가서 컨텍스트 윈도우를 많이 채웁니다. 10강에서 본 점진적 공개, 그러니까 필요한 만큼만 꺼내 쓰자는 원칙을 정면으로 어기는 거죠.When you use tools, remember one cost: tools eat context too. Especially if you Read a big file whole, all of it lands on the desk and fills up a lot of the context window. That goes straight against progressive disclosure — the principle from Session 10 of pulling out only what you need.

그래서 요령은 이래요. 먼저 그렙으로 찾는 게 어디 있는지 위치를 좁히고, 리드는 그 범위만 콕 집어서 읽고, 고칠 때는 에딧으로 필요한 부분만 바꿉니다. 파일 전체를 라이트로 다시 쓰는 건 가능하면 피하고요. 한마디로, 점진적 공개를 도구로 실천하는 겁니다. 필요한 만큼만 읽고, 필요한 만큼만 씁니다.So the trick is this. First, use Grep to narrow down where the thing you're looking for is. Then Read just that range, pinpointed. And when you edit, use Edit to change only the part you need. Avoid rewriting the whole file with Write when you can. In a word, you're practicing progressive disclosure with tools. Read only what you need, write only what you need.

6 · 병렬 도구 호출 = 한 턴에 여러 손6 · Parallel tool calls — many hands in one turn

도구를 빠르게 쓰는 요령이 하나 있어요. 파일 세 개를 봐야 한다고 해볼게요. 하나 읽고 기다리고, 또 하나 읽고 기다리고, 이렇게 순차로 하면 왕복을 세 번 해야 합니다. 그런데 이 세 파일이 서로 상관이 없다면, 한 번에 리드 세 개를 동시에 보낼 수 있어요. 그러면 왕복이 한 번으로 줄고, 그만큼 빨라집니다.There's one trick to using tools fast. Say you need to look at three files. Read one and wait, read another and wait — done sequentially, that's three round-trips. But if those three files have nothing to do with each other, you can send all three Reads at once in a single turn. Then it's just one round-trip, and that much faster.

단, 조건이 있습니다. 서로 결과에 의존하지 않을 때만 병렬이 가능해요. 만약 첫 번째 파일을 읽어봐야 두 번째로 뭘 읽을지 정해진다면, 그건 순서를 지켜야 합니다. 정리하면 간단해요. 독립적인 일이면 병렬로 동시에, 의존하는 일이면 순차로 차례차례.There's one condition, though. Parallel only works when the results don't depend on each other. If you have to read the first file before you can decide what to read second, that has to stay in order. To sum up simply: independent work goes in parallel, all at once; dependent work goes sequentially, one after another.

7 · 도구의 작동 = 관찰 → 행동 루프7 · How tools work — observe → act loop

도구가 어떻게 작동하는지 그 속을 들여다볼게요. 도구 호출은 한 방향으로 명령을 던지고 끝나는 게 아니에요. 루프입니다. 먼저 Claude가 도구를 호출해서 행동을 합니다. 그러면 환경이 실제 결과를 돌려줘요. 명령 출력일 수도 있고, 에러 메시지일 수도 있고, 파일 내용일 수도 있죠. Claude는 그 결과를 보고 다음에 뭘 할지 정합니다. 그리고 이걸 반복해요.Let's look inside how a tool actually works. A tool call isn't a one-way command you throw out and you're done. It's a loop. First, Claude calls a tool and acts. Then the environment returns a real result — it might be command output, an error message, or file contents. Claude reads that result and decides what to do next. And it repeats this.

어디서 본 모양 아닌가요? 맞아요. 10강에서 본 한 조각 하고, 멈춰서 확인하고, 다음 조각으로 가는 그 루프와 똑같습니다. 그 확인하고 다음으로 가는 루프를 실제로 돌리는 엔진이 바로 도구예요. Claude가 결과를 본다는 게 핵심인데요. 그렇다면 그 결과를 얼마나 믿어야 할까요? 이건 잠시 뒤에 따로 다루겠습니다.Look familiar? Right — it's exactly the loop from Session 10: do one piece, stop and verify, move to the next. The engine that actually runs that verify-and-move-on loop is the tool. The key is that Claude reads the result. So then — how much should we trust that result? We'll handle that separately in a moment.

8 · Agent 도구 = 서브에이전트에게 통째로 위임8 · Agent tool — delegate wholesale to a subagent

도구 중에 좀 특별한 게 하나 있어요. 에이전트, 그러니까 서브에이전트 도구입니다. 어떤 일은 양이 너무 많아요. 예를 들어 방대한 거래 데이터나 상품 카탈로그를 샅샅이 뒤져서 이상 항목을 찾는 일이요. 이걸 메인 대화에서 직접 하면, 그 수많은 탐색 로그가 전부 메인 컨텍스트, 그러니까 우리 책상 위에 쌓입니다. 정작 중요한 대화가 밀려나서 컨텍스트가 오염돼요.There's one tool among them that's a bit special: the Agent, or subagent, tool. Some jobs are just too big — say, combing through a massive transaction log or product catalog to find anomalies. If you do that directly in the main conversation, all those search logs pile up in the main context — on our desk. The conversation that actually matters gets pushed off, and the context gets polluted.

그래서 이런 무겁고 독립적인 일은 서브에이전트에게 통째로 맡깁니다. 서브에이전트는 자기만의 별도 컨텍스트에서 그 탐색을 다 하고, 우리한테는 결과 요약만 돌려줘요. 지저분한 과정은 거기서 끝나고, 메인 책상은 깨끗하게 유지됩니다. 10강에서 크고 독립적인 조각은 에이전트에게 맡기라고 했던 게 바로 이거예요. 통째로 위임하고, 돌아온 결과만 검증하면 됩니다.So this kind of heavy, independent work, we hand off to a subagent entirely. The subagent does all that searching in its own separate context and returns only a summary to us. The messy process ends over there, and the main desk stays clean. This is exactly what we meant in Session 10 by handing big, independent pieces to an agent. Delegate the whole thing, and just verify the result that comes back.

9 · WebFetch·WebSearch = 컨텍스트 밖 세계9 · WebFetch·WebSearch — the world outside context

3강 해부학에서, Claude는 학습 시점 이후의 최신 정보에 약하다고 했죠. 본 적이 없으니 그럴듯하게 지어내기 쉽다고요. 이 약점을 메우는 도구가 두 개 있습니다. 웹서치는 키워드로 최신 정보를 검색하고, 웹페치는 특정 유알엘을 주면 그 페이지 내용을 그대로 가져옵니다.In Session 3, the anatomy session, we said Claude is weak on recent information past its training cutoff — it never saw it, so it's easy to fabricate something plausible. There are two tools that fill this gap. WebSearch searches for recent information by keyword, and WebFetch, given a specific URL, pulls back the contents of that page as they are.

그러니까 최신이거나 모델 밖에 있는 사실은, 기억에서 떠올리려고 하지 말고 이 도구들로 조회하세요. 가격이 얼마인지, 어제 무슨 일이 있었는지 같은 건 조회가 답입니다. 다만 한 가지. 조회해 온 결과도 무조건 옳은 건 아니에요. 출처가 믿을 만한지는 한 번 더 봐야 합니다. 이 검증 얘기로 자연스럽게 넘어가 볼게요.So for facts that are recent or live outside the model, don't try to recall them from memory — look them up with these tools. What a price is, what happened yesterday — for those, looking it up is the answer. One caveat, though: what you fetch back isn't automatically correct either. You still need to check whether the source is trustworthy. Let's move naturally into that question of verification.

10 · 도구는 손, 운전대는 사람10 · Tools are hands, steering wheel is yours

여기까지 도구를 쓰는 법을 봤습니다. 그런데 도구가 강력한 만큼, 한 가지 함정이 있어요. 도구 결과를 그냥 무조건 믿으면 위험하다는 겁니다. 세 가지만 기억하세요. 도구 결과가 항상 정답인 건 아니다. 검색 결과가 비었다고 해서 그게 없다는 뜻은 아니다. 명령이 성공적으로 출력을 냈다고 해서 내 의도대로 됐다는 뜻은 아니다. 도구를 쓸 줄 알게 됐으니, 이제 그 결과를 제대로 읽는 법을 볼 차례입니다.That covers how to use the tools. But as powerful as tools are, there's one trap: blindly trusting a tool's output is risky. Remember just three things. A tool result isn't always correct. An empty search result doesn't mean the thing doesn't exist. And a command producing output successfully doesn't mean it did what you intended. Now that you know how to use the tools, it's time to learn how to read their results properly.

11 · 도구 결과 5점검11 · Five checks for tool results

자, 오늘의 완성형입니다. 도구 결과를 읽을 때 이 다섯 가지를 점검하세요. 첫째, 그 도구가 실제로 호출됐나? 맨 앞에서 본 것처럼, 고쳤다고 말만 하고 에딧은 안 했을 수 있어요. 둘째, 결과가 비었거나 에러는 아닌가? 특히 그렙 결과가 비었다면, 그건 그게 없다는 뜻이 아니라 못 찾았다는 뜻일 수 있습니다. 셋째, 경로와 범위가 내가 의도한 그곳이 맞나? 엉뚱한 파일을 보고 있을 수도 있거든요.Alright, here's today's complete picture. When you read a tool's result, check these five. One: did the tool actually run? As we saw at the very start, it may have just said "fixed it" and never called Edit. Two: is the result empty, or an error? Especially if a Grep comes back empty, that may not mean the thing doesn't exist — it may mean it wasn't found. Three: are the path and range the place you meant? You might be looking at the wrong file.

넷째, 배시 출력이 정말 성공을 뜻하나? 명령이 화면에 뭔가 출력했다고 끝난 게 아닙니다. 에러 없이 끝났는지를 봐야 해요. 이걸 종료 코드라고 하는데, 성공인지 실패인지를 알리는 신호입니다. 클로드에게 "정말 성공했어? 에러는 없었어?"라고 되물으세요. 다섯째, 외부 조회 결과라면 출처를 한 번 더 봤나? 웹에서 가져온 건 출처가 믿을 만한지 확인하세요. 재밌는 건, 이 다섯 가지가 앞에서 본 도구 이야기와 하나씩 정확히 짝을 이룬다는 겁니다. 도구를 쓰는 법이 절반이고, 그 결과를 읽는 법이 나머지 절반이에요.Four: does the Bash output truly mean success? Just because something printed to the screen doesn't mean it succeeded. You need to check whether it finished without errors — that's called the exit code, the signal that says success or failure. Ask Claude: "did it really succeed? any errors?" Five: if it's an external lookup, did you re-check the source? For anything fetched from the web, confirm the source is trustworthy. Here's the fun part: these five map exactly, one by one, onto the tool topics we saw earlier. Using the tools is half of it; reading their results is the other half.

12 · 도구 사용을 한 줄 행동으로12 · Tool use in one action line

오늘 배운 걸 한 줄 공식으로 정리해볼게요. 사실이 필요하면 말 대신 도구로 확인한다. 일이 서로 독립적이면 병렬로 동시에 한다. 무겁고 독립적인 일은 에이전트에게 통째로 위임한다. 최신이거나 외부 사실은 웹으로 조회한다. 그리고 마지막, 무엇을 하든 결과를 다시 읽는다. 보세요. 도구로 사실을 얻고, 컨텍스트를 아끼고, 결과를 검증하는 이 자리에서, 룰 넘버 원과 투, 그리고 일레븐이 정확히 만납니다.Let me lock today's lesson into a one-line formula. Need a fact? Confirm it with a tool, not talk. Is the work independent? Do it in parallel, all at once. Heavy and independent? Delegate it whole to an Agent. Recent or external? Look it up on the web. And finally — whatever you do, read the result back. Look: getting facts from tools, saving context, and verifying results — right here, Rules Number One, Two, and Eleven meet exactly.

13 · 말로만 vs 도구로 — 뒤집기13 · Talk-only vs tools — the flip

맨 처음 그 장면으로 돌아가 볼게요. 같은 일인데 결과가 완전히 갈립니다. 말로만 하는 쪽은, "고쳤습니다"라고 그럴듯하게 보고하지만 파일은 그대로예요. 그리고 우리는 그 말이 맞는지 확인할 방법이 없습니다. 반면 도구로 하는 쪽은, 에딧을 실제로 호출해서 고치고, 리드로 다시 읽어서 확인까지 해요. 결과가 눈에 보이는 사실로 남습니다. 했다고 말하는 것과, 진짜 하게 만드는 것은 다릅니다. 이게 룰 넘버 일레븐의 핵심이에요.Let's go back to that very first scene. Same task, but the outcomes split completely. The talk-only side reports plausibly, "fixed it," but the file is unchanged — and we have no way to confirm whether that's true. The tool side, by contrast, actually calls Edit to make the change, then reads it back with Read to confirm. The result remains as a visible fact. Saying it's done and actually making it happen are different things. That's the heart of Rule Number Eleven.

14 · Rule No.1114 · Closing — Rule No.11

오늘 한 단어만 가져가신다면, 말, 도구, 검증입니다. 사실이 필요하면 말하지 말고 도구를 쓰고, 그 결과를 다시 읽어서 검증한다. 손으로 직접 만져본 사람이 진짜로 아는 거예요. 도구는 앞으로 계속 늘어나겠지만, 말 대신 도구를 쓰고 결과를 다시 읽는다는 이 습관은 그대로 갑니다. 그런데 만약 필요한 도구가 도구함에 없다면 어떻게 할까요? 다음 시간에는 도구를 직접 만드는 법, 엠씨피와 훅을 들여다보겠습니다.If you take one word from today, it's: talk, tool, verify. When you need a fact, don't say it — use a tool, then read the result back to verify. The person who's touched it with their own hands is the one who truly knows. Tools will keep growing, but this habit — using a tool instead of talk, and reading the result back — stays the same. But what if the tool you need isn't in the toolbox? Next time, we'll look at how to build tools yourself: MCP and Hooks.