클로드 글쓰기 프롬프트 2026 — 공식 문서에서 채팅에 그대로 옮길 수 있는 여섯 가지

「블로그 글 하나 써줘」라고 보내면 어디서 본 듯한 글이 나옵니다. 그래서 클로드 글쓰기 프롬프트를 길게 늘여 써봐도 결과가 크게 달라지지 않습니다.

저도 한동안 그랬습니다. 시킬 말을 더 많이 적는 쪽으로만 고쳤거든요.

앤트로픽 공식 문서를 열어보고 나서야 제가 놓치고 있던 게 말의 양이 아니라 순서와 형식이었다는 걸 알았습니다.

🔑 긴 원고를 붙일 때는 원고를 위에 두고, 시킬 말을 아래에 적습니다. 이 순서 하나가 제일 크게 바뀐 부분입니다.

👉 지금 쓰는 프롬프트가 왜 안 걸리는지부터 궁금하시면 「한 번에 안 나왔을 때 — 공식 안내 네 가지」 절부터 보셔도 됩니다.

시작하기 전에 — 공식 문서가 두 종류입니다

이게 헷갈림의 절반입니다. 「클로드 공식 문서」라고 검색하면 성격이 아주 다른 두 곳이 같이 나옵니다.

어디	누구를 향해 쓰였나
platform.claude.com 의 Prompting best practices	개발자입니다. 예시를 파이썬 · cURL 같은 코드로 보여줍니다
support.claude.com 의 Introduction to prompt design	채팅으로 쓰는 사람입니다. 코드가 한 줄도 없습니다

지원 문서 「Introduction to prompt design」의 전문은 이렇습니다.

Claude is trained to be a helpful, honest, and harmless assistant. It is used to “speaking” conversationally and you can instruct it in English. Think of Claude as a newly-hired contractor. It doesn’t have any context about you, your task, or your organization. Give it very specific instructions about exactly what you’d like it to do.

For more information on effective prompt design, refer to our Claude API Docs.

마지막 줄이 「자세한 건 개발자 문서를 보라」입니다.

그래서 채팅만 쓰는 사람도 결국 개발자 문서를 열게 됩니다. 문제는 그 문서에 API 코드가 많이 섞여 있어서, 채팅 입력창에 옮길 수 있는 것과 옮길 수 없는 것이 섞여 있다는 점입니다.

⚠️ 이 글은 그중 채팅 입력창에 그대로 칠 수 있는 것만 골라 여섯 개로 정리한 것입니다. 구체적으로 적기 · 이유 붙이기 · 원고를 위로 · 예시 붙이기 · 칸 나누기 · 형식 맞추기 여섯입니다. 그대로는 옮길 수 없는 것 하나(역할 주기)도 왜 그런지 따로 다룹니다.

① 클로드를 「오늘 처음 온 사람」이라고 생각하세요

개발자 문서와 지원 문서가 같은 비유를 씁니다. 우연이 아니라 이게 이 문서들의 출발점입니다.

Think of Claude as a brilliant but new employee who lacks context on your norms and workflows. The more precisely you explain what you want, the better the result.

지원 문서 쪽은 「newly-hired contractor」, 그러니까 오늘 계약해서 온 사람입니다.

똑똑하지만 내 사정을 하나도 모르는 사람이라는 뜻입니다. 제 블로그가 무슨 블로그인지, 독자가 누구인지, 제가 어떤 말투를 쓰는지를 모릅니다.

그래서 「내 블로그 글 써줘」는 오늘 온 사람한테 통하지 않는 말입니다.

문서에는 이걸 확인하는 방법도 한 줄로 적혀 있습니다.

Golden rule: Show your prompt to a colleague with minimal context on the task and ask them to follow it. If they’d be confused, Claude will be too.

내가 쓴 프롬프트를 사정 모르는 사람한테 보여주고 그대로 해보라고 했을 때 헷갈리면, 클로드도 헷갈립니다.

문서가 든 예시는 이렇게 짧습니다.

Create an analytics dashboard

이걸 이렇게 바꿉니다.

Create an analytics dashboard. Include as many relevant features and interactions as possible. Go beyond the basics to create a fully-featured implementation.

문서는 이 지점을 이렇게 설명합니다. 「above and beyond」 결과를 원하면 그렇게 해달라고 직접 적으라는 것입니다. 알아서 해주기를 기대하지 말라는 뜻입니다.

글쓰기로 옮기면 이렇게 됩니다.

이렇게 쓰던 것	이렇게 바꿉니다
육림랜드 후기 써줘	네 살 아이랑 육림랜드에 다녀온 후기를 씁니다. 읽는 사람은 같은 또래 아이를 데리고 갈까 말까 고민하는 부모입니다. 놀이기구 이름과 키 제한, 화장실 위치처럼 가기 전에 알아야 할 것 위주로 적어주세요
좀 더 자연스럽게	소리 내어 읽었을 때 걸리지 않게 고쳐주세요. 문장 하나에 쉼표가 두 개를 넘지 않게 하고, 같은 낱말이 한 문단에 두 번 나오면 하나를 바꿔주세요

⚠️ 「자세히」·「자연스럽게」·「잘」은 클로드가 재량으로 채우는 자리입니다. 그 자리에 뭘 넣을지는 매번 다릅니다. 그래서 결과가 들쭉날쭉합니다.

② 「하지 마세요」에는 이유를 붙이세요

이건 제가 제일 많이 틀리던 것입니다. 저는 금지 목록을 길게 적어두는 쪽이었거든요.

문서가 든 예시가 정확히 그 모양입니다.

NEVER use ellipses

대문자로 NEVER까지 썼는데 문서는 이걸 덜 효과적인 쪽으로 분류합니다. 더 효과적인 쪽은 이렇습니다.

Your response will be read aloud by a text-to-speech engine, so never use ellipses since the text-to-speech engine will not know how to pronounce them.

「말줄임표 쓰지 마」가 아니라 「이 답을 기계가 소리 내어 읽을 거라서, 말줄임표는 어떻게 읽어야 할지 몰라」입니다. 금지 자체는 그대로 있고 앞에 이유가 붙었습니다.

문서는 그 이유가 왜 효과가 있는지도 한 줄로 붙여뒀습니다.

Claude is smart enough to generalize from the explanation.

이유를 알면 내가 미처 안 적은 경우까지 알아서 맞춘다는 뜻입니다. 말줄임표만 안 쓰는 게 아니라 소리 내어 읽기 어려운 다른 것도 피하기를 기대할 수 있습니다.

금지 목록을 늘리는 대신 이유 한 줄을 붙이는 게 낫다는 이야기입니다.

이유 없이 적던 것	이유를 붙인 것
이모지 쓰지 마	이 글은 차분한 말투로 가려고 합니다. 이모지 없이 문장으로만 써주세요
어려운 말 쓰지 마	읽는 사람이 이 주제를 처음 보는 사람입니다. 설명 없이 쓰면 못 알아들을 낱말은 괄호로 뜻을 달아주세요
표 쓰지 마	제가 이 글을 붙일 곳은 표가 그대로 안 들어갑니다. 비교할 게 있으면 줄바꿈으로 나눠 적어주세요

③ 원고를 먼저 붙이고, 시킬 말은 아래에 적으세요

이 글에서 제일 크게 바뀐 게 이겁니다. 내용은 그대로 두고 순서만 바꾸는 것이라 당장 해볼 수 있습니다.

저는 늘 시킬 말을 먼저 쓰고 원고를 아래에 붙였습니다. 사람한테 부탁하는 순서가 그러니까요.

문서는 반대로 하라고 합니다.

Put longform data at the top: Place your long documents and inputs near the top of your prompt, above your query, instructions, and examples. This improves performance across all models.

붙임말까지 붙어 있습니다.

Queries at the end can improve response quality by up to 30 percent in tests, especially with complex, multidocument inputs.

⚠️ 이 안내가 붙은 조건을 같이 봐야 합니다. 문서는 이 절을 「large documents or data-rich inputs (20k+ tokens)」, 그러니까 아주 긴 자료를 다룰 때로 한정해 두었습니다. 토큰은 글의 길이를 세는 단위입니다. 「up to」와 「in tests」, 「especially with complex, multidocument inputs」도 그대로 붙어 있습니다. 짧은 문단 하나를 고칠 때 30퍼센트가 좋아진다는 이야기가 아닙니다.

토큰이 한국어로 몇 자인지는 문서에 안 적혀 있습니다. 그래서 이 숫자만으로 「원고 몇 자부터」인지는 가늠할 수 없습니다.

다만 순서를 바꾸는 데 드는 품이 없습니다. 짧은 글에서는 차이를 못 느끼실 수 있고, 문서가 이 안내를 붙여둔 자리가 「긴 자료」 절이라 원고가 길어질 때 볼 이야기로 읽으시면 됩니다.

바뀌는 건 이 정도입니다.

제가 쓰던 순서	문서가 권하는 순서
시킬 말 → 원고	원고 → 시킬 말
「아래 글을 고쳐줘」 + 긴 원고	긴 원고 + 「위 글을 이렇게 고쳐줘」

붙일 때 「위 글」이라고 가리키는 말을 꼭 넣으세요. 원고가 길면 시킬 말이 원고의 일부처럼 읽힐 수 있습니다. 뒤에 나오는 ⑤ 칸 나누기가 그 헷갈림을 줄이는 방법입니다.

같은 절에 하나 더 옮길 만한 게 있습니다. 긴 원고를 다룰 때 쓰는 요령입니다.

Ground responses in quotes: For long document tasks, ask Claude to quote relevant parts of the documents first before carrying out its task. This helps Claude focus on the relevant content and ignore the rest of the document.

시키기 전에 「해당되는 부분을 먼저 그대로 옮겨 적어달라」고 한 단계를 넣으라는 것입니다. 그러면 나머지는 제쳐두고 그 부분에 집중한다는 설명입니다.

긴 원고에서 한 곳만 고칠 때 이렇게 씁니다. 「위 원고에서 가격을 이야기하는 문장을 먼저 그대로 뽑아주세요. 그다음에 그 문장들만 고쳐주세요.」

⚠️ 옮겨 적은 부분이 원고에 실제로 있는 문장인지 눈으로 한 번 보세요. 없는 문장이 섞이면 그 뒤 단계가 전부 어긋납니다.

④ 예시를 세 개에서 다섯 개 붙이면 말투가 따라옵니다

「내 말투로 써줘」는 안 됩니다. 클로드가 제 말투를 모르니까요.

문서는 예시를 붙이는 쪽을 출력 형식과 어조, 구조를 잡는 가장 믿을 만한 방법 중 하나로 설명합니다. 그리고 예시가 갖춰야 할 것을 셋으로 나눠뒀습니다.

• Relevant — 실제로 시킬 일과 닮아 있을 것. 후기 글을 시키면서 상품 설명을 예시로 주면 안 맞습니다
• Diverse — 서로 달라야 합니다. 드물게 나오는 경우까지 섞어 두라고 문서는 적습니다. 비슷한 예시만 세 개 주면 닮은 데를 규칙으로 받아들이기 쉽습니다
• Structured — <example> 태그로 감싸서 지시문과 구분되게 할 것. 여러 개면 바깥을 <examples> 로 한 번 더 감쌉니다 (꺾쇠로 감싸는 방법은 ⑤에서 설명합니다)

몇 개가 좋은지도 숫자로 적혀 있습니다.

Include 3–5 examples for best results. You can also ask Claude to evaluate your examples for relevance and diversity, or to generate additional ones based on your initial set.

뒷문장이 실전에서 편합니다. 예시 세 개를 모아놓고 「이 예시들이 시킬 일에 맞는지, 서로 충분히 다른지 봐줘」라고 물어볼 수 있고, 「이 셋을 바탕으로 성격이 겹치지 않는 걸 두 개 더 만들어줘」라고 시킬 수도 있습니다.

제가 하는 방식은 이렇습니다. 제 예전 글 중에 마음에 드는 문단을 세 개 골라서 붙입니다. 소개하는 문단 하나, 설명하는 문단 하나, 마무리 문단 하나로 성격을 다르게 고릅니다. 그게 Diverse 조건입니다.

⚠️ 예시는 글 전체가 아니라 문단이면 됩니다. 글 세 편을 통째로 붙이면 길이만 늘고 클로드가 뭘 따라야 하는지 흐려집니다.

⑤ 칸을 나누면 원고와 시킬 말이 덜 섞입니다

앞 절에서 나온 <example> 같은 꺾쇠 표시가 이것입니다. 문서에서는 XML 태그라고 부릅니다.

어렵게 들리는데 여는 표시와 닫는 표시로 감싸서 여기부터 여기까지가 한 덩어리라고 알려주는 것이 전부입니다. 저는 봉투에 이름표 붙이는 것으로 생각하고 씁니다.

문서가 예로 든 이름은 이 셋입니다.

• <instructions> — 시킬 말
• <context> — 배경 설명
• <input> — 처리할 원고

왜 필요한가는 ③에서 한 번 나왔습니다. 원고가 길면 시킬 말이 원고의 일부로 읽히기도 하고, 반대로 원고 속 문장이 지시로 읽히기도 합니다. 제 원고에 「이 부분은 나중에 다시 쓸 것」이라는 메모가 남아 있으면 클로드가 그걸 제가 시킨 말로 받아들이는 식입니다. 칸을 나누면 그렇게 섞일 일이 줄어듭니다.

문서에는 이름 짓는 요령도 있습니다.

Use consistent, descriptive tag names across your prompts.

매번 같은 이름을 쓰고, 이름만 봐도 뭐가 들었는지 알게 지으라는 것입니다. 한 번은 <원고>, 다음엔 <글>, 그다음엔 <본문> 이런 식으로 흔들리지 않게요.

요령이 하나 더 있습니다. 안에 층이 있으면 태그도 층을 두라는 것입니다. 문서는 여러 문서를 다룰 때 바깥을 <documents> 로 묶고 그 안에 <document> 를 하나씩 두는 모양을 예로 듭니다. 예시 여러 개를 넣을 때 쓸 방법이 이것인데, 이 글의 틀은 안쪽에 번호를 붙였습니다.

⚠️ 정해진 이름 목록이 있는 게 아닙니다. 문서가 든 것도 예시입니다. 한글로 <원고> 라고 지어도 됩니다. 여는 것과 닫는 것의 철자만 같으면 됩니다.

붙여넣을 틀은 이런 모양이 됩니다. ③에서 본 순서대로 원고가 위입니다. 태그 줄은 그대로 두고, 괄호로 적힌 안내를 지운 뒤 그 자리에 본인 것을 넣으세요.

<원고>

(여기에 원고를 붙입니다)

</원고>

<예시>

<예시1>(소개하는 문단 하나)</예시1>

<예시2>(설명하는 문단 하나)</예시2>

<예시3>(마무리 문단 하나)</예시3>

</예시>

<시킬일>

위 원고를 예시의 말투로 고쳐주세요. 문단 순서는 그대로 두고 문장만 손봅니다.

</시킬일>

예시 칸 안쪽을 <예시1> · <예시2> · <예시3> 으로 한 번 더 나눈 것이 보이실 겁니다. 세 문단을 한 칸에 이어 붙이면 어디서 한 예시가 끝나고 다음이 시작되는지 흐려집니다.

이 틀에는 아직 배경 칸이 없습니다. 여섯 개를 다 넣은 완성형은 뒤에 다시 나옵니다. 거기서는 배경 칸이 하나 더 붙는데, 매번 똑같은 내 사정(블로그 성격 · 읽는 사람)을 적는 자리입니다.

⑥ 줄글로 받고 싶으면 시킬 말도 줄글로 적으세요

클로드한테 글을 시키면 굵은 글씨와 점 목록이 잔뜩 붙어 나옵니다. 블로그에 그대로 붙이기엔 산만합니다.

「굵은 글씨 쓰지 마」라고 적어도 잘 안 걸립니다. 문서가 이 절에서 먼저 드는 방법이 금지를 뒤집어 적는 것입니다. 「쓰지 마」 대신 원하는 모양을 적으라는 것입니다. ②가 금지를 두고 앞에 이유를 붙이는 쪽이라면, 이건 금지를 아예 원하는 모양으로 바꿔 적는 쪽입니다.

그런데 문서에 제가 몰랐던 게 하나 더 있었습니다.

The formatting style used in your prompt may influence Claude’s response style. If you are still experiencing steerability issues with output formatting, try matching your prompt style to your desired output style as closely as possible. For example, removing markdown from your prompt can reduce the volume of markdown in the output.

내가 보낸 글에 굵은 글씨와 점 목록이 많으면 답에도 많아지기 쉽다는 것입니다. 그래서 시킬 말에서 별표와 점을 빼면 답에서도 줄어들 수 있다고 적혀 있습니다. 문서도 「그럴 수 있다」는 쪽으로 적어뒀지 반드시 그렇게 된다고 하지는 않습니다.

저는 프롬프트를 정리한답시고 점 목록으로 조목조목 적고 있었습니다. 그게 「이런 모양으로 답하라」는 신호가 되고 있었던 셈입니다.

굵은 글씨나 점 목록 없이 줄글로 받고 싶으면 시킬 말도 줄글로 적으면 됩니다. 문서가 쓰는 말로는 산문입니다.

문서가 든 다른 방법 하나는 ⑤에서 본 태그로 형식 자체를 지정하는 것입니다. 문서에 실린 예시는 이렇습니다.

Try: “Write the prose sections of your response in <smoothly_flowing_prose_paragraphs> tags.”

「산문 문단으로 쓴 부분을 이 태그 안에 넣어달라」는 뜻입니다. 태그 이름 자체가 원하는 모양을 말해주고 있어서, 이름만 바꿔 쓰셔도 됩니다.

「역할을 주라」는 말은 채팅 이야기가 아닙니다

프롬프트 이야기를 찾아보면 「너는 20년 경력 카피라이터야」로 시작하라는 말을 많이 봅니다. 공식 문서에도 그 항목이 있습니다.

Setting a role in the system prompt focuses Claude’s behavior and tone for your use case. Even a single sentence makes a difference:

그런데 system prompt 는 API 요청 안에 넣는 값입니다. 문서에서 이 항목 아래 붙은 예시가 코드입니다. 코드 상자 위에 언어를 고르는 칸이 아홉 개 붙어 있습니다. cURL · CLI · Python · TypeScript · C# · Go · Java · PHP · Ruby입니다. 처음 열면 Python 쪽이 펼쳐져 있습니다.

그 코드 안에 system= 으로 시작하는 줄이 있습니다. 거기가 역할을 적는 자리입니다. 예시로 적힌 역할은 「파이썬을 잘 아는 코딩 도우미」입니다.

프로그램을 만들 때 쓰는 자리라는 뜻입니다. 채팅에서는 이런 코드를 보낼 일이 없으니, 같은 일을 하려면 적는 자리가 달라집니다.

그래서 「클로드한테 역할부터 정해주라」면서 이 항목을 채팅 사용법인 것처럼 옮겨놓은 글을 보시면, 개발자 문서의 system prompt 이야기가 그대로 넘어온 것입니다.

채팅에서 비슷하게 하려면 자리가 셋 있습니다. 걸리는 범위가 다릅니다.

어디에 적나	어디까지 걸리나
대화창 첫 줄에 그냥 적기	그 대화 하나에만. 새 대화를 열면 다시 적어야 합니다
설정 → 일반의 「Claude 지침」 칸	계정 전체의 모든 대화에
프로젝트를 만들고 그 안의 「지침」 칸	그 프로젝트 안의 모든 대화에

⚠️ 자리마다 서로 어긋나는 말을 적어두면 결과가 흔들립니다. 계정 전체에 「짧게 답해」를 적어두고 프로젝트 지침에 「자세히 써」를 적어두면 어느 쪽이 이길지 모릅니다.

👉 프로젝트 지침 칸은 자리가 헷갈리기 쉽습니다. 지침·메모리·컨텍스트·예정됨 네 칸의 차이와, 적어둔 지침이 진짜 걸렸는지 확인하는 방법은 클로드 프로젝트 지침 쓰는 법에 따로 정리해뒀습니다.

한 번에 안 나왔을 때 — 공식 안내 네 가지

지원 문서 「My prompt isn’t giving me a helpful answer.」에는 네 가지가 적혀 있습니다. 코드가 한 줄도 없어서 채팅에 그대로 옮길 수 있습니다.

Explain your ask simply and clearly.

Make sure that your prompt contains as much context as possible. Pretend you are giving these instructions to someone with no background knowledge about what you are asking.

Break down complex requests into substeps.

Give Claude feedback: you provide Claude with follow-up instructions, clarifications, or ask it to rewrite an answer.

첫째와 둘째는 이 글의 ①에서 다룬 이야기이고, 이유를 붙이는 ②가 둘째를 한 걸음 더 밀고 간 것입니다. 셋째와 넷째가 이 글에서 아직 안 다룬 것입니다.

셋째는 다음 절에서 따로 보겠습니다. 넷째부터 보면, 프롬프트를 처음부터 완벽하게 쓰려고 애쓰지 말고 나온 답을 보고 되물으라는 것입니다. 문서는 넷째 줄 하나에 되묻는 방법을 세 가지로 적어뒀습니다. 이어서 시키기, 헷갈렸던 걸 분명히 해주기, 다시 써달라고 하기입니다.

저는 이렇게 씁니다.

• 전체를 다시 시키지 않고 문단을 지정합니다. 「세 번째 문단만 다시」처럼요
• 왜 안 맞는지 한 줄을 붙입니다. 「너무 설명조라 읽기 지루합니다」
• 마음에 든 부분이 있으면 그것도 말합니다. 「첫 문단 말투는 좋습니다. 그대로 두세요」

세 번째가 의외로 중요합니다. 안 적으면 다시 쓰면서 마음에 들었던 부분까지 같이 바뀝니다.

글 한 편을 한 번에 시키지 마세요

앞 절 안내의 셋째가 이것입니다.

Break down complex requests into substeps.

복잡한 부탁은 작은 단계로 쪼개라는 것입니다. 「블로그 글 한 편 써줘」는 클로드 입장에서 한 덩어리로 오는 큰 부탁입니다.

개발자 문서에도 같은 이야기가 더 구체적으로 적혀 있습니다. 여러 단계로 나눠 시키는 방식 중 문서가 제일 흔하다고 든 것은 스스로 고치기입니다.

The most common chaining pattern is self-correction: generate a draft → have Claude review it against criteria → have Claude refine based on the review. Each step is a separate API call so you can log, evaluate, or branch at any point.

초안을 쓰게 하고 → 기준에 맞는지 검사하게 하고 → 검사 결과대로 고치게 하는 세 걸음입니다.

⚠️ 이 대목은 개발자 문서 쪽 이야기라서 원래는 API를 세 번 호출하는 방식을 말합니다. 채팅에서는 대화 한 곳에서 메시지 세 번이면 됩니다. 대화가 이어지니까 앞 단계 결과를 다시 붙일 필요가 없습니다.

제가 쓰는 순서는 앞에 소제목 단계를 하나 더 붙여 네 번입니다.

몇 번째 메시지	무엇을 시키나
첫 번째	소제목만 뽑아주세요. 본문은 아직 쓰지 마세요
두 번째	(첫 회에는 소제목을 손본 뒤) 이번 차례인 소제목 하나만 골라 그 본문만 써주세요
세 번째	지금 쓴 부분을 다음 세 가지로 검사해주세요. 확인 안 된 사실을 단정한 곳, 같은 말이 두 번 나온 곳, 소리 내어 읽기 어려운 문장입니다
네 번째	검사에서 나온 것만 고쳐주세요. 나머지 문장은 그대로 두세요

두 번째부터 네 번째까지를 소제목 수만큼 되풀이합니다. 소제목 하나가 끝날 때마다 검사와 고치기를 붙이는 쪽이 다 쓰고 한꺼번에 검사하는 것보다 낫습니다.

소제목을 먼저 받는 게 핵심입니다. 글 전체를 받고 나면 구조가 마음에 안 들어도 통째로 다시 시켜야 하는데, 소제목 단계에서는 한 줄만 고치면 됩니다.

네 번째 줄의 「나머지는 그대로」는 꼭 넣으세요. 안 넣으면 고치라고 안 한 문장까지 다시 씁니다.

여섯 가지를 한 벌로 붙이면 이렇게 됩니다

앞 절의 쪼개기는 글을 새로 쓰게 할 때 이야기입니다. 아래 틀은 이미 있는 원고를 고칠 때 쓰는 것이라 한 번에 보내셔도 됩니다.

지금까지 나온 것을 하나로 합친 틀입니다. 태그 줄은 그대로 두고, 괄호로 적힌 안내를 지운 뒤 그 자리에 본인 것을 넣으세요.

<원고>

(고칠 원고를 여기 붙입니다 — 제일 위입니다)

</원고>

<예시>

<예시1>(내 예전 글에서 고른 소개하는 문단)</예시1>

<예시2>(설명하는 문단)</예시2>

<예시3>(마무리 문단)</예시3>

</예시>

<배경>

네 살 아이를 키우면서 춘천에서 블로그를 씁니다. 읽는 사람은 같은 또래 아이를 데리고 어디를 갈까 고민하는 부모입니다.

</배경>

<시킬일>

위 원고를 예시의 말투로 고쳐주세요. 문단 순서는 그대로 두고 문장만 손봅니다.

이 블로그는 차분한 말투로 가고 있습니다. 이모지 없이 문장으로만 써주세요.

소리 내어 읽었을 때 걸리지 않게, 문장 하나에 쉼표가 두 개를 넘지 않게 해주세요.

</시킬일>

들어간 것을 짚어보면 이렇습니다. 원고가 제일 위(③), 예시 셋(④), 칸 나누기(⑤), 금지에 이유를 붙임(②), 시킬 말이 구체적(①). ⑥은 시킬일 칸이 굵은 글씨와 점 목록 없이 줄글로 적혀 있는 것으로 지켜집니다. 원고 칸에 붙이는 원고는 원래 모양 그대로 두셔도 됩니다.

⚠️ 배경 칸과 시킬일 칸에 적힌 문장은 제 것입니다. 괄호가 없더라도 본인 사정으로 바꿔서 보내세요. 예시 자리에 본인 글이 안 들어가면 ④가 없는 것과 같습니다.

이 틀이 길어지면 매번 붙여넣기가 일입니다

여기까지 오면 프롬프트가 꽤 길어집니다. 예시 문단 셋과 배경은 매번 똑같은데 새 대화마다 다시 붙여야 합니다.

바뀌지 않는 부분은 프로젝트 지침으로 옮기면 됩니다. 예시 · 배경 · 늘 지키는 규칙이 거기 해당합니다. 원고와 그때그때 시킬 말만 대화창에 적으면 됩니다.

⚠️ 바뀌는 값은 지침에 두지 마세요. 목표 개수, 가격, 날짜처럼 나중에 달라질 숫자를 지침에 적어두면, 그 대화에서는 새 숫자로 이야기해도 새 대화를 열면 지침에 적힌 옛날 숫자로 돌아갑니다. 지침은 대화마다 처음부터 다시 읽히기 때문입니다.

③의 「원고를 위에」는 문서 원문으로는 프롬프트 전체를 두고 한 말입니다. 지침으로 옮긴 예시는 대화보다 앞에 붙게 되니, 대화창 안에서만이라도 원고를 먼저 두시면 됩니다.

👉 옮기는 방법과 걸렸는지 확인하는 법은 클로드 프로젝트 지침 쓰는 법에 있습니다.

휴대폰에서도 똑같습니다

프롬프트는 화면 생김새와 상관이 없습니다. 입력창에 치는 글자가 전부라서 PC에서 되는 것은 휴대폰에서도 됩니다.

다만 치는 품은 조금 더 듭니다. 태그가 열 줄을 넘어가면 < 와 > 를 그만큼 여러 번 쳐야 해서 성가십니다.

👉 메모 앱에 빈 틀을 한 번 저장해두고 복사해 쓰시는 게 편합니다. 안쪽만 바꾸면 되니까 기호를 다시 칠 일이 없습니다.

앞 절에 나온 대로 바뀌지 않는 부분을 프로젝트 지침으로 옮겨두면 휴대폰에서 칠 글자 자체가 줄어듭니다.

그래도 안 될 때 볼 곳

이런 증상이면	여기부터 봅니다
시킨 대로 안 하고 자기 마음대로 씀	① — 「자세히」·「잘」처럼 재량으로 채울 자리를 남겨두지 않았는지
하지 말라고 한 걸 계속 함	② — 이유를 안 붙였을 가능성이 큽니다
원고 속 문장을 지시로 착각함	⑤ — 칸을 안 나눴을 때 나는 증상입니다
긴 원고를 붙였는데 엉뚱한 데를 고침	③ — 원고를 위에 두고 「위 원고」라고 가리켰는지
말투가 매번 다름	④ — 예시가 없거나, 예시가 서로 너무 비슷할 때입니다
굵은 글씨와 점 목록이 계속 나옴	⑥ — 내 프롬프트에 그게 많지 않은지 먼저 봅니다
새 대화를 열면 처음으로 돌아감	대화창에만 적어둔 것입니다. 「이 틀이 길어지면 매번 붙여넣기가 일입니다」 절을 보세요
답이 자꾸 길게 나옴	형식과 별개 문제입니다. 아래 문단을 보세요

답 길이는 ⑥과 별개입니다. 문서에는 모델에 따라 기본 길이가 다르다고 적혀 있고, Claude Opus 5는 기본 답이 이전 모델들보다 길게 나오는 쪽이라고 따로 표시돼 있습니다. 짧게 받고 싶으면 짧게 해달라고 직접 적으라고 문서가 권합니다.

한 장으로 정리하면 이렇습니다

• ① 오늘 온 사람에게 설명하듯 구체적으로 적습니다
• ② 금지에는 이유를 한 줄 붙입니다
• ③ 원고를 위에, 시킬 말을 아래에 둡니다
• ④ 내 예전 글 문단 세 개를 예시로 붙입니다
• ⑤ 원고 · 예시 · 시킬 말을 태그로 나눕니다
• ⑥ 줄글로 받고 싶으면 시킬 말도 줄글로 적습니다

처음부터 여섯 개를 다 지키실 필요는 없습니다. 저는 ③ 하나만 바꿨을 때 제일 크게 달라졌습니다. 순서만 뒤집는 거라 오늘 바로 해보실 수 있습니다.

같이 보면 좋은 글

• 클로드 AI 사용법 2026 — 처음 쓰시는 분을 위한 화면과 순서
• 클로드 가입 방법 3분 정리 — 비밀번호 없이 가입되는 이유까지
• 클로드 무료 유료 차이 7가지 — 결제 전에 볼 일곱 가지
• 챗GPT 무료로 어디까지 되나요 — 클로드 무료와 다섯 가지 비교
• 클로드 아티팩트 사용법 2026 — 무료도 되는데 왜 안 보이는지
• 클로드 코워크가 뭐예요 — 채팅·코드·디자인 다섯 가지 정리
• 클로드 페이블 5.1 미토스 5.1 차이 — 어느 모델이 어디서 되는지
• 애드센스 「가치가 별로 없는 콘텐츠」 — AI 때문일까 — 정책 본문엔 AI가 없었고, 막는 건 「자동 생성」이었습니다

이 글이 본 문서와 시점

이 글에 인용한 문장은 2026년 9월 5일에 연 화면 기준입니다. 문서는 예고 없이 바뀔 수 있습니다.

• 개발자 문서 — platform.claude.com 의 Prompting best practices
• 지원 문서 — Introduction to prompt design · My prompt isn’t giving me a helpful answer.

⚠️ 문서는 권하는 형식입니다. 「반드시 이렇게 해야 한다」고 정해둔 규칙이 아니라 이렇게 하면 결과가 낫더라는 안내입니다. 여섯 개를 다 지켜도 답은 매번 조금씩 다르게 나옵니다.

같은 프롬프트를 두 번 보내면 결과가 다릅니다. 그건 프롬프트가 잘못된 게 아니라 원래 그렇습니다. 한 번 보고 판단하지 마시고 두세 번 받아보신 뒤에 고치세요.