저희는 소프트웨어 회사가 아닙니다. 리퍼비시 노트북과 iPhone을 판매합니다. 하지만 저희는 소프트웨어를 운영합니다. 그것도 아주 많이요. 제품 설명 생성, 고객 문의 라우팅(routing), 재고 등급 판정 지원, 반품 사유 분류 등 운영 프로세스에 LLM API를 통합한 지 18개월이 지나면서, 저희는 "이 정도면 감당할 만하다"에서 "이것은 진정으로 우리의 마진을 위협하고 있다"라는 단계에 이르렀습니다.

여기에 실제로 어떤 일이 일어났는지, 수치를 실제로 분석했을 때 무엇을 발견했는지, 그리고 품질을 크게 저하시키지 않으면서 월간 LLM 지출을 71% 줄일 수 있었던 세 가지 변화에 대한 솔직한 분석을 담았습니다.

우리가 이런 상황에 처하게 된 이유

시작은 제품 설명이었습니다. 저희는 수백 대의 리퍼비시 기기를 목록화합니다. 각 기기에 대해 정확하고 구체적이며 SEO(검색 엔진 최적화)에 최적화된 설명을 수동으로 작성하는 것은 시간 비용이 많이 듭니다. 그래서 기기 사양, 상태 등급, 배터리 건강 상태를 입력받아 리스팅 문구를 생성하는 파이프라인을 구축했습니다. 잘 작동했습니다. 그래서 저희는 이를 확장했습니다.

그다음 고객 문의 분류기(classifier)를 추가했습니다. 그다음 반품 사유 분석기를 추가했습니다. 그다음 일반적인 지원 티켓(support tickets)에 대한 이메일 초안 응답기를 추가했습니다. 각각의 추가는 점진적인 것처럼 느껴졌습니다. 각각은 개별적으로 보면 타당했습니다.

6개월 후, 저희의 월간 LLM API 지출은 £180에서 £1,340로 증가했습니다.
30~35%의 매출 총이익률(gross margins)로 운영되는 실물 제품 비즈니스에서, 월 £1,340의 API 비용은 단순한 오차 범위가 아닙니다. 이는 월 매출의 상당 부분에 대한 마진의 유의미한 비율을 차지합니다. 저희는 각 기능을 구축할 때 그런 방식으로 모델링하지 않았습니다. 각 기능을 개별적으로만 모델링했습니다.

감사(Audit) — 실제로 발견한 것

LLM API 가격은 주요 제공업체에 따라 모델과 제공업체에 따라 입력 토큰 100만 개당 $0.05에서 $30까지 600배 이상 차이가 납니다. 저희는 그 범위 중 어디에 위치해 있는지 주의를 기울이지 않았습니다.

사용량을 제대로 감사했을 때, 저희는 세 가지 문제를 발견했습니다:

문제 1 — 필요하지 않은 작업에 플래그십(flagship) 모델을 사용하고 있었습니다.

저희의 제품 설명 파이프라인은 GPT-4o에서 실행되고 있었습니다. 당시 비용은 입력 토큰 100만 개당 $2.50, 출력 토큰 100만 개당 $10였습니다. 저희는 정해진 구조화된 템플릿(structured template)에 깔끔하게 들어맞는 사양을 가진 기기들을 위한 설명을 생성하고 있었습니다. 이 작업에는 일관된 형식과 정확한 사양 통합이 필요했을 뿐, 정교한 추론(reasoning)이 필요하지 않았습니다. 플래그십(flagship) 모델을 사용하는 것은 완전히 과잉(overkill)이었습니다.

문제 2 — 시스템 프롬프트(system prompts)가 너무 방대했고, 매 호출마다 그 비용을 지불하고 있었습니다.

저희의 제품 설명 시스템 프롬프트는 2,400 토큰 길이에 달했습니다. 여기에는 상세한 형식 지침, 브랜드 보이스(brand voice) 가이드라인, SEO 원칙, 그리고 모든 기기 카테고리에 대한 예시 출력(example outputs)이 포함되어 있었습니다. 저희는 매 API 호출마다, 즉 하루에 수백 번씩 이 2,400 토큰을 보내는 비용을 지불하고 있었습니다. 저희는 프롬프트 캐싱(prompt caching)을 전혀 구현하지 않은 상태였습니다.

현재 모든 주요 제공업체는 자주 재사용되는 시스템 프롬프트를 서버 측에 저장하고 일반 입력 요율의 아주 일부만 부과하는 프롬프트 캐싱을 제공합니다. OpenAI는 캐시된 읽기(cached reads)에 대해 90%의 비용 절감을 제공하며, Anthropic은 캐시 히트(cache hits) 시 기본 입력 가격의 10%만 부과합니다. WPS Office
저희는 동일한 2,400 토큰에 대해 매일 수백 번씩 전체 가격을 지불하고 있었습니다. 이는 오후 시간만 투자해도 해결할 수 있는 문제였습니다.

문제 3 — 라우팅 로직(routing logic)이 없었습니다. 모든 것이 동일한 모델로 전송되었습니다.

고객 지원 문의 분류(Customer support query classification) — 들어온 메시지가 반품 요청인지, 배송 문의인지, 제품 질문인지, 아니면 다른 것인지 파악하는 작업 — 가 가장 복잡한 작업과 동일한 플래그십 모델에서 실행되고 있었습니다. 분류는 단순한 작업입니다. 출력 토큰 100만 개당 $10의 비용이 드는 모델을 필요로 하지 않습니다.

세 가지 해결책

**해결책 1 — 작업 복잡도에 따른 모델 계층화 (Model tiering based on task complexity)

일반적인 기업의 배포 방식은 쿼리의 70%를 저가형 모델(budget model)로, 20%를 중간 단계 모델(mid-tier model)로, 10%를 프리미엄 모델(premium model)로 라우팅합니다. 이러한 계층적 접근 방식(tiered approach)은 모든 트래픽을 단일 프리미엄 모델로 라우팅하는 것과 비교했을 때 쿼리당 평균 비용을 60~80% 절감합니다. Laptop Mag
우리는 스택 내의 모든 LLM 작업을 복잡도(complexity)에 따라 다음과 같이 분류했습니다:

`TASK_ROUTING = {

단순 분류, 템플릿화된 출력 (Simple classification, templated output)

"query_classifier": "gpt-4.1-nano", # MTok당 $0.10/$0.40
"return_reason_classifier": "gpt-4.1-nano",
"email_category": "gpt-4.1-nano",

# 중간 정도의 복잡도를 가진 구조화된 생성 (Structured generation with moderate complexity)
"product_description": "gpt-4.1-mini",   # MTok당 $0.40/$1.60
"condition_summary": "gpt-4.1-mini",
...

}`

가장 많은 작업량이 발생하는 분류 작업(classification tasks)의 경우, 출력 비용이 MTok당 $10에서 $0.40로 감소했습니다. 해당 호출에서 96%의 비용 절감을 달성했습니다.

해결책 2 — 프롬프트 캐싱(prompt caching)을 적절히 구현하기

OpenAI의 경우, 정적 콘텐츠(static content)가 먼저 나타나도록 프롬프트를 구조화해야 합니다:

messages = [ { "role": "system", "content": STATIC_SYSTEM_PROMPT # 2,400 토큰 — 첫 호출 후 캐싱됨 }, { "role": "user", "content": f"Generate description for: {device_specs}" # 호출마다 변함 } ]

Anthropic의 API의 경우, 명시적인 캐시 제어 헤더(cache control headers)가 필요합니다:

messages = [ { "role": "user", "content": [ { "type": "text", "text": STATIC_SYSTEM_PROMPT, "cache_control": {"type": "ephemeral"} }, { "type": "text", "text": f"Generate description for: {device_specs}" } ] } ]

캐싱을 구현한 후, 정적 시스템 프롬프트(static system prompt)의 비용은 이후 모든 호출에서 전체 입력 토큰 가격의 10% 수준으로 떨어졌습니다. 하루에 300회 이상의 호출이 발생하는 제품 설명 파이프라인(description pipeline)에서, 이 변경만으로 월간 지출이 약 £280 감소했습니다.

해결책 3 — 지연 시간에 민감하지 않은 워크로드(workloads)를 위한 배치 처리(Batch processing)

모든 LLM 작업이 실시간으로 결과를 반환할 필요는 없습니다. 저희의 반품 사유 분류(return reason classification)는 고객이 직접 사용하는 인터페이스가 아니라, 제출된 반품 요청을 대상으로 실행됩니다. 30분의 처리 지연은 완전히 허용 가능한 수준입니다.
Batch API는 지연 시간에 민감하지 않은 워크로드(workloads)에 대해 OpenAI와 Anthropic의 모든 모델에 대해 50% 할인을 제공합니다.

저희는 반품 사유 분류, 상태 요약 생성(condition summary generation), 그리고 야간 재고 설명 업데이트(overnight inventory description updates)를 배치 처리(batch processing)로 전환했습니다. 이 모든 작업의 비용이 절반으로 줄었습니다.

# 반품 분류를 위해 실시간 API 호출을 사용하는 대신: client.batches.create( input_file_id=batch_file_id, endpoint="/v1/chat/completions", completion_window="24h", metadata={"job_type": "return_classification"} )

세 가지 변화 이후의 수치들

고객 지원 이메일 초안 작성(Support email drafts)은 가장 적은 비용 절감 효과를 보였는데, 이는 해당 작업이 진정으로 고품질의 모델을 필요로 하기 때문입니다. 출력 결과가 고객에게 직접 전달되므로 품질이 중요합니다. 저희는 이 작업을 GPT-4.1로 유지하고 비용을 감수했습니다. 나머지 세 가지 워크로드는 유의미한 품질 저하 없이 전환되었습니다.

처음부터 다르게 했을 것이라면

각 LLM 기능을 출시하기 전에 비용 모델(cost model)을 구축했을 것입니다. 대략적인 추정치가 아니라, 예상 호출량(call volume), 토큰 수(token counts), 그리고 사용할 계획인 모델을 기반으로 한 실제 계산 말입니다. 저희는 초기 클라우드 도입자들이 컴퓨팅 비용을 다루었던 방식처럼, LLM 비용을 나중에 걱정해도 되는 것으로 취급했습니다. 그리고 '나중'은 결국 찾아왔습니다.

해당 작업을 수행할 수 있는 가장 저렴한 모델을 기본값으로 설정하십시오. 예산 계층(budget tier)에서 시작하여, 출력 품질이 진정으로 불충분할 때만 더 유능한 모델로 올라가야 합니다. 저희는 반대로 했습니다. 플래그십(flagship) 모델을 기본값으로 설정했다가, 청구서가 날아온 후에야 비용을 최적화하며 내려갔습니다.

첫날부터 캐싱 (caching)을 구현하세요. 구현하지 않을 이유가 전혀 없습니다. 일관된 시스템 프롬프트 (system prompts)를 사용하는 애플리케이션의 경우, 프롬프트 캐싱 (prompt caching)을 통해 캐싱된 부분에 대한 입력 비용을 70~90%까지 절감할 수 있습니다. 구현하는 데는 오후 한나절이면 충분하며, 절감 효과는 영구적입니다. Laptop Mag

아키텍처 설계 단계에서 지연 시간 (latency)에 민감한 워크로드와 배치 (batch) 처리가 가능한 워크로드를 분리하세요. 모든 LLM 호출을 구축하기 전에 "이 작업이 3초 이내에 응답해야 하는가?"라는 질문을 던져야 합니다. 만약 대답이 '아니오'라면, 배치 (batch) 처리를 하세요.

더 넓은 관점

2025년 초와 2026년 초 사이에 LLM API 가격은 약 80% 하락했으며, 이는 진심으로 반가운 소식입니다. 하지만 가격이 하락하더라도, 사용량이 가격 하락 속도보다 빠르게 확장되거나 작업에 맞지 않는 잘못된 모델 계층 (model tier)을 사용하고 있다면 비용 증가로부터 보호받을 수 없습니다.

LLM 통합에서의 비용 문제는 대개 가격 책정 (pricing)의 문제가 아닙니다. 그것은 아키텍처 (architecture)의 문제입니다. 예산 모델 (budget model)로 충분한 곳에 플래그십 (flagship) 모델을 사용하고, 캐싱되지 않은 시스템 프롬프트 (system prompts)를 사용하며, 배치 (batch) 처리가 가능한 곳에 동기식 호출 (synchronous calls)을 사용하는 것 — 이것들은 구축 시점에 내려진 아키텍처 결정들이며, 규모가 커짐에 따라 상당한 월간 비용으로 누적됩니다.

해결책은 복잡하지 않습니다. 그저 청구서가 도착하기 전에 실제로 수치를 살펴보는 것만 필요할 뿐입니다.

Exact Solution은 영국, 폴란드 및 유럽 전역에서 전문적으로 리퍼비시 (refurbished)된 MacBook, iPhone 및 노트북을 판매합니다 — 테스트 및 등급 분류를 거쳤으며 보증이 제공됩니다.
exactsolution.com