퓨샷 프롬프트(Few-shot) 예시로 가르치기: 좋은 예와 나쁜 예 함께 쓰기

🤔 말로 설명해도 형식이 맞지 않을 때

"제목은 짧게, 본문은 세 문단, 마지막에 행동 제안 한 줄"이라고 아무리 적어도 결과가 매번 조금씩 다릅니다. 제목이 두 줄이 되기도 하고 행동 제안이 문단 중간에 끼기도 합니다. 설명이 부족한 것이 아니라 형식이라는 것 자체가 말로 옮기기 어렵습니다.

이럴 때 설명을 더 쓰는 대신 원하는 결과물 하나를 그대로 보여 주면 대부분 해결됩니다. 새로 온 동료에게 보고서 양식을 말로 설명하는 것보다 지난달 보고서 한 장을 건네는 편이 빠른 것과 같습니다.

🔑 퓨샷 프롬프트의 정의

퓨샷 프롬프트(Few-shot Prompting)는 원하는 결과의 실제 예시를 프롬프트 안에 몇 개 넣어 모델이 형식과 말투와 판단 기준을 따라 하게 만드는 방식입니다. 샷(shot)은 예시 하나를 세는 단위라서 예시가 없으면 제로샷, 하나면 원샷, 몇 개면 퓨샷이라고 부릅니다. 앤트로픽 문서는 같은 뜻으로 멀티샷(multishot)이라는 말도 씁니다.

앤트로픽 공식 문서는 예시를 출력의 형식과 어조와 구조를 조종하는 가장 믿을 만한 방법 가운데 하나로 꼽고, 잘 만든 예시 몇 개가 정확도와 일관성을 올린다고 설명합니다. 구글 제미나이 문서는 한 걸음 더 나가서 예시 없는 프롬프트는 효과가 떨어지기 쉽다고 적고, 예시가 충분히 분명하면 지시문을 아예 생략해도 된다고 안내합니다.

📏 예시의 개수와 세 가지 조건

앤트로픽 공식 문서가 권하는 개수는 3~5개입니다. 예시가 갖출 조건은 세 가지입니다.

구글 문서는 여기에 서식의 일관성을 더합니다. 예시마다 태그와 공백, 줄바꿈, 구분자를 똑같이 맞추라는 안내입니다. 예시 하나는 콜론으로 나누고 다른 하나는 줄바꿈으로 나누면 모델이 어느 쪽을 따라야 할지 정하지 못합니다. 예시가 너무 많으면 과적합, 즉 예시의 사소한 특징까지 따라 하는 문제가 생긴다는 경고도 같은 문서에 있습니다.

개수를 정하는 순서는 OpenAI 도움말이 분명하게 적어 두었습니다. 예시 없이 먼저 시험하고, 결과가 일정하지 않으면 예시 몇 개를 더하고, 그래도 안 되면 그때 미세조정을 검토하라는 순서입니다.

✍️ 좋은 예와 나쁜 예를 함께 넣는 법

좋은 예만 넣으면 모델은 어디까지가 허용되는지 모릅니다. 경계를 보여 주려면 나쁜 예를 함께 넣되, 왜 나쁜지를 한 줄로 붙입니다. 이유가 없는 나쁜 예는 모델이 그것도 따라 할 수 있습니다.

좋은 예 셋은 유형이 다르고(쿠폰, 배송, 교환) 형식은 같습니다. 나쁜 예 둘은 너무 길거나 너무 짧은 양극단을 보여 주고 이유가 붙어 있습니다. 태그 이름을 좋은 예와 나쁜 예에서 다르게 붙여 모델이 섞어 읽지 않게 했습니다.

말투를 가르칠 때도 같은 구조를 씁니다. 자기가 직접 쓴 글 서너 편을 예시로 넣고 "이 예시들의 문장 길이와 어휘 수준을 따라 주세요"라고 적는 방식인데, 그 원리는 말투와 문체 지시하기에서 이어집니다.

🧭 예시가 특히 잘 통하는 작업

예시는 설명으로 옮기기 어려운 조건을 전달할 때 효과가 가장 큽니다.

• 분류와 태그 붙이기: 환불과 교환의 경계처럼 말로 정의하기 애매한 기준을 사례로 보여 줍니다
• 정해진 형식으로 추출하기: OpenAI 도움말은 원하는 출력 형식을 예시로 보여 주라고 권합니다. 회사 이름은 어디에, 사람 이름은 어디에 적는지 빈 양식을 함께 넣습니다
• 말투와 길이 맞추기: 뉴스레터 인사말, 상품 설명처럼 어조가 중요한 글
• 추론 방식 보여 주기: 앤트로픽 문서는 예시 안에 <thinking> 태그로 생각 과정을 넣어 두면 모델이 그 방식을 일반화한다고 설명합니다

반대로 예시가 필요 없는 때도 분명합니다. 정답이 하나뿐인 계산이나 사실 확인, 한 번에 끝나는 짧은 번역은 예시를 넣어도 달라지지 않습니다. 형식과 판단 기준이 결과를 좌우하는 작업인지 먼저 봅니다.

🚧 예시가 오히려 결과를 망치는 경우

예시를 넣었는데 결과가 나빠졌다면 예시 자체를 의심합니다.

• 예시가 한 가지 모양뿐일 때: 긍정 후기만 세 개 넣으면 부정 후기도 긍정처럼 요약합니다. 경계 사례를 하나는 넣습니다
• 예시와 실제 자료의 길이가 크게 다를 때: 세 줄짜리 예시로 배운 모델은 세 쪽짜리 자료를 세 줄처럼 다룹니다
• 예시에 우연한 공통점이 있을 때: 예시 셋이 모두 "고객님"으로 시작하면 모델은 그 시작을 규칙으로 배웁니다
• 예시가 지시와 어긋날 때: 지시에는 25자 이내라고 적고 예시가 40자면 모델은 둘 중 하나를 골라야 합니다

앤트로픽 문서는 이럴 때 쓸 방법을 하나 더 적어 두었습니다. 클로드에게 지금 넣은 예시가 관련성과 다양성을 갖췄는지 평가하게 하거나, 처음 넣은 몇 개를 바탕으로 예시를 더 만들어 달라고 하는 방법입니다. 예시를 사람이 다 만들지 않아도 됩니다.

⚠️ 자주 하는 실수

• 예시를 태그 없이 지시 사이에 끼워 넣습니다: 모델이 예시 문장을 지시로 읽습니다
• 예시마다 서식을 다르게 씁니다: 어느 서식을 따를지 정하지 못해 결과가 매번 달라집니다
• 나쁜 예에 이유를 붙이지 않습니다: 모델이 나쁜 예도 따라 할 수 있습니다
• 예시를 열 개 넘게 넣습니다: 예시의 사소한 특징까지 따라 하고 프롬프트가 길어져 자료를 넣을 공간이 줄어듭니다
• 처음부터 예시를 넣습니다: 예시 없이 먼저 시험해 어디가 달라지는지 본 뒤 그 부분에만 예시를 더합니다

❓ 자주 묻는 질문

예시는 몇 개가 적당한가요?

앤트로픽 공식 문서는 3~5개를 권합니다. 구글 문서는 모델이 적은 예시로도 패턴을 알아보지만 너무 많으면 과적합 위험이 있다고 적고 있습니다. 하나로 시작해 결과가 일정하지 않은 유형을 하나씩 더하는 편이 어디까지 필요한지 알기 쉽습니다.

나쁜 예를 넣으면 모델이 나쁜 예를 따라 하지 않나요?

이유 없이 넣으면 그럴 수 있습니다. 나쁜 예에는 왜 나쁜지를 한 줄로 붙이고 좋은 예와 다른 태그 이름으로 감싸 구분합니다. 나쁜 예가 필요한 경우는 경계를 보여 줘야 할 때이고, 형식만 가르치는 작업이라면 좋은 예만으로 충분합니다.

예시를 넣으면 프롬프트가 길어져 비용이 늘지 않나요?

늘어납니다. API에서는 예시도 입력 토큰으로 청구됩니다. 같은 예시를 매번 보내는 작업이라면 예시를 시스템 프롬프트 쪽에 두고 사용자 쪽에는 자료만 넣는 구조가 관리하기 쉽고, 어디에 두는지는 시스템 프롬프트와 사용자 프롬프트 차이에 있습니다.

제로샷으로 잘 되는데도 예시를 넣어야 하나요?

넣지 않아도 됩니다. OpenAI 도움말이 제시하는 순서가 제로샷을 먼저 시험하고 안 될 때 퓨샷으로 가는 것입니다. 잘 되는 프롬프트에 예시를 더하면 예시의 특징이 결과에 섞여 오히려 달라질 수 있습니다.

📋 3줄 요약

1. 퓨샷 프롬프트(Few-shot Prompting)는 원하는 결과의 실제 예시를 프롬프트 안에 몇 개 넣어 모델이 형식과 말투와 판단 기준을 따라 하게 만드는 방식이고 설명으로 적기 어려운 조건을 전달하는 데 맞습니다.

2. 앤트로픽 공식 문서는 실제 용도와 닮고 서로 달라서 의도하지 않은 패턴을 배우지 않는 예시 3~5개를 example 태그로 감싸라고 권하고, 구글 문서는 예시의 구조와 서식을 똑같이 맞추라고 안내합니다.

3. 나쁜 예를 넣을 때는 왜 나쁜지를 한 줄로 붙이고, 예시가 한 가지 모양뿐이면 모델이 그 모양만 따라 하므로 예시 없는 제로샷으로 먼저 시험한 뒤 결과가 일정하지 않은 곳에만 예시를 더합니다.

📚 참고 자료

• Prompting best practices: Use examples effectively, Claude Platform Docs
• Prompt design strategies, Gemini API Docs
• Best practices for prompt engineering with the OpenAI API, OpenAI Help Center
• 프롬프트 엔지니어링 기본 익히기, 준이아빠블로그

2026년 9월 28일 기준으로 공식 문서를 확인했습니다.