모든 AI 제공업체는 백만 토큰당 달러 단위로 가격을 공시합니다. 모든 비교표는 이를 기준으로 순위를 매깁니다. 모든 '자체 구축 vs 구매 (build-versus-buy)' 스프레드시트는 이 수치를 기반으로 작동합니다.

그 수치는 오해의 소지가 있으며, 결코 사소한 수준이 아닙니다. 10배까지 차이가 날 수 있으며, 비싼 옵션이 저렴해 보이도록 잘못된 방향으로 나타날 수 있습니다.

이 글은 AI 작업의 실제 비용에 관한 일곱 가지 사항을 설명합니다. 각각의 사항은 저를 포함한 똑똑한 사람들이 상황을 거꾸로 이해하는 것을 목격한 지점들입니다.

1. 표시 가격이 실제 가격은 아니다

핵심: 모델이 생각하는 동안 생성하는 토큰에 대해 비용이 청구되지만, 정작 사용자는 그 토큰을 볼 수도 없고 사용할 수도 없습니다.

최신 모델들은 "추론 토큰 (reasoning tokens)"을 방출합니다. 모델이 문제를 해결해 나가는 과정 자체가 생성된 텍스트이며, 이에 대해 비용이 청구됩니다. 많은 API에서는 이 토큰을 아예 받지도 못합니다.

우리가 직접 수행한 실제 평가 사례는 다음과 같습니다. 우리는 저비용 티어를 더 저렴한 모델로 교체하는 것을 고려하고 있었습니다:

현재 모델: 백만 토큰당 입력(in) $0.07 / 출력(out) $0.27
후보 모델: 백만 토큰당 입력(in) $0.05 / 출력(out) $0.20
서류상 수치: 양쪽 모두 약 30% 더 저렴함.

당연히 교체해야 할 상황이었습니다. 그래서 우리는 실제 요청을 하나 보냈습니다. 모델은 정확하게 답변했습니다. 그 후 청구 세부 내역을 확인했습니다:

프롬프트 토큰 (prompt tokens) 274개
완성 토큰 (completion tokens) 132개
  그 중 123개는 추론 토큰 (REASONING tokens)
...

당신은 132개 전체에 대해 비용을 지불합니다. 하지만 실제로 사용할 수 있는 것은 9개뿐입니다.

그 산술 계산을 해보면, 유용한 출력 토큰의 실질 가격은 백만 개당 $2.93였으며, 이는 광고된 요율보다 14.7배 높은 수치였습니다. "30% 더 저렴한" 모델이 기존 모델보다 대략 10배 더 비쌌던 것입니다.

우리는 해당 호출에 대해 제공업체가 보고한 비용과 대조하여 이를 검증했으며, 두 수치가 정확히 일치했습니다. 따라서 이는 저희 측의 단위 오류가 아닙니다.

솔직한 한계점을 말씀드리자면, 이것은 단 한 번의 호출 결과였습니다. 비율은 질문의 난이도에 따라 변할 것입니다. 특정한 14.7이라는 숫자보다는 이 메커니즘 자체를 결과로 받아들이십시오. 방향성은 변하지 않습니다.

동일한 계열의 두 번째 함정이 있습니다. 일부 모델에서는 추론 (reasoning) 과정이 별도의 필드로 들어가고, 콘텐츠 (content) 필드는 빈 상태로 반환됩니다. 출력 제한 (output limit)이 엄격할 경우, 답변이 생성되기도 전에 추론 과정이 전체 예산을 모두 소모해 버립니다. 우리는 정확히 이 현상을 목격했습니다: 100 토큰 제한에서는 빈 응답이 나왔고, 200 토큰에서는 올바른 응답이 나왔습니다. 빈 응답은 모델이 능력이 없는 것처럼 보였지만, 실제로는 예산 문제의 증상이었습니다. 만약 우리가 첫 번째 결과만 믿었다면, 제대로 작동하는 모델을 폐기했을 것입니다.

대처 방법: 어떤 가격 비교 수치를 믿기 전에, 실제 요청을 하나 보내고 응답 내의 completion_tokens_details.reasoning_tokens를 확인하십시오. 그런 다음 '유용한 (useful)' 출력 토큰당 달러 비용을 계산하십시오. 만약 제공업체가 해당 필드를 공개하지 않는다면, 실제로 모델의 가격을 산정할 수 없는 것이며, 회의에서 이 점을 분명히 언급해야 합니다.

2. 저렴한 모델이 일률적으로 더 나쁜 것은 아닙니다. 그들은 다르게 실패하며, 그 차이가 핵심입니다.

핵심 요점: 모델이 멍청함에서 똑똑함까지 하나의 선상에 놓여 있다는 표준적인 사고 모델(mental model)은 당신에게 해를 끼칠 것입니다. 점수가 거의 동일한 두 모델이라도, 결정적인 순간에는 완전히 다르게 행동할 수 있습니다.

대부분의 사람들은 단일한 품질 축을 상상합니다. 비싼 것은 똑똑하고, 저렴한 것은 멍청하니, 예산에 맞는 지점을 선택하면 된다고 생각합니다. 만약 그것이 사실이라면, 모델을 선택하는 것은 단순히 예산 맞추기 작업이 될 것입니다.

하지만 그것은 사실이 아닙니다. 여기 800개의 도구 호출 (tool-calling) 태스크에 대한 모델 필드가 있습니다. 먼저, 단순 정확도 (plain accuracy)입니다:

frontier model A   95.9
frontier model B   95.1
ours               ~94
...

이 열만 본다면 저렴한 모델들이 매우 저렴한 횡재처럼 보일 것입니다. 가격은 아주 조금인데 정확도는 4% 포인트나 높으니까요.

이제 두 번째 열이 있습니다. 이 800개의 태스크 안에는 의도적인 함정들이 포함되어 있습니다. 즉, 적절한 도구를 사용할 수 없거나 요청이 잘못 형성되어 있어 거절하는 것이 올바른 행동인 요청들입니다. 이 열은 잘못된 도구를 잡지 않고 함정을 처리한 비율입니다:

frontier model A   100%
ours               100%
strong open model  100%
...

마지막 줄에서 멈추십시오. 정확도가 4%p 뒤처져 보이는 모델은 유도 질문(baited)을 받았을 때 절반의 확률로 잘못된 도구를 선택할 것입니다.

실제 권한(permissions)이 부여된 시스템에서 이것이 무엇을 의미하는지 생각해 보십시오. 이것은 단순히 "약간 덜 정확한" 수준이 아닙니다. 이는 "그에 맞는 도구가 없습니다"라고 말해야 할 상황에서 자신 있게 delete_records를 호출할 모델을 의미합니다. 평균 정확도는 가장 중요한 단 하나의 행동을 완전히 보이지 않게 만들어 버렸습니다.

해결 방법: 정답이 거절(refuse)인 작은 작업 세트를 구축하고, 거절률(refusal rate)을 별도로 측정하십시오. 절대로 이를 정확도 점수에 평균하여 포함시키지 마십시오. 만약 벤더(vendor)가 아무것도 하지 말아야 할 상황에서 모델이 어떻게 행동하는지 알려줄 수 없다면, 당신은 중요한 수치를 가지고 있지 않은 것입니다.

3. 실패 방식이 다르기 때문에, 업그레이드보다 분류(sorting)가 유리하다

핵심: 만약 저렴한 모델들이 일률적으로 성능이 낮다면, 당신이 사용할 수 있는 유일한 레버(lever)는 더 많은 비용을 지불하는 것뿐일 것입니다. 하지만 저렴한 모델들은 특정하고 예측 가능한 방식으로 실패하기 때문에, 당신에게는 훨씬 더 좋은 레버가 있습니다. 바로 각 작업을 실제로 수행할 수 있는 가장 약한 모델로 보내는 것입니다.

이것이 라우팅(routing)이며, 라우팅에서 중요한 점은 이것이 지능(intelligence)의 문제가 아니라 분류(sorting)의 문제라는 것입니다. 분류는 저렴합니다. 지능은 비쌉니다. 두 번째를 첫 번째로 전환할 수 있는 모든 순간에 당신은 승리합니다.

우리의 실제 운영 트래픽 68,369개 요청에 대한 30일간의 구체적인 모습은 다음과 같습니다:

Frontier 모델 가격 기준 동일 트래픽: $166.25
실제 발생 비용:                      ~$46 to $51
매출 총이익(Gross margin):           약 70%

하지만 내재화해야 할 부분은 그 구성(composition)입니다:

전체 비용의 84%는 비싼 모델로의 에스컬레이션(escalations)에서 발생했습니다. 그 외의 모든 것, 즉 모든 저렴한 서빙(serving)과 모든 인프라는 그에 비하면 반올림 오차 수준이었습니다.

이는 비용 조절의 핵심이 어떤 모델을 선택했느냐나 협상한 가격이 아니라는 것을 의미합니다. 핵심은 얼마나 자주 에스컬레이션을 해야 하는가입니다. 에스컬레이션 비율을 10% 줄이는 것이 어떤 벤더로부터 10% 할인을 받는 것보다 청구서에 더 큰 도움이 됩니다.

해결책: 다른 어떤 것을 최적화하기 전에 에스컬레이션 비율을 측정하십시오. 요청 중 비싼 모델이 필요한 부분이 어느 정도인지 모른다면, 시스템 비용이나 그 이유를 알 수 없습니다.

4. 검증(Verification)이야말로 저렴함을 안전하게 만드는 요소입니다.

핵심: 라우팅 자체는 도박에 불과합니다. 이것을 엔지니어링으로 바꾸는 것은 저렴한 답변이 맞는지 여부를 값싸게 확인할 수 있는 능력을 갖추는 것입니다.**

전체 접근 방식이 의존하는 비대칭성이 여기에 있습니다:

정확한 답변을 생성하는 것은 비용이 많이 듭니다. 하나를 확인하는 것은 종종 매우 저렴합니다.

여러분은 이미 일반 소프트웨어에서 이것을 알고 있습니다. 함수를 작성하는 것이 어려운 부분입니다. 테스트를 실행하는 것은 쉬운 부분입니다. 이 비대칭성은 모델이 함수를 작성하더라도 사라지지 않으며, 여러분이 활용해야 할 것입니다.

활용 가능한 저렴한 검증 방법들: 테스트를 실행하십시오. 타입을 확인하십시오. 컴파일되는지 살펴보십시오. 그리고 사람들이 충분히 사용하지 않는 한 가지 더: 두 개의 독립적인 모델에게 물어보고 의견이 일치하는지 확인하십시오.

저희가 이 마지막 방법을 측정했습니다. 테스트할 질문이 없는 경우, 두 개의 독립적인 엔드포인트를 사용하여:

두 모델의 답변이 일치했을 때, 답변이 틀릴 확률: 0.00 (n=160)
그들이 일치한 빈도: 76%

이 160개의 사례는 의도적으로 어려운 함정을 포함하여 네 가지 작업군에 걸쳐 있었습니다.

이것이 실제로 무엇을 사주는지 읽어보십시오. 이것은 '저렴한 모델로 충분하다'라는 희망이 아닙니다. 이것은 다음과 같습니다: 76%의 시간 동안 저렴한 답변을 사용할 수 있고, 그리고 그렇게 할 수 있다는 것을 알게 됩니다. 나머지 24%는 비싼 모델로 에스컬레이션됩니다.

이것이 도박과 분류(sorting) 사이의 차이입니다. 여러분은 저렴한 모델이 맞기를 바라는 것이 아닙니다. 언제 그것이 맞았는지 알려주는 테스트를 가지고 있습니다.

해결책: 모델에 보내는 모든 작업 유형에 대해, 그 답변을 어떻게 값싸게 검증할지 적어보십시오. 만약 그렇게 할 수 없다면, 그 작업 유형은 아직 라우팅 후보가 아니며, 이것을 아는 것은 구축하기 전에 유용합니다.

5. 벤치마크는 여러분이 원하는 행동을 적극적으로 처벌합니다.

핵심 요점: 리더보드는 올바른 거절을 실패로 점수 매깁니다. 만약 리더보드를 기준으로 모델을 선택한다면, 당신은 안전성을 배제하는 선택을 하고 있는 것입니다.

이 부분은 매우 명시적으로 짚고 넘어갈 가치가 있습니다. 왜냐하면 이는 직관에 어긋나며 비용이 많이 드는 문제이기 때문입니다.

실제 서비스(production) 환경의 에이전트에게 가장 가치 있는 행동은 요청이 모호하거나, 형식이 잘못되었거나, 혹은 자신의 권한 밖일 때 행동하기를 거부하는 것입니다.

주요 에이전트 벤치마크(benchmarks)는 **작업 성공(task success)**을 측정합니다. 거절은 실패한 작업으로 간주됩니다. 그들은 "위험한 일을 하라는 요청을 올바르게 거절함"에 대해 어떠한 점수도 부여하지 않습니다.

따라서 실제 서비스의 안전성을 위해 튜닝된 시스템은, 항상 시도하다가 가끔 치명적인 오류를 범하는 시스템보다 헤드라인 수치(headline number)에서 더 낮은 점수를 받게 됩니다.

이 점을 깊이 생각해보십시오. 모든 사람이 비교하는 공개 지표는, 이 구체적이고 중요한 측면에서 잘못된 방향을 가리키고 있습니다.

대응 방안: 그럼에도 불구하고 벤치마크를 실행하십시오. 당신의 고객과 경쟁사들이 실행할 것이기 때문입니다. 하지만 매번 작업 성공률(task-success rate) 바로 옆에 잘못된 행동률(wrong-action rate)을 함께 보고하십시오. 그리고 누군가 당신에게 공개적으로 벤치마크를 들이대기 전에, 내부적으로 두 수치를 모두 파악하고 있어야 합니다.

6. 경제성을 결정하는 것은 아키텍처가 아니라 워크로드의 형태입니다

핵심 요점: 단일화된 요청당 혼합 비용(blended cost-per-request) 수치는 이것이 당신에게 수익성이 있는지 여부를 실제로 결정하는 변수를 가립니다.

동일한 시스템을 통과하는 두 가지 워크로드(workloads):

도구 호출(Tool-calling) 작업: 거의 항상 비싼 모델이 필요하지 않음
코딩(Coding) 작업: 새로운 문제의 약 57%가 상위 모델로 에스컬레이션됨

동일한 코드. 동일한 모델. 동일한 가격. 하지만 하나는 엄청난 수익을 내고, 다른 하나는 수익이 매우 적습니다.

우리의 건전한 마진(margin)은 부분적으로 우리의 트래픽이 도구 호출(tool-calling) 비중이 높기 때문에 존재합니다. 작업의 대부분이 새로운 코딩인 고객은 실질적으로 훨씬 더 나쁜 경제성을 경험하게 될 것이며, 우리가 우리의 수치를 그들에게 인용하는 것은 정직하지 못한 일일 것입니다.

제가 이렇게 솔직하게 말씀드리는 이유는 업계 전체가 혼합 수치(blended numbers)를 인용하기 때문입니다. 그리고 혼합 수치는 당신의 작업 구성(mix)에 대한 숨겨진 가정을 담고 있습니다.

대응 방법: 누군가 AI 시스템의 요청당 비용(cost-per-request)을 제시한다면, 당신의 첫 번째 질문은 "어떤 작업 구성(mix)을 기준으로 한 것인가?"여야 합니다. 만약 그들이 답을 내놓지 못한다면, 그 수치는 당신의 것이 아니라 그들의 트래픽을 설명하는 것뿐입니다. 그리고 무엇인가를 예측하기 전에 당신만의 작업 구성(mix)을 먼저 측정하십시오.

7. 한계치(ceiling)를 정직하게 공개하십시오. 누군가는 반드시 그것을 찾아낼 것이기 때문입니다.

핵심 요점: 우리는 코드 측면에서 대등한 수준(parity)에 와 있는 것이지, 앞서 있는 것이 아닙니다. 그렇게 말하는 것만이 회의론자와 마주했을 때 살아남을 수 있는 유일한 버전입니다.

캐시가 없는 깨끗한 상태에서 표준 코딩 벤치마크(coding benchmark)를 실행했을 때:

우리의 캐스케이드(cascade):        92.1
프런티어 모델 A:               92.7
프런티어 모델 B:               93.3
...

네 가지 모두 동일한 테스트 환경(harness)을 사용했습니다. 우리는 프런티어(frontier) 모델보다 약간
낮은 수준입니다. 아키텍처(architecture) 자체만으로 저가형 모델보다 약 11포인트를 더해줍니다.

우리는 "프런티어를 능가한다"라는 문구의 유혹을 느꼈습니다. 하지만 측정 결과가 이를 뒷받침하지 않았기에 사용하지 않았습니다. 대등함(Parity)이 정직한 표현이며, 훨씬 적은 비용으로 구현하는 대등함이 실제 제품의 가치입니다.

대응 방법: 당신을 치켜세워주지 않는 수치만이 출판할 가치가 있는 유일한 수치입니다. 왜냐하면 고객이 직접 재실행했을 때 견뎌낼 수 있는 수치는 그것뿐이기 때문입니다. 검증을 견뎌낼 수 없는 주장은 지연된 도화선을 가진 부채(liability)와 같습니다.

8. 가장 어려운 부분은 시스템을 구축하는 것이 아닙니다. 자신의 측정값을 신뢰하는 것입니다.

핵심 요점: 잘못된 측정은 측정을 하지 않는 것보다 더 위험합니다. 왜냐하면 잘못된 측정에는 확신(confidence)이 뒤따르기 때문입니다.

이것은 제가 독자들이 가장 얻어갔으면 하는 부분입니다. 왜냐하면 당신이 위에서 언급한 것들을 구축하든 하지 않든 상관없이 적용되는 원칙이기 때문입니다.

단 한 번의 작업 세션 동안, 우리는 일곱 개의 별개 경보(alarm)를 추적했습니다. 일곱 개 모두 실제 문제가 아니라 고장 난 측정 도구였습니다. 79행짜리 파일에서 단 5행만 읽고는 재앙이라고 보고하는 파서(parser). 자신의 콘솔 출력값과 에러 문자열을 대조하여 스스로 출력한 "에러"를 찾아내는 체커(checker). 실제 수치는 27%인데 하드 리밋(hard limit)의 135%라고 보고하는 계측기.

운영 환경(production)에서 발생한 세 가지 사례가 더 있으며, 모두 교훈적입니다:

우리는 모든 트래픽 급증(traffic burst)의 3분의 2를 놓치고 있었으며, 이를 인지조차 하지 못했습니다. 우리 서버에는 과부하가 발생했을 때