Zero-shot에서 Few-shot으로

한 번 잘 되는 프롬프트와, 여러 번 써도 비슷하게 잘 되는 프롬프트는 다릅니다. 중급 단계에서 중요한 차이는 바로 여기서 생깁니다. 어떤 일은 예시 없이도 충분히 잘 처리됩니다. 반대로 어떤 일은 지시문을 아무리 길게 써도, 예시 한두 개를 붙이는 순간 훨씬 안정적으로 돌아갑니다.

이 장의 핵심은 단순합니다. 예시를 많이 넣는 것이 능사가 아니라, 예시가 필요한 과업과 필요하지 않은 과업을 구분하는 판단력이 중요하다는 점입니다. Zero-shot과 Few-shot의 차이를 이해하면, 프롬프트를 더 길게 쓰기 전에 먼저 이렇게 묻게 됩니다. "이 일은 설명만으로 충분한가, 아니면 패턴을 보여줘야 하는가?"

Zero-shot은 무엇이고, Few-shot은 무엇인가

Zero-shot은 말 그대로 예시 없이 지시만 주는 방식입니다. 해야 할 일, 입력 자료, 출력 형식, 제약 조건을 설명하고 바로 답을 받습니다. 예를 들어 "아래 문서를 5문장으로 요약해줘"처럼 요청하는 방식이 여기에 가깝습니다.

Few-shot은 짧은 예시를 함께 주어 원하는 패턴을 보여주는 방식입니다. 모델에게 규칙을 장황하게 설명하는 대신, "입력이 이렇다면 출력은 이렇게 나와야 한다"는 작은 샘플을 먼저 보여줍니다. 사람에게 일을 가르칠 때도 비슷합니다. 말로만 설명하는 것보다, 잘된 예시 하나를 보여주면 훨씬 빨리 감을 잡는 경우가 많습니다.

중요한 점은 둘의 차이가 단순히 "예시를 넣었느냐"에만 있지 않다는 것입니다. 더 본질적인 차이는 이것입니다.

• Zero-shot은 규칙 설명 중심입니다.

• Few-shot은 패턴 학습 중심입니다.

• 따라서 Few-shot은 "무엇을 할지"뿐 아니라 "어떻게 보이게 할지"까지 전달하는 데 강합니다.

즉, Zero-shot은 설계서를 읽고 바로 일하는 방식이고, Few-shot은 설계서와 함께 견본품을 보는 방식이라고 생각하면 이해하기 쉽습니다.

예시 없이도 잘 되는 과업

모든 과업에 예시가 필요한 것은 아닙니다. 오히려 예시를 붙이지 않는 편이 더 깔끔하고 빠른 경우도 많습니다. 특히 과업의 목표가 단순하고, 출력 형식이 명확하며, 정답의 방향이 비교적 넓게 허용되는 경우에는 Zero-shot이 잘 작동합니다.

예를 들어 다음과 같은 경우가 그렇습니다.

• 긴 글을 짧게 요약하기

• 회의 메모를 항목별로 정리하기

• 문장에서 날짜, 이름, 금액 같은 정보를 추출하기

• 이미 정해진 형식으로 표를 만들어 정리하기

• 쉬운 말로 다시 설명하기

이런 과업은 규칙이 비교적 분명합니다. "짧게", "표로", "초등학생도 이해하게", "다섯 줄 안으로" 같은 지시가 꽤 직접적으로 통합니다. 이때는 예시보다도 출력 형식, 길이, 포함할 항목, 제외할 항목을 분명히 적는 것이 더 중요합니다.

예를 들어 문서 요약 과업을 생각해봅시다.

아래 보고서를 읽고, 핵심 주장 3개와 실행 항목 2개를 분리해서 정리해줘. 각 항목은 한 문장으로 쓰고, 원문에 없는 추측은 넣지 마.

이 프롬프트는 예시가 없어도 꽤 안정적입니다. 해야 할 일이 분명하고, 출력 형식도 정해져 있기 때문입니다. 이럴 때 굳이 예시를 넣으면 프롬프트만 길어지고, 오히려 특정 표현 방식에 답이 갇힐 수 있습니다.

예시가 성능을 안정화하는 과업

반대로, 말로 설명해도 애매함이 남는 과업이 있습니다. 이런 일은 예시가 큰 힘을 발휘합니다. 특히 다음과 같은 상황에서 Few-shot이 유용합니다.

첫째, 분류 기준이 미묘할 때입니다. 고객 문의를 "환불", "배송", "제품 불량", "단순 문의"로 나누는 일은 얼핏 쉬워 보이지만, 실제 메시지는 여러 범주가 섞여 있습니다. "물건이 늦게 왔는데 포장도 찢어져 있었어요" 같은 문장은 배송 문제이면서 제품 문제처럼 보일 수 있습니다. 이런 경우 예시가 있으면 분류 우선순위를 보여줄 수 있습니다.

둘째, 톤과 스타일이 중요할 때입니다. "정중하게 써줘"라는 지시는 생각보다 폭이 넓습니다. 누군가에게는 딱딱한 공문체가 정중함이고, 다른 누군가에게는 따뜻하고 배려 있는 말투가 정중함입니다. 이럴 때 예시를 붙이면 모델은 단어 선택, 문장 길이, 말투의 온도를 더 잘 맞춥니다.

셋째, 좋은 답의 기준이 여러 개일 때입니다. 예를 들어 자기소개서 피드백을 할 때는 정확성만으로 부족합니다. 구체성, 설득력, 문장력, 직무 적합성 같은 요소가 함께 들어갑니다. 이런 복합 기준은 지시문만으로는 전달이 흐릿할 수 있습니다. 예시를 통해 "이런 피드백을 좋은 피드백으로 본다"는 감각을 심어줄 수 있습니다.

넷째, 조직 내부의 방식이 있을 때입니다. 같은 회의록이라도 어떤 팀은 의사결정만 뽑고, 어떤 팀은 액션 아이템과 담당자까지 적어야 합니다. 외부의 일반 규칙이 아니라 우리 팀만의 형식이 중요한 순간에는 Few-shot이 특히 강합니다.

Zero-shot과 Few-shot을 가르는 판단 기준

실무에서는 "무조건 Few-shot"도 아니고 "일단 Zero-shot"도 아닙니다. 판단의 기준이 필요합니다. 아래 표는 그 기준을 빠르게 잡는 데 도움이 됩니다.

이 표를 한 문장으로 줄이면 이렇습니다. 설명으로 끝나는 일은 Zero-shot, 감을 보여줘야 하는 일은 Few-shot입니다.

Zero-shot이 특히 잘 맞는 상황

Zero-shot은 가볍고 빠릅니다. 프롬프트가 짧아 관리하기도 쉽습니다. 그래서 다음과 같은 상황에서 좋은 출발점이 됩니다.

규칙이 이미 일상언어로 충분히 설명될 때

"세 문장으로 요약해줘", "표로 정리해줘", "중학생 수준으로 쉽게 설명해줘" 같은 요청은 사람도 이해하기 쉽고 모델도 잘 따릅니다. 이럴 때는 예시보다 지시의 선명함이 더 중요합니다.

초안을 빨리 받아야 할 때

브레인스토밍, 제목 후보 만들기, 초안 작성처럼 처음부터 완벽함보다 속도가 중요한 업무가 있습니다. 이 단계에서는 예시 없이 넓게 받아본 뒤, 다음 단계에서 다듬는 편이 효율적입니다.

예시가 오히려 답을 좁힐 수 있을 때

광고 문구 아이디어나 새로운 행사 콘셉트처럼 다양성이 중요한 과업에서는 예시가 모델을 한 방향으로 끌어당길 수 있습니다. 예시가 창의성의 레일이 되어버리는 셈입니다.

예를 들어 "봄맞이 캠페인 카피 20개를 제안해줘"라는 요청에 특정 스타일 예시를 붙이면, 20개가 사실상 같은 톤으로 나올 가능성이 큽니다. 이럴 때는 예시를 빼고 제약만 주는 쪽이 더 낫습니다.

Few-shot이 특히 잘 맞는 상황

Few-shot은 패턴 전달에 강합니다. 특히 결과의 일관성이 중요할수록 힘을 발휘합니다.

분류 작업에서 경계가 흐릴 때

예를 들어 고객 문의를 분류한다고 해봅시다. 규칙을 말로 설명해도 경계가 애매합니다. 이럴 때는 대표 사례를 보여주는 것이 빠릅니다.

분류 기준:
- 배송: 배송 지연, 오배송, 배송 상태 문의
- 환불: 결제 취소, 환불 요청
- 제품 불량: 기능 이상, 파손, 누락

예시 1
입력: 아직 상품이 안 왔는데 배송 조회도 안 됩니다.
출력: 배송

예시 2
입력: 상품을 받았는데 전원이 켜지지 않습니다.
출력: 제품 불량

이제 아래 문의를 같은 기준으로 분류해줘.
입력: 박스가 찢어진 상태로 왔고 내용물도 하나 빠졌어요.
출력:

이 프롬프트가 주는 힘은 단순히 정답 두 개를 보여주는 데 있지 않습니다. "이 조직은 이런 문장을 이런 라벨로 본다"는 판단 기준을 전달한다는 데 있습니다.

평가 작업에서 기준이 추상적일 때

"더 설득력 있게", "더 전문적으로", "더 친절하게"는 모두 추상적인 표현입니다. 평가 항목이 많고 주관성이 들어가는 업무는 예시가 있어야 기준이 살아납니다.

예를 들어 자기소개서 피드백을 요청하면서, 좋은 피드백 예시와 나쁜 피드백 예시를 함께 주면 결과가 훨씬 안정됩니다. 모델은 단순히 단점을 나열하는 대신, 구체적인 개선 제안까지 담는 방향을 배우게 됩니다.

조직 스타일을 유지해야 할 때

고객 응답 메일, 교육용 설명문, 주간 보고서 서두처럼 팀의 말투가 중요한 문서는 Few-shot의 효과가 큽니다. 예시는 단어 선택, 문장 길이, 배려 표현, 강조 방식까지 묵묵히 가르칩니다.

예시가 성능을 망치는 경우

Few-shot이 강력하다고 해서 항상 좋은 것은 아닙니다. 예시는 방향을 잡아주지만, 잘못된 방향도 아주 잘 고정시킵니다. 그래서 "예시를 넣을까?" 못지않게 "이 예시가 괜찮은가?"를 따져야 합니다.

예시가 편향되어 있을 때

예를 들어 고객 문의 분류 예시를 모두 쉬운 사례만 넣으면, 실제 현장에서 자주 나오는 애매한 문장을 제대로 처리하지 못합니다. 예시는 규칙을 가르치는 교재이므로, 한쪽으로 치우치면 결과도 치우칩니다.

예시끼리 기준이 다를 때

첫 번째 예시에서는 짧고 딱딱하게 답했고, 두 번째 예시에서는 길고 친절하게 답했다면 모델은 어느 쪽을 따라야 할지 혼란스러워집니다. 예시를 여러 개 넣을수록 내부 일관성이 중요합니다.

예시가 너무 길어 핵심을 묻을 때

긴 예시는 풍부해 보이지만, 실제로는 중요한 패턴을 흐리게 만들기도 합니다. 특히 실무 프롬프트는 반복 사용이 목적이므로, 예시가 너무 장황하면 관리도 어려워집니다. Few-shot은 "많이 보여주기"보다 "핵심을 정확히 보여주기"에 가깝습니다.

예시가 창의성을 제한할 때

카피라이팅, 아이디어 발상, 제목 생성처럼 다양한 결과가 필요한 업무에서는 예시가 정답처럼 작동할 수 있습니다. 결국 모델은 새롭게 생각하기보다, 예시 주변을 맴도는 답을 내놓게 됩니다.

예시가 낡았을 때

팀에서 만든 프롬프트 라이브러리를 오래 쓰다 보면 예시가 현재 기준과 어긋나는 경우가 생깁니다. 예전 제품명, 오래된 정책, 바뀐 말투가 예시에 남아 있으면 결과도 그 방향으로 끌려갑니다. Few-shot은 강력한 만큼, 유지보수가 필요합니다.

Few-shot은 몇 개의 예시가 적당할까

실무에서는 "많을수록 좋다"보다 "대표성이 있느냐"가 더 중요합니다. 보통은 적은 수의 예시로도 충분히 방향을 잡을 수 있습니다. 핵심은 개수가 아니라 구성입니다.

좋은 시작점은 다음과 같습니다.

• 가장 대표적인 정상 사례

• 헷갈리기 쉬운 경계 사례

• 하지 말아야 할 금지 사례 또는 반례

이 세 종류가 들어가면 예시는 훨씬 살아납니다. 대표 사례는 기본기를 가르치고, 경계 사례는 판단 기준을 날카롭게 만들며, 반례는 금지선을 분명하게 보여줍니다. 즉, Few-shot의 목적은 "정답 모음집"을 주는 것이 아니라 판단의 모서리를 세워주는 데 있습니다.

설명과 예시를 함께 써야 더 강해진다

초보 단계에서는 종종 "설명을 자세히 쓰면 예시는 필요 없고, 예시를 넣으면 설명은 필요 없다"고 생각합니다. 하지만 중급에서는 둘을 경쟁 관계로 보지 않습니다. 설명은 원칙을 주고, 예시는 감각을 줍니다. 둘을 함께 써야 더 안정적입니다.

예를 들어 이메일 톤 변환 작업을 생각해봅시다.

Zero-shot 방식은 이렇게 쓸 수 있습니다.

아래 문장을 고객 응대용으로 정중하고 따뜻한 말투로 바꿔줘.
한 문단으로 쓰고, 책임 회피처럼 들리는 표현은 피하고, 해결 의지가 드러나게 작성해줘.

이것만으로도 어느 정도는 됩니다. 하지만 팀이 원하는 말투가 분명하다면 Few-shot을 섞는 편이 좋습니다.

역할: 고객 응대 메일 작성자
목표: 불만 고객에게 정중하고 따뜻하게 답하되, 과도한 약속은 하지 않는다.
제약: 사과 표현은 포함하되 법적 책임을 단정하는 문장은 피한다.

예시 1
입력: 배송이 늦어서 화가 났어요.
출력: 기다리게 해드려 죄송합니다. 현재 배송 상태를 바로 확인해 안내드리겠습니다.

예시 2
입력: 제품이 기대와 달라 실망했습니다.
출력: 기대에 미치지 못해 실망을 드린 점 죄송합니다. 불편하셨던 부분을 확인해 적절한 안내를 도와드리겠습니다.

이제 아래 문장에 답해줘.
입력: 상담원 말이 계속 달라서 신뢰가 안 갑니다.
출력:

여기서 중요한 것은 예시 자체보다 구조입니다. 먼저 역할과 목표, 제약을 설명하고, 그다음 짧은 예시로 톤을 고정합니다. 중급 프롬프트는 설명과 예시가 서로 빈틈을 메우는 구조를 가집니다.

Zero-shot에서 Few-shot으로 넘어가야 하는 신호

실무에서 가장 흔한 문제는 "언제까지 Zero-shot으로 버틸 것인가"입니다. 아래와 같은 신호가 보이면 Few-shot으로 넘어갈 시점입니다.

• 같은 프롬프트인데 결과 톤이 들쭉날쭉하다.

• 형식은 맞는데 판단 기준이 자꾸 흔들린다.

• 애매한 입력이 들어오면 답의 품질이 급격히 떨어진다.

• 팀원이 써도 비슷한 결과가 나오지 않는다.

• '이건 아닌데 왜 아닌지 설명하기 어렵다'는 피드백이 반복된다.

이런 상황은 대개 규칙 설명만으로는 충분하지 않다는 뜻입니다. 모델이 이해하지 못했다기보다, 우리가 기대하는 좋은 답의 모습이 아직 충분히 드러나지 않았다는 의미에 가깝습니다. 이때 Few-shot은 설명을 보충하는 장치가 됩니다.

실무용 판단 순서: 먼저 Zero-shot, 필요하면 Few-shot

중급 실무에서는 보통 다음 순서가 효율적입니다.

1단계: Zero-shot으로 시작한다

먼저 목적, 입력, 출력 형식, 제약 조건을 명확히 적습니다. 이 단계만으로 충분히 안정적인 과업이 적지 않습니다.

2단계: 실패 패턴을 관찰한다

결과가 왜 흔들리는지 봅니다. 형식 문제인지, 분류 기준 문제인지, 톤 문제인지, 누락 문제인지 구분해야 합니다.

3단계: 예시가 필요한 실패인지 판단한다

형식 누락이라면 스키마를 더 분명히 쓰면 해결될 수 있습니다. 하지만 판단 기준이 흔들리는 문제라면 예시가 더 효과적입니다.

4단계: 짧고 대표적인 예시를 넣는다

예시는 많이 넣기보다, 실패를 바로잡는 데 필요한 만큼만 넣습니다. 특히 자주 틀리는 경계 사례를 넣으면 효과가 큽니다.

5단계: 예시가 새로운 문제를 만들지 확인한다

예시를 넣은 뒤 결과가 지나치게 비슷해지거나, 특정 표현만 반복하거나, 예시와 닮은 입력에만 강해지지 않는지 확인해야 합니다.

이 순서를 익히면 프롬프트를 무작정 길게 늘이지 않게 됩니다. 문제의 원인에 따라 지시를 고칠지, 예시를 넣을지 선택할 수 있기 때문입니다.

작은 예시 하나가 큰 차이를 만드는 이유

Few-shot의 힘은 단순한 흉내 내기에만 있지 않습니다. 예시는 모델에게 여러 가지를 한꺼번에 알려줍니다.

• 무엇을 중요하게 봐야 하는지

• 어떤 경계에서 판단해야 하는지

• 어떤 형식과 톤을 유지해야 하는지

• 무엇을 하지 말아야 하는지

즉, 예시는 축약된 규칙집입니다. 잘 만든 예시 하나는 긴 설명문보다 더 많은 힌트를 담을 수 있습니다. 그래서 중급 단계에서는 예시를 "옵션"이 아니라 설계 도구로 보아야 합니다.

다만 설계 도구인 만큼, 예시는 전략적으로 써야 합니다. 모든 프롬프트에 습관처럼 붙이는 것이 아니라, 모델이 특히 헷갈릴 부분을 겨냥해 넣는 것이 중요합니다.

이 장의 핵심 정리

Zero-shot과 Few-shot의 차이는 단순히 예시의 유무가 아닙니다. Zero-shot은 설명으로 일하게 하고, Few-shot은 패턴을 보여주어 일하게 합니다.

요약하면 다음과 같습니다.

• 규칙이 명확하고 형식이 단순한 과업은 Zero-shot으로 충분한 경우가 많다.

• 분류, 평가, 톤 변환, 조직 고유 스타일처럼 기준이 미묘한 과업은 Few-shot이 성능을 안정화한다.

• 예시는 많다고 좋은 것이 아니라, 대표성 있고 일관된 예시가 중요하다.

• 잘못된 예시는 결과를 더 나쁘게 만들 수 있다.

• 실무에서는 Zero-shot으로 시작하고, 실패 패턴이 보일 때 Few-shot으로 확장하는 접근이 효율적이다.

결국 중급 프롬프트 설계의 질문은 이것입니다. "예시를 넣을까?"가 아니라, "이 과업은 설명만으로 충분한가, 아니면 패턴을 보여줘야 하는가?" 이 질문에 답할 수 있게 되면, 프롬프트는 문장이 아니라 재현 가능한 작업 도구로 바뀌기 시작합니다.