토큰은 싸져 가는데 AI 청구서는 왜 커질까?

2023년 GPT-4 API 입력 단가는 100만 토큰당 $30이었습니다. 2024년 말에는 같은 급의 모델이 $3 아래로 떨어졌고, 2025년에는 Haiku급이 $1을 밑돌았습니다. 단가만 보면 AI는 분명히 싸져 가고 있습니다.

그런데 지난달 청구서를 열면 대부분 같은 반응을 합니다: 작년보다 왜 더 나왔지?

착각이 아닙니다. 벤더가 덫을 파 놓은 것도 아닙니다. 160년 된 경제학 법칙이 AI 시대에 다시 재현되고 있는 것입니다——제봉스 역설(Jevons Paradox)입니다.

핵심 결론

토큰 단가가 절반이 될 때마다 실제 사용량은 보통 3~5배 늘어납니다. 단가 하락으로 아낀 금액은 늘어난 소비에 통째로 잡아먹히고, 총 청구액은 오히려 올라갑니다.

−97%

GPT-4급 모델
단가 2023→2026

10×

동기간 평균
토큰 사용량 증가

3×

개발자 AI 월 청구
동기간 평균 증가

제봉스 역설: 싸질수록 더 쓴다

1865년 경제학자 윌리엄 스탠리 제봉스는 석탄 연구에서 역설적인 현상을 발견했습니다. 증기기관 효율이 오를 때마다 석탄 총소비량은 줄지 않고 늘었습니다. 단위 비용이 내려가니 원래 못 쓰던 공장이 들어서고, 한 라인이던 곳이 세 라인이 되는 식입니다.

「단위당 절약」이 「총 절약」을 뜻하지 않습니다. 이것이 제봉스 역설입니다: 자원이 더 효율적(또는 저렴)해지면, 총수요는 줄기보다 늘어나는 경우가 많다.

토큰 이야기도 완전히 같습니다. 단가가 한 자릿수 내려갈 때마다 「너무 비싸서 포기했던」 유스케이스가 한꺼번에 풀립니다.

$30/M일 때는 주간 보고 요약만 AI에 맡깁니다.
$3/M이 되면 코드 리뷰도 돌리기 시작합니다.
$0.3/M에서는 백그라운드 Agent, 고객 티켓, 시간마다 로그 스캔까지 넣습니다.
$0.03/M이 되면 워크플로 전체를 넘기고 끄는 걸 잊어버립니다.

매번 가격 인하는 「절약」이 아니라 「더 써도 된다」는 신호입니다. 단가는 내려가는데 청구 총액은 조용히 올라갑니다.

청구가 부풀어 오르는 세 가지 구조적 원인

제봉스 역설은 「왜」를 설명합니다. 비용을 잡으려면 돈이 어디서 타는지 알아야 합니다. AI API 청구에서 구조적으로 부풀리는 세 가지 원인이 있습니다.

원인 1: 사용량 폭발——「가끔 물어보기」에서 「상시 백그라운드」로

2년 전 전형적인 패턴은 「막힐 때만 ChatGPT」였습니다. 지금 한국 스타트업·소규모 팀에서는 Cursor, OpenClaw, 자작 스크립트가 동시에 돌아가며, AI 비용이 「개인 구독」이 아니라 「팀 burn rate」 항목으로 올라갑니다. 잠자는 동안 CI 로그를 요약하고, 회의 중에 레포를 정리하고, 점심에 사용자 피드백을 처리합니다——AI는 「수동 Q&A」에서 「능동 실행」으로 바뀌었습니다.

호출 빈도는 「하루 수십 번」에서 「하루 수천 번」으로. 호출당 단가가 1/10이어도 총량으로 보면 청구는 쉽게 배가 됩니다. 시리즈 A 이전 팀이라면 「이번 달 API 몇 만 원 더 나왔네」가 곧 runway 일수로 이어지는 경우가 많습니다.

사용 단계	전형적 호출 빈도	호출당 토큰	월간 토큰 총량
Q&A 보조 (2023)	30회/일	~500 tokens	~450K tokens
코드 Review (2024)	200회/일	~3,000 tokens	~18M tokens
상시 Agent (2025+)	2,000회/일	~8,000 tokens	~480M tokens

마지막 줄에 주목하세요: 450K에서 480M——약 1000배입니다. 같은 기간 단가가 90% 떨어져도 청구는 2023년 대비 100배가 될 수 있습니다.

원인 2: 컨텍스트 비대화——한 번 요청의 「무게」가 달라졌다

더 은밀한 청구 킬러는 「횟수」가 아니라 「한 번의 부피」입니다.

2023년 GPT-3.5 컨텍스트는 4K였습니다. 지금은 Claude Sonnet 200K, Gemini 2.5 Pro 1M. 팀이 커질수록 「컨텍스트를 깎자」보다 「레포 전체를 넣자」가 기본이 됩니다. 스타트업에서 흔한 패턴: 신입 한 명이 @codebase로 전체 모노레포를 매 PR마다 실어 보내고, CTO는 월말에 「왜 API가 인건비만큼 나왔지?」를 봅니다.

컨텍스트의 숨은 비용

500KB 소스 파일을 prompt에 넣으면 약 125,000 토큰——2023년 한 달 typical 사용량을 넘깁니다. Agent가 매 요청마다 풀 컨텍스트를 끌고 다니면 청구는 선형이 아니라 지수적으로 커집니다.

여기에 「extended thinking」 모드까지 더해집니다. 최종 답 전에 내부 추론 토큰이 대량 발생하고, 그것도 과금됩니다. 한 번의 「깊은 분석」이 예상의 5~10배이 되는 일은 흔합니다.

원인 3: Agent 승수——토큰은 덧셈이 아니라 곱셈

청구 부풀림에서 가장 날카로운 부분입니다.

Q&A 모드에서는 요청 1번 = 과금 1번. Agentic 워크플로에서는 사용자 지시 1개가 호출 체인 전체를 켭니다.

그림 1 · 「간단한」Agent 요청의 내부 호출 체인

사용자 지시 1건「이 PR 리뷰하고 수정안 줘」

Orchestrator Agent서브태스크 분할 → LLM 1회

자식 Agent ×4코드 읽기·문서 검색·테스트 확인·코멘트 생성 → 매번 풀 컨텍스트

집계 + 재시도오류 시 자동 재시도 → 2~3회 추가

사용자는 한 줄 보냈을 뿐인데 실제로는 7~8번의 LLM 호출. 버튼은 한 번 눌렀는데 청구서에는 여덟 줄이 찍힙니다.

더 위험한 건 종료 조건 없는 Agent 루프입니다. CI에 「실패 테스트 자동 수정」 Agent를 붙이고 max retry를 안 걸어두면, flaky test 하나가 8시간에 2,300회 호출, $340를 만들 수 있습니다. 단가가 싸도 승수가 크면 어떤 가격이든 큰 숫자가 나옵니다.

실제 사례

한 스타트업이 CI에 「자동 테스트 수리」 Agent를 연결한 뒤 최대 재시도를 설정하지 않았습니다. 우발적 flaky test가 루프를 유발해 8시간 동안 2,300회 LLM 호출, 청구 $340. 모델은 이미 쌌습니다. 승수만 크면 됩니다.

청구를 쪼개 보기: 냉정한 산수

오늘의 전형적 시나리오: 하루 Agent 작업 10건, 작업당 평균 8회 LLM 호출, 호출당 평균 10,000 토큰(컨텍스트 포함).

파라미터	값
하루 Agent 작업 수	10
작업당 LLM 호출(승수)	8
호출당 토큰	10,000
월간 토큰 총량	10 × 8 × 10,000 × 30 = 24M tokens
단가(Sonnet급 $3/M)	24M × $3/M = $72/월
고가 모델($15/M) 사용 시	24M × $15/M = $360/월

$72~$360/월은 개발자 1명의 일상만입니다. 팀이 10명이거나 Agent 작업이 두 배면 숫자도 그대로 곱해집니다. 청구 크기는 「AI를 쓰느냐」가 아니라 「승수 체인이 얼마나 길느냐」로 결정됩니다. 스타트업 CFO 관점에서는 「인당 $72」가 「팀 $720」이 되는 순간 runway 표에 바로 반영됩니다.

청구를 통제하기: 덜 쓰는 게 아니라 의도적으로 쓰기

제봉스 역설의 교훈은 「쓰지 마라」가 아니라 「구조를 맞춰라」입니다. 석탄 소비 증가는 산업혁명을 가져왔고, 토큰 소비 증가도 생산성 혁명을 가져옵니다. 문제는 그 청구에 맞는 가치가 나오고 있느냐는 것입니다.

바로 적용할 수 있는 세 가지——구현 비용 낮은 순입니다.

방법 1: 계층 라우팅——싼 모델에 대량 작업을 태우기

모든 작업에 최강 모델이 필요하지 않습니다. 「이 코드에 문법 오류 있나」와 「시스템 전체 설계」는 요구 지능이 한 자릿수 차이 납니다. 둘 다 Claude Sonnet을 쓰면 청구도 한 자릿수 차이 납니다.

복잡도 기준 세 단계가 실무적입니다.

포맷·요약·단순 분류: Haiku / GPT-4o-mini급 ($0.15~$0.3/M)
코드 생성·다단 추론·문서 작성: Sonnet / GPT-4o급 ($3~$5/M)
아키텍처 설계·난해한 디버깅·extended thinking: Opus / o3급, 필요할 때만

구현은 LiteLLM 같은 Gateway에서 모델 별칭(fast / smart / deep)을 정의하고, 클라이언트는 작업 유형별로 라우팅합니다. 마스터 키와 규칙은 클라우드 Mac Gateway에 모읍니다——클라우드 Mac + OpenRouter 실전 가이드의 3계층 라우팅이 그대로 뼈대가 됩니다. OpenRouter 공식 문서와 맞추면 Cursor·OpenClaw·스크립트가 같은 엔드포인트를 바라보게 할 수 있습니다.

방법 2: 예산 차단——타버리기 전에 차단기 내리기

계층 라우팅은 「맞는 모델」, 예산 차단은 「통제 불가한 사용량」을 잡습니다. Agent 루프, 예상 밖 재시도, 종료 조건 없는 장시간 작업——이론이 아니라 Agent를 진지하게 쓰는 팀이 반드시 밟는 지뢰입니다. 3인 팀이면 「누가 어떤 키로 뭘 돌렸는지」부터 추적이 어려워집니다.

최소 두 겹의 방어가 필요합니다.

상류 credit cap: OpenRouter·Anthropic 콘솔에서 월간 하드 한도. 초과 시 API가 거절하고 조용히 과금되지 않습니다.
Virtual Key 단위 spend cap: LiteLLM 자체 호스팅 Gateway에서 Cursor·OpenClaw·스크립트마다 Virtual Key를 나눠 개별 월 예산을 겁니다. 한 도구가 폭주해도 나머지는 안전합니다.

LiteLLM Virtual Key 생성 예시 (API)

curl -X POST http://127.0.0.1:4000/key/generate \
                  -H "Authorization: Bearer $LITELLM_MASTER_KEY" \
                  -H "Content-Type: application/json" \
                  -d '{
                    "key_alias": "cursor-dev",
                    "models": ["fast", "smart"],
                    "max_budget": 20,
                    "budget_duration": "1mo",
                    "metadata": {"tool": "cursor", "env": "dev"}
                  }'

이 Virtual Key는 월 $20 상한, fast와 smart만 사용 가능. 초과 시 429로 차단되고 마스터 키는 영향 없습니다. 소규모 팀용 「최소 엔터프라이즈 거버넌스」입니다.

방법 3: 로그 가시화——어디서 타는지 모르면 못 줄인다

많은 청구 문제는 「월말에야 알게」 됩니다. 금요일 밤 Agent가 $50를 조용히 태웠는데 작업은 이미 끝났다——실시간 spend 뷰가 없으면 막을 수 없습니다. 스타트업에서는 이게 곧 「이번 달 마케팅 예산을 API가 먹었다」는 슬랙 스레드로 이어지기도 합니다.

최소 가시성 스택:

LiteLLM 내장 Dashboard: litellm --detailed_debug 후 /ui에서 Virtual Key별 spend·요청량·지연 확인 (공식 문서).
일일 spend 알림: cron으로 DB 집계, 임계치 넘으면 Slack——OpenClaw Slack 연동이 그대로 씁니다.
상류 청구 대조: 주 1회 LiteLLM 로컬 spend와 OpenRouter 콘솔 비교. 10% 이상 차이는 Gateway 우회 「누수 요청」 신호입니다.

가시화의 가치

spend 모니터링을 넣은 팀 대부분은 첫 달에 20~30% 「무효 소비」를 찾습니다——결과를 아무도 안 읽는 상시 Agent, 매번 풀 컨텍스트만 실어 나르는 스크립트, cron에 남은 옛 작업 등.

진짜 질문은 「어떻게 아끼나」가 아니다

제봉스 역설의 자주 놓치는 면: 효율 향상 자체를 부정하지 않았다는 것. 석탄 총소비는 늘었지만 영국은 산업혁명을 이뤘습니다.

마찬가지로 토큰이 싸지고 AI 청구가 오르는 것이 반드시 나쁜 건 아닙니다. 물어야 할 것은:

늘어난 토큰이 그만큼의 가치를 만들고 있는가?
청구 중 「의도적 투자」와 「무의식 낭비」 비율은?
위 두 가지에 언제든 답할 수 있는 시스템이 있는가?

「토큰을 아낀다」는 목표는 틀렸습니다. 「모든 토큰이 날카롭게 쓰인다」가 맞는 목표입니다. 계층 라우팅, 예산 차단, 소비 가시화——이 셋은 덜 쓰려는 게 아니라 무엇을 어디에 쓰고 그만한 가치가 있는지 아는 장치입니다.

토큰은 계속 싸질 것이고, 청구도 계속 오를 겁니다. 거버넌스 구조가 갖춰져 있으면, 적어도 「오를 만한 부분」만 오릅니다.

FAQ

제봉스 역설은 영원히 성립하나요? 효용에 상한이 없는 자원에서는 대체로 성립합니다. AI 추론은 인력을 거의 무한히 대체할 수 있어 가격이 내려갈 때마다 새 유스케이스가 열립니다. 능력의 천장에 닿는 날에는 약해지겠지만, 그날은 아직 안 보입니다.

싼 모델로 바꾸면 청구를 잡을 수 있나요? 단기엔 됩니다. 싼 모델로 충분하다는 걸 알면 남은 예산을 다른 작업에 쓰고, 다시 제봉스 궤도로 돌아갑니다. 지속 가능한 건 「예산 제약 + 가시화」이지 모델 다운그레이드만이 아닙니다.

Agent 승수 효과를 없앨 수 있나요? 완전히는 못 없애지만 통제는 가능합니다. ① 각 Agent에 최대 스텝·최대 호출 수, ② 결과 캐시로 동일 서브태스크 재실행 방지, ③ Orchestrator에서 「LLM이 꼭 필요한가」 판단——많은 단계는 규칙 엔진이 수백 배 쌉니다.

팀이 커지면 통제가 더 어려워지나요? 그렇습니다. 사람이 늘수록 「누가 어떤 모델로 무엇을 도는지」 추적이 어려워집니다. Gateway Virtual Key 분리와 per-user spend cap은 3명 넘기 전엔 「있으면 좋음」에서 「필수」로 바뀝니다. 나중에 옮기면 마이그레이션 비용이 더 큽니다.