같은 일을 시키는 프롬프트인데 토큰이 247개짜리와 18개짜리로 나뉜다면, 그 차이가 실제 비용에서 어떻게 드러날지 궁금하지 않으셨습니까. 저는 궁금했고, 직접 실험해봤습니다. 그 결과가 생각보다 꽤 명확해서, 오늘은 제가 겪은 시행착오와 함께 프롬프트 토큰 최적화의 실체를 짚어보겠습니다.
비교 실험: 같은 태스크, 다른 프롬프트
제가 진행한 실험의 태스크는 단순했습니다. 고객 리뷰 텍스트를 긍정/부정/중립으로 분류하는 것이었습니다. 여기에 4가지 프롬프트 변형을 만들어 count_tokens API로 사전 측정했습니다. count_tokens API란 Anthropic이 무료로 제공하는 엔드포인트로, 실제 요청을 보내기 전에 예상 토큰 수를 미리 확인할 수 있는 도구입니다. 실험 비용 없이 프롬프트 간 토큰 차이를 비교할 수 있어서 최적화 실험에 매우 유용합니다.
네 가지 변형의 결과는 다음과 같았습니다.
- 버전 A (장황한 설명형): 247토큰 / 정확도 82%
- 버전 B (간결한 지시형): 18토큰 / 정확도 79%
- 버전 C (Few-shot 3개 예시 포함): 183토큰 / 정확도 88%
- 버전 D (Few-shot 1개 예시 + 간결 지시): 67토큰 / 정확도 87%
솔직히 이건 예상 밖이었습니다. 버전 D가 버전 C 대비 토큰은 63% 더 적으면서 정확도 차이는 1%에 불과했습니다. Few-shot이란 모델에게 소수의 입출력 예시를 보여줘 태스크 패턴을 학습시키는 방식입니다. 예시가 많을수록 성능이 오른다고 생각하는 분들도 있는데, 저는 1개만 넣어도 3개와 거의 차이가 없다는 걸 직접 확인했습니다. 연구에서도 과도한 도메인 특화 예시가 오히려 일부 모델의 성능을 저하시킬 수 있다고 보고되고 있습니다(출처: arXiv 논문 - The Few-shot Dilemma).
Few-shot 딜레마: 예시가 많을수록 좋은가
'더 많은 예시 = 더 나은 성능'이라는 통념은 생각보다 자주 깨집니다. 제 경험상 이건 좀 다릅니다. 감성 분류처럼 비교적 명확한 태스크에서는 예시 1~2개로도 모델이 패턴을 충분히 파악합니다. 예시를 쌓을수록 오히려 모델이 특정 예시 패턴에 과도하게 반응해 일반화 성능이 떨어지는 경우도 있었습니다.
이 현상은 오버피팅(overfitting)과 유사한 맥락으로 볼 수 있습니다. 오버피팅이란 모델이 학습 데이터에 지나치게 맞춰져 새로운 입력에 유연하게 대응하지 못하는 현상입니다. 프롬프트 내 예시도 너무 많아지면 모델이 예시에 얽매여 다양한 입력을 제대로 처리하지 못할 수 있다는 뜻입니다.
물론 태스크가 복잡하거나 도메인 특화 표현이 많을 경우에는 예시 수가 늘어날수록 성능이 오르는 경우도 있습니다. 최적의 예시 수는 태스크와 모델에 따라 다르고, 실험 없이 선험적으로 정하기 어렵습니다. 그래서 저는 지금도 새로운 태스크를 설계할 때 예시 수를 1개부터 시작해 단계적으로 늘려가며 성능 변화를 직접 측정하는 방식을 씁니다.
Chain-of-Thought(CoT) 프롬프팅도 비슷한 맥락에서 재검토가 필요합니다. CoT란 모델에게 "단계적으로 생각하라"고 지시해 추론 과정을 출력하게 만드는 기법입니다. 단순한 분류 태스크에서 CoT 지시를 추가했더니 출력 토큰이 수십 개 늘었지만 정확도는 거의 변화가 없었습니다. Reasoning 모델처럼 내부 추론이 이미 포함된 경우에는 명시적 CoT 지시가 오히려 토큰 낭비가 될 수 있다고 생각합니다.
비용 절감: 출력 형식 제어의 위력
입력 토큰보다 출력 토큰에서 더 큰 절감 효과가 나는 경우가 많습니다. 제가 직접 써봤는데, 분류 결과에 설명을 함께 출력하도록 했을 때와 레이블만 출력하도록 했을 때의 평균 출력 토큰이 각각 89개와 3개였습니다. 약 30배 차이입니다.
이 실험 이후 저희 서비스의 배치 분류 파이프라인에서 출력 포맷을 JSON with 설명에서 단순 레이블로 변경했고, 그 결과 출력 토큰 비용이 월 약 280달러 줄었습니다. 배치 처리란 대량의 입력을 일괄적으로 처리하는 방식으로, 실시간 응답이 필요 없는 분류·분석 업무에서 주로 씁니다. 규모가 클수록 포맷 변경 한 번의 효과가 엄청나게 커집니다.
잘 최적화된 프롬프트는 단순 구현 대비 40
70%의 토큰 절감이 가능하고, 출력 포맷 최적화까지 포함하면 총 절감 효과는 50
80%에 이른다는 분석도 있습니다(출처: Redis 블로그 - LLM Token Optimization). 월 1만 달러를 LLM API에 지출하는 팀이라면 이것은 5,000~8,000달러의 월 절감을 의미합니다. 숫자로 보면 결코 작지 않습니다.
프롬프트 캐싱과 역할 분리 전략
제가 실험하면서 가장 효과적이라고 느낀 전략 중 하나는 시스템 프롬프트와 유저 프롬프트의 역할 분리입니다. 태스크 지시, Few-shot 예시, 출력 형식 규칙을 모두 시스템 프롬프트에 몰아두고, 유저 메시지에는 순수한 입력 텍스트만 넣는 방식입니다.
이것이 효과적인 이유는 프롬프트 캐싱(prompt caching) 때문입니다. 프롬프트 캐싱이란 동일한 시스템 프롬프트가 반복 사용될 때 처리 비용을 대폭 줄여주는 기능으로, Anthropic의 경우 캐시된 토큰은 일반 가격의 약 10%로 과금됩니다. 시스템 프롬프트가 캐시되면 요청마다 토큰 비용이 누적 절감되는 구조입니다.
토큰 최적화 전략을 정리하면 다음과 같습니다.
- 출력 포맷을 가장 먼저 검토한다. 설명 없이 레이블만 출력하면 출력 토큰이 수십 배 줄 수 있습니다.
- Few-shot 예시는 1개부터 시작해 필요할 때만 늘린다. 무조건 많다고 좋지 않습니다.
- 태스크 지시는 시스템 프롬프트에 집중시켜 캐싱 효율을 높인다.
- Reasoning 모델에서는 명시적 CoT 지시를 생략하거나 최소화한다.
- count_tokens API로 사전에 변형 간 토큰 수를 측정하고 실험한다.
토큰 최소화를 목표로 삼는 것 자체가 함정이 될 수 있다는 점도 짚어둡니다. 복잡한 추론 태스크에서 구조화된 지시를 줄이면 실패율이 오르고, 재시도 비용까지 더해지면 오히려 더 비싸질 수 있습니다. 진짜 목표는 '단위 비용당 최대 성능'입니다.
프롬프트 토큰 최적화는 한 번 실험으로 끝나는 일이 아닙니다. 모델이 업데이트되고, 입력 패턴이 바뀌고, 태스크가 다양해지면 최적 프롬프트도 달라집니다. 버전 관리와 지속적인 A/B 테스트 체계를 갖추지 않으면 한 번의 실험 결과에 과도하게 의존하는 위험이 생깁니다. 지금 쓰는 프롬프트가 3개월 전에 최적화된 버전이라면, 지금도 최적이라는 보장은 없습니다. 일단 count_tokens API로 현재 프롬프트의 토큰 수부터 측정해보시는 것을 권합니다.
참고:
- Anthropic Token Counting API: https://platform.claude.com/docs/en/build-with-claude/token-counting
- Optimizing Prompts to Reduce Token Usage (InventiveHQ, 2026): https://inventivehq.com/blog/optimize-prompts-reduce-token-costs
- The Few-shot Dilemma: Over-prompting LLMs (arXiv, 2025): https://arxiv.org/pdf/2509.13196
- LLM Token Optimization (Redis Blog, 2026): https://redis.io/blog/llm-token-optimization-speed-up-apps/