하나의 프롬프트에 6개의 Few-Shot 예시를 추가해 보았습니다. 그중 두 개는 결과물을 더 악화시켰습니다.

오랫동안 저는 Few-Shot (퓨샷) 예시를 조미료처럼 취급했습니다. 많을수록 좋다고 생각했죠. 두 개의 예시가 프롬프트를 더 좋게 만든다면, 여섯 개는 아주 훌륭하게 만들 것이라고 믿었고, 그 가정에 대한 수학적 검증은 전혀 신경 쓰지 않았습니다.

지난달, 저는 하나의 분류 (classification) 프롬프트를 두고 예시를 하나씩 추가하며 실제로 측정해 보았습니다. 제가 자랑스럽게 생각하는 여섯 개의 예시가 있었습니다. 그중 네 개는 정확도 (accuracy)를 높였지만, 두 개는 정확도를 떨어뜨렸습니다. 단순히 "노이즈를 추가한 것"도, "영향이 없는 것"도 아니었습니다. 제가 직접 엄선했고 개별적으로 보았을 때는 완벽하게 합리적으로 보였던 두 개의 예시가, 네 개의 예시를 사용했을 때보다 결과물을 9포인트나 더 낮게 끌어내렸습니다.

불편한 사실은 이렇습니다. 개별적으로 보았을 때, 그 나쁜 두 예시는 제가 자랑스럽게 보여주고 싶었을 법한 것들이었습니다. 그것들은 가장 상세했습니다. 바로 그 점 때문에 피해를 입힌 것입니다.

이 글은 어떤 두 개의 예시가 왜 그랬는지, 그리고 제가 이제는 이를 배포하기 전에 어떻게 잡아내는지에 대한 이야기입니다.

제 수치를 적절히 판단하실 수 있도록 설정한 환경

이것은 깔끔한 벤치마크 (benchmark) 논문이 아닙니다. 하나의 작업 (task)을 하나의 모델 (model)에서 실행하고, 제가 직접 만든 60개의 라벨링된 데이터 세트 (labeled set)를 기준으로 점수를 매긴 것입니다. 수치를 절대적인 진리로 받아들이기보다는 방향성을 나타내는 지표로 취급해 주세요.

작업 내용: 들어오는 고객 지원 메시지를 billing, bug, feature_request, account 중 하나의 버킷 (bucket)으로 분류하는 것입니다. 일반 텍스트가 입력되면 하나의 라벨이 출력됩니다. 저는 Hookline이라는 가상의 제품(실제로 존재하지 않음)을 사용하고 있으므로, 실제 프롬프트가 유출될 염려는 없습니다.

프롬프트는 짧은 시스템 지침 (system instruction)과 N개의 Few-Shot (퓨샷) 예시로 구성되며, 각 예시는 메시지와 그에 맞는 올바른 라벨이 쌍을 이룹니다:

당신은 고객 지원 메시지를 정확히 하나의 버킷으로 분류합니다:
billing, bug, feature_request, account.

...

저는 60개의 홀드아웃 (holdout) 데이터 세트에 대해 정확도를 측정했습니다. 동일한 모델, 동일한 온도 (temperature), 동일한 홀드아웃을 사용했으며, 유일하게 변하는 것은 프롬프트에 어떤 예시가 포함되느냐였습니다. 저는 예시를 하나씩 추가했으며, 추가할 때마다 전체 세트를 다시 실행했습니다.

수치

여기 제가 예상했던 곡선과 실제 얻은 곡선이 있습니다.

Examples in prompt	Accuracy	Change from previous
0 (zero-shot)	68%	--
...

The first four examples did what few-shot is supposed to do. Smooth climb, 68 to 84. Then I added two more examples that I thought were my best material, and the line went the wrong way. Six examples scored 9 points below four.

If you wallpaper a room and step back to find you covered the light switch, you know the feeling. I had spent the afternoon making the prompt worse and feeling productive the entire time.

어떤 두 가지였고, 왜 그랬을까요

패턴이 결론보다 더 유용하기 때문에, 어느 것이 실패를 초래했는지 구체적으로 말씀드리겠습니다.

Example 5는 길고 상세한 청구 사례였습니다. 환불 실패, 중복 청구, 그리고 혼란스러운 인보이스에 대한 세 문장짜리 메시지였으며, billing으로 라벨링되었습니다. 합리적인 라벨입니다. 문제는 길이와 위치였습니다. 다른 예시보다 네 배 길었고 프롬프트의 끝 근처에 배치되어 있었습니다.

Example 6는 길고 상세한 버그 리포트였습니다. 스택 트레이스(Stack trace), 재현 단계(repro steps), 브라우저 버전이 포함되었으며, bug로 라벨링되었습니다. 이 역시 고립된 상태에서는 괜찮은 라벨입니다. 다시 말해, 길었고 이제 모델이 실제 메시지를 읽기 직전의 마지막 내용이었습니다.

여기서 두 가지 실패 모드가 겹쳐 발생했으며, 둘 다 이름이 있습니다.

최근성(Recency): 모델은 가장 최근에 본 것을 과대평가한다

LLM은 프롬프트에서 가장 최근에 나타난 라벨 쪽으로 기울어지는 경향이 있습니다. 이것은 제 설정의 결함이 아니라 문서화된 편향입니다:

제 6번 예시는 bug 예시였고, 마지막에 위치했습니다. 이 예시를 추가한 후, 오분류(misroutes)가 bug 쪽으로 치우쳤습니다. 실제로는 account나 feature_request인 메시지들이 bug로 낙인찍히기 시작했는데, 이는 모델의 단기 기억(short-term memory)에서 가장 최근에 나타난 가장 강렬한 정보가 생생한 버그 보고서였기 때문입니다. 예시 자체가 틀린 것이 아니라, 그 위치가 문제였습니다.

분포 변화 (Distribution shift): 예시가 테스트 세트와 닮지 않음

저의 실제 고객 지원 메시지는 짧습니다. 한두 문장 정도이며, 종종 오타가 있고, 대개 스택 트레이스(stack trace)가 없습니다. 반면 예시 5번과 6번은 다듬어진 형태의 여러 문장으로 구성된 잘 정돈된 형식이었습니다. 결과적으로 저는 모델에게 실제 입력값이 어떻게 생겼는지와 일치하지 않는 "입력의 모습"을 보여준 셈입니다.

이 부분이 제가 진심으로 직관에 어긋난다고 느끼는 지점입니다. 제가 추가한 두 예시는 추상적인 관점에서는 _더 높은 품질(higher quality)_을 가졌습니다. 더 완전하고, 더 많은 정보를 담고 있으며, 더 정교했습니다. 하지만 퓨샷 (Few-shot) 예시는 문서화(documentation)가 아니라 입력 분포 (input distribution)의 샘플입니다. 실제 트래픽을 잘못 나타내는 아름다운 예시는 모델에게 잘못된 형태를 가르칩니다. 올바른 것을 찍은 흐릿한 사진이, 잘못된 것을 찍은 선명한 사진보다 낫습니다.

2026년 문헌에서는 이러한 일반적인 현상에 대해 깔끔한 이름을 붙였습니다. 그들은 이를 "퓨샷 딜레마 (few-shot dilemma)"라고 부릅니다. 즉, 성능이 특정 예시 개수에서 정점을 찍은 후 예시를 더 추가할수록 하락하며, 이러한 하락은 단 하나의 모델이 아니라 많은 모델에서 공통적으로 나타납니다 (Zhang et al., 2025). 여기서 얻어야 할 교훈은 "예시를 적게 사용하라"가 아닙니다. 예시의 개수에는 예시가 실제로 무엇을 포함하고 있는지에 따라 결정되는 상한선(ceiling)이 있으며, 그 상한선을 넘어서면 대가를 치르게 된다는 것입니다.

퓨샷 (Few-shot)의 실제 용도

이 실험은 제가 저질러온 범주 오류 (category error)에 대해 솔직해지도록 만들었습니다. 저는 퓨샷 예시를, 그것이 잘 수행하지 못하는 작업에 사용하고 있었습니다.

퓨샷 (Few-shot)은 **형식과 동작 (form and behavior)**을 위한 제어 표면 (control surface)입니다. 즉, 출력 형태, 레이블 어휘 (label vocabulary), 톤, 그리고 모델이 "모르겠습니다"를 처리하는 방식 등을 조절하는 도구입니다. 이는 지식 채널 (knowledge channel)이 아닙니다. 모델이 새로운 사실을 알기를 원한다면, 예시를 제공한다고 해서 그 지식이 주입되지는 않습니다. 그것은 검색 (retrieval)이 담당해야 할 영역이며, 검색조차도 오도된 검색 컨텍스트 (retrieved context)가 모델의 제로샷 (zero-shot) 답변 수준보다 더 낮은 성능을 유발할 수 있는 고유의 실패 모드 (failure mode)를 가지고 있습니다 (Ming et al., 2025).

그래서 저는 이제 다음과 같이 명확한 역할 분담을 머릿속에 새겨둡니다:

작업	적절한 도구	잘못된 도구
출력 형식 / 레이블 세트 수정	퓨샷 (Few-shot)	RAG
...

제 예시 5번과 6번이 실패한 이유는, 그들의 유일한 실제 역할이 메시지에서 레이블로의 매핑 (mapping)을 보여주는 것이었음에도 불구하고, 제가 무의식적으로 그것들을 "정보가 많을수록 좋다"는 식의 지식 주입 (knowledge injection)으로 취급했기 때문입니다. 해당 작업의 경우, 분포 내 (on-distribution)의 짧은 예시 두 개가 분포 외 (off-distribution)의 긴 걸작 하나보다 훨씬 효과적이었습니다.

현재 제가 이를 잡아내는 방법

해결책은 영리한 기교가 아니었습니다. 적절한 입도 (granularity)로 측정하는 것이었습니다. 이를 통해 세 가지 습관이 생겼습니다:

예시를 하나씩 추가하고 다시 점수를 매깁니다. 전체 합계인 "예시 4개, 84%"는 아무것도 숨기지 않았지만, 저는 예시별 차이 (per-example deltas)를 확인했기에 어떤 두 예시가 독이 되었는지 알 수 있었습니다. 만약 여섯 개를 한꺼번에 추가했다면 75%라는 수치를 보고 모델 탓을 하며 대수롭지 않게 넘겼을 것입니다.

예시의 길이와 스타일을 실제 입력값과 일치시킵니다. 예시를 프롬프트에 넣기 전에, 그것이 실제 사용자가 보낼 법한 형태인지 자문합니다. 만약 제 트래픽이 오타가 섞인 한 줄짜리 메시지라면, 제 예시도 오타가 섞인 한 줄짜리 메시지여야 합니다. 다듬어진 예시는 프롬프트가 아니라 문서 (docs)에 들어가야 합니다.

마지막 예시를 특별히 주의 깊게 살핍니다. 최신성 편향 (recency) 때문에 마지막 예시는 추가적인 가중치를 가집니다. 저는 이제 마지막 슬롯이 특정 강한 레이블에 의해 끝부분이 오염되지 않도록, 중립적인 예시를 넣거나 순서를 교체(rotate)하여 배치합니다. 더 깊이 들어가고 싶다면 문맥적 보정 (Contextual calibration)이 엄격한 버전이 될 것이며, 간단한 버전은 그저 가장 극적인 예시를 마지막에 배치하지 않는 것입니다.

이 모든 과정은 저에게 오후 시간 한나절을 소모하게 했고, 자신감에도 약간의 타격을 주었습니다. 하지만 저는 더 이상 "예시를 하나 더 추가하는 것"을 공짜로 얻을 수 있는 수로 취급하지 않습니다. 모든 예시는 하나의 투표이며, 최신성 (recency)은 뒤에 나온 투표의 목소리를 더 크게 만듭니다. 그리고 잘못된 방향을 향하고 있는 두 명의 확신에 찬 투표자가 올바른 방향을 향한 네 명의 투표자보다 더 큰 영향력을 행사할 수 있습니다.

여섯 개의 예시. 네 명의 선량한 시민. 그리고 제가 자랑스럽게 여겼을 법하지만, 조용히 모든 것을 악화시키고 있었던 두 명의 시민.

이 실험은 제 저서인 컨텍스트 엔지니어링 (context engineering)의 한 장을 실제로 구현해 본 버전입니다. 이 책에서 저는 형태 대 지식 (form-versus-knowledge)의 분리에 대해 더 깊이 다루며, 대신 언제 검색 (retrieval)을 활용해야 하는지에 대해 설명합니다. 만약 이러한 역할 분담이 유용하다고 느끼신다면, 전체 내용은 Context Engineering에서 확인하실 수 있습니다.