#프롬프트는 도대체 어떻게 쓰나 — Zero-shot / Few-shot / CoT

← 전체 목차 · 이전: 접두사 캐시와 시맨틱 캐시의 차이 · 다음: 프롬프트가 너무 길면 무슨 함정이 있나

프롬프트를 잘 설명하지 못하는 근본 원인은 표준 패러다임의 부재다. 프롬프트 기법은 하나의 점진적 사슬로 수렴한다:

Zero-shot(제로샷) → Few-shot(퓨샷) → Chain-of-Thought(사고 사슬, CoT)

#Zero-shot(제로샷 프롬프트): 대규모 모델을 검색 엔진처럼 쓰기

• 전형적인 인식: 대규모 모델 ≈ 검색 엔진, "떠오르는 질문을 그대로 던지면 된다".
• 비유: 복습을 전혀 하지 않은 학생이 그대로 시험장에 들어가는 것. 평소 쌓아둔 밑천만으로 버틴다.
• 적용 범위: 간단한 번역, 기초 문답 — 맨몸 시험으로도 문제없다.
• 실패 구간:

실패 경로: 문제만 던짐 → 머리가 달아오름 → 틀린 답.

#Few-shot(퓨샷 프롬프트): 서너 개의 고품질 문답 쌍

• 방법: 모델에게 3~5개의 고품질 문답 쌍을 주어 "감을 잡게" 한다.
• 얻을 수 있는 것: 당신의 답변 형식과 특정 스타일을 빠르게 학습한다(문형을 배운다).
• 얻을 수 없는 것: 논리 사슬이 너무 길면 계산이 틀리거나 막다른 길에 빠진다.

실패 경로: 참고 예시 Q&A(문형 학습) + 새 문제 → 모델 → 건너뛰며 찍기.

#Chain-of-Thought(사고 사슬, CoT): 판을 바꾸는 한 수

Few-shot과의 유일한 차이: 예시를 줄 때 최종 답만 주지 않고 중간 풀이 단계를 한 겹씩 명확히 적는다.

#동일 문제 대조 실험: 철수의 사과 문제

문제: 철수에게 사과가 5개 있다. 2개를 먹었고, 남은 개수의 3배를 다시 사 왔다. 지금 모두 몇 개인가?

CoT의 시범 단계:

#CoT가 작동하는 메커니즘: 선형 동작으로 쪼개 블랙박스를 깬다

엉킨 실타래 → 선형 동작 1 / 선형 동작 2 / 선형 동작 3

모델이 최종 결과를 서둘러 찍지 않고 사람처럼 단계를 밟게 된다. 강제로 스스로 계단을 놓게 만들어 "한 걸음 틀리면 계속 틀리는" 국면을 되살린다.

#선택과 승급 절차

[프롬프트를 한 줄 쓴다]
     │
     ▼
① 논리 사슬의 길이를 판단
     ├── 짧음(번역 / 분류 / 추출 / 기초 문답)
     │        └──> Zero-shot: 작업을 직접 서술하면 충분, 불필요한 예시를 넣지 말 것
     │
     ├── 출력 형식/스타일에 강한 요구가 있음
     │        └──> Few-shot: 3~5개의 고품질 문답 쌍
     │                 · 예시는 경계 상황을 커버할 것
     │                 · 예시의 형식은 기대 출력과 완전히 일치해야 함
     │
     └── 김(수학 / 다단계 추론 / 계획 / 복잡한 업무 판단)
              └──> Chain-of-Thought
                       · 예시에 완전한 중간 단계를 쓰고, 최종값만 쓰지 말 것
                       · 각 단계는 하나의 원자 동작만
                       · 모델이 단계를 먼저 출력하고 마지막에 결론을 내게 할 것
     │
     ▼
② 검증: 같은 유형의 새 문제로 바꿔서, 모델이 "단계를 따라가는지" 아니면 "곧바로 답을 뱉는지" 확인
     ├── 곧바로 답을 뱉음 → 시범 입도가 아직 부족, 계속 단계를 쪼갤 것
     └── 단계를 따라감   → 패러다임이 발효됨
     │
     ▼
③ 오류 위치 파악: CoT 출력은 단계별 검증이 가능 → 몇 번째 단계에서 틀렸는지 한눈에 → 표적으로 예시 보완

#세 패러다임 속견표

#핵심 통찰

1. 프롬프트의 핵심 변수는 "어휘 선택"이 아니라 "시범 입도"다 — 세 패러다임의 진짜 차이는 하나뿐이다. 모델에게 추론 사슬을 얼마나 보여주었는가. 예시 0개 / 답만 있는 예시 N개 / 중간 단계가 있는 예시 N개는 본질적으로 시범 입도가 거친 것에서 세밀한 것으로 가는 축이다.
2. Few-shot이 가르치는 것은 형식이지 능력이 아니다 — 출력 형식과 어조를 매우 빠르게 정렬시키지만 "계산이 맞는가"에는 거의 기여하지 않는다. Few-shot을 추론 강화 수단으로 여기는 것은 흔한 오용이며, 그것은 형식 정렬 도구다.
3. 적용 시나리오보다 실패 모드를 기억하는 편이 값지다 — Zero-shot의 실패 모드는 "그럴듯해 보이는 환각", Few-shot의 실패 모드는 "형식은 맞는데 건너뛰며 찍기"다. 실패 모드를 설명할 수 있는 편이 정의를 복창하는 것보다 훨씬 설득력이 있다.
4. CoT의 가치는 블랙박스를 감사 가능한 중간 상태로 바꾸는 데 있다 — 모델이 5-2=3, 3×3=9, 3+9=12를 적어내는 순간 답만이 아니라 단계별로 검증할 수 있고 몇 번째 단계에서 틀렸는지 특정할 수 있는 증거 사슬을 얻는다. 엔지니어링(자동 교정, 단계 단위 평가)에서 답 자체보다 훨씬 중요하다.
5. "한 걸음 틀리면 계속 틀린다"는 쪼개서 되살릴 수 있다 — 긴 논리 사슬의 실패는 모델의 능력 부족이 아니라 최종값을 한 번에 출력하도록 강요받은 결과다. 긴 사슬을 선형 동작으로 잘라 각 단계가 하나만 하게 하면 오류율이 크게 떨어진다.
6. 선택은 논리 사슬의 길이를 보지 작업이 "어려워 보이는지"를 보지 않는다 — 판정 기준은 소박하다. 사슬이 짧으면(번역, 분류, 추출) Zero-shot, 형식·스타일을 고정해야 하면 Few-shot, 사슬이 길면(수학, 다단계 추론, 계획) CoT.
7. 세 패러다임은 배타적이지 않고 중첩된다 — 프로덕션에서 흔한 것은 Few-shot + CoT다. 형식 템플릿을 주면서 각 예시에 완전한 추론 단계를 담아 "형식 정렬"과 "추론 정확성"을 동시에 해결한다.
8. 이 문제에 답할 때는 "패러다임 감각"이 필요하다 — 묻는 것은 CoT를 아는지가 아니라 복창 가능한 승급 경로가 있는가이다. "제로샷 → 퓨샷 → 사고 사슬, 각각 무엇을 해결하고 각각 어디서 실패하는가"로 답하면 그 자체로 체계가 된다.

#엔지니어링 실전 Tips

• Few-shot 예시는 3~5개면 충분하다: 관건은 "고품질"이지 "많음"이 아니다.
• 예시의 형식이 곧 계약이다: 모델은 예시의 형식을 구두점, 줄바꿈, 필드 순서까지 엄격히 모방하므로 예시 형식이 파서의 기대와 완전히 일치해야 한다.
• CoT 예시의 각 단계는 원자 동작이어야 한다(5-2=3이지 5-2를 다시 3배가 아니다): 단계 입도가 세밀할수록 모델이 건너뛸 확률이 낮아진다.
• "먼저 추론, 나중에 결론"의 출력 순서를 강제할 것: 모델이 답을 먼저 주고 이유를 보태게 하면, 이유는 이미 낸 답에 대한 사후 합리화로 퇴화해 교정 가치를 잃는다.
• CoT로 단계 단위 평가를 할 것: 중간 단계를 따로 채점할 수 있어 "2단계 곱셈 오류"까지 특정할 수 있고, 최종값만 보는 pass/fail보다 훨씬 유용하다.
• 비용 취사선택에 주의할 것: CoT는 출력 Token을 뚜렷이 늘린다. 간단한 작업에 CoT를 남용하는 것은 순수한 낭비다.
• 동일 문제 대조가 가장 빠른 디버깅법이다: 같은 문제를 세 패러다임으로 각각 한 번씩 돌리면 병목이 형식에 있는지 추론에 있는지 즉시 드러난다.
• 더 파고들 방향: Zero-shot CoT("한 걸음씩 생각해 보자" 한 문장만 추가하는 저비용 변종), 자기 일관성 샘플링(Self-Consistency, 여러 CoT 경로를 샘플링해 투표), 단계 단위 평가와 자동 교정.