Claude를 안정적으로 쓰는 첫 번째 기준은 프롬프트를 “질문”이 아니라 작업 명세서로 작성하는 것입니다.
모델이 똑똑해질수록 대충 써도 어느 정도 답은 나옵니다. 하지만 실무에서는 “그럴듯한 답”보다 “반복 가능하고 검증 가능한 결과”가 중요합니다. 특히 API, 코딩 에이전트, 문서 요약, 리서치, 고객지원 자동화처럼 결과물이 실제 업무에 들어가는 경우에는 프롬프트가 곧 요구사항 문서가 됩니다.
분석 기준일: 2026-05-02
주요 참고자료: Anthropic Claude prompting best practices, Models overview, Extended thinking, Tool use 문서
시리즈: Claude 프롬프트 실무 가이드
이 글의 범위: 명확한 지시, 맥락 제공, 성공 기준, 예시 설계
핵심 요약
- Claude 프롬프트는 짧게 쓰는 것보다 오해할 여지를 줄이는 것이 중요합니다.
- 좋은 프롬프트는 작업 목적, 독자, 출력 형식, 성공 기준, 금지 행동을 함께 제공합니다.
- “알아서 잘 해줘”는 모델에게 추측을 맡기는 요청입니다. 실무 프롬프트는 추측을 줄이는 명세여야 합니다.
- 예시는 출력 형식과 판단 기준을 동시에 고정하는 가장 강력한 방법입니다.
- 복잡한 작업일수록 프롬프트 안에 “무엇을 하지 말아야 하는지”가 필요합니다.
1. 왜 프롬프트를 작업 명세서로 봐야 하나
Claude는 맥락을 잘 읽지만, 사용자의 조직, 코드베이스, 고객, 문서 규칙, 품질 기준을 자동으로 알지는 못합니다. 이 점이 핵심입니다.
예를 들어 다음 요청은 표면적으로는 간단합니다.
# 예시이 코드 개선해줘.하지만 실제로는 해석이 너무 많습니다.
| 해석 가능성 | Claude가 할 수 있는 일 | 문제 |
|---|---|---|
| 성능 개선 | 알고리즘이나 캐시를 바꿈 | 동작 변경 위험 |
| 가독성 개선 | 함수와 변수명을 바꿈 | 불필요한 diff 증가 |
| 안정성 개선 | 검증 로직을 추가함 | 기존 호출자가 깨질 수 있음 |
| 테스트 보강 | 테스트 파일을 추가함 | 사용자가 원한 범위가 아닐 수 있음 |
| 구조 개선 | 모듈을 나눔 | 과한 리팩터링 가능 |
“개선”이라는 단어는 사람 사이에서도 애매합니다. 모델에게도 마찬가지입니다. 좋은 프롬프트는 개선의 방향을 좁힙니다.
# 예시아래 TypeScript 함수의 런타임 오류 가능성을 줄여줘. 범위:- 함수 시그니처는 바꾸지 말 것- 외부 라이브러리는 추가하지 말 것- 기존 테스트가 깨지지 않게 할 것- 주변 코드 리팩터링은 하지 말 것 출력:1. 문제가 되는 지점 요약2. 수정된 코드3. 변경 이유4. 추가하면 좋은 테스트 케이스이 프롬프트는 훨씬 안정적입니다. 작업 목적, 제약, 출력 순서를 모두 제공합니다. Claude가 “어디까지 해도 되는지”를 추측하지 않아도 됩니다.
2. 명확한 지시의 최소 구성
실무 프롬프트는 보통 다섯 가지를 포함하면 품질이 안정됩니다.
| 구성 | 질문 | 예시 |
|---|---|---|
| 목표 | 무엇을 해야 하나 | “릴리스 노트를 개발 영향 중심으로 요약” |
| 맥락 | 결과물이 어디에 쓰이나 | “이번 주 스프린트 계획 회의용” |
| 형식 | 어떤 모양이어야 하나 | “표 1개, 리스크 3개, 액션 3개” |
| 기준 | 성공을 어떻게 판단하나 | “breaking change를 먼저 표시” |
| 경계 | 무엇은 하지 말아야 하나 | “문서에 없는 내용은 추정하지 않음” |
이 다섯 가지는 길게 쓸 필요가 없습니다. 중요한 것은 빠짐없이 쓰는 것입니다.
# 예시이 문서를 임원 보고용으로 요약하세요. 목표:- 전체 번역이 아니라 의사결정에 필요한 쟁점을 뽑는다. 맥락:- 독자는 기술 세부 구현보다 비용, 일정, 리스크에 관심이 있다. 출력:- 핵심 요약 5개- 의사결정 필요 항목 3개- 리스크와 대응책 표 경계:- 문서에 없는 수치나 일정을 만들지 않는다.- 추정은 “추정”이라고 표시한다.이 정도만 넣어도 결과물은 크게 달라집니다.
3. 맥락은 장식이 아니라 판단 기준이다
맥락은 모델을 친절하게 대하기 위한 설명이 아닙니다. 애매한 순간에 어떤 선택을 해야 하는지 알려주는 판단 기준입니다.
예를 들어 “짧게 답변해줘”라는 요청은 충분하지 않습니다. 짧아야 하는 이유가 없기 때문입니다.
# 예시이 답변은 모바일 앱의 도움말 툴팁에 들어갑니다.사용자가 5초 안에 읽어야 하므로 2문장 이내로 작성하세요.전문 용어는 피하고, 사용자가 다음 행동을 바로 알 수 있게 쓰세요.이 프롬프트는 “짧게”의 의미를 정합니다. 단순히 글자 수를 줄이는 것이 아니라 모바일 UI에 맞는 정보 밀도를 선택하게 만듭니다.
맥락은 특히 다음 작업에서 중요합니다.
| 작업 | 필요한 맥락 |
|---|---|
| 문서 요약 | 독자, 사용 목적, 생략 가능한 정보 |
| 코드 리뷰 | 배포 환경, 호환성, 테스트 기준 |
| 고객지원 | 제품 정책, 금지 표현, 에스컬레이션 조건 |
| 리서치 | 날짜 기준, 신뢰 가능한 출처, 판단 기준 |
| 프론트엔드 생성 | 사용자, 도메인, 브랜드 톤, 밀도 |
4. 성공 기준을 넣으면 결과가 검증 가능해진다
성공 기준이 없는 프롬프트는 결과를 평가하기 어렵습니다. 모델은 답을 냈지만, 그 답이 좋은지 나쁜지 판단할 기준이 없습니다.
<!-- 예시 --><task>아래 릴리스 노트를 개발팀 공유용으로 요약하세요.</task> <context>목적은 전체 내용을 완벽히 번역하는 것이 아니라,이번 주 스프린트에 영향을 줄 수 있는 변경사항을 빠르게 파악하는 것입니다.</context> <success_criteria>- breaking change를 먼저 보여줄 것- API 변경, 인증 변경, 비용 변경을 분리할 것- 확인이 필요한 항목은 "확인 필요"라고 표시할 것- 추정과 공식 사실을 섞지 말 것</success_criteria> <output_format>마크다운으로 작성하세요.섹션은 "핵심 요약", "개발 영향", "확인 필요", "추천 액션" 순서로 구성하세요.</output_format>이 구조는 팀에서 반복 사용하기 좋습니다. 같은 문서를 여러 사람이 요약하더라도 결과물의 기준이 비슷하게 유지됩니다.
5. 예시는 설명보다 강하다
Claude는 예시에 강합니다. 출력 형식, 톤, 판단 기준을 말로 설명하는 것도 필요하지만, 실제 예시를 주면 더 안정적으로 따라옵니다.
고객 문의 분류 작업을 예로 들면 다음과 같습니다.
<!-- 예시 --><instructions>다음 고객 문의를 분류하세요.분류는 bug, billing, feature_request, account, other 중 하나만 사용하세요.</instructions> <examples> <example> <input>결제했는데 영수증을 받을 수 없습니다.</input> <output>billing</output> </example> <example> <input>로그인하면 화면이 하얗게 멈춥니다.</input> <output>bug</output> </example> <example> <input>팀별 권한 관리 기능이 있으면 좋겠습니다.</input> <output>feature_request</output> </example></examples> <input>{{USER_MESSAGE}}</input>예시는 단순한 샘플이 아닙니다. 모델에게 “이런 판단을 이런 형식으로 하라”는 패턴을 전달합니다. 분류, 추출, 코드 리뷰, 정책 판정, 고객지원 응답처럼 일관성이 중요한 작업에서는 예시가 거의 필수입니다.
6. 예시를 넣을 때의 기준
좋은 예시는 세 가지 조건을 만족합니다.
| 조건 | 설명 |
|---|---|
| 관련성 | 실제 입력과 비슷해야 함 |
| 다양성 | 정상 케이스와 경계 케이스를 함께 포함 |
| 구조화 | 입력과 출력을 명확히 구분 |
나쁜 예시는 오히려 품질을 낮춥니다. 예를 들어 모든 예시가 너무 짧으면 Claude는 긴 입력에서도 짧은 답만 하려 할 수 있습니다. 모든 예시가 긍정 사례이면 거절하거나 에스컬레이션해야 하는 상황을 놓칠 수 있습니다.
실무에서는 3~5개 예시부터 시작하는 편이 좋습니다. 너무 적으면 패턴이 약하고, 너무 많으면 프롬프트가 비대해집니다.
7. “하지 말 것”도 명세의 일부다
AI 작업에서 사고는 대개 “무엇을 하라”보다 “어디까지 해도 되는지”가 모호할 때 생깁니다.
코딩 에이전트에게는 다음 경계가 필요합니다.
# 예시금지:- 요청 범위를 벗어난 리팩터링 금지- 테스트 삭제 또는 약화 금지- 비밀키, 토큰, 개인정보 출력 금지- 사용자 확인 없는 force push, reset, 배포 금지- 실패를 감추기 위한 하드코딩 금지문서 요약 작업에서도 경계는 필요합니다.
# 예시금지:- 문서에 없는 가격, 일정, 모델명을 추정하지 말 것- 공식 사실과 작성자의 해석을 한 문단에 섞지 말 것- 불확실한 내용을 확정적으로 쓰지 말 것좋은 경계는 모델을 답답하게 만드는 것이 아니라, 결과물을 업무에 넣을 수 있게 만듭니다.
8. 바로 쓰는 기본 템플릿
아래 템플릿은 대부분의 분석 작업에 바로 쓸 수 있습니다.
<!-- 예시 --><role>당신은 이 주제를 실무 관점에서 분석하는 시니어 컨설턴트입니다.</role> <context>이 분석은 {{AUDIENCE}}가 의사결정에 사용할 예정입니다.목적은 단순 요약이 아니라 실행 가능한 판단 기준을 만드는 것입니다.</context> <input>{{CONTENT}}</input> <task>입력 내용을 분석해서 핵심 쟁점, 실무 영향, 리스크, 추천 액션을 정리하세요.</task> <rules>- 확인된 사실과 해석을 분리하세요.- 불확실한 내용은 "확인 필요"라고 표시하세요.- 과장된 표현을 피하고 근거 수준에 맞게 말하세요.</rules> <output_format>## 핵심 요약## 확인된 사실## 실무 영향## 리스크## 추천 액션## 확인 필요</output_format>핵심은 태그 자체가 아닙니다. 목표, 맥락, 입력, 규칙, 출력 형식을 분리하는 것입니다. XML은 그 분리를 눈에 보이게 만드는 도구입니다.
마무리
Claude 프롬프트의 출발점은 마법 문장을 찾는 것이 아닙니다. 모델이 추측해야 하는 부분을 줄이고, 결과물을 평가할 기준을 넣는 것입니다.
다음 글에서는 복잡한 프롬프트에서 XML 태그와 출력 형식을 어떻게 써야 하는지 더 구체적으로 다룹니다. 지시문, 예시, 긴 문서, 변수 입력이 섞일 때 Claude가 덜 헷갈리게 만드는 구조가 핵심입니다.
참고자료
- Anthropic Claude Prompting Best Practices: https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/claude-prompting-best-practices
- Use XML tags to structure your prompts: https://docs.anthropic.com/en/docs/build-with-claude/prompt-engineering/use-xml-tags
- Models overview: https://platform.claude.com/docs/en/about-claude/models/overview
댓글
GitHub 계정으로 로그인하면 댓글을 남길 수 있습니다. 댓글은 GitHub Discussions를 통해 운영됩니다.