프로덕션 규모에서 LLM 토큰 비용을 절감하는 12가지 엔지니어링 습관

당신의 LLM 청구서는 하나의 큰 누수가 아닙니다. 12개의 작은 누수입니다.

한 팀이 제품에 훌륭한 AI 기능을 출시했습니다. 비용은 6주 만에 조용히 세 배로 뛰었습니다. 모델도 같고, 제품도 같으며, 명확한 설명도 없었습니다.

그것은 모델의 문제가 아닙니다. 그것은 습관의 문제입니다.

토큰 가격은 하락하고 있습니다. 기업의 AI 청구서는 상승하고 있습니다. 이 명백한 모순은 진짜 범인을 볼 때 즉시 해결됩니다. 바로 가격 하락보다 볼륨(Volume)이 더 빠르게 성장한다는 점입니다. Google은 이제 한 달에 1,000조(quadrillion) 개 이상의 토큰을 처리합니다. Deloitte의 2026년 CFO 가이드라인은 AI를 기술 예산에서 가장 빠르게 성장하는 항목으로 지목했습니다. 당신은 더 저렴한 토큰을 사용하면서 동시에 더 높은 청구서를 받을 수 있으며, 대부분의 팀이 실제로 그러합니다.

이 상황에서 살아남는 팀은 가장 저렴한 모델을 사용하거나 가장 유리한 요율을 협상한 팀이 아닙니다. 그들은 구축 방식에 깨끗한 습관을 엔지니어링해 넣은 팀입니다. 모든 호출(Call). 모든 기능. 모든 배포(Deploy).

여기 중요한 12가지 습관이 있습니다.

토큰 가격 하락이 당신을 구원하지 못하는 이유

전술을 살펴보기 전에, 구조적인 함정을 이해해 봅시다.

1M당 토큰 가격: $15 → $8 → $4 (빠르게 하락 중)
월간 토큰 볼륨: 10M → 80M → 600M (더 빠르게 성장 중)

...

이것은 가설이 아닙니다. 비용 규율 없이 AI 기능을 출시하는 모든 팀이 겪는 궤적입니다. 토큰당 가격은 떨어집니다. 총 청구서는 폭발합니다. 그리고 CFO가 왜 AI 항목이 세 배로 늘었는지 묻기 전까지는 아무도 알아차리지 못합니다.

해결책은 더 저렴한 모델이 아닙니다. 해결책은 12가지의 더 깨끗한 습관입니다.

12가지 엔지니어링 습관

1. 작업에 적합한 모델을 선택하라

대부분의 팀은 기본적으로 가장 큰 모델을 선택합니다. 큰 실수입니다.

가장 큰 모델이 적절한 모델인 경우는 드뭅니다. 그저 가장 안전하다고 느껴지는 모델일 뿐입니다. 모든 요청은 품질 기준을 통과하면서도 가장 작고 저렴한 모델로 라우팅(Routing)될 자격이 있습니다.

제가 사용하는 라우팅 휴리스틱(Heuristic)은 다음과 같습니다:

작업 유형 (Task Type)	모델 계층 (Model Tier)	예시 (Examples)
라우팅 (Routing), 분류 (Classifying), 추출 (Extracting)	소형 (Small)	GPT-5.4-mini, Claude Haiku 4.5
...	...	...

대부분의 프로덕션 워크로드 (Production workloads)는 대형 모델의 가격표를 달고 있는 소형 모델용 작업들입니다. 요청 유형을 매핑하고, 각 계층에서의 출력 품질 (Output quality)을 측정하여 그에 따라 라우팅하십시오. 간단한 분류기(Classifier) — 네, 아마도 소형 모델일 것입니다 — 가 이 라우팅을 저렴하게 수행할 수 있습니다.

def route_model(task_type: str) -> str:
    routing_map = {
        "classify": "claude-haiku-4-5",
...

2. 입력 토큰 (Input Tokens) 절감

당신은 결과로 받는 토큰뿐만 아니라, 보내는 모든 토큰에 대해 비용을 지불합니다.

매 호출마다 2,000토큰 규모의 시스템 프롬프트 (System prompt)를 사용하는 것은 영구적인 세금을 내는 것과 같습니다. 모든 개별 요청마다, 영원히 그 비용을 지불하게 됩니다. 팀들은 예시를 쌓아두고, 호출 전반에 걸쳐 지침을 반복하며, "만약을 대비해" 거대한 컨텍스트 (Context) 블록을 붙여넣습니다. 모델은 당신의 인생사를 알 필요가 없습니다.

시스템 프롬프트를 감사(Audit)하십시오. 토크나이저 (Tokenizer)를 통해 실행해 보십시오. 대부분의 팀은 첫 번째 검토에서 중복된 예시, 오래된 지침, 모델이 전혀 사용하지 않는 컨텍스트 등 30~50%를 잘라낼 수 있다는 것을 발견합니다.

간결하게 작성하십시오. 더 적게 보내십시오. 그런 다음 품질이 실제로 떨어졌는지 측정하십시오. 보통은 떨어지지 않습니다.

3. 출력 토큰 (Output Tokens) 제한

긴 답변은 철저해 보입니다. 하지만 비용도 많이 듭니다.

출력 토큰 상한선 (Output token caps)을 엄격하게 설정하십시오. 프롬프트에서 불렛 포인트 (Bullet points), 구조화된 응답 (Structured responses), 또는 명시적인 길이 제한을 요청하십시오:

# 개방형 생성 (Open-ended generation) 대신
messages = [{"role": "user", "content": "X가 어떻게 작동하는지 설명해줘."}]

...

50토큰의 답변이 500토큰의 답변보다 낫습니다 — 비용 측면에서도, 그리고 종종 사용자 측면에서도 말입니다. 장황한 모델 출력은 종종 미사여구 속에 핵심 신호 (Signal)를 묻어버립니다. 출력 길이를 제한하면 비용과 품질이 모두 향상됩니다.

4. 캐싱 (Caching)을 공격적으로 사용

사용자들은 똑같은 질문을 반복해서 합니다. 똑같은 답변을 다시 생성하는 것을 멈추십시오.

여기에는 두 가지 캐싱 계층 (Caching layers)이 중요합니다:

정확 일치 캐싱 (Exact-match caching): 프롬프트를 해싱(Hash)하고 응답을 캐싱합니다. 구현이 매우 간단하며, 모든 FAQ 스타일의 트래픽에 대해 즉각적인 투자 대비 효과 (ROI)를 제공합니다.

시맨틱 캐싱 (Semantic caching): 임베딩 유사도 (embedding similarity)를 사용하여 문구가 조금 다르더라도 거의 중복되는 프롬프트를 포착합니다. "비밀번호를 어떻게 재설정하나요?"라는 질문과 "비밀번호를 잊어버렸는데 어떻게 해야 하죠?"라는 질문은 동일한 캐싱된 응답을 반환해야 합니다.

프롬프트 접두사 캐싱 (Prompt prefix caching): 대부분의 제공업체는 이제 긴 시스템 프롬프트의 정적 부분에 대해 캐싱된 접두사 (cached prefixes)를 제공합니다. 모든 호출마다 1,500토큰의 시스템 프롬프트가 사용된다면, 프롬프트 캐싱만으로도 입력 비용을 절반으로 줄일 수 있습니다. 이것은 거저 얻는 이득입니다. 반드시 활용하세요.

시맨틱 캐시를 적용한 아키텍처:

사용자 쿼리 (User Query)
...

5. 제대로 된 RAG (RAG Done Right)

잘못된 RAG는 조용히 예산을 갉아먹는 주범입니다. 팀들은 거대한 컨텍스트 청크 (context chunks)를 쏟아붓고 모델이 알아서 정리하기를 바랍니다. 모델은 실제로 정리를 해내지만, 그 과정에서 발생하는 모든 토큰에 대해 비용을 청구합니다.

해결책은 정밀한 검색 (surgical retrieval)입니다:

• 작게 청킹하기 (Chunk small): 더 작고 집중된 청크는 더 정교한 검색을 의미합니다. 256토큰 청크가 의미론적으로 더 정확하다면 2,000토큰 청크보다 낫습니다.
• 현재 질문에 필요한 것만 검색하기: 지식 베이스 전체를 검색하지 마세요. 고정된 K값이 아니라, 관련성 임계값 (relevance threshold)을 적용한 Top-K 검색을 사용하세요.
• 전송 전 다듬기 (Trim before you send): 검색 후, 가벼운 리랭커 (reranker)를 실행하거나 저렴한 모델을 한 번 통과시켜 관련 없는 검색 청크를 메인 컨텍스트 창 (context window)에 들어가기 전에 제거하세요. 좋은 RAG는 "더 많은 컨텍스트"가 아닙니다. 더 적더라도, 정확하게 맞는 컨텍스트를 제공하는 것입니다.

6. 배치 요청 (Batch Requests)

하나씩 처리하는 API 호출은 오버헤드 (overhead)를 발생시킵니다. 배칭 (Batching)은 이를 제거합니다.

대부분의 제공업체는 실시간성이 중요하지 않은 작업에 대해 대폭 할인된 (종종 50% 할인) 배치 API 계층을 제공합니다. 문서를 처리하거나, 코퍼스 (corpus)를 임베딩하거나, 평가 (evaluations)를 실행하는 경우, 실시간 가격을 지불할 이유가 없습니다.

# 배치 워크로드에 대해 이렇게 하지 마세요
for document in documents:
    result = client.messages.create(...)  # 순차적, 실시간 가격 적용
...

밤샘 처리 작업 (Overnight processing jobs)은 실시간 가격이 필요하지 않습니다. 이를 배치 계층으로 라우팅하세요.

7. 함수 호출 (Function Calling) 및 구조화된 출력 (Structured Output) 사용

자유 형식의 텍스트(Free-text) 답변은 파싱(Parsing) 비용이 많이 듭니다. 워크플로우는 다음과 같이 변합니다: 장황한 텍스트 생성 → 파싱 코드 작성 → 예외 케이스 처리 → 오류 발생 시 재질문. 모든 단계가 토큰을 추가합니다.

함수 호출 (Function Calling) 및 구조화된 출력 (Structured Output)은 이 과정을 압축합니다:

# 비용이 많이 드는 방식: 이후에 파싱해야 하는 자유 형식의 텍스트 답변
response = "사용자의 감정은 긍정적이며, 구매 의도는..."

...

스키마(Schema)를 정의하세요. 깔끔한 JSON을 요청하세요. 자연어 형태의 래퍼(Wrapper)를 건너뛰세요. 더 적은 토큰, 더 적은 재시도, 그리고 글루 코드(Glue code)가 필요 없습니다.

8. 프롬프트 라이브러리 (Prompt Library) 구축

모든 팀은 동일한 프롬프트를 약간씩 다른 다섯 가지 방식으로 다시 작성합니다. 각 버전은 점차 변질됩니다. 각 버전은 점점 길어집니다. 아무도 이를 관리하지 않습니다.

대신 검증된 매개변수화된 템플릿(Parameterized templates) 라이브러리를 구축하세요:

PROMPT_LIBRARY = {
    "classify_support_ticket": """
Classify this support ticket into exactly one category: {categories}.
...

프롬프트를 한 번 작성하고, 한 번 튜닝하고, 한 번 측정하여 어디에서나 재사용하세요. 이는 비용, 품질, 그리고 유지보수 측면에서의 승리입니다.

9. 계층화된 2단계 접근 방식 (Tiered, Two-Step Approach) 사용

모든 요청이 가장 비싼 모델을 사용할 가치가 있는 것은 아닙니다. 먼저 필터링하세요.

                    모든 요청 (All Requests)
                         │
                         ▼
...

대부분의 트래픽은 비싼 모델을 전혀 필요로 하지 않습니다. 저렴한 분류 단계(Triage pass) — 요청 복잡도 분류, 노이즈 필터링, 단순 케이스 직접 처리 — 를 통해 진정으로 어려운 문제만을 비용이 높은 스택으로 라우팅합니다. 절감 효과는 종종 극적입니다. 프로덕션 트래픽의 60~80%를 소형 모델 비용으로 처리할 수 있습니다.

10. 기능별 토큰 지출 모니터링

보이지 않는 것은 고칠 수 없습니다.

대부분의 팀은 어떤 기능이 가장 많은 토큰을 소모하는지 알지 못합니다. 그들은 추측하고, 틀린 추측을 하며, 결국 잘못된 것을 최적화합니다.

기능(Feature) 수준에서 계측(Instrument)하세요:

import time

def tracked_completion(feature: str, messages: list, **kwargs):
...

기능별, 사용자 등급별, 요청 유형별로 지출을 추적하세요. 비용을 가장 많이 발생시키는 상위 3가지를 찾아내세요. 그것부터 먼저 해결하십시오. 청구서가 폭발한 뒤에 영웅적인 뒷수습을 하는 것보다, 매주 확인하는 대시보드가 훨씬 낫습니다.

11. 제공업체 가격 책정을 조달 결정(Procurement Decision)으로 취급하기

제공업체(Provider)의 가격 책정은 고정되어 있지 않습니다. 모델, 지역, 약정 등급(Commitment tier), 워크로드 유형에 따라 변합니다. 대부분의 팀은 제공업체를 한 번 선택하면 다시는 검토하지 않습니다.

이를 인프라 조달과 같이 취급하십시오:

• 프로덕션 볼륨을 확정하기 전에 실제 워크로드 혼합(Workload mix)을 기준으로 제공업체들을 비교하십시오.
• 예약 용량(Reserved capacity) 및 약정 사용 할인(Committed-use discounts)을 평가하십시오 (종종 온디맨드(On-demand) 대비 30~60% 저렴합니다).
• 다른 지역(Region)이 더 낮은 지연 시간(Latency)과 더 낮은 비용을 동시에 제공하는지 고려하십시오.
• 모델이 진화함에 따라 제공업체 전반에 걸쳐 주기적인 품질 대비 비용(Cost-per-quality) 벤치마크를 실행하십시오.

이것은 운영(Ops) 팀뿐만 아니라 엔지니어링 팀이 주도해야 하는 조달 결정입니다. 절감 잠재력은 종종 다른 12가지 습관을 모두 합친 것보다 더 큽니다.

12. 임베딩(Embeddings) 사용 최적화

임베딩은 호출당 비용이 저렴하게 느껴집니다. 하지만 규모가 커지면 그렇지 않습니다.

가장 흔한 낭비 패턴은 다음과 같습니다:

• 동일한 콘텐츠를 반복적으로 다시 임베딩함 (캐싱(Caching) 부재)
• 거의 중복된 콘텐츠를 별도로 임베딩함 (중복 제거(Deduplication) 부재)
• 배치(Batching) 대신 개별 임베딩 호출을 수행함

이 세 가지를 모두 해결하십시오:

import hashlib

# 콘텐츠 해시를 통해 임베딩 캐싱
...

호출당 비용은 작지만, 프로덕션 규모에서는 총비용이 막대합니다. 정리할 가치가 충분합니다.

12가지 습관을 관통하는 패턴

목록을 다시 읽어보십시오. 무언가 느껴지십니까?

이 중 영리한 기술은 하나도 없습니다. 비밀스러운 모델 플래그도, 문서화되지 않은 API 파라미터도, 벤더의 트릭도 없습니다. 모든 전략은 단 하나의 움직임으로 귀결됩니다: 더 적은 토큰을 보내고, 중요한 토큰만 보내는 것.

LLM 비용 최적화는 일회성 프로젝트가 아닙니다. 로깅(Logging), 테스트(Testing), 에러 핸들링(Error handling)을 내재화하는 것과 마찬가지로, 팀이 구축하는 방식에 녹여내야 하는 규율(Discipline)입니다.

Azure에서의 적용 방식

Azure에서 구축하고 있다면, 이 플랫폼은 대부분의 전략에 대한 네이티브 환경을 제공합니다:

전략	Azure 서비스
모델 라우팅 (소형/중형/대형)	Azure AI Foundry 모델 카탈로그 — 다양한 티어를 배포하고 이들 사이를 라우팅
...

이 12가지를 모두 수동으로 연결할 필요는 없습니다. 플랫폼을 연결하세요.

핵심 요약 (Key Takeaways)

• 토큰 가격은 내려가고 있지만, 청구 금액은 올라가고 있습니다. 가격 하락보다 사용량 증가 속도가 더 빠릅니다. 이는 우연이 아닌 구조적인 문제입니다.
• 대부분의 LLM 비용은 기능(feature)이 아닌 습관에서 발생합니다. 과도하게 큰 모델 사용, 장황한 프롬프트 (verbose prompts), 캐싱되지 않은 반복 호출, 그리고 순차적 배치 (sequential batching) 처리가 주요 원인입니다.
• 이번 주에 바로 적용할 세 가지: 모델 라우팅의 크기를 적절히 조정하고, 출력 토큰 (output tokens)을 제한하며, 프롬프트 접두사 캐싱 (prompt prefix caching)을 활성화하세요. 이 세 가지만으로도 일반적으로 비용을 3분의 1 수준으로 절감할 수 있습니다.
• 기능 단위로 모니터링하세요. 측정할 수 없는 것은 최적화할 수 없습니다. 기능별 토큰 지출 대시보드를 통해 비용의 80%를 유발하는 20%의 요청을 찾아내야 합니다.
• 비용 최적화는 매 API 호출 시 이루어지는 설계 선택입니다. 이는 분기별로 진행하는 정리 프로젝트가 아닙니다.

논쟁해 볼 만한 질문

제가 진심으로 고민하고 있는 지점이 하나 있습니다. 모델은 더 저렴해지고 컨텍스트 윈도우 (context windows)는 더 커짐에 따라, 이러한 습관 중 일부는 덜 중요해질 수도 있습니다. 어쩌면 2년 뒤에는 모든 호출에 10,000-토큰 컨텍스트 윈도우를 보내는 비용이 불과 몇 푼에 불과해져 아무도 신경 쓰지 않게 될지도 모릅니다.

혹은, 사용량이 가격 하락분을 모두 채울 만큼 성장할 것이며, 절제된 습관이 그 어느 때보다 더 중요해질 수도 있습니다.

여러분은 어떻게 생각하시나요? 프로덕션 환경에서 LLM 비용을 적극적으로 최적화하고 계신가요, 아니면 가격 곡선이 문제를 해결해 줄 것이라고 믿고 계신가요? 댓글로 알려주세요. 팀들이 이를 엔지니어링 인프라로 다루고 있는지, 아니면 시장이 해결해주기를 바라고 있는지 진심으로 궁금합니다.