지난 7월 7일 오후 10시 20분, 국내 한 개발자에게 결제 실패 안내 메일이 도착했다. 청구 금액은 166만9,875.90달러였다. 처음에는 피싱을 의심했다. 그러나 발신 주소와 결제 링크는 Anthropic의 결제 대행사인 Stripe의 정식 인보이스 시스템으로 연결돼 있었다.
이상한 일은 다음 날 다시 벌어졌다. 7월 8일 오후 11시 42분, 두 번째 결제 실패 메일에 적힌 금액은 1,662만7,739.70달러였다. 하루 만에 약 10배로 늘어난 액수로, 한화로는 247억 원 안팎이다. 단순히 잘못 작성된 이메일도 아니었다. 결제 요청은 실제 금융 시스템까지 전달됐고, 연결된 카드의 승인이 거절되면서 출금만 이뤄지지 않았다.
사용자는 여러 AI 에이전트와 자동화 스크립트를 운영하고 있었다. 처음에는 자신이 만든 시스템 어딘가에서 Anthropic API가 반복 호출됐을 가능성을 의심했다. 봇과 워커, 프록시 서버, 예약 작업 등을 점검했지만 실제 비용을 발생시킬 수 있는 API 키는 찾지 못했다. Anthropic 대시보드에 표시된 API 사용량도 0이었다. 그는 결국 Claude Max 구독을 중단하고 등록해 둔 카드까지 정지시켰다.
원인은 사건 발생 뒤 일주일가량이 지나서야 알려졌다. Anthropic이 사용자에게 보낸 답변에 따르면 해당 계정의 자동 충전 금액이 정상 범위를 벗어난 값으로 잘못 설정돼 있었다. 회사는 자동 충전 기능을 비활성화하고 금액을 기본값으로 되돌렸으며, 무단 접근이나 계정 탈취는 아니었다고 설명했다. 실제 돈도 빠져나가지 않았다. 그러나 자동 충전 값이 왜 1,662만 달러가 넘는 결제 요청으로 이어졌는지, 그 과정에서 비정상적인 금액을 걸러낼 장치가 왜 작동하지 않았는지는 공개되지 않았다.
사건은 청구 오류에서 끝나지 않았다. 사용자는 고객지원과 기술·마케팅 부서 등 여러 창구에 15차례 메일을 보냈다. 나흘 뒤에야 실제 담당자에게 전달하겠다는 자동 안내를 받았다. 수백억 원 규모의 결제 요청이 발생했지만, 이를 긴급 사고로 분류해 곧바로 사람이 대응하는 절차는 보이지 않았다. Anthropic은 이후 고객과의 소통을 통해 문제가 해결됐다고 밝혔지만, 보상이나 별도의 후속 조치는 발표하지 않았다.
여기서 중요한 것은 실제로 247억 원이 인출됐느냐가 아니다. 사용량이 0으로 표시된 계정에서 거액의 청구서가 만들어졌고, 그 결제 요청이 금융 시스템까지 도달했으며, 사용자가 여러 날에 걸쳐 오류를 직접 입증해야 했다는 사실이다.
AI 요금은 어느 한순간 완성되지 않는다. 작업이 모델 호출로 바뀌고, 호출량이 사용량으로 기록되며, 여기에 가격과 할인, 구독 한도와 추가 사용량이 적용된다. 이후 인보이스가 만들어지고 결제가 집행된다. 이번 사건은 이 과정 가운데 어느 한 단계가 어긋나더라도, 오류가 다음 단계로 그대로 전달될 수 있다는 점을 보여준다.
그렇다면 이것은 한 사용자의 계정에서 우연히 발생한 예외였을까.
한 번의 오류는 아니다
247억 원 청구서는 규모 면에서 극단적이다. 그렇다고 이 사건 하나만으로 Anthropic의 과다 청구가 광범위하게 발생한다고 단정할 수는 없다. 다만 최근 공개된 다른 사례들을 함께 보면, AI 과금이 어긋나는 방식이 하나뿐은 아니라는 점은 확인할 수 있다.
지난 4월에는 Claude Code의 과금 경로가 특정 문자열 하나 때문에 달라지는 오류가 발견됐다. Git 커밋 기록에 대문자로 된 HERMES.md라는 문자열이 들어 있으면, Claude Max 구독에 포함돼야 할 요청이 별도의 ‘추가 사용량’으로 분류됐다. 문제를 제보한 사용자는 월 200달러짜리 Max 요금제의 주간 한도를 대부분 남겨둔 상태에서 추가 사용 크레딧 200.98달러가 소진됐다고 밝혔다. 같은 문자열을 소문자로 바꾸거나 커밋 기록에서 제거하면 문제가 사라지는 재현 절차도 공개됐다.
이 문제는 Anthropic의 Claude Code 공식 저장소에서 ‘비용’ 관련 버그로 분류돼 종료됐다. Anthropic 측 담당자는 영향을 받은 사용자에게 환불하고, 한 달분에 해당하는 200달러의 크레딧을 추가로 제공하겠다고 밝혔다. 이는 사용량이 폭주한 사례가 아니었고, 사용 자체는 정상적이었지만, 시스템이 요청의 성격을 잘못 판단하면서 비용이 다른 통로로 빠져나간 경우였다.
기업 청구서에서도 유사한 불일치가 제기됐다. AI 비용 감사 업체 Vaudit은 지난 3월부터 6월까지 60개 기업의 AI 지출 3,400만 달러를 검토해 약 170만 달러의 과다 청구를 찾아냈다고 밝혔는데, 이는 감사 대상 금액의 약 5%에 해당하는 규모다. Vaudit에 따르면 이 가운데 약 80%는 Anthropic과 OpenAI, AWS, Google Cloud, Microsoft Azure 등 공급자나 클라우드 플랫폼에서 크레딧으로 조정됐다.
Vaudit이 제시한 오류 유형은 한 가지가 아니었다. 실제 이용한 모델보다 비싼 요율이 적용되거나, 결과가 반환되지 않은 요청에 비용이 붙고, 에이전트가 실패한 작업을 반복하면서 중복 비용이 쌓이는 사례가 포함됐다. 서비스 장애 중에도 청구가 이어지거나, 클라우드의 오케스트레이션 오류로 하나의 요청이 두 모델에 동시에 전달된 경우도 있었다. Vaudit은 고객의 AI 환경에 별도 소프트웨어를 설치해 원시 사용 기록을 수집하고, 이를 공급자의 인보이스와 대조했다고 설명한다.
다만 이 수치를 AI 산업 전체의 평균 오류율로 해석해서는 안 된다. 5%는 Vaudit이 확보한 60개 기업의 감사 대상 인보이스에서 나온 비율이며, Vaudit은 과다 청구 탐지 서비스를 판매하는 당사자이기도 하다. 표본의 선정 방식과 기업별 세부 내역도 전부 공개되지는 않았다. 따라서 이 결과는 AI 요금의 약 5%가 보편적으로 잘못 청구된다는 증거라기보다, 일정 규모의 기업 환경에서 사용 기록과 인보이스를 대조했을 때 무시하기 어려운 차이가 발견됐다는 자료에 가깝다.
Anthropic도 Vaudit의 설명을 그대로 인정하지는 않았다. 회사 측은 미완료 요청이나 오류 메시지에 비용을 부과하지 않으며, 사용자의 요청을 알리지 않은 채 다른 모델로 보내지도 않는다고 반박했다. 과다 청구가 광범위하게 벌어지고 있다는 징후도 확인되지 않았다는 입장이다.
책임 소재 역시 하나의 기업으로만 돌리기 어렵다. Vaudit이 검토한 과금 결정의 약 절반은 모델 기업과 고객 사이에 AWS Bedrock, Google Vertex AI, Microsoft Azure 같은 클라우드 플랫폼이 끼어 있었다. 요청을 어느 모델로 보낼지 결정하는 과정이나 실제 인보이스를 만드는 단계에서 중간 플랫폼의 오류가 발생할 가능성도 있다는 뜻이다.
지금까지 공개된 자료만으로 Anthropic의 청구 시스템 전체가 구조적으로 고장 났다고 결론 내릴 수는 없다. 그러나 247억 원 사건을 단순한 숫자 입력 실수로만 넘기기도 어렵다. 자동 충전 값이 비정상적인 인보이스로 바뀐 사례, 정상 구독 요청이 추가 사용량으로 분류된 사례, 기업의 자체 기록과 공급자 청구서가 일치하지 않은 사례는 서로 다른 지점에서 발생했다.
하나는 사용량과 무관한 청구 생성의 오류였고, 하나는 과금 경로를 잘못 선택한 분류 오류였다. 또 다른 하나는 여러 공급자와 클라우드가 얽힌 기업 청구서를 사후에 대조해야만 발견할 수 있는 불일치였다.
문제는 한 번의 사고가 반복됐다는 데만 있지 않다. AI 비용이 만들어지는 과정 곳곳에 서로 다른 종류의 오류가 들어갈 수 있고, 사용자는 최종 청구서가 도착하기 전까지 그 과정을 거의 볼 수 없다는 데 있다.
AI 청구서는 어디서 어긋나는가
AI 요금은 하나의 숫자로 시작하지 않는다. 사용자의 명령이 여러 차례의 모델 호출로 바뀌고, 각각의 호출량이 토큰으로 집계된다. 여기에 모델별 가격과 구독 한도, 추가 사용량, 선불 크레딧이 적용된 뒤 인보이스가 생성되고 결제가 이뤄진다. 우리가 마지막에 받아보는 청구액은 이 여러 단계를 통과한 결과다.
따라서 AI 요금이 예상과 달라지는 이유도 하나가 아니다. 실제 사용량이 급증할 수도 있고, 사용량은 정상이지만 다른 가격이 적용될 수도 있다. 사용 기록은 멀쩡한데 청구서를 만드는 과정에서 오류가 발생할 가능성도 있다. 겉으로는 모두 ‘과다 청구’처럼 보이지만, 문제가 시작된 지점은 서로 다르다.
소비의 생성 — 한 번의 명령이 반복 호출이 된다
일반적인 챗봇에서는 질문 한 번에 답변 하나가 돌아온다. 그러나 Claude Code와 같은 AI 에이전트는 파일을 읽고, 코드를 수정하고, 명령을 실행하며, 필요하면 테스트 결과를 확인해 다시 작업한다. 사용자가 한 번 지시했더라도 내부에서는 여러 차례의 모델 호출과 도구 사용이 이어질 수 있다. Anthropic이 비대화형 작업에 에이전트의 최대 진행 횟수를 제한하는 --max-turns 옵션을 별도로 제공하는 것도 이 때문이다. 도구 정의와 실행 결과 역시 입력·출력 토큰에 포함되며, 서버 측 도구를 사용하면 별도의 사용료가 더해질 수 있다.
이 구조에서는 시스템에 오류가 없어도 비용이 예상보다 빠르게 늘어날 수 있다. 작업이 실패할 때마다 다시 시도하거나, 여러 파일을 반복해서 읽거나, 하나의 에이전트가 다른 에이전트를 호출하면 사용량이 계속 쌓인다. 이는 잘못된 청구가 아니라 실제로 발생한 소비다. 다만 사용자는 하나의 작업을 맡겼다고 생각하는 반면, 과금 시스템은 그 안에서 발생한 모든 호출을 각각 계산한다.
우버의 사례는 이런 차이를 보여준다. 우버 최고경영자 다라 코스로샤히는 2026년 전체를 기준으로 편성한 AI 토큰·인프라 예산을 약 3~4개월 만에 소진했다고 밝혔다. 그는 토큰 소비 증가가 실제 제품 개선과 어느 정도 연결되는지 판단하기 어려워지면서, 회사가 인력과 AI 인프라 예산의 관계를 다시 계산하고 있다고 설명했다. 이 사례는 청구 오류의 증거가 아니다. 정상적으로 집계된 AI 사용량도 기존 소프트웨어 예산의 속도와 규모를 넘어설 수 있다는 사례에 가깝다.
사용량의 측정 — 공급자가 계산한 숫자만 보인다
사용량이 발생하면 다음 단계는 측정이다. Anthropic은 API 응답에 입력·출력 토큰과 캐시 사용량을 표시하고, 기업 고객에게는 API 키·워크스페이스·모델별 사용량과 비용을 조회할 수 있는 관리 기능을 제공한다. Claude Code 역시 조직과 사용자 단위로 사용량과 비용을 확인할 수 있다.
그러나 이처럼 상세한 자료가 제공되더라도, 기본적인 계량 주체는 여전히 공급자다. 어떤 요청이 몇 개의 토큰으로 계산됐는지, 캐시가 적용됐는지, 어느 모델과 서비스 등급이 사용됐는지는 공급자의 시스템이 판정한다. 사용자가 보는 대시보드와 비용 보고서도 그 판정 결과를 다시 보여주는 화면이다.
전기요금이라면 외부 계량기를 설치해 공급자의 수치와 비교할 수 있다. AI 서비스에서는 고객이 별도의 호출 로그를 남기거나 중간 게이트웨이를 운영하지 않는 이상, 공급자가 만든 사용량 기록을 독립적으로 재현하기 어렵다. Vaudit이 고객 환경에서 별도의 기록을 수집하고 이를 공급자 인보이스와 대조한 이유도 여기에 있다. 문제는 대시보드가 없다는 것이 아니라, 대시보드와 청구서가 같은 계량 체계에서 만들어진다는 데 있다.
가격의 적용 — 같은 작업도 경로에 따라 요금이 달라진다
측정된 사용량에는 다시 가격이 붙는다. 이 단계에서는 얼마나 사용했는지만큼이나, 어떤 경로로 사용했는가가 중요하다.
Claude의 구독 요금제와 API는 별개의 과금 체계다. Pro나 Max 구독에 포함된 Claude Code 사용량이 남아 있어도, 컴퓨터에 ANTHROPIC_API_KEY 환경 변수가 설정돼 있으면 Claude Code는 구독 계정이 아니라 해당 API 키로 인증한다. 이 경우 사용량은 구독 한도에서 차감되지 않고 표준 API 요율로 청구된다. Anthropic도 공식 도움말에서 두 체계가 분리돼 있으며, API 키 환경 변수가 구독 인증보다 우선한다고 안내한다.
기업 환경에서는 경로가 더 늘어난다. Claude Code를 Anthropic API에 직접 연결할 수도 있지만, Amazon Bedrock이나 Google Cloud, Microsoft의 클라우드 환경 또는 별도의 LLM 게이트웨이를 거칠 수도 있다. 게이트웨이 자격 증명이 사용되면 개인의 Claude 구독은 적용되지 않고, 요청을 전달한 조직이나 클라우드 계정에 토큰 단위 비용이 부과된다. 같은 Claude Code 화면에서 같은 작업을 수행하더라도, 인증 정보와 연결 경로에 따라 비용의 부담 주체와 청구 방식이 달라지는 셈이다.
앞서 살펴본 HERMES.md 사건은 이 분류 단계가 잘못 작동한 사례다. 특정 문자열이 최근 커밋 메시지에 포함되자 Max 요금제에 포함돼야 할 요청이 별도의 추가 사용량으로 전달됐다. 사용자가 더 많은 작업을 한 것도, 더 비싼 모델을 직접 선택한 것도 아니었다. 요청을 어느 비용 항목에 넣을지를 시스템이 잘못 판단했다.
이처럼 AI 과금에서는 사용량이 정확하더라도 청구액이 틀릴 수 있다. 토큰을 세는 과정과 그 토큰에 가격표를 붙이는 과정이 서로 다르기 때문이다.
청구의 생성 — 사용량과 인보이스가 갈라진다
가격까지 적용되면 인보이스가 만들어진다. 정상적인 경우라면 사용량과 단가를 합산한 결과가 청구액으로 이어진다. 그러나 247억 원 유령 청구서 사건은 이 연결이 항상 보장되는 것은 아니라는 점을 보여줬다.
Anthropic은 해당 사건의 원인으로 잘못 설정된 자동 충전 기능을 지목했다. 자동 충전을 비활성화하고 설정값을 기본 상태로 되돌렸으며, 실제 금액은 출금되지 않았다고 설명했다. 하지만 잘못된 설정값이 어떤 계산을 거쳐 1,662만 달러가 넘는 인보이스로 바뀌었는지는 공개하지 않았다.
공개된 내용만으로 내부 시스템의 정확한 작동 방식을 단정할 수는 없다. 다만 결과적으로 대시보드의 사용량 0이라는 수치가 거액의 인보이스 생성을 막는 최종 검증 조건으로 작동하지 않았다는 점은 분명하다. 사용량을 보여주는 화면과 청구서를 생성하는 시스템 사이에 별도의 설정값과 자동 충전 로직이 있었고, 그중 하나가 어긋난 상태로 다음 단계까지 진행된 것으로 볼 수 있다.
이는 사용량 측정이 정확하면 청구도 자동으로 정확해진다는 가정을 흔든다. AI 비용은 사용량에 단가를 곱하는 단순한 계산처럼 보이지만, 실제로는 크레딧 잔액과 자동 충전 기준, 월별 한도, 구독 상태, 결제 주기 등 여러 계정 정보가 추가로 개입한다. 사용량과 청구액은 연결돼 있지만, 동일한 숫자는 아니다.
결제의 집행 — 비정상적인 금액도 다음 단계로 넘어간다
인보이스가 생성됐다고 해서 반드시 카드 결제가 이뤄지는 것은 아니다. 결제 전에는 금액 상한과 사용자 확인, 이상 거래 탐지 같은 안전장치가 작동할 수 있다.
현재 Anthropic의 공식 안내에는 Pro·Max 이용자가 월간 추가 사용 한도와 자동 충전 기준을 설정하고, 사용량이 한도에 가까워지면 알림을 받을 수 있다고 적혀 있다. Claude Code에서 크레딧을 구매하거나 자동 충전 설정을 변경할 때는 사용자의 확인도 요구한다. API 조직 역시 월간 지출 상한과 워크스페이스별 한도를 설정할 수 있다.
이런 기능은 정상적인 사용량 증가나 키 유출, 잘못 작성된 반복 호출을 막는 데 유용하다. 그러나 안전장치가 사용자가 입력한 정상적인 설정값만을 감시한다면, 시스템 내부에서 설정값 자체가 비정상적으로 바뀐 경우에는 충분하지 않을 수 있다. 247억 원 사건에서 필요한 것은 단순한 월간 한도만이 아니었다. 평소 결제 규모, 실제 사용량, 계정 상태와 비교해 청구액이 비정상적으로 큰지를 별도로 확인하는 절차였다.
예컨대 사용량이 0인 계정에서 수백억 원 규모의 결제가 생성됐다면, 카드사에 요청을 보내기 전에 청구를 중지하고 사람의 검토를 거치도록 할 수 있다. 평소 수십 달러를 사용하던 계정에서 갑자기 수백만 달러의 결제가 발생한다면, 기존 한도와 무관하게 계정 소유자의 재승인을 요구할 수도 있다.
결제 시스템의 안전성은 오류가 전혀 발생하지 않는 데서만 나오지 않는다. 앞 단계에서 잘못된 값이 들어오더라도 다음 단계에서 이를 비정상으로 판단하고 멈출 수 있어야 한다.
사후 대응 — 청구는 자동이지만, 정정은 매우 느리다
마지막 단계는 사고 이후의 대응이다. 자동화된 과금 시스템은 사용량을 집계하고 인보이스를 생성해 결제 요청을 전달할 수 있다. 반면 오류를 정정하려면 사용자가 사용 기록과 청구서, 카드 승인 내역을 모아 문제를 설명하고, 고객지원 담당자가 이를 다시 확인해야 한다.
여기에는 뚜렷한 속도 차이가 있다. 잘못된 청구는 자동으로 다음 단계에 전달되지만, 이를 되돌리는 일은 사람의 판단을 기다린다. 금액이 실제로 출금되지 않거나 나중에 환급되더라도 계정 정지, 카드 교체, 업무 중단과 문의에 들어간 시간은 남는다.
따라서 청구 오류에 대한 대응을 환불 여부만으로 평가해서는 안 된다. 거액의 이상 청구를 일반 문의와 분리해 즉시 담당자에게 전달했는지, 사용자가 같은 설명을 반복하지 않아도 되는지, 어떤 단계에서 오류가 발생했는지를 확인할 기록이 남아 있는지도 함께 살펴야 한다.
AI 청구서가 어긋나는 과정은 결국 여섯 단계로 나뉜다. 소비가 예상보다 많이 발생할 수 있고, 사용량이 잘못 측정될 수 있다. 정확한 사용량에 잘못된 가격이 붙을 수 있으며, 청구서 생성 과정에서 별도의 오류가 들어갈 수도 있다. 잘못된 청구가 결제 단계에서 차단되지 않을 수 있고, 사고 이후의 정정은 자동 청구보다 느리게 진행될 수 있다.
이 가운데 어느 하나만 고쳐서는 충분하지 않다. AI 요금의 안전성은 각 단계가 정확하게 작동하는 것뿐 아니라, 한 단계의 오류를 다음 단계가 발견하고 멈추는 구조에서 만들어져야 한다.
AI 청구서의 안전장치는 누가 만들어야 하나
청구 오류가 여러 단계에서 발생한다면, 이를 막는 책임도 한 사람에게만 맡길 수 없다. 공급자는 과금 시스템 자체를 통제해야 하고, 기업은 조직 안에서 발생하는 소비를 관리해야 한다. 개인도 자신이 어떤 계정과 인증 경로를 사용하고 있는지 확인할 필요가 있다.
다만 세 주체의 책임이 같은 무게를 갖는 것은 아니다. 사용량을 측정하고 가격을 적용하며 인보이스를 만드는 권한은 공급자에게 있다. 사용자가 할 수 있는 일은 대부분 공급자가 제공한 설정을 확인하고, 이미 발생한 오류에 대응하는 것이다. 방어의 첫 번째 책임은 서비스를 설계하고 운영하는 쪽에 놓여야 한다.
공급자가 막아야 할 오류
공급자가 마련해야 할 첫 번째 장치는 사용량과 청구액의 교차 검증이다. 사용량, 적용 모델, 인증 경로, 자동 충전 값과 최종 청구액이 서로 맞지 않으면 인보이스 발행을 중단해야 한다. 단순히 각 시스템이 입력받은 값을 정확히 처리했는지를 확인하는 것만으로는 부족하다. 여러 시스템에서 나온 결과가 상식적인 범위 안에서 일치하는지도 살펴야 한다.
두 번째는 비정상 금액에 대한 별도의 차단 기준이다. 월간 지출 한도는 사용자가 설정한 예산을 지키는 기능이다. 여기에 평소 결제 패턴과 비교해 갑작스러운 증가를 탐지하는 장치가 더해져야 한다. 사용량과 동떨어진 청구, 기존 결제액을 크게 넘어선 청구, 장기간 활동이 없던 계정의 고액 결제는 자동으로 보류할 수 있다.
세 번째는 청구 경로의 투명성이다. 사용자는 최종 금액뿐 아니라 어느 인증 정보가 사용됐고, 구독 한도와 API 크레딧 가운데 무엇이 적용됐으며, 어떤 모델과 클라우드 경로를 거쳤는지를 확인할 수 있어야 한다. 오류가 발생했을 때 원인을 추적할 수 있는 기록도 함께 남아야 한다.
마지막은 긴급 대응 체계다. 수백만 달러 규모의 비정상 청구를 일반적인 사용법 문의와 같은 대기열에서 처리해서는 안 된다. 일정 금액을 넘거나 실제 금융기관의 승인 거절이 발생한 경우에는 자동으로 고액 청구 전담 절차로 전환하고, 사람이 즉시 확인하도록 해야 한다.
기업이 통제해야 할 지출
기업은 공급자의 대시보드만 확인하는 데서 그치지 않고, 자체적인 사용 기록을 마련할 필요가 있다. Anthropic도 조직이 LLM 게이트웨이를 통해 사용자와 팀별 사용량을 추적하고, 예산과 요청 속도를 제한하며, 모든 모델 호출을 감사 로그로 남길 수 있다고 안내한다.
이때 중요한 것은 비용 한도와 기술적 한도를 함께 두는 것이다. 월간 예산만 설정하면 짧은 시간에 발생하는 폭주를 늦게 발견할 수 있다. 반대로 분당 요청 수만 제한하면 느린 속도로 장기간 이어지는 낭비를 막기 어렵다. 프로젝트·부서·사용자별 지출 상한과 함께, 에이전트의 최대 진행 횟수, 재시도 횟수, 동시 실행 수를 별도로 관리해야 한다.
또한 비용을 모델 단위가 아니라 업무 단위로 볼 필요가 있다. 어느 부서가 몇 개의 토큰을 사용했는지만으로는 지출의 타당성을 판단하기 어렵다. 특정 기능 개발이나 문서 작성, 고객지원 자동화에 얼마가 들었고, 그 결과로 어떤 산출물이 만들어졌는지를 연결해야 한다. 우버가 토큰 소비와 실제 제품 개선 사이의 관계를 고민한 것도 같은 문제다.
마지막으로 공급자 인보이스와 자체 로그를 정기적으로 대조해야 한다. 매달 청구서를 받은 뒤 총액만 확인하는 방식으로는 모델·계정·프로젝트별 오류를 찾기 어렵다. 사용량과 비용 보고서를 API 키, 워크스페이스, 모델별로 나누어 확인하고, 차이가 크면 결제 전에 원인을 조사하는 절차가 필요하다. Anthropic은 기업 고객에게 사용량·비용 보고서와 워크스페이스별 지출 한도를 제공하고 있다.
개인이 확인해야 할 과금 경로
개인 사용자가 먼저 확인할 것은 자신이 어떤 방식으로 Claude Code에 접속하고 있는가이다. 구독 계정으로 로그인했다고 생각해도 시스템에 API 키 환경 변수가 남아 있으면 API 과금이 적용될 수 있다. 구독 사용량과 API 크레딧은 별도의 체계이므로, 로그인 상태와 환경 변수, 실제 비용이 차감되는 대시보드를 함께 확인해야 한다.
추가 사용량을 활성화했다면 월간 한도와 자동 충전 기준도 점검해야 한다. 자동 충전은 작업이 중단되지 않도록 해주는 기능이지만, 잘못된 스크립트나 키 유출이 발생했을 때 비용을 계속 늘릴 수도 있다. 처음에는 낮은 한도를 설정하고, 사용 패턴이 확인된 뒤 조정하는 편이 안전하다. 카드 결제 알림을 활성화하고, 사용하지 않는 API 키를 폐기하며, 프로젝트별로 키를 분리하는 것도 피해 범위를 줄이는 방법이다. Anthropic 역시 API 키별 사용량 확인과 지출 한도 설정을 권고하고 있다.
이상 청구가 발견되면 공급자 문의와 카드사 이의 제기를 동시에 준비해야 한다. 이때 대시보드 화면, 인보이스, 결제 시각, 사용량 기록을 보존하는 것이 중요하다. 다만 이것은 사고 이후의 대응이다. 사용자가 카드 알림을 설정하지 않았거나 환경 변수를 확인하지 않았다는 이유로, 공급자의 청구 오류 책임까지 사용자에게 돌릴 수는 없다.
개인의 점검은 마지막 방어선일 뿐이다. 사용자가 비정상적인 청구를 발견할 수는 있어도, 잘못된 인보이스가 만들어지는 것을 시스템 내부에서 막을 수는 없다.
요금보다 더 큰 문제는 계산 과정이다
AI 비용이 예측하기 어려운 이유는 단순히 많이 써서가 아니다. 한 번의 프롬프트가 여러 차례의 모델 호출과 도구 실행으로 이어지고, 에이전트가 더 많은 자율성을 가질수록 토큰 소비는 빠르게 늘어난다. 그러나 비용의 불확실성은 사용량 폭증보다 더 깊은 곳에서 발생한다. 사용량이 늘지 않았는데도 잘못된 분류나 설정 하나로 청구 금액만 엉뚱하게 튀어 오를 수 있다.
오늘날 AI 과금은 소비, 측정, 분류, 가격 적용, 청구, 결제가 순식간에 맞물려 돌아가는 자동화 파이프라인이다. 이 매끄러운 연결은 정산을 빠르게 만들었지만, 앞 단계의 오류를 다음 단계로 그대로 전달하기도 한다. 측정의 착오는 가격의 왜곡으로, 가격의 왜곡은 잘못된 청구서로 이어진다. 필요한 것은 시스템에 결함이 없으리라는 낙관이 아니다. 어느 단계에서든 이상 징후가 발견되면 다음 단계로 넘어가기 전에 멈추는 안전장치다.
현재의 구조에서 정보는 대부분 공급자 쪽에 있다. 공급자는 사용량을 측정하고, 가격을 적용하고, 청구서를 발행하는 데 필요한 정보를 모두 갖고 있다. 반면 사용자는 최종 결과를 받아 든 뒤에야 그 과정을 거슬러 추적하기 시작한다.
결국 이 글이 남기는 질문은 요금이 얼마나 나왔는가가 아니다.
계산의 전 과정을 공급자가 통제하는 구조에서, 그 계산이 틀렸다는 사실마저 사용자가 증명해야 하는가.
바로 이 불균형이, AI 과금이 안고 있는 가장 까다로운 문제다.
