AI를 프로덕션 환경에서 운영할 때, 토큰 가격은 전체 비용의 아주 작은 부분일 뿐입니다.

AI 기능이 비싸지면 가장 먼저 모델을 의심하게 됩니다.

하지만 소프트웨어 엔지니어로서 우리는 더 불편한 질문부터 던져야 합니다. 즉, 우리가 모델에게 불필요하게 많은 작업을 요구하고 있는 것은 아닌가 하는 것입니다.

하나의 요청은 여러 개의 모델 호출을 유발할 수 있고, 관련 없는 컨텍스트를 수천 토큰만큼 포함할 수 있으며, 실패 후에도 반복적인 작업을 수행하게 할 수 있습니다. 모델을 더 저렴한 것으로 교체하면 청구서가 줄어들 수는 있지만, 근본적인 아키텍처 결정들은 그대로 남게 됩니다.

호출의 가격을 최적화하기 전에, 저는 그 호출을 만들어낸 워크플로우를 먼저 검토할 것입니다.

1. 모델 가격은 시작에 불과하다

모델 가격도 중요하지만, AI 기능의 전체 비용을 설명하지는 못합니다.

프로덕션 워크플로우에는 다음과 같은 것들이 포함될 수 있습니다:

• 모델로 전송되는 입력 및 출력 토큰.
• 단일 사용자 요청에 대한 여러 모델 호출.
• 문서 검색(Document retrieval), 검색(search), 그리고 재순위화(reranking).
• 도구 실행(Tool execution) 및 외부 API 호출.
• 재시도(Retries), 폴백(fallbacks), 추가 검증(validation).
• 애플리케이션 인프라, 스토리지, 모니터링.

일부 비용은 모델 제공업체의 청구서에 직접 나타납니다. 다른 비용들은 주변 인프라에 속합니다. 어느 쪽이든, 토큰 가격만 보고 전체 비용을 결정하는 아키텍처적 결정을 놓칠 수 있습니다.

청구서 관련 질문에 답변하는 고객 지원 어시스턴트를 가정해 봅시다.

단순한 구현은 관련 청구서 정보를 검색하고 단 한 번의 모델 호출로 끝납니다. 반면, 더 정교한 구현은 요청을 분류(classifies)하고, 대화를 요약하며, 여러 데이터 소스를 검색하고, 모델에게 행동 계획 수립을 요청하며, 도구를 호출하고, 최종 답변 생성을 위해 또 다른 모델을 실행합니다.

두 구현 모두 동일한 문제를 해결할 수 있습니다. 하지만 그 비용 구조는 매우 다를 수 있습니다.

전체 비용에 대해 생각하는 유용한 방법은 다음과 같습니다:

총 워크플로우 비용 (Total Workflow Cost)

모델 호출 (Model Calls) + 검색 및 조회 (Retrieval and Search) + 도구 실행 (Tool Execution) + 재시도 및 복구 (Retries and Recovery) + 할당된 인프라 (Allocated Infrastructure)

첫 번째 엔지니어링 작업은 이 구성 요소들 중 실제로 청구서에 기여하는 것이 무엇인지 이해하는 것입니다.

2. 컨텍스트는 공짜가 아니다 (Context Is Not Free)
AI 비용을 증가시키는 가장 쉬운 방법 중 하나는 프롬프트에 계속해서 정보를 추가하는 것입니다.

어떤 기능은 시스템 명령어(system instruction)와 사용자 질문으로 시작합니다. 나중에 팀은 대화 기록, 고객 세부 정보, 내부 문서, 이전 도구 결과, 정책 문서 및 예시를 추가합니다.

각 추가 요소는 개별적으로는 합리적으로 보입니다. 하지만 이들이 결합되면, 상당 부분이 관련이 없음에도 불구하고 반복적으로 처리되는 거대한 컨텍스트가 생성될 수 있습니다.

직원이 다음과 같이 질문하는 상황을 상상해 보세요:

'3월 인보이스가 왜 아직 열려 있나요?'

애플리케이션은 인보이스 상태, 결제 내역 및 최신 관련 지원 상호 작용이 필요할 수 있습니다.

하지만 고객의 모든 인보이스, 전체 지원 기록, 그리고 청구와 관련된 모든 내부 정책 문서는 아마도 필요하지 않을 것입니다.

그럼에도 불구하고 순진한 검색 구현(naive retrieval implementation)은 이 모든 것을 모델에 전송할 수 있습니다.

해결책은 유용한 컨텍스트와 단순히 사용 가능한 컨텍스트를 구별하는 것입니다.

• 현재 질문과 관련된 정보만 조회합니다 (Retrieve only information relevant to the current question).
• 대화 기록을 현재 작업이 필요로 하는 내용으로 제한합니다 (Limit conversation history to what the current task needs).
• 전체 스크립트가 불필요할 때는 더 오래된 기록을 요약합니다 (Summarize older history when a full transcript is unnecessary).
• 캐싱(caching)을 통해 재사용할 수 있는 안정적인 명령어와 참조 자료는 반복하지 않도록 합니다 (Avoid repeating stable instructions and reference material when caching can reuse them).
• 조회되는 문서 및 출력 길이에 명시적인 제한을 설정합니다 (Set explicit limits on retrieved documents and output length).
• 추가 컨텍스트가 비용을 정당화할 만큼 답변을 충분히 개선하는지 측정합니다 (Measure whether additional context improves the answer enough to justify its cost).

결정적인 정책이나 필수 증거를 제거하면 실수, 재시도 및 인간의 개입이 증가할 수 있습니다.

결과를 개선하는 컨텍스트는 유지하고, 단순히 볼륨만 추가하는 컨텍스트는 제거하세요.

캐싱이 도움이 될 수는 있지만, 부실한 컨텍스트 디자인 자체를 고칠 수는 없습니다.
워크플로우가 동일한 지침이나 참고 자료를 반복적으로 전송할 때, 프롬프트 캐싱(prompt caching)은 반복되는 입력을 처리하는 비용을 줄일 수 있습니다.

제공업체들은 캐싱을 다르게 구현하며, 적격성, 캐시 수명, 가격 책정 및 지원 모델이 다양합니다. OpenAI API 가격 책정 문서는 표준 입력 토큰과 캐시된 입력 토큰을 구분합니다. Google 역시 Vertex AI 문서에서 컨텍스트 캐싱(context caching)에 대해 설명하고 있습니다.

캐싱은 반복적인 컨텍스트가 필요할 때 유용합니다. 하지만 애플리케이션이 요청마다 수천 개의 관련 없는 토큰을 전송한다면, 그 토큰들을 저렴하게 만든다고 해서 유용해지는 것은 아닙니다.

먼저 불필요한 컨텍스트를 줄이고, 진정으로 재사용해야 하는 정보만 캐싱하세요.

3. 토큰뿐 아니라 호출 횟수를 세세요

단일 사용자 요청이 반드시 단일 모델 호출을 의미하지는 않습니다.

다음 워크플로우를 고려해 보세요:

사용자 요청
↓
의도 분류(Classify Intent)
↓
문서 검색(Retrieve Documents)
↓
다음 작업 계획(Plan Next Action)
↓
도구 호출(Call Tool)
↓
도구 결과 해석(Interpret Tool Result)
↓
최종 답변 생성(Generate Final Answer)

구현 방식에 따라 이 단계들 중 여러 개가 모델을 호출할 수 있습니다.

어떤 워크플로우는 이러한 분리가 실제로 필요합니다. 모호한 지침, 여러 데이터 소스 또는 이전 결과에 의존하는 결정이 포함된 복잡한 작업은 추가적인 추론 단계(reasoning steps)의 이점을 얻을 수 있습니다.

다른 워크플로우는 모든 새로운 요구사항이 또 다른 AI 단계가 되면서 모델 호출이 누적됩니다.

애플리케이션은 확정적인 규칙으로 처리할 수 있는 지원 카테고리가 있음에도 불구하고 모델에게 요청 분류를 시킬 수 있습니다. 이미 인증된 애플리케이션 컨텍스트에 존재하는 고객 식별자를 추출하도록 다른 모델에게 요청할 수도 있습니다. 최종 생성 단계로 전달하기 전에 짧은 도구 응답을 요약할 수도 있습니다.

각 호출은 비용과 지연 시간(latency)을 추가합니다. 또한 잘못 해석될 또 다른 기회를 만듭니다.

모든 모델 호출에 대해 다음 질문을 하세요:

이 호출은 어떤 구체적인 책임을 가집니까?
이전 단계가 제공할 수 없는 것은 무엇을 추가합니까?
이 호출을 제거하면 어떻게 변경됩니까?
만약 호출을 제거해도 결과에 의미 있는 변화가 없다면, 워크플로우에 포함되지 않을 수 있습니다.

이는 모든 책임을 하나의 거대한 프롬프트에 넣으라는 의미는 아닙니다. 관련 없는 책임들을 결합하는 것은 시스템을 테스트하고, 제약하며, 디버깅하기 더 어렵게 만들 수 있습니다.

목표는 실제 가치를 제공하는 경계를 보존하면서 불필요한 호출을 제거하는 것입니다.

모든 모델 호출은 아키텍처 내에서 그 자리를 증명해야 합니다.

4. 모든 요청이 동일한 모델을 필요로 하지는 않습니다

잘 정의된 문장에서 날짜를 추출하는 것은 모호한 고객 불만을 해석하는 것과 같은 문제가 아닙니다. 요청을 알려진 몇 가지 범주로 분류하는 것은 여러 문서에 걸친 상충되는 증거를 분석하는 것과 같지 않습니다.

모든 작업에 동일한 고성능 모델을 사용하는 것이 구현을 단순화할 수 있지만, 불필요하게 비용이 많이 들 수도 있습니다.

더 신중한 설계는 요구 사항에 따라 작업을 경로 지정합니다.

들어오는 요청
|

작업 유형 결정
|
+-----------+-----------+
| |
잘 정의된 복잡하거나 모호한 작업
| |
작은 모델 또는 더 강력한 모델
| |
결정론적 로직 모델
| |
+-----------+-----------+
|
결과 검증
|

워크플로우 계속

작업 카테고리를 정의하고, 대표적인 예시를 기반으로 후보 모델을 평가하며, 비용이 저렴한 옵션이 요구되는 품질 및 지연 시간 임계값(threshold)을 충족하는 경우에만 해당 카테고리로 라우팅합니다.

이 결정은 모델 크기만으로 하는 것이 아니라 관찰된 작업 성능을 기반으로 해야 합니다.

5. 차이 계산: 예시를 통한 설명

비용 차이를 구체적으로 살펴보겠습니다.

예를 들어, 인보이스 어시스턴트가 6번의 모델 호출(model calls)을 사용하여 요청을 처리하고 총 12,000 토큰을 소비한다고 가정해 봅시다. 워크플로우 검토 후, 팀은 중복되는 분류 및 요약 단계를 제거하고 불필요한 컨텍스트를 줄이며, 해석 및 응답 생성을 위해 필요한 호출만 유지합니다.

최적화된 버전은 2번의 모델 호출과 3,000 토큰을 사용합니다.

이 수치들은 실제 운영 시스템(production system)에서 측정된 것이 아니라 예시적인 가정입니다. 간단하게 하기 위해 두 버전 모두 동일한 모델을 사용하며, 결합된 입력 및 출력 토큰이 평균 유효 가격 $2/백만 토큰(million tokens)을 가진다고 가정합니다. 실제 입력 및 출력 가격은 보통 다르며, 캐싱된 토큰은 별도의 가격 책정이 될 수 있습니다.

계산은 다음과 같습니다:

초기(Initial):
12,000 / 1,000,000 × $2 = $0.024

최적화됨(Optimized):
3,000 / 1,000,000 × $2 = $0.006

이러한 가정 하에, 최적화된 설계는 모델 호출 수를 66.7% 줄이고, 토큰 소비를 75% 줄이며, 모델-토큰 비용을 75% 줄입니다.

하지만 모델 청구서(model bill)는 계산의 일부일 뿐입니다.

잘못될 경우의 비용 (The Cost of Being Wrong)
이제 초기 설계가 98%의 확률로 정확하게 답변하는 반면, 최적화된 버전은 94%의 확률로만 정확하게 답변한다고 가정해 봅시다. 각 부정확한 답변이 직원 수정에 $2의 비용이 발생한다고 가정합니다.

요청당 예상 비용(expected cost per request)은 다음과 같이 계산됩니다:

Initial:
$0.024 + (2% × $2.00) = $0.064
Optimized:
$0.006 + (6% × $2.00) = $0.126
최적화된 버전은 모델 토큰 비용을 75% 줄였지만, 요청당 예상 총 비용은 거의 두 배에 가깝습니다.

이것이 바로 토큰 절감만으로는 AI 효율성을 측정하는 데 부적절한 이유입니다. 더 저렴한 워크플로우가 비즈니스의 다른 곳에서 더 비싼 작업을 초래할 수 있습니다.

이 계산은 부정확한 답변 하나당 추가 $2의 수정 비용이 발생하고 명시된 정확도율이 유지된다고 가정합니다. 실제 시스템은 실제 경제성을 확립하기 위해 측정된 오류율과 수정 비용이 필요할 것입니다.

6. 시스템을 망가뜨리지 않으면서 최적화하기

워크플로우를 이해하면 여러 가지 최적화를 평가하기가 더 쉬워집니다.

불필요한 출력 줄이기
애플리케이션이 상태와 짧은 설명을 필요로 할 때, 긴 서사(narrative)를 요청하는 것은 가치가 거의 없습니다.

적절한 경우 구조화된 출력(structured output)을 사용하고, 명확한 응답 제한을 정의하며, 다운스트림 컴포넌트가 폐기할 정보를 생성하는 것을 피해야 합니다.

하지만 출력을 맹목적으로 잘라내서는 안 됩니다. 불완전한 구조화 객체나 누락된 증거(evidence)는 실패와 추가 작업을 유발할 수 있습니다.

재시도(retries)를 신중하게 하기
시간 초과(timeout), 속도 제한 응답(rate-limit response), 잘못된 JSON, 의미적으로 부정확한 답변은 서로 다른 실패 모드입니다. 이들은 각기 다른 처리가 필요합니다.

제한된 재시도(bounded retries), 적절한 백오프(backoff), 그리고 실패별 복구 전략을 사용해야 합니다. 근본적인 문제가 유효하지 않은 입력이나 결정론적 검증 실패인 경우 동일한 요청을 반복해서 보내지 마십시오.

외부 부작용(external side effects)이 있는 작업의 경우, 재시도 동작은 또한 **멱등성(idempotency)**을 고려해야 합니다. 작업을 반복하는 것이 실수로 같은 인보이스를 전송하거나 같은 비즈니스 거래를 두 번 생성해서는 안 됩니다.

동일한 작업만 캐싱하기
입력과 결과의 의미가 동일하게 유지되는 경우, 캐싱은 반복적인 계산을 피할 수 있게 합니다.

공개된 기술 개념에 대한 캐시된 답변은 여러 사용자에게 재사용될 수 있습니다. 그러나 청구서, 계정 잔액 또는 고객 권한에 대한 캐시된 답변은 신원(identity), 승인(authorization) 또는 기본 데이터가 변경되면 부정확해지거나 정보를 노출할 수 있습니다.

캐시 키(Cache keys), 무효화 규칙(invalidation rules), 그리고 접근 제어 경계(access-control boundaries)는 설계의 일부입니다.

가능한 경우 비동기 처리(asynchronous processing)를 사용하세요.
일부 작업은 즉각적인 응답을 필요로 하지 않습니다. 문서 분류, 예약 요약 생성, 대량 추출 등은 배치 처리(batch processing)에 적합할 수 있습니다.

제공사별로 제공하는 서비스가 다르지만, OpenAI API 가격 책정 문서는 지원되는 배치 워크로드(batch workloads)에 대한 별도의 가격 옵션을 설명합니다.

더 광범위한 엔지니어링 원칙은 필요하지 않은 즉각적인 응답성에 대해 비용을 지불하기보다는 비즈니스 요구 사항에 실행 모드를 맞추는 것입니다.

모든 변경 사항 측정
프로덕션 워크플로우를 변경하기 전에, 비용(cost), 지연 시간(latency), 작업 품질(task quality)에 대한 기준선(baseline)을 설정하세요. 가능하다면 한 번에 하나의 주요 요인만 변경하고, 새로운 동작을 대표적인 요청과 비교해 보세요.