더 저렴한 API가 2.5배 더 쌌지만, 비용은 1.6배 더 많이 들었습니다

AI-공개 (AI-disclosure): AI의 도움을 받아 초안을 작성하고 사람이 검토했습니다. 데모 수치는 아래에 전체 포함된 결정론적(deterministic)이고 표준 라이브러리(stdlib)만 사용하는 Python 스크립트의 출력값(stdout)을 그대로 가져온 것입니다. 스크립트를 다시 실행하면 동일한 바이트를 얻을 수 있습니다. 해당 스크립트의 시도 횟수는 회계 메커니즘을 연습하기 위해 제가 선택한 합성(SYNTHETIC) 고정값이며, 제가 사용하는 스크레이퍼(scraper) 로그(Apify 히스토리의 실행 횟수)에서 관찰되는 재시도 왜곡(retry skew)에 맞춰 조정되었습니다. 이는 특정 벤더의 API나 가격에 대한 벤치마크(benchmark)가 아닙니다. 유일한 외부 주장(성공한 작업당 비용 공식)은 출처를 밝히고 링크를 연결했습니다.

더 저렴한 API는 호출당 2.5배 더 저렴했습니다. 하지만 월간 청구액은 어쨌든 더 높게 나왔습니다.

단순한 반올림 오차 때문이 아닙니다. "저렴한" 옵션은 표기된 가격이 더 높은 옵션보다 성공한 작업당 비용이 1.63배 더 많이 들었습니다. 작업량은 동일했습니다. 가격 페이지에는 결코 이 숫자가 표시되지 않았습니다. 가격 페이지는 여러분의 성공률(success rate)을 알지 못하기 때문입니다. 여러분은 이미 결제를 마친 후에야 그 사실을 알게 됩니다.

이것이 호출당 가격이 숨기고 있는 산술입니다. 그리고 이것은 지출한 후에 덧붙이는 상한선이 아니라, 지출하기 전에 내려야 하는 결정입니다.

요약 (TL;DR)

여러분은 두 API 티어(tier)를 호출당(또는 토큰당) 가격으로 비교하고 더 저렴한 것을 선택합니다. 하지만 그 순위는 틀릴 수 있습니다.
여러분은 성공 여부와 상관없이 모든 시도에 대해 비용을 지불합니다. 실제로 비용을 결정하는 분모는 호출 횟수가 아니라 **성공한 작업(successful tasks)**입니다.
실제 비용 = 시도당 가격 × 시도 횟수 ÷ 성공 횟수. 성공률이 낮은 저렴한 티어는 재시도(retries) 과정에서 할인 혜택을 다 써버립니다.
아래 실행 결과에서: 저렴한 티어는 호출당 $0.0020이지만 성공당 $0.0096입니다. 반면 견고한(robust) 티어는 호출당 $0.0050이지만 성공당 $0.0059입니다. 표기 가격의 승자가 패배합니다.
에이전트(agent)를 위해 API, 모델 또는 티어를 선택하려는 분이라면: 일주일 동안 시도 횟수와 성공 횟수를 기록하고, 나누어 본 뒤 결정하십시오. 하단에 70줄짜리 스크립트가 있으니 여러분의 수치를 입력해 보세요.

가격 페이지는 표기된 가격일 뿐, 실제 청구서가 아닙니다

여기에 명확하게 기술된 함정이 있습니다. 가격 페이지의 숫자는 **호출 (call)**당 가격입니다. 인보이스(invoice)에 찍히는 숫자 역시 호출당 가격이지만, 여러분이 얻은 가치는 **성공한 작업 (successful task)**당 가치입니다. 이 둘은 분모가 다르며, 그 차이가 바로 실패한 작업의 양입니다.

모든 시도는 비용이 청구됩니다. 타임아웃(timeout)이 발생하여 재시도된 호출도 청구됩니다. 형식이 잘못되어(malformed) 다시 프롬프트를 입력한 호출도 청구됩니다. 네 번째 시도에서 성공한 호출은 네 번의 비용이 청구됩니다. 만약 특정 티어(tier)가 작업의 35%를 실패하고, 어려운 작업을 해결하기 위해 각 작업당 3~6번의 시도를 소모한다면, 여러분은 실제로 사용할 수 있는 결과물을 전혀 만들어내지 못한 수많은 호출에 대해 비용을 지불하고 있는 것입니다.

따라서 진짜 질문은 "어떤 티어가 호출당 더 저렴한가"가 아닙니다. "내가 실제로 완료한 작업당 어떤 티어가 더 저렴한가"입니다. 이 질문에 대한 답은 서로 다른 티어를 가리킬 수 있습니다. 만약 답이 달라진다면, 표기된 가격(sticker price)으로 순위를 매기는 것은 패배자를 선택하는 일이 됩니다.

공식은 한 문장에 들어갈 정도로 간단합니다:

성공한 작업당 비용 = 시도당 비용 ÷ 성공률 (success rate)

Codebridge는 2026년 2월에 작성된 _Real Cost per Successful Task_라는 제목의 글에서 이를 동일하게 설명했습니다: "시도당 0.01달러가 들지만 성공률이 50%뿐인 모델은 실질적으로 성공당 0.02달러의 비용이 듭니다." 또한 "시도된 작업과 완료된 결과 사이의 간극에 실제 비용의 대부분이 포함되어 있습니다." (codebridge.tech) 메커니즘은 동일합니다. 여기서 제가 기여하는 바는 공식 자체가 아니라, 재현 가능한 수치를 통해 순위가 뒤바뀌는 것을 보여주고, 현실적인 재시도(retry) 형태가 어디에서 기인하는지를 보여주는 것입니다.

역전 현상 측정하기

이 역전 현상을 구체화하기 위해 작은 스크립트를 작성했습니다. 이 스크립트는 결정론적(deterministic)입니다. 표준 라이브러리(stdlib)만 사용하며, 네트워크, 난수(random), 시계(clock)를 사용하지 않습니다. 두 개의 티어를 대상으로 각각 40개의 작업을 수행합니다. 각 작업에 대해 비용이 청구된 시도 횟수와 최종 성공 여부를 기록합니다. 그런 다음 티어당 세 가지 수치를 계산합니다: 호출당 비용, 작업당 비용(모든 작업에 분산된 지출), 그리고 성공한 작업당 비용입니다.

중요한 사항이기에 미리 솔직하게 밝히자면, 시도 횟수(attempt counts)는 제가 메커니즘을 테스트하기 위해 **직접 작성한 합성 피스처 (synthetic fixture)**입니다. 즉, 특정 벤더를 측정한 수치가 아니라 제가 임의로 선택한 숫자입니다. 이 수치들이 임의적이지 않고 현실적인 이유는, 제가 2,190회의 전체 실행 기간 동안 자신의 스크래퍼(scraper) 운영 로그에서 목격한 편향(skew)을 반영하여 구성했기 때문입니다. 즉, 저렴하지만 불안정한 소스는 안정적인 소스보다 성공당 훨씬 더 많은 재시도(retries)를 소모합니다. 메커니즘은 실제이며, 특정 수치들은 예시일 뿐입니다. 여러분의 데이터를 넣으면 스크립트는 동일한 산술 연산을 수행합니다.

#!/usr/bin/env python3
# cost_per_successful_task.py
# 결정론적(Deterministic), 표준 라이브러리(stdlib) 전용, 네트워크 미사용. 피스처(Fixture)는 아래에 포함됨.
...

python3 -I cost_per_successful_task.py로 실행하세요. 정확한 출력 결과는 다음과 같습니다:

================================================================
성공한 작업당 비용 — 표시 가격(sticker price) vs 실제 청구액
(회계 메커니즘의 표준 라이브러리 시뮬레이션; LLM 벤치마크 아님)
...

표를 한 번 읽어보십시오. 호출당(Per call) 비용은 cheap이 $0.0020이고 robust가 $0.0050으로, 표시된 가격대로 정확히 2.5배의 할인율을 보입니다. 하지만 성공한 작업당(Per successful task) 비용은 cheap이 $0.0096이고 robust가 $0.0059입니다. 순위가 뒤집혔습니다. 할인이 사라진 것이 아니라, 성공하지 못한 14개의 작업과 그 작업을 쫓느라 발생한 재시도 비용으로 소진된 것입니다.

순위가 뒤집히는 이유: 달러당 호출 횟수가 아닌, 성공당 시도 횟수

모든 것을 설명해 주는 문장은 출력 결과의 마지막 줄에 있습니다: cheap은 26번의 성공을 위해 125번의 시도를 소모했습니다 — 성공당 4.81회의 시도입니다. robust는 39번의 성공을 위해 46번의 시도를 소모했습니다 — 성공당 1.18회의 시도입니다.

이는 사용 가능한 결과 하나를 얻기 위해 청구되는 호출 횟수에서 4배의 차이가 난다는 것을 의미합니다. 2.5배의 가격 할인은 4배의 시도 페널티를 견뎌낼 수 없습니다. 계산은 명확합니다. 0.0020 × 4.81 ≈ 0.0096. 0.0050 × 1.18 ≈ 0.0059. 저렴한 티어는 여러분이 배포하지 못하는 단위(단순 호출)에서는 더 저렴하지만, 실제로 배포하는 단위(성공한 작업)에서는 더 비쌉니다.

가운데 열도 주목하십시오. 작업당 비용(per-task) 측면에서 40개 작업 전체에 지출을 분산해 보면, 두 티어의 비용은 $0.0063 대 $0.0057로 거의 비슷해 보입니다. 하지만 이 열 자체가 하나의 함정입니다. 이 수치는 분모에 실패한 작업들을 마치 가치가 있는 것처럼 포함하여 계산합니다. 하지만 실패한 작업은 가치가 없습니다. 성공한 작업으로만 나누어 보면 실제 격차가 드러납니다.

"하지만 제 성공률은 기본적으로 비슷합니다"

여러분은 이렇게 생각할지도 모릅니다. '내 두 옵션은 65% 대 98%가 아니라, 92% 대 95% 정도라서 나에게는 해당되지 않는다'라고 말이죠. 그럴 수도 있습니다. 하지만 바로 그 점이 핵심입니다. 직접 계산해 보기 전까지는 알 수 없으며, 가격표만 보고 시도 횟수(attempt ratio)가 4배나 차이 날 것이라고 눈대중으로 파악할 수는 없습니다.

한 티어가 더 강력하게 재시도(retry)를 수행하는 경우, 성공률의 작은 차이는 보기보다 훨씬 더 큰 영향을 미칩니다. 두 가지 요소가 복합적으로 작용하기 때문입니다. 하나는 결코 성공하지 못하는 비율(순수 낭비)이고, 다른 하나는 성공한 작업에 대해 소요되는 작업당 시도 횟수(attempts-per-success)입니다. 어떤 티어는 90%라는 '괜찮은' 성공률을 유지하면서도, 어려운 작업마다 세 번의 시도를 소모할 수 있습니다. 그리고 이 두 번째 요소는 대시보드상에서는 실패로 나타나지 않습니다. 대신 더 큰 청구서로 나타납니다. 그러니 격차를 추측하지 마십시오. 로그(log)를 남기십시오.

제가 여러분에게 로그를 남기라고 권하는 만큼, 제 주장에도 솔직한 한계가 있음을 밝힙니다. 저는 두 개의 특정 LLM API를 대상으로 실제 운영 환경에서 이와 정확히 일치하는 A/B 테스트를 수행한 적은 없습니다. 재시도 편향(retry skew)은 실재하며, 이는 불안정한 소스가 안정적인 소스보다 사용 가능한 레코드당 항상 몇 배의 비용을 발생시켰던 제 스크래퍼 로그(scraper logs)에서 비롯된 것입니다. 이 시나리오에서의 두 티어 간 역전 현상은 벤더(vendor)의 벤치마크가 아니라, 그러한 패턴을 명확하게 보여주는 예시입니다. 만약 실제로 테스트를 진행했는데 격차가 작다면 — 아주 좋습니다. 여러분은 단 일주일간의 로깅 비용으로 확실성을 구매한 셈이니까요.

월요일에 해야 할 일

이 변화는 기술적인 것이 아니라 절차적인 것이며, 티어를 결정하기 전에 이루어져야 합니다. 청구서를 보고 놀란 뒤에 추가하는 지출 한도(spending cap)가 아닙니다.

각 옵션당 두 개의 카운터 기록: 청구된 시도 횟수(billed attempts)와 성공한 작업(successful tasks)입니다. 대부분의 SDK는 이미 시도/재시도(attempt/retry) 횟수를 제공하지만, 제공하지 않는다면 재시도 래퍼(retry wrapper)에서 카운터를 증가시키세요.
각 티어에서 일주일간 실행 (또는 동일한 워크로드를 양쪽 모두에 공정하게 샘플링하여 실행). 합성 핑(synthetic ping)이 아닌 실제 작업이 필요합니다. 저렴한 티어에서 비용이 새어나가는 지점은 바로 당신의 까다로운 케이스(hard cases)들입니다.
가격 페이지가 아니라 총 지출 ÷ 성공 횟수로 순위를 매기세요. 이 단 한 번의 나눗셈이 결정의 전부입니다.
그다음 선택하세요. 만약 저렴한 티어가 성공당 비용(cost-per-success) 측면에서 여전히 승리한다면, 확신을 가지고 선택하십시오. 만약 결과가 뒤집힌다면, 당신은 단순히 겉보기에 더 저렴해 보이는 가격 때문에 1.6배 더 많은 비용을 지불하는 상황을 방지한 것입니다.

이것은 모든 예산 가드레일(budget guardrail)보다 상위 단계의 작업입니다. 지출 한도(spending cap)는 잘못된 선택을 하여 비용이 새어나가기 시작한 후에야 당신을 막아줍니다. 성공당 비용을 기준으로 선택한다는 것은, 애초에 시도 횟수를 덜 낭비하는 티어를 선택했기 때문에 제한해야 할 금액 자체가 적어진다는 것을 의미합니다. (만약 하위 단계의 가드레일도 원한다면, HTTP 402 예산 관련 글이 이 내용의 나머지 절반입니다. 그것은 실행 도중의 지출을 제한하는 것에 관한 것이고, 이것은 실행 전에 어떤 옵션을 선택할지에 관한 것입니다.)

가격 페이지는 그들이 가장 저렴해 보이게 만드는 수치인 '호출당 가격'을 판매합니다. 하지만 당신의 인보이스(invoice)를 결정하는 수치는 '성공한 작업당 가격'입니다. 전환하기 전에, 당신의 로그를 사용하여 직접 두 번째 수치를 계산해 보십시오.

재시도 횟수를 계산했을 때, 표시 가격(sticker price)과 실제 성공당 비용 사이에서 목격한 가장 큰 격차는 얼마였나요? 저는 최악의 역전 사례들을 수집하고 있습니다. 댓글로 남겨주세요. 👇

실제 운영 환경에서의 다음 성공당 비용 수치들을 확인하려면 팔로우하세요. 모든 댓글을 읽습니다.