프롬프트 패턴 치트시트

프롬프트 쓸 때 가장 자주 여는 문서. 기법 → 언제 쓸지 표 + 2026 의 함정.

⚠️ 2026 의 가장 큰 변화: 추론(reasoning) 모델이 고전 규칙을 뒤집는다. 일반 모델을 돕던 기법(장황한 CoT, few-shot 스캐폴딩)이 추론 모델에서는 오히려 해가 된다. 자세히 → reasoning-vs-standard-models

기법 → 언제 손 뻗을지

기법	언제	모델 주의
Zero-shot	잘 정의된 작업, 기본값	항상 먼저 시도
Few-shot	포맷/스타일/엣지케이스를 보여줘야 할 때	일반모델엔 도움, 추론모델엔 해로움 → 포맷 용도로만
Chain-of-Thought	어려운 추론 (일반모델)	추론모델엔 불필요~역효과 — effort 노브 쓰기
Role/System 프롬프트	관점·제약·출력계약 설정	항상
구조화 출력	프로그램이 소비하는 모든 것	JSON-Schema(OpenAI/Gemini/Claude) — Claude 도 네이티브 지원(`output_config.format`, verified 2026-07), XML 태그도 유효 → structured-output
프롬프트 체이닝	복잡한 작업을 테스트가능 단계로 분해	사소한 작업엔 지연·비용만 늘림
ReAct	툴 쓰는 에이전트	네이티브 function-calling 플러밍 사용
Self-consistency	고가치·정답 하나인 작업 (수학·추출)	N배 비용, 추론모델엔 대체로 불필요
프롬프트 캐싱	반복되는 안정적 프리픽스	stable-first, variable-last → prompt-caching

핵심 패턴 스니펫

Few-shot (포맷을 보여주기)

감정을 positive/negative/neutral 로 분류.

"또 살래요, 최고." → positive
"박스가 찌그러져 왔어요." → negative
"폰이네요. 작동은 함." → neutral
"배송은 늦었지만 지원팀이 빨리 고쳐줌." →

⚠️ few-shot 오염: 지시를 바꿨는데 예시가 옛것이면 조용히 틀린 출력이 나온다 — 프로덕션 실패의 1위 원인. 지시 바꿀 때마다 예시 감사.

CoT — 내부 추론 + 고정 포맷 출력 (파싱 오염 방지)

문제를 <scratchpad> 안에서 단계별로 생각해.
그 다음 최종 답만 <answer> 안에 숫자 하나로.

<scratchpad>...추론...</scratchpad>
<answer>9</answer>

구조화 출력 (JSON Schema, OpenAI/Gemini)

{
  "type": "json_schema",
  "json_schema": {
    "name": "extraction", "strict": true,
    "schema": {
      "type": "object",
      "properties": {
        "company":    { "type": "string" },
        "amount_usd": { "type": ["number", "null"] },
        "confidence": { "type": "string", "enum": ["high","medium","low"] }
      },
      "required": ["company", "amount_usd", "confidence"],
      "additionalProperties": false
    }
  }
}

철칙: 모든 필드를 required-or-nullable 로 하고 "unknown"/null 탈출구를 줘라. 안 그러면 스키마를 만족시키려고 값을 지어낸다(hallucinate).

구조화 출력 (XML 태그, Claude 선호)

<document>{{계약서_원문}}</document>
<instructions>
모든 지급 의무를 추출. 항목마다 <obligation> 블록 하나씩,
<party> <amount> <due_date> 포함. 없는 필드는 "not stated".
</instructions>

프로그램이 파싱하는 출력이면 Claude 도 이제 네이티브 구조화 출력(output_config: {format: {type:"json_schema", schema}}, verified 2026-07)이 우선이다 — XML 태그는 산문 응답 안에서 출력을 유도할 때 여전히 유용. 상세 → structured-output

안티패턴 (자주 밟는 지뢰)

안티패턴	뭐가 문제	고치기
지시 쌓기	규칙 추가할수록 앞 규칙에 대한 주의가 단조 감소	지시셋 작게, 규칙은 예시/체이닝으로
few-shot 오염	옛 예시가 현재 지시와 모순 → 조용한 오답	지시 바꿀 때마다 예시 재감사
페르소나 채우기	"천재 10x 록스타" 는 노이즈만 추가	기능적 역할 + 구체적 제약만
부정문 위주	"X 하지 마"는 약함, 모델이 X 로 흐름	할 것을 말하라: "3문장 이하로"
lost-in-the-middle	긴 컨텍스트 중간에 묻힌 지시는 무시됨	핵심 지시는 시작과 끝에
추론모델에 CoT	o-series/thinking 에 "단계별로" 는 역효과	작업+제약+출력포맷만, effort 노브로
조용한 퇴화	데모는 완벽, 프로덕션에서 몇 달 서서히 정확도 하락	eval 스위트 + 캐시히트 모니터링

각 안티패턴의 전체 설명·재현·회피 → anti-patterns

두 개의 절대 방어 (2026 컨센서스)

실패 모드에 이름을 붙여라 — 무엇이 잘못될지 명명.
모든 프롬프트를 eval 스위트로 뒷받침하라 — eval 없는 프롬프트는 눈에 안 보이게 썩는다.

참고

추론모델 vs 일반모델 상세 → reasoning-vs-standard-models
구조화 출력 상세(JSON Schema·output_config.format·전략) → structured-output
안티패턴 전체 목록 → anti-patterns
캐싱 규칙 → prompt-caching
ReAct·에이전트 패턴 → agent-design-patterns
개념(토큰·컨텍스트) → glossary