토큰 낭비는 새로운 기술 부채입니다: LLM 비용 80%를 절감하는 실전 최적화 전략

단순히 싼 모델을 찾는 게 아니라, 작업별 최적 모델 매칭과 프롬프트 압축으로 품질 저하 없이 비용을 걷어내는 법을 다룹니다.

단순한 RAG 파이프라인과 에이전트 워크플로우를 운영하던 사이드 프로젝트가 하나 있었어요. 큰 기대 없이 돌렸는데, 어느 날 청구서를 보니 월 비용이 $847.32라는 숫자로 찍혀 있더라고요. 정말 당혹스러웠죠. 이미지 생성이나 파인튜닝 같은 무거운 작업을 한 것도 아니었는데, 대체 어디서 이렇게 토큰이 샜는지 도무지 알 길이 없었습니다 [1].

여기서 제가 깨달은 게 하나 있어요. LLM 비용 최적화의 핵심은 무조건 싼 모델을 찾는 게 아니라는 겁니다. 작업의 복잡도에 맞춰 모델을 적절히 배분하는 ‘라우팅’과, 불필요한 토큰을 걷어내는 ‘프롬프트 다이어트’를 결합하는 것이 진짜 정답이에요.

보이지 않는 지출: 토큰 비용이 폭발하는 4가지 지점

최적화를 시작하기 전에 가장 먼저 해야 할 일은 ‘어디서 돈이 새는지’를 정확히 보는 거예요. 측정하지 않으면 최적화는 그냥 추측일 뿐이거든요. 사실 많은 팀이 기능별, 사용자별 비용 추적 없이 그냥 전체 청구서 숫자만 보고 놀라곤 합니다.

“The terrifying part isn’t the spend itself. It’s the complete absence of visibility.”

(정말 무서운 건 지출 금액 그 자체가 아니라, 어디에 쓰이는지 전혀 보이지 않는다는 점입니다.) [1]

제가 분석해 보니 토큰 비용이 폭발하는 지점은 크게 네 가지로 나뉘더라고요 [2].

첫째는 무분별한 재시도(Retries)입니다. 도구 호출(Tool call)이 실패하거나 타임아웃이 났을 때, 시스템이 자동으로 계속 재시도하면서 토큰을 갉아먹는 경우죠. 예를 들어, API 응답 형식이 잘못되어 파싱 에러가 났을 때 지수 백오프(Exponential Backoff) 전략 없이 즉시 재시도하면 순식간에 수천 개의 토큰이 낭비됩니다.

둘째는 과도한 컨텍스트예요. RAG 파이프라인에서 답변에 필요 없는 문서까지 너무 많이 가져와서 프롬프트에 때려 넣는 상황입니다. 검색 결과 상위 10개를 무조건 넣기보다, 리랭커(Reranker)를 도입해 정말 관련 있는 상위 3개만 추려 넣는 것만으로도 입력 토큰을 획기적으로 줄일 수 있습니다.

셋째는 장황한 응답입니다. max_tokens 설정을 안 했거나 출력 형식을 지정하지 않으면, 모델이 불필요하게 말을 길게 늘어뜨리며 출력 토큰 비용을 높입니다. “단계별로 생각해서 자세히 설명해줘”라는 지시는 추론 성능을 높이지만, 단순 추출 작업에서는 독이 됩니다.

마지막으로 오버스펙 모델 사용이에요. 단순한 감성 분석이나 분류 작업 같은 가벼운 일에 굳이 최고 성능의 프론티어 모델을 쓰는 거죠. 이는 마치 편의점에 가는데 덤프트럭을 모는 것과 같습니다.

프롬프트 다이어트: 80% 비용 절감을 위한 압축 기술

프롬프트를 짤 때 우리는 보통 “확실하게 시키려고” 같은 말을 여러 번 반복하거나, 아주 상세한 배경 설명을 넣는 습관이 있어요. 하지만 모델 입장에서는 이게 오히려 노이즈가 될 수 있고, 무엇보다 돈이 됩니다.

놀라운 건, 프롬프트를 2~3배 정도 가볍게 압축하는 것만으로도 정확도 하락은 5% 미만으로 유지하면서 비용을 80%까지 줄일 수 있다는 점이에요 [1]. 제가 추천하는 ‘다이어트’ 포인트는 이렇습니다.

• 중복 제약 조건 제거: “간결하게 답해줘”, “짧게 써줘”, “군더더기 없이 말해줘”라고 여러 번 강조하는 대신 “답변은 한 문장으로 제한함”과 같이 한 번만 명확히 지시하세요.
• 불필요한 배경 설명 삭제: 모델이 작업을 수행하는 데 굳이 몰라도 되는 장황한 서술은 과감히 쳐내세요. “우리는 현재 글로벌 시장 진출을 위해 다양한 전략을 수립 중인 팀이며…” 같은 서술보다는 “목표: 글로벌 시장 진출 전략 수립”이라고 핵심만 적는 것이 효율적입니다.
• 엣지 케이스 예시 정리: 실제 프로덕션에서 거의 발생하지 않는 희귀한 사례들을 예시(Few-shot)로 너무 많이 넣고 있지는 않은지 확인해 보세요. 대표적인 사례 2~3개면 충분합니다.
• 페르소나 다이어트: 기술적인 데이터 추출 작업인데 “너는 20년 경력의 친절하고 세심한 전문가야” 같은 성격 설정이 꼭 필요한지 생각해보세요. “역할: JSON 데이터 추출기” 정도로 충분합니다.

특히 JSON 같은 반구조화된 포맷을 쓰면 토큰 수도 줄어들고 모델의 해석 신뢰도까지 높아지는 효과가 있습니다 [3].

# 나쁜 예: 장황한 자연어 지시문
# "너는 아주 유능한 분석가야. 아래 텍스트를 읽고 가격, 특징, 평점을 추출해줘. 
# 아주 정확하게 해야 하며, 절대 빼먹지 말고, 친절하게 JSON 형태로 출력해줘."

# 좋은 예: 압축된 구조화 프롬프트
# 아래와 같이 핵심 태스크와 제약 조건만 명시합니다.
instruction: "Extract entities from text"
format: "JSON"
fields: ["price", "features", "rating"] # 추출할 필드만 명확히 정의
constraints: ["Strictly JSON", "No conversational filler"] # 불필요한 수식어 제거

이런 식으로 프롬프트를 구조화하면 모델이 헤매지 않고 정확히 필요한 값만 내뱉게 되어 입력과 출력 토큰 모두를 아낄 수 있습니다.

지능적 라우팅: 모델 매칭과 캐스케이딩 전략

모든 요청에 GPT-4o나 Claude 3.5 같은 최고 사양 모델을 쓰는 건 매우 비효율적입니다. 작업의 난이도에 따라 모델을 매칭하는 ‘판단력’이 필요합니다.

가장 기본은 정적 라우팅(Static Routing)이에요. 단순 분류나 요약은 저렴한 모델(Budget Model, 예: GPT-4o-mini)에게, 복잡한 논리 추론이나 코딩은 프론티어 모델에게 보내는 거죠. 이를 구현하기 위해 요청의 키워드나 의도(Intent)를 먼저 파악하는 가벼운 분류기를 앞에 두는 방식을 많이 사용합니다.

여기서 한 단계 더 나아가면 캐스케이딩(Cascading) 기법을 쓸 수 있습니다. 캐스케이딩은 먼저 저렴한 모델에게 답을 시켜보고, 그 답의 신뢰도(Confidence score)를 측정하는 방식이에요.

1. 1단계: 저렴한 모델이 답변 생성 및 자체 신뢰도 점수 부여. 2. 2단계: 신뢰도가 임계값(예: 0.8) 미만인 경우에만 상위 모델로 요청을 전달. 3. 3단계: 최종 답변을 사용자에게 제공.

실제로 FrugalGPT 논문에서는 이 방식을 통해 최고 성능 모델의 정확도를 유지하면서 비용을 최대 98%까지 절감했다고 합니다 [2].

물론 처음부터 복잡하게 갈 필요는 없어요. 일단 어떤 작업에 정말로 고성능 모델이 필요한지 판단하는 기준을 세우고, 정적 라우팅부터 시작해서 점진적으로 고도화하는 것을 추천합니다 [1].

짚고 넘어갈 한계와 안티패턴

비용을 줄이는 게 좋긴 하지만, 너무 공격적으로 최적화하다 보면 ‘품질’이라는 소중한 가치를 잃을 수 있습니다. 제가 겪어보니 주의해야 할 함정들이 있더라고요.

우선 프롬프트를 너무 심하게 압축하면 모델이 문맥의 미묘한 뉘앙스를 놓치는 경우가 생깁니다 [4]. 특히 대화형 컨텍스트에 최적화된 모델들은 자체적으로 히스토리를 관리하는 기능이 있어서, 사람이 억지로 압축한 프롬프트가 오히려 모델의 추론 흐름을 방해하는 독이 될 때가 있어요 [4].

또한, 캐스케이딩 전략은 비용은 획기적으로 줄여주지만 시스템 복잡도를 높입니다. 신뢰도를 측정하는 단계가 추가되니 응답 지연 시간(Tail Latency)이 늘어날 수밖에 없죠 [2]. 만약 신뢰도 임계값을 잘못 설정하면, 엉뚱한 답이 사용자에게 그대로 전달되거나 반대로 모든 요청이 상위 모델로 넘어가 비용 절감 효과가 사라지는 불상사가 생길 수 있습니다.

핵심 요약

• 측정할 수 없다면 최적화할 수 없다. Langfuse나 LangSmith 같은 도구로 기능별 토큰 추적부터 시작하세요.
• 프롬프트 압축 2~3배만으로도 정확도 손실 거의 없이 비용 80% 절감이 가능합니다.
• 모든 곳에 최고 사양 모델을 쓸 필요는 없습니다. 작업별 ‘모델 매칭’과 라우팅이 핵심입니다.
• 비용 절감은 일회성 이벤트가 아니라, 지속적인 FinOps 프로세스로 관리해야 합니다 [2].

처음에는 단순히 청구서의 숫자를 줄이는 게 목표였어요. 하지만 과정을 겪어보니, 이건 단순히 돈을 아끼는 일이 아니더라고요. 내 서비스의 어떤 기능이 정말 가치 있고, 어떤 부분이 낭비인지 이해하는 일종의 ‘제품 분석’ 과정과 같았습니다. 결국 효율적인 비용 관리가 더 건강한 제품을 만드는 길이라는 걸 배웠네요.

---

참고 자료 (References)

1. [pub.towardsai.net] How I Cut My LLM Costs by 80% Without Sacrificing Quality. — https://pub.towardsai.net/how-i-cut-my-llm-costs-by-80-without-sacrificing-quality-85f8505eec96 2. [bigdataboutique.com] LLM Cost Optimization Techniques: A Production Playbook — https://bigdataboutique.com/blog/llm-cost-optimization-techniques 3. [machinelearningmastery.com] Prompt Compression for LLM Generation Optimization and Cost Reduction — https://machinelearningmastery.com/prompt-compression-for-llm-generation-optimization-and-cost-reduction 4. [www.datacamp.com] Prompt Compression: A Guide With Python Examples — https://www.datacamp.com/tutorial/prompt-compression

관련 글 추천

• https://infobuza.com/2026/06/13/20260613-2eooaf/
• https://infobuza.com/2026/06/13/20260613-dxtfxo/

FAQ

LLM 토큰 비용이 급격히 증가하는 주요 원인 4가지는 무엇인가요?

무분별한 재시도(Retries), 답변에 불필요한 문서까지 포함하는 과도한 컨텍스트, max_tokens 설정 미비 등으로 인한 장황한 응답, 그리고 단순 작업에 고성능 모델을 사용하는 오버스펙 모델 사용이 주요 원인입니다.

프롬프트 다이어트를 통해 어느 정도의 비용 절감 효과를 볼 수 있나요?

프롬프트를 2~3배 정도 가볍게 압축하는 것만으로도 정확도 하락은 5% 미만으로 유지하면서 비용을 최대 80%까지 줄일 수 있습니다.

효율적인 프롬프트 압축을 위한 구체적인 방법은 무엇인가요?

중복된 제약 조건을 하나로 명확히 통합하고, 불필요한 배경 설명을 삭제하며, 희귀한 엣지 케이스 예시를 정리하고, 과도한 페르소나 설정을 핵심 역할 중심으로 간소화하는 방법이 있습니다.

지능적 라우팅 중 '캐스케이딩(Cascading)' 기법이란 무엇인가요?

먼저 저렴한 모델에게 답변을 시키고 그 답의 신뢰도 점수를 측정하여, 신뢰도가 설정한 임계값 미만인 경우에만 상위 모델로 요청을 전달하는 방식입니다.

비용 최적화를 과도하게 진행했을 때 발생할 수 있는 부작용은 무엇인가요?

프롬프트를 너무 심하게 압축하면 모델이 문맥의 미묘한 뉘앙스를 놓치거나 추론 흐름이 방해받을 수 있으며, 캐스케이딩 전략의 경우 시스템 복잡도가 증가하여 응답 지연 시간(Tail Latency)이 늘어날 수 있습니다.