당신은 클로드 프롬프트를 잘못 쓰고 있다. 클로드 개발자에게 배우는 프롬프트 제대로 쓰는 법.

클로드가 엉뚱한 답을 내놓으면 모델 탓부터 하기 쉽다. 하지만 많은 실패는 프롬프트가 일을 정의하지 않은 데서 시작한다. “전문적으로 써줘”, “깊게 분석해줘”, “최대한 잘 만들어줘”는 기대를 표현할 뿐, 무엇을 완료로 볼지 알려주지 않는다.

Anthropic의 공식 문서는 클로드를 배경지식 없는 유능한 신입 직원처럼 대하라고 설명한다. 원하는 결과를 동료가 처음 읽어도 실행할 수 있을 만큼 명확히 써야 한다는 뜻이다. 좋은 프롬프트는 화려한 문장이 아니라 작업 명세서에 가깝다.

당신은 질문을 썼지만, 일을 정의하지 않았다

“이 보고서를 분석해줘”에는 독자, 목적, 중요 지표, 근거 범위, 분량과 형식이 없다. 클로드는 빈칸을 추측해야 한다. 답이 장황하거나, 핵심 수치를 놓치거나, 원하지 않은 형식으로 나오는 것은 자연스러운 결과다.

Anthropic 공식 가이드에서 뽑은 10가지 작성법

1. “잘해줘” 대신 완료 조건을 써라

원하는 독자, 결과물, 길이, 반드시 포함할 항목과 제외할 항목을 명시한다. 순서가 중요하면 번호를 붙인다. “요약해줘”보다 “경영진이 2분 안에 읽을 수 있는 5개 항목으로, 매출 영향과 위험을 분리해 요약해라”가 낫다.

2. 지시 뒤의 이유를 알려줘라

형식만 강요하기보다 왜 필요한지 한 문장으로 설명하면 모델이 예외 상황에도 의도를 유지하기 쉽다. “문장을 짧게 써라”에서 끝내지 말고 “모바일 화면에서 빠르게 읽어야 하므로 문장을 짧게 써라”라고 적는다.

3. 예시는 3~5개, 비슷하지만 다양하게 줘라

Anthropic은 예시를 출력 형식과 말투를 통제하는 가장 안정적인 방법 중 하나로 본다. 실제 작업과 가까운 예시, 경계 사례를 포함한 다양한 예시, 구조가 분명한 예시가 좋다. 예시 하나만 주면 우연한 특징까지 규칙으로 배울 수 있다.

4. 복잡한 입력은 XML 태그로 경계를 나눠라

지시와 원문, 예시, 사용자 입력이 한 덩어리면 무엇을 따라야 하는지 모호해진다. <instructions>, <context>, <examples>, <input>처럼 의미가 보이는 이름을 일관되게 사용한다.

5. 역할은 직함이 아니라 판단 기준까지 써라

“너는 마케터다”보다 “너는 B2B SaaS 전환율을 개선하는 마케터다. 클릭보다 유효 리드와 매출 기여를 우선한다”가 강하다. 역할은 말투 장식이 아니라 무엇을 우선할지 정하는 시스템 지침이다.

6. 긴 문서는 앞에, 질문은 끝에 둬라

2만 토큰이 넘는 긴 문서나 여러 자료를 다룰 때 Anthropic은 자료를 프롬프트 위쪽에 놓고 질문과 지시를 뒤에 두라고 권한다. 공식 문서가 소개한 테스트에서는 복잡한 다중 문서 입력에서 질문을 끝에 둔 구성이 응답 품질을 최대 30% 높였다.

7. 원하는 형식을 긍정문과 예시로 보여줘라

“장황하게 쓰지 마”보다 “결론을 첫 문장에 쓰고 근거는 세 항목으로 제한해라”가 낫다. 최신 Claude는 지시를 문자 그대로 따르는 경향이 강하므로, 모든 섹션에 적용할 규칙이라면 적용 범위도 명시해야 한다.

8. “생각해”를 반복하지 말고 effort를 맞춰라

최신 Claude API 모델은 adaptive thinking과 effort 설정으로 추론 깊이를 조절한다. 어려운 코딩·에이전트 작업이 얕게 끝난다면 주문을 덧붙이기 전에 effort를 높이는 것이 우선이다. 반대로 단순 작업에 과도한 검증 지시를 붙이면 비용과 지연만 늘 수 있다.

9. 도구를 언제, 왜 써야 하는지 적어라

검색이나 코드 도구가 있다고 자동으로 최적 사용이 보장되지는 않는다. 최신 정보가 필요하면 검색하라, 특정 파일을 언급하면 답하기 전에 열어라, 계산은 코드로 검증하라처럼 발동 조건을 적는다. 추측을 줄이려면 “읽지 않은 코드에 대해 단정하지 말라”는 조사 규칙도 효과적이다.

10. 마지막에 검증 기준을 붙여라

“완료 전에 숫자를 원문과 대조하고, 빠진 요구사항이 없는지 확인하라”처럼 검증 대상을 명시한다. 다만 최신 상위 모델은 자체 검증이 강하므로 모든 작업에 반복 검사를 강제하면 과잉 검증이 생길 수 있다. 실제 실패 유형을 보고 필요한 검사만 남겨야 한다.

나쁜 프롬프트는 이렇게 고친다

나쁜 예: “이 자료를 전문가처럼 분석해서 좋은 보고서로 써줘. 틀리면 안 되고 깊게 생각해.”

전문가의 분야가 없고, 독자와 결정 목적도 없으며, ‘좋은’과 ‘깊게’의 기준도 없다. 다음처럼 작업을 분해하면 결과가 달라진다.

<role>
너는 B2B SaaS의 수익성을 검토하는 전략 분석가다.
</role>

<context>
이 보고서는 다음 분기 예산 회의에서 CFO가 사용한다.
성장률보다 현금흐름과 고객 획득비용의 악화를 먼저 본다.
</context>

<instructions>
1. 원문에서 확인되는 사실과 해석을 분리한다.
2. 전분기 대비 변화를 계산한다.
3. 가장 큰 위험 3개와 대응책을 제시한다.
4. 자료에 없는 숫자는 추정하지 않는다.
</instructions>

<output_format>
결론 3문장 → 핵심 지표 표 → 위험과 대응책 → 확인이 필요한 정보
</output_format>

<source>
...원문 자료...
</source>

위 기준으로 CFO용 보고서를 작성하라.

복사해서 바로 쓰는 클로드 프롬프트 템플릿

<role>
[클로드가 맡을 전문 역할과 우선 판단 기준]
</role>

<goal>
[누가 무엇을 결정하기 위해 사용할 결과물인지]
</goal>

<context>
[필요한 배경과 제약]
</context>

<instructions>
1. [해야 할 일]
2. [근거 사용 규칙]
3. [제외하거나 질문할 조건]
</instructions>

<examples>
[원하는 입력과 출력 예시 3~5개]
</examples>

<output_format>
[순서, 표, 분량, 문체]
</output_format>

<verification>
[완료 전에 확인할 기준]
</verification>

<input>
[실제 자료]
</input>

모든 칸을 항상 채울 필요는 없다. 간단한 질문에 XML 태그 여덟 개를 붙이면 오히려 잡음이다. 모델이 잘못 추측할 가능성이 큰 결정만 명시하는 것이 핵심이다.

공식 가이드는 모델마다 다시 보라고 말한다

Claude는 세대가 바뀔수록 더 문자 그대로 지시를 따르고, 도구 사용과 자체 검증에 더 적극적으로 변한다. 예전 모델의 수동 확장 사고 설정이나 과도한 “끝까지 절대 멈추지 마라” 지침을 그대로 옮기면 최신 모델에서는 비용 증가, 범위 확장, 과잉 검증이 생길 수 있다.

그래서 공통 프롬프트 원칙과 모델별 설정을 분리해야 한다. 역할·목표·예시·형식은 공통 자산으로 관리하고, effort·thinking·도구 사용·진행 보고는 실제 사용하는 모델의 공식 페이지에서 조정하는 편이 안전하다.

프롬프트 엔지니어링의 결론은 더 많은 말이 아니다

좋은 프롬프트는 모델을 속이는 주문이 아니다. 누가 결과를 쓰고, 무엇을 결정하며, 어떤 자료를 근거로 삼고, 어떤 모양이면 완료인지 정의하는 일이다. 여기에 가까운 예시와 필요한 검증을 붙이면 출력은 훨씬 재현 가능해진다.

클로드가 계속 엉뚱하게 답한다면 “더 깊게 생각해”를 추가하기 전에 네 가지를 확인하라. 목표가 보이는가, 입력과 지시가 분리돼 있는가, 원하는 결과 예시가 있는가, 완료 기준이 측정 가능한가. 대부분의 프롬프트는 여기서 고쳐진다.

자주 묻는 질문