퓨샷 프롬프팅(few-shot prompting)은 원하는 입출력 예시를 프롬프트에 포함해 Claude의 응답 형식과 판단 기준을 학습시키는 기법입니다. 예시 선택 전략, 형식 일관성, 경계 사례 포함법, 그리고 예시가 오히려 해가 되는 경우를 다룹니다.
예시가 지시보다 강력한 이유
길게 설명한 지시문보다 잘 고른 예시 3개가 형식 준수율을 더 높이는 경우가 많습니다. 지시문은 해석의 여지를 남기지만, 예시는 기대 출력을 구체적 형태로 보여 주기 때문입니다. Anthropic 문서는 "예시를 활용하라(Use examples)"를 핵심 프롬프트 기법으로 명시하며, 특히 출력 형식이 복잡하거나 판단 기준이 미묘한 작업에서 효과가 크다고 설명합니다.
<instructions>
고객 문의를 카테고리로 분류하세요. 아래 예시의 판단 기준을 따르세요.
</instructions>
<examples>
<example>
문의: 어제 주문한 상품이 아직 배송 준비 중이에요.
분류: 배송 문의
</example>
<example>
문의: 결제는 됐는데 주문 내역이 안 보여요.
분류: 주문 오류
</example>
<example>
문의: 상품 자체는 좋은데 배송 박스가 찌그러져 왔어요.
분류: 배송 문의
</example>
</examples>
<query>
문의: {{CUSTOMER_MESSAGE}}
분류:
</query>
세 번째 예시가 중요합니다. '상품 이야기가 섞여 있어도 핵심 불만이 배송이면 배송 문의'라는 미묘한 판단 기준은 지시문으로 쓰기 어렵지만 예시로는 명확히 전달됩니다. 이것이 퓨샷의 본질입니다. 말로 설명하기 어려운 판단 기준을 사례로 전달하는 것입니다. 예시를 <example> 태그로 감싸는 이유는 예시와 실제 입력의 경계를 분명히 하기 위해서입니다. 경계가 없으면 Claude가 예시 속 내용을 실제 처리 대상으로 오인할 수 있습니다.
예시 선택 전략: 다양성과 경계 사례
예시의 개수보다 구성이 중요합니다. 서로 비슷한 예시 5개보다 서로 다른 상황을 대표하는 예시 3개가 낫습니다. 좋은 예시 세트를 만드는 기준은 세 가지입니다.
- 대표성: 실제 운영에서 가장 자주 나타나는 입력 유형을 포함합니다. 프로덕션 로그에서 빈도 상위 유형을 뽑는 것이 이상적입니다.
- 다양성: 카테고리 분류라면 모든 카테고리가 최소 한 번씩 등장해야 합니다. 특정 카테고리만 예시에 있으면 그쪽으로 분류가 쏠리는 편향이 생깁니다.
- 경계 사례(edge case): 두 카테고리에 걸치는 애매한 입력, 빈 입력, 형식이 깨진 입력에 대한 올바른 처리를 예시로 보여 줍니다.
<example>
문의: ㅁㄴㅇㄹ
분류: 분류 불가
</example>
<example>
문의: 환불해 주세요. 그리고 배송도 늦었어요.
분류: 환불 요청
</example>
두 번째 예시는 '복수 주제가 섞이면 행동 요청이 우선'이라는 우선순위 규칙을 전달합니다. 이런 규칙은 지시문에도 쓰고 예시로도 보여 주면 가장 안정적입니다.
주의할 점은 예시의 오류는 그대로 복제된다는 것입니다. 예시 출력에 오타나 형식 불일치가 있으면 Claude는 그것까지 학습합니다. 예시 세트는 사람이 검수한 정답만 포함해야 하며, 프로덕션에서 잘못 처리된 사례를 수정 없이 예시로 넣는 실수를 경계해야 합니다.
형식 일관성과 퓨샷의 함정
퓨샷 예시의 형식은 실제 입력의 형식과 정확히 일치해야 합니다. 예시에서는 "문의:"로 시작했는데 실제 입력은 JSON으로 주면 예시의 효과가 크게 떨어집니다. 또한 모든 예시가 같은 구조를 가져야 합니다. 예시마다 필드 순서가 다르면 Claude는 어떤 형식을 따라야 할지 혼란스러워합니다.
퓨샷이 오히려 해가 되는 경우도 시험에 출제됩니다.
함정 1: 창의적 작업의 과잉 제약. 브레인스토밍이나 자유 작문에서 예시를 주면 출력이 예시의 어휘와 구조에 수렴해 다양성이 사라집니다. 창의적 작업에는 제로샷(zero-shot)이나 방향만 제시하는 짧은 지침이 낫습니다.
함정 2: 예시 개수 편향. 감정 분류 예시 10개 중 8개가 '부정'이면, 실제 분포와 무관하게 부정 분류가 과다해집니다. 예시의 레이블 분포는 균형 있게 구성해야 합니다.
함정 3: 토큰 비용 무시. 예시가 늘수록 매 호출의 입력 토큰이 늘어납니다. 긴 예시 세트를 반복 사용한다면 프롬프트 캐싱을 적용해 예시 부분을 캐시하는 것이 비용 최적화의 정석입니다.
# 예시 블록에 캐시 브레이크포인트를 두는 패턴
system = [
{"type": "text", "text": ROLE_AND_RULES},
{"type": "text", "text": EXAMPLES_BLOCK,
"cache_control": {"type": "ephemeral"}},
]
정리하면, 퓨샷은 '형식과 판단 기준이 중요한 반복 작업'에 쓰고, '다양성이 중요한 생성 작업'에는 피하는 것이 원칙입니다.
시험 함정
- '예시는 많을수록 좋다'는 선택지는 오답입니다. 다양성과 대표성을 갖춘 3~5개가 비슷한 예시 여러 개보다 효과적입니다.
- 창의적 생성 작업에 퓨샷을 권하는 선택지는 함정입니다. 예시는 출력 다양성을 좁히므로 자유 작문에는 부적합합니다.
- 예시 레이블 분포가 한쪽에 쏠려도 무방하다는 선택지는 오답입니다. 분포 편향은 분류 결과를 왜곡합니다.
- 예시 형식과 실제 입력 형식이 달라도 된다는 선택지는 오답입니다. 형식 불일치는 퓨샷 효과를 크게 떨어뜨립니다.
- 긴 예시 세트의 비용 대책으로 '예시 삭제'만 제시하는 선택지보다 프롬프트 캐싱 적용이 정답인 경우가 많습니다.
실습 시나리오
실제 시험과 같은 형식의 시나리오 문제입니다.
제품 리뷰를 5개 카테고리로 분류하는 파이프라인에서 '품질 불만' 카테고리의 재현율이 유독 낮습니다. 프롬프트에는 예시 4개가 있고 그중 '품질 불만' 예시는 없습니다. 가장 적절한 개선책은 무엇입니까?
빌드 연습 · 문의 분류기의 예시 세트 구축과 편향 측정
약 40분1.카테고리와 우선순위 규칙 정의
문의 5개 카테고리와, 복수 주제가 섞였을 때의 우선순위 규칙을 문서화합니다.
기대 결과 · 카테고리 정의서와 우선순위 규칙 3개가 완성됩니다.
2.제로샷 기준선 측정
예시 없이 지시문만으로 테스트 입력 20개를 분류하고 정확도를 기록합니다.
기대 결과 · 카테고리별 정확도 표가 만들어져 개선 효과를 비교할 기준선이 생깁니다.
3.예시 세트 설계
카테고리별 전형 사례 1개 + 경계 사례 2개 + 분류 불가 사례 1개로 예시를 구성합니다.
기대 결과 · 모든 카테고리가 등장하고 레이블 분포가 균형 잡힌 예시 블록이 완성됩니다.
4.퓨샷 적용 후 재측정
같은 테스트 입력 20개를 퓨샷 프롬프트로 재분류하고 기준선과 비교합니다.
기대 결과 · 카테고리별 정확도 변화가 수치로 확인되고, 특히 경계 사례 정확도가 개선됩니다.
5.캐싱 적용
예시 블록에 cache_control을 설정해 반복 호출 비용을 줄입니다.
기대 결과 · 두 번째 호출부터 캐시 히트가 발생하며 입력 토큰 비용이 감소합니다.