AI API 비용은 보통 잘못된 단위로 예측됩니다.

모델 호출당 비용(Cost per model call)도 중요하지만, 그것이 에이전트형 제품(agentic product)의 경제적 단위는 아닙니다. 사용자가 인지하는 하나의 동작은 검색(retrieval), 플래너 호출(planner calls), 도구 호출(tool calls), 검증(validation), 재시도(retries), 폴백 모델(fallback models) 및 감사 추적(audit trail)으로 확장될 수 있습니다.

제품은 하나의 기능처럼 보이지만, 청구서는 하나의 워크플로우(workflow)처럼 나타납니다.

잘못된 질문

대부분의 가격 산정 스프레드시트는 단순한 숫자, 즉 모델 호출당 비용에서 시작합니다. AI 기능이 단일 프롬프트-응답(prompt-response) 교환일 때는 이 방식이 작동합니다. 하지만 제품이 에이전트형(agentic)이 되면 이 방식은 무너집니다.

에이전트 워크플로우(agent workflow)에서 사용자가 인지하는 하나의 동작은 다음과 같은 체인을 트리거할 수 있습니다:

• 컨텍스트 검색 (retrieve context)
• 플래너 모델 호출 (call a planner model)
• 하나 이상의 도구 호출 (call one or more tools)
• 구조화된 출력 검증 (validate structured output)
• 잘못된 응답 후 재시도 (retry after a malformed response)
• 더 강력한 모델로 폴백 (fall back to a stronger model)
• 결과 요약 (summarize the result)
• 감사 추적 작성 (write an audit trail)

고객은 버튼을 한 번 클릭했을 뿐입니다. 하지만 시스템은 유료 결제가 발생하는 열 번의 결정을 내렸을 수 있습니다.

이것이 바로 AI 제품을 만드는 팀들이 종종 자신들의 마진(margins)에 놀라는 이유입니다. 평균적인 모델 호출이 문제가 아닙니다. 꼬리 부분의 워크플로우(tail workflow)가 문제입니다.

흔히 던지는 질문은 다음과 같습니다:

이 모델은 100만 토큰당 비용이 얼마인가요?

이것도 중요하지만, 그것만으로는 충분하지 않습니다.

더 나은 질문은 다음과 같습니다:

전체 워크플로우(workflow)에 걸쳐 이 고객 결과(customer outcome)를 도출하는 데 비용이 얼마나 드는가?

예를 들어, "지원 질문에 답변하기"는 단순한 모델 호출이 아닙니다. 여기에는 검색(retrieval), 분류(classification), 라우팅(routing), 답변 초안 작성(draft answer), 정책 확인(policy check), 도구 조회(tool lookup) 및 인계(handoff)가 포함될 수 있습니다. "보고서 생성"은 검색(search), 추출(extraction), 요약(summarization), 차트 생성(chart generation) 및 최종 검토 단계(final review pass)를 포함할 수 있습니다.

만약 이러한 것들을 단일 호출로 가격을 책정한다면, 스프레드시트는 깔끔해 보이겠지만 여러분의 매출 총이익률(gross margin)은 허구가 될 것입니다.

비용은 단계(Step)에 귀속되어야 합니다

실질적인 시스템은 세 가지 수준에서 비용을 추적합니다:

1. 제공자 호출 (Provider call)
2. 워크플로우 단계 (Workflow step)
3. 사용자 인지 동작 (User-visible action)

제공자 호출 비용(Provider-call cost)은 어떤 모델이 비쌌는지를 알려줍니다.

워크플로우 단계 비용(Workflow-step cost)은 제품의 어느 부분이 비싼지를 알려줍니다.

사용자 액션 비용(User-action cost)은 비즈니스 모델이 작동하는지 여부를 알려줍니다.

세 번째는 가격 책정(Pricing)에 있어 중요한 수치입니다. 만약 하나의 "자동화된 조사 보고서(automated research brief)" 비용이 중앙값(median)에서는 30센트이지만, 상위 1%(99th percentile)에서는 9달러라면, 당신의 비즈니스 리스크는 중앙값이 아닙니다. 바로 꼬리 부분(tail)입니다.

라우팅(Routing)은 제품 결정 사항입니다

워크플로우 단위로 생각하기 시작하면, 모델 라우팅(model routing)의 형태가 바뀝니다.

라우팅은 단순히 "이 프롬프트를 가장 저렴한 제공업체로 보내라"는 것이 아닙니다. 현재 단계에 필요한 최소한의 충분한 모델과 컨텍스트(context)를 결정하는 것입니다.

어떤 단계는 틀렸을 때의 비용이 높기 때문에 강력한 모델이 필요합니다. 어떤 단계는 분류, 추출 또는 포맷팅만 수행하므로 저렴한 모델을 사용할 수 있습니다. 어떤 단계는 결정론적 규칙(deterministic rule)을 사용할 수 있다면 모델을 아예 호출해서는 안 됩니다.

성숙한 AI API 레이어는 다음 사항을 알고 있어야 합니다:

• 어떤 단계가 실행되고 있는지;
• 사용자 액션에 남은 예산이 얼마인지;
• 해당 단계가 되돌릴 수 있는지(reversible);
• 폴백(fallback)이 허용되는지;
• 다음 액션 이전에 어떤 증거(evidence)가 기록되어야 하는지;
• 언제 멈추고, 조용히 계속 진행하는 대신 예산 소진(budget-exhausted) 상태를 반환해야 하는지.

이것이 API 액세스(access)와 API 운영(operations)의 차이입니다.

예산 소진은 제품 상태(Product State)여야 합니다

많은 팀이 사용량 제한을 인프라 오류로 취급합니다.

그것들은 제품 상태(product states)로 취급되어야 합니다.

만약 에이전트(agent)가 토큰 예산, 도구 호출(tool-call) 제한 또는 재시도 상한선에 도달한다면, 시스템은 무언가 고장 난 것처럼 동작해서는 안 됩니다. 대신 다음과 같이 제어된 결과를 반환해야 합니다:

• 누락된 섹션이 있음을 알리는 부분적인 답변;
• 계속 진행하기 위한 사용자의 승인 요청;
• 성능이 저하된 저렴한 경로(degraded cheaper path);
• 사람에게 전달(handoff);
• 대기열에 추가된 백그라운드 실행;
• 명시적인 "예산 소진" 이벤트.

이는 고정 가격 AI 제품에 특히 중요합니다. 정액 구독 모델은 런타임(runtime)에 엄격한 상한선이 있을 때만 작동할 수 있습니다. 그렇지 않으면 몇몇 비정상적인 에이전트 실행이 다른 모든 사용자를 위한 마진(margin)을 모두 소비해 버립니다.

영수증이 중요합니다

에이전트 워크플로우(agentic workflows)의 경우, 비용 기록은 운영 기록의 일부여야 합니다.

단순히 "41,000 토큰을 사용했습니다"라고 말하는 것이 아닙니다. 유용한 영수증은 다음과 같은 내용을 담고 있어야 합니다:

• 어떤 사용자 작업(user action)이 비용 발생을 유발했는지;
• 어떤 워크플로우 단계(workflow step)에서 소비되었는지;
• 어떤 모델/제공업체(model/provider)가 사용되었는지;
• 재시도(retry)나 폴백(fallback)이 발생했는지;
• 어떤 도구 호출(tool calls)이 이루어졌는지;
• 어떤 제한(limit)이나 정책(policy)이 비용 지출을 허용했는지;
• 어떤 결과가 생성되었는지.

이러한 정보가 있어야 제품(product), 엔지니어링(engineering), 재무(finance) 팀이 동일한 맥락에서 대화할 수 있습니다.

이것이 없다면, 재무 팀은 청구서를 보고, 엔지니어링 팀은 로그를 보며, 제품 팀은 사용자 결과(user outcomes)를 보게 되어, 누구도 이들을 깔끔하게 대조(reconcile)할 수 없게 됩니다.

이것이 변화시키는 것

비용을 워크플로우(workflow) 단위로 측정할 때, 팀은 더 나은 의사결정을 내릴 수 있습니다:

• 추측이 아닌 결과(outcome)에 기반한 가격 책정;
• 마진(margin)을 깎아먹는 흐름(flow) 식별;
• 저위험 단계는 더 저렴한 모델로 라우팅(route);
• 고위험 단계에는 강력한 모델을 예약(reserve) 사용;
• 비용 지출이나 작업이 되돌릴 수 없는 경우에만 승인 게이트(approval gates) 추가;
• 사용량 변동(usage variance)이 존재하지 않는 척하지 않고, 예측 가능한 용량(capacity) 판매.

목표는 모든 AI 호출을 저렴하게 만드는 것이 아닙니다. 목표는 전체 워크플로우를 경제적으로 판독 가능하게(economically legible) 만드는 것입니다.

이것이 AI 인프라가 나아가는 방향입니다. 단순히 더 많은 모델을 제공하는 것이 아니라, 모델이 언제, 왜, 어떻게 사용되는지에 대한 더 나은 제어(control)를 제공하는 것입니다.

차세대 AI API 플랫폼은 단순히 얼마나 많은 제공업체를 노출하느냐로 평가받지 않을 것입니다. 대신 다음과 같은 더 어려운 질문에 답할 수 있는지로 평가받을 것입니다:

이 고객 결과(customer outcome)에 비용이 얼마나 들었으며, 왜 그 비용이 발생했는가? 그리고 다음에는 어떻게 해야 하는가?

이것이 바로 중요한 단위(unit)입니다.

다른 팀들은 이를 어떻게 추적하고 있는지 궁금합니다. 제공업체 호출(provider call), 워크플로우 단계(workflow step), 사용자에게 보이는 작업(user-visible action), 아니면 다른 방식인가요?