핵심 수치
- 1퓨샷의 일반적 범위: 예시 2~10개. 8개를 넘기면 효과가 대체로 평평해집니다
- 2출처: Brown 외 (2020), "Language Models are Few-Shot Learners" — 파라미터 1,750억 개의 GPT-3 논문
- 3GPT-3에서 보고된 향상: TriviaQA 기준 제로샷 64.3% → 퓨샷 71.2%
- 4토큰 비용: 약 120토큰짜리 예시 5개는 요청마다 약 600 입력 토큰을 더합니다
- 5프롬프트 캐싱: 고정된 퓨샷 블록은 Claude 프롬프트 캐싱으로 반복 입력 비용을 최대 90%까지 줄일 수 있습니다
- 6도입 기준: 테스트 50건에서 10%포인트 이상 향상될 때 퓨샷을 배포하세요
제로샷 프롬프팅이란
📍 In One Sentence
제로샷 프롬프팅은 문맥 내 시연 없이 과제 지시만 전달하며, 모델의 사전 학습과 지시 튜닝에 전적으로 의존합니다.
💬 In Plain Terms
제로샷은 무엇을 할지만 알려 주고 이미 방법을 안다고 믿는 방식입니다. 예제 없이 지시만 줍니다.
제로샷 프롬프팅은 프롬프트 안에 예시를 두지 않고, 명확한 지시만으로 모델이 과제를 해결하도록 요청하는 방식입니다. 모델은 사전 학습과 정렬 과정에서 얻은 일반 지식과 지시 수행 능력에 의존합니다.
예시 쌍을 설계하거나 관리할 필요가 없어 도입이 빠릅니다. 일반 질의응답, 단순 분류, 요약, 평이한 번역처럼 지시만으로 충분한 넓은 과제에 잘 맞습니다.
퓨샷 프롬프팅이란
📍 In One Sentence
퓨샷 프롬프팅은 지시 앞에 소수의 입력·출력 시연을 배치해, 가중치 갱신 없이 모델이 문맥 안에서 패턴을 추론하도록 합니다.
💬 In Plain Terms
퓨샷은 네 번째를 부탁하기 전에 완성된 예시 세 개를 보여 주는 방식입니다. 모델은 눈에 보이는 패턴을 그대로 따라 합니다.
퓨샷 프롬프팅은 지시에 소수의 입력·출력 예시를 덧붙여, 모델이 구체적인 시연에서 과제 패턴을 추론하게 하는 방식입니다. 실무에서는 보통 2~10개를 뜻합니다.
이 예시들은 프롬프트 안의 작은 학습 세트처럼 작동하며, 모호한 과제나 특수한 형식, 도메인 용어를 어떻게 해석할지 안내합니다. 일반적인 지시로는 담기 어려운 스타일·스키마·미묘한 동작이 필요할 때 특히 유용합니다.
학습은 전혀 일어나지 않습니다. 예시는 한 번의 호출 동안만 컨텍스트 윈도에 존재하고 이후 폐기됩니다. 파인튜닝이 아니라 인컨텍스트 러닝이라고 부르는 이유입니다.
핵심 차이: 제로샷 vs 퓨샷
두 방식의 차이는 주로 준비 부담, 특정 과제에서의 정확도, 여러 사용 사례로의 확장성에 있습니다. 같은 모델을 쓰면서 예시 설계 비용과 과제 적합도를 맞바꾸는 구조입니다.
항목 | 제로샷 | 퓨샷 |
|---|---|---|
| 프롬프트 내 예시 | 없음 | 대표 예시 2~10개 이상 |
| 도입 속도 | 매우 빠름. 예시 선별 불필요 | 느림. 예시를 고르고 관리해야 함 |
| 데이터 요건 | 라벨 데이터 불필요 | 최소한의 라벨 예시 필요 |
| 좁은 과제 정확도 | 대체로 낮거나 일반적인 답에 그침 | 특정 도메인에서 대체로 더 높고 일관적 |
| 출력 형식 통제 | 형식을 얼마나 정확히 서술하느냐에 달림 | 강함. 예시 자체가 형식 명세가 됨 |
| 호출당 입력 토큰 | 지시만 | 지시와 모든 예시를 매 호출마다 전송 |
| 과제 확장성 | 높음. 새 과제 추가가 쉬움 | 낮음. 과제마다 별도 예시가 필요할 수 있음 |
제로샷을 쓸 때
속도가 필요하고, 라벨이 붙은 예시가 없으며, 과제가 비교적 일반적일 때 제로샷 프롬프팅을 쓰세요. 첫 시도나 기준선으로 적합합니다.
대표적인 제로샷 상황:
- 일반 질의응답, 간단한 요약, 기본적인 감성 분류.
- 과제의 형태를 아직 탐색하는 단계의 빠른 실험.
- 정제된 예시가 없는 새로운 도메인이나 언어.
- 입력 토큰 하나가 수백만 호출에 걸쳐 배가되는 대량·비용 민감형 파이프라인.
퓨샷을 쓸 때
과제가 전문적이거나 형식에 민감하거나 위험도가 높고, 좋은 예시를 제공할 수 있을 때 퓨샷 프롬프팅을 쓰세요. 이런 경우 예시는 지시만 쓸 때보다 신뢰도를 크게 높입니다.
흔한 퓨샷 상황:
- 라벨과 표현의 정확성이 중요한 도메인 특화 분류·추출(법률, 의료, 금융).
- 지저분한 텍스트에서 구조화된 JSON을 뽑는 등 엄격한 스키마가 필요한 과제.
- 언어별로 예시 몇 개가 관용 표현과 문체를 잡아 주는 다국어·현지화 작업.
- "이렇게 써 달라"를 설명하기보다 보여 주는 편이 쉬운 사내 문체와 톤.
- 지시만으로는 형식을 자주 벗어나는 소형 모델이나 로컬 실행 모델.
예시: 제로샷 프롬프트 vs 퓨샷 프롬프트
같은 과제의 프롬프트를 나란히 두면 두 방식의 실무적 차이가 분명해집니다. 여기서는 고객 지원 티켓을 의도별로 분류합니다.
나쁜 프롬프트 – 구조 없음
"이 지원 티켓을 보고 무슨 내용인지 알려 줘."
제로샷 프롬프트
"다음 지원 티켓을 `billing_issue`, `login_problem`, `feature_request`, `bug_report`, `other` 중 하나로 분류하세요. 티켓: "오늘 비밀번호 재설정을 세 번 시도했는데 링크가 매번 만료되었다고 나옵니다." 카테고리 이름만 출력하세요."
퓨샷 프롬프트
"각 지원 티켓을 `billing_issue`, `login_problem`, `feature_request`, `bug_report`, `other` 중 하나로 분류하세요. 카테고리 이름만 출력하세요. 예시 1: 티켓: "이번 달에 같은 구독료가 두 번 청구되었습니다." 라벨: `billing_issue` 예시 2: 티켓: "'보고서 내보내기'를 눌러도 아무 일도 일어나지 않고, 새로고침해도 마찬가지입니다." 라벨: `bug_report` 예시 3: 티켓: "보고서를 Google Sheets로 바로 내보내는 기능을 추가해 주실 수 있나요?" 라벨: `feature_request` 이제 이 티켓을 분류하세요: "오늘 비밀번호 재설정을 세 번 시도했는데 링크가 매번 만료되었다고 나옵니다."
퓨샷 버전은 패턴을 명시적으로 보여 주기 때문에, 미묘하거나 표현이 지저분한 티켓에서 분류 품질이 대체로 좋아집니다.
예시의 품질이 퓨샷 성능을 좌우한다
잘 고른 예시 3개가 거의 똑같은 10개를 꾸준히 앞섭니다. 모델은 양이 아니라 보여 준 다양성에서 과제의 경계를 배우기 때문입니다. 실망스러운 퓨샷 결과의 대부분은 예시 개수가 아니라 선택의 문제입니다.
- 1쉬운 사례만이 아니라 범위 전체를 담으세요. 모호한 티켓, 아주 짧은 티켓, 엉성하게 쓴 티켓을 포함해야 합니다. 실서비스에서 실패하는 입력이 바로 그런 것들입니다.
- 2라벨 균형을 맞추세요. 다섯 중 넷이 `bug_report`라면 모델은 `bug_report`를 과도하게 예측합니다. 각 클래스에 비슷한 비중을 주세요.
- 3순서를 섞으세요. 모델은 뒤쪽 예시에 더 큰 가중치를 두므로 같은 라벨을 블록 끝에 몰아 두지 마세요.
- 4모든 예시에서 형식을 완전히 동일하게 유지하세요. 공백, 따옴표, 키 순서가 흔들리면 형식은 협상 가능하다고 모델이 학습합니다.
- 5예시는 실제 운영 입력에서 가져오세요. 손으로 쓴 깔끔한 예시는 실제로는 오지 않을 깔끔한 입력을 기대하게 만듭니다.
- 6실제 고객 데이터를 프롬프트 템플릿에 붙여 넣지 마세요. 익명화하거나 합성 데이터를 쓰세요. 퓨샷 블록은 코드처럼 저장·버전 관리·공유됩니다.
퓨샷은 호출마다 토큰을 쓴다
퓨샷 예시는 한 번만 드는 설정 비용이 아니라, 요청할 때마다 입력 토큰으로 다시 전송됩니다. 약 120토큰짜리 예시 5개면 호출당 약 600 입력 토큰이 늘어납니다. 테스트 단계에서는 무시할 수준이지만 월 100만 호출에서는 무시할 수 없습니다.
제로샷 기준선을 먼저 측정해야 하는 현실적인 이유가 여기 있습니다. 제로샷이 이미 정확도 기준을 넘는다면, 퓨샷은 아무것도 주지 못한 채 계속 비용만 청구합니다.
🔍 예시 블록을 캐싱하세요
호출 사이에 변하지 않는 퓨샷 블록은 프롬프트 캐싱의 이상적인 대상입니다. Anthropic, OpenAI, Google 모두 캐시된 입력에 큰 할인을 적용하며 Claude 프롬프트 캐싱에서는 최대 90%에 이릅니다. 대량 파이프라인에서 퓨샷에 대한 비용 반론은 이것으로 대부분 해소됩니다.
추론 모델이 제로샷과의 격차를 좁혔다
강력한 지시 튜닝 덕분에 퓨샷 프롬프팅이 프런티어 모델에서 벌어 주던 정확도 우위는 상당 부분 사라졌습니다. Claude Opus 5, GPT-5.6, Gemini 3.1 Pro에서는 정교하게 쓴 제로샷 지시가 많은 일반 과제에서 퓨샷과 대등합니다. 다만 이 수렴이 모든 모델에 해당하지는 않습니다.
퓨샷이 여전히 토큰값을 하는 영역은 형식과 어휘입니다. 자체 라벨 체계, 내부 스키마, 사내 톤, 사전 학습에서 본 적 없는 예외 사례가 그렇습니다. 또한 소형 모델이나 로컬 호스팅 모델에서는 파인튜닝을 제외하면 여전히 가장 효과적인 정확도 수단입니다.
모델 분류 | 제로샷 품질 | 퓨샷이 여전히 도움이 되나 |
|---|---|---|
| 프런티어 추론(Claude Opus 5, GPT-5.6, Gemini 3.1 Pro) | 일반 과제에서 높음 | 주로 출력 형식, 사내 톤, 자체 라벨 체계에서 |
| 프런티어 비추론(Claude Sonnet 5, Gemini 3.7 Flash) | 양호 | 그렇다 — 좁은 도메인과 엄격한 스키마에서 |
| 소형 호스팅(Claude Haiku 4.5, Gemini 3.5 Flash-Lite) | 전문 과제에서는 들쭉날쭉 | 그렇다 — 단일 항목으로 가장 큰 정확도 향상인 경우가 많음 |
| 로컬 오픈웨이트 7~30B(Qwen3 8B, Llama 4 Scout, Gemma 4) | 편차가 크고 형식 이탈이 잦음 | 그렇다 — 쓸 만한 출력과 못 쓰는 출력을 가르는 경우가 많음 |
흔한 실수
퓨샷 실패의 대부분은 모델의 문제가 아니라 절차의 문제입니다. 예시를 넣었는데 출력이 오히려 나빠진 사례는 대체로 다음 다섯 가지로 설명됩니다.
❌ 제로샷 기준선을 재기 전에 예시부터 추가한다
Why it hurts: 예시가 실제로 도움이 됐는지 모른 채 입력 토큰 비용만 계속 부담하게 됩니다.
Fix: 먼저 테스트 50건을 제로샷으로 실행해 정확도를 기록하세요. 그다음에 예시를 넣고 다시 측정합니다.
❌ 모든 예시가 같은 라벨이다
Why it hurts: 모델은 이 불균형을 사전 확률로 읽고 실제 입력에서 그 클래스를 과도하게 예측합니다.
Fix: 예시 전체에서 클래스 균형을 맞추고, 같은 라벨이 붙어 있지 않도록 섞으세요.
❌ 예시가 작성된 지시와 모순된다
Why it hurts: 지시와 시연이 어긋나면 모델은 대개 조용히 시연을 따릅니다.
Fix: 수정할 때마다 지시와 모든 예시를 대조해 다시 읽으세요. 예시를 명세로 취급해야 합니다.
❌ 예시가 실제 입력보다 훨씬 길거나 깔끔하다
Why it hurts: 모델이 정돈된 입력을 기대하도록 학습해, 실제로 들어오는 지저분한 텍스트에서 성능이 떨어집니다.
Fix: 운영 트래픽에서 예시를 표본으로 뽑으세요. 보기 나쁜 사례도 포함해야 합니다.
❌ 실제 고객 데이터를 예시 블록에 남겨 둔다
Why it hurts: 프롬프트 템플릿은 버전 관리·공유·로깅되므로, 그 안의 개인정보는 곧바로 컴플라이언스 노출이 됩니다.
Fix: 저장되는 템플릿에 들어가기 전에 모든 예시를 익명화하거나 합성 데이터로 대체하세요.
PromptQuorum이 선택을 돕는 방법
PromptQuorum은 제로샷과 퓨샷 프롬프트를 여러 제공사에 걸쳐 한곳에서 테스트할 수 있는 멀티모델 AI 디스패치 도구입니다. 지시만 담은 프롬프트와 예시를 붙인 프롬프트를 GPT-5.6, Claude Opus 5, Gemini 3.1 Pro 같은 모델에 동시에 보내 나란히 비교할 수 있습니다.
PromptQuorum에서 할 수 있는 일:
- Single Step, RTF, CO-STAR 같은 프레임워크로 제로샷 프롬프트를 작성해 빠르게 기준선을 만듭니다.
- 더 촘촘한 통제가 필요할 때 SPECS나 Google 프롬프팅 가이드 같은 프레임워크에 대표 예시를 넣어 퓨샷으로 전환합니다.
- 두 버전을 모두 템플릿으로 저장하고, 모델별로 정확도·지연시간·토큰 비용을 시간에 걸쳐 비교합니다.
제로샷과 퓨샷 프롬프팅 중 선택하는 방법
- 1일상적이고 단순한 과제는 제로샷(예시 없음)으로 시작하세요. 예: "이 리뷰를 긍정 또는 부정으로 분류하세요." 정확도가 충분하다면 제로샷이 더 빠르고 저렴합니다.
- 2제로샷 성능이 부족하면(정확도나 품질이 80% 미만) 퓨샷 예시를 2~5개 추가하세요. 올바른 라벨이 붙은 긍정 리뷰 2~3개와 부정 리뷰 2~3개를 보여 줍니다. 퓨샷은 예시로 가르치는 방식입니다.
- 3미묘한 구분이나 드문 패턴이 있는 과제라면 예시를 5~10개까지 늘리세요. 반어, 유해한 편향, 도메인 특유의 뉘앙스를 잡아야 한다면 예시가 많을수록 도움이 됩니다.
- 4예상되는 입력 범위를 아우르는 예시를 고르세요. 제품 리뷰를 분류한다면 열광적인 것, 미지근한 것, 부정적인 것을 모두 넣으세요. 쉬운 사례만 보여 주면 안 됩니다.
- 5운영에 넣기 전에 테스트 세트에서 퓨샷의 효과를 측정하세요. 같은 프롬프트를 예시 0개와 5개로 50건에 실행합니다. 10%포인트 이상 오르면 예시를 채택하고, 개선이 5% 미만이면 제로샷을 유지하세요.
- 6퓨샷을 운영에 넣은 뒤에는 예시 블록을 캐싱하고 분기마다 점검하세요. 오래된 예시는 제품이 더는 쓰지 않는 분류와 형식을 조용히 고착시킵니다.
자주 묻는 질문
"퓨샷"은 예시 몇 개를 뜻하나요?
두 개에서 대략 열 개까지입니다. 하나만 주면 원샷이라고 부릅니다. 효과는 보통 여덟 개 부근에서 평평해지고, 그 이상은 대체로 줄어드는 수익에 입력 토큰만 더 쓰는 셈이 됩니다. 목표 정확도를 맞추는 데 수십 개가 필요하다면 대개 파인튜닝이 더 적합한 도구입니다.
퓨샷 프롬프팅은 파인튜닝과 같은 건가요?
아닙니다. 퓨샷 프롬프팅은 인컨텍스트 러닝으로, 예시는 한 번의 호출 동안 프롬프트에 있을 뿐 모델 자체는 바뀌지 않습니다. 파인튜닝은 가중치를 갱신해 이후 모든 호출에 남습니다. 퓨샷은 요청마다 입력 토큰 비용이 들고, 파인튜닝은 학습 실행과 전용 모델 호스팅 비용이 듭니다.
추론 모델에서도 퓨샷 프롬프팅이 도움이 되나요?
순수 정확도 측면에서는 예전만 못하지만, 형식 측면에서는 생각보다 훨씬 유용합니다. Claude Opus 5, GPT-5.6, Gemini 3.1 Pro에서는 정확하게 쓴 제로샷 지시가 일반 과제에서 퓨샷과 대등한 경우가 많습니다. 다만 정확한 JSON 스키마, 자체 라벨 어휘, 특정한 사내 톤이 필요하다면 예시를 주는 것이 여전히 가장 확실한 방법입니다.
예시를 넣었더니 출력이 왜 나빠졌나요?
대개 라벨 불균형, 지시와의 모순, 형식 흔들림 때문입니다. 예시 대부분이 한 라벨이면 모델이 그 라벨을 과도하게 예측합니다. 어떤 예시가 작성된 지시와 충돌하면 모델은 예시 쪽을 따르는 경향이 있습니다. 또 예시가 실제 입력보다 깔끔하면, 실제로 들어오는 지저분한 텍스트에서 성능이 떨어집니다.
퓨샷 예시의 순서가 중요한가요?
중요합니다. 모델은 뒤쪽 예시에 더 큰 가중치를 두기 때문에, 같은 라벨 세 개로 끝나는 블록은 예측을 그 라벨 쪽으로 치우치게 만듭니다. 클래스를 번갈아 배치하고, 순서를 바꿨다면 반드시 다시 테스트하세요. 순서 효과는 정확도를 몇 포인트 움직일 만큼 실재합니다.
대규모로 쓸 때 퓨샷 비용을 어떻게 관리하나요?
프롬프트 캐싱을 쓰세요. 고정된 예시 블록은 호출마다 동일하므로 캐싱 대상으로 이상적입니다. Anthropic, OpenAI, Google 모두 캐시된 입력을 큰 폭으로 할인해 청구하며 Claude 프롬프트 캐싱에서는 약 90%까지 절감됩니다. 캐시되는 접두부가 안정되도록 예시는 프롬프트 맨 앞에 두세요.
퓨샷과 Chain-of-Thought 프롬프팅을 함께 쓸 수 있나요?
쓸 수 있고, 가장 강력한 조합 중 하나입니다. 퓨샷 Chain-of-Thought는 예시가 최종 답만이 아니라 추론 단계까지 보여 준다는 뜻입니다. 두 기법을 따로 쓸 때보다 출력 토큰이 더 들지만, 다단계 과제에서는 제로샷 "단계별로 생각하라"보다 대체로 더 안정적입니다.
출처 및 더 읽을거리
- Brown, T., Mann, B., Ryder, N., et al. (2020). "Language Models are Few-Shot Learners." NeurIPS 2020. arXiv:2005.14165 — 퓨샷, 원샷, 제로샷을 프롬프팅 방식으로 정립한 논문.
- Zhao, Z., Wallace, E., Feng, S., Klein, D., & Singh, S. (2021). "Calibrate Before Use: Improving Few-Shot Performance of Language Models." ICML 2021. arXiv:2102.09690 — 예시 순서에서 나타나는 다수 라벨 편향과 최근성 편향에 관한 연구.
- Lu, Y., Bartolo, M., Moore, A., Riedel, S., & Stenetorp, P. (2022). "Fantastically Ordered Prompts and Where to Find Them." ACL 2022. arXiv:2104.08786 — 퓨샷 정확도가 예시 순서에 얼마나 민감한지 다룬 연구.
- Min, S., Lyu, X., Holtzman, A., et al. (2022). "Rethinking the Role of Demonstrations." EMNLP 2022. arXiv:2202.12837 — 라벨의 정확성보다 예시의 형식과 입력 분포가 더 중요하다는 근거.
- Anthropic. "Prompt caching." Claude 플랫폼 문서 — 퓨샷 블록 같은 고정 프롬프트 접두부에 대한 캐시 입력 과금 안내.