본문으로 건너뛰기
블로그로 돌아가기
AI 운영

Claude API 거부 응답 과금 기준과 재시도 점검법

Claude API에서는 모델이 답변을 거부해도 요금이 나올 수 있다. 출력 전과 출력 도중 거부의 과금 기준, fallback 사용량과 HTTP 200의 함정, 요청 기록을 청구 자료와 맞춰 보는 순서를 정리했다.

7분 소요AI 운영
Claude APIAnthropicAPI 비용AI 운영
Claude API 거부 응답 과금 기준과 재시도 점검법

Claude API에서는 모델이 답변을 거부해도 요금이 나올 수 있다. Anthropic이 9월 24일 일부 거부 응답의 과금을 다시 시작했다. 출력 전 거부는 세 유형만 과금된다. 답변 도중 멈춘 거부는 원래부터 과금 대상이다. 근거는 공식 거부 과금 기준이다.

보고서 자동화를 돌리는 팀이라면 확인이 필요하다. 결과물이 멀쩡해도 비용 기록은 틀릴 수 있다. 첫 모델이 거부하고 두 번째 모델이 답했다면, 청구서에는 두 시도가 모두 잡힐 수 있다.

무엇이 바뀌었나

발표는 9월 24일 릴리스 노트에 실렸다. 정확한 시행 시각은 적혀 있지 않다.

핵심은 두 가지다. 출력이 시작됐는지, 그리고 거부 유형이 무엇인지다.

거부 시점유형과금
출력 전bio, frontier_llm, reasoning_extraction실행한 모델의 일반 요율
출력 전그 밖의 유형, null없음
출력 도중일부 답변 뒤 거부입력과 이미 만든 출력

공식 과금 기준은 모든 플랫폼에 같다. Claude API, Amazon Bedrock, Claude Platform on AWS, Google Cloud, Microsoft Foundry가 모두 해당된다. 과금 유형 목록은 2026년 9월 기준이다. 바뀔 수 있으니 운영 전에 다시 확인하자.

Claude 심볼에서 출력 전과 출력 중 거부로 갈라지는 흐름. 출력 전 지정 세 유형은 과금, 그 밖과 null은 비과금, 출력 중에는 입력과 생성한 출력에 과금.
거부 시점과 유형부터 나누면, 답변이 없어도 요금이 나오는 경우가 보인다.

무료 거부에도 흔적은 남는다. 출력 전 거부는 본문이 비어 있다. 그래도 usage(토큰 사용량 항목)에는 토큰 수가 찍힌다. 속도 제한에도 들어간다. 토큰 수만 보고 요금이 나갔다고 판단하면 안 된다. 근거는 비과금 거부의 사용량과 속도 제한 설명이다.

재시도하면 첫 요청 요금은 어떻게 되나

가상의 광고 보고서 자동화를 예로 든다. 첫 모델이 요청을 거부했다. 두 번째 모델이 보고서를 완성했다. 파일은 정상 전달됐다. 마지막 응답만 기록했다면 첫 거부는 로그에서 빠진다.

거부된 요청을 다른 모델로 다시 보내는 것을 fallback(대체 모델 재시도)이라 한다. 첫 시도가 과금 대상이었다면 그 요금은 그대로 남는다. 다음 시도가 성공해도 마찬가지다. fallback은 운영자가 켜는 선택 기능이다. 모델을 바꾼다고 답이 보장되지도 않는다.

첫 요청, Claude의 거부 응답, 선택적인 다른 모델 재시도, 성공한 경우의 최종 답변 순서. 처음 요청과 재시도 요금을 함께 확인하도록 연결한 그림.
보고서 하나가 나오기까지 실행된 시도를 모두 함께 본다. 실제 청구 내역이 아닌 가상 흐름이다.

서버 측 fallback을 쓰면 HTTP 요청은 한 번이다. 하지만 모델은 여러 번 돌 수 있다. 시도별 사용량은 usage.iterations(시도별 사용량 목록)에 담긴다. 응답 맨 위 usage는 최종 응답을 만든 시도만 보여 준다. 비용을 맞출 때 두 값을 섞으면 안 된다. 자세한 내용은 공식 사용량·과금 설명에 있다.

fallback credit(대체 재시도 크레딧)은 다른 장치다. 같은 대화를 다시 캐시하는 중복 비용만 보정한다. 재시도 전체가 무료가 되지는 않는다. 서버 측 fallback과 SDK 미들웨어는 이를 자동 적용한다. 재시도 코드를 직접 짰다면 크레딧 토큰과 헤더 전달법을 확인하자.

HTTP 200이 성공은 아니다

거부는 오류 코드로 오지 않을 수 있다. HTTP 200으로 돌아온다. 공식 응답 예시에서도 상태 코드는 정상이다. 종료 이유만 stop_reason: "refusal"이다.

HTTP 200 응답을 돋보기로 살펴보니 stop_reason이 refusal인 모습. 거부 여부, 유형, 요청별 비용을 차례로 확인하는 흐름.
응답을 받은 것과 필요한 답을 얻은 것은 따로 확인해야 한다.

다른 종료 이유도 봐야 한다. max_tokens는 출력 한도에 걸려 잘린 답이다. end_turn이어도 내용이 비어 있을 수 있다. 답이 실제로 들어 있을 때만 수치와 형식 검수로 넘어간다. 기준은 공식 종료 이유 안내에 있다.

MCPY는 로컬 서버의 합성 응답 네 건으로 이 차이를 확인했다. 네 건 모두 HTTP 200이었다. 본문을 읽자 거부, 잘린 응답, 빈 응답, 검수 대상으로 갈렸다. 실제 Claude 호출이나 청구 실험은 아니다. 이 결과로 거부율이나 절감액은 계산할 수 없다.

오늘 할 일: 작업 하나만 열어 보자

로그 전체를 정비할 필요는 없다. 최근 끝난 작업 하나면 된다. 아래 순서는 공식 규정이 아니다. MCPY가 제안하는 점검법이다.

  1. 결과물과 실행 기록을 잇는다. 어떤 모델이 몇 번 실행됐는지 찾는다. 서버 측 fallback이면 usage.iterations까지 본다.
  2. 거부 시점과 유형을 확인한다. 출력 전인지 도중인지 나눈다. stop_details.category를 본다. null을 과금 유형으로 바꿔 적지 않는다.
  3. 사용량을 청구 자료와 맞춘다. 금액이 확인되지 않으면 0원이 아니라 미확인으로 둔다.

기록표 항목은 이 정도면 된다. 작업 ID / 요청 ID / 모델 / 종료 이유 / 거부 유형 / 출력 시점 / 사용량 / 재시도 연결 / 비용 확인 상태. 청구 자료가 날짜·모델·워크스페이스 합계로만 나오면 로그도 같은 단위로 묶는다. 고객 정보나 프롬프트 전문은 옮길 필요 없다.

청구 자료를 API로 뽑으려면 Usage & Cost Admin API가 필요하다. 조직 관리자 자격 증명이 있어야 한다. 조직이 없는 개인 계정은 쓸 수 없다. 워크스페이스 전용 키로도 안 된다. Claude Platform on AWS는 이 API를 아직 제공하지 않는다. Console의 Usage·Cost 화면에서 본다. 조건은 Usage & Cost API 공식 문서에 있다.

자주 묻는 질문

이제 모든 거부에 요금이 붙나?
아니다. 출력 전 거부는 세 유형만 과금된다. 나머지 유형과 null은 여전히 무료다. 출력 도중 거부는 예전처럼 입력과 이미 만든 출력에 과금된다.

우리 팀 비용도 늘었을까?
공지만으로는 알 수 없다. 거부 유형과 재시도 기록을 청구 자료와 맞춰 봐야 한다. 사용량과 실제 비용을 따로 기록하는 이유다.

네이버 검색 API도 쓴다면 NAVER API HUB의 요금·호출 한도·재시도 조건도 점검하자. 서비스마다 규칙이 다르다. Claude 기준을 다른 API에 그대로 적용하면 안 된다.

공식 정책 확인: 2026년 9월 28일. 이미지는 과금 조건과 처리 흐름을 설명하는 생성 일러스트다. 실제 제품 화면이나 청구 증빙이 아니다.

같은 주제 글

이 글이 도움이 되었다면 공유해주세요

최신 인사이트

관련 프로젝트

새 글을 이메일로 받아보세요

마케팅, 분석, 개발 인사이트를 정리해서 보내드려요.