언제 어떤 few-shot을 쓸 것인가
few-shot은 강력하지만 항상 정답은 아니다. 아키텍트는 예시를 추가하기 전에 더 단순하거나 더 확실한 수단이 있는지 먼저 판단해야 한다. 이 절은 의사결정 순서를 다룬다.
첫 번째 질문은 "zero-shot으로 충분한가"이다. claude-opus-4-8은 지시를 매우 충실히 따르므로, 명확한 시스템 프롬프트 한 문장으로 해결되는 작업에 예시를 끼워 넣을 필요가 없다. 예시는 토큰 비용과 지연을 늘리고, 잘못 고른 예시는 모델을 그 예시 분포에 가두어 일반화를 막는다. 그래서 "zero-shot 먼저, 부족할 때 few-shot"이 기본 순서다.
두 번째 질문은 "예시가 무엇을 고정해야 하는가"이다. few-shot이 잘 맞는 경우는 말로 설명하기 어려운 출력 스타일·말투·서식, 또는 까다로운 경계 사례를 보여 줄 때다. 반대로 단순히 라벨 집합만 정해 주면 되는 분류는 예시 두세 개로 충분하고, 그 이상은 효과가 미미하다.
세 번째 질문이 가장 중요하다. "형식을 반드시 보장해야 하는가." 예시는 출력을 유도(shape)할 뿐 강제(enforce)하지 못한다. 예시를 아무리 쌓아도 모델이 가끔 다른 형식으로 답할 수 있다. JSON 스키마나 고정 라벨을 무조건 보장해야 한다면 예시 누적이 아니라 구조화 출력(output_config.format)이나 strict 도구 사용이 정답이다.
# enforce_schema.pyresponse = client.messages.create( model="claude-opus-4-8", max_tokens=1024, output_config={ "format": { "type": "json_schema", "schema": { "type": "object", "properties": {"sentiment": {"type": "string"}, "score": {"type": "number"}}, "required": ["sentiment", "score"], "additionalProperties": False, } } }, messages=[{"role": "user", "content": "리뷰: 가격은 적당하네요"}],)정리하면 few-shot은 스타일·뉘앙스를 가르치는 데 강하고, 구조화 출력은 형식을 보장하는 데 강하다. 둘은 함께 쓸 수도 있다. 예시로 판단 기준을 보여 주면서 동시에 output_config.format으로 출력 형식을 못 박는 식이다.
네 번째 질문은 운영 차원이다. "이 예시 블록이 크고 반복되는가." 그렇다면 14-01의 캐싱 패턴을 적용해 공유 예시 prefix를 캐시하고, 가변 질문만 그 뒤에 둔다. 예시가 매번 달라진다면 캐시 이득이 없으니 차라리 예시를 줄이거나 zero-shot으로 되돌아간다.
네 가지 질문을 순서대로 적용하면 다음 결정 흐름이 된다.
시험은 이 절을 시나리오 선택형으로 묻는다. "모든 응답이 유효한 JSON이어야 한다"는 요구에는 few-shot 예시를 더 넣는 보기가 아니라 구조화 출력을 고르는 것이 정답이고, "응답 말투를 회사 브랜드 톤에 맞춰라"는 요구에는 few-shot 예시가 정답이다. 또한 capable 모델에서 예시를 무작정 늘리는 보기는 함정 오답으로 자주 등장한다 — 개수보다 품질, 보장이 필요하면 구조화 출력이라는 두 원칙을 기억한다.
정리
- 의사결정 순서는 zero-shot 우선 → 스타일·경계 사례에만 few-shot → 형식 보장이 필요하면 구조화 출력·strict 도구 → 큰 반복 블록이면 캐싱이다.
- few-shot은 출력을 유도(shape)하고, 구조화 출력은 형식을 강제(enforce)한다 — 보장이 필요하면 예시 누적이 아니라
output_config.format이다. - few-shot과 구조화 출력은 병행 가능하다. 예시로 판단을 가르치고 format으로 형식을 고정한다.
- claude-opus-4-8 같은 capable 모델은 예시가 적어도 잘 따르며, 과도한 예시는 일반화를 해친다.
- 시험은 "JSON 보장 → 구조화 출력", "말투·뉘앙스 → few-shot"의 시나리오 매칭과 예시 남발 함정을 묻는다.