결론부터 말씀드리면, LLM 프롬프트에 few-shot 예시를 넣을수록 느려지는 이유는 간단합니다. 예시 하나하나가 모델이 실제로 읽어야 하는 입력 토큰으로 그대로 쌓이기 때문입니다. 예시를 넣을수록 형식 준수율과 답변 일관성은 좋아지지만, 그만큼 입력 시퀀스가 길어지면서 처리 시간과 비용이 함께 늘어납니다.
이 글은 OpenAI Chat Completions API(gpt-4, gpt-3.5-turbo 계열, cl100k_base 토크나이저 기준)와 Anthropic Claude API의 프롬프트 캐싱 기능을 기준으로 설명합니다. gpt-4o처럼 o200k_base 인코딩을 쓰는 모델은 토큰 수 계산 결과가 다를 수 있다는 점을 먼저 밝힙니다.
few-shot 예시가 프롬프트 토큰 수를 그대로 늘리는 구조
대부분의 LLM API는 입력(input) 토큰과 출력(output) 토큰을 나눠서 과금합니다. few-shot 예시로 넣는 질문-정답 쌍은 시스템 프롬프트나 사용자 메시지 안에 그대로 얹혀서 전송되기 때문에, 예시 텍스트 전부가 입력 토큰으로 계산됩니다.
여기서 헷갈리기 쉬운 부분이 토큰과 글자 수의 차이입니다. 영어는 단어 하나가 대체로 토큰 1~2개로 쪼개지지만, 한글은 BPE 기반 토크나이저(cl100k_base 등)가 완성형 음절 단위로 최적화되어 있지 않아서 같은 의미를 담은 문장이라도 영어보다 토큰 소모가 많은 편입니다. 즉 예시를 한글로 작성할 경우, 같은 글자 수라도 영어 예시보다 비용에 미치는 영향이 더 클 수 있습니다.
예시를 2개 넣으면 입력 토큰이 2배가 아니라 “지시문 + 예시 2개 분량”만큼 늘어나고, 예시를 10개 넣으면 지시문 비중은 상대적으로 작아지고 예시 텍스트가 프롬프트의 대부분을 차지하게 됩니다. 이 누적 구조를 이해하지 못하면 “예시 몇 개 추가했을 뿐인데 왜 이렇게 비싸지지”라는 질문에 답하기 어렵습니다.
예시를 넣을수록 느려지는 이유는 시퀀스 길이 증가에 있습니다
트랜스포머 기반 모델은 입력을 받으면 먼저 프리필(prefill) 단계에서 전체 입력 토큰을 한 번에 처리합니다. 이 단계의 핵심 연산이 셀프어텐션이고, 이 연산은 시퀀스 안의 모든 토큰이 서로를 참조하는 구조라서 입력 길이가 늘어날수록 계산량이 더 가파르게 커집니다.
프리필이 끝나면 모델은 한 토큰씩 답을 생성하는 디코딩 단계로 넘어가는데, 이때도 이미 처리한 입력 토큰들의 키/값(KV) 캐시를 매 스텝마다 조회해야 합니다. 입력이 길수록 조회할 대상이 많아지므로, 답변을 다 뽑는 데 걸리는 시간도 조금씩이지만 함께 늘어납니다.
정리하면 few-shot 예시를 넣을수록 느려지는 지점은 두 군데입니다. 첫 토큰이 나오기까지의 시간(프리필)이 늘어나는 것과, 답변을 생성하는 동안의 스텝별 처리 시간이 미세하게 늘어나는 것입니다. 짧은 답변을 받는 API라면 전자의 영향이 체감상 더 크게 느껴지는 경우가 많습니다.
예시 몇 개부터 느려짐이 체감될까요?
기준 프롬프트가 원래 짧았는지, 아니면 이미 RAG로 수천 토큰짜리 문서를 붙이고 있었는지에 따라 답이 달라집니다. 지시문만 100토큰 안팎이던 프롬프트에 예시 3개(대략 300~500토큰 추가)를 붙이면 전체 길이가 4~5배로 뛰지만, 이미 3,000토큰짜리 컨텍스트를 쓰고 있었다면 예시 몇 개를 더 넣는 비율 자체는 크지 않습니다.
여기서 짚어야 할 트레이드오프가 있습니다. 예시를 늘린다고 정확도가 계속 좋아지는 것은 아닙니다. 예시 품질이 들쭉날쭉하거나 예시끼리 형식이 미묘하게 다르면, 예시를 추가할수록 오히려 모델이 어떤 패턴을 따라야 할지 헷갈려서 출력이 불안정해지는 경우도 있습니다. 이럴 때는 비용과 지연만 늘고 품질 개선은 없는, 순수한 손해 구간에 들어갑니다.
| 구성 | 입력 토큰 배율(대략) | 첫 토큰까지 지연 | 정확도 경향 | 비용 영향 |
|---|---|---|---|---|
| zero-shot | 1배(기준) | 가장 짧음 | 형식·톤이 불안정할 수 있음 | 가장 낮음 |
| few-shot 2~3개 | 약 2~4배 | 소폭 증가 | 형식 준수율 상승, 답변 일관성 개선 | 입력 토큰에 비례해 증가 |
| few-shot 8개 이상(many-shot) | 약 6배 이상 | 눈에 띄게 증가 | 개선 폭이 둔화되고 예시 배치 순서에 흔들릴 수 있음 | 반복 호출 시 누적 비용이 큼 |
직접 토큰 수를 재보고 손익을 계산해 보세요
감으로 판단하지 말고 실제 토큰 수를 재보는 편이 정확합니다. OpenAI 계열 모델에 쓰이는 tiktoken 라이브러리로 zero-shot 프롬프트와 few-shot 프롬프트의 토큰 수를 직접 비교할 수 있습니다.
import tiktoken
encoding = tiktoken.get_encoding("cl100k_base")
zero_shot_prompt = """다음 문장의 감정을 긍정/부정/중립 중 하나로 분류하세요.
문장: "배송이 빨라서 좋았어요."
분류:"""
few_shot_prompt = """다음 문장의 감정을 긍정/부정/중립 중 하나로 분류하세요.
문장: "다시는 안 살 것 같아요."
분류: 부정
문장: "그냥 그랬어요, 나쁘지 않았어요."
분류: 중립
문장: "포장이 꼼꼼해서 만족스러웠어요."
분류: 긍정
문장: "배송이 빨라서 좋았어요."
분류:"""
print("zero-shot 토큰 수:", len(encoding.encode(zero_shot_prompt)))
print("few-shot(3개) 토큰 수:", len(encoding.encode(few_shot_prompt)))
이 코드를 그대로 실행하면 두 프롬프트의 토큰 수가 정수로 출력됩니다. 예시 문장의 길이에 따라 구체적인 숫자는 달라지지만, 예시 3개를 추가한 프롬프트가 zero-shot 대비 눈에 띄게 늘어나는 것을 직접 확인할 수 있습니다. 이 값에 사용 중인 모델의 입력 토큰 단가를 곱하면, 예시를 추가함으로써 호출 1회당 실제로 얼마가 더 드는지 바로 계산됩니다. 여기에 예상 호출 빈도를 곱하면 예시를 유지할지 줄일지 판단할 손익 기준이 나옵니다.
캐싱을 적용했는데 왜 여전히 느린가요?
Anthropic Claude API는 프롬프트의 앞부분을 캐싱해 두는 기능을 제공합니다. few-shot 예시는 호출마다 동일한 텍스트인 경우가 많아서 캐싱에 딱 맞는 대상입니다. 예시 부분을 캐시로 저장해두면 같은 프리픽스를 다시 계산하지 않아도 되므로 비용을 줄일 수 있습니다.
다만 캐싱이 적용되는 범위는 정확히 일치하는 프리픽스, 즉 예시 텍스트와 그 앞의 지시문까지입니다. 예시 뒤에 붙는 실제 사용자 질문은 매번 바뀌므로 이 부분은 캐시 대상이 아니고, 여전히 새로 처리해야 합니다. 또한 캐싱은 입력을 다시 읽는 과정(프리필)의 부담을 줄여주는 것이지, 답을 한 토큰씩 뽑아내는 디코딩 속도 자체를 빠르게 만들어주지는 않습니다.
그래서 캐싱을 켠 뒤에도 “여전히 느리다”고 느껴지는 경우가 생깁니다. 캐시는 비용 절감에는 확실히 도움이 되지만, 체감 응답 완료 시간은 예시를 아예 없앴을 때만큼 줄어들지 않을 수 있습니다. 캐시 유효 시간이 지나거나 예시 문구를 한 글자라도 바꾸면 캐시가 무효화되어 다음 호출부터 다시 전액 계산된다는 점도 함께 감안해야 합니다.
예시 개수는 품질 목표와 호출 빈도로 정하면 됩니다
LLM 프롬프트에 few-shot 예시를 넣을수록 느려지는 것은 예시 텍스트가 그대로 입력 토큰으로 쌓여 프리필 시간과 디코딩 스텝 비용을 함께 늘리기 때문입니다. 호출 빈도가 낮고 정확도가 무엇보다 중요한 작업이라면 예시를 넉넉히 넣는 편이 남는 장사이고, 호출 빈도가 높은 프로덕션 API라면 예시를 2~3개로 최소화하거나 캐싱 가능한 구조로 고정해두는 편이 유리합니다.
다음 단계로는 지금 쓰고 있는 프롬프트를 tiktoken으로 실제 토큰 수를 재보고, 예시를 하나씩 줄이거나 늘려가며 출력 품질이 어느 지점부터 나빠지는지 직접 A/B로 확인해 보시길 권합니다. 그 지점이 바로 이번 작업에서 가장 남는 예시 개수입니다.
