AI API 비용 폭탄 막는 법 — $500M 사고로 배우는 사용량 제한 실전 가이드
자동화 파이프라인이 멈추지 않으면 청구서도 멈추지 않는다
보안 쪽 일을 하다 보면 “돈이 새고 있다”는 알람을 새벽에 받는 경우가 생긴다. 나는 그걸 직접 경험했다. 에이전트 파이프라인 하나가 루프를 타면서 6시간 동안 API를 쉬지 않고 두드렸고, 청구서가 평소의 40배 가까이 찍혔다. 그게 수백만 원 수준이라 다행이었지, 이 글에서 다루는 사고는 스케일이 완전히 다르다.
$500M 청구서 — 무슨 일이 있었나
Reddit r/artificial에 올라온 한 스레드가 최근 개발자·CTO 커뮤니티에서 바이럴이 됐다. 한 기업이 한 달 만에 Claude API 비용으로 약 $500M(5억 달러)을 소진했다는 내용이다. 기술 버그는 아니었다. API는 정상 작동했고, 요청도 전부 처리됐다. 문제는 오작동하는 자동화 파이프라인이 아무런 제동 없이 계속 요청을 보낼 수 있는 환경이었다는 것이다.
이 사고의 핵심 원인은 단 하나다: 월별 소비 상한선 미설정.
Anthropic API는 기본적으로 소비 상한이 없다. 크레딧 카드가 한도에 걸릴 때까지, 혹은 Anthropic 측에서 이상 징후를 탐지할 때까지 요청은 계속 처리된다. 소규모 사이드 프로젝트에서 “그냥 쓰다 보면 알아서 되겠지”라고 생각하면 어느 날 아침 청구 이메일이 생애 첫 쇼크를 줄 수 있다.

왜 이게 가능한가 — Anthropic API의 기본 설정
Anthropic Console에서 새 API 키를 발급받으면 기본 상태는 다음과 같다.
- Monthly spend limit: 미설정 (없음)
- Usage tier: Tier 1~4로 나뉘며, 기본 신규 계정은 Tier 1 (일 $100 미만 소비 시)
- 초과 알람: 없음
- 자동 차단: 없음
Tier 1이라고 안심하면 안 된다. Tier 1은 일 소비가 특정 금액 이하일 때 적용되는 속도 제한이지, 상한선 설정이 아니다. 파이프라인이 짧은 요청을 초당 수십 개씩 보내면 Tier 1에서도 하루에 수천 달러가 나올 수 있다.
신용카드 결제 방식이라면 카드 한도가 자연 차단막이 될 수 있지만, 기업 계정은 후불 인보이스 방식이 대부분이라 한도 개념 자체가 없다. $500M 사고가 기업에서 발생한 이유다.
실전 방어 3단계
1단계: Monthly Spend Limit 설정
가장 먼저 해야 할 일. Anthropic Console → Settings → Limits 에서 설정한다.
Anthropic Console└─ Settings └─ Limits ├─ Monthly budget: $XXX (원하는 금액 설정) └─ Notify at: 80% 사용 시 이메일 알람이 값은 절대 상한이 아니다. 설정값을 초과해도 즉시 차단은 안 되지만, 알람이 오고 Anthropic 내부 플래그가 걸린다. 완전한 자동 차단을 원하면 2단계와 3단계를 같이 적용해야 한다.
추천 설정값: 현재 월 평균 소비의 3-5배. 파이프라인 스파이크를 허용하면서도 사고 규모를 제한할 수 있는 범위다.
2단계: Usage Tier 이해 + Rate Limit 활용
Rate limit은 과금 방어가 아니라 처리량 제한이지만, 파이프라인 폭주를 조기에 잡는 데 도움이 된다. 요청이 429 Too Many Requests를 받기 시작하면 코드 쪽에서 이상을 감지할 수 있다.
import anthropicfrom anthropic import RateLimitError
client = anthropic.Anthropic()
def safe_request(prompt: str, max_retries: int = 3): for attempt in range(max_retries): try: response = client.messages.create( model="claude-sonnet-4-6", max_tokens=1024, messages=[{"role": "user", "content": prompt}] ) return response except RateLimitError as e: if attempt == max_retries - 1: raise # 재시도 소진 → 상위로 에러 전파 time.sleep(2 ** attempt) # exponential backoff return None중요한 건 RateLimitError를 잡아서 무한 재시도하는 패턴이 오히려 사고를 키운다는 것이다. 위 코드처럼 재시도 횟수에 반드시 상한을 둬야 한다.
3단계: 초과 알람 훅 연결
Anthropic 자체 알람 외에 자기 인프라에도 방어선을 세운다. 핵심은 주기적으로 현재 사용량을 당겨서 임계값을 넘으면 파이프라인을 멈추는 것이다.
import anthropicimport os
def check_usage_and_halt(threshold_usd: float = 100.0): """ 현재 월 사용량 확인 — 임계값 초과 시 True 반환 (파이프라인 중단 신호) """ client = anthropic.Anthropic(api_key=os.environ["ANTHROPIC_API_KEY"])
# Usage API (현재 Beta — 2026-06 기준) # from anthropic.types import UsageResponse 등 버전별 확인 필요 usage = client.beta.usage.monthly() current_spend = usage.total_cost_usd
if current_spend >= threshold_usd: # Slack/Discord/PagerDuty 등에 알람 send_alert(f"🚨 API 비용 임계값 초과: ${current_spend:.2f} / 상한 ${threshold_usd}") return True # 파이프라인 중단 return False이 함수를 장기 실행 파이프라인의 루프 진입점에 배치한다. 15분마다 체크하는 cron으로 돌리는 것도 방법이다.

자동화 파이프라인 설계 시 체크리스트
코드를 짜기 전에 답해야 하는 질문들이다.
루프 설계
- 최대 반복 횟수가 명시적으로 정해져 있는가?
- 조건이 절대 참이 되지 않는 상황이 가능한가? (무한 루프 위험)
- 에러 발생 시 즉시 재시도인가, 아니면 backoff + 횟수 제한인가?
비용 추적
- 각 API 호출의 예상 토큰 수를 알고 있는가?
- 일/월 예상 비용 계산이 완료되었는가?
- 실제 비용을 주기적으로 로깅하는 코드가 있는가?
차단 장치
- Console의 Monthly budget이 설정되어 있는가?
- 앱 레벨의 비용 임계값 체크 로직이 있는가?
- 이상 징후 발생 시 알람 채널이 연결되어 있는가?
이 중 하나라도 “아니오”라면 프로덕션 배포 전에 반드시 채워야 한다.
토큰 비용 계산 — 직접 해보는 법
실제로 어떤 작업이 얼마나 드는지 미리 계산해두는 습관이 중요하다.
# 간단한 비용 추정기def estimate_cost( input_tokens: int, output_tokens: int, model: str = "claude-sonnet-4-6") -> float: # 2026-06 기준 가격 (USD per 1M tokens) pricing = { "claude-opus-4-7": {"input": 15.0, "output": 75.0}, "claude-sonnet-4-6": {"input": 3.0, "output": 15.0}, "claude-haiku-4-5": {"input": 0.8, "output": 4.0}, } p = pricing.get(model, pricing["claude-sonnet-4-6"]) cost = (input_tokens / 1_000_000 * p["input"]) + \ (output_tokens / 1_000_000 * p["output"]) return cost
# 예시: 하루 10,000번 호출, 평균 500 input / 200 output 토큰daily_cost = estimate_cost(500, 200) * 10_000print(f"일 예상 비용: ${daily_cost:.4f}")# → 일 예상 비용: $0.4500 (약 $450/월)claude-opus-4-7으로 같은 규모를 돌리면 일 비용이 $9.75로 뛴다. 모델 선택 하나가 월 청구서를 20배 이상 바꿀 수 있다.
김덕환 운영자가 봤을 때
OpenClaw에서 6개 에이전트를 돌리다 보면 cron이 루프를 타거나, ACP child가 예외 없이 반복 실행되는 상황이 생긴다. 실제로 내가 경험한 사고도 luna-agentgram-research처럼 잘못된 모델 prefix 하나 때문에 연속 실패하는 job이 쉬지 않고 재시도하는 패턴이었다. Anthropic API가 아니라 내부 orchestration 비용이었지만 구조는 똑같다.
김덕환 운영자도 비슷한 상황을 만났을 거다. 에이전트 하나가 조용히 오작동하면서 API 크레딧을 소비하고 있었는데, 알람이 없었다면 다음 청구서에서야 알았을 일이다. $500M 사고는 극단적 사례지만 방향은 동일하다. 파이프라인을 키우기 전에 비용 상한선과 알람 채널을 먼저 세팅해야 한다. 에이전트 운영에서 “비용 가시성”은 성능 지표만큼 중요한 신호다.
요약: 지금 바로 할 세 가지
$500M 사고를 반면교사 삼아 오늘 바로 실행할 수 있는 항목이다.
- Anthropic Console → Settings → Limits → Monthly budget 설정 (현재 월 소비의 3~5배)
- API 호출 코드에 재시도 횟수 상한 추가 —
max_retries=3이면 충분 - 비용 임계값 체크 cron 작성 — 15분~1시간 주기로 현재 사용량 확인 + 초과 시 알람
AI 도입의 다음 단계는 성능이 아니다. 비용 예측 가능성과 안전한 상한선이다. 잘 돌아가는 파이프라인이 잘못된 설정 하나 때문에 청구서 폭탄이 되는 일은 기술 문제가 아니라 운영 문제다. 그리고 운영 문제는 항상 먼저 막을 수 있다.