당신의 AI 비용 문제는 모델의 문제가 아니라 아키텍처의 문제입니다

만약 LLM (Large Language Model) 비용이 계속 상승하고 있다면, 본능적으로 항상 똑같은 선택을 하게 됩니다. 더 저렴한 모델로 교체하는 것이죠. GPT-4에서 GPT-4-mini로, Claude Opus에서 Claude Haiku로 바꾸는 식입니다. 때로는 이것이 약간의 도움이 될 수도 있습니다. 하지만 실제 문제를 해결하는 경우는 거의 없습니다.

제가 살펴본 대부분의 워크플로우 (workflow)에서 발생하는 실제 문제는, 언어적 추론 (language reasoning)이 전혀 필요 없는 단계조차 모든 단계가 LLM을 거치도록 라우팅 (routing)된다는 점입니다.

이 포스트는 무엇이 LLM을 사용해야 하고 무엇이 사용하지 말아야 하는지를 결정하기 위한 간단한 멘탈 모델 (mental model)을 설명하며, 여러분이 적용할 수 있는 작동 예시를 제공합니다.

모든 AI 워크플로우의 4가지 구성 요소

고객 지원 티켓 라우터 (support ticket router), 사기 탐지 (fraud check), 또는 콘텐츠 파이프라인 (content pipeline) 등 모든 자동화된 워크플로우는 네 가지 빌딩 블록 (building blocks)의 조합으로 구축됩니다. 워크플로우 다이어그램을 평면적으로 그리면 모두 동일하게 취급되지만, 이들은 매우 다른 비용 및 지연 시간 (latency) 프로필을 가집니다.

구성 요소	역할	비유	일반적인 비용
Trigger (트리거)	워크플로우를 시작함	초인종	~$0
...

2행과 3행 사이의 간격이 이 글의 핵심입니다. 분류기 (classifier)와 LLM 호출은 정확히 동일한 문제를 해결할 수 있지만, 모델과 제공업체에 따라 하나가 다른 것보다 대략 100~1000배 더 많은 비용이 들 수 있습니다. 만약 여러분이 어떤 단계에 어떤 것을 사용할지 의도적으로 결정하지 않는다면, 아마도 비싼 쪽을 기본값으로 사용하고 있을 가능성이 높습니다. 왜냐하면 LangChain과 같은 프레임워크나 빠른 커스텀 에이전트 루프 (custom agent loop)에서는 모든 것을 프롬프트 (prompt)에 밀어 넣는 것이 훨씬 쉽기 때문입니다.

이것이 실제로 나타나는 곳

제가 끊임없이 목격하는 워크플로우는 다음과 같습니다: 자동화된 고객 지원 티켓 분류 (triage) 시스템입니다.

flowchart LR
    A[New support ticket] --> B{Classify intent}
    B --> C[Route to team]
...

단순하게 구축된 방식은 티켓 텍스트 전체를 LLM에 보내고 한 번에 모든 것을 수행하도록 요청합니다: 의도 분류, 라우팅 결정, 답변 초안 작성, 그리고 CRM 업데이트 형식 지정까지 — 이 모든 것을 단일 프롬프트 내에서 수행하며, 종종 라우팅 결정을 위해 LLM에 구조화된 JSON을 출력하도록 요청하기도 합니다.

이 방식은 작동합니다. 하지만 수행하는 작업에 비해 비용이 터무니없이 높습니다. 왜냐하면 B 단계인 분류 (classification)에는 LLM의 추론 (reasoning) 능력이 필요하지 않기 때문입니다. 대신 티켓 텍스트를 N개의 카테고리 중 하나로 매핑하는 것과 같은 하나의 좁은 작업에 특화된 모델이 필요합니다.

세부 분석

트리거 (Trigger) — 웹훅 (webhook)을 통해 티켓이 도착합니다. 비용은 무료입니다.

결정론적 ML (Deterministic ML) — 가벼운 분류기 (미세 조정된 (fine-tuned) BERT 스타일 모델, 또는 임베딩 (embeddings) 기반의 그래디언트 부스팅 분류기)가 의도(intent)를 결정합니다: 결제, 기술 지원, 계정, 스팸. 이것은 계산기 문제와 같습니다. 빠르고, 저렴하며, 일관적입니다. 즉, 동일한 입력에 대해 매번 동일한 출력을 제공하며, 이는 나중에 라우팅 로직을 디버깅할 때 매우 중요합니다.

LLM / 생성형 (Generative) — 오직 답변 초안 작성을 위해서만 호출되며, 실제로 서면 답변이 필요한 티켓에 대해서만 호출됩니다 (예를 들어, 자동으로 태그가 지정되어 조용히 아카이브되는 스팸 티켓은 제외됩니다).

도구 / API (Tool / API) — CRM 업데이트입니다. 데이터베이스 쓰기 작업입니다. 추론이 필요하지 않습니다.

단순한 (naive) 버전에서는 즉시 폐기되는 스팸을 포함하여 모든 티켓이 필요하지도 않은 분류 작업을 위해 LLM 세금 (LLM tax)을 지불합니다.

단순화된 라우팅 계층

이러한 관심사들을 분리했을 때 코드상에서 대략 어떤 모습인지 보여줍니다. 이는 예시일 뿐이며 프로덕션 수준으로 견고하게 만들어진 것은 아닙니다. 핵심은 특정 분류기 구현이 아니라 결정의 형태입니다.

from dataclasses import dataclass
from enum import Enum

...

구조는 삽입하는 특정 분류기보다 더 중요합니다. 저는 팀들이

명확히 말씀드리자면: 이 수치들은 규모(order of magnitude)를 설명하기 위한 예시일 뿐, 특정 배포 환경에서 측정된 결과가 아닙니다. 실제 비용은 사용 중인 제공업체(provider), 모델 선택, 그리고 티켓 수량에 따라 달라집니다.

접근 방식	분류 (Classification)	응답 생성 (Response generation)	월 10,000개 티켓 기준 총합 (~30% 스팸, ~70% 답변 필요)
모든 것을 LLM으로 처리	티켓당 LLM 호출	티켓당 LLM 호출	LLM 10,000회 호출
라우팅 아키텍처 (Routed architecture)	티켓당 저렴한 분류기 사용	스팸이 아닌 경우에만 LLM 호출	LLM 약 7,000회 호출

이 간단한 예시에서도, 모델을 교체하기도 전에 라우팅(routing)만으로 가장 비용이 많이 드는 호출의 30%를 제거할 수 있습니다. 여기에 일반적인 패턴에 대한 템플릿 응답(templated responses)과 반복되는 질문에 대한 캐싱(caching)을 추가하면, LLM 호출 횟수는 더욱 줄어듭니다. 이는 대개 모델을 전환함으로써 얻는 절감액보다 더 큰 효과를 냅니다.

실제로 더 작은 모델을 고려해야 하는 시점

이것은 저렴한 LLM 사용을 반대하는 논거가 아닙니다. 적절한 위치에 사용하자는 논거입니다. 결정론적 작업(deterministic work)과 생성적 작업(generative work)을 분리하고 나면, "더 작고 저렴한 모델을 사용해야 하는가"라는 질문은 훨씬 더 좁은 범위로 좁혀집니다. 즉, 모든 것에 억지로 끼워 맞추는 것이 아니라, 모델이 원래 있어야 할 생성(generation) 단계에만 적용되는 문제가 됩니다.

합리적인 작업 순서는 다음과 같습니다:

1. 워크플로우를 위 네 가지 구성 요소에 맞춰 매핑(Map)하세요. 어떤 단계가 실제로 분류(classification)/추출(extraction)/랭킹(ranking)인지, 아니면 진정한 언어 생성(language generation)인지 솔직하게 구분해야 합니다.
2. 결정론적(deterministic) 단계들을 프롬프트에서 제외하세요. 분류, 라우팅(routing), 점수 산정(scoring), 구조화된 추출(structured extraction) 등은