같은 일을 시키는 프롬프트인데 토큰이 247개짜리와 18개짜리로 나뉜다면, 그 차이가 실제 비용에서 어떻게 드러날지 궁금하지 않았는가. 나는 궁금했고, 직접 실험해봤다. 그 결과가 생각보다 꽤 명확해서, 내가 겪은 시행착오와 함께 프롬프트 토큰 최적화의 실체를 짚어보겠다.
비교 실험: 같은 태스크, 다른 프롬프트
내가 진행한 실험의 태스크는 단순했다. 고객 리뷰 텍스트를 긍정/부정/중립으로 분류하는 것이었다. 여기에 4가지 프롬프트 변형을 만들어 count_tokens API로 사전 측정했다. count_tokens API란 Anthropic이 무료로 제공하는 엔드포인트로, 실제 요청을 보내기 전에 예상 토큰 수를 미리 확인할 수 있는 도구다. 실험 비용 없이 프롬프트 간 토큰 차이를 비교할 수 있어서 최적화 실험에 매우 유용하다. 이 API의 존재를 늦게 알았는데, 일찍 알았다면 많은 실험 비용을 아꼈을 것이다.
네 가지 변형의 결과는 다음과 같았다. 버전 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개와 거의 차이가 없다는 걸 직접 확인했다. 오히려 예시 선택에 더 공을 들이는 게 예시 수를 늘리는 것보다 효과적이었다.
한 가지 비판적 시각을 추가하고 싶다. 이 실험은 감성 분류라는 비교적 명확한 태스크에서의 결과다. 도메인 특화 전문 용어가 많거나 판단 기준이 미묘하게 다른 태스크에서는 결과가 다를 수 있다. 이 수치를 보편적인 진리처럼 적용하면 안 된다. 각자의 태스크로 직접 실험해봐야 한다. 나도 이 실험 결과를 다른 태스크에 그대로 적용했다가 낭패를 본 적이 있다. 복잡한 법률 문서 분류 태스크에서는 예시 3개 이상이 명확히 더 좋은 결과를 냈다.
Few-shot 딜레마: 예시가 많을수록 좋은가
'더 많은 예시 = 더 나은 성능'이라는 통념은 생각보다 자주 깨진다. 감성 분류처럼 비교적 명확한 태스크에서는 예시 1~2개로도 모델이 패턴을 충분히 파악한다. 예시를 쌓을수록 오히려 모델이 특정 예시 패턴에 과도하게 반응해 일반화 성능이 떨어지는 경우도 있었다.
이 현상은 오버피팅과 유사한 맥락으로 볼 수 있다. 오버피팅이란 모델이 학습 데이터에 지나치게 맞춰져 새로운 입력에 유연하게 대응하지 못하는 현상이다. 프롬프트 내 예시도 너무 많아지면 모델이 예시에 얽매여 다양한 입력을 제대로 처리하지 못할 수 있다는 뜻이다. 연구에서도 과도한 도메인 특화 예시가 오히려 일부 모델의 성능을 저하시킬 수 있다고 보고되고 있다.
물론 태스크가 복잡하거나 도메인 특화 표현이 많을 경우에는 예시 수가 늘어날수록 성능이 오르는 경우도 있다. 최적의 예시 수는 태스크와 모델에 따라 다르고, 실험 없이 선험적으로 정하기 어렵다. 그래서 나는 지금도 새로운 태스크를 설계할 때 예시 수를 1개부터 시작해 단계적으로 늘려가며 성능 변화를 직접 측정하는 방식을 쓴다. 예시 개수를 먼저 정하고 들어가는 것보다 데이터 기반으로 결정하는 게 낫다.
Chain-of-Thought 프롬프팅도 비슷한 맥락에서 재검토가 필요하다. CoT란 모델에게 "단계적으로 생각하라"고 지시해 추론 과정을 출력하게 만드는 기법이다. 단순한 분류 태스크에서 CoT 지시를 추가했더니 출력 토큰이 수십 개 늘었지만 정확도는 거의 변화가 없었다. Reasoning 모델처럼 내부 추론이 이미 포함된 경우에는 명시적 CoT 지시가 오히려 토큰 낭비가 될 수 있다고 생각한다. 물론 복잡한 다단계 추론이 필요한 태스크에서 CoT는 여전히 강력하다. 어디서 쓰고 어디서 빼는지를 구분하는 것이 핵심이다.
비용 절감: 출력 형식 제어의 위력
입력 토큰보다 출력 토큰에서 더 큰 절감 효과가 나는 경우가 많다. 직접 써봤는데, 분류 결과에 설명을 함께 출력하도록 했을 때와 레이블만 출력하도록 했을 때의 평균 출력 토큰이 각각 89개와 3개였다. 약 30배 차이다.
이 실험 이후 배치 분류 파이프라인에서 출력 포맷을 설명 포함 JSON에서 단순 레이블로 변경했고, 그 결과 출력 토큰 비용이 월 약 280달러 줄었다. 배치 처리란 대량의 입력을 일괄적으로 처리하는 방식으로, 실시간 응답이 필요 없는 분류나 분석 업무에서 주로 쓴다. 규모가 클수록 포맷 변경 한 번의 효과가 엄청나게 커진다.
잘 최적화된 프롬프트는 단순 구현 대비 40~70%의 토큰 절감이 가능하고, 출력 포맷 최적화까지 포함하면 총 절감 효과는 50~80%에 이른다는 분석도 있다. 월 1만 달러를 LLM API에 지출하는 팀이라면 5,000~8,000달러의 월 절감을 의미한다. 숫자로 보면 결코 작지 않다.
다만 출력을 지나치게 압축하면 다른 문제가 생긴다. 레이블만 돌려받으면 왜 그렇게 분류했는지 검증하기가 어렵다. 파이프라인 디버깅이나 품질 관리 측면에서 설명을 전혀 없애면 나중에 오분류를 추적하는 데 훨씬 많은 비용이 들 수 있다. 비용 절감과 운영 투명성 사이의 균형을 잘 잡아야 한다. 나는 프로덕션에서는 레이블만 출력하되, 샘플링된 소수의 요청에는 설명도 함께 받아 주기적으로 품질을 확인하는 방식을 쓴다. 이 방식이 비용도 지키면서 품질 감시도 유지하는 현실적인 타협점이었다.
프롬프트 캐싱과 역할 분리 전략
내가 실험하면서 가장 효과적이라고 느낀 전략 중 하나는 시스템 프롬프트와 유저 프롬프트의 역할 분리다. 태스크 지시, Few-shot 예시, 출력 형식 규칙을 모두 시스템 프롬프트에 몰아두고, 유저 메시지에는 순수한 입력 텍스트만 넣는 방식이다.
이것이 효과적인 이유는 프롬프트 캐싱 때문이다. 프롬프트 캐싱이란 동일한 시스템 프롬프트가 반복 사용될 때 처리 비용을 대폭 줄여주는 기능으로, Anthropic의 경우 캐시된 토큰은 일반 가격의 약 10%로 과금된다. 시스템 프롬프트가 캐시되면 요청마다 토큰 비용이 누적 절감되는 구조다. 단, 캐시가 제대로 활용되려면 시스템 프롬프트가 자주 바뀌지 않아야 한다. A/B 테스트 중에 시스템 프롬프트를 자주 변경하면 캐시 효과가 사라진다. 이 부분을 처음에 간과했다가 예상보다 캐시 히트율이 낮게 나온 경험이 있다. A/B 테스트 중에는 캐싱 효과가 기대보다 훨씬 낮게 나온다는 것을 미리 알았다면 다르게 설계했을 것이다.
토큰 최적화 전략을 정리하면 다음과 같다. 출력 포맷을 가장 먼저 검토해야 한다. 설명 없이 레이블만 출력하면 출력 토큰이 수십 배 줄 수 있다. 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/