클로드 프롬프트 작성법의 핵심은 원하는 결과를 분명히 적고 이유, 구체 조건, 예시를 붙이는 거예요. 앤트로픽 프롬프트 엔지니어링 모범 사례(2025년 11월 10일)가 이 네 가지를 기본 기법으로 꼽았어요.
같은 글은 과한 역할 지정과 XML 태그가 요즘 모델에서는 덜 필요하다고 설명해요. 기본기, 템플릿, 지침 넣는 곳 순서로 살펴볼게요.
한 줄 정답: 원하는 결과와 이유, 구체 조건, 예시 1개를 한 프롬프트에 담으세요.
[핵심 요약] 클로드 프롬프트 작성법이란?
클로드 프롬프트 작성법은 앤트로픽의 AI 클로드(Claude)에게 원하는 결과를 정확히 전달하는 지시문 쓰는 법이에요. 무엇을 할지, 왜 필요한지, 어떤 형식으로 받을지를 적는 게 기본이죠.
| 항목 | 내용 | 비고 |
|---|---|---|
| 기준 자료 | 앤트로픽 프롬프트 엔지니어링 모범 사례 | 2025년 11월 10일 공개 |
| 기본 기법 4가지 | 분명한 지시, 이유 설명, 구체 조건, 예시 | 단순 작업은 기본기만 |
| 역할 지정 | 과하게 쓰면 도움이 줄 수 있음 | 원하는 관점을 직접 적기 |
| 형식 제어 | 하지 말 것보다 할 것을 적기 | 예시나 시작 문구 지정 |
| 반복 지시 | 프로젝트 지침에 한 번 저장 | 무료 계정은 프로젝트 5개 |
1. 클로드 프롬프트 작성법, 기본기 네 가지
앤트로픽 프롬프트 엔지니어링 모범 사례는 기본 기법을 꾸준히 쓰기만 해도 답변 품질이 바로 좋아진다고 설명해요.
모델이 알아서 짐작하리라 기대하지 말고 원하는 것을 직접 말하라는 게 출발점이에요.
| 기본기 | 흐린 요청 | 고친 요청 |
|---|---|---|
| 분명한 지시 | 분석 대시보드 만들어 줘 | 분석 대시보드를 만들어 줘. 관련 기능과 상호작용을 최대한 넣고 기본을 넘어선 완성본으로 |
| 이유 설명 | 글머리표 절대 쓰지 마 | 글머리표보다 문단이 읽기 편해서, 자연스러운 문단으로 답해 줘 |
| 구체 조건 | 지중해식 식단 짜 줘 | 하루 1,800칼로리, 저혈당지수 위주로 아침, 점심, 저녁, 간식 1회와 영양 정보까지 |
| 예시 | 이 기사 요약해 줘 | 원하는 요약 예시 1개를 보여 준 뒤 같은 형식으로 요약해 달라고 요청 |
표의 예시는 모범 사례 글에 실린 영어 예시를 한국어로 옮긴 거예요.
동사로 바로 시작하고, 무엇을 다룰지보다 결과물에 무엇이 들어가야 하는지 적으라는 조언도 함께 있어요.
1-1. 왜 이유를 붙이면 결과가 달라질까?
규칙만 던지면 클로드는 그 규칙이 어디까지 적용되는지 알기 어려워요.
같은 글는 이유를 알려 주면 모델이 관련된 다른 형식 선택도 더 잘 판단한다고 설명해요.
결과물의 목적과 읽을 사람, 쓰일 곳, 해결하려는 문제를 한 줄씩 붙여 보세요.
2. 클로드 프롬프트 예시, 한 장 템플릿으로 조립하기
기본기를 합치면 아래처럼 하나의 템플릿이 돼요.
대괄호 안만 바꿔 넣으면 보고서, 메일, 요약 등 여러 업무에 그대로 쓸 수 있어요.
[결과물]을 작성해 줘. 이 자료는 [읽을 사람]이 [쓰일 곳]에서 볼 거라서 [이유]가 중요해. 조건은 [분량], [형식], [꼭 들어갈 항목]이야. 아래 예시와 같은 형식으로 써 줘. [예시 1개] 자료에 근거가 부족한 부분은 추측하지 말고 부족하다고 말해 줘.
마지막 문장은 모범 사례 글이 권한 불확실성 허용 문구예요.
모르면 모른다고 말해도 된다고 허락하면 지어낸 답이 줄고 신뢰도가 올라간다고 해요.
| 템플릿 칸 | 적는 내용 | 해당 기본기 |
|---|---|---|
| 결과물 | 동사로 시작하는 요청 | 분명한 지시 |
| 읽을 사람, 쓰일 곳 | 목적과 독자 | 이유 설명 |
| 분량, 형식, 항목 | 글자 수, 표나 문단, 필수 내용 | 구체 조건 |
| 예시 | 원하는 결과 1개 | 예시 |
| 마지막 문장 | 근거 부족 시 말하기 | 불확실성 허용 |
3. 역할 지정과 XML 태그는 아직 필요할까?
앤트로픽 프롬프트 엔지니어링 모범 사례는 두 기법을 예전 모델에서 유행했지만 지금은 덜 필요한 기법으로 분류해요.
“당신은 재무 상담가예요”처럼 역할을 주는 방식은 효과가 있지만, 너무 좁게 묶으면 오히려 도움이 줄 수 있다고 했어요.
그 대신 “위험 감수 성향과 장기 성장 가능성에 초점을 맞춰 분석해 줘”처럼 관점을 직접 적으라고 권해요.
| 기법 | 지금도 쓸 만한 경우 | 대안 |
|---|---|---|
| 역할 지정 | 여러 결과물의 말투를 똑같이 맞춰야 할 때 | 원하는 관점을 문장으로 적기 |
| 역할 지정 | 특정 캐릭터가 필요한 앱을 만들 때 | 역할은 짧고 넓게 |
| XML 태그 | 여러 종류 자료가 섞인 아주 복잡한 프롬프트 | 소제목, 줄바꿈, 분명한 문장 |
| XML 태그 | 자료 경계를 확실히 나눠야 할 때 | “아래 선수 정보를 바탕으로”처럼 지칭 |
정리하면 역할과 태그는 기본기가 갖춰진 뒤 필요할 때만 더하는 도구예요.
4. 출력 형식 정하기와 단계별 사고 요청
답변 형식이 원하는 대로 나오지 않는다면 지시 방향부터 바꿔 보세요.
같은 글는 하지 말 것보다 할 것을 적으라고 안내해요. “마크다운 쓰지 마” 대신 “부드럽게 이어지는 문단으로 써 줘”가 그 예시예요.
프롬프트 자체의 형식도 답변에 영향을 줘서, 마크다운을 줄이고 싶다면 프롬프트의 마크다운부터 줄이라고 했어요.
| 단계별 사고 방식 | 프롬프트에 넣는 문장 | 맞는 상황 |
|---|---|---|
| 기본형 | 메일을 쓰기 전에 단계별로 생각해 줘 | 빠르게 추론을 더하고 싶을 때 |
| 안내형 | 먼저 이 기부자에게 맞는 메시지를 생각하고, 다음에 프로그램 장점을 고른 뒤 메일을 써 줘 | 생각할 순서를 정해 주고 싶을 때 |
| 구조형 | 생각은 thinking 태그에, 메일은 email 태그에 나눠 써 줘 | 추론과 결과를 따로 검토할 때 |
클로드에 확장 사고 기능이 있으면 보통 그쪽이 수동 단계별 요청보다 낫다고 글은 설명해요.
다만 무료 플랜처럼 확장 사고를 쓸 수 없거나 추론 과정을 직접 보고 싶을 때는 위 방식이 쓸모 있어요.
4-1. 긴 작업은 프롬프트를 나눠서 이어 가세요
복잡한 작업 하나를 여러 프롬프트로 나누는 방법을 프롬프트 체이닝이라고 불러요.
시간은 더 들지만 단계마다 일이 쉬워져서 정확도가 올라간다는 설명이에요.
- 논문의 방법, 결과, 임상적 의미를 요약해 달라고 요청해요.
- 위 요약을 정확성, 명확성, 완결성 기준으로 검토하고 점수를 매겨 달라고 하세요.
- 받은 피드백을 붙여 넣고 그 내용대로 요약을 고치면 끝이에요.
한 프롬프트로 결과가 들쭉날쭉하거나 중간 검증이 필요할 때 특히 잘 맞아요.
5. 클로드 시스템 프롬프트와 프로젝트 지침, 어디에 적을까?
매번 반복하는 지시는 대화마다 붙이지 말고 한곳에 저장해 두는 편이 효율적이에요.
Claude 고객지원 프로젝트 안내(2026년 10월 14일 업데이트)에 따르면 프로젝트마다 지침을 정해 답변을 맞출 수 있어요.
격식 있는 말투나 특정 직무 관점으로 답하라는 지시가 공식 예시예요.
| 넣는 곳 | 어울리는 내용 | 공식 안내 |
|---|---|---|
| 대화 속 프롬프트 | 이번 한 번만 필요한 요청과 자료 | 기본기 네 가지 적용 |
| 프로젝트 지침 | 말투, 관점, 매번 지킬 형식 | 무료 계정도 프로젝트 최대 5개 |
| 프로젝트 지식 | 참고 문서, 코드, 자료 파일 | 유료 플랜은 RAG로 용량 최대 10배 |
| 시스템 프롬프트(API) | 앱 전체에 적용할 역할과 규칙 | 짧고 넓은 역할이 유리 |
API로 앱을 만든다면 시스템 프롬프트가 같은 역할을 해요. 호출 비용은 Claude API 토큰 요금 글에서 따로 계산해 볼 수 있어요.
모범 사례 글도 매 세션에 적용할 지시는 CLAUDE.md 파일이나 스킬 같은 방법으로 옮기라고 권했어요.
공식 자료 기준 요약, 지침을 나눠 두는 법
- 한 번만 쓸 요청은 대화창 프롬프트에 기본기 네 가지로 적어요.
- 매번 지킬 말투와 형식은 프로젝트 지침에 한 번만 저장해 두세요.
- 참고 문서는 프로젝트 지식에 올리면 그 프로젝트의 모든 대화에서 활용돼요.
- 팀 플랜에서는 프로젝트를 동료와 보기 권한, 편집 권한으로 나눠 공유할 수 있어요.
6. 업무별 템플릿, 그대로 복사해 쓰기
아래 템플릿은 모범 사례 글의 기법을 업무 상황에 맞게 조합한 거예요.
괄호 안만 바꾸고 결과를 본 뒤 한 군데씩 다듬어 보세요.
| 업무 | 템플릿 문장 | 쓴 기법 |
|---|---|---|
| 회의록 요약 | 이 회의록을 팀장이 1분 안에 읽을 수 있게 결정 사항, 담당자, 기한 표로 정리해 줘. 기한이 없으면 미정으로 적어 줘 | 이유, 형식, 불확실성 허용 |
| 메일 초안 | 거래처에 납기 연기를 알리는 메일을 써 줘. 관계 유지가 중요해서 사과와 대안을 함께 넣고 5문장 안으로 | 이유, 구체 조건 |
| 데이터 정리 | 이 분기 보고서에서 매출, 이익률, 성장률만 JSON으로 뽑아 줘. 없는 값은 null로 두고 설명 없이 중괄호로 시작해 | 형식 제어, 불확실성 허용 |
| 보고서 검토 | 아래 초안을 정확성, 명확성, 완결성 기준으로 검토하고 항목별 점수와 고칠 문장을 알려 줘 | 체이닝 2단계 |
| 블로그 개요 | 아래 예시 개요와 같은 형식으로 새 주제의 소제목 5개를 만들어 줘 | 예시(원샷) |
데이터 정리 템플릿은 모범 사례 글이 여러 기법을 합친 예시로 든 재무 지표 추출 프롬프트를 옮긴 거예요.
예시는 1개로 시작하고, 결과가 여전히 어긋날 때만 더 늘리라고 글은 권해요.
7. 답변이 어긋날 때 고치는 법
| 이런 상황이라면 | 이렇게 고쳐요 |
|---|---|
| 답이 너무 뻔하고 일반적이에요 | 구체 조건과 예시를 더하고 기본을 넘어서 달라고 요청 |
| 질문 의도를 놓쳐요 | 진짜 목표와 질문하는 이유를 적기 |
| 형식이 매번 달라요 | 예시를 주거나 시작 문구를 지정 |
| 없는 정보를 지어내요 | 모르면 모른다고 말해도 된다고 허락 |
| 제안만 하고 고쳐 주지 않아요 | “바꿔 줘”처럼 실행을 직접 요청 |
같은 글는 길고 복잡한 프롬프트가 늘 좋은 건 아니라고 강조해요.
단순하게 시작해 하나씩 더하고, 더할 때마다 실제로 나아졌는지 확인하라는 거죠.
보내기 전 프롬프트 점검
- 결과물이 무엇인지 동사로 시작하는 문장에 담았나요?
- 왜 필요한지, 누가 읽는지 한 줄이라도 적었는지 볼까요?
- 분량, 형식, 꼭 들어갈 항목을 숫자와 이름으로 정해 두세요.
- 근거가 부족하면 추측하지 말라는 문장도 넣었나요?
8. 함께 보면 좋은 글
- 다른 AI와 비교하고 싶다면 ChatGPT 프롬프트 작성법와 제미나이 프롬프트 작성법를 함께 보세요.
- 클로드를 업무 자동화까지 넓혀 쓰고 싶다면 클로드 코워크 업무 활용법 글도 참고해 보세요.
9. 클로드 프롬프트 작성법 자주 묻는 질문
Q1. 클로드에게 역할을 꼭 정해 줘야 하나요?
아니요, 과한 역할 지정은 요즘 모델에 덜 필요해요. 앤트로픽 모범 사례는 역할 대신 어떤 관점으로 분석할지 직접 적는 편이 더 효과적일 때가 많다고 설명해요.
Q2. 프롬프트는 길게 쓸수록 좋은가요?
아니요, 길고 복잡하다고 늘 좋은 결과가 나오지는 않아요. 단순하게 시작해 필요한 기법만 하나씩 더하고, 더할 때마다 결과가 나아졌는지 확인하라고 안내해요.
Q3. 클로드 프로젝트 지침은 무료로도 쓸 수 있나요?
네, 프로젝트는 무료 계정을 포함한 모든 사용자가 쓸 수 있어요. 무료 사용자는 프로젝트를 최대 5개까지 만들 수 있고, RAG로 지식 용량을 늘리는 기능은 유료 플랜에서만 제공돼요.
Q4. 클로드가 없는 내용을 지어내면 어떻게 하나요?
모르면 모른다고 말해도 된다고 프롬프트에 적어 주세요. 근거가 부족하면 추측하지 말고 부족하다고 말해 달라는 문장을 넣으면 지어낸 답이 줄어든다고 모범 사례 글은 설명해요.
공식 출처 및 팩트체크 기준
- Anthropic, Prompt engineering best practices (발표일 2025-11-10, 확인일 2026-10-21)
- Claude Help Center, What are projects? (발표일 2026-10-14, 확인일 2026-10-21)
- Anthropic 유튜브, Prompting 101 | Code w/ Claude (발표일 2025-07-31, 확인일 2026-10-21)
