프롬프트 엔지니어링의 기본기

좋은 답변은 우연히 나오지 않는다

Claude에게 "회의록 정리해 줘"라고 말하면 회의록 비슷한 문서를 받을 수 있다. 하지만 그것이 바로 제출 가능한 회의록일 가능성은 높지 않다. 누가 참석했는지, 어떤 안건이 중요했는지, 결정 사항과 할 일을 분리해야 하는지, 말투는 보고서체인지 메신저 공유용인지, 불확실한 내용은 어떻게 표시해야 하는지 Claude는 알지 못한다. 사용자가 말하지 않았기 때문이다.

프롬프트 엔지니어링은 거창한 주문을 외우는 기술이 아니다. 일을 맡길 때 필요한 설명을 빠뜨리지 않는 기술이다. 유능한 동료에게 일을 넘길 때도 "이것 좀 해 줘"만으로는 부족하다. 목적을 말하고, 배경을 공유하고, 참고 자료를 건네고, 완성 기준을 정하고, 결과물을 어떤 형식으로 받을지 합의해야 한다. Claude도 마찬가지다.

이 장의 핵심은 간단하다. 좋은 답변은 좋은 입력 구조에서 나온다. 같은 모델을 쓰더라도 어떤 사람은 매번 "쓸 만하지만 아쉬운 초안"을 받고, 어떤 사람은 바로 업무에 넣을 수 있는 산출물을 받는다. 차이는 대부분 질문의 길이가 아니라 구조에 있다. 길게 말했지만 지시와 자료와 감상이 뒤섞인 프롬프트보다, 짧더라도 목표·맥락·제약·형식이 분명한 프롬프트가 훨씬 강하다.

Anthropic의 프롬프트 엔지니어링 안내도 이 점을 강조한다. 프롬프트로 통제할 수 있는 성공 조건을 먼저 살피고, 모든 실패를 프롬프트만으로 고치려 하지 말라는 것이다.¹ 이 문장은 실무에서 특히 중요하다. Claude의 답이 마음에 들지 않을 때마다 "프롬프트를 더 잘 써야 하나?"라고만 생각하면, 도구 연결·데이터 품질·평가 기준·사람의 검토가 필요한 문제까지 프롬프트 문제로 착각하게 된다.

프롬프트는 마법 주문이 아니라 작업 지시서다. 그리고 좋은 작업 지시서는 "무엇을 해 달라"보다 먼저 "무엇이면 성공인가"를 정의한다.

먼저 '좋은 답변'의 조건을 정한다

많은 사용자가 프롬프트를 쓸 때 작업부터 적는다.

다음 글을 요약해 줘.

이 요청은 틀리지 않다. 그러나 Claude가 선택해야 할 것이 너무 많다. 짧게 요약할지 길게 요약할지, 핵심 주장만 뽑을지 숫자와 근거까지 보존할지, 임원 보고용인지 개인 이해용인지, 원문에 없는 해석을 덧붙여도 되는지 알 수 없다. 그러면 Claude는 평균적인 답을 만든다. 평균적인 답은 대체로 무난하지만, 실무에서는 무난함이 곧 재작업을 뜻한다.

프롬프트를 쓰기 전에 먼저 성공 조건을 정해야 한다. 좋은 답변의 조건은 작업마다 다르지만, 실무에서는 대개 다음 여섯 가지로 정리된다.

• 정확성: 원문, 데이터, 지시와 어긋나지 않아야 한다.

• 완전성: 빠뜨리면 안 되는 항목을 모두 포함해야 한다.

• 말투: 독자와 상황에 맞는 문체를 유지해야 한다.

• 분량: 너무 길거나 짧지 않고 사용 목적에 맞아야 한다.

• 근거 제시: 주장, 판단, 추천의 근거를 드러내야 한다.

• 금지 행동: 추측, 과장, 임의 창작, 민감정보 노출처럼 피해야 할 행동을 하지 않아야 한다.

예를 들어 "요약해 줘"라는 요청을 실무형 성공 조건으로 바꾸면 이렇게 된다.

목표: 아래 회의 메모를 팀 공유용 회의록으로 정리한다.

성공 조건:
- 결정 사항, 액션 아이템, 미해결 쟁점을 분리한다.
- 액션 아이템에는 담당자와 기한을 표시한다.
- 원문에 없는 담당자나 기한은 추측하지 말고 "미정"으로 표시한다.
- 전체 분량은 A4 반 페이지 이내로 유지한다.
- 말투는 간결한 업무 보고체로 작성한다.

이제 Claude는 무엇을 최적화해야 하는지 안다. 단순히 글을 줄이는 것이 아니라, 팀이 바로 실행할 수 있는 회의록을 만드는 것이 목표다. "추측하지 말고 미정으로 표시하라"는 조건도 중요하다. 이 한 줄이 없으면 Claude는 맥락상 그럴듯한 담당자나 기한을 만들어 낼 수 있다. 사람에게는 친절한 보완처럼 보일 수 있지만, 업무에서는 오류가 된다.

성공 조건을 세울 때는 프롬프트로 통제 가능한 것과 그렇지 않은 것을 나누어야 한다. 말투, 형식, 분량, 금지 행동, 원문 기반 답변 여부는 프롬프트로 상당 부분 통제할 수 있다. 반면 최신 가격 정보, 사내 데이터베이스에만 있는 사실, 법률적 최종 판단, 의료적 판단, 통계적으로 검증된 성능은 프롬프트만으로 보장할 수 없다. 그런 문제에는 검색, 파일 제공, 도구 연결, 전문가 검토, 평가셋이 필요하다.

다음처럼 구분하면 실수가 줄어든다.

좋은 프롬프트는 모델에게 많은 것을 떠넘기지 않는다. 모델이 잘할 수 있는 일은 명확히 지시하고, 모델만으로 해결할 수 없는 일은 시스템 설계의 과제로 남긴다. 이 감각이 생기면 프롬프트가 훨씬 안정된다.

프롬프트를 한 덩어리로 쓰지 않는다

나쁜 프롬프트의 전형은 모든 것을 한 문단에 섞는 것이다.

너는 마케팅 전문가야. 우리 회사는 B2B SaaS를 하고 있고 이번에 보안 기능을 출시했는데 고객은 중견기업 IT 관리자들이고 너무 과장하지 말고 전문적으로 써 줘. 아래 자료를 참고해서 블로그 글을 써 주고 표도 넣고 마지막에는 CTA도 넣어 줘. 너무 길지는 않게 하고 SEO도 고려해 줘. 자료는 다음과 같아...

이 프롬프트는 정보가 많지만 구조가 없다. 역할, 회사 배경, 독자, 말투, 참고 자료, 산출물 조건, 금지 사항이 모두 이어져 있다. 사람은 대충 읽고 맥락을 잡을 수 있지만, 긴 입력에서는 Claude도 경계를 헷갈릴 수 있다. 특히 참고 자료 안에 "해야 한다", "금지한다", "중요하다" 같은 문장이 들어 있으면 그것이 사용자의 지시인지 문서 속 내용인지 구분이 흐려진다.

기본 구조는 다섯 블록이면 충분하다.

## 역할
너는 [역할]이다.

## 배경
[회사, 독자, 상황, 목적]

## 작업
[이번에 수행할 구체적 작업]

## 제약 조건
[반드시 지킬 규칙과 하지 말아야 할 행동]

## 출력 형식
[제목, 섹션, 표, JSON 필드, 분량, 말투]

같은 요청을 블록으로 나누면 이렇게 바뀐다.

## 역할
너는 B2B SaaS 보안 제품을 잘 이해하는 콘텐츠 전략가다.

## 배경
우리 회사는 중견기업을 대상으로 협업 소프트웨어를 제공한다.
이번에 관리자 감사 로그와 세션 제어 기능을 출시했다.
주 독자는 사내 보안 정책을 관리하는 IT 관리자다.

## 작업
아래 참고 자료를 바탕으로 제품 출시 블로그 초안을 작성하라.

## 제약 조건
- 과장된 표현을 피하고, 실제 기능 중심으로 설명한다.
- 원문에 없는 수치나 고객 사례를 만들지 않는다.
- 전문 용어를 쓰되, 처음 등장할 때 한 문장으로 쉽게 설명한다.
- 경쟁사 비방 표현은 사용하지 않는다.

## 출력 형식
- 제목 후보 3개
- 2문단 이내의 도입부
- 본문 H2 4개
- 기능 요약 표 1개
- 마지막에 데모 신청 CTA 1문장

## 참고 자료
[여기에 자료 붙여넣기]

블록을 나누면 두 가지 이점이 생긴다. 첫째, Claude가 무엇이 지시이고 무엇이 자료인지 더 안정적으로 구분한다. 둘째, 사용자가 프롬프트를 고치기 쉬워진다. 결과가 너무 길면 출력 형식만 바꾸면 되고, 말투가 맞지 않으면 제약 조건이나 역할만 조정하면 된다. 프롬프트가 재사용 가능한 양식이 되는 것이다.

API나 프로젝트 환경에서는 이 구분이 더 중요하다. 시스템 성격의 지침은 "항상 지킬 기본 원칙"에 가깝고, 사용자 요청은 "이번에 할 일"에 가깝다. 참고 자료는 "판단의 근거로 삼을 데이터"이고, 출력 형식은 "후속 작업에 넘길 계약"이다. 이 네 가지가 섞이면 디버깅이 어려워진다. 반대로 분리하면 어느 부분을 수정해야 하는지 보인다.

역할은 '분장'이 아니라 판단 기준이다

"너는 최고의 전문가야" 같은 역할 지정은 흔히 쓰이지만, 그것만으로는 부족하다. 역할은 멋있어 보이기 위한 장식이 아니다. Claude가 무엇을 중요하게 판단해야 하는지 알려 주는 장치다.

다음 두 요청을 비교해 보자.

너는 마케팅 전문가야. 이 문구를 고쳐 줘.

너는 B2B SaaS 랜딩페이지를 검토하는 전환율 최적화 컨설턴트다.
주 독자는 보안 검토를 담당하는 IT 관리자다.
아래 문구를 검토하고, 모호한 가치 제안·과장 표현·행동 유도 부족을 중심으로 고쳐라.

첫 번째 역할은 넓다. 두 번째 역할은 판단 기준을 포함한다. 전환율, 독자, 검토 관점이 들어 있기 때문에 Claude는 단순히 문장을 예쁘게 다듬는 대신, 목적에 맞게 문구를 고친다.

역할을 쓸 때는 세 가지를 함께 정하면 좋다.

역할이 너무 강하면 부작용도 생긴다. "세계 최고의 세일즈 카피라이터처럼 써 줘"라고만 하면 과장된 문장이 나올 수 있다. "매우 냉철한 비판가처럼 검토해 줘"라고만 하면 장점보다 단점만 부각될 수 있다. 그래서 역할 뒤에는 항상 기준을 붙여야 한다.

너는 냉정하지만 실용적인 편집자다.
목표는 글을 깎아내리는 것이 아니라, 독자가 오해할 부분을 줄이고 메시지를 선명하게 만드는 것이다.

이렇게 쓰면 역할이 성격 놀이에서 업무 기준으로 바뀐다.

제로샷과 예시 기반 프롬프트를 구분한다

모든 프롬프트에 예시가 필요한 것은 아니다. 단순하고 기준이 분명한 작업은 예시 없이도 충분하다. 이를 제로샷 요청이라고 부른다. 반대로 기준 해석이 중요하거나, 특정한 문체와 형식을 맞춰야 하거나, 분류 기준이 애매한 작업에는 예시를 주는 편이 좋다. 이를 원샷 또는 퓨샷 프롬프팅이라고 부른다. Anthropic의 프롬프트 관련 자료도 명확한 지시, 예시, 구조화가 Claude의 응답 품질을 높이는 핵심 요소라고 설명한다.²

제로샷으로 충분한 작업은 대체로 다음과 같다.

• "이 문단을 3문장으로 요약하라"처럼 기준이 단순한 작업

• "아래 영어 문장을 한국어로 번역하라"처럼 결과 유형이 분명한 작업

• "이 표를 마크다운 표로 바꿔라"처럼 변환 규칙이 명확한 작업

예시가 필요한 작업은 조금 다르다.

• 고객 문의를 "긴급/보통/낮음"으로 분류해야 하는 작업

• 브랜드 문체를 맞춰야 하는 작업

• 좋은 답과 나쁜 답의 경계가 미묘한 평가 작업

• JSON, CSV, 표처럼 후속 자동화에 쓰일 형식 작업

• 법률·정책·고객지원처럼 잘못된 표현의 비용이 큰 작업

예를 들어 고객 문의 우선순위를 분류한다고 하자. 제로샷 요청은 이렇게 쓸 수 있다.

아래 고객 문의를 긴급, 보통, 낮음 중 하나로 분류해 줘.

문의: "로그인이 안 됩니다. 오늘 오후 이사회 보고 전까지 자료를 내려받아야 합니다."

그럭저럭 답은 나오겠지만, "긴급"의 기준이 조직마다 다르면 결과가 흔들린다. 이때는 예시가 기준을 만든다.

## 작업
고객 문의를 우선순위로 분류하라.

## 라벨 정의
- 긴급: 서비스 중단, 결제 장애, 보안 사고, 명시적 마감 시간이 있는 업무 차질
- 보통: 기능 오류나 사용 문의가 있으나 즉시 업무가 중단되지는 않음
- 낮음: 일반 질문, 기능 제안, 단순 안내 요청

## 예시
입력: "관리자 계정이 잠겼고 전 직원이 접속하지 못합니다."
출력: 긴급
이유: 전사 서비스 중단에 해당한다.

입력: "대시보드 색상을 바꿀 수 있나요?"
출력: 낮음
이유: 단순 기능 문의다.

입력: "파일 업로드가 가끔 실패합니다. 우회해서 업로드는 가능합니다."
출력: 보통
이유: 오류가 있지만 즉시 업무 중단은 아니다.

## 분류할 문의
"로그인이 안 됩니다. 오늘 오후 이사회 보고 전까지 자료를 내려받아야 합니다."

## 출력 형식
라벨: [긴급/보통/낮음]
이유: [1문장]

예시는 단순한 샘플이 아니라 "판단 기준의 압축본"이다. 특히 좋은 예시만 주는 것보다 나쁜 반례를 함께 주면 더 안정적이다.

## 좋은 출력 예시
라벨: 긴급
이유: 명시적 마감 시간이 있고 업무 차질이 크다.

## 나쁜 출력 예시
라벨: 긴급
이유: 고객이 급해 보인다.

## 나쁜 이유
"급해 보인다"는 감정 추정일 뿐이며, 우선순위 기준을 설명하지 못한다.

반례는 Claude에게 "이런 방향은 피하라"고 가르친다. 문체 변환에서도 유용하다. "친근하게 써 줘"라고만 하면 지나치게 가벼워질 수 있다. 대신 좋은 문장과 나쁜 문장을 함께 주면 경계가 생긴다.

좋은 문체:
"설정은 3분 안에 끝납니다. 먼저 관리자 메뉴에서 보안 탭을 열어 주세요."

피해야 할 문체:
"완전 쉽습니다! 보안 탭으로 고고하세요 😄"

문체 기준:
친절하지만 과하게 들뜨지 않는다. 존댓말을 유지한다.

예시는 많이 넣는다고 무조건 좋은 것이 아니다. 서로 다른 기준의 예시가 섞이면 오히려 혼란스럽다. 처음에는 1~3개의 대표 예시로 시작하고, 실패한 사례가 반복될 때 반례를 추가하는 방식이 좋다.

Markdown과 XML 태그로 경계를 만든다

Claude에게 긴 자료를 줄수록 가장 위험한 것은 내용 부족이 아니라 경계 붕괴다. 지시문, 참고 자료, 예시, 변수, 출력 형식이 한 덩어리로 붙어 있으면 Claude가 어느 부분을 따라야 하고 어느 부분을 분석해야 하는지 헷갈릴 수 있다. 그래서 긴 프롬프트에는 시각적 구획이 필요하다.

간단한 업무 프롬프트는 Markdown 제목만으로 충분하다.

## 목표
## 배경
## 입력 자료
## 작업 절차
## 출력 형식

하지만 참고 문서가 길거나, 문서 안에 명령문처럼 보이는 문장이 많거나, 여러 예시를 함께 넣는다면 XML 태그가 더 안정적이다. Anthropic 문서에서도 <instructions>, <example>, <formatting>처럼 의미가 분명한 태그로 프롬프트의 구성 요소를 분리하는 방식을 권장한다. 태그 이름에 정해진 정답이 있는 것은 아니지만, 감싸는 내용의 의미를 분명히 드러내야 한다.³

기본 형태는 다음과 같다.

<context>
이 작업의 배경과 독자 정보를 넣는다.
</context>

<instructions>
Claude가 수행해야 할 작업과 우선순위를 넣는다.
</instructions>

<source>
분석할 원문, 회의록, 계약 조항, 고객 문의 등을 넣는다.
</source>

<examples>
원하는 입력과 출력 예시를 넣는다.
</examples>

<format>
최종 답변의 구조, 필드, 분량, 누락 처리 규칙을 넣는다.
</format>

중요한 점은 태그를 예쁘게 쓰는 것이 아니라, 자료와 지시를 분리하는 것이다. 예를 들어 계약서 요약 작업에서 계약서 원문 안에 "본 계약은 즉시 해지한다"라는 문장이 있을 수 있다. 이것은 사용자의 명령이 아니라 계약서 내용이다. <contract> 태그로 감싸면 Claude가 그 문장을 실행 지시가 아니라 분석 대상으로 다루기 쉽다.

<instructions>
아래 계약 조항을 검토하고, 우리 회사에 불리한 조항을 찾아라.
원문에 없는 법률 판단을 확정적으로 말하지 말고, 검토 필요 항목으로 표시하라.
</instructions>

<contract>
[계약 조항 원문]
</contract>

<format>
1. 핵심 요약: 3문장 이내
2. 위험 조항 표: 조항 / 위험 이유 / 확인 질문
3. 법무팀에 물어볼 질문: 최대 5개
</format>

XML 태그는 중첩해서 쓸 수도 있다.

<examples>
  <example type="good">
    <input>배송이 늦어져서 내일 행사에 못 씁니다.</input>
    <output>긴급</output>
    <reason>명시적 마감 시간이 있고 고객 피해가 크다.</reason>
  </example>
  <example type="bad">
    <input>이 기능은 왜 이렇게 불편하죠?</input>
    <output>긴급</output>
    <reason>불만이 강해 보인다.</reason>
  </example>
</examples>

태그를 쓸 때는 일관성이 중요하다. 어떤 프롬프트에서는 <source>, 다른 프롬프트에서는 <data>, 또 다른 프롬프트에서는 <text>를 마구 섞어 쓰면 재사용성이 떨어진다. 팀에서 자주 쓰는 태그 이름을 정해 두면 좋다.

Markdown 제목과 XML 태그 중 무엇을 써야 할지 고민된다면 이렇게 판단하면 된다. 사람이 읽는 일회성 요청에는 Markdown이 편하다. 긴 문서, 반복 업무, API 연결, 자동 파싱이 필요한 작업에는 XML 태그가 유리하다. 둘을 섞어도 된다. 중요한 것은 Claude가 각 부분의 역할을 분명히 알 수 있게 만드는 것이다.

출력 형식은 '원하는 모양'이 아니라 계약이다

"표로 정리해 줘"는 출력 형식 지시처럼 보이지만 실제로는 너무 느슨하다. 몇 개 열을 만들지, 열 이름은 무엇인지, 누락된 값은 어떻게 표시할지, 긴 설명을 허용할지, 표 아래에 해설을 붙여도 되는지 정하지 않았기 때문이다. Claude는 그 빈칸을 알아서 채운다. 운이 좋으면 마음에 드는 표가 나오고, 운이 나쁘면 다시 고쳐야 한다.

출력 형식을 정할 때는 다음을 명시해야 한다.

• 필드명 또는 열 이름

• 필드 순서

• 허용 값 또는 선택지

• 누락된 정보 처리 방식

• 분량 제한

• 추가 설명 허용 여부

• 금지 표현 또는 금지 형식

예를 들어 고객 문의 추출 작업을 JSON으로 받고 싶다면 "JSON으로 반환"만으로는 부족하다.

아래 고객 문의에서 정보를 추출해 JSON으로 반환해 줘.

더 안정적인 지시는 이렇게 쓴다.

아래 고객 문의에서 정보를 추출하라.

출력은 유효한 JSON 객체 하나만 반환한다. 코드블록, 설명 문장, 주석은 쓰지 않는다.

스키마:
{
  "customer_name": "문자열 또는 null",
  "order_id": "문자열 또는 null",
  "issue_category": "delivery | refund | product | account | other",
  "urgency": "low | medium | high",
  "requested_action": "문자열 또는 null",
  "missing_fields": ["확인되지 않은 필드명"]
}

규칙:
- 원문에 없는 정보는 추측하지 말고 null로 둔다.
- issue_category는 반드시 허용 값 중 하나를 사용한다.
- urgency 판단 근거가 부족하면 medium을 기본값으로 사용하고 missing_fields에 "urgency_evidence"를 추가한다.

이렇게 쓰면 Claude는 답변을 후속 자동화에 넘기기 쉬운 형태로 만든다. 물론 중요한 프로덕션 시스템에서는 프롬프트만 믿지 말고 JSON 파서, 스키마 검증, 재시도 로직을 함께 써야 한다. 그러나 프롬프트 단계에서 스키마를 명확히 주면 형식 붕괴가 크게 줄어든다. Anthropic의 학습 자료에서도 출력 형식 지정과 Claude에게 적합한 표현 방식은 프롬프트 품질의 핵심 주제로 다뤄진다.⁴

문서 작업에서도 출력 형식은 계약처럼 써야 한다.

출력 형식:
1. 제목: 30자 이내, 숫자나 과장 표현 금지
2. 요약: 2문장, 각 문장 40자 이내
3. 본문:
   - H2 소제목 3개
   - 각 소제목 아래 2문단
   - 각 문단은 3문장 이하
4. 마지막 문장: 독자가 바로 실행할 수 있는 행동 제안

금지:
- "혁신적인", "압도적인", "최고의" 같은 검증 불가능한 표현
- 원문에 없는 통계 수치
- 이모지

여기서 "30자 이내", "2문장", "H2 소제목 3개"처럼 측정 가능한 조건이 중요하다. "짧게", "전문적으로", "보기 좋게"는 사람마다 기준이 다르다. Claude가 따를 수 있는 조건으로 바꿔야 한다.

좋은 지시는 '하지 마'보다 '이렇게 해'에 가깝다

금지 조건은 필요하다. "추측하지 말라", "민감정보를 노출하지 말라", "원문에 없는 수치를 만들지 말라"는 매우 중요한 지시다. 하지만 프롬프트가 금지어만 가득하면 Claude는 무엇을 해야 하는지보다 무엇을 피해야 하는지에 집중하게 된다. 결과가 소극적이거나 어색해질 수 있다.

나쁜 예를 보자.

너무 길게 쓰지 말고, 어려운 말 쓰지 말고, 과장하지 말고, 뻔한 말 하지 말고, 마케팅 느낌 나지 않게 써 줘.

이 요청은 사용자의 불만은 잘 드러내지만 대안이 없다. 더 좋은 방식은 금지를 긍정형 기준으로 바꾸는 것이다.

문체 기준:
- 한 문장은 40자 안팎으로 쓴다.
- 전문 용어는 필요할 때만 쓰고, 처음 등장할 때 쉬운 설명을 붙인다.
- 기능의 장점은 실제 사용 상황과 연결해 설명한다.
- 검증할 수 없는 최상급 표현 대신 구체적인 변화나 사용 예를 쓴다.

"하지 마"는 울타리다. "이렇게 해"는 길이다. 둘 다 필요하지만, 길이 없는 울타리는 답답한 결과를 만든다. 특히 글쓰기·마케팅·교육 콘텐츠처럼 표현의 품질이 중요한 작업에서는 피해야 할 표현과 원하는 표현을 함께 제시해야 한다.

피해야 할 표현:
"업무 효율을 혁신적으로 개선합니다."

원하는 표현:
"반복 승인 절차를 한 화면에서 확인해, 담당자가 다음 단계를 놓치지 않게 돕습니다."

차이:
추상적 장점이 아니라 실제 사용 장면을 보여 준다.

이런 식의 미니 예시는 긴 설명보다 강하다. "전문적이면서도 친근하게"라는 말보다, 한 문장의 좋은 예시가 Claude에게 더 분명한 기준을 준다.

한국어 프롬프트에서 자주 무너지는 지점

한국어 프롬프트는 영어 프롬프트와 다른 함정이 있다. Claude가 한국어를 잘 처리하더라도, 한국어 자체의 생략과 높임 표현 때문에 지시가 흐려질 수 있다.

첫 번째 문제는 주어 생략이다.

검토하고 이상하면 수정해 줘.

무엇을 검토해야 하는가? 이상하다는 기준은 무엇인가? 수정 범위는 문장인가, 구조인가, 사실관계인가? 한국어에서는 대화 맥락상 통할 수 있지만, 업무 프롬프트에서는 기준이 부족하다.

아래 보고서 초안을 검토하라.
검토 기준은 사실관계 불일치, 중복 문장, 표와 본문 수치 차이, 과장 표현이다.
수정본을 바로 작성하지 말고 먼저 문제 목록을 표로 제시하라.

두 번째 문제는 존댓말과 반말의 혼합이다. 사용자가 "친근하게 써 줘"라고 하면 Claude가 반말, 과한 감탄사, 이모지를 섞을 수 있다. 한국어에서는 친근함과 예의의 조합을 구체적으로 지정해야 한다.

문체:
- 존댓말을 사용한다.
- 문장은 짧고 자연스럽게 쓴다.
- 친구처럼 가볍게 농담하지 않는다.
- 고객 안내문에 어울리는 차분한 친절함을 유지한다.

세 번째 문제는 번역투 지시다. "프로페셔널하고 인게이징하게 작성해 줘" 같은 표현은 대략적인 느낌은 전달하지만 결과가 흔들린다. "전문적"과 "흥미로운"을 측정 가능한 기준으로 바꾸는 편이 낫다.

전문성 기준:
- 주장마다 이유를 붙인다.
- 검증되지 않은 유행어를 쓰지 않는다.
- 독자가 바로 적용할 수 있는 예시를 포함한다.

흥미 기준:
- 첫 문단에 독자가 겪는 구체적 문제 상황을 제시한다.
- 각 절의 첫 문장은 질문이나 장면으로 시작한다.

네 번째 문제는 모호한 수식어다. "적당히", "깔끔하게", "풍부하게", "간단히", "임팩트 있게"는 자주 쓰이지만 기준이 없다. 이런 표현은 숫자, 구조, 예시로 바꿔야 한다.

다섯 번째 문제는 과도하게 긴 복문이다. 한국어에서는 여러 조건을 쉼표로 이어 붙이기 쉽다. 그러나 프롬프트에서는 한 문장에 조건을 많이 넣을수록 누락 가능성이 커진다. 조건은 문장보다 목록이 낫다.

나쁜 예:
아래 글을 읽고 핵심을 살리면서 너무 딱딱하지 않게, 하지만 가벼워 보이지는 않게, 독자가 이해하기 쉽게, 필요한 경우 예시도 넣어서, 전체적으로 자연스럽게 고쳐 줘.

좋은 예:
아래 글을 독자 안내문으로 고쳐라.

수정 기준:
- 핵심 메시지는 유지한다.
- 존댓말을 사용한다.
- 문장은 평균 40자 이내로 줄인다.
- 어려운 용어에는 쉬운 설명을 붙인다.
- 필요한 곳에만 예시를 1개 추가한다.

출력:
1. 수정본
2. 주요 수정 이유 5개

한국어 프롬프트의 핵심은 "느낌"을 "조건"으로 번역하는 것이다. 사용자가 원하는 감각을 Claude가 실행 가능한 규칙으로 바꿔 주어야 한다.

바로 가져다 쓰는 기본 템플릿 20선

프롬프트는 매번 새로 쓸 필요가 없다. 자주 하는 일은 템플릿으로 만들어 두고, 변수만 바꾸면 된다. 아래 템플릿은 Claude.ai 채팅, 프로젝트 지침, API 사용자 메시지 어디에서든 응용할 수 있다. 대괄호 안의 내용을 바꿔 쓰면 된다.

1. 요약 템플릿

## 작업
아래 자료를 [독자]가 빠르게 이해할 수 있도록 요약하라.

## 성공 조건
- 핵심 주장 [개수]개를 놓치지 않는다.
- 중요한 수치와 고유명사는 유지한다.
- 원문에 없는 해석은 추가하지 않는다.
- 불확실한 내용은 "확인 필요"로 표시한다.

## 출력 형식
1. 한 문장 요약
2. 핵심 포인트 [개수]개
3. 확인이 필요한 내용

## 자료
[붙여넣기]

2. 재작성 템플릿

## 작업
아래 문장을 [상황]에 맞게 다시 작성하라.

## 문체 기준
- [존댓말/반말]을 사용한다.
- 독자는 [독자]다.
- 문장은 [짧게/중간/상세하게] 쓴다.
- [피해야 할 표현]은 사용하지 않는다.

## 출력
- 수정본
- 수정 이유 3개

## 원문
[붙여넣기]

3. 회의록 정리 템플릿

## 작업
아래 회의 메모를 실행 중심 회의록으로 정리하라.

## 규칙
- 결정 사항과 논의 사항을 분리한다.
- 액션 아이템에는 담당자, 기한, 다음 단계를 표시한다.
- 담당자나 기한이 없으면 "미정"으로 표시한다.
- 원문에 없는 결정을 만들지 않는다.

## 출력 형식
| 구분 | 내용 | 담당자 | 기한 | 비고 |

## 회의 메모
[붙여넣기]

4. 보고서 초안 템플릿

## 역할
너는 [분야] 보고서를 쓰는 실무 편집자다.

## 배경
보고서 독자: [독자]
보고서 목적: [목적]
핵심 메시지: [메시지]

## 작업
아래 자료를 바탕으로 보고서 초안을 작성하라.

## 출력 형식
- 제목
- 요약 3문장
- 본문 H2 [개수]개
- 결론 및 다음 단계

## 제약
원문에 없는 수치, 사례, 인용을 만들지 않는다.

## 자료
[붙여넣기]

5. 문서 리뷰 템플릿

## 작업
아래 문서를 검토하고 바로 수정하지 말고 문제 목록을 먼저 제시하라.

## 검토 기준
- 논리 흐름
- 중복 내용
- 용어 불일치
- 본문과 표의 수치 불일치
- 독자가 오해할 표현

## 출력 형식
| 위치 | 문제 유형 | 문제 설명 | 수정 제안 | 우선순위 |

## 문서
[붙여넣기]

6. 용어 통일 템플릿

## 작업
아래 문서에서 같은 의미로 쓰인 용어를 찾아 통일안을 제안하라.

## 규칙
- 원문을 바로 고치지 않는다.
- 용어 후보, 등장 표현, 추천 용어, 이유를 표로 정리한다.
- 의미가 다를 수 있는 용어는 "확인 필요"로 표시한다.

## 문서
[붙여넣기]

7. 분류 템플릿

## 작업
아래 입력을 라벨 중 하나로 분류하라.

## 라벨
- [라벨 A]: [정의]
- [라벨 B]: [정의]
- [라벨 C]: [정의]

## 예시
입력: [예시 입력]
출력: [라벨]
이유: [짧은 이유]

## 출력 형식
라벨: [허용 라벨 중 하나]
이유: [1문장]
확신도: [높음/중간/낮음]

## 입력
[붙여넣기]

8. 정보 추출 템플릿

## 작업
아래 텍스트에서 지정된 정보를 추출하라.

## 규칙
- 없는 정보는 null로 표시한다.
- 추측하지 않는다.
- 출력은 JSON 객체 하나만 반환한다.

## 스키마
{
  "name": "string 또는 null",
  "date": "YYYY-MM-DD 또는 null",
  "amount": "number 또는 null",
  "issue": "string 또는 null"
}

## 텍스트
[붙여넣기]

9. 비교 템플릿

## 작업
[대상 A]와 [대상 B]를 [판단 목적] 관점에서 비교하라.

## 비교 기준
- 비용
- 장점
- 위험
- 도입 난이도
- 추천 상황

## 출력 형식
1. 결론 먼저: [A/B/조건부]
2. 비교 표
3. 선택 기준
4. 추가 확인 질문

10. 의사결정 템플릿

## 역할
너는 의사결정 회의의 퍼실리테이터다.

## 작업
아래 상황에서 선택 가능한 옵션을 정리하고 추천안을 제시하라.

## 규칙
- 옵션은 최소 3개 제시한다.
- 각 옵션의 장점, 단점, 전제 조건을 분리한다.
- 정보가 부족하면 결론을 단정하지 말고 확인 질문을 제시한다.

## 상황
[붙여넣기]

11. 아이디어 발상 템플릿

## 작업
[목표]를 달성하기 위한 아이디어를 제안하라.

## 제약
- 예산: [예산]
- 기간: [기간]
- 인력: [인력]
- 피해야 할 방식: [금지]

## 출력 형식
| 아이디어 | 기대 효과 | 실행 난이도 | 첫 단계 | 리스크 |

12. 비판적 검토 템플릿

## 역할
너는 친절하지만 날카로운 검토자다.
목표는 비난이 아니라 실패 가능성을 줄이는 것이다.

## 작업
아래 계획의 약점, 빠진 전제, 검증할 가정을 찾아라.

## 출력 형식
1. 가장 큰 리스크 3개
2. 빠진 질문
3. 당장 검증할 실험
4. 유지해도 좋은 강점

## 계획
[붙여넣기]

13. 학습 설명 템플릿

## 작업
[개념]을 [독자 수준]에게 설명하라.

## 설명 방식
- 먼저 쉬운 비유를 든다.
- 그다음 정확한 정의를 제시한다.
- 마지막에 실무 예시를 1개 든다.
- 전문 용어는 처음 등장할 때 풀이한다.

## 분량
[분량]

14. 이메일 작성 템플릿

## 작업
아래 상황에 맞는 이메일 초안을 작성하라.

## 상황
보내는 사람: [나]
받는 사람: [상대]
목적: [목적]
상대가 알아야 할 배경: [배경]
원하는 행동: [행동]

## 문체
정중하지만 장황하지 않게 쓴다.

## 출력
제목 3개와 본문 1개를 작성한다.

15. 고객 응대 템플릿

## 역할
너는 고객지원 담당자다.

## 작업
아래 고객 문의에 답변하라.

## 규칙
- 먼저 불편에 공감한다.
- 가능한 조치를 구체적으로 안내한다.
- 정책상 불가능한 것은 우회적으로 숨기지 말고 명확히 설명한다.
- 확인이 필요한 정보는 마지막에 질문한다.

## 고객 문의
[붙여넣기]

16. 리서치 질문 분해 템플릿

## 작업
아래 리서치 주제를 조사 가능한 질문으로 분해하라.

## 출력 형식
| 하위 질문 | 필요한 자료 | 확인 방법 | 우선순위 |

## 규칙
- 현재 정보만으로 답을 만들지 않는다.
- 사실 확인이 필요한 항목과 해석이 필요한 항목을 구분한다.

## 주제
[붙여넣기]

17. 체크리스트 생성 템플릿

## 작업
[업무]를 수행하기 위한 체크리스트를 작성하라.

## 기준
- 실행 전, 실행 중, 실행 후로 나눈다.
- 각 항목은 확인 가능한 행동으로 쓴다.
- 추상적인 조언은 제외한다.

## 출력 형식
| 단계 | 체크 항목 | 확인 방법 | 담당자 |

18. 프롬프트 개선 템플릿

## 작업
아래 프롬프트를 더 안정적인 프롬프트로 개선하라.

## 개선 기준
- 목표가 명확한가
- 맥락이 충분한가
- 제약 조건이 측정 가능한가
- 출력 형식이 구체적인가
- 누락 정보 처리 규칙이 있는가

## 출력
1. 개선된 프롬프트
2. 무엇을 왜 바꿨는지 설명

## 기존 프롬프트
[붙여넣기]

19. 자기 점검 템플릿

## 작업
아래 답변을 제출 전 점검하라.

## 점검 기준
- 지시한 출력 형식을 지켰는가
- 원문에 없는 내용을 추가했는가
- 누락된 항목이 있는가
- 모호한 표현이 있는가
- 독자가 바로 실행할 수 있는가

## 출력 형식
| 점검 항목 | 결과 | 수정 제안 |

## 답변
[붙여넣기]

20. 작업 분할 템플릿

## 작업
아래 복잡한 요청을 Claude에게 맡길 수 있는 작은 단계로 나누어라.

## 규칙
- 한 단계에는 하나의 목표만 둔다.
- 각 단계의 입력과 출력을 명시한다.
- 사람이 검토해야 할 지점을 표시한다.

## 요청
[붙여넣기]

이 템플릿들은 정답이 아니다. 시작점이다. 중요한 것은 템플릿을 그대로 외우는 것이 아니라, 그 안에 들어 있는 구조를 익히는 것이다. 목표를 먼저 쓰고, 맥락을 분리하고, 제약을 명확히 하고, 출력 형식을 계약처럼 쓰는 습관이 생기면 어떤 업무에도 응용할 수 있다.

프롬프트도 초안에서 시작한다

좋은 프롬프트는 한 번에 완성되지 않는다. 첫 답변이 기대와 다를 때 "Claude가 못하네"라고 끝내기보다, 어느 조건이 빠졌는지 찾아야 한다. 프롬프트 개선은 대개 네 단계로 진행된다.

첫째, 기대한 결과와 실제 결과의 차이를 적는다. "별로다"가 아니라 "표는 좋지만 누락 정보 처리 규칙이 없다", "문체가 너무 가볍다", "근거 없이 추천했다"처럼 구체적으로 써야 한다.

둘째, 그 차이가 프롬프트로 통제 가능한지 판단한다. 문체, 분량, 형식, 누락 처리 규칙은 프롬프트로 고칠 수 있다. 최신 사실 부족, 내부 데이터 부재, 법적 판단은 추가 자료나 검토 절차가 필요하다.

셋째, 조건을 추가한다. "더 전문적으로"가 아니라 "주장마다 근거를 붙이고, 검증되지 않은 최상급 표현을 쓰지 말라"처럼 바꾼다.

넷째, 반복되는 작업이면 예시를 넣는다. 원하는 답과 원하지 않는 답을 함께 저장해 두면 다음부터 훨씬 빨라진다.

프롬프트 디버깅에는 다음 표를 사용할 수 있다.

프롬프트를 개선할 때 가장 좋은 질문은 "Claude가 왜 이렇게 답했을까?"가 아니다. 더 실용적인 질문은 "내가 어떤 판단 기준을 말하지 않았을까?"다. 대부분의 실패는 Claude의 능력 부족이 아니라 브리핑의 빈칸에서 시작된다.

기본기는 결국 업무 언어의 정리다

프롬프트 엔지니어링의 기본기는 복잡하지 않다. 하지만 꾸준히 지키기는 어렵다. 급할수록 우리는 "빨리 요약해 줘", "알아서 정리해 줘", "좋게 고쳐 줘"라고 말한다. 그 결과 다시 고치느라 시간을 쓴다.

Claude를 잘 쓰는 사람은 더 많은 요령을 아는 사람이 아니다. 일을 더 분명하게 설명하는 사람이다. 원하는 결과를 먼저 정의하고, 필요한 맥락을 주고, 예시로 기준을 보여 주고, 출력 형식을 계약처럼 정한다. 그리고 프롬프트로 해결할 수 없는 문제는 데이터, 도구, 평가, 사람의 검토로 넘긴다.

다음과 같은 한 문장으로 기본기를 요약할 수 있다.

Claude에게 일을 맡길 때는 목표, 맥락, 기준, 자료, 형식을 분리해서 준다.

이 원칙을 익히면 이후의 고급 프롬프팅도 훨씬 쉬워진다. 프롬프트 체이닝, 긴 문맥 압축, 구조화 출력, 도구 사용, 평가 자동화는 모두 이 기본 위에 올라간다. 기본이 흐리면 고급 기법은 복잡한 우회로가 되고, 기본이 단단하면 고급 기법은 자연스러운 확장이 된다.

참고

¹Prompt engineering overview - Claude API Docs

²Prompting best practices - Claude API Docs

³Use XML tags to structure your prompts - Claude Documentation

⁴Formatting output and speaking for Claude - Anthropic courses