AI 도구 활용법 – 클로드 프롬프트(Claude Prompt) 습관 5가지 – 공식 문서의 전후 예시로 고치기
클로드 프롬프트(Claude Prompt)를 쓰다 보면 고쳐 달라는 뜻으로 물었는데 의견만 돌아오는 일이 있습니다. Anthropic이 공개한 프롬프트 작성 안내 문서에는 요청 문장을 덜 효과적인 쪽과 더 효과적인 쪽으로 나란히 보여 주는 예시가 실려 있어요.

그 가운데 코드를 몰라도 오늘 쓰는 클로드 프롬프트에 바로 옮길 수 있는 것을 다섯 가지 골랐습니다. 문서의 영어 예시는 2026년 10월 12일에 찍은 화면으로 싣고, 그 아래에 판매 글이나 고객 답변 같은 일에 옮겨 본 한국어 문장을 붙였어요. 한국어 문장은 문서에 실린 것이 아니고 제가 만든 예시입니다.
클로드 프롬프트 문서가 전후 예시로 보여 주는 것
이 문서는 현재 Claude 모델에 쓰는 프롬프트 엔지니어링(Prompt Engineering) 참고 자료입니다. 앞쪽에 모델별 안내가 있고, 그 뒤에 현재 모델 전체에 적용되는 기법이 일반 원칙, 출력과 형식, 도구 사용 같은 묶음으로 이어져요. AI 자동화를 짜는 사람도, 채팅으로 글을 쓰는 사람도 클로드 프롬프트를 쓸 때 참고할 만한 자료라고 봅니다.
이 글에서 고른 클로드 프롬프트 습관 다섯 가지가 문서의 어느 절에 있는지부터 적어 두면 이렇습니다. 묶음과 순서는 제가 정한 것이고, 문서가 “다섯 가지”로 묶어 소개한 것은 아닙니다.
| 고칠 습관 | 문서의 절 | 문서에 있는 것 |
|---|---|---|
| 제안을 묻는 말투 | Tool use > Tool usage | 전후 예시 |
| 이유 없는 금지 | Add context to improve performance | 전후 예시 |
| 하지 말 것만 적기 | Control the format of responses | 바꿔 쓴 문장 한 쌍 |
| 짧게 던지는 요청 | Be clear and direct | 전후 예시 |
| 질문 먼저, 자료 나중 | Long context prompting | 권장 구조와 수치 |
문서는 기법 묶음 첫머리에 단서를 하나 달아 뒀어요. 특정 모델 이름이 붙은 기법은 그 모델에서 잰 것으로 보고, 다른 모델에 옮기기 전에 직접 다시 확인하라는 내용입니다. 아래 다섯 가지 가운데 모델 이름이 붙은 부분은 본문에 그대로 적었습니다.
“제안해 줄래?”라고 쓰면 제안만 돌아올 때가 있다
문서는 최신 Claude 모델이 지시를 정밀하게 따르도록 훈련됐다고 적습니다. 그래서 실제로는 바꿔 주길 바라면서 바꿀 점을 제안해 줄 수 있냐고 물으면, Claude가 고치는 대신 제안을 내놓을 때가 있다는 거예요. 행동하게 하려면 더 명시적으로 쓰라는 문장 바로 아래에 이 예시가 있습니다.

같은 차이를 우리말 클로드 프롬프트에 옮겨 봤어요. 아래는 제가 만든 예시입니다.
묻는 말투
- 이 상세페이지 문구 좀 봐줄 수 있어?
- 이 답변 메일 어떤지 의견 줄래?
- 표에 고칠 데 있으면 알려 줘
시키는 말투
- 이 상세페이지 문구를 고쳐서 완성본으로 써 줘
- 이 답변 메일을 정중한 말투로 다시 써 줘
- 표에서 틀린 합계를 찾아 고친 표를 줘
의견만 듣고 싶은 날도 있으니 묻는 말투가 틀린 것은 아닙니다. 받고 싶은 결과물이 고친 완성본이라면 그렇게 적으라는 얘기예요.
이 설명이 실린 자리
이 내용은 문서의 도구 사용(Tool use) 절에 있습니다. Claude가 도구로 파일을 읽고 고치는 상황을 다루는 대목이라, 도구 없이 대화만 하는 채팅에서도 같은 일이 생긴다고 문서가 적은 것은 아니에요. 같은 절에는 앱을 만드는 사람이 쓸 수 있는 프롬프트 문구가 두 방향으로 실려 있습니다. 시스템 프롬프트(System Prompt)에 넣어 기본으로 실행까지 하게 하는 문구가 하나, 분명히 시키기 전에는 조사와 권고만 하게 하는 문구가 하나입니다.
금지 한 줄보다 이유가 붙은 한 줄이 낫다
지시 뒤에 있는 맥락이나 동기를 알려 주면, 예를 들어 그 행동이 왜 중요한지 설명해 주면 Claude가 목표를 더 잘 이해하고 더 맞는 답을 내는 데 도움이 될 수 있다고 문서는 적습니다. 예시는 말줄임표를 쓰지 말라는 지시예요. 덜 효과적인 쪽은 금지만 적었고(NEVER는 대문자), 더 효과적인 쪽은 이 답을 음성 합성 엔진이 소리 내어 읽는데 엔진이 말줄임표를 어떻게 읽을지 모른다는 사정을 함께 적었습니다.

예시 바로 아래에 문서가 덧붙인 문장은 하나입니다. “Claude is smart enough to generalize from the explanation.” 설명을 들으면 거기서 일반화할 수 있다는 뜻이에요.
우리말 클로드 프롬프트로 옮기면 이런 식이 됩니다. 사정은 제가 지어낸 예시입니다.
| 금지만 적은 문장 | 이유를 붙인 문장 |
|---|---|
| 이모지 쓰지 마. | 이 글은 쇼핑몰 상세페이지에 붙여 넣을 건데 거기서 이모지가 깨져 보여. 이모지 없이 써 줘. |
| 영어 쓰지 마. | 읽는 분이 60대 고객이라 영어 낱말이 낯설어. 우리말로 풀어서 써 줘. |
| 길게 쓰지 마. | 문자 메시지로 보낼 거라 한 화면에 다 보여야 해. 세 문장 안으로 써 줘. |
하지 말 것 대신 원하는 모습을 적는다
형식을 다루는 절에서 문서는 효과가 좋은 방법을 넷 드는데, 첫 번째가 하지 말 것 대신 할 것을 말하라는 항목입니다. 마크다운(Markdown)을 쓰지 말라고 적는 대신, 답이 자연스럽게 이어지는 산문 문단으로 이뤄지게 해 달라고 적어 보라는 한 쌍이 실려 있어요.

같은 목록의 세 번째 항목도 같이 볼 만합니다. 프롬프트에 쓴 형식이 답의 형식에 영향을 줄 수 있어서, 프롬프트에서 마크다운을 빼면 답에 나오는 마크다운 양이 줄 수 있다고 해요. 번호와 굵은 글씨를 잔뜩 넣은 클로드 프롬프트로 “문단으로 써 줘”라고 시키고 있었다면 요청문의 모양부터 바꿔 볼 일입니다.
아래는 제가 만든 한국어 클로드 프롬프트 예시예요.
- “번호 목록 쓰지 마.” → “자연스럽게 이어지는 문단 글로 써 줘.”
- “딱딱하게 쓰지 마.” → “단골에게 보내는 안내 문자처럼 편한 존댓말로 써 줘.”
- “표로 만들지 마.” → “항목마다 한 문장씩, 줄글로 이어서 써 줘.”
모델에 따라 반대로 손봐야 하는 경우
문서는 마크다운을 줄이는 긴 예시 문구를 실은 뒤, Claude Fable 5.1은 이전 모델보다 이미 형식을 덜 쓴다고 적었습니다. 그 모델에 이런 문구를 넣으면 내용에 필요한 구조까지 눌릴 수 있으니 빼거나 더 짧은 규칙으로 바꾸라는 안내예요.
기본을 넘는 결과는 요청해야 나온다
문서의 일반 원칙 묶음은 분명하고 직접적으로 쓰라는 절로 시작합니다. 기대 이상의 결과를 원하면 모델이 모호한 프롬프트에서 알아서 짐작하길 기대하지 말고 명시적으로 요청하라고 적혀 있어요. Claude를 뛰어나지만 우리 쪽 기준과 일하는 방식을 아직 모르는 새 직원으로 생각하라는 설명도 같은 절에 있습니다.

같은 절에는 문서가 황금률(Golden rule)이라고 부르는 점검법이 있습니다. 그 일의 사정을 거의 모르는 동료에게 프롬프트를 보여 주고 따라 해 보라고 했을 때 동료가 헷갈린다면 Claude도 헷갈린다는 거예요.
우리말 클로드 프롬프트로는 이렇게 옮길 수 있습니다. 제가 만든 예시예요.
한 문장 요청
- 매출 대시보드 만들어 줘
- 상세페이지 문구 써 줘
- 고객 문의 답변 써 줘
기대 수준을 적은 요청
- 매출 대시보드를 만들어 줘. 쓸 만한 기능과 상호작용을 넣을 수 있는 만큼 넣고, 기본 수준을 넘어 완성된 형태로 만들어 줘
- 상세페이지 문구를 써 줘. 첫 화면 문구, 특징 설명, 자주 묻는 질문까지 한 벌로 써 줘
- 고객 문의 답변을 써 줘. 사과, 원인 설명, 처리 일정, 다음 안내가 다 들어가게 써 줘
문서 뒤쪽의 이전 세대 모델에서 옮겨 올 때 볼 항목에도 같은 대시보드 문장이 다시 나오고, 애니메이션이나 상호작용 요소는 원할 때 명시적으로 요청하라는 항목이 이어집니다. 반대 방향의 주의도 그 목록에 있어요. 예전에 더 꼼꼼히 하라고 모델을 다그치던 문구는 줄이라는 것이고, Claude 4.6 모델은 더 적극적이라 이전 모델에 필요했던 지시에 과하게 반응할 수 있다는 이유가 붙어 있습니다.
긴 자료는 위에, 질문은 맨 아래에 둔다
다섯 번째는 클로드 프롬프트 안에서 자료와 질문을 놓는 순서입니다. 문서는 2만 토큰(token) 이상의 큰 문서나 자료를 넣을 때 긴 자료를 프롬프트 위쪽에, 질문과 지시와 예시보다 위에 두라고 권합니다. 이렇게 하면 모든 모델에서 성능이 좋아진다고 적고, 바로 아래 상자에 수치를 달았어요.

이 30퍼센트는 “최대”이고 “테스트에서”라는 말이 붙은 값입니다. 어떤 테스트였는지, 어느 모델로 쟀는지는 문서에 나와 있지 않아요. 짧은 질문 하나를 던질 때의 얘기도 아닙니다.

계약서를 붙여 넣고 묻는 클로드 프롬프트로 옮기면 아래와 같습니다. 제가 만든 예시예요.
질문 먼저
- 이 계약서에서 위약금 조항 찾아줘
- (계약서 전문)
자료 먼저
- (계약서 전문)
- 위 계약서에서 위약금 조항을 찾아서 조항 번호와 함께 알려 줘
같은 절에 두 가지가 더 있어요. 문서를 여러 개 넣을 때는 문서마다 태그로 감싸고 출처 같은 정보를 하위 태그로 나눠 적으라고 하고, 긴 문서 작업에서는 관련 부분을 먼저 인용하게 한 뒤 본 작업을 시키라고 합니다. 인용을 먼저 하면 Claude가 관련 내용에 집중하고 나머지를 흘려보내는 데 도움이 된다고 문서는 설명합니다.
다섯 가지를 클로드 프롬프트 한 건에 넣으면
판매 글을 고치는 클로드 프롬프트 하나에 다섯 가지를 다 넣어 봤습니다. 문서에 있는 문장은 아니고, 이 글의 내용을 묶어 제가 만든 예시예요.
(상품 설명서 전문)
(지금 쓰는 상세페이지 문구)
위 두 자료를 바탕으로 상세페이지 문구를 고쳐서 완성본으로 써 줘.
쇼핑몰 편집기에 그대로 붙여 넣을 거라 이모지는 깨져 보여. 이모지 없이 써 줘.
항목마다 두세 문장짜리 문단으로 이어서 써 줘.
첫 화면 문구, 특징 설명, 자주 묻는 질문까지 한 벌로, 기본 수준을 넘어 완성된 형태로 만들어 줘.자료가 맨 위에 있고, 요청은 “고쳐서 완성본으로”라고 시키는 말투입니다. 이모지 금지에는 이유가 붙었고, 형식은 원하는 모습으로 적었고, 기대 수준도 문장으로 들어가 있어요. 클로드 프롬프트를 보내기 전에 훑어볼 순서로 바꾸면 이렇습니다.
- 긴 자료가 있으면 프롬프트 위쪽으로 올리고 질문을 그 아래에 둔다
- 받고 싶은 결과물을 “봐 줘” 대신 고쳐 줘, 써 줘로 적는다
- 금지할 것이 있으면 왜 안 되는지 한 줄을 붙인다
- 싫은 형식 대신 원하는 형식을 적는다
- 기본보다 더 바라는 것이 있으면 그 수준을 문장으로 적는다
클로드 프롬프트 한 건을 다듬는 범위를 넘어 AI 자동화에서 모델이 읽는 자료 전체를 어떻게 짤지는 컨텍스트 엔지니어링 글에서 다뤘고, 매번 같은 요청문을 다시 쓰지 않도록 절차로 묶어 두는 방법은 에이전트 스킬 글에 있습니다.
참고한 공식 문서
Anthropic의 Prompting best practices를 2026년 10월 12일에 읽고 정리했습니다. 영어 예시 화면은 같은 날 이 문서에서 찍은 것이고, 한국어 예시는 제가 만든 것입니다. 문서는 바뀔 수 있으니 원문을 확인해 주세요.
클로드 프롬프트 자주 묻는 질문
클로드에게 “제안해 줄래?”라고 쓰면 왜 제안만 하나요?
Anthropic 공식 문서는 최신 Claude 모델이 지시를 정밀하게 따르도록 훈련됐다고 설명합니다. 그래서 바꿔 주길 바라고 “바꿀 점을 제안해 줄래?”라고 써도 제안만 내놓을 때가 있다고 적고 있어요. 이 설명은 문서의 도구 사용 절에 있습니다.
질문을 맨 아래에 두면 답이 얼마나 좋아지나요?
문서는 질문을 끝에 두면 테스트에서 응답 품질이 최대 30퍼센트 좋아질 수 있고, 복잡한 여러 문서를 넣었을 때 특히 그렇다고 적었습니다. 어떤 테스트와 모델로 잰 값인지는 문서에 없고, 대상은 2만 토큰 이상의 긴 자료입니다.
하지 말라는 지시는 쓰면 안 되나요?
쓰지 말라는 내용은 문서에 없습니다. 문서는 형식을 다룰 때 하지 말 것 대신 할 것을 말하라고 권하고, 금지가 필요하면 이유를 함께 적은 예시를 더 효과적인 쪽으로 보여 줍니다.
글에 나온 규칙 파일과 에이전트는 Claude Code에서 쓰는 방식이고, 공식 안내는 Claude Code 공식 문서에 있습니다.
이 글은 직접 만들고 운영하며 남긴 기록입니다. 적힌 수치는 작성 시점의 제 계정 기준이며, 같은 결과나 수익을 보장하지 않습니다.


4 Comments