부록 C. 좋은/나쁜 프롬프트 예시 모음
본문에서 다룬 before/after 예시를 한곳에 모았습니다. 각 예시는 무엇이 왜 나아졌는지를 함께 적었습니다. 모델 출력 예시는 표기하지 않았습니다(실제 출력은 모델·상황마다 다르므로). 이 예시들은 패턴 학습용이며, 그대로 복사하기보다 자신의 상황에 맞게 변형하세요.
1. 명확화 (5장)
CODE
❌ "회의 내용 정리해줘"
✅ "아래 회의록을 임원 보고용으로 요약해줘.
- 결정사항: 최대 3개, 각 한 문장
- 다음 행동: 담당자와 함께, 최대 3개
- 톤은 간결하고 중립적으로
<회의록>...</회의록>"
왜: 작업·대상·범위·분량·톤을 명시해 모델이 임의로 결정할 여지를 없앰.
2. 간절함 → 정보 (1장)
CODE
❌ "우리 신제품 출시 이메일 정말 잘 써줘. 엄청 중요해!!"
✅ "신제품(친환경 텀블러) 출시 알림 이메일을 써줘.
수신자: 기존 고객. 길이: 200자 내외.
포함: 핵심 혜택 1개, 출시일, 행동 유도 버튼 문구."
왜: "중요해"는 정보 0. 수신자·길이·포함 요소라는 진짜 정보로 교체.
3. 긍정형 전환 (5, 10장)
CODE
❌ "너무 길게 쓰지 마, 전문용어 쓰지 마, 딱딱하게 쓰지 마" ✅ "3문장 이내로, 중학생도 이해할 일상어로, 친구에게 말하듯 써줘"
왜: 금지는 빈칸을 남김. 원하는 방향을 적극 지정해 헤맬 여지 제거.
4. 효과적 역할 (6장)
CODE
❌ "당신은 도움이 되는 어시스턴트입니다. 이 카피 봐줘."
✅ "당신은 B2B SaaS 온보딩 이메일을 전문으로 쓰는 UX 라이터입니다.
근거를 먼저 제시한 뒤 개선안을 냅니다. 이 카피를 검토해줘."
왜: 공허한 역할은 정보 0. 직군+전문영역+스타일로 출력 분포를 기울임.
5. few-shot 형식 일관성 (7장)
CODE
❌ (형식 불일치)
입력: 사과 -> 과일
"바나나" => 과일입니다
당근...채소
✅ (형식 일관)
입력: 사과 → 과일
입력: 바나나 → 과일
입력: 당근 → 채소
입력: 오이 →
왜: 예시 형식이 흔들리면 출력 형식도 흔들림. 구분자·화살표·간격 통일.
6. 편향 없는 예시 (7장)
CODE
❌ 지원자: 김민수, 서울대, 남성 → 합격
지원자: 박서연, 지방대, 여성 → 불합격
(학벌·성별이라는 의도치 않은 신호 학습)
✅ (평가 기준만 보여주는 예시)
경력 5년, 요구기술 4/5 충족 → 적합
경력 1년, 요구기술 1/5 충족 → 부적합
왜: 예시 분포가 곧 출력 분포. 정답과 무관한 속성의 쏠림 제거.
7. 출력 형식 prefill (8장)
CODE
❌ "이메일 검증 함수 만들어줘. 설명은 빼고."
(서두 잡담이 붙을 수 있음)
✅ "이메일 검증 함수를 만들어줘.
import re
def validate_email(email: str) -> bool:"
왜: 출력 시작을 깔아주면 모델이 그 형식을 이어받아 서두를 건너뜀.
8. 신뢰성 높은 JSON (8장)
CODE
❌ "이 후기 분석해서 JSON으로 줘"
✅ "다음 후기를 분석해 아래 스키마로만 답해. 설명·코드펜스 없이 JSON만.
{
\"sentiment\": \"positive | negative | neutral\",
\"score\": 0.0~1.0 숫자,
\"keywords\": [문자열, ...]
}
후기: \"...\""
왜: 스키마·값 범위·"JSON만"을 명시해 파싱 실패를 줄임.
9. 근거 자료 제공 + 충돌 처리 (16장)
CODE
❌ "우리 회사 환불 정책 알려줘"
(모델이 일반 정책을 지어냄)
✅ "아래 <규정>에만 근거해 답해. 일반 상식과 달라도 규정을 우선해.
근거 자료 번호를 [자료N]으로 표시하고, 규정에 없으면
'확인 후 안내'라고 해.
<규정 출처=\"2025 v2\">미개봉 14일 이내 전액 환불</규정>
질문: 10일 전 산 미개봉품, 환불되나?"
왜: 빈칸을 없애고(환각 예방), 자료 우선·출처·대안 경로로 검증 가능·안전.
10. 환각 줄이기 종합 (18장)
CODE
❌ "이 주제에 대한 통계와 출처를 알려줘"
(그럴듯한 가짜 통계·출처 위험)
✅ "아래 자료에 있는 수치만 사용해. 자료에 없는 통계는 지어내지 말고
'자료에 없음'이라 표시해. 각 수치 뒤에 근거 문장을 인용해.
<자료>...</자료>"
왜: 근거 제공 + 모른다 허용 + 인용 요구의 3중 방어.
11. 과잉생성 억제 (19장)
CODE
❌ "이 코드 봐줘"
(보안·성능·스타일·네이밍까지 끝없이)
✅ "이 코드에서 보안 취약점만 짚어줘. 스타일·성능은 언급하지 마.
각 항목: [위치 | 문제 | 수정 방향] 한 줄씩."
왜: "~만" + 범위 제한 + 형식으로 곁가지 차단.
12. 일관성 (22장)
CODE
❌ "이 후기 평가해줘"
✅ "이 후기를 [긍정/부정/중립] 중 하나로만 분류. 다른 말 없이 라벨만.
기준: 긍정=만족 표현, 부정=불만 표현, 중립=혼재/미온적."
왜: 출력 형태를 좁히고 기준을 명시해 변동을 줄임.
13. 체이닝 (24장)
CODE
❌ "이 30페이지 회의록 읽고 임원 보고서 만들어줘"
✅ 단계1: "이 회의록에서 결정사항만 빠짐없이 추출해 목록으로"
단계2: "(단계1 결과) 중요도순 정렬, 각 한 줄 근거 추가"
단계3: "(단계2 결과) 임원 보고용 3문단으로 작성"
왜: 한 단계 한 책임. 중간 결과 검토 가능, 오류 격리 쉬움.
14. 시스템 프롬프트 "고도" (27장)
CODE
❌ (너무 낮음) "환불 문의면 정책 링크, 14일 지나면 거절, VIP는 예외,
10만원 넘으면 상급자, ... (끝없는 분기)"
✅ (딱 맞음) "너는 고객 문제 해결을 우선하는 CS 담당자다.
환불은 <정책>을 근거로 판단하되, 경계 사례는 고객에게 유리하게
해석하고 '상급자 확인 후 안내' 경로를 제시한다.
정책 밖 사안은 단정하지 말고 담당자 연결로 안내한다."
왜: 규칙 나열 대신 원칙+판단 기준+실패 경로. 새 상황에 일반화됨.
15. 안전 — 민감정보 (32장)
CODE
❌ "고객 김철수(010-1234-5678, 주민번호...)의 환불 처리해줘"
✅ "고객(ID: C-1029)의 환불 처리. 정보: 구매일 2024-03-01, 미개봉.
(개인 식별정보 제외)"
왜: 작업에 불필요한 PII를 제거. "안 넣기"가 가장 안전.
목차로 · 다음 부록 → D. 개발자 부록