Claude Opus 4.7 API 비용 계산법: 긴 문서·긴 대화·배치 작업 예산 잡기

프롬프트 캐싱을 쓰는 경우에는 재사용 가능한 컨텍스트를 따로 떼어 계산해야 합니다. 처음 5분 캐시에 쓰는 토큰은 $6.25/MTok, 처음 1시간 캐시에 쓰는 토큰은 $10/MTok, 이후 cache hit / refresh는 $0.50/MTok입니다. 캐시에 들어가지 않은 새 질문이나 새 메시지는 일반 input 단가로, 모델이 생성한 답변은 output 단가로 계산합니다.

일회성 긴 문서 분석: input + output으로 바로 계산

문서를 한 번만 분석하고 후속 질문이 없다면 계산은 단순합니다. 문서 본문, 시스템 프롬프트, 사용자 질문은 input tokens이고, 모델 답변은 output tokens입니다. 아래 예시는 모두 Claude API 공개 가격 기준입니다.

예를 들어 300k input + 8k output이면 이렇게 계산됩니다.

다만 기존 모델에서 Opus 4.7로 옮기는 경우, 예전 토큰 추정치를 그대로 쓰는 것은 위험합니다. Anthropic 가격 문서는 Opus 4.7이 새 tokenizer를 사용하며, 같은 고정 텍스트의 토큰 수가 최대 35% 늘어날 수 있다고 설명합니다.

예를 들어 기존에 300k input으로 잡았던 작업을 보수적으로 405k input으로 다시 잡고, output 8k를 더하면 다음과 같습니다.

항상 35%가 늘어난다는 뜻은 아닙니다. 다만 아직 실제 토큰 로그가 없다면, 마이그레이션 초기 예산에는 이 정도의 완충치를 넣는 편이 안전합니다.

같은 긴 문서를 반복해서 묻는다면: 캐시가 손익분기점

긴 문서 기반 서비스에서 자주 놓치는 비용은 첫 답변이 아니라, 같은 문서를 매 질문마다 다시 보내는 구조입니다. 문서가 여러 번 조회될 가능성이 있다면 프롬프트 캐싱을 먼저 예산 모델에 넣어야 합니다.

가정은 다음과 같습니다.

• 문서: 300k tokens
• 매번 새 질문: 2k tokens
• 매번 답변: 2k output tokens
• 5분 prompt cache 사용

이 예시에서는 첫 번째 캐시 생성 요청이 캐시 없이 보내는 요청보다 비쌉니다. 하지만 같은 문서에 대해 두 번째 질문이 들어오는 순간 총비용은 역전됩니다.

따라서 긴 문서 Q&A 예산의 핵심은 cache hit rate입니다. 실제로 같은 문서가 반복 조회되는지, 사용자의 후속 질문이 캐시 유효 시간 안에 들어오는지, 매 요청마다 캐시되지 않은 새 컨텍스트를 얼마나 추가하는지를 따로 봐야 합니다.

긴 대화 예산: 대화 기록을 매번 다시 계산하게 두지 않기

긴 대화도 원리는 같습니다. 애플리케이션이 매 턴마다 방대한 대화 기록을 모델에 다시 보내면 input 비용이 빠르게 누적됩니다. 안정적으로 재사용되는 과거 대화 컨텍스트는 프롬프트 캐싱 후보로 먼저 검토해야 합니다.

가정은 다음과 같습니다.

• 과거 대화 기록: 200k tokens
• 매 턴 새 메시지: 1k tokens
• 매 턴 output: 2k tokens

5분 캐시와 1시간 캐시 중 어느 쪽이 유리한지는 단가만 보고 결정할 문제가 아닙니다.

• 사용자가 보통 5분 안에 연속으로 묻는다면 5분 캐시부터 계산합니다.
• 사용자가 5분은 자주 넘기지만 대체로 1시간 안에 돌아온다면, 1시간 캐시의 첫 write 비용이 더 높아도 재생성 비용을 줄일 수 있습니다.
• 응답 간격이 들쑥날쑥하다면 실제 트래픽 일부를 샘플링해 cache hit rate를 먼저 측정한 뒤 구조를 조정하는 편이 낫습니다.

배치 작업: 할인 확인 전에는 동기식 공개가로 보수 계산

배치 작업은 오프라인 분석, 데이터 라벨링, 대량 요약, 대량 분류에서 자주 쓰입니다. 다만 계정, 계약, API 종류, 클라우드 플랫폼 엔드포인트에 따라 실제 단가가 달라질 수 있으므로, 적용 가능한 batch pricing을 확인하기 전에는 검증되지 않은 할인을 공식 예산에 먼저 넣지 않는 편이 안전합니다.

보수적으로는 동기식 API 공개 가격을 그대로 적용합니다.

예를 들어 10,000건의 작업이 있고, 각 작업이 2k input + 500 output이라면 다음과 같습니다.

이 $225는 batch discount를 전혀 반영하지 않은 동기식 공개가 기준의 보수 추정치입니다. 이후 실제 적용 가능한 배치 단가를 확인하면, 같은 계산식에서 단가만 바꿔 예산을 낮추면 됩니다.

또한 Anthropic Claude API에 직접 연결하지 않고 클라우드 플랫폼이나 서드파티 모델 라우터를 거친다면 청구액이 달라질 수 있습니다. 제3자 자료인 CloudPrice는 Opus 4.7의 Anthropic / global 유형을 $5 input / $25 output per MTok으로 표시하는 한편, 일부 AWS Bedrock 지역형 코드에는 $5.50 input / $27.50 output per MTok도 함께 표시합니다. 이런 자료는 검산용으로 보고, 실제 구매·운영 예산은 사용하는 플랫폼의 청구 페이지, 계약서, 공식 문서를 기준으로 확정해야 합니다.

실무 버퍼: 이론값만 보고 예산 승인하지 않기

실제 토큰 분포가 아직 없다면 이론값은 대체로 낙관적입니다. 최소한 다음 세 가지는 안전 여유로 반영하는 편이 좋습니다.

1. Tokenizer 전환 리스크: Opus 4.7의 새 tokenizer로 인해 같은 고정 텍스트의 토큰 수가 최대 35% 늘어날 수 있습니다.
2. Cache hit rate 불확실성: 캐시는 같은 컨텍스트가 실제로 반복 사용되고, 유효 시간 안에 다시 호출될 때 비용을 크게 낮춥니다.
3. 실제 사용자 행동: 사용자는 더 긴 답변을 요구하거나, 같은 요청을 재시도하거나, 더 큰 파일을 올리거나, 예상보다 긴 대화 기록을 남길 수 있습니다.

아래 계수는 Anthropic의 공식 견적이 아니라, 예산 관리용 보수 가정입니다.

정식 운영 후에는 추정치에 계속 의존하지 말고, 실제 token 로그, cache hit rate, 청구서 데이터를 다시 넣어 예산 모델을 갱신해야 합니다.

바로 쓰는 월 예산 템플릿

캐싱이 없다면 월 비용은 먼저 이렇게 잡을 수 있습니다.

캐싱이 있다면 한 줄 공식으로 뭉개지 말고 항목을 나눠야 합니다.

실제 구현 전에는 최소한 아래 변수를 채워 보세요.

결론: 예산은 이 순서로 잡기

일회성 긴 문서 분석은 $5/MTok input + $25/MTok output으로 바로 계산하면 됩니다.

같은 긴 문서를 반복해서 묻거나, 긴 대화에서 매 턴 많은 기록을 들고 간다면 프롬프트 캐싱부터 계산해야 합니다. 300k 문서, 2k 질문, 2k output 예시에서는 5분 cache hit 이후 요청이 약 $0.21인 반면, 매번 전문을 다시 보내면 약 $1.56입니다.

배치 작업은 실제 batch pricing, 클라우드 플랫폼 단가, 계약 단가를 확인하기 전까지 동기식 API 공개 가격으로 보수 예산을 잡는 편이 안전합니다. 기존 모델에서 Opus 4.7로 옮긴다면 input token 추정치에 최대 1.35배의 tokenizer buffer를 먼저 반영하고, 여기에 운영 buffer를 더해야 실제 청구액에 더 가까워집니다.